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

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

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

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

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

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

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

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

      Рис. 12. Схема работы со всеми инструментами и обратной связью

      Вся работа должна быть визуализирована: от процесса и целей до мелких пожеланий и требований. Мы исходим из простого принципа: «You cannot improve what you cannot see».

      Первое знакомство с проектом всегда начинаем с целей. Спрашиваем: «Как вы поймёте, что достигли успеха?», «Что для вас является успешным продуктом?», «По каким критериям вы оцените его успешность?» и так далее, пока цели не материализуются. Приоритезируем цели и строим пути их достижения.

      Следующий шаг понимания будущей системы – Customer Journey Mapping (CJM), но не в классическом варианте, а в том, как его описал мой коллега Андрей Шапиро в статье «Схематизация опыта с CJM и Service Blueprint. Практика гибридной нотации»[21]