Зачем мы здесь собрались, чего хотим достичь — вопрос, который каждая команда ставит перед собой на старте. Когда есть цель, есть и стратегический план по ее достижению. Мы поговорили с Sr. ADC Дашей Войтовой о том, как наличие Roadmap влияет на мотивацию команды, почему созданием стратегического плана не должен заниматься один человек и какие ошибки нельзя допускать при его разработке.
Давай разберемся, что такое Roadmap.
— Есть общепринятое определение Roadmap и оно совпадает с моим пониманием. По сути, это стратегический план, который определяет цели и тот результат, который мы хотим получить. Как правило, Roadmap включает основные шаги и контрольные точки их достижения — у команды должно быть понимание конечного результата. Зачем мы собрались и чего хотим достичь — это основной вопрос для создания Roadmap. Каждый член команды, абсолютно каждый, должен понимать, для чего он здесь работает, зачем он делает то, что делает, какие задачи перед ним стоят, для чего он их выполняет. Когда есть цель, как правило, есть и план по ее достижению.
Если мы говорим о Roadmap и плане проекта — в чем разница?
— Все зависит от того, с какой стороны на них посмотреть. В Godel мы постепенно отошли от понятия «проекты», за которыми были закреплены Project Managers. Сейчас мы говорим об engagements — партнерстве, сотрудничестве. Долговременное сотрудничество с клиентом подразумевает работу над несколькими проектами и/или поддержку какой-то платформы или продукта. План проекта — project plan — это частная история по сравнению с Roadmap. План проекта и Roadmap как инструменты имеют разный фокус и цели. В фокусе плана проекта — один элемент Roadmap, мы ориентированы на часть работы, которую нужно сделать, ресурсы и время. Roadmap демонстрирует действия, которые команда будет выполнять по отношению к продукту/сервису — в зависимости от поставленных целей.
Какие элементы Roadmap обязательно должен содержать? Есть ли общие принципы, которых нужно придерживаться?
— У нас есть график: по оси X — время, по оси Y — инициативы. Инициативы располагаются блоками на временной шкале в зависимости от продолжительности и показывают, что именно и когда команда будет делать, сколько это займет времени. Они могут располагаться в параллели — если инициатив несколько, и работу над ними можно распределить между участниками команды. Если у нас есть активность, которая полностью займет время всей команды, то она будет единственной в данный момент времени. Никаких особых секретов нет — это план поочередного выполнения задач. В зависимости от ситуации активности можно делить по смысловой нагрузке — касающиеся технической или бизнес-части. Roadmap — это план, а как он будет выглядеть, нужно решать по ситуации.
Хорошая практика: если у команды есть постоянная активность, занимающая определенный процент ее времени и возможностей, можно сразу отобразить ее на Roadmap. В таком случае стейкхолдеры будут видеть, что есть работа по поддержке продукта/сервиса, занимающая 30% capacity команды. Все остальные инициативы, отображенные на Roadmap, будут вмещаться в оставшиеся 70% времени.
Для чего нужен Roadmap? Может ли команда и бизнес без него обойтись?
— Roadmap в первую очередь нужен команде — для того чтобы понимать, как она будет приходить к конечному результату. Если стратегического плана нет, будет страдать мотивация. Без понимания, зачем мы выполняем те или иные задачи, сотрудники будут придерживаться принципа «мне сказали — я сделал». Если мы хотим достичь эффективного результата, такого быть не должно. Участники команды, которые видят, чем они будут заниматься, совмещают план действий со своими личными амбициями, смотрят, насколько им интересно то, что будет происходить, и соответствует ли это их взглядам на дальнейшее развитие. С другой стороны, Roadmap нужен для того, чтобы синхронизироваться с другими командами — в каждой компании этот процесс устроен по-своему. Roadmap помогает совместить активности, расставить приоритеты, подхватить или поделиться частью работы. Roadmap других команд нужны, чтобы понимать, как управлять зависимостями между ними.
Roadmap необходим не только команде, но и бизнесу. Заказчику важно видеть, как команда будет достигать целей. Имея перед собой визуализацию стратегического плана, он принимает решения — что нужно делать и в какой последовательности, а что не стоит. Получается, Roadmap нужен всем!
А что будет, если работать без Roadmap? Это реально?
— Бывают ситуации, когда команды работают по такому принципу: сейчас есть пул работы, а дальше — вдруг что-то еще появится. В этом случае страдает мотивация. Людям не нравится так работать — им хочется видеть, зачем они здесь находятся. Причем, мы говорим не только о мотивации в принципе работать, но и о мотивации работать хорошо. Если не знаешь, как ты влияешь на конечный результат, в чем смысл стараться делать что-то круто?
Без Roadmap сложно мониторить взаимосвязи между командами: допустим, мы что-то запланировали, но как узнать, готова ли к этому компания и другие команды? Если нет Roadmap, мы никому не сообщили о своих планах и заблаговременно не предупредили о том, что будем делать, скорее всего, у нас ничего не получится, потому что никто не будет к этому готов. Без Roadmap сложно управлять ожиданиями стейкхолдеров — если нет визуализации наших планов, нам будут постоянно задавать вопросы, будет некомфортно от незнания, что происходит.
Roadmap повышает прозрачность, которая в свою очередь снижает градус волнения — всем все видно и понятно. Отсутствие Roadmap может привести к принятию неверных решений. Например, если инициатива занимает слишком много времени, то, возможно, ее не стоит делать вовсе. Без визуализированного плана это сложно вовремя идентифицировать.
Кто принимает участие в создании Roadmap? Все ли члены команды могут его редактировать или для этого есть определенные роли?
— У продукта есть Product Owner, который отвечает за прибыль, понимает цели и организует работу для их достижения. Он ответственный за то, чтобы построить план. Поэтому в большинстве случаев именно Product Owner курирует создание Roadmap. Иногда разработка плана ложится на плечи Agile Delivery Coordinator. В создании «дорожной карты» могут участвовать и бизнес-аналитики, которые зачастую выполняют часть активностей Product Owner — в каждой компании это работает по-разному. Идеальный вариант — когда в разработке Roadmap участвует вся команда: участники могут высказывать свое мнение, предлагать идеи и согласовывать их с Product Owner. Ответственность за достижение целей распределяется по всем членам команды — это приводит к эффективному результату. Роль ответственного за Roadmap принадлежит Product Owner, но при этом у каждого из участников есть право голоса, в плане есть и его идеи.
А если Product Owner составит Roadmap, который невозможно реализовать?
— Такие ситуации бывают — кризисы случаются. Например, Product Owner составил план, который выполнить нельзя ввиду каких-то критических зависимостей — нужно думать над тем, что сделать можно, но идей мало. У нас есть такая практика: команда садится вместе с Product Owner, и начинается мозговой штурм на тему того, что можно было бы сделать — с технической и продуктовой точек зрения. Все участники могут предлагать свои идеи и наполнять ими Roadmap. Product Owner необязательно должен приходить с готовым планом — он может прийти к команде с идеями, и мы вместе подумаем, как их достичь.
С чего начинается построение Roadmap?
— Это происходит по-разному. Чаще всего у клиентов, которые заключали с нами контракт, какой-то план уже есть — для того чтобы понимать, с чем будет работать команда, с которой заключен долгосрочный договор. То есть, составление драфта Roadmap происходит еще до того, как команда приступает к работе — ей объясняют, как работает бизнес заказчика, какие у него цели, зачем она заключила с нами контракт. После этого команде показывают примерный план. С началом работы его начинают адаптировать: команду вовлекают в его оценку, участники вносят свои коррективы, высказывают мнение.
Разработка Roadmap начинается с осознания целей и стратегии. Дальше в зависимости от целей строится план и визуализируется. Его подготовка важна для того, чтобы у всех была одинаковая картинка и одинаковое понимание составленного плана. Команда смотрит, обменивается мнением, сможет ли она таким образом достичь результата, в том числе, с учетом технических зависимостей.
Какие инструменты используются для создания Roadmap?
— Roadmap желательно строить в онлайн-инструменте, в котором можно совместно его редактировать. Если делать это в офлайн, участники команды не будут видеть изменений. В онлайн-инструментах все — представители бизнеса, стейкхолдеры, команда — видят актуальную картинку, которая есть на данный момент. Roadmap можно построить даже в Excel Online, расположив в документе все необходимые блоки. Есть специальные инструменты, типа Product Plan, где блоки можно двигать — они дают большее визуальное понимание, это удобно, людям нравится.
Roadmap должен выглядеть так, как это необходимо в данном конкретном случае, не более того. Не стоит брать какой-то красивый образец и слепо ему следовать. Если нам нужно, чтобы в Roadmap был какой-то элемент, значит, его обязательно следует туда внести — все зависит от нужд конкретной команды. Если у заказчика есть общепринятые элементы Roadmap, мы берем их за основу.
Какие, на твой взгляд, ошибки можно допустить при разработке Roadmap?
— Чаще всего ошибки связаны с детализацией Roadmap — он может быть слишком общим или, наоборот, чересчур подробным. Оба таких плана не дают информации, которая нам нужна. Плохо, когда Roadmap слабо детализирован — в нем указаны только очень большие инициативы. Такой план очень редко обновляется, отсутствует динамика и информативность. Бывает наоборот — стратегический план очень подробный, там находятся активности, которые, например, длятся один день. В итоге образуется множество мелких элементов — чтобы поддерживать такой Roadmap в актуальном состоянии, нужно приложить немало усилий, поскольку он будет часто меняться. А если информация постоянно обновляется, то смысла в таком плане нет — никто не может на нем основываться: каждый день нужно открывать документ и смотреть, что в нем изменилось.
Нехорошая ситуация, если Roadmap создает один человек без участия команды. Бывает так: Product Owner придумал план и, не пообщавшись с командой, пришел к стейкхолдерам и сказал, что так оно и будет. Product Owner прикинул, что одна часть работы займет три месяца, другая — два. Команда посмотрела Roadmap, и сказала, что вместо трех месяцев активность будет длиться полгода. Получается, команда еще не начала работать, но уже виновата в том, что нарушила чьи-то обещания. Если Roadmap кто-то составил, с кем-то поделился и без участия команды утвердил, она не несет ответственности за результат. Чтобы поддержать вовлечение всех ребят, усилить их мотивацию при работе над одной целью, Roadmap должен быть продуктом команды.
Давай подытожим. Что, исходя из собственного опыта, ты можешь посоветовать командам, работающим над Roadmap проекта?
— На мой взгляд, лидер команды, будь то Project Manager или ADC, должен понимать важность Roadmap и фасилитировать его создание. Он должен убедиться в том, что все члены команды понимают, зачем выполняют ту или иную задачу, какие есть цели и как нужно их достигать. Хорошо, когда команда участвует в создании Roadmap, потому что в этом случае она несет ответственность за результат — распределенную на всех, а не сосредоточенную на ком-то одном. Все это соответствует формированию продуктового мышления, при котором люди понимают, что они делают, стремятся к максимально эффективному результату, становятся кросс-функциональными. Если команда принимает участие в создании Roadmap, понимая цели и осознавая план действий, она сможет его обновлять и актуализировать, анализировать, полезно ли на данный момент то, что было придумано ранее.
Если мы идем по заранее придуманному и составленному для нас плану, то речь идет скорее о краткосрочных, нежели долгосрочных результатах. Нам сказали — мы сделали: эффективность и ценность команды измеряется по тому, насколько хорошо она выполнила те или иные элементы. Нет фокуса на том, позволят ли эти элементы бизнесу достичь желаемых результатов при работе с нами.
Команде не стоит сидеть в ожидании, что ей все принесут, покажут и расскажут — можно и нужно предлагать свои идеи, если мы рассчитываем на долгосрочное партнерство. Зачастую клиенты хотят нас видеть именно такими: чтобы мы разобрались в продукте, в работе, которая у нас есть, и сами что-то предложили. Поэтому не нужно стесняться наполнять Roadmap своими идеями, генерировать их. Если идея твоя, ты замотивирован, чтобы она сработала.
Еще у нас есть такая практика — один раз в месяц команды проводят Innovation Days. В эти дни команда может заниматься чем угодно. Участники могут взять и сделать Proof of Concept по какой-нибудь фиче, которую они сами придумали. Зачастую, чтобы продвинуть или реализовать свою идею в Roadmap, нужно создать и показать бизнесу PoC — заказчику будет понятно, как это будет работать.
Еще один момент — элементы, расположенные в Roadmap, должны быть понятны всем — с минимальным объяснением. Логические блоки можно разделить на технические и продуктовые. Чем читабельнее и понятнее будет Roadmap, тем лучше.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.