Руководитель разработки в CSI.
Автор книги «Разработка программного обеспечения».
Работаю с несколькими инженерными командами как с одной системой — с их зависимостями, ответственностью, процессами, данными и технологическим контекстом.
Особенно интересны ситуации, когда все заняты и процессы существуют, но результат не соответствует усилиям и непонятно, где находится настоящая причина.
Симптом может быть виден в сроках, производительности команды или качестве процесса. Причина при этом может находиться в структуре зависимостей, границах ответственности, способе формирования работы или самой модели поставки продукта.
Несколько команд работают, процессы существуют, люди заняты — но общий результат не растёт так, как ожидается. В такой ситуации добавлять ещё один процесс обычно рано: сначала нужно понять, где находится ограничение.
Меняется структура, система метрик, способ поставки или сам подход к разработке. До запуска полезно проверить, действительно ли изменение затрагивает ту часть системы, в которой находится проблема.
Работа идёт несколько месяцев, действий много, а ожидаемого эффекта нет. Тогда вопрос часто не в том, как сильнее протолкнуть внедрение, а в том, верна ли исходная гипотеза.
Сначала разобрать систему и отделить наблюдения от предположений.
Понять, что реально ограничивает результат, и проверить альтернативные объяснения.
Только после этого решать, что менять: процесс, структуру, ответственность, метрики, технологический подход — или сам способ организации работы.
Решение для меня не заканчивается выводом: его нужно довести до первых изменений и посмотреть, выдерживает ли гипотеза проверку реальностью.
Не «идеальную организацию» и не одну универсальную метрику. Скорее устройство конкретной системы и связи между её частями.
Что именно должна производить разработка и как выглядит результат для бизнеса и продукта.
Как разделена работа, где возникают зависимости и какие локальные оптимизации мешают системе целиком.
Где находятся полномочия, решения и ручные компенсации плохой конструкции.
Как задача проходит от идеи до production и где на этом пути возникают задержки, возвраты и потери контекста.
Что видит руководство, какие выводы из этого делает и не создают ли показатели ложное ощущение контроля.
Что происходит на границах engineering, продукта и бизнеса и как эти взаимодействия влияют на общий результат.
Ниже не «консалтинговые кейсы», а несколько примеров из моей текущей управленческой практики. Они лучше всего показывают тип задач, который мне интересен.
Новых DevOps брать нельзя, а существующая команда участвует в установке продукта у клиентов. Вместо попытки просто ускорить эту команду была изменена сама схема поставки: продукт стал передаваться в воспроизводимом виде, чтобы клиент мог выполнить установку самостоятельно. Ограничение снималось не локальной оптимизацией, а изменением конструкции работы.
В работе с AI мне интереснее не выдача очередного помощника программисту, а более широкий вопрос: как AI может участвовать в создании продукта, проверять противоречия, помогать удерживать контекст и менять сам способ производства software. Здесь технология важна только вместе с изменением процесса и ролей.
При подготовке одного из запусков задача была не только в том, чтобы «успеть к дате», а в том, чтобы заранее собрать понятную схему взаимодействия и убрать неопределённость между участниками. Запуск, вероятно, состоялся бы и без этого, но позже, с большим количеством ручного разруливания и менее устойчивой организацией работы.
7–10 инженерных команд.
До 100 специалистов.
Несколько команд и инженерное направление, а не отдельная команда как самостоятельная система.
Диагностика сложных проблем, устройство взаимодействия команд, процессы, организационные изменения и новые способы работы.
Техническая база помогает не отделять управление от того, как software действительно проектируется, собирается, поставляется и поддерживается. Со временем основной масштаб работы сместился от отдельных технических решений к системе нескольких команд.
Если ситуация похожа на описанные выше
Без универсальной трансформации и без обещания «починить всё».
Достаточно коротко описать, что происходит, почему это стало проблемой, что уже пробовали и что вы хотите понять или решить.
Обсудить ситуацию