Андрей раскрыл главный тезис встречи: бюрократия в IT недооценена разработчиками. Речь идет о формализации процессов – описании того, как компания на самом деле работает. ISO-сертификация, CMMI и подобные фреймворки заставляют договориться о единообразном подходе к работе. Бюрократия сопротивляется хаотичным изменениям, что парадоксально полезно: однажды зафиксированный процесс трудно сломать, и это создает стабильность для измерений – velocity, длительности задач, регрессионного тестирования. Без стабильного процесса все метрики становятся хрупкими и бессмысленными.
Участники обсудили эксперимент с записью времени на задачи в рамках спринта. Один из участников рассказал, как команда добровольно фиксировала затраты времени для ретроспективы, чтобы найти узкие места. Андрей подтвердил, что замеры времени – инструмент наблюдательный, а не управленческий: их нельзя использовать для оценки эффективности, но они помогают выявить скрытые проблемы – например, блокирующий VPN, тормозящую внешнюю команду или неочевидные преграды, которые люди не озвучивают. Важно смотреть не через призму эффективности, а через призму «что работает, а что нет».
Валентин поделился впечатлениями от аудиокниги Сазерленда. Книга воюет с waterfall – что было актуально для 80-х годов, но звучит как «соломенное пугало» сегодня. Сазерленд позиционирует Scrum как универсальную формулу, применимую к любому виду деятельности и ускоряющую работу в 10 раз, что противоречит реальному опыту сообщества. Участники неоднократно обсуждали границы применимости Scrum: часто отказ от полного следования Scrum – это признак того, что он не нужен в данных условиях. Интересный момент из книги – исследование студентов-отличников: одни справляются быстро, другие тратят неделю на ту же оценку, что показывает независимость квалификации от скорости.
Миша выступил с контрпозицией к анти-waterfall нарративу. Его опыт в системной интеграции показывает, что диаграммы Ганта – рабочий инструмент для проектов с физической составляющей: монтаж ЦОД, установка серверов, прокладка сетей. Там четкая последовательность: нет ЦОД – нет стойки, нет стойки – нет сервера. Backlog и Jira бессмысленны в таком контексте. Microsoft Project – основной инструмент, а не Jira. Даже в смешанных проектах с разработкой (один разработчик на прошивку или SharePoint-портал) диаграмма Ганта работала отлично. Все используют метод набегающей волны – крупноблочное планирование далеких этапов с детализацией ближних.
Андрей провел глубокую аналогию change management с рефакторингом и градиентным спуском. Люди начинают менять процессы либо на эмоциональном подъеме (увидели, как круто у других), либо от страха после крупного провала – обе ситуации нездоровые для принятия решений. Рациональный подход – итеративное улучшение: берешь один проблемный отдел, лечишь только его, наблюдаешь последствия. Как в рефакторинге – меняя одну маленькую часть, ты знаешь, что именно вызвало проблему. Гигантский рефакторинг всего и вся приведет к непредсказуемым поломкам. Вера в счастливое будущее – самое опасное при change management.
Обсуждалась статья о том, как бюрократия делает работу видимой. Исторический пример: в Германии 200 лет назад ввели учет срубленных деревьев – работа стала медленнее, но прогнозирование улучшилось, потому что инспекторы могли объективно оценить прогресс. Документация процессов помогает новым сотрудникам – это «интересное чтиво», описывающее входы, выходы, стейт-машины. Андрей предложил тактический подход к документации: не all-in, а ситуативно. Пример – техника «это есть в вики»: валидируешь запрос (если человек вернулся – пишешь статью), таким образом органически наращивая базу знаний без отдельного проекта документирования.
Бюрократия обеспечивает заменяемость людей – а значит, возможность уходить в отпуск. Отпуск руководителя – лакмусовая бумажка: может ли команда прожить три недели без пожара? Бек рассказал про кейс, когда вместо постмортемов писали объяснительные, а команда могла уйти в отпуск только после того, как натренировала нового сотрудника (6 месяцев). Андрей подчеркнул: незаменимость – это зло, и достаточно один раз уйти с позиции незаменимого, чтобы понять, что все будет нормально. Плоды документирования приходят через полгода, но начинают работать достаточно быстро.
Андрей настаивал на том, что тестирование и рефакторинг – это часть разработки, а не отдельная активность. Он всегда закладывал их в стоимость работы. Тест-план – пример полезной бюрократии, о которой забыли в эпоху agile: это способ подумать, как проверить, что спецификация будет работать. Для Legacy-проектов без тестов работает итеративный подход: нашел место – написал тест, сделал маленький рефакторинг. Через полгода уже есть покрытие. В анархических организациях это даже проще – тебе позволят написать что угодно.
| Вопрос | Андрей | Миша | Бек |
|---|---|---|---|
| Бюрократия в IT | Недооценена, помогает стабилизировать процессы и метрики | Рабочий инструмент, особенно в системной интеграции | Нужна, но в маленьких компаниях ее обычно нет |
| Измерение времени | Наблюдательный инструмент, не для оценки эффективности | – | – |
| Scrum и waterfall | Scrum имеет границы применимости, догматизм вреден | Waterfall и Гант работают для физических проектов | – |
| Change management | Маленькие итерации, как рефакторинг – не все сразу | – | – |
| Документация и онбординг | Тактический подход, техника «это есть в вики» | – | Без документации команда не может уйти в отпуск, пока не обучит замену |
| Постмортемы | Инцидент-менеджмент возможен и в маленьких компаниях | – | В маленьких компаниях вместо постмортемов – объяснительные |
Формализация процессов сопротивляется хаотичным изменениям, что делает метрики (velocity, длительность задач) осмысленными. Без стабильного процесса измерения бесполезны – вы будете «угадывать, как оно есть». Перебрасывание людей между задачами и проектами уничтожает возможность замерить длительность любого отдельного процесса.
Не пытайтесь менять всю организацию сразу. Берите один проблемный участок, лечите его, наблюдайте результат. Решения на эмоциях (восторг от чужого опыта или страх после провала) приводят к плохим результатам. Двигайтесь по градиенту – туда, где максимальный эффект при минимальном риске.
Не нужен all-in подход к документированию. Техника «это есть в вики» позволяет валидировать запросы и органически наращивать базу знаний. Каждый ответ на повторяющийся вопрос становится статьей. Через полгода у вас уже есть рабочая база, покрывающая реальные потребности.
Если команда не может прожить три недели без лида – процессы не настроены. Документирование и формализация делают людей заменяемыми, а значит – свободными уходить в отпуск. Плоды приходят через полгода, но это ничто для долгоживущих проектов.
Диаграммы Ганта работают в системной интеграции, Scrum – в продуктовой разработке определенного масштаба. Догматичное следование любой методологии вредно. Границы применимости определяются контекстом: размер команды, тип проекта, физический или цифровой продукт.
Хотите обсудить эти темы с практикующими тимлидами?
Обсудить в Telegram