4 сентября 2015 г.

Пять самых важных составляющих процесса выпуска успешных проектов

Оригинал статьи на сайте Цукерберг Позвонит https://vc.ru/p/byndyu

Видео с конференции и слайды по это теме http://blog.byndyu.ru/2015/12/blog-post.html

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

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

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

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

Уверен, что процесс, описанный ниже, подойдет для разных проектов, разного размера, разных предметных областей и т.д. На всякий случай скажу, что наш типовой проект обычно объемом работы от 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#:

[Test]
public void IgnoreAdsIfStartDateIsNotReached()
{
 var entertainmentVideo1 = new Video(VideoType.Noncommercial, 30) {Id = 1};

 var adsVideo1 = new Video(VideoType.Ads, 10) {Id = 2};
 var adsCampaign = new AdsCampaign(adsVideo1, 120, new DateTime(2014, 09, 10), new DateTime(2014, 10, 25));

 var videoTimeline = new VideoTimeline(new List<AdsCampaign> {adsCampaign},
  new List<NoncommercialContent> {new NoncommercialContent(entertainmentVideo1)}, new DateTime(2014, 09, 09), 30);

 IEnumerable<TimelineItem> playlist = videoTimeline.CreatedPlaylist;

Разработчики пишут тесты, чтобы понять, как объекты будут влиять друг на друга, откуда будет получаться результат и т.п. Другими словами, разработчики моделируют предметную область через тесты. Из этих экспериментов, как и из UI-прототипов, тоже рождается много более конкретных вопросов к владельцам продукта.

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

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

Работа над релизом

В этой фазе идет активное печатание кода, настройка Continuous Deployment, тестирование и т.п. обычная такая разработка. Мы часто используем TDD, CQRS, различные СУБД, чтобы точнее попасть в требования к системе в рамках стоимости инфраструктуры и гибкости. Большое внимание уделяем DDD.

Практически никогда не создается Big Design Up Front. Работа над программной архитектурой происходит инкрементально. Мы рисуем архитектуру, выбираем точки расширения и масштабирования, которые согласуются с целями системы. Как мы уже говорили, цели системы периодически меняются, поэтому архитектура должна быть гибкой, чтобы успевать меняться за видением проекта. В архитектуре важно с одной стороны не быть архитектурным астронавтом, а с другой — иметь опыт проектирования сложных систем.

UI/UX, разработчики и QA-инженеры постоянно взаимодействуют друг с другом. Промежутки от планирования до демо небольшие — всего одна неделя, поэтому работа получается довольно плотная. Результатом каждой итерации является инкремент к релизу, который двигает нас в сторону достижения целей.

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

К чему готовить заказчика?

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

Нам такой вариант не подходит. Рекомендуем ещё на старте проекта обратить внимание заказчика на следующее:

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

Практика включения заказчика в команду известна под названием Onsite Customer и является, например, частью Extreme Programming. Обсудите в самом начале, как вы будете общаться, как часто это будет происходить, через какие каналы связи, что значит принять участие в демо и т.п. Всё это важно, т.к. может изменить привычный ритм жизни заказчика.

Бизнес-кейс

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

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

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

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

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

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

Из описания причин провала мы выделили:

  • Главная проблема — сложная предметная область. На данный момент мы можем сказать, что предметная область действительно сложная и довольно запутанная, но разве с налогами бывает как-то иначе?
  • В ТЗ написано одно, а по факту надо было другое. Например, количество Приложений, относящихся к одному акту, может быть неограниченным, может перечисляться через запятую, а может и через интервал посредством дефиса.
  • В ТЗ многие детали были пропущены. Например, не было сказано, что номер Акта является уникальным в рамках Договора и года. На первый взгляд небольшая деталь, но она может значительно повлиять на реализацию.

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

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

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

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

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

Конкретно в этом проекте на Impact Mapping ушло около трех часов, вот одна из частей:

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

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

Работаем с историями пользователей

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

Первую версию User Story Map сделали примерно за два-три часа:

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

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

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

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

В этой анимации показано полгода работы.

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

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

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

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

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

Разработка и релиз

Разработка шла по Scrum с итерацией в одну неделю. Интересно, что глобально проект разрабатывался по схеме Fixed price, т.к. этого требовали бизнес-процессы внутри компании заказчика, но внути разработка строилась, исходя из гибких границ проекта.

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

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

Почему это работает?

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

  1. В самом начале мы понимаем, что на самом деле надо продукту для успеха
  2. Постоянная обратная связь и полная прозрачность процесса. Подробней про это в статье Customer satisfaction для программистов: Доверие и прозрачность
  3. Качественный код, но это же по-умолчанию должно быть :)

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

Комментариев нет:

Отправить комментарий