Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
В своей прошлой статье я обозначил «погоню за лидерами рынка взамен выверенного расписания» - типичной ошибкой проектного менеджера в реализации продуктового подхода. Здесь разбираемся совместно: что такое и зачем нужен roadmap, без чего он бесполезен, как может выглядеть и способен ли он эволюционировать в график календарно-сетевого планирования.
Для примера применяется разбор приключений Красной шапочки по версии жизненных уроков от Братьев Гримм.
Помощь от сказочных персонажей
Красная шапочка в нашем иносказании – это нанятый доставщик ценностей, он же в какой-то компании может быть назван как проектный, где-то - продуктовый менеджер. По задумке авторов сказки, персонаж должен вызвать у читателя симпатию и сопереживание: этот доставщик мил, молод и неуклюж. Возможно, он не так-то прост: Волк-то оказался в итоге зарезанным.
Мать Красной шапочки – пусть будет её начальство, фрактальное порождение владельцев бизнеса. Братья Гримм уделили ей скудное место в истории. Не вникая глубоко в диспозицию отношений отмечу, что именно Мать отправляет малолетнюю посыльную в лес, кишащий опасностями. И вроде как подталкивание в зону дискомфорта для доставки ценностей - это естественно.
Бабушка – обездвиженная болезнью лесная отшельница, единственный по праву сказки потребитель ценностей от Красной шапочки. В нашем иносказании будет олицетворять владельцев бизнеса, на пользу которых трудится героиня: они обладают почтенным опытом, «больны» любовью к своему детищу и пытаются отойти от дел, лишь своим незримым присутствием способны привести всё в движение.
Волк – искушения и стимул роста персонажей. Братья Гримм оживили страшного зверя речами, искушающими Красную шапочку отвлекаться, дезинформирующими Бабушку о реальных намерениях животного, украсили бездонным всехпоглощающим брюхом, адаптивной под запрос внешностью и приправили настолько неожиданным возникновением в истории, что даже Мать не смогла (или не захотела?) заранее предостеречь своё дитя об опасности.
Охотник – пусть в этой интерпретации будет набором знаний, основанных на опыте. При том опыта пока не хватает до мудрости: он по юношески стремится всюду себя реализовать, видимо от того “оказался неподалеку”. В изначальной версии Красной шапочки Дровосек с намозоленными руками приходит на помощь вместо мастера ружья. Именно личный опыт разрушения тумана искушений и заблуждений порождает эффективное оружие, а страсть к оттачиванию мастерства на практике становится движущей силой охотника.
Диспозиция требований к дорожной карте
Roadmap – это стратегическая карта намерений, текущих и ближайших действий по развитию продукта, соотнесенная с клиентскими потребностями и измеряемым эффектом их удовлетворения. Контекст, определяющий среду возникновения запроса на дорожную карту, цель её применения, задают содержимое документа, а значит и его судьбу. Именно поэтому важен разбор контекста.
Никакой бизнес не вечен: клиент неминуемо эволюционирует в своей потребности, процессы нуждаются в калибровке. Рано или поздно у владельцев живого бизнеса (Бабушка) возникает запрос на обновление и реализовывать его в крупной организации нанятому высшему менеджменту (Мать) руками рядового доставщика ценностей (Красная шапочка).
Степень профессиональной и личной зрелости инициатора поиска доставщиков ценностей (это далеко не тоже самое, что уровень развитости организации в целом) определяет побочные эффекты ввязывания в игры по улучшениям:
вначале юношеской влюбленности в объект своего труда, когда реформатору требуется надежная личная поддержка, подсознательно нанимаются ментально наиболее предсказуемые (понятные), “свои люди”. На этой стадии как нигде велик риск попасть на продукт-игрушку, которая будет лишь взращивать самоуверенность и отображать любовь реформатора к самому себе
по мере мере осознания рисков краха реформ или статуса нанимателя возрастает желание перестраховаться. И страховка “на все случаи” возможна, ведь зачастую этот банкет происходит за счет чужого кармана - кармана владельца. Так возникает запрос на хайповые управленческие инструменты, людей “с медальками” и быстрые победы во имя личной политической прочности
восприняв страхи в лицо, возникает запрос на эффективные действия. У бизнеса появляется желание сытой тихой старости: только деньги как мерило - ничего личного. Схоже с задумкой нашей сказки: Бабушка в уютной постели и с крышей над головой - отдельно, дочка с провиантом и увлекающейся внучкой для доставки провианта - отдельно. Тут как бы не про людей - тут только про возврат вложений: цинично, но зато честно. Но не всем такая циничность по природе: отсутствие примененных "намозоленных трудом рук" в такой среде приносит неотвратимые приключения - излишний релевантный опыт должен быть как у заказчика обновлений, так и у исполнителей
осознание временной природы сытости стимулирует потребность к постоянному “переизобретению бизнеса”, декларируется запрос: породить что-то кардинально «другое» для будущей сытости, готовность сеять ресурсы «почти безвозмездно». Розовые единороги - это скорее удачная покупка корпоративных структур, но их зачатие находится за пределами их естественных забюрократизированных возможностей. Ведь чтобы получить что-то новое, необходимо выйти из зоны комфорта, а этому будет препятствовать вся структура, нацеленная на сохранение неизменности прошлого успеха. Спасение есть в особых песочницах неокрепших идей (термин раскрыт в Lean startup Эрика Риса), но не у всех хватает смелости на них, свободных ресурсов и мудрой требовательности.
Для каждого из обозначенных пунктов выше свой залог выживания Дорожной карты:
для «продукта-игрушки»: угадать ожидания увлекшегося заказчика
для «продукта-перестраховки»: не принести проблемы или привнести защиту
для «сытой старости»: обеспечить увеличение отдачи понятного продукта
для «будущей сытости»: породить иной ценностный поток
Возможно сочетание требований «под настроение» основного заказчика документа, но тем тяжелее для Красной шапочки нащупать всё-таки основной, судьбоносный мотив и для документа и для себя.
В нашем примере Бабушкины предпочтения проявлены указанием Матери: «Вот кусок пирога и бутылка вина, снеси бабушке гостинец! Бабушка больная и слабая, пусть подкрепится. Только выходи пораньше, пока ещё не жарко, и иди прямо, никуда с дороги не сворачивай, а то ещё упадёшь и бутылку разобьёшь, тогда бабушке ничего не достанется. А когда ты к ней в избушку войдёшь, не забудь с ней поздороваться, и не заглядывай сперва во все углы!».
Такие вводные скорее подходят для зачатка Устава проекта, который определяет:
ключевое заинтересованное лицо – Бабушка
цель мероприятия – Обеспечение сытости для Бабушки (Подкрепиться)
вводные для планирования её достижения - Выходи пораньше, пока ещё не жарко, и иди прямо, никуда с дороги не сворачивай,
риски и стратегию реагирование на них (избегание) – а то ещё упадёшь и бутылку разобьёшь, тогда бабушке ничего не достанется
рекомендации по управлению заинтересованным лицом - А когда ты к ней в избушку войдёшь, не забудь с ней поздороваться, и не заглядывай сперва во все углы!
Применяя инструментарий проектного менеджмента, уместнее использовать термин «проектные вехи» (они же milestones) – именно они обеспечивают возможность беглого отслеживания прогресса реализации задумки. За возможность упрощенной навигации по срокам проекта многие называют документ с верхеуровневыми ориентирами «дорожной картой» (можно сравнить с картой местности).
Распространённость желания взглянуть на длинный, детализированный график проекта и сразу всё понять вытесняет популярностью термин «дорожная карта», насыщенный духом переменчивости agile.
Описываемый в сказке Братьев Гримм продукт – доставка. Клиент и его потребности предопределены в первых предложениях. Хотя если бы среда функционирования Красной шапочки помимо неожиданного появления Волка изобиловала иными неопределенностями, к дорожной карте были бы предъявлены дополнительные требования:
Понятные места возникновения неопределенностей
Кто целевой клиент: не то Волка накормить, не то Бабушку
В чем его потребность: вроде Бабушке поесть надо, а может лучше ей выпить и забыться, а как насчет цветов из леса?
Как Бабушку удовлетворить лучше альтернатив: кусок пирога позволит Бабушке насытиться?
Обоснованность и системность применения приоритетов одних действий над другими
Сначала напоить потребителя или эффективнее накормить?
Выгоднее кормить Волка или Бабушку?
Если вино будет подано на подносе со свежими лесными цветами, восторг Бабушки будет ярче?
В связи с заложенным конфликтом приоритетов – измеримость и неотвратимая измеряемость результатов
Неверное распознавание среды функционирования проекта и попытка из него сделать продукт стоило Красной шапочке приключений и всеобщего порицания: вместо прямого пути к Бабушке, юное создание пыталось цветами, собранными в лесу, удовлетворить надуманную потребность пожилой родственницы:
"А что, если б я бабушке принесла свежий пучок цветов, ведь это бы ее тоже порадовало; теперь же еще так рано, что я еще всегда успею к ней прийти вовремя!" Да и сбежала с дороги в сторону, в лес, и стала собирать цветы. Чуть сорвет один цветочек, как уж ее другой манит, еще лучше, и она за тем побежит, и так все дальше да дальше уходила в глубь леса”.
Ключевая ценность применения гибких технологий в случае необходимости валидации множества неизвестностей – это возможность почти неуправляемый, неизбежно принимаемый риск ошибки снизить в затратах до размера стоимости спринта (как сверхмалой длительности проекта). Но без осознанного формулирования гипотез, планирования эксперимента, фиксации факта ошибки предположений или успеха, основанного на беспристрастных измерениях, эта гибкость абсолютно бессмысленна: использование навигатора в виде agile roadmap в таком случае не более чем прикрытая популярным словосочетанием преступная некомпетентность.
Казалось бы всё просто: очутились в проекте с ожиданием ключевыми лицами scope - рисуйте вехи, в продукте - думаете про состав будущих релизов по прозрачной системе приоритезации гипотез. Но обычно не так и “Волк одевает овечью шкуру”: в среде с порицаемой неожиданностью развития декларируется безудержная гибкость высоких (цифровых) технологий на пути к клиентским потребностям. Много об эту тему сломано судеб и побито клавиш, но часть вины лежит и на доставщиках ценностей (тут про команду в целом, один - не воин): качественно выстроенный scrum делает бессмысленным войну над ресурсами. Ведь на кону лишь цена ресурсов спринта и неизбежность pivot при недостаточно эффективном итерационном (инкрементном) продвижении. Но вот если framework не получается, то вместо принципов agile во благо клиента, начинают доминировать законы личной власти, среди которых: скрывай свои намерения, завоевывай внимание любой ценой, строй зависимости от себя, играй друга, будь шпионом и т.п. Scrum как agile framework - полная противоположность таких законов. И если в окружении запроса на roadmap усматривается проявление законов власти, то истинная гибкость и клиентоориентированность в такой среде будет явно или скрыто порицаема.
Совещание. Идет обсуждение какого-то вопроса.
Брежнев потихоньку задремал...
Обсуждение зашло в тупик. срочно требуется новая идея...
Вдруг Брежнев встрепенулся (в смысле проснулся) и сказал : И де я... Иде я...
Все радостно подумали - вот, наконец-то появилась хоть какая-то идея!
Брежнев продолжает : Иде я... Игдея... И где я нахожуся?
“Дыма без огня не бывает” и понимая среду возникновения требований к дорожной карте, можно увидеть истинные намерения заказчиков документа сквозь хайповые декларации неизбежности “успешного успеха”. Даже не зная конца сказки про Красную шапочку, можно предположить путём анализа контекста - будет ли героиня наказана автором за своевольность по отношению к наказу Матери и вольные толкования потребности Бабушки или нет.
План, вызывающий брезгливость
В этой главе будут рассмотрены типичные на мой взгляд ошибки при построении дорожных карт в гибкой среде (agile product roadmap): какие-то бывают по незнанию, некоторые совершаются злонамеренно.
Инструмент погони за несколькими зайцами
Дорожная карта развития продукта нужна многим заинтересованным лицам, например:
Команде:
команде
в целях минимизации архитектурных ошибок
для бодрости в думах о высокой цели продукта
для синхронизациями внутри, с соседними командами, KPI, спущенными сверху и т.д.
руководству
в целях обеспечения поддержки от держателей ресурсов, владельцев бизнеса
для выстраивания внешних связей продукта
в качестве опоры при принятии решений стратегического уровня
внешним потребителям
клиентам могут быть интересны планы при принятии решения о пользовании продуктом
внешним инвесторам о размере и условиях вливаний средств, для оценки адекватности владельцев startup
конкурентам для выявления технологических, маркетинговых, потребительских и прочих трендов
Даже если помечтать, что содержимое дорожной карты для каждой из этих задач будет схожим, то вполне логичным видится, что формат донесения информации будет разным.
Если брать популярную scrum методологию, то даже там разделены церемонии: demo для заинтересованных лиц в конце спринта и ежедневные standup meeting для синхроннизации командных усилий. Больно даже представлять что будет, когда на ежедневную синхронизацию будут призывать stakeholders. Если бездумно объединять требования к функциональности ПО под разные задачи, то можно утолить жажду шопоголизма за счет компании (есть из чего выбрать или даже можно породить новый софт) Удобство пользования - это важный критерий, определяющий беспрепятственную вовлеченность членов коллектива, но не единственный (вспоминаем Fogg curve): roadmap при должной мотивации можно и в таблицах нарисовать.
Приоритезация: кручу, верчу…
Один из самых знаменитых законов власти звучит как: “Разделяй и властвуй”. Качество применения многочисленных способов приоритезации бэклога определяется лишь результатом релизов задач, где фактический эффект по каждой оценен и растет. Разделение приоритетов внимания команды на задачи “от всех” и “от избранных” обеспечивает начало борьбы за ресурсы. А на войне за выгоду, как гласит мудрость, всё допускается - по итогам победителей ведь не судят. Если эффект от релиза feature известен не всем или неизвестен никому, то именно тут включается не agile со всеобщей прозрачностью, а властные противостояния за ресурс разработки - чьи амбиции будут реализованы: не проверены практикой, а именно реализованы.
Случалось наблюдать следующие составляющего такого тлеющего конфликта:
Команда на основании своих субъективных мнений или давлении сверху принимает решение о способе приоритезации задач, дружно расставляя веса. Так зарождается категория “избранных”, которые могут добавить понятную для команды задачу в бэклог в нужной степени детализации и предварительной проработки, всех остальных “недостаточно некомпетентных” стимулируют к обучению либо к придумыванию небылиц о планируемом экономическом эффекте их задумок
В таком случае среди “остальных” находятся те, кто будет искать изъян в работе команды, чтобы дискредитировать компетентность через манипулятивную подмену понятий и административным путем продавить в команде свои интересы. Изъяны находятся всевозможные:
Слишком долго делаете. Могут придумывать пугающие риски или немыслимые потери при невыполненной задаче
Не можете справиться. Тут вариации: либо накидывается бесконечный поток задач с которым никто не справится, либо задачи ставятся изначально невыполнимые
Не то делаете. Это крайний способ претензии, где ещё надо потрудиться найти огрехи команды. Часто задачи для такого запасного хода ставятся устно ну или команде даётся свобода творчества в придумывание важных бизнес требований, на что потом можно заявить: “Ну голову-то надо было включать..”
Если всё-таки стимулирование манипуляцией привело к нужному релизу, то необходимость продолжать “продавливать” останется, так как члены команды, а в частности Product Owner, будут стремиться реализоваться за счет пуска в жизнь своих задач, оттесняя временный приоритет в пользу заинтересованных лиц
Избавиться от этого порочного круга позволит либо гибридная / проектная разработка, когда со scope не спорят, а укладывают в проектный треугольник. Второй способ - наладить data driven (informed) подход, когда реализованные задачи со временем оцениваются на результат. Вот только в таком случае экспертность в понимании реальных потребностей пользователей и качество предварительной приоритезации начинает цениться.
Движение без навигатора успешности
Ключевая ценность гибкости - это возможность постоянного принятия риска за счет осознания ничтожности размера ошибки. Но менеджер, регулярно осуществляющий одни и те же ошибки, в лучшем случае будет назван недальновидным. В ошибках самое главное - не их несовершение, а их неповторение. Именно своевременно совершенный pivot или быстрое масштабирование успеха определяют жизнеспособность управления высоко рискованными проектами. Так, если бы писался ремейк Красной шапочки, представьте, что ошибка Матери по отправке Красной шапочки в дикий лес повторилась бы. Насколько велико было бы общественное осуждение? Ну или малолетний курьер для Бабушки продолжил бы раскрывать незнакомцам тайны семьи: где ключ от двери лежит, куда пожилой потребитель вина и пирогов складывает фамильные ценности и т.д.
Ожидаемые или даже плановые ошибки мероприятий, из которых состоит agile roadmap могут быть:
Ошибки в ходе фиксации целевого клиента: сколько Волка не корми.. Запланировали эксперимент, завершили его с успехом, а объем затрат на привлечение только растет или новых клиентов почти нет. Главное - вовремя осознать свое положение
Ошибки в ходе определения потребности целевых клиентов: предполагали, что аппетит у Волков придёт во время еды, но ошиблись - животные на волне хайпа стали веганами и пацифистами. PDCA цикл в помощь
Недостататки планирования выгоды: самая распространенная оплошность, совершаемая при планировании - это в порыве визионерства в одиночку тыкать пальцем в далекий образ “журавля в небе”, не желая замечать возможности использовать ресурсы команды для конструктивной критики. Техники, которые придумали для оценки сложности задач, применимы и для нивелирования ошибок в ходе формулирования гипотез потребительской проблематики: в частности Роберт Фитцпатрик на последних страницах знаменитой книги подводит итоги, что ходить в одиночку на интервью проблематики губительно. Самое страшное, когда вне зависимости от набранного опыта экспериментов, точность планирования выгоды не улучшается.
Противники дотошных расчетов могут быть правы, заявляя, что для очевидных улучшений эксперименты не нужны. Но не используя безжалостные к нашим надеждам цифры вовсе, легко встать на дорожку несгибаемой самоуверенной позиции голого короля.
Гибкость высечена в камне
Разные причины могут заставлять высекать roadmap на камне, то есть делать неизменным:
Уговор дороже денег: изменение уговора - это предательство? Бывает что для владельца бизнеса или иной значимой фигуры важнее прогнозируемость того, что делает доставщик ценностей, чем потенциальная негарантированная выгода. Красная шапочка тоже пыталась найти дополнительные выгоды: собирала цветы на полянке в надежде порадовать Бабушку, пока ту поглощал Волк. Чтобы избежать непонимания между заказчиком работы и исполнителем, в project management придумали управление рисками и change request, куда можно записать даже порядок реакции на положительные - те, которые приносят выгоду. Scrum этот момент упростил: product owner выбирает наиболее выгодные (важные) задачи по умолчанию, следуя своему основному предназначению
Усиленно не работаем и не рубим сук, на котором сидим. Одним из основных рисков для работы в роли как product manager, так и project manager - это закрытие объекта применения усилий. Причин может быть множество: от нежизнеспособности продукта до успешного завершения проекта. Бывает, что люди не мотивированы объявить проект закрытым, а roadmap ограниченным в краткосрочной перспективе, так как после этого не гарантирована их занятость, а следовательно и защита интересов. Project management и тут может прийти в помощь, ведь stakeholders - это и команда в том числе. Scrum сообщество уделяет много внимания данному фактору, в том числе воспевая роль scrum master, который мотивирует развивая профессионалов, что должно концентрировать на личном росте, а не паразитировании за счет продукта. Но в реальности эта функция либо подменяется team lead - эксперта в ИТ, а не в управлении, либо низвергается до “говорящей тренерской головы”
Сначала курица, потом яйцо? Дорожная карта бывает тяжело изменяема просто от того, что это очерченный проект и любое изменение как состава работ, так и сроков неприемлемо ни по технологии, ни по интересам заинтересованных сторон: 9 женщин не смогут родить общего ребенка за месяц. Так продуктовый roadmap незаметно для всех может стать проектным графиком календарно сетевого планирования. Зачастую такая эволюция требований замалчивается и приравнивается к провалу продуктовой трансформации, а наложенные поверх элементы работы с продуктом (“результативные” спринты; лучше продукт, чем документация; мотивация команды на продуктовые метрики и пр.) могут убить подход к строительству капитальных решений
Современность диктует хайповый навык “уметь переобуваться в воздухе”, но не везде этот навык применим - важно уметь различать среду реализации проекта и именно отталкиваясь от её свойств выбирать наиболее подходящий инструментарий.
Выводы
Roadmap, который не был построен в сказке, предусматривал бы план движения Красной шапочки или план удовлетворения потребностей Бабушки. Но так в жизни случается, что информация иногда намеренно умалчивается, скрывая чью-то выгоду. Если Вы не желаете попасть в такие, ситуации, то:
ищите истинные причины вашего существования в организации путем анализа как степени зрелости окружающих процессов, так и личных мотивов вашего нанимателя: вне контекста потребности roadmap не существует
синхронизируйтесь с вопрошающими roadmap коллегами на уровне понятийного аппарата: для профессионального продуктолога дорожная карта вне замеров обратной связи не существует, а для проектного менеджера - вполне, если в основе проекта лежит просчитанный кейс
в случае очерченных проектных границ, обеспокойтесь планом управления рисками и порядком совершения запроса на изменения, в случае высокой степени неопределенности - замерами как ориентирами поступательного продвижения к успеху
Никто не вправе однозначно утверждать, какой смысл заложен изначально в Красной шапочке: не то детей проучить, не то Волков напугать. Возможно, раньше история толковалась мудрецами, а в наше время из-за эффекта Манделы воспринимается в основном в виде детского развлекательного контента. Для достижения внутреннего комфорта человеку свойственно упрощать внешний мир, мой призыв - не ограничиваться улучшением проектного инструментария или продуктового мышления, а анализировать мотивы: свои и тех, от кого так же зависит успех.
