Одна из ключевых практик в 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 для программистов»:
Спасибо Александр. Было интересно.
ОтветитьУдалитьImpact mapping - напомнил чем то "Тестирование по спецификации", где каждая "фича" разбивается на пункты и помогает осмыслить заказчику требование.
У Specification by Example тот же автор, можно сказать, что Impact Mapping это дальнейшее развитией его идей. В статьях и книге он периодически делает отсылки к Spec by Example
ОтветитьУдалитьЗначит не зря напомнило). Эххх сколько бы я дней сэкономил если бы с одним из заказчиков провел несколько часов за Impact Mapping'ом. Сколько нехороших мыслей было о нем (за его требования) и о себе (за то что не добился от него нужных задач). Хоть и было понимание что что то делаю не так, а что именно догнать не мог. Еще раз спасибо.
ОтветитьУдалитьУ Specification by Example тот же автор, можно сказать, что Impact Mapping это дальнейшее развитией его идей. В статьях и книге он периодически делает отсылки к Spec by Example красивые вечерние платья
ОтветитьУдалить