Всем привет! Меня зовут Анна Калачёва, я руковожу группой в отделе архитектурного проектирования и визуализации Института «Гипростроймост». Мы проектируем мосты, тоннели и развязки — в том числе Золотой мост во Владивостоке и Большой Обуховский мост в Петербурге.

Со стороны может показаться, что проектирование моста — это последовательность понятных этапов. На деле одна правка может затронуть сразу чертежи, расчёты и 3D-модель, а над объектом параллельно работают несколько специалистов. Когда мы решили перенести этот процесс в таск-трекер, выяснилось неожиданное: сложнее всего было не выбрать сервис и не настроить доски, а понять, как устроена наша работа. Расскажу, как вообще проектируется мост, что мы несколько раз переделывали и какие правила в итоге помогли не потеряться в десятках взаимосвязанных задач.

Таск-трекер не исправит процесс, если вы сами его не понимаете

Когда я пришла в отдел в 2024 году, большая часть коммуникации жила в общем чате WhatsApp: там обсуждали сразу несколько объектов, файлы присылали по почте, поручения оставались после звонков. Чтобы понять статус проекта, руководителю приходилось собирать его по кусочкам. Пока проектов немного, это работает. Но сообщение вроде «нужно закончить постобработку» через несколько дней уже сложно привязать к конкретному объекту.

Поэтому мы решили переехать в таск-трекер: попробовали несколько вариантов и в итоге остановились на российской системе управления проектами YouGile. Для института было важно не зависеть от зарубежного ПО, а нам понравился простой интерфейс и обсуждения прямо внутри задач.

Но выбрать сервис оказалось проще, чем перенести в него реальную работу. Что считать задачей? Как делить проекты на доски? Где хранить исходные данные, если чертежи и модели меняются параллельно и зависят друг от друга? Если это не продумать, старый хаос просто переедет из WhatsApp в таск-трекер. А нам, наоборот, хотелось открывать систему и сразу видеть, что происходит в работе команды. Поэтому вместе с начальником отдела Леонидом Беляевым мы начали с другой стороны.

Как превратить проектирование моста в понятную доску

Сперва мы разложили весь процесс работы в Miro. Хотелось увидеть, как он проходит через отдел и где разные специалисты зависят друг от друга. Схема показала: проектирование не идёт строго по этапам. Чертежи, модели, согласования и визуализации развиваются параллельно, а изменения в одном месте почти всегда тянут за собой правки в другом.

Допустим, приходит новый объект — мост, тоннель или развязка. Сначала мы собираем исходные данные и формируем концепцию. Дальше архитекторы развивают решение, конструкторы проверяют, можно ли его реализовать, а специалисты по 3D собирают модель и окружение — рельеф, дороги, застройку.

По ходу работы промежуточные решения проходят согласование. Если главный конструктор отправляет вариант на доработку, команда возвращается к чертежам и модели. После нескольких таких итераций всё собирается в альбомы — по 160–200 страниц. А на крупных объектах их бывает несколько.

Когда схема была готова, стало понятно, как строить доску. Делить её просто на «Нужно сделать», «В работе» и «Готово» нам не подходило: важнее было сразу видеть, с какой частью проекта сейчас трудится команда. Поэтому колонками сделали реальные направления работы: концепцию, чертежи, моделирование, рендеринг, альбомы и рабочие файлы.

Этого уже хватило, чтобы запустить первую версию шаблона в YouGile и начать вести в ней проекты. Дальше мы просто дорабатывали её по ходу работы: где-то добавляли недостающий этап, где-то убирали лишний, где-то немного меняли структуру. Постепенно получился шаблон, который теперь подходит для большинства объектов.

Сейчас этот шаблон используем как основу: создаём новую доску, копируем структуру и адаптируем её под конкретный объект. Благодаря этому проекты остаются привычными для команды, но не превращаются в одинаковые копии друг друга.

Мы попытались вести 15 сооружений на одной доске. Больше так не делаем

Сначала казалось, что шаблон получился удачным и будет применим везде. Но однажды у нас появился крупный объект из примерно 15 самостоятельных сооружений. У каждого — свои чертежи, модели, визуализации, согласования и правки.

Сначала мы решили вести всё на одной доске. Казалось, так будет проще. Получилось наоборот. Чем дальше шёл проект, тем сильнее доска разрасталась. Задачи разных сооружений перемешивались — так что в какой-то момент само пространство стало мешать ориентироваться.

После этого мы поменяли подход. Теперь, если большой проект состоит из нескольких самостоятельных объектов, для каждого создаём отдельную доску. Шаблон остаётся общим, но внутри — только задачи по конкретному сооружению.

Наверное, это был один из самых полезных уроков за эти полтора года. Мы поняли, что невозможно один раз придумать идеальную систему на все случаи жизни. Реальные проекты всё равно быстро покажут, где придуманная схема перестаёт работать. И тогда проще её поменять, чем заставлять команду под неё подстраиваться.

Сотрудник не должен идти за контекстом в пять разных мест

Когда структура проектов устоялась, мы договорились о простом правиле: всё необходимое для работы должно лежать внутри задачи в YouGile. Исходные данные, ссылки на файлы, требования, комментарии и договорённости — всё собираем там же. Если работа состоит из нескольких этапов, добавляем чек-лист. Так сотруднику не приходится искать детали в WhatsApp, почте или вспоминать созвоны: он открывает задачу и сразу понимает, что нужно сделать.

При этом большинство сотрудников почти не открывает всю доску проекта — день обычно начинается с раздела «Мои задачи». Поэтому каждая задача должна быть понятна сама по себе. В начало названия мы добавляем индекс объекта: не просто «Подготовить чертежи», а «КАД-2. Подготовить чертежи плана». Когда параллельно идёт несколько проектов, так проще сразу понять, к какому из них относится задача.

Ещё я использую цвета. Срочные задачи отмечаю красным, а остальные могу выделять разными цветами в зависимости от направления работы. Это не строгая система — просто быстрый способ увидеть, что требует внимания прямо сейчас.

Вместо новых правил мы старались убирать лишние действия

Технически всё уже работало. Оставалось сделать так, чтобы новая схема стала привычной для команды. Поначалу коллеги по инерции продолжали писать в чаты и звонить. Я и сама могла поставить человеку задачу, а потом всё равно набрать его:

— Ты видел? Я тебе там задачу поставила.

Мы не стали вводить жёсткие правила. Если что-то было неудобно, просто упрощали процесс: меняли структуру, убирали лишние действия, добавляли в задачи недостающий контекст. Постепенно необходимость дублировать поручения звонками и сообщениями исчезла — сотрудники сами начали проверять задачи и обсуждать работу внутри них.

А потом команда стала замечать, что ещё можно упростить. Так в YouGile появился небольшой аналог базы знаний с инструкциями и рабочими правилами, а для всего отдела — чат, где сотрудники отмечают, кто сегодня на связи и в какое время. Вместо отдельного календаря с доступами и правилами нам хватило группового чата, который настраивается за несколько минут и виден всей команде.

Мне кажется, это хороший критерий для внутренних процессов: не обязательно строить идеальную систему, если простая уже решает задачу и ей действительно пользуются.

Если бы мы начинали заново: четыре правила для работы команды

За полтора года у меня сложилось несколько принципов.

Сначала разберитесь, как на самом деле работает команда. Откуда появляются задачи, кто принимает решения, где пересекаются роли и в какой момент теряется информация. Иначе можно идеально настроить таск-трекер и просто перенести в него старый хаос.

Не пытайтесь сразу придумать идеальную структуру. Мы несколько раз меняли шаблон, а однажды разделили одну огромную доску на несколько. Реальная работа довольно быстро показывает, где вы ошиблись. Хорошо, если исправить это можно так же быстро.

Если что-то можно сделать проще — попробуйте сначала простой вариант. Не каждому процессу нужен отдельный сервис, сложный регламент или автоматизация. Иногда достаточно цвета задачи, понятного названия или одного простого правила движения по доске — если оно понятно команде и действительно соблюдается.

Если свести всё к одной мысли, таск-трекер должен отражать реальную работу команды, а не заставлять людей обслуживать систему. Тогда он действительно помогает работать эффективнее: по доске видно, кто чем занят, как движутся задачи и где процесс остановился.

Система управления проектами YouGile бесплатна до 10 человек — без ограничения по функциям и времени.