26 июня у одного из наших клиентов - iDom, завершилась фаза разработки продукта. Мы пообщались директором компании, Николаем Павловым, и рады представить Вам интервью на тематику применения Agile в Start Up проекте.
Николай, ты завершил реализацию своего продукта, используя один из подходов гибкой разработки - SCRUM. Расскажи, с чего все начиналось?
Когда я начал разработку своей стартап-идеи, я решил использовать все те практики, о которых я узнал в свое время, работая с Ruby on Rails. Но тяжело было найти готовых специалистов, а целую команду – практически не реально. К тому же, стоимость разработки была бы неоправданно высокой. Я нашел компромисс в том, что бы подобрать группу разработчиков за приемлемые деньги, обучить их инженерным практикам, помочь выстроить процессы.
В то же время, я попал на конференцию IT Talk, где обсуждались Agile-подходы к управлению проектами разработки. Там я познакомился с Алексеем Кривицким, и на следующий день прошел его тренинг по базовым концепциям Agile и SCRUM.
К тому времени, когда я получил инвестиции, я уже мог сам объяснить Александру Хистеву, директору компании-подрядчика WDG, о преимуществах гибкой разработки. Саша был открыт к экспериментам, мы приняли решение и пригласили Лешу Кривицкого. Запуск проекта, включая тренинги, прошел за неделю.
- Какие ты видел технологические предпосылки использовать SCRUM?
Мой предыдущий опыт говорил о том, что SCRUM подходит для небольших веб-ориентированных проектов. Характерными чертами нынешнего проекта были наличие ключевых требований к пользовательскому интерфейсу, возможность быстрого прототипирования, отсутствие тяжелой архитектуры, которая могла бы потребовать использования более тяжеловесной методологии.
- Что дало использование SCRUM тебе лично, как владельцу идеи и проекта?
Во-первых, глубокую мотивацию команды, которая для меня является большой поддержкой.
Могу привести один пример: на одном из планирований ребята сами предложили провести демонстрацию в дни праздников - 1-го мая. Они понимали, что времени на реализацию одной из важных функций будет мало, но очень хотели закончить ее в предстоящем спринте. (Прим. редактора: команда работает на фиксированной зарплате и не имеет опционов, бонусов, др. видов материальной мотивации)
Это один из примеров, демонстрирующих две очень важные вещи: приверженность правилам процесса (строго ограниченные во времени итерации, потенциально применимый продукт как результат каждой из них) и разделение приоритетов бизнеса. Согласно принципам SCRUM, именно разработчики определяют объем работы на итерацию. Они могли отказаться от реализации этой функции, но не стали этого делать, понимая ее важность.
Отсутствие необходимости давить на команду в вопросах сроков и ответственности к работе - это большой подарок.
Еще один пример мотивированной команды – отношение к неудачным спринтам. Есть внутреннее желание команды – разобраться в причинах ошибок и провалов. Это потому, что люди живут проектом, вкладывают в него все свои старания, и «удовлетворительные» результаты никому не нужны.
Цель ретроспективы в SCRUM – обсудить прошедший Sprint и найти способы сделать следующий более удачным. Ребятам удается докопаться до сути мешающих вещей, потому что они честны с собой. Причиной могли быть и банальная лень, и неудачно проведенное планирование. Именно то, что они сами ищут причины и принимают ответные решения, позволяет быть уверенным в том, что они будут придерживаться их в последствие.
У меня нет необходимости в поиске виновных, во внешнем вмешательстве в процессы, в давлении и принуждении. Это важная характеристика процесса SCRUM, позволяющая получать удовольствие от работы.
Во-вторых, наличие четкого процесса и понимание того, как этот процесс функционирует. Это позволяет предсказывать результаты и дает уверенность в их достижимости.
Практически, SCRUM позволяет предсказывать будущее, на небольшие сроки, в которых мы хотим сосредоточиться на реализации той или иной функциональности продукта. Я могу говорить о том, что эта функция будет готова через две недели, а та – через месяц. Не потому, что я хочу этого, не потому, что мне это необходимо, а потому, что собрались люди, работающие над продуктом, и дали трезвую оценку. Это предсказание не на основе желания, а на основе возможности. Этот прогноз гораздо более реалистичен.
Для бизнеса важно быть правдивым, как с другими, так и с собой, не путать желания с действительностью. Реалистичные прогнозы позволяют избежать многих рисков при принятии решений, и дают основу доверительным отношениям со всеми заинтересованными лицами проекта.
- Ты говорил о поддержке, которую дает мотивация команды. Каким образом она проявляется?
Команда не просто занимается разработкой продукта, она активно участвует в генерации идей. У меня есть общее видение того, каким будет продукт. По результатам общения с экспертами предметной области, я формирую некие требования к нему. Я иду с этими требованиями в команду, не всегда понимая, в какие именно функции продукта они должны вылиться. Зачастую, команда быстро и эффективно помогает мне в этом.
На практике это так, что я прихожу на планирование спринта и говорю на простом «человеческом» языке чего я хочу от продукта. В течение сессии планирования, ребята успевают генерировать массу идей: как это может выглядеть для пользователя, как может влиться в архитектуру приложения, какие еще дополнительные фичи можно реализовать. Поскольку они очень сильно мотивированы, им доставляет удовольствие генерация новых идей для продукта.
- Поскольку ты создавал команду «с нуля», такой мотивации не было вначале. Когда ты почувствовал, что ситуация изменилась?
Я думаю, что потребовалось порядка двух-трех месяцев для того, что бы ребята из проектной группы превратились в действительно сплоченную общими целями команду.
Сам процесс SCRUM является сильным катализатором командного взаимодействия. Например, использование Planning poker как некого ритуала во время сессий планирования,
создает неповторимую атмосферу работы как игры. Благодаря этому может приходить большой поток новых идей, многие из которых оказываются очень интересными.
Зачастую, не только я как Владелец Продукта, но и эксперты предметной области, не имеют представления, как должна выглядеть реализация того или иного требования в продукте. Особенно, если разрабатываешь некую инновационную бизнес-идею - сталкиваешься с высоким уровнем абстракции в требованиях и отсутствием примеров. В таких ситуациях команда здорово помогает. И осознание командой собственной роли и собственной значимости для проекта, создает основу той мотивации, о которой мы говорим.
- Что было твоим личным вкладом в процесс формирование команды?
Наладить процесс живого общения, создать атмосферу постоянного самосовершенствования, заложить основу мотивации – доверие к людям и осознание важности их роли в проекте. Постоянно развиваться самому. И с определенного момента, ты больше ничего не можешь дать им: они сами преодолевают любые препятствия.
На стадии разработки самой идеи стартапа важно создать команду, способную реализовать продукт, подобрать подходящую технологию, сформировать бюджет и заложить предсказуемые и управляемые процессы. Все эти задачи взаимосвязаны и хорошо накладываются на каркас SCRUM.
- Что сейчас происходит в жизни твоего проекта?
У нас огромное количество идей, которые ждут своей реализации, но мы можем уже сейчас закончить проект и идти с продуктом на рынок. Все функции работают и могут приносить деньги. Постоянный контроль качества, который обеспечивают agile-процессы, позволяет вывести продукт на рынок на самых ранних стадиях. Для стартапа это имеет критически важное значение. Важна не сумма инвестиций, которую тебе удалось получить – а то, сработает ли твоя идея. И чем раньше ты сможешь это проверить, тем лучше.
Выпустите продукт с одной функцией, демонстрирующей ключевую идею, и получите быструю обратную связь. Обеспечьте выпуск потенциально применимого продукта в результате каждой итерации и наращивайте функциональность. Будьте гибкими по отношению к ситуации на рынке. Будьте готовы остановиться в любой момент. SCRUM – это подход к организации процессов, которые обеспечивают следование этим принципам.
- Что ты можешь сказать о технологических рисках?
- Agile-философия о гибкости и адаптивности. Мы склонны менять внутренние архитектурные решения. Но это не сказывается серьезным образом на качестве продукта. Примером тому может служить наша работа над алгоритмом поиска. Мы долго его совершенствовали. Он меняется, и будет продолжать меняться. Можно рассматривать как недостаток то, что его архитектура не была должным образом проработана вначале. Зато уже через два месяца после старта, мы могли продемонстрировать первую завершенную функциональность продукта. Мы можем себе позволить полностью изменить алгоритм в течение одного спринта. Использование таких инженерных практик как Test-Driven Development, позволяет нам покрыть тестами любую функциональность и обеспечить непрерывное тестирование при внесении изменений.
Серьезные технологические риски испытывают проекты, не использующие подобных практик. Тогда цена изменений может быть слишком велика.
- Что самого ценного ты для себя открыл во время работы над стартапом?
Самый большой и ценный опыт - это создание продуктивной команды. Способной «радостно наброситься» на любую задачу, какой бы сложной она не казалась.
В таком случае, помимо того что ты разрабатываешь продукт, выполняешь обязательства перед собой и другими - достигаешь намеченных целей, сам процесс приносит тебе удовольствие.
Мы пригласили Николая выступить с докладом 14 июля на нашей конференции SCRUM:open. Вместе с Александром Хистевым они постараются дать более подробную и разносторонюю оценку эффективности гибких подходов. В заключительной части мероприятия Вы можете использовать живое общение для ответов на возникающие вопросы.
Наталья Тренина,
Командный коуч, SCRUM тренер
Результат командной сессии поиска корневых причин.
Сессия коучинга организации процессов.
детализации требований по мере надобности;