Comments 7
Было ли сопротивление со стороны команд и как вы с этим работали?
Там проводилось столько активностей, что можно набрать материал еще на статью.)
Если кратко, то можно разделить на два направления:
Разработка. Сначала, когда мы разработку в выравнивания вовлекали, было много недовольства. По разговорам на 1-1 и на ретро поняли, что ребятам скучно и бесполезно. Да и в целом на самих встречах ребята не особо активно себя вели. Поэтому органично появилось решение ребят из встреч исключить. Если кто-то добровольно хочет - мы только за, подключаем. Не хотят - ок, мы уже поняли, что это не самая удачная идея была. В итоге разработка довольна, потому что они просто продолжают жить в своем обычном процессе, зато появились прозрачные приоритеты, которые перестали активно меняться в течение квартала.
Продакты. Для продактов эти встречи выглядели изначально как дополнительная нагрузка. Вникнуть, разобраться, организоваться - правда с непривычки было тяжело. Очень помогло, что руководители горели этой идеей, поэтому проговаривали на 1-1, проводили воркшопы и обучения, опросы ADKAR и точечно работали с отстающими. Кроме того, команде выделялся наставник, поэтому можно было по всем вопросам обращаться в любое время за советом. А после того, как мы прошли первый цикл и увидели первые результаты, дальше стало проще.)
Если кто-то отказал, уже за рамками выравнивания команда продукта привлекает руководителя и занимается переприоритизацией
Интересует вот такой момент. На выравнивании вам отказали в 2 проектах. Другой команде в одном проекте ну и так далее. В итоге у вас освободилось капасити и у кого-то тоже. Митинг выравнивания закончился. Счастливые команды у кого все ок побежали делать работу а оставшиеся будут пытаться придумать как им быть и какие проекты они могут сделать без чужой помощи? Или какой флоу в таком случае?
Отличный вопрос!
У команды в любом случае лимит ограниченный и надо выбирать. Нельзя сделать 5 проектов за короткий период, если по статистике делаете 3. У меня платформенная команда, в мой бэклог на выравнивании регулярно пытаются впихнуть задачи с горкой, а мне приходится решать, что с этим делать.)
Сначала пытаемся вместе найти обходной путь, как команда продукта может справиться сама. Например, они сами все сделают, с нас ревью и подключиться на е2е. Так снимем зависимость, проект будет готов, наш бэклог не пострадает, все счастливы.
Если команда продукта сама сделать не может, думаем, можно ли безболезненно отказаться от куска, в котором они от нас зависят. Если можно, ура, успех. Сюда же ок ситуация, если им в этом квартале для пилота хватит урезанной функциональности, а на следующий квартал мы уже в бэклог сразу закладываем, что надо будет помочь и доделать.
Если команда продукта сама сделать не может, урезать ничего нельзя, без помощи проект никак не запустить, то привлекаем CPO, чтобы выкинуть какой-нибудь другой проект. СРО на время выравнивания обычно поблизости, поэтому долго ждать решения вопроса не нужно.
А еще обычно проекты, которые требуют помощи других, - это большая работа, которая не появляется спонтанно. Еще на этапе идеи команда считает доходность, обсуждает свою идею с руководителем, руководитель помогает встроить идею в приоритеты бизнес-линии. И к выравниванию команда уже приходит с обоснованием, почему они самые крутые и надо им помочь, а кого-нибудь другому помочь в следующем квартале.
В итоге, работа есть у всех и всегда.) Кто-то вписывается в большие проекты, а кому из-за этого места не хватило, делает что-то локальное.
Как-то много букв получилось.) Если что-то непонятно, уточняйте. :)
Спасибо, в целом понято. У меня в принципе похожая ситуация (платформенные команды, которые еще и между собой зависят от проекта к проекту). Если говорить о таком квартальном планировании, получается к нему уже все проекты должны быть предварительно проработаны технически, чтобы понимать где какая связь возникает? За сколько времени вы начинаете эту проработку и выделяете ли явно в квартале, например, последний спринт, чисто под проработку и ресерч проектов следующего квартала? У меня боль такая, что при планировании не хватает времени на детальную проработку, а так как проекты сложные технически то там может быть 5+ команд спокойно. И вот эти команды потом становятся блокерами. А варианты типа "сделай сам" хорошо работают когда языки одинаковые в командах, что не мой вариант))
Мы живем по канбану, поэтому процесс дискавери растянут во времени и не привязан к кварталу. И часто так получается, что верхнеуровневая проработка начинается в одном квартале, а запуск в другом. И если проект большой и сложный, то проработка и обоснование могут даже на несколько кварталов затянуться.
По поводу зависимостей: у нас давно уже прорисована архитектура, какой сервис зачем к кому ходит, кто держатель сервиса. Поэтому даже пока идея только витает в воздухе, уже по наброску пользовательского пути по схеме понятно, кого придется привлекать, поэтому можно заранее прощупывать почву.)
Вообще кажется по описанию, что у вас проекты, а проектное управление все-таки отличается. В теории, его в квартальное планирование упихать можно, если у вас проекты небольшие.
Мы так и живем: если можно сделать за квартал, то это просто большая задача с несколькими командами, можно спокойно выравниваться по процессу выше.
Если сразу понятно, что это критичная сложная штука, за квартал ценность точно никак не выдать, порезать поменьше нельзя, то это проект. Проекты живут в отдельной парадигме с проектным офисом, проектными выделенными командами, менеджерами проекта.
На мой взгляд, даже здоровенные проекты имеет смысл резать и пытаться выдать хоть что-то через квартал. Потому что на здоровенную задачу надо и других привлекать на несколько месяцев. Конечно, они будут против и будут находить миллиард веских аргументов для отказа.) А помочь с каким-то кусочком на недельку-две - и вроде уже не страшно.)
Как синхронизировать множество команд между собой