Про то, почему и как в разных компаниях приходят к продуктовым командам. Мыслями поделился автор telegram-канала для продактов alexcouncil Алексей Арефьев.
округ продуктовой темы много хайпа: куча образовательных программ для продактов, народ идет повально учиться, компании хотят выстроить «продуктовый подход», продакт, продакт, продакт. Но откуда все это добро взялось и почему оно набирает?
Мне удалось поработать в нескольких крупных компаниях, и то, что я видел, кажется, поможет ответить на вопрос выше. Чтобы легче было воспринимать информацию, собрал всю суть в схему. Скачать в хорошем качестве можно здесь.
Весь процесс эволюции продуктовых команд я разделил на этапы. Каждому свойственны свои особенности и симптомы. Изменения, которые появляются на каждом следующем этапе, выделены оранжевым. Давайте детальнее разберем.
1. Как-то
Все началось с того, что в компании есть какая-то разработка и это как-то работает.
PM — продакт менеджер, или тот, кто отвечает за развитие digital-продукта.
IT — подразделение, отвечающее за разработку.
Релиз — выпуск/публикация разработанной функциональности.
Роли PM и IT могут по-разному называться: ecom, digital, разработчики и так далее. Суть от этого не меняется, так как одни (PM на схеме) задачи ставят, другие (IT) помогают их реализовывать. Релиз — момент времени, когда задача готова и выпущена для эксплуатации.
Ситуация: есть некий поток задач, который сыпется в волшебную коробку под названием IT. Задачи могут прилетать с разных сторон. Часть идет через PM-подразделение, часть напрямую.
Симптомы:
Отсутствует бизнес планирования. Что-то как-то реализуется.
Часть задач выходит в срок, часть нет.
Нет релизного цикла.
Нагрузка на IT не распределена. Народ то перегружен, то недогружен. Внутри: тлен, безысходность, непонимание смысла жизни, выгорание.
2. Релизная схема, спринты
Нужно что-то менять и как-то сбалансировать нагрузку на людей.
Ситуация: появляется релизная схема и спринты, фиксированный период времени на разработку и тестирование задач. Теперь задачи кладутся в спринт и выпускаются строго в определенные даты релизов.
Нагрузка на IT становится более сбалансированной. Плановые работы на регрессионное тестирование и подготовку релизов помогают немного упорядочить хаос. Сокращаются трудозатраты за счет стандартизации работ.
У системы появляется темп/шаг. Две недели спринта — релиз, две недели спринта — релиз.
Но:
Задачи все так же поступают со всех сторон.
Какие-то влезают в спринты, какие-то нет.
Бизнес-планирования все еще нет: сроки не выдерживаются — заказчики негодуют.
3. Пропускная способность спринтов
Как научиться выдерживать сроки?
Ситуация: начинаем оценивать задачи. Сколько стоит та или иная задача, допустим, в часах? Сколько часов мы можем закрыть за один спринт? Появляется пропускная способность спринта.
Зарождается планирование. Прозрачнее становится понимание возможностей команды. Чуть лучше становится управление ожиданиями заказчиков.
Но:
Поток задач в IT все также не упорядочен.
Нет понятного приоритета задач.
Не сбалансирована нагрузка на команду IT.
Отсутствует стратегия развития продукта.
4. Поток
Чтобы эффективно управлять системой и ресурсом разработки, нужен процесс — выстроенный поток задач с учетом приоритетов бизнеса.
Ситуация: все задачи на разработку проходят через PM. Исходя из оценки задачи, приоритетов и пропускной способности команды планируются задачи на спринт. Система «вытягивается», поток задач становится прямым. Появляется понятное бизнес планирование с приоритетами и сроками.
Нормализуется нагрузка на команду IT. На вход приходит фиксированный список задач. Изменения не вносятся во время спринта. Растет эффективность всей системы за счет постоянного потока и упорядочивания хаоса.
Вся система становится прозрачной. Видны «узкие места», те части процесса, в которых задачи могут «подвисать». Расширяем эти места — улучшаем time to market (время от момента, когда задачу придумали до ее фактической реализации).
5. Продуктовые команды
Можно ли эффективнее управлять развитием продукта и ресурсом разработки?
CPO — chief product officer или главный продакт-менеджер.
Развитие продукта должно отталкиваться от стратегии компании. Как с помощью продукта достичь поставленных бизнес целей?
Необходима продуктовая стратегия — набор изменений в рамках продукта, направленный на достижение бизнес целей компании. За сборку стратегии отвечает CPO. Внутри стратегии могут быть выделены направления, сущности или куски пользовательского опыта, требующие особого фокуса.
За каждым направлением выделяется продуктовая команда во главе со своим PM. Внутри команды есть полностью выделенные роли: разработчики, тестировщики, дизайнеры (опционально), аналитики (опционально).
На практике делить могут по платформам (web, app), по сущностям (личный кабинет, интернет-магазин), по воронке пользователя (acquisition, activation) и так далее. Отсюда появляются: продакт мобильного приложения, продакт личного кабинета, продакт activation...
PM собирает стратегию по своему направлению в рамках общей продуктовой стратегии. Внутри команды ставятся общие KPI, что позволяет сфокусировать всех участников процесса на единой цели.
Приоритет задач, оценка и планирование спринтов происходит внутри команды. Прямые коммуникации сокращают время на принятие решения. Независимость от других продуктовых команд позволяет лучше планировать изменения и управлять ожиданиями заказчиков.
Таким образом на уровне компании появляется прогнозируемое развитие продукта с фокусом на бизнес цели и сокращенным time to market.
Мысли
Этапы, которые я описал выше, — это лишь взгляд на то, что мне удалось увидеть. Те «боли» и потребности, которые возникали в разных компаниях, подталкивали систему к изменениям. Эволюционно все так или иначе приходили к одному — некоему подобию продуктовых команд.
P.S. В схеме, которую приложил к статье, я оставил 6 этап под вопросом и написал: «Что дальше?» А ведь правда, что? Какая структура будет следующей? Что-то бирюзовое или еще какое? У меня нет ответа на этот вопрос.
Если у вас есть опыт или мысли на этот счет, поделитесь, пожалуйста, в комментариях
Комментарии (26)
VEadm
19.02.2022 23:43Если продукт игрушка, то у меня больше вопросов нет. Спасибо за ответы, хороших выходных.
ermadmi78
20.02.2022 13:12С сильным DevOps и с хорошим покрытием кода интеграционными автотестами (что с появлением Docker и Testcontainers стало обыденным делом) я могу релизиться хоть несколько раз в день. Если говорить о микросервисной архитектуре, то там вообще у каждого микросервиса может быть свой релизный цикл. Соответственно теряет смысл связка (спринт -> релиз). Если по итогам спринта у нас нет релиза (а есть штук 20 микрорелизов), то начинает размываться смысл самого спринта. И так процесс разработки начинает эволюционировать от скрам подобных спринтов к линейному беклогу и работе без спринтов в стиле канбана. Т.е. эволюция подходов к построению процесса разработки идет по спирали.
Это так, мысли вслух :)
Asterris
21.02.2022 01:12+2Всю эту историю нельзя рассматривать в отрыве от бизнес-заказчика, который собственно и генерирует этот поток задач - и от позиции и веса ИТ как бизнес-юнита внутри компании. И от веса ИТ-директора в структуре управления компанией. И от общей культуры стратегического планирования и стратегического управления.
Потому что хорошие, умные и светлые ИТшники искренне хотят, чтобы продукт был качественным, релизы выходили в срок и не было никаких косяков. Да вот только коммерсы и топы зачастую мыслят другими категориями. Они сегодня утром родили гениальную идею - и тут же кидают её в ИТ со словами "ну-ка сделайте-ка быстренько". Всем плевать на спринты, приоритеты и ресурсы. У них всегда приоритетнее - потому что это клиенты, это бизнес, это приказ генерального, в конце концов! И у ИТ-директора должна быть очень мощная позиция внутри управленческой команды, чтобы суметь сказать "нет" генеральному. Или тому же маркетингу - который немедленно побежит жаловаться генеральному со словами "вонючие ИТшники рушат наш бизнес!". Поэтому ИТ, не умея отказать, набирает на себя кучу задач, которые делает как попало, чтобы угодить тому, кто громче кричит. И всё равно остаются виноваты, потому что срывают сроки где-то в других областях - особенно если ИТ-отдел одновременно и поддерживает, и эксплуатирует и дорабатывает.
Спринты, оценки и релизы появятся только тогда, когда топ-менеджмент поймет, что прикручивать каждый день новые фичи - это путь в никуда. Когда начнет планировать развитие продукта на год и не переделывать план каждую неделю. Когда ИТ получит полномочия отказывать коммерсам в их запросах, потому что нет ресурсов и есть план - а для этого, помимо плана, нужно ещё и ресурсы правильно посчитать, правильно расписать по проектам и по нагрузке и правильно этот график поддерживать. Тогда коммерсы захотят приоритезировать запросы, чтобы ИТ брало их в план - и тут появляется проектный комитет, на котором топы начинают задавать неудобные вопросы и внезапно узнают, что стратегия-то есть, но никто её не соблюдает... Появляется стратегический комитет... И так далее ????
Короче - это ооооочень большая история и зависит она не только от ИТ, вернее - не столько от ИТ, сколько от стратегического управления компанией.
helg1978
21.02.2022 03:26Пораженный глубиной коментария, хотел реквестировать статью от вас, но в ваших публикациях тут же нашел, уже написанную. С удовольствием прочитал.
Asterris
21.02.2022 14:29Спасибо, очень рад, что приношу пользу людям ????
У меня и на тему данной статьи есть прям кейсик описанный (ну как описанный - в телеге описанный для чатика ????), который отлично иллюстрирует все управленческие взаимодействия, которые в данном вопросе возникают. С вашей подачи я даже подумал, что это можно и в статью положить! Займусь, пожалуй, в ближайший день защитника отечества ????
DikSoft
21.02.2022 08:21Грамотно сформулировано, во многом соглашусь. Часть явлений непосредственно наблюдал. Вы написали:
.. особенно если ИТ-отдел одновременно и поддерживает, и эксплуатирует и дорабатывает.
А как с Вашей точки зрения, "поддержка и эксплуатация" без превращения ИТ сервиса в "Продукт" рациональное решение, или надо обязательно "вот это вот всё", продакт, спринты, прогрессивные методологии и железное подсаживание бизнеса на вечный цикл разработки?
Ну, т.е. где грань между нормальной поддержкой и разработкой?
Asterris
21.02.2022 14:09А это зависит, опять же, от бизнес-задачи, страт.планирования и управленческой силы ИТ. Потому что поддержка и разработка различаются, в первую очередь, с точки зрения бизнес-процессов и их параметров: преимуществ, производительности, прямых затрат и затрат косвенных (например, усилий, требующихся чтобы убедить два десятка пузатых директоров в том, что ИТ - это не помойка для их гениальных идей, а четкий механизм, работающий по своим правилам)
Вот смотрите. Спринт - он для чего нужен? Если просто - то для того, чтобы продукт выходил вовремя и без косяков, а также - чтобы разрабы не зашивались и не рвали волосы, метаясь между потоком задач от орущих маркетологов. А далее вопрос - а самим маркетологам это нужно? Как правило - им плевать на план и регулярность, им надо ad hoc - потому что так работает вся компания.
И даже если на словах ИТ-директор может договориться с генералом о том, что "спринт - это важно, стратегия - это важно, давайте придерживаться и т.п." - то закончится это тем, что генерал всё равно потом придет и скажет: "Ладно, пацаны, ну чо вы со своими спринтами - ну сделайте вы уже фичи этим маркетологичкам, у них же клиенты там, бизнес, продажи..."
Всё, значит стратегия не работает на самом высоком уровне. И значит, что для всей компании сиюминутное реагирование и тушение пожаров приоритетнее, чем планомерное движение к цели. Ок, это ни плохо, ни хорошо - это просто статус-кво. Просто этот статус-кво не бьётся с желанием ИТ делать всё системно. И аргументы типа: "У меня команда выгорает от неравномерной загрузки задачами, постоянного негатива от коммерсов и постоянно вчерашних дедлайнов!!" - эти аргументы не волнуют генерального. Ему плевать, что там с командой - ему важно, чтобы выдерживался привычный ему стиль работы: приказ отдал, побежали выполнять без вопросов. Что ж, такова данность и дальше надо думать, как в рамках нее существовать - есть ли у вас влияние, чтобы убедить генерального? Есть ли у вас полномочия, чтобы отказывать коммерсам? Есть ли у компании ресурсы, чтобы дать вам правильного объема команду? Есть ли вообще хоть у кого-то понимание, куда он идёт - и как это положить на ваш план? ????
Asterris
21.02.2022 14:19То есть вся эта история с разными типами продуктовых команд и спринтов, это в первую очередь история про разрыв в управленческих компетенций между коммерсами и ИТ. И исправлять начинать надо именно оттуда.
Приведу пример - вот буквально три месяца назад ко мне обратилась ИТ-команда из сложного большого ритейла ровно с таким же вопросом: как разнести техпод и разработку и как сделать так, чтобы генеральный не считал нас мудаками?
Про это можно отдельную статью писать, конечно, там много всего фундаментального. Но если вкратце - я им предложил разнести их работу на три разных сценария с разными SLA:
Техпод - это быстрые короткие задачи от которых зависит выживание бизнеса. Сиюминутное реагирование, высший приоритет - но список задач ограничен
Хотелки - это реализация хотелок бизнеса, но через призму оценки трудоемкости, жёстких приоритетов и четких SLA: сказали через месяц - значит получите через месяц и не орите ????
R&D - это четкий процесс долгосрочного развития систем, а также реализации хотелок, которые на первый взгляд были "изи", а как копнули - то стали "так блэт". Тут уже свои, очень длинные, сроки и другой формат взаимодействия с заказчиком
blackshow Автор
21.02.2022 21:18Вы правильно подсвечиваете вес "отказа" и силу процесссов с "невкидыванием" задач. Обычно это называют продуктовой и технологической стратегией. Если ее внутри компании защищают и поддерживают, то далее ветки и фокус спускается вниз и на тактическом уровне она выживает. Поэтому важно "сверху" строить всб историю.
Но хочу вас дополнить про "план развития продукта на год". Важно, чтобы это план отражал скорее вектора и основные направления ращвития, нежели конкретныф бэклог задач, потому как, если вы соьираете b2c сервис и холдируете чекто задачи на год, то то есть риск потерять актуальность рынку. Поэтому, лучше оперировать более широкими областями на уровне годовой стратегии. И да, это не отменяет операционных процессов и правил с "невкидвванием задач вов ремя спринта" ;)
Asterris
21.02.2022 14:26Сорри, я чота нажимаю и оно исчезает, поэтому пишу три камента ????
Это всё строго загоняется в таск-трекер, все загрузки считаются, под коммуникацию с коммерсами выстраивается управленческая методология, ответственность за которую перекладывается на ГД, а не на ИТ. Ну т.е. если ИТ завернуло задачу от маркетологички - то это значит, что маркетологичка не бежит в ГД и не обкладывает ху@ми итшников - а идёт на проектный комитет и сама защищает приоритетность своей задачи в обществе таких же крикливых коммерсов, как она - а на ИТ выносится только финальный список договоренностей между коммерсами. К слову сказать, этот подход довольно быстро сбивает спесь с бизнес-заказчиков - т.к. орать на беззащитного итшника это не то же самое, что орать на коммерческого директора ????
В общем, этой длинной телегой я попытался ответить на ваш вопрос - а где грань?
Грань можно понять, когда разделите разные по формату задачи разработки, поддержки и развития и наложите их на текущий управленческий статус-кво - для понимания того, что из этого реально нужно бизнесу. Звучит сложновато, но в реальности - довольно просто проектируется, зато отвечает на кучу вопросов сразу
DikSoft
21.02.2022 16:17Т.е. грань проходит и существует только тогда , когда (обманом/лестью/уговорами/реальными аргументами) удалось протащить превращение существующего и работающего ИТ сервиса в статус "Его величество Продукт", со всеми вытекающими для команды поддержки продукта ништяками. И дальше уже можно выдвигать/диктовать бизнесу разные условия, ибо он (бизнес) уже
проигралсмирился с тем, что этот конкретный ИТ сервис всегда будет работать "сегодня" не так, как нужно. Или будет, но очень сильно не сразу.Про модель "разово заказали допиливание" сторонней (или внутренней) команде мы бизнесу не говорим.
Я правильно понял?
Asterris
21.02.2022 17:36Примерно, но не так радикально :)
Грань - это рамки бизнес-модели, в которых существует продукт. А бизнес-модель - это не только разработка. Это, в первую очередь, стабильность и предсказуемость результатов при понятном формате взаимодействия и в понятном формате экономики.В этом смысле, хаотичное допиливание и заваливание итшников рандомными задачами - вполне себе допустимая модель, подавляющее большинство бизнесов прекрасно в ней работает десятки лет. Она приятная для топов с их ЧСВ, она понятная для коммерсов и их коротким горизонтом планирования, она приемлема для акционеров с их совковым видением развития бизнеса в духе "бери больше кидай дальше, от забора и до обеда". Аргументы итшников в этом раскладе просто не будут услышаны, ИТ в данной ситуации - не драйвер бизнеса, а обслуживающее подразделение.
Переход к продукту происходит тогда, когда бизнес осознает, что продукт - это не просто спринты и релизы, а это стабильность развития функционала, гарантия его работоспособности и прогнозируемые затраты на получение понятного результата. Но запрос на такую стабилизацию экономики и прогнозируемость результата должен прийти от тех самых истеричных маркетологов - у которых должна, для этого, появиться стратегия и они должны научиться по ней работать, а не просто класть её в стол. Где-то тут должно появится понимание, что ИТ - это не просто мальчики на побегушках, а бизнес-критичный ресурс, от слаженной работы которого зависит получение коммерческого результата. А значит - итшников нельзя кошмарить лишний раз, нельзя заваливать задачами и отвлекать от работы, нельзя экономить на их штате и т.п. Тогда и начинается серьезный разговор и переход к продуктовым форматам.
Понятно, что и в этих форматах бывает бардак - продукты тоже, порой, допиливаются на бегу и скрам-команды иногда тушат пожары и работают в две смены. Но в данной ситуации это будет скорее исключение, чем правило - а значит не приведет к выгоранию и развалу команды, остановке разработки и, как следствие, остановки в развитии бизнеса.
DikSoft
21.02.2022 18:06Позволю себе длинную цитату:
Переход к продукту происходит тогда, когда бизнес осознает, что продукт - это не просто спринты и релизы, а это стабильность развития функционала, гарантия его работоспособности и прогнозируемые затраты на получение понятного результата.
Выше Вы практически дословно дали определение цифровой трансформации. ИТ превращается из обслуги в драйвер развития бизнеса, меняя его процессы и способ получения прибыли.
Внимание вопрос, точнее два: Любой ли ИТ сервис реально станет фактором трансформации, т.е. почему всё подряд обязательно надо превращать в "Продукт"? Нет ли тут намеренного обмана со стороны ИТ?
DikSoft
Вся суть продуктового подхода в инсорсе: навязать бизнесу свою постоянную необходимость, бонусом уменьшив ответственность.
Красивые слова о ценностях, релизных циклах, спринтах - это лапша на уши вместо реального решения задач тогда, когда они возникают, придумывание, чем показать свою занятость.
На выходе - никогда не работающий ИТ сервис в том объёме и так, как это требуется бизнесу. Зато куча "мы так активно пашем" менеджеров и "что за фигню мы опять делаем" разрабов. + нехилый бюджет, ухудшающий конкурентоспособность самого бизнеса.
ashiku
Все так, если поток задач не превышает возможностей команды.
Что делать, если задач у бизнеса больше, чем можно сделать прямо сейчас, когда они возникли?
> На выходе - никогда не работающий ИТ сервис в том объёме и так, как это требуется бизнесу
Мне кажется, это больше про ожидания бизнеса, чем про добросовестность разработки.
VEadm
Выглядит эмоционально. За такими одиозными выводами есть какой-то опыт? Поделитесь, пожалуйста. Второй момент - а как без продуктового менеджмента? Так работают все, это стандарт индустрии. И работают там люди/человеки, кто-то эффективней, кто менее, но это уже частности.
DikSoft
Это удачно созданное заблуждение, в которое поверили многие заказчики, т.е. менеджмент.
Если ИТ не ваш профильный бизнес, то классическая модель покупки софта для закрытия потребностей в ИТ сервисах + покупка разовых тюнингов на стороне + покупка саппорта (своего или внешнего) вполне себе рентабельная практика. Разделение приобретения/разработки и поддержки/эксплуатации давным-давно придуманы и прекрасно работают.
А вот когда берут в штат людей для постоянного "допиливания", тогда и начинается бредятина о том, что "теперь нам уже точно и обязательно нужен свой Продукт с большой буквы. Иначе конкуренты у которых Продукт уже есть нас съедят." Считать надо деньги, а не верить в красивые мифы, подсунутые заинтересованными в постоянной занятости манагерами.
VEadm
А причем тут PM?
DikSoft
Смотря что Вы имеете в виду под PM. Если это пресловутый продуктовый подход, то он в большинстве случаев даром не сдался в инсорсе, как и сам "Продукт".
Вроде как в Digital Transofmation уже наигрались, единицам действительно нужно трансформировать бизнес. Для остальных "Продукт" это очень дорогая игрушка.
blackshow Автор
Могу только отталкиваться от собственного опыта: "навязывание" есть там, где живут космические бюджеты. Приходит консультант новомодный и давай скрамы внедрять с командами в зеленых банках. Где-то взлетело, где-то наоборот упало. Сколько потратили? Да пофиг, не видно.
Если посмотреть на компании поменьше, то вопрос продуктовых команд, это скорее альтернативная конфигурация. При тех. же ресурсах попробовать сделать получше ttm, например, через обновление процесса и фокусировки. Взлетит? Да хрен его знает, надо пробовать. Что влияет на успешность такой структуры, да куча всего.
В свое время в нескольких компаниях видел как работает этот переход: больно, долго, но с положительными результатами. Правда скажу, что делать выводы надо через 3-6 месяцев после изменений, потому как только к этому времени люди срабатываются и начинают разгонять систему.
А так: можно ли и без команд? Да легко, вопрос лишь в том, а можно ли лучше при существующем конфиге и кто про это думает?
DikSoft
Вот тут уже становится интересно. Для простоты оставим случай , когда основной бизнес компании не связан с ИТ и речь про инсорс.
Как бы Вы описали разницу между командой поддержки ИТ сервиса и продуктовой командой?
blackshow Автор
Как разные команды со своими целями и мотивацией, ечли на то позволябт ресурсы. То есть, есть отдельно те, кто работает над ростом бизнес показателей и те, кто поддерживают инфраструктуру, чтобы этот рост случился.
Если ресрусов недостаточно, то багофиксы и прочие штуки уходят в команду, ровно как и рефакторинги, потому как опять же влияют на результаты всего продукта.
DikSoft
Уточню: вопрос был про конкретный ИТ сервис, у которого может быть команда поддержки. При чем тут команда инфраструктуры?
blackshow Автор
Не понял вашего вопроса, можете подробнее про инсорс раскрыть?
DikSoft
Да, попробую быть более точным.
У не ИТ компании , есть ИТ сервис, ну например "работа с поставщиками чего-нибудь", этот сервис целиком обеспечивает некий программный продукт. Есть выделенная внутренняя команда поддержки этого ИТ сервиса. В нашем случае это команда поддержки вот этого прикладного софта. Допилить там что-то, когда меняется формат обмена данными или отчёт какой разработать/изменить или устранить выявленные ошибки в работе сервиса. Это саппорт и эксплуатация.
А есть так называемая внутренняя "команда Продукта", в нашем случае - команда, которая постоянно "допиливает" этот продукт.
Как бы Вы сформулировали принципиальную разницу между этими двумя командами?
Спасибо.
blackshow Автор
По процессам разницы так таковой не вижу. Продуктовая команда - это лишь способ организации людей, привязанных к определенной цели.
Цели у внутренней команды Продукта могут мыть одни: бизнес метрики и прочее. Цели команды поддержки - други. Может ли команда Продукта быть организовага одним способом, а поддержки другим? Конечно, если это решает задачи компании. Можно ли улучшить текущую структуру с процессами? Конечно, если кому-то это важно в компании.
В статье мне скорее хотелось отразить тренд появления продуктовых команд и причины. Будучи частью такой команды, решил поделиться опытом. Но прошу ни в коем случае не воспринимайте материал, как категорически правильный и единственный конфиг. Если у вас отлично работают люди и бизнес доволен, то и менять, ради "менять' ничего не нужно. Но задуматьсч о том, можно ли лучше, стоит попробовать.