Рис. 28. Метафора для инструмента планирования
На мой взгляд, хорошо подходит метафора навигатора (рис. 28) в автомобиле:
1. Навигатор знает, где мы сейчас и куда хотим приехать.
2. Если по дороге домой мы решили свернуть в магазин, то он перестроит первоначальный путь с учётом изменений.
3. Если мы передумали ехать домой, то ставим новую точку, и нам сразу показывается новый оптимальный путь до новой цели.
4. Если на дороге случилось ДТП и путь закрыт, то навигатор перестраивает маршрут.
Хорошо было бы иметь такие навигаторы при работе над IT-продуктами. Наше планирование превратилось бы в постоянное прокладывание оптимальных маршрутов до бизнес-ценности с быстрой реакцией на изменение внешних факторов, таких как отзывы пользователей, действия конкурентов, желания инвесторов и других. «Чёрные лебеди» (неожиданные события, которые очень сильно влияют на ситуацию) не предупреждают о своём появлении, поэтому я за такой инструмент, который готов выдержать любые неожиданности.
Реализация адаптивного плана работ
Чтобы создать навигатор для IT-продукта, я рекомендую использовать подходящие инструменты планирования, периодически возвращаться к началу планирования и пересматривать планы, прекратить фиксировать объём работ на отдалённое будущее и строить коммуникацию вокруг бизнес-целей.
Визуальное и «многомерное» техническое задание
Люди хорошо работают с визуальными образами, mind map'ами и схемами. Поэтому в своей практике мы мало пишем «плоского» текста, зато активно используем карты и образы. Рисунки и карты легко перестроить в отличие от 300-страничного документа. К тому же эти карты быстро считываются и помогают эффективно коммуницировать.
Для построения карты целей и нахождения кратчайшего пути до цели мы рисуем Impact Map (раздел l, глава 2).
Взаимодействие всех частей IT-продукта, пользовательский опыт и сценарии работы пользователя описываются в Customer Journey Map и User Story Map.
После создания этих трёх карт нужно выбрать самые важные для бизнеса задачи на ближайший релиз и проложить самые короткий путь до цели. Здесь опять помогает то, что все карты визуальные: можно отрезать неважные части и проложить путь к цели.
Циклы и пересмотры
Гибкость создаётся за счёт цикличности процесса разработки IT-продукта и лёгкости внесения изменений в планы. Так как все планы описаны в схемах и стикерах, внесение в них изменений не составляет труда.
После каждого релиза надо обязательно вернуться в начало и посмотреть, в верном ли направлении был сделан шаг (рис. 12). Каждый цикл учит нас чему-то новому о рынке и о своих возможностях; мы делаем выводы и идём на новый круг (раздел l, глава 4).
Объём работ – не фиксированная величина
Для обеспечения гибкости в классическом проектном треугольнике нужно поменять две вещи: перестать фиксировать объём работ и начать фиксировать качество (рис. 29).
Рис. 29. Фиксируем качество и не фиксируем объём работ
Фиксация качества. Направление разработки ПО всё время меняется, но архитектура и код не должны ломаться при внесении изменений. Код не должен быть хрупким. Для повышения качества кода используют практики Экстремального программирования[42] и следят за уровнем технического долга (раздел II, глава 6).
Плавающий объём работ. Обычно для заказчика важны срок и цена, эти величины остаются зафиксированными. Но что конкретно мы сделаем в указанный срок? Сделаем то, что максимально приблизит заказчика к бизнес-цели, а это будет видно по картам и схемам, которые используются при планировании.
Разработчикам хорошо известно, что одну и ту же задачу можно сделать бесконечным количеством способов. Например, если выводить красивый индикатор, то это займёт два дня работы дизайнера, верстальщика и программиста, а если вместо него показать цифру, то в пять раз быстрее. Поэтому мы часто «флексим», то есть делаем меньше, но не ухудшаем достижимость бизнес-цели (подробнее в разделе I, главе 10).
Чтобы сделать объём работ плавающим, между исполнителем и заказчиком надо выстроить высокий уровень доверия. Как этого добиться – в статье «Customer satisfaction для программистов: Доверие и прозрачность» [43].
Ориентация на бизнес-цель
Заказчик и исполнитель вместе ориентируются на бизнес-цель при прокладывании пути без формального технического задания (рис. 30).
Рис. 30. Заказчик и исполнитель фокусируются на бизнес-цели
При таком подходе нет формального списка работ, который надо выполнить вопреки здравому смыслу и потере эффективности.
Я бухгалтер, я так вижу
Наши схемы и стикеры на стене, к сожалению, не подходят для формальной документации и юридического оформления работ. Бухгалтеры и юристы требуют сроки и описание объёма работ. Они не противодействуют гибкому подходу, они лишь пытаются соблюдать законы и правила отчётности, принятые в стране. Поэтому обычно в жизни схема работы выглядит как на рис. 31.
Рис. 31. ТЗ может быть в схеме в качестве вспомогательного элемента
В этом случае ТЗ остаётся, но является не более чем юридическим сопровождением проекта. Часто оно пишется относительно абстрактно, чтобы оставить достаточно пространства для творчества и реакции на возникающие риски. Ещё чаще список работ заполняется уже после реализации IT-продукта и подписывается датой начала проекта. При этом все нормы закона соблюдены и ТЗ не портит ход работ своей негибкостью.
Повышаем качество работы
Основные идеи, которые помогут повысить качество работы:
1. Планирование работ – цикличный и постоянный процесс, мы занимаемся непрерывным прилаживанием новых вводных, поэтому нужно использовать гибкие инструменты.
2. Не заменяйте живую коммуникацию на ТЗ. Если ТЗ начинает занимать ведущую роль, то стоит насторожиться и проверить, как устроена коммуникация в проекте между всеми участниками.
3. Пишите ТЗ, когда это необходимо. Делайте его как можно более полезным.
4. Контроль процесса разработки достигается за счёт визуализации текущего состояния проекта и понимания дальнейших шагов.
Глава 9. Определение провала IT-проекта
Из всех монстров, которыми наполнены кошмары нашего фольклора, самыми страшными являются оборотни, поскольку нас пугает неожиданное превращение того, что нам хорошо знакомо, в нечто ужасное. Мы ищем серебряные пули, которые могли бы