Александр Бындю, ByndyuSoft: Пять самых важных составляющих процесса выпуска проектов Статьи редакции

Александр Бындю, руководитель компании ByndyuSoft, написал для VC колонку, посвящённую процессу разработки ИТ-продуктов, принятому в студии и найденному после долгих проб и ошибок, и привёл пример проекта, создаваемого таким путём.

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

Нам посчастливилось создать успешные продукты, которые приносят прибыль заказчикам. Продукты мы создаем на заказ в качестве аутстаф-команды. Предметные области самые разные: медицина, наружная реклама, госзакупки, налоги, логистика.

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

Иногда я буду писать «проект», а иногда «продукт». Для себя мы не разделяем два этих понятия. В книге «Бережливое производство программного обеспечения. От идеи до прибыли» есть интересная мысль, что любой проект можно рассматривать, как продукт, поэтому при разработке ПО мы используем подходы по созданию продуктов.

Уверен, что процесс, описанный ниже, подойдет для разных проектов, разного размера, разных предметных областей и так далее. На всякий случай скажу, что наш типовой проект обычно объемом работы от 500 человеко-дней, то есть начиная с загрузки для четырех человек на 4-5 месяцев. Вот на таких проектах мы и обкатывали предложенные подходы.

Общий взгляд на процесс

Разработка ПО — это процесс создания знания. В начале работы неопределенность очень высокая. Заказчик витает в облаках со своей идеей, разработчики неглубоко знают предметную область.

Мы много экспериментировали с разными методологиями от жёстких до гибких, от Agile до Lean, и пришли вот к такому процессу:

1. Вся работа должна быть визуализирована: от процесса и целей до мелких пожеланий и требований. Мы исходим из простого принципа: «You cannot improve what you cannot see»
2. Первое знакомство с проектом всегда начинаем с целей. Спрашиваем: «Как вы поймёте что достигли успеха?», «Что для вас является успешным продуктом?», «Представим, что продукт создан, по каким критериям вы его оцените?» и так до тех пор, пока цели не материализуются. Приоритизируем цели и путь до их достижения. Подробнее об этом написано в статье «Impact Mapping на практике».
3. Следующий шаг понимания будущей системы — User Story Mapping. После описания сценариев, приоритизируем их и выбираем самые важные для ближайшего релиза, не надо пытаться охватить все разом.
4. Выбираем список User Story для ближайшего релиза, делим истории на итерации и стартуем разработку. В каждую итерацию (у нас она равна неделе) обязательно входят: планирование на неделю, ежедневные стендапы, демо результатов работы в конце недели. Другие практики используются или нет в зависимости от потребностей проекта. Например, ретроспектива может быть раз в месяц или каждую итерацию.
5. В любой момент заказчик и/или команда могут остановиться и вернуться к пересмотру Impact Map, или обновлению User Story Map или вообще сделать Pivot, так как текущая гипотеза оказалась ошибочной. В общем, всё является гибким, обсуждаемым и изменяемым.
6. После реализации задуманных сценариев компануем релиз, делаем приемочное тестирование всех сценариев и другие виды тестирования, проводим демо по релизу, получаем одобрение всех стейкхолдеров и продукт выходит в свет.
7. После релиза крайне важно вернуться к Impact Map и понять достигли мы целей или нет.
8. Дальше весь цикл повторяется заново.

Релиз это обычно радость. Усилия наконец дают результат, все рады и довольны. Тем не менее мы считаем, что релиз прошел успешно только тогда, когда цели достигнуты. Если мы сделали все фичи, всё прекрасно работает, код отлично написан, всем, включая заказчиков, этот релиз нравится, но цели не достигнуты — значит релиз прошел неуспешно, надо сделать ретроспективу и понять в чем проблема.

Более детальный взгляд

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

Как уже было написано, для начала нам надо понять цели проекта. Для этого мы используем Impact Mapping. Обычно работа по созданию Impact Map занимает от дня до недели, зависит от размера проекта и свободного времени у всех заинтересованных лиц.

Каждый раз стартуя продукт, заказчик уверяет нас, что цели и так все понятны, что не стоит тратить время на их обсуждение. Иногда цели описаны в каком-то документе, иногда даже этого нет. Мы всё это уже проходили, мы не верим таким документам. И не верим, что все одинаково понимают и принимают цели проекта.

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

Примерно к финалу формирования Impact Map становится возможно стартовать работу по созданию User Story Mapping. Карта сценариев состоит из:

• ролей (бухгалтер, отдел маркетинга и так далее);
• активностей этих ролей (формирование отчета, создание рекламной кампании);
• и задач, которые детализируют активности (задает временной период, активизируем подписку с помощью почты);
• все сценарии приоритизированы по двум направлениям: время и важность.

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

Создание User Story Map обычно не происходит с первого раза. Часто этот процесс занимает несколько итераций с постоянным уточнением ролей, активностей и приоритетов.

Когда User Story Map близок к полноте, UI/UX-специалисты приступают к первым UI-прототипам. Важно быстрее проверить основные концепции, которые есть в нашем User Story Map. Бывает, что эти прототипы рисуют просто на бумаге, сканируют и рассылают. Но даже от таких простых прототипов возникают более конкретные вопросы и возвраты на переформатирование User Story Map. Пример прототипа на бумаге из нашего проекта:

В это же время разработчики пишут код через TDD, чтобы лучше понять предметную область. Вот один из примеров такого кода на C#:

public void IgnoreAdsIfStartDateIsNotReached()