Полный Agile. Честный кейс о проблемах управления от руководителя IT-разработки

Начнем с базы. Рассмотрим ситуацию в контексте общих моделей деятельности IT-вендоров. Давайте выделим две общие категорий.

Первая – вы создаете продукты в рамках замкнутой стратегии. И предлагаете рынку ограниченное коробочное решение. Сбор требований вы проводите через регулярные исследования рынка и на основании обратной связи от своих пользователей. Фильтруете, консолидируете, формируя понимание, что должен представлять из себя продукт и как он должен развиваться. Требованиями вы управляете внутри и работаете по внутреннему релизному графику. Клиенту поставляете только коробочную версию, и он принимает систему с той функциональностью, которая есть на момент покупки. Все доработки и обновления каждый отдельный клиент получает строго в рамках единого и внутреннего графика обновления продукта, и ему крайне сложно повлиять на их состав. Кастомный консалтинг исключен. Здесь Agile вполне себе работает.

Вторая – вы создаете продукты, основываясь на требованиях отдельных клиентов и его проектах. Это означает, что каждый клиент в моменте оказывает значительное влияние на развитие продукта и состав обновлений. Для продуктовой команды эта модель — серьезный вызов. У вас есть минимум времени на консолидацию требований, и формирование коробочного решения становится крайне сложным процессом. Эта модель самая сложная и, к сожалению, не является редким случаем для вендоров.

Внутри второй модели есть развилка.

Вы можете “пилить” продукт вместе с клиентом, встроившись в его процессы. Это формат аутсорса или чистого консалтинга. Вендор предоставляет свои ресурсы, экспертизу и продукт как платформу для реализации идей заказчика. Качество технической реализации — вопрос вендора, целевой результат — ответственность заказчика.

Это не самая популярный формат, потому что риски для заказчика очень высоки, и подрядчик находится в крайне низкой зоне ответственности за результаты проекта.

Здесь Agile может сработать. С оговоркой, что если продакт вдруг осознает, что решение развивается неправильно и нужно срочно изменить вектор, переписав “немного кода” пока не поздно, это принимается за нормальный результат, как и положено в Agile. Итеративный подход как раз дает вам возможность увидеть проблемы и оценить заранее, насколько правильный путь вы выбрали. А вот у бизнеса и заказчика такой результат вызовет однозначный негатив, так как бюджет — запланирован, часть ресурсов — потрачена, а продукт мы в указанные сроки, получается, уже не получим. И непонятно, сколько еще таких осмыслений нам предстоит. Agile на этот вопрос отвечает: “Столько, сколько нужно”. Но этот ответ гарантированно не устроит клиента в B2B и уж точно не соответствует ожиданиям клиентов в России.

Другой вариант наиболее распространенный. Здесь за результат отвечаете вы как внешний подрядчик. У вас есть контрактные обязательства с установленными сроками, ТЗ и бюджетом, где будет четко прописано, что к конкретным датам должны быть завершены обследование, дизайн процессов, разработка, тестирование, приемка и ввод в эксплуатацию. Места для маневров не остается, вы находитесь в ограничениях ТЗ, сроков и бюджетов. И здесь, к сожалению, Agile со своими принципами совсем не вписывается.

Другими словами, в ситуации, в которой работает большинство российских вендоров, Agile в чистом виде не применим.

Классический Waterfall со всеми его этапами: сбор требований, проектирование, разработка, пилот, выход в промышленную эксплуатацию – в IT-разработке обычно приводит к не менее классическим ошибкам.

Выглядит это так. После создания ТЗ заказчик теряется в процессе разработки, а вендор пускается в “глухую” реализацию. Но ТЗ от заказчика — это всегда общие тезисы, которые часто можно трактовать настолько свободно, насколько развита фантазия у команды. Поэтому каким должен быть конечный результат, мало кто понимает. У проектной команды заказчика свое видение, у подрядчика — свое, а бизнес хочет вообще третьего. И это становится хорошо заметно на этапах пилотирования. Вы сделали проект в соответствии со своей трактовкой ТЗ, показали клиенту, получили негативную обратную связь, в спешке перепилили проект раз 10, получили скоуп багов, “слили” бюджет и получили, мягко говоря, недовольного клиента.

Что приводит к таким проблемам? Отсутствие диалога, сквозных механизмов коммуникации в проектной команде и недостаточное внимание к проектированию будущего результата на этапах обследования. Слепая ориентация на документацию и надежда, что обследования процессов AS-IS для понимания, чего конкретно хочет заказчик, достаточно.

Сначала вводные. В нашем портфеле – три продукта, включая платформу для разработки. Начинали мы разрабатывать наши первые решения на проектах в коллаборации с клиентами.

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

Естественно, допускались классические ошибки, при которых значительно страдало качество обследования и проектирования целевой системы. К этапу разработки они уже вырастали в большой снежный ком с кучей “белых пятен” в карте процессов. В результате оценка предстоящих работ получается крайне поверхностной, а потерянные на старте требования начинают всплывать в процессе реализации.

Попытки применять Agile в таких случаях для спасения ситуации на проектах c waterfall-моделью также давали негативный результат. Проектные рамки часто не дают развернуться в нужном фреймворке, если клиент не готов идти на изменения в объемах и сроках, менять схему приемки системы и актирования работ.

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

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

Что мы сделали? Нам пришлось пересмотреть подход к взаимодействию с клиентами и запустить глобальные изменения в наших процессах.

Шаг 1.

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

Шаг 2.

Мы разделили команды на два блока — проектный и продуктовый. Один управляет изменениями в клиентских проектах, другой формирует набор доработок коробочного решения. Процессы выстраиваются гибко и по-разному: проектные команды работают в каскадной модели, удобной для клиентов, а продуктовая работает по Agile с фреймворком SCRUM.

Шаг 3. Введение дизайн-спринтов

На проектах внедрения мы “подкрутили гайки” и добавили дизайн-спринты в этапы обследования и дизайна, что позволило нам в разы улучшили качество проектирования и оценку, оставшись в понятной для клиентов каскадной модели.

Эти изменения позволили нам воспользоваться принципами Agile и полноценно применить SCRUM в продуктовом блоке.

Интернет пестрит различные статьями и методичками по внедрению SCRUM. Информации достаточно, много сырых переводов и дельной информации. Я хочу честно делиться своим опытом..

В начальной точки трансформации мы решили, что можно начать с себя, проводя изменения только в команде разработки. Но довольно быстро стало ясно, что нельзя изменить производство, пока не перестроятся все процессы в компании в целом. Фреймворк SCRUM влияет на всю цепочку деятельности компании и требует менять процессы на всех уровнях, поэтому трансформацию нужно разворачивать горизонтально и сверху вниз.

Мы провели коммуникацию по всей компании и организовали серию встреч, чтобы погрузить всех в целевой процесс и новые правила игры.

“Это поможет нам повысить стабильность системы и прозрачность в поставках изменений”, – сказали мы. Все согласились, но поняли не до конца.

Поэтому начались проблемы.

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

Ситуация стала патовой. Спринты стали разрушать, подкидывали незапланированные задачи и срочные требования.

Стало понятно, что при таких глобальных изменениях нужно уделять гораздо больше времени на погружение команды, чем мы ожидали.

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

Нас услышали, и процесс трансформации был запущен. Все роли, участвующие в производстве продукта, объединились и совместно начали генерировать решения. Проектирование и разработка слились в один большой стрим, началась кросс-компетентная коллаборация, в которой участвовали менеджеры, архитекторы, разработчики, аналитики и продакты. Команда могла собраться в любой момент. Коммуникации стали горизонтальными и более эффективными. Мы вообще стали больше общаться. А еще документация стала более сжатой и емкой, мы стали тратить на нее меньше времени, и это позволило сконцентрироваться на реализации и качестве разработки.

Адаптация шла около трех месяцев. Мы ввели ежедневные статусы на 15-30 минут, на которых быстро, сухо и без воды решались оперативные проблемы. Все быстро привыкли к тому, что все роли в одной команде, а не в иерархии: менеджер может задать вопросы архитектору, а продакт — разработчику. А еще все можно оперативно согласовать. Никакой лишней бюрократии.

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

Лично передо мной стоял свой soft-skill вызов: мне нужно было принять ситуацию, что я как руководитель частично теряю контроль. Пришлось учиться больше доверять команде. Раньше мы пытались придерживаться более жестких регламентов: разработчики не принимали никаких задач, пока системные аналитики не верифицировали постановку. Они должны были убедиться в том, что постановка содержит всю необходимую информацию, заполнена строго по форме и в соответствии с требованиями к содержанию. Кросс-коммуникация была исключена. Зато это давало гарантию, что разработчики не будут тратить время разбор плохо сформулированных задач и не будут включаться в работу на коленке. Это не всегда работало, но мы старались придерживаться такого похода.

Но оказалось, что эти риски можно снять и по-другому: объединив всех участников процесса в одну команду и единую зону ответственности. Такая модель помогает фокусировать всех на конечный результат, а не на выполнение только своих локальных задач. А участники команды начинают проводить реальную оценку собственной эффективности, измеряя результаты не количеством выполненных действий, а завершенными задачами. С помощью этой модели мы добились максимального вовлечения специалистов и дали каждому возможность участвовать в процессе и положительно влиять на общий результат. Поэтому сейчас многие рычаги управления перешли именно к команде, что позволило повысить общую ответственность и качество результата. И это — сюрприз! — мотивирует меня майнить еще больше доверия к коллегам.