Колонка Антона Рябова – руководителя разработки в Goodt (100+ человек в управлении, 2 продукта, кастомная разработка под клиентские проекты)
Agile – очевидный тренд и массовое явление среди IT-вендоров. Выбирают Scrum и/или Kanban. Отказываются от Waterfall с его клеймом архаичного подхода. Но точно ли в эту эволюционную игру стоит ввязываться всем, ныряя в нее с головой? Я хочу поделиться нашим кейсом и рассказать о том, как мы внедряли разные подходы, какую модель управления нам удалось построить в результате и чего нам это стоило.
Почему не Agile?
Начнем с базы. Рассмотрим ситуацию в контексте общих моделей деятельности IT-вендоров. Давайте выделим две общие категорий.
Первая – вы создаете продукты в рамках замкнутой стратегии. И предлагаете рынку ограниченное коробочное решение. Сбор требований вы проводите через регулярные исследования рынка и на основании обратной связи от своих пользователей. Фильтруете, консолидируете, формируя понимание, что должен представлять из себя продукт и как он должен развиваться. Требованиями вы управляете внутри и работаете по внутреннему релизному графику. Клиенту поставляете только коробочную версию, и он принимает систему с той функциональностью, которая есть на момент покупки. Все доработки и обновления каждый отдельный клиент получает строго в рамках единого и внутреннего графика обновления продукта, и ему крайне сложно повлиять на их состав. Кастомный консалтинг исключен. Здесь Agile вполне себе работает.
Вторая – вы создаете продукты, основываясь на требованиях отдельных клиентов и его проектах. Это означает, что каждый клиент в моменте оказывает значительное влияние на развитие продукта и состав обновлений. Для продуктовой команды эта модель — серьезный вызов. У вас есть минимум времени на консолидацию требований, и формирование коробочного решения становится крайне сложным процессом. Эта модель самая сложная и, к сожалению, не является редким случаем для вендоров.
Внутри второй модели есть развилка.
Вы можете “пилить” продукт вместе с клиентом, встроившись в его процессы. Это формат аутсорса или чистого консалтинга. Вендор предоставляет свои ресурсы, экспертизу и продукт как платформу для реализации идей заказчика. Качество технической реализации — вопрос вендора, целевой результат — ответственность заказчика.
Это не самая популярный формат, потому что риски для заказчика очень высоки, и подрядчик находится в крайне низкой зоне ответственности за результаты проекта.
Здесь Agile может сработать. С оговоркой, что если продакт вдруг осознает, что решение развивается неправильно и нужно срочно изменить вектор, переписав “немного кода” пока не поздно, это принимается за нормальный результат, как и положено в Agile. Итеративный подход как раз дает вам возможность увидеть проблемы и оценить заранее, насколько правильный путь вы выбрали. А вот у бизнеса и заказчика такой результат вызовет однозначный негатив, так как бюджет — запланирован, часть ресурсов — потрачена, а продукт мы в указанные сроки, получается, уже не получим. И непонятно, сколько еще таких осмыслений нам предстоит. Agile на этот вопрос отвечает: “Столько, сколько нужно”. Но этот ответ гарантированно не устроит клиента в B2B и уж точно не соответствует ожиданиям клиентов в России.
Другой вариант наиболее распространенный. Здесь за результат отвечаете вы как внешний подрядчик. У вас есть контрактные обязательства с установленными сроками, ТЗ и бюджетом, где будет четко прописано, что к конкретным датам должны быть завершены обследование, дизайн процессов, разработка, тестирование, приемка и ввод в эксплуатацию. Места для маневров не остается, вы находитесь в ограничениях ТЗ, сроков и бюджетов. И здесь, к сожалению, Agile со своими принципами совсем не вписывается.
Другими словами, в ситуации, в которой работает большинство российских вендоров, Agile в чистом виде не применим.
Проблемы “классической” модели
Классический Waterfall со всеми его этапами: сбор требований, проектирование, разработка, пилот, выход в промышленную эксплуатацию – в IT-разработке обычно приводит к не менее классическим ошибкам.
Выглядит это так. После создания ТЗ заказчик теряется в процессе разработки, а вендор пускается в “глухую” реализацию. Но ТЗ от заказчика — это всегда общие тезисы, которые часто можно трактовать настолько свободно, насколько развита фантазия у команды. Поэтому каким должен быть конечный результат, мало кто понимает. У проектной команды заказчика свое видение, у подрядчика — свое, а бизнес хочет вообще третьего. И это становится хорошо заметно на этапах пилотирования. Вы сделали проект в соответствии со своей трактовкой ТЗ, показали клиенту, получили негативную обратную связь, в спешке перепилили проект раз 10, получили скоуп багов, “слили” бюджет и получили, мягко говоря, недовольного клиента.
Что приводит к таким проблемам? Отсутствие диалога, сквозных механизмов коммуникации в проектной команде и недостаточное внимание к проектированию будущего результата на этапах обследования. Слепая ориентация на документацию и надежда, что обследования процессов AS-IS для понимания, чего конкретно хочет заказчик, достаточно.
Кейс Goodt
Сначала вводные. В нашем портфеле – три продукта, включая платформу для разработки. Начинали мы разрабатывать наши первые решения на проектах в коллаборации с клиентами.
Первые годы работа велась в чисто каскадной модели. Ситуация выглядела так: мы проводили обследование, собирали требования и уходили в реализацию. При этом с клиентами выстраивалась достаточно демократичная модель взаимодействия, и чаще нам приходилось говорить “да”, когда что-то нужно было оперативно осмыслить и “запилить на коленке”. Ошибки в таком процессе всегда были неизбежны, а ресурсов и бюджета на доработку к определенному моменту уже не оставалось.
Естественно, допускались классические ошибки, при которых значительно страдало качество обследования и проектирования целевой системы. К этапу разработки они уже вырастали в большой снежный ком с кучей “белых пятен” в карте процессов. В результате оценка предстоящих работ получается крайне поверхностной, а потерянные на старте требования начинают всплывать в процессе реализации.
Попытки применять Agile в таких случаях для спасения ситуации на проектах c waterfall-моделью также давали негативный результат. Проектные рамки часто не дают развернуться в нужном фреймворке, если клиент не готов идти на изменения в объемах и сроках, менять схему приемки системы и актирования работ.
С точки зрения коробочного решения ситуацию осложняло то, что ее сборка происходила фактически на клиентских проектах. Полученное решение на одном проекте переиспользовалось на другом проекте, кастомизировалось и параллельно дорабатывалось под третий проект. В итоге возникали постоянные коллизии требований и сложности в унификации решения.
Мы ушли в бесконечный цикл доработок. Запросы сыпались одновременно с разных проектов. Времени на консолидацию требований и их упаковку в проработанное коробочное решение практически не оставалось. Стабилизации мы также уделяли минимум времени, что впоследствии вызвало шквал ошибок, которые мы не успевали закрывать. Образовался огромный технический долг, и систему подпирали костыли во всех процессах.
Что мы сделали? Нам пришлось пересмотреть подход к взаимодействию с клиентами и запустить глобальные изменения в наших процессах.
Шаг 1.
Мы разделили продукт: отдельная ветка под каждый проект и отдельная ветка под развитие коробочного решения. Для проектной команды это возможность локализовать задачи и убрать коллизии, вызванные параллельными изменениями системы для разных клиентов. А продуктовая команда получила две важных возможности. Во-первых, это консолидированный бэклог требований, из которого можно отбирать актуальные идеи для развития коробочного решения. Во-вторых, у коробочного решения появился стабильный график выпуска обновлений, на который можно было ориентироваться.Шаг 2.
Мы разделили команды на два блока — проектный и продуктовый. Один управляет изменениями в клиентских проектах, другой формирует набор доработок коробочного решения. Процессы выстраиваются гибко и по-разному: проектные команды работают в каскадной модели, удобной для клиентов, а продуктовая работает по Agile с фреймворком SCRUM.
Шаг 3. Введение дизайн-спринтов
На проектах внедрения мы “подкрутили гайки” и добавили дизайн-спринты в этапы обследования и дизайна, что позволило нам в разы улучшили качество проектирования и оценку, оставшись в понятной для клиентов каскадной модели.
Эти изменения позволили нам воспользоваться принципами Agile и полноценно применить SCRUM в продуктовом блоке.
Какой должна быть среда для развертывания фреймворка SCRUM
- Если вы занимаетесь клиентской разработкой, заказчик должен полностью поддерживать, понимать и осознавать концепцию Agile. Принимать на себя риски и издержки этого подхода. В том числе он должен быть отражен в договорных отношениях. Если такого не случается, лучше строго придерживаться классической модели — детальная проработка процессов, качественный пакет документации, однозначно описывающей этапы разработки и внедрения системы. Попытки же усидеть на двух стульях, когда проект работает по каскадной модели, а работу внутри вы пытаетесь выстраивать по “Agile” ни к чему хорошему не приведут.
- Консолидированный канал требований и единый бэклог. Продуктовая команда не должна работать с разрозненными каналами требованиями. Стрим с требованиями должен быть строго централизован, и команда должна фокусироваться на развитии продукта в рамках установленной долгосрочной стратегии, а не на удовлетворении локальных запросов клиента. Любое раскачивание лодки приведет к разрушению спринтов, релизного скоупа и продукта в целом.
- Изолированная команда. Если вы вдруг решили, что можете и продукт создать, и проект внедрения осилить, будьте добры не рассчитывать на продуктовую команду. Может показаться, что это положительно повлияет на вашу экономику, но в результате вы получите размытую структуру затрат, крайне сложные процессы приоритизации, “раздергивание” и перегрев команды. Внедрение и разработка продукта — процессы разные, и ими занимаются разные люди..
Как мы переходили на SCRUM
Интернет пестрит различные статьями и методичками по внедрению SCRUM. Информации достаточно, много сырых переводов и дельной информации. Я хочу честно делиться своим опытом..
В начальной точки трансформации мы решили, что можно начать с себя, проводя изменения только в команде разработки. Но довольно быстро стало ясно, что нельзя изменить производство, пока не перестроятся все процессы в компании в целом. Фреймворк SCRUM влияет на всю цепочку деятельности компании и требует менять процессы на всех уровнях, поэтому трансформацию нужно разворачивать горизонтально и сверху вниз.
Мы провели коммуникацию по всей компании и организовали серию встреч, чтобы погрузить всех в целевой процесс и новые правила игры.
“Это поможет нам повысить стабильность системы и прозрачность в поставках изменений”, – сказали мы. Все согласились, но поняли не до конца.
Поэтому начались проблемы.
Обычно мы выпускали релизы раз в месяц и отдавали их клиентам. SCRUM предполагает, что в спринте задачи не должны меняться, ну, или изменения могут быть минимальны. Если кто-то не успел внести корректировку или добавить вводные, они уходят в следующий спринт или релиз. Многие к такому готовы не были. И после первых же спринтов, когда все поняли, что объем изменений беспощадно фиксируется и к нам больше нельзя прийти в любой момент с новыми требованиями, чтобы успеть в релиз, всех это стало сильно раздражать.
Ситуация стала патовой. Спринты стали разрушать, подкидывали незапланированные задачи и срочные требования.
Стало понятно, что при таких глобальных изменениях нужно уделять гораздо больше времени на погружение команды, чем мы ожидали.
Тогда мы начали проводить дополнительные встречи с разными департаментами. Первое время нам пришлось очень много общаться, проводя регулярные созвоны, разбирая вопросы от коллег и объясняя им, как нужно действовать в тех или иных ситуациях. В течение нескольких месяцев мы рассказывали, как работать в новом процессе, когда набор требований формируется под релиз и их нельзя менять на ходу, почему эффективнее если внутри итераций мы будем работать не в изоляции, а с активным вовлечением в процесс всей команды.
Нас услышали, и процесс трансформации был запущен. Все роли, участвующие в производстве продукта, объединились и совместно начали генерировать решения. Проектирование и разработка слились в один большой стрим, началась кросс-компетентная коллаборация, в которой участвовали менеджеры, архитекторы, разработчики, аналитики и продакты. Команда могла собраться в любой момент. Коммуникации стали горизонтальными и более эффективными. Мы вообще стали больше общаться. А еще документация стала более сжатой и емкой, мы стали тратить на нее меньше времени, и это позволило сконцентрироваться на реализации и качестве разработки.
Адаптация шла около трех месяцев. Мы ввели ежедневные статусы на 15-30 минут, на которых быстро, сухо и без воды решались оперативные проблемы. Все быстро привыкли к тому, что все роли в одной команде, а не в иерархии: менеджер может задать вопросы архитектору, а продакт — разработчику. А еще все можно оперативно согласовать. Никакой лишней бюрократии.
Было ли сопротивление? Было, но после того, как мы начали больше работать с командой и все прониклись процессом, сопротивление ушло. Более интровертным по профессии разработчикам помогают вливаться в коммуникации другие участники команды – аналитики или продакты, для которых общение – часть софт-скиллов. Они задают вопросы разрабам, вовлекая их в комфортную коммуникацию. Получается не всегда, но почти всегда.
Лично передо мной стоял свой soft-skill вызов: мне нужно было принять ситуацию, что я как руководитель частично теряю контроль. Пришлось учиться больше доверять команде. Раньше мы пытались придерживаться более жестких регламентов: разработчики не принимали никаких задач, пока системные аналитики не верифицировали постановку. Они должны были убедиться в том, что постановка содержит всю необходимую информацию, заполнена строго по форме и в соответствии с требованиями к содержанию. Кросс-коммуникация была исключена. Зато это давало гарантию, что разработчики не будут тратить время разбор плохо сформулированных задач и не будут включаться в работу на коленке. Это не всегда работало, но мы старались придерживаться такого похода.
Но оказалось, что эти риски можно снять и по-другому: объединив всех участников процесса в одну команду и единую зону ответственности. Такая модель помогает фокусировать всех на конечный результат, а не на выполнение только своих локальных задач. А участники команды начинают проводить реальную оценку собственной эффективности, измеряя результаты не количеством выполненных действий, а завершенными задачами. С помощью этой модели мы добились максимального вовлечения специалистов и дали каждому возможность участвовать в процессе и положительно влиять на общий результат. Поэтому сейчас многие рычаги управления перешли именно к команде, что позволило повысить общую ответственность и качество результата. И это — сюрприз! — мотивирует меня майнить еще больше доверия к коллегам.
Два важных вывода
- При переходе на новую модель управления постарайтесь не внедрять ее сразу на весь блок разработки и на все продукты. Проводите внедрение по горизонтали в рамках определенной ветки, где в процесс будут включены все роли процесса — от продавцов до клиентской поддержки. Если кто-либо выпадет из процесса, ничего не получится. Команда разработки — это не разработчики, а вся компания. Будьте готовы к тому, что кривая эффективности при трансформации упадет в течение первых нескольких месяцев. У всех процессов есть специфика, и на калибровку под новую модель уйдет время. Лучше сделайте полигоном один блок, проведите калибровку, задокументируйте полученную экспертизу, напишите инструкцию и проведите тиражирование.
- Даже если компания работает по классическому Waterfall, возможно, стоит выбрать эволюционный, а не революционный подход. Если в простой модели команда работает плохо, стоит для начала подкрутить винтики, изучить точки провалов в коммуникациях и неэффективные роли. А дальше я бы рекомендовал поэтапно и безболезненно переходить к современным моделям. Введите итеративность, тщательней планируйте релизы и сохраняйте стабильный график обновлений, даже срочные фичи могут подождать, перейдите на Kanban, чтобы появилась визуализированная доска, на которой вы бы построили вытягивающую модель и начали больше завершать задачи, чем начинать. Вы сможете отслеживать, насколько эффективно отрабатываются задачи, погрузите в контекст всю команду и начнете обсуждать текущие результаты вместе. Вполне вероятно, что именно команда укажет вам на проблемы, недостаток экспертизы или разрывы в процессах. Уже эта несложная активность поможет вам получить быстрый результат и плюс к эффективности.
