Назад
Представьте: над одним мостом, тоннелем или дорожной развязкой одновременно работают архитекторы, конструкторы, расчётчики и главные инженеры проекта. Их работа тесно связана: изменения в 3D-модели нужно перенести в чертёж, новое конструктивное решение — отразить в архитектурной части, а затем собрать всё в подробные проектные альбомы.
Именно так работает отдел архитектурного проектирования и визуализации АО «Институт Гипростроймост – Санкт-Петербург». За полвека с участием организации построили и реконструировали более 700 инфраструктурных объектов в России и за рубежом — среди них Большой Обуховский мост в Петербурге и Золотой мост во Владивостоке. При таком масштабе работа над каждым объектом быстро превращается в десятки связанных процессов. Поэтому здесь недостаточно просто раздать задачи исполнителям: команде важно одновременно видеть актуальные чертежи, модели, обсуждения и изменения по каждому проекту, не теряя связи между ними.
Золотой мост — вантовый мост через бухту Золотой Рог во Владивостоке, который стал одной из главных достопримечательностей города
Как организовать такую работу? Руководитель группы Анна Калачёва рассказывает, как команда вместе с начальником отдела Леонидом Беляевым выстроила систему в YouGile, провела через неё более 45 проектов и постепенно отказалась от постоянных звонков, ручных напоминаний и поиска информации по чатам.
Проблема: задачи растворялись между почтой, WhatsApp и заметками
Когда Анна пришла в отдел в 2024 году, рабочая информация была разбросана по нескольким каналам: проекты обсуждали в общем чате WhatsApp, исходные данные пересылали по почте, рабочие файлы хранили на общем диске, а отдельные поручения фиксировали в заметках.
Причём в WhatsApp обсуждалось вообще всё. Когда проектов много, крайне сложно вычленить из переписки нужную информацию и понять, кто что должен сделать!
Одновременно в чате могли обсуждать мост, тоннель и дорожную развязку. Новые сообщения быстро вытесняли предыдущие, поэтому через несколько дней уже было сложно понять, к какому объекту относилась договорённость, кто за неё отвечал и оставалась ли задача актуальной.
Путаницу усиливало то, что в разных проектах команда выполняла однотипные работы: выпускала чертежи, собирала 3D-модели, готовила визуализации и проектные альбомы. Поэтому фраза вроде «нужно закончить постобработку» превращалась в загадку: о каком объекте и изображении вообще идёт речь?
Сотрудникам приходилось искать исходные данные и договорённости в разных местах, а руководителям — вручную собирать статусы по проектам. А для начальника отдела архитектурного проектирования и визуализации Леонида Беляева эффективная работа подразделения означала прежде всего прозрачность: в любой момент должно быть понятно, кто, когда и над чем работает.
Поэтому ещё с 2015 года он искал способ собрать эту работу в одной системе: связать задачи с конкретными объектами, хранить рядом материалы и договорённости и при этом сохранить реальную логику проектирования.
Однако подходящий сервис удалось найти не сразу — решение предложила Анна Калачёва.
Интерфейс решает всё. Как «Битрикс24» оказался слишком сложным, а Trello — слишком простым
Первым попробовали «Битрикс24» — но система показалась слишком перегруженной.
Команде было сложно ориентироваться в интерфейсе: там было много разделов, колонок и функций, которые не использовались в повседневной работе. Так что мы довольно быстро отказались от инструмента.
В качестве альтернативы Анна рассматривала Trello, который раньше использовала как личный таск-трекер. Для собственных дел его возможностей было достаточно, но для процессов отдела — уже нет. В сервисе не хватало понятной иерархии между проектами, подзадач и полноценного обсуждения внутри каждого поручения. Такая структура плохо подходила команде, где одновременно ведётся работа над десятками чертежей, моделей, визуализаций и проектных альбомов. Кроме того, институту было важно выбрать российское решение, которое не зависело бы от зарубежного ПО.
В итоге остановились на системе управления проектами YouGile — с ней Анна работала ранее. Сервис был достаточно простым, чтобы команда могла быстро в нём разобраться. И при этом позволял держать в порядке десятки задач по разным направлениям.
Я хочу, чтобы подразделение функционировало максимально продуктивно. В YouGile для этого достаточно открыть доску, чтобы понять, кто чем занят и как движутся задачи. Если работа где-то остановилась, это сразу очевидно.
Но выбрать подходящий инструмент было только половиной задачи. Теперь предстояло перенести в него реальную логику проектирования.
Как разложить проектирование моста на задачи — от концепции до альбома на 200 страниц
Чтобы вместе с текущими поручениями не перенести в YouGile прежнюю путаницу, Леонид Беляев и Анна Калачёва сначала описали в Miro весь путь проекта — от получения исходных данных и разработки концепции до чертежей, 3D-моделей, визуализаций и сборки итоговых альбомов.
Так команда описала связи между этапами работы
На схеме видно: проектирование нельзя представить как линейный конвейер. Архитекторы, конструкторы, специалисты по моделированию и визуализации работают параллельно, а изменения в одном направлении сразу влияют на остальные. Например, новую форму опоры нужно одновременно отразить и в чертеже, и в 3D-модели.
Эту структуру перенесли в YouGile. Реальные направления работы стали отдельными колонками доски:
- разработка концепции;
- чертежи;
- моделирование;
- рендеринг;
- альбомы;
- пути к файлам.
Так YouGile начал повторять реальный процесс проектирования внутри отдела.
От этой структуры команда отталкивается в новых проектах
Если объяснять его совсем просто, всё начинается с исходных данных. В отдел поступают наброски, схемы, требования и другие исходные материалы — обычно через руководителя или главного инженера проекта. При этом готового задания на проектирование моста, тоннеля или развязки может ещё не быть: архитекторы сами помогают определить, какие данные нужны и какой результат предстоит подготовить.
Затем команда разрабатывает концепцию объекта. Например, определяет, как будут выглядеть мост, опоры, пилоны, ограждения, освещение и другие элементы. Иногда решение создают с нуля — но чаще архитекторы работают с уже подготовленным конструктивом и ищут вариант, который одновременно будет выразительным и технически реализуемым.
По одному объекту могут подготовить сразу несколько концепций. Над ними параллельно работают несколько специалистов: один делает эскизы, другой — чертежи, третий — 3D-модель. Поэтому одна и та же часть сооружения постепенно появляется и в двухмерной, и в трёхмерной форме.
Чертежи и модели постоянно сверяют между собой. Если меняется форма опоры в 3D, правку нужно перенести в чертёж. Если новое решение сначала появляется на плане или разрезе — его добавляют в модель. Одновременно специалисты создают окружение: рельеф, дорогу, городскую застройку и другие элементы местности, потому что мост или тоннель нельзя показать в отрыве от реального пространства.
Готовую модель помещают в окружение, выбирают ракурсы, рендерят и обрабатывают изображения
Затем все материалы собирают в проектные альбомы — это подробно оформленные документы, по которым можно понять весь замысел проекта: где расположен объект, как он устроен, как выглядит с разных сторон и какие архитектурные решения предлагает команда.
Один альбом может занимать 160–200 страниц, а для крупного проекта их бывает несколько — по дороге, мосту, предпроектному исследованию и другим частям работы
В YouGile под каждый конкретный результат создают отдельную задачу: разработать вариант опоры, подготовить чертёж, собрать модель окружения, обработать ракурс или оформить раздел альбома. В колонке «Альбомы» находятся задачи по сборке итоговых материалов, а в «Путях к файлам» — ссылки на рабочие папки, модели, чертежи и готовые результаты.
Поэтому доска показывает не линейный конвейер, а несколько параллельных и тесно связанных направлений работы.
Не уверены, как лучше выстроить структуру для своей команды? В отдельной статье мы разобрали семь типовых процессов — от работы с подрядчиками до онбординга. За 10 минут вы сможете собрать под них удобные канбан-доски любого масштаба.
Один шаблон на все проекты не сработал: как команда нашла правильный масштаб досок
После первых запусков отдел продолжил дорабатывать шаблон на реальных проектах. Его несколько раз меняли: добавляли новые этапы, объединяли лишние колонки и корректировали структуру с учётом обратной связи сотрудников.
Обычно под новый объект создают отдельную доску — внутри команды её называют картой проекта. Сотрудники копируют типовую структуру, убирают ненужные задачи и добавляют те, которые требуются для конкретного сооружения.
Вот так шаблон адаптируют под актуальные задачи
Благодаря этому проекты сохраняют общую логику, но не становятся точными копиями друг друга. По доске можно быстро увидеть:
- какие варианты концепции уже подготовлены;
- над какими чертежами и моделями сейчас работают;
- какие изображения нужно отрендерить и обработать;
- какие материалы ещё предстоит добавить в проектный альбом.
Однако правило «один объект — одна доска» подошло не для всех проектов. Однажды команда одновременно работала примерно над 15 сооружениями: мостами, тоннелями и пешеходными переходами. Для каждого требовались собственные чертежи, модели и визуализации — но сначала все задачи разместили в одном пространстве.
По мере развития проекта доска разрасталась, и ориентироваться в ней становилось всё сложнее. Когда в одном пространстве накапливается слишком много параллельных процессов, оно само становится источником путаницы. Как объясняет Анна Калачёва, на старте команда просто не представляла, до какого масштаба вырастет проект.
Этот опыт помог сформулировать правило на будущее: если проект состоит из нескольких самостоятельных сооружений, для каждого лучше сразу создать отдельную доску с общей структурой. Тогда задачи, материалы и обсуждения по разным объектам не будут смешиваться.
Как ставить задачи, чтобы они были ясны без дополнительных вопросов
Общее задание на проектирование команда раскладывает на конкретные результаты. Отдельная задача может быть посвящена чертежу плана, модели опоры, ракурсу визуализации, постобработке изображения или сборке раздела проектного альбома.
Внутри фиксируют всё, что понадобится исполнителю: исходные данные, ссылки на рабочие файлы, комментарии, требования и ожидаемый результат. Когда письменного описания недостаточно, сотрудники созваниваются. Но после разговора материалы, договорённости и принятые решения всё равно добавляют в задачу. Благодаря этому исполнителю не приходится искать контекст в общем чате, почте или личной переписке.
В YouGile рабочие материалы остаются в одном месте
Большинство специалистов редко открывает всю карту проекта. Обычно они заходят в раздел «Мои задачи» и работают со своими поручениями. Поэтому каждая задача должна быть понятна сама по себе: к какому объекту она относится, что именно нужно сделать и какие материалы использовать.
Лайфхак отдела: как называть похожие задачи, чтобы их не путать
В разных проектах архитекторы выполняют похожие действия: готовят чертежи, создают модели, обрабатывают изображения и собирают альбомы. Из-за этого в «Моих задачах» могут одновременно появиться задачи с почти одинаковыми названиями.
Чтобы сотрудники их не путали, в начало каждого названия добавляют индекс объекта:
- КАД-2. Подготовить чертежи плана;
- КАД-2. Выполнить постобработку изображений;
- КАД-2. Собрать итоговый альбом.
По названию исполнитель сразу понимает, к какому проекту относится поручение — для этого даже не надо открывать общую доску
Для дополнительной навигации Анна использует цвета. Срочные задачи выделяет красным, а остальные может окрашивать в цвет соответствующего направления работы. Завершённые поручения обычно становятся белыми. Это не жёсткая система статусов, а простой визуальный ориентир, который помогает быстро заметить приоритетные задачи и оценить общую картину проекта.
Цвет превращает доску в быстрый визуальный ориентир
Но одной понятной структуры было недостаточно. Сотрудникам ещё предстояло привыкнуть к тому, что новые поручения теперь появляются не в личных сообщениях и звонках, а в YouGile. И начать самостоятельно следить за назначенными задачами.
Как чаты в YouGile заменили звонки и напоминания
Как бы ни хотелось сразу отказаться от ручного контроля, поначалу одного назначения в системе было недостаточно. Анна всё равно звонила сотрудникам после постановки задачи и уточняла, увидели ли они новое поручение.
Переход занял время. Анна обсуждала с коллегами, что им мешает в работе, собирала обратную связь и вместе с командой дорабатывала структуру проектов. Новые настройки проверяли на реальных задачах и при необходимости снова меняли.
Постепенно сотрудники увидели практическую пользу YouGile. В каждой задаче уже были исходные данные, рабочие материалы и понятное описание результата — больше не требовалось искать их в общем чате WhatsApp. Особенно новый подход оценили специалисты, у которых одновременно было много поручений по разным проектам. Теперь Анне не нужно дополнительно сообщать о каждом новом поручении.
Я испытываю восторг, когда ставлю задачу, а сотрудники дальше сами всё обсуждают, принимают решения и выдают результат. Система работает уже без моего постоянного контроля!
Когда такой формат прижился в проектной работе, команда стала переносить в YouGile и другие процессы. Например, в отдельном чате фиксируют графики удалённых сотрудников — поэтому не нужно уточнять в переписках, кто и до которого времени сегодня на связи.
Так рабочие вопросы не смешиваются с личной перепиской
Другой чат превратили в аналог технической базы знаний. В нём хранят инструкции по работе с программами и файлами, внутренние правила и ответы на повторяющиеся вопросы. Новые сотрудники могут изучить историю обсуждений и быстрее разобраться в процессах отдела.
На организационной доске «Инфо» команда собрала графики отпусков, полезные материалы и рабочие референсы. Эти пространства не заменяют проектные доски, но помогают синхронизироваться и не возвращать организационные вопросы в личные чаты.
Для нас YouGile перестал быть просто хранилищем задач. Здесь мы ведём проекты, обсуждаем работу, решаем организационные вопросы и храним внутренние инструкции — всё находится в одном месте и всегда перед глазами!
Главный вывод: система должна делать работу команды прозрачной
За время работы в YouGile команда провела через сервис свыше 45 проектов. Под каждый объект заводят отдельную карту и хранят в ней задачи, исходные данные, обсуждения и результаты. Руководителям больше не приходится собирать картину по WhatsApp и почте, а сотрудникам — ждать звонка с напоминанием. Весь путь от концепции до итогового альбома теперь проходит внутри одного рабочего пространства.
Команда собрала собственную систему работы, которая учитывает реальные связи между концепцией, чертежами, 3D-моделями, визуализациями и проектными альбомами. При этом главное для команды — прозрачность. По доске в любой момент видно, кто чем занят, как движутся задачи и где работа остановилась. Именно такая наглядность помогает подразделению работать эффективнее.
Какие решения можно перенять
С чего начать внедрение таск-трекера в проектной команде?
Начните с разбора того, как команда работает сейчас: какие этапы проходит проект, кто участвует в работе, где пересекаются функции сотрудников и какие результаты должны появляться на выходе.
В «Гипростроймосте» сначала собрали схему проектирования в Miro и только после этого превратили её в структуру YouGile. Такой подход помогает сначала понять реальный процесс, договориться о правилах там, где их не хватает, и только потом переносить работу в таск-трекер. Иначе новый сервис рискует просто воспроизвести старый хаос.
Как построить структуру проекта в таск-трекере?
Универсальной схемы не существует. Если реальный процесс действительно укладывается в несколько последовательных этапов, доска тоже может быть простой. Главное, чтобы названия колонок и правила перехода между ними соответствовали тому, как работает команда.
Если несколько направлений идут параллельно и постоянно влияют друг на друга, структуру лучше строить вокруг реальных этапов работы. Именно поэтому в «Гипростроймосте» отдельными направлениями стали концепция, чертежи, моделирование, рендеринг и сборка альбомов.
Не добавляйте этапы, статусы, дедлайны и обязательные поля только потому, что такие возможности есть в таск-трекере. Чем меньше лишних формальностей, тем проще команде работать по новым правилам.Необязательно с первого раза создавать идеальную систему. Её можно протестировать на живом проекте, собрать обратную связь сотрудников и постепенно доработать.
А если не знаете, с чего начать, используйте готовые шаблоны. Например, в этой статье мы показали семь рабочих сценариев: для онбординга, внутренней поддержки, работы с подрядчиками, стратегического планирования и других типовых процессов.
Что хранить внутри задачи, кроме описания?
Весь контекст, без которого исполнителю придётся идти за дополнительными уточнениями: исходные данные, нужные ссылки и файлы, ожидаемый результат, важные договорённости после созвонов.
Чек-листы, дополнительные поля и другие элементы стоит добавлять только там, где они действительно помогают работе, а не превращают постановку каждой задачи в отдельную бюрократическую процедуру.
Главное: чем меньше сотруднику приходится искать информацию в почте, мессенджерах и личных сообщениях, тем проще ему приступить к работе. При этом история проекта остаётся в одном месте и доступна другим участникам команды.
Как перевести сотрудников из чатов в таск-трекер без сопротивления?
Не стоит ждать, что команда изменит привычки за один день. Внедрению нужны и управленческая инициатива, и человек внутри команды, который будет сопровождать новый процесс.
В «Гипростроймосте» поиск подходящего инструмента запустил начальник отдела архитектурного проектирования и визуализации Леонид Беляев. После выбора системы Анна Калачёва взяла внедрение на себя: объясняла правила, напоминала о задачах, собирала обратную связь и дорабатывала структуру, если сотрудникам было неудобно.
Постепенно специалисты увидели практическую пользу: исходные данные и рабочие материалы уже находились внутри задачи, поэтому больше не нужно было искать их в общем чате. Изменения закрепляются быстрее, когда руководитель задаёт направление, а внутри команды есть человек, который помогает последовательно встроить новые правила в повседневную работу.
Если задачи, обсуждения и материалы уже расползлись по чатам и почте, не пытайтесь перенести в таск-трекер сразу всю работу. Выберите один реальный процесс — например, запуск проекта или работу с подрядчиком. Разберите, как он устроен сейчас, и соберите под него простую доску в YouGile. Не добавляйте лишних этапов и правил: протестируйте схему на живой работе, соберите обратную связь команды и только после этого масштабируйте её на другие процессы.
Команды до 10 человек могут пользоваться всем функционалом YouGile бесплатно — навсегда.
