Гибкие методологии управления ИТ-разработкой изначально несли в себе посыл становится клиентоориентированными, фокусироваться на бизнес-ценности, чтобы создавать результат, максимально удовлетворяющий заказчика. Двадцать лет назад мысль о том, что ответственность ИТ-разработчиков заключается не просто в создании новой функциональности, а в поставке ценности была действительно революционной. Фокусировка на ценности позволяет найти лучшее техническое решение из множества доступных разработчикам, когда они выбирают способ реализации требование бизнеса. В итоге результат соответствует ожиданиям заказчиков и созданную функциональность не приходится дорабатывать или переделывать. Что экономит время разработки и повышает качество продукта.
Однако, с течением времени стало понятно, что фокусировка разработчиков на бизнес-ценности задач штука совершенно необходимая, но недостаточная. Помимо этого нужно понимать цели развития продукта, которые ставит бизнес.
Научившись выстраивать коммуникации с заказчиками, определять и описывать бизнес-ценность каждой задачи, многие владельцы продуктов и разработчики угодили в ситуацию, когда, как говорится, за деревьями леса не видно. Там, где бизнесу очевидно, какие возможности должны быть созданы на этой неделе, в следующем месяце или в течение квартала, разработчики движутся от задачи к задаче по приоритизированной очереди без ясной цели.
Почему понимание цели развития продута важно в рабочем процессе?
Владелец продукта формирует очередь задач в продуктовом бэклоге исходя из приоритетов, которые он обсуждает с бизнес-заказчиками и заинтересованными лицами. Хорошо, если он делает это учитывая верхнеуровневую стратегию развития бизнес-функций, которые призван поддерживать ИТ-продукт. Отлично, если использует инструменты фиксации видения развития продукта в определённом периоде (например, дорожную карту). Тогда он сам чётче понимает те целевые состояния, которые последовательно будет проходить продукт в своём жизненном цикле и долгосрочные цели его существования. А значит лучше может планировать очередь задач.
Однако, помимо тактических целей в развитии продукта постоянно возникают оперативные задачи, как реакция со стороны бизнеса на уже реализованные решения. И поскольку гибкая ИТ-разработка является клиентоориентированной, владелец продукта не может их игнорировать. Это означает, что бэклог продукта постоянно пополняется новыми требованиями и происходит переприоритизация элементов работы в соответствии с новой картиной мира.
Беда в том, что оперативные задачи не всегда приближают продукт к заданным целевым состояниям его развития. Зачастую это необходимые улучшения качества текущей версии, но не создающие принципиально новых возможностей. В итоге оперативные ожидания бизнеса исполняются, а долгосрочные нарушаются, прогнозное состояние продукта не достигается. Квартал прошёл, а продукт все ещё не обрёл ожидаемых возможностей. И бизнес снова недоволен.
Балансировать оперативные задачи и задачи по достижению целевого состояния развития продукта важная ответственность владельца продукта при управлении бэклогом. Которую под давлением текущих запросов со стороны бизнеса он может реализовывать недостаточно хорошо.
С другой стороны, разработчики пользуются продуктовым бэклогом для формирования входа в рабочий процесс. Они берут задачи не слишком задумываясь о том, почему очередь приоритетов именно такая. Им не очевидно стоит ли за этим какая-то чёткая цель, или просто владелец продукта и заказчики так договорились на этой неделе. Разработчики не привыкли задавать вопросы о развитии продукта, им не понятно, каким образом это знание может помочь им в работе.
В итоге нарушается обратная связь. Владелец продукта забывает соотнести тактические и оперативные решения, а разработчики «пилят фичи» без понимания почему они делают то, что делают.
Работа делается, а меняется ли что-то в мире?
Отсутствие понимания, к чему в реальности приводит нематериальная деятельность разработчиков существенно подрывает мотивацию команды. Они честно работали три месяца, но бизнес недоволен, потому что не получил развития продукта. Заказчики выставляют дедлайны, что провоцирует на авральный режим работы. Происходит дисбаланс нагрузки на разработчиков.
Этого можно избежать чётче фокусируясь на целях развития продукта и задавая вопрос: те задачи, которые находятся в очереди с высоким приоритетом, приближают определённое целевое состояние? Команда делает действительно то, что нужно или отрабатывает сырые бизнес-идеи, которые не проверялись на целесообразность?
Разработчики склонны перекладывать это решение на плечи владельца продукта целиком. Но именно им потом приходится принимать на себя усиленную нагрузку, когда приходит время оценить прогресс продукта в определённом периоде. Поэтому им не мешало бы обезопасить себя от лишней работы, задавая больше вопросов.
Понимание цели как защита от ненужной работы
Знание целевых состояний, к которым должен прийти ИТ-продукт на следующем этапе развития, тех возможностей для пользователей, которые ожидает получить бизнес несколько релизов спустя, помогает чётче планировать оперативную деятельность команды разработки. Создавая конкретное техническое решение, они должны понимать, какова перспектива его дальнейшего развития. Иначе велика вероятность, что получившуюся функциональность придётся существенно дорабатывать или вовсе менять на другой вариант реализации, когда очередь задач доберётся до соответствующих ожиданий бизнеса.
Другая дисфункция – это выполнение работы впрок. Продумывая техническое решение, разработчики зачастую фантазируют о том, что в будущем им может пригодиться определённая функциональность. И проектируют архитектуру ИТ-продукта исходя из этих соображений. При этом они опираются на собственный опыт и здравый или не очень смысл.
Понимание цели развития продукта может подтвердить или опровергнуть необходимость таких решений. Если со стороны бизнеса не планируется расширять функциональность продукта в этом направлении, то она не несёт бизнес-ценности. Эта лишняя работа, которая никогда не будет востребована. Неоправданная трата интеллектуальных ресурсов и времени команды разработчиков.
Понимание цели как регулятор темпов работы
Ещё одна важная составляющая пользы от понимания цели существования и целевых состояний развития продукта – это определение нужного темпа работы команды. Не только понимание, в каком направлении должен развиваться продукт, но и в каком объёме должны происходить изменения в текущем периоде.
По определению команда – это группа людей, объединившихся вокруг достижения определённой цели. Умение людей работать совместно лежит в основе гибкого управления, о чем подробно писал мой коллега в этой статье. Насколько продуктивной будет деятельность команды во многом зависит от чёткости определения цели.
С каким темпом команда разработчиков будет осваивать собственный продуктовый бэклог определяется самими разработчиками. Всем известный закон Паркинсона гласит, что работа займёт всё отведённое на неё время. Но как понять в гибком развивающемся продукте сколько времени действительно есть у команды на реализацию требований заказчиков?
Из-за того, что планирование работы при гибком управлении опирается на прогнозы, а не на крайние сроки, команде сложно бывает понять сколько задач должно проходить по этапам разработки в краткосрочном периоде. Знание о целевых состояниях развития продукта и привязка их к прогнозным датам реализации помогает определить с какой нагрузкой должны трудится разработчики.
Понимание реальности достижения цели
При этом более явным становится соотнесение запросов бизнес-заказчиков и возможностей их реализации. Ожидания бизнеса могут быть сильно завышены и выставлены в очень оптимистичные цели. Приземление их на реальность находится в руках разработчиков.
Если диалог о том, какие возможности от продукта хочет получить заказчик через месяц или квартал не состоялся, а пополнение бэклога произошло, очень вероятна ситуация, что у команды просто не хватит реальных ресурсов для того, чтобы достичь поставленной цели в ожидаемый срок. И выяснится это только при оценке уже состоявшегося прогресса развития продукта, когда что-то менять будет поздно.
Поэтому чем раньше владелец продукта продемонстрирует команде планы относительно развития продукта и чем более конкретно будут сформулированы целевые состояния на этом пути, тем более адекватно будет сформировано понимание нагрузки на команду. Нужна совместная оценка разработчиками и владельцем продукта реальности поставленных целей.
Управление ожиданиями бизнес-заказчиков и заинтересованных лиц ещё одна важная функция владельца продукта, которая не может реализоваться без соучастия разработчиков.
Кто и когда должен начать говорить о целях?
Ответ на вопрос «кто?» очень простой: конечно же тот, кому есть от этого выгода. Кто непосредственно несёт ответственность за развитие продукта в нужном направлении и заданными темпами.
Владелец продукта обязан реализовать стратегическое видение бизнеса относительно того, какие новые возможности на каком этапе жизненного цикла продукта должны появляться. В его зоне ответственности фокусировка на целях развития продукта всех участников процесса создания ценности. Он должен балансировать ресурсы команды между решением оперативных задач от бизнеса и движения в направлении поставленных целей. Он формирует бэклог продукта на основе этого баланса и управляет ожиданиями заказчиков, не перекашивая рабочие процессы в ту или иную сторону.
Владелец продукта должен зафиксировать цели, чтобы вести планирование работы. Вот почему важно строить дорожную карту развития продукта от целевых состояний, а не от объёма задач. Просто последовательно выполняя запросы от бизнеса легко запутаться и подорвать прогресс возможностей продукта в долгосрочном периоде.
Команде разработки необходимо обезопасить себя от ненужной работы, авральной нагрузки и бесцельного создания невостребованной функциональности впрок. Разработчикам важно понимать объёмы поставленных задач и темпы взятия их в работу для равномерного и предсказуемого создания ценности.
Команде нужны чёткие ориентиры, которые не будут меняться слишком часто, приводя к переприоритизации задач в очереди на разработку и срыву запланированных сроков реализации. Процесс развития продукта должен быть прозрачен для команды, в чем так же помогает дорожная карта и непрерывный диалог о реальности поставленных целей.
Ответ на вопрос «когда?» тоже не сложен: как можно раньше и постоянно. Планирование целевых состояний определяет всю последующую деятельность по управлению продуктовым бэклогом и рабочими процессами. При этом конечно же реальный мир бизнеса сложен и изменчив, поэтому цели постоянно уточняются. Однако они не должны разрушаться и терять логичность.
Туманные неопределённые цели заведут развитие продукта в тупик, подорвут авторитет владельца продукта и лишат мотивации команду разработки. Не имея представления о том, зачем перед командой стоят именно эти задачи, почему они важны и необходимы бизнес-заказчикам, как их реализация повлияет на последующие запросы невозможно добиться стабильной и сбалансированной работы.
Интересно будет узнать у наших читателей, возникают ли у вас проблемы с пониманием цели своей деятельности и как вы их решаете?
