Антихрупкость в IT - Александр Васильевич Бындю

1. Ему придётся активно участвовать в жизни проекта и работать наравне с командой.

2. Заказчику придётся принимать довольно много решений под свою ответственность на основе своего опыта/целей/знаний или чего-то ещё – отсидеться в стороне не получится.

Практика включения заказчика в команду известна под названием Onsite Customer[28] и является, например, частью Extreme Programming[29]. Обсудите в самом начале, как вы будете общаться, как часто это будет происходить, через какие каналы связи. Это чрезвычайно важно, потому что такой подход к созданию IT-продуктов может нарушить привычный ритм жизни заказчика.

Бизнес-кейс

Давайте я расскажу об одном проекте, который прошёл по такому пути. Предметная область проекта: транспортная компания и работа с налогами на экспортные перевозки.

Первая попытка создания продукта

Заказчик пришёл к нам с негативным опытом от первой попытки создания системы. К сожалению, время и деньги были потрачены впустую, проект запустить не удалось. Нам повезло: перед началом работы у нас оказался документ, где анализировались неудачи предыдущей разработки.

Предыдущая компания придерживалась каскадного процесса[30]. Им написали ТЗ, они ушли в работу. Вернулись через сколько-то месяцев и показали то, что сделали. Как оказалось… сделали совсем не то, что нужно, но ровно то, что написано в ТЗ. Созданной системой невозможно было пользоваться в реальных условиях бизнеса.

Из описания причин провала мы выделили следующие факторы.

Сложная предметная область. Действительно сложная и очень запутанная. Но разве с налогами бывает как-то иначе? Хорошо, что наш процесс, как раз и стоит применять именно для сложных проектов.

В ТЗ написано одно, а по факту надо было другое. Например, количество приложений, относящихся к одному акту, может быть неограниченным, может перечисляться через запятую, а может и через интервал посредством дефиса. Как это обычно бывает, бизнес может зависеть от 3–4 микронюансов, которые все знают, но забывают о них сказать, ведь они всем кажутся очевидными.

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

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

Начинаем с целей

Мы подготовили всех стейкхолдеров к Impact Mapping. Разослали материалы с описанием этого инструмента, попросили выделить пару часов времени для созвона.

На Impact Mapping со стороны заказчика пришли: технический директор с заместителем, главный бухгалтер с помощниками и коммерческий директор. Это была большая удача – удалось с первого раза собрать всех нужных людей. С нашей стороны была вся команда.

Обычно я начинаю с провокационной фразы, звучит она примерно так: «Давайте по-быстрому запишем цели и пойдём дальше рассматривать роли». Каждый участник уверен, что цели все знают, поэтому кто-то просто озвучивает то, что считает целями проекта. Вся соль в том, что этого человека сразу поправляет другой, так как цели в его голове были другие, его тоже поправляют и так далее. Возникает оживлённая дискуссия на тему: что же мы собрались сделать? Команде разработчиков на этой стадии важно замолчать. Не надо мешать всем заинтересованным лицам высказаться. Во время обсуждения происходит кристаллизация целей в голове заказчика (всех стейкхолдеров), от команды требуется эти цели просто записать.

Конкретно в этом проекте на Impact Mapping ушло около трёх часов. После этого в течение нескольких недель заказчики сами возвращались к IM и вносили туда изменения.

Важно правильно настроиться на Impact Mapping. Надо понимать, что стейкхолдеры – это люди с высокой квалификацией в своей предметной области. Они очень глубоко знают предмет, но не имеют большого опыта в создании ПО. Поэтому мы им помогаем активным слушанием и задаём много «глупых» вопросов, чтобы как можно сильнее раскрыть их знания.

Работаем с CJM и USM

Когда цели и путь до них были определены, мы запустили CJM и USM. Со стороны заказчика участвовали технический директор с заместителем, а с нашей стороны, как обычно, вся команда. Обратите внимание, что «нетехнические» стейкхолдеры в этот момент уже не принимали участие, хотя мы всячески пытались их привлечь. Не всегда всё идёт по плану.

Пример финального CJM приведён на рис. 17. Мы описали все роли и их взаимодействия.

Рис. 17. Оформленный CJM

Первую версию User Story Map сделали примерно за два-три часа, результат показан на рис. 18.

Рис. 18. Оформленный USM

В отличие от Impact Map, который часто меняется только в начале проекта, CJM и USM меняются и пересобираются на протяжении всего проекта. Чем сложнее предметная область, тем чаще нас и заказчика посещают озарения, тем чаще мы возвращаемся к пользовательским историям.

User Story Map даёт заметное преимущество – у вас появляется шанс до старта разработки углубиться в предмет. Для нас этот инструмент относится к артефактам, без которых практически невозможно делать полезные проекты.

Модель предметной области

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

Разработка интерфейса

Итерация дизайна включала в себя несколько циклических витков с разными специалистами:

1. Когда дизайнеры в рамках своей группы считают, что ценный инкремент достигнут, они показывают его внутри команды.

2. Разработчики дают обратную связь о реализуемости, все вместе проверяют на работоспособность и непротиворечивость, макеты дорабатываются.

3. Исправленные макеты дизайнеры демонстрируют заказчику, получают новую порцию замечаний уже по бизнесу.

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

Для примера приведём наброски интерфейса из середины проекта. На картинке есть уже устоявшийся интерфейс, а идею нового компонента пробуем маркером поверх распечатки (рис. 19).

Рис. 19. Макет интерфейса на бумаге

Нет смысла детально прорисовывать дизайны, которые