Customer satisfaction для программистов: Визуализация

22 февраля 2015 г.

Одна из ключевых практик в Kanban — это визуализация работы: «You cannot improve what you cannot see». Следующие три подхода нацелены на визуализацию целей проекта, задач и текущего процесса.

Понимаем цели через Impact Mapping

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

Impact Mapping простая и эффективная техника для определения целей заказчика и передача этих целей разработчикам. Для средних размеров проекта (полгода работы) составление карты занимает от 2 до 6 часов.

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

  • Q: Как уговорить заказчика заниматься Impact Mapping'ом? Особенно интересно работает ли это для государственных заказчиков?
    A: Как всегда начните с проблемы. Был ли у заказчика неудачный опыт, когда он написал детальное ТЗ, а в результате получил не то, что хотел? Нужно показать, что есть такая проблема и предложить Impact Mapping в качестве решения. С гос. заказчиками это работает точно также. Среди гос. заказов бывают разные, там главное найти человека, которому действительно нужен этот проект и сделать с ним Impact Mapping. Если проект (коммерческий или гос.) делается для галочки, то маппинг лучше не делать, ни к чему время тратить.
  • Q: Мы хотим узнать проблему, настроиться на волну заказчика и постоянно спрашиваем Почему, Почему и т.п.? А конкуренты не спрашивают, они берут ТЗ и делают, что им сказали или пытаются угадать. Как не спугнуть заказчика своими постоянными распросами и новыми техниками?
    A: Ответ аналогичный прошлому. Начните с объяснения проблемы. Если заказчик отказывается и не понимает зачем делать Impact Mapping, то может и не стоит его делать. По опыту могу сказать, что зрелые заказчики никогда не отказываются от этой практики, т.к. его польза для проекта очевидна.
  • Q: Пришёл заказчик, который хочет заказать веб-проект. Разобрали цели и вместе поняли, что для достижения целей веб-проект не нужен. Обидно терять заказчика. Как быть?
    A: Это моральный выбор каждого. Можно показать заказчику другие пути развития его бизнеса, в которых вы не участвуете. Он будет вам благодарен и возможно вернется снова. Если боятся того, что после Impact Mapping вы окажетесь не нужны, то лучше его не делать, но и на хороший результат расчитывать не стоит.
  • Q: Что если в начале проекта сделали Impact Mapping, определили цели проекта, а в конце проекта поняли, что цели не достигнуты?
    A: Постановка целей — это эксперемент, все могут ошибаться. Важно как можно быстрее понять, что целей мы не достигаем и изменить маршрут. Для этого необходимы частые релизы и сбор обратной связи.

Story Mapping

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

В ТЗ нет объема и динамики, нет приоритетов, его не достаточно, чтобы понять масштабы проекта. Суть Story Map в том, чтобы разложить все User Story по осям времени и важности:

Здесь я не буду подробно расписывать нюансы этой техники, могу только порекомендовать статью The new user story backlog is a map и книжку User Story Mapping: Discover the Whole Story, Build the Right Product. Кроме того, Story Mapping рассматривается почти в каждой книге про гибкое управление проектами.

Важная рекомендация: На Story Mapping обязательно берите с собой UI/UX специалиста, который будет заниматься проектом. Он должен критически смотреть на все User Story и фильтровать поток мыслей от заказчика.

В качестве реального примера фотография из нашего офиса, на ней Story Map для первой версии продукта. Объём работы примерно на 4 месяца для команды из 5 человек. Составление карты заняло 5 часов. Участвовали 3 представителя заказчика, 3 разработчика. Вёл эту сессию я вместе с UI/UX специалистом:

Kanban-доска

После того, как мы спланировали работу, начинаем визуализировать процесс разработки на доске. На данный момент Kanban-доска, пожалуй, один из самых популярных инструментов. Про доску написано много и в книгах про Scrum, и в книгах про Kanban, и в других источниках про Agile и Lean.

Здесь я хочу отметить только одну важную деталь, на которую не многие обращают внимание. Скажите, как называется ваш последний столбец на доске? Могу предположить, что он называется Closed, Release, Production или что-то в этом духе. На самом деле Impact Mapping подсказывает нам, что последний столбец это не выкладка фичи в релиз, это проверка достижения цели. Мы брали фичу в работу, исходя из того, что она повлияет на достижение цели, так почему бы в конце это не проверить?

Визуализации много не бывает

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

Для начала хочу отметить, что разработка ПО сложная штука и является прежде всего «knowledge work». Если мы правильно поняли цели проекта, правильно определили приоритеты и можем постоянно оптимизировать процесс разработки, то у нас появляется 8 шансов из 10 сделать нужный продукт/проект. Попытка делать эти маппинги и визуализация работы на доске — это способ разъяснять самим себе и заказчику суть решаемых задач.

Надеюсь, вы согласитесь с моим предыдущим тезисом. Если да, то надо понимать, что маппингов много не бывает. Их значимость для проекта трудно переоценить.

На сколько затратно поддерживать это всё в актуальном состоянии? Как работать с изменениями, которые в любом случае будут происходить? Исходя из практики, могу сказать, что Impact Mapping довольно редко меняется и пересматривается. Обычно не чаще, чем выходят мажорные релизы, а то и реже. Чуть чаще обновляется Story Mapping. Ежедневно нам надо обновлять только доску, а это не занимает много сил и времени. Обновление статуса задач на стендапе довольно веселая и простая практика. В любом случае польза от визуализации нашей работы перевешивает затраты на их создание и поддержание.


Серия статей «Customer satisfaction для программистов»:

4 комментария:

  1. Спасибо Александр. Было интересно.
    Impact mapping - напомнил чем то "Тестирование по спецификации", где каждая "фича" разбивается на пункты и помогает осмыслить заказчику требование.

    ОтветитьУдалить
  2. У Specification by Example тот же автор, можно сказать, что Impact Mapping это дальнейшее развитией его идей. В статьях и книге он периодически делает отсылки к Spec by Example

    ОтветитьУдалить
  3. Значит не зря напомнило). Эххх сколько бы я дней сэкономил если бы с одним из заказчиков провел несколько часов за Impact Mapping'ом. Сколько нехороших мыслей было о нем (за его требования) и о себе (за то что не добился от него нужных задач). Хоть и было понимание что что то делаю не так, а что именно догнать не мог. Еще раз спасибо.

    ОтветитьУдалить
  4. У Specification by Example тот же автор, можно сказать, что Impact Mapping это дальнейшее развитией его идей. В статьях и книге он периодически делает отсылки к Spec by Example красивые вечерние платья

    ОтветитьУдалить

Моя книга «Антихрупкость в IT»

Как достигать результатов в IT-проектах в условиях неопределённости. Подробнее...