Как с помощью Agile обеспечить баланс гибкости и стабильности в растущем стартапе

Кейс о том, как команда SmartUnits выстроила гибкие процессы в растущем стартапе.

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

Выход в том, чтобы внедрять гибкие подходы к управлению. На примере кейса мы расскажем о том, как удалось обеспечить баланс гибкости и стабильности в растущем стартапе.

Старт проекта

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

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

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

Второй команде, которая создавала новый продукт, требовалась скорость: научиться выпускать продукт быстро и регулярно, чтобы уменьшать риски того, что мы делаем не то. Цель стояла в быстром запуске MVP и получении фидбека с рынка

Результаты диагностики

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

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

В первой команде мы договорились использовать Kanban-метод – метод эволюционных улучшений. Для того, чтобы сделать первый прототип Kanban системы, начали с инструмента STATIC (System ThinkingApproach for Introducing Kanban). Мы выделили 2 составляющих – upstream, проработка идей, взаимодействие с клиентом, выбор задач и downstream, на котором и происходило создание ценности. Первый этап был нужен для того, чтобы визуализировать то, что происходит на этапе выбора и отсева задач и здесь стояла задача выбирать самые ценные задачи и отсеивать менее ценные, с точки зрения бизнес ценности. На втором этапе – downstream, стояла задача создать быстрый и предсказуемый процесс поставки.

После создания прототипа Kanban-доски, мы вывесили на нее все задачи, которые на данный момент были в команде. Оказалось, что количество задач в работе значительно больше, чем представлялось в начале. После того как это было сделано, мы получили визуализацию того, что происходит внутри команды, какие задачи на каких этапах. Это позволило нам увидеть картину целиком и начать управлять потоком. На уровне инструментов мы умышленно отказались от ведения задач в Jira и стали работать в Miro. Статистику собирали вручную и вели в Excel.

Еще один важный момент на данном этапе – встреча со всеми стейкхолдерами, на которой предстояло договориться о лимитах задач на вход команде, на основе ее пропускной способности. Условно говоря, предстояло договориться брать ровно столько задач, сколько команда перерабатывает за единицу времени. Сначала мы встречались каждые 2 недели, потом поняли, что первые 1,5 месяца нужно разобраться с накопившимися задачами. Ключевым этапом стало то, что мы договорились со стейкхолдерами закрыть «входящую очередь» до тех пор, пока не разгрузим систему. В дальнейшем установили лимит на вход – 2 задачи. Далее мы договорились о лимитах на этапах и первично установили лимита исходя из количества людей, задействованных на данном этапе минус 1. В дальнейшем эти лимиты корректировались исходя из опыта, полученного в работе с Kanban. По сути мы начали учиться завершать задачи, а не брать новые, и давать обещания заказчикам только в тот момент, когда задача начинала делаться, тк до этого ее судьба была еще непонятна и ей предстояло пройти процесс отбора и выбора

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

Внедрение гибких подходов

После регулярных обзоров спринтов и ретроспектив команда начала получать обратную связь, мы все чаще привлекали стейкхолдеров к обзорам и вовлеченность команды начала расти. Конечно, для команд это был непростой путь.

В первой команде результаты стали заметны уже спустя месяц. Работа стала двигаться более упорядоченно. Спустя два месяца мы получили определенные метрики с точки зрения времени выполнения задач, появилась статистика, и мы начали давать стейкхолдерам более объективные ожидания. Например, задача может быть выполнена в течение 47 дней с вероятностью 90%. Такой прогноз мы смогли давать на основе распределения времени выполнения. Тогда появилась следующая цель – сокращать время выполнения задачи до 35 дней, меняя процесс, устраняя блокеры и барьеры, расшивая «узкие горлышки» в процессе. Например, так нам удалось «расшить» тестирование и научиться поставлять небольшими порциями, что значительно ускорило процесс поставки.

Также, спустя 2 месяца мы сделали замер по удовлетворенности работой. Через 2 месяца команды оценили удовлетворенность, прозрачность и предсказуемость поставок от 7 до 9 баллов по 10-балльной шкале. Но самое главное – команда стала самоорганизующейся, люди стали по собственной инициативе помогать друг другу.

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

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

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

Сейчас мы работаем над тем, чтобы у каждой команды появились измеримые цели с метриками, чтобы команды научились ставить себе задачи и брать ответственность за их достижение. Мы держим фокус на том, чтобы объединить все команды на уровне общей цели. Это позволяет привнести ответственность за бизнес результат в команды, сделать их автономными и гибкими, а следовательно, быстрыми.

На следующем этапе мы планируем запускать новые команды, их объединять и синхронизировать, то есть подходим к вопросам масштабирования Agile.

Итоги:

Результатом первых 3 месяцев внедрения Agile-подходов в стартапе стало то, что первая команда стала более управляемой и несмотря на рост пожеланий от клиентов, научилась управлять входящей очередью ожиданий заказчиков и стейкхолдеров и давать объективные ожидания на основе метрик. Во второй команде, запустив Scrum, мы постепенно приходим с стабильному темпу выпуска продукта и фокуса команды на клиентах. А самое главное удалось запустить MVP и начать получать первый фидбек.

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

Данная структура и подходы позволяют нам достичь баланса между хаосом и излишней стабильностью. А самое главное, появляется прозрачность, и возможность видеть все «узкие места» и оперативно реагировать на изменения, внедряя их на системном уровне.