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