В этой статье: продакт овнер – это человек поживший. Быстрое решение задач – это как никотин, вызывает привыкание. Продакт не равно эникейщик. Результаты беседы с PO Lead в логистической компании.
Кому не подходит вариант статьи, то есть стрим: ссылка на youtube.
Т: Меня зовут Тигран, я автор канала Black Product Owner. У меня есть стартап - это платформа для старшеклассников по профориентации в IT, мы готовим их к поступлению на бюджет в IT-вузы. Работой с продуктами я занимаюсь примерно с 2013-2014 года.
Т здесь и далее – это автор, С - это гость.
С: Я Сергей Воскобойников, автор телеграм-канала “Воскобойников” (https://t.me/theway_sv) , где я пишу про управление IT-продуктами, их созданием и т.д. Изначально я был автотестером, а потом стал предпринимателем и остаюсь им по сей день. У нас было небольшое агентство с двумя офисами - в Питере и Москве. Мы занимались performance-маркетингом, я успешно проработал над этим 5-6 лет и закрыл агентство в пандемию, вернувшись к продуктовой жизни. Сейчас я руковожу core-продуктом груза в компании monopoly.online, мы делаем matching между грузоперевозчиками и грузовладельцами.
Т: Когда мы созванивались, чтобы обсудить тему, мы пришли к тому, что есть некий непрекращающийся конфликт между разными сторонами, как будто продакт всегда находится между молотом и наковальней. Скажи, пожалуйста, почему так происходит?
С: Скажу через свой опыт, я сам был РО и сейчас у меня 8 команд в управлении. Наверное, это связано с тем, что РО здорового человека управляет бизнесом, он влияет на бизнес процессы. И в зависимости от структуры компании, в которой он находится, он либо реализовывает это совместно с business-owner’ом, либо сам в себе воплощает часть business-owner’а, и тогда у него есть стейкхолдер, C-level, фаундеры и т.д. Тогда от его решения зачастую зависит не только то, что будут делать люди в текущем спринте, но и то, куда повернет продукт. Он может это продавать своим стейкхолдерам, может реализовывать решения не согласовывая их с кем-то и тд. В нынешних реалиях каждый РО управляет своим стаффом (персоналом) в среднем от полутора до трех миллионов, где-то больше, где-то меньше. Это достаточно нормальные деньги, порядка 40 миллионов в год. И от решений, которые он принимает, зависят последствия - что из этого дальше будет происходить и к чему это все приведет. И зачастую неверное решение приводит к большим потерям. Я в свое время ошибся и мы потеряли пару миллионов за выходные, если не больше, из-за того, что просто обсчитался и выбрал не лучшее время для A/B-тестирования.
Т: Давай я задам тебе несколько уточняющих вопросов. Просто здесь есть разные термины, такие, как business-owner, продакт и другие. Ты можешь дать им определения?
С: Если упрощать, то я попробовал бы так: есть горстка стейкхолдеров - это те кто занимается размещением заказов. Business-owner’ы являются одним из его представителей, это те, кто отвечает за бизнес. Особенно если это гибридный продукт и есть яркая оффлайн-часть бизнеса. Эта оффлайн-часть есть всегда, например, даже у фейсбука и убера есть офисы. Но здесь есть именно процесс, который нужно сопроводить, организовать и реализовать. Business-owner выступает некой первичной бизнесовой компетенцией рынка, продукта и клиента, то есть он может быть таким хорошим первоисточником. А в тандеме с продуктом и продуктовой командой творит добро делает business value.
Функции продакта
Т: Правильно ли я понимаю, что стейкхолдеры это некие заказчики, т.е. люди, которые, условно, хотят чего-то от продукта? Например, руководители каких-нибудь отделов. Вот приходит отдел продаж и говорит: “Мне нужно для моих клиентов, чтобы вот такая вот фича в продукте”. Есть отдел сервис, который занимается поддержкой сервиса, он приходит и говорит: “Вообще что-то все сыпется, было бы классно все дела улучшить таким-то вот образом”.
Вот эти все вещи падают в идеале в какой-то бэклог. На самом деле, в голову вот этого продакта, который думает, как бы это все не потерять сейчас. Потом еще приходит business-owner, который, по моему опыту, чаще всего СЕО, либо, дай бог, если есть СРО, который все это как-то располагает в стратегии, но чаще всего это СЕО. Причем я сталкивался чаще всего с СЕО, которые самодуры, такие, мол: “Я сказал так, так и будет”. И между этими всеми людьми есть продукт, т.е. человек, который менеджерит вот эти штуки. Но с другой стороны есть еще и команда. Ты сказал что у тебя, например, 8 команд, которые как-то вот работают, а чем, с другой стороны, управляет продакт?
С: Слушай, это зависит от стадии развития продакта. Зачастую в контексте нашего рынка, бывает так, что продукт это проджект, такое случается. Когда он чуть подрастает, его начинают называть delivery-менеджером каких-то компаний. Здесь можно изощряться по-разному, но он занимается именно delivery, то есть это означает, что в него пришел входящий поток, он его распределил, оценил, поставил приоритет, дальше загрузил свою команду и в свое производство. Я сейчас свой опыт рассказываю, но когда продакт подрастает, мне кажется, что он задается вопросом: “А что еще есть в этой жизни кроме jira и описания продуктов”. И здесь появляется сакральная мысль, что мы это делаем для кого-то, для какого-то человека, для клиента. И, наверное, ему то, что мы производим, нужно. И ты начинаешь задаваться вопросом, искать вот эту потребность, что ему нужно, почему именно твой продукт должен закрыть эту проблему. И по мере изучения своего клиента, своих потребностей, ты приходишь к тому, что ты можешь придумать что-то сам. У тебя происходит какой-то мэтч в голове, пазл складывается, и ты такой: “О, а можно им дать не только SLA лучшие, а можно еще дать смс-рассылку, чтобы при взятии заявки они в один клик точно знали, что мы оказали услугу”. И вот здесь зарождается, мне кажется, грань продакта, который уже открывает что-то новое. В нашей терминологии, можно сказать “discovery”, пусть это и заезженное слово. Он ищет новшество, не обязательно с рынка, не только в международные рынки можно смотреть. Мы делаем много международных брейн-маркетов, а ты смотришь внутрь своей же компании, и смотришь как это устроено. И глядя в эти процессы, ты придумываешь, как это сделать проще, сделать путь короче. Т.е. путь клиента должен быть таким же кайфовым, как шоколадка - ты съел ее и тебе кайфово.
Product Delivery — поставка Продуктов. Клиентоориентированный подход к определению, созданию и выпуску непрерывного потока ценных для клиентов и пользователей продуктов и сервисов.
Product Discovery – это процесс выяснения того, что же в конечном итоге предстоит создать. Он отражает ваше видение, дает более четкое представление о потребностях пользователей и ключевые ответы на вопросы, возникающие во время построения дорожной карты.
Т: Я вот сейчас записываю курс для Нетологии и там есть все вот эти продуктовые темы. Вопрос такой, вот то, что ты описал, это ведь не то, чему там учат и не то, с чего начинают. Продакт это про пользователя, качество, найти проблему, описать ее, провести кастдевы. Получается, что продакт это что-то другое. Возникают вопросы - а кто такой business-owner тогда? И кто такой по настоящему продакт в таком контексте?
С: Я маленькую ремарку добавлю, особенно, связанную с курсами. Мне нравится аналогия, которую используют, когда учат на программистов. Вот если взять высшее образование, я вот с вышкой, где учили на программистов, там очень сильно напрягают по матану. Прям очень сильно напрягают по теории вероятностей, истории алгоритмов и прочему. А приходя на место, ребята сталкиваются с тем, что нужно распарсить json и толкнуть его в другой формат. И ,в принципе, вся эта красота, которой вас учили 6 лет, оказывается ненужной до лучших времен. Продакты, мне кажется, не исключение. Кастдевы появляются, когда у тебя появляется пространство и компания изнутри имеет такой запрос, чтобы ты кастдевил. Ну, кастдев - это просто фреймворк, по сути там users research и разное проявление таких изучений рынка потребностей и всего прочего.
Т: И кто на себя тогда берет эти функции в продукте ?
С: Зачастую если нет СРО, то это делает тот, кто является СЕО, он же является фаундером зачастую. Из моей практики это не панацея, точно где-то можно прийти и по нормальному заняться продуктовой работой и не заниматься проджектовой. Ты говорил про business-owner’а, давай лучше на примере.
Бизнес до продукта существовал, есть разные стадии продукта, но чтобы не углубляться, возьмем, что продукт уже существует и он уже как то работает. У него есть какой-то денежный оборот, он генерирует какую-то выручку и прибыль, и, возможно, такой сейчас популярный будет кейс, когда компания решает перейти с рельсов обычной компании и стать продуктовой. Чтобы был какой-то может даже сервис и он поехал, чтобы было больше оптимизации и меньше человеческого ресурса. Здесь, мне кажется, business-owner продолжает саппортить вот эту вот часть бизнеса, за счет которой они сегодня живут. И он уже имеет клиентов, он уже имеет опыт продажи, и вообще пользовательский опыт оффлайновской части, он моделирует тот кусочек бизнеса, который уже существует. А продакт, он может, например, связать такой кейс - он берет эту оффлайн часть бизнеса и пытается ее видоизменить, сделав ее таким удобным продуктом, чтобы можно было пользоваться там через цифры. Вот стык и переход.
Т: Получается, что продакт это утилитарная функция превращения идеи в сервис?
С: Если упрощать, то, наверное, да. Не всегда business-owner может развернуть это и поставить лицом к нам.
Почему ты всегда во всем виноват?
Т: Вопрос, переходя уже к нашей теме. Расскажу свой опыт: я был продактом в компании, в которой занимался всей айтишкой, это был стартап, который постепенно перешел в такой образовательный бизнес. Я там отвечал за всю айтишку, но в том числе и выполнял функции продукта, и руководителя разработки, и еще что-то. Еще я видел стратегию развития продукта и получалось так что все время я оказывался виноватым во всем, за delivery ты виноват, что-то не продумал - виноват, кто-то тз не написал - ты тоже виноват. Скажи почему так?
С: Я сталкивался с разными заказчиками, business-owner’ами, стейкхолдерами и на мой взгляд, основная проблема в невысоком уровне компетенции, т.е. непрофессиональный заказчик не понимает как использовать микроскоп. Он начинает микроскопом забивать гвоздь. Например, делать delivery, можно, и скорее всего будет неплохо. Продакты, обычно, умеют делать delivery, но их можно использовать более эффективно, мне кажется, отсюда растут ноги. Круто, когда человек оказывается в компании, в которой есть продуктовая культура, есть понимание, чего ожидать от самого продукта, и вообще чем он должен заниматься. И тогда выстраивается вокруг этого процесс и все процессы в целом, тогда и получается, что у нас продукт. Я знаю продакта, который до сих пор настраивает контекстную рекламу, потому что в компании нет тех, кто будет это делать. Это как у Пушкина - и жнец, и на дуде игрец, а это не очень хорошо. Поэтому, если очень коротко, то надо видеть, с кем предстоит работать. Это, на самом деле, видно на этапах собеса, ну, если достаточно много насмотренности и есть разное представление, какие бывают заказчики, какие бывают процессы внутри компании. Поэтому если стартап, то тут нужен дефолт, я за всех и тут все за всех, тут нет альтернативы. У меня в своих стартапах тоже всё делали все, в большинстве своем. Потому что если есть функция, ее всегда кто-то будет исполнять, и не особо важно - это выделенная роль или она распределена по нескольким людям, все равно ее кто-то будет делать. В большой компании более страшно, мне кажется, потому что масштабы претензий и желания результата становятся более жесткими, как и любая система. Эта семейственность стартапов начинает растворятся, превращаться в достаточно жесткую структуру, и здесь уже только может спасти, если продукт может продать идею того, как он видит, это раз. Это означает ,что нужно выделить ресурсы на это, людей, деньги, время и так далее. Второй момент - он умеет именно выстраивать систему как процесс, т.е. не то что я в один все это буду тащить, это неэффективно.
Т: Два момента. Первый, почему ты во всем виноват, мне кажется, ты правильную вещь сказал, но я повторю, это вопрос ожиданий, и вопрос коммуникации, мне кажется, что здесь очень много на этом замешано, если не производится никакая работа с ожиданиями, ты на этапе входа не производишь эту работу, то на этапе выхода от тебя ждут чего-то другого, того что ты не знаешь, или ты выдаешь не тот результат просто. Поэтому я бы здесь зафиксировал это так - в любом случае, если ты виноват, или так выходит, значит ты на самом деле во всем и виноват, потому что ты не поработал с ожиданиями чувак, ты что-то сделал не так. Работа с ожиданиями - очень крутой скилл, который очень сложно наработать, в моем представлении, потому что нужно учится говорить нет, и говорить нет много, а этот скилл очень редко где дается у нас. Я занимаюсь образованием больше 12 лет, и по опыту, честно скажу, нигде не учат говорить нет, в основном везде говорят да, т.е. тебе дают домашку, ты такой: “да, я это сделаю”. Дают проект, ты такой: “да, я это сделаю”. Никто не учит приоритизировать, негде вообще говорить нет, не учат говорить нет не потому, что я козел последний, а потому что я не вижу в этом смысла. Второе это то, что ты очень крутую мысль озвучил, это - продукт не равно эникейщик. Если ты эникейшиком хочешь заниматься, т.е. все что угодно закрывать, это все-таки не продукт. Конечно, на ранних этапах стартапа, я до сих пор какие-то вещи ручками делаю, потому что я поленился все вплетать, но это не то чем должен заниматься продакт. Он должен заниматься принесением какой-то пользы в виде денег для компании и пользы для конечного клиента.
Какой необходим сетап для команды?
Т: Переходим к следующему блоку. А какой нужен сетап для команды, как ты, человек, у которого 8 команд это строишь, какие ты видишь элементы?
С: Я добавлю сюда такой момент. Сетап может быть софтовым сетапом или это как-то иначе. Когда у тебя 8 команд, становится не очень заниматься микроменеджментом, и главное - это договариваться с людьми о измеримом результате. Т.е. вот со всем заезженным вагончиком, который за этим следует, брать людей, которые умеют выполнять и вообще ориентированы на результат. Люди, которые умеют декомпозировать, устраивать и планировать время. Вот это все - это результат. Т.е. чтобы не каждый день присутствовать на каких-то дейликах, не дай бог, надо иметь вот такой тоже скилл. Он тоже, мне кажется, в нашей среде, сложный для нашего менталитета. Как говорить нет - у меня сейчас успешно работает такая история. Есть РО который понимает, чего от него хотят, в лице меня. Он может перформить, он может выдавать результат, он берет на себя ответственность и готов это обеспечивать дальше, чтобы у него было время заниматься именно продуктовой работой. Я как бы подбираю по одному майндсету его и тимлида, что очень важно. Потому что тимлид имеет другой контекст, нежели продакт, к команде, а команда - это основной ресурс для достижения цели и она должна быть в порядке во всех смыслах. В ментальных, эмоциональных, технологически раскована, иметь все ресурсы, виртуальные среды всех рабочих, всего прочего, гитов и тд. С одной стороны, получается, что они вместе достигают общую цель, тимлид помогает обеспечить результат в технической части. Он вместе с продактом, но с разных сторон, он настраивает команду людей, что им нужно делать, в каком отношении они друг к другу находятся. Кто-то выстраивает хладнокровно: “мы на работе с 9 до 6”. Окей - если это обеспечит результат, то каждый делает для себя так, как считает правильным .
Вторая часть, это когда вы с ним говорите, что вы команда. У меня всегда во всех командах есть конвенция взаимоотношений внутри коллектива - это некий свод договоренностей, как мы друг с другом взаимодействуем. Главное, чтобы коллективу было комфортно и их это устраивало. Какие-то такие постулаты, которые фиксируют, для того, чтобы люди могли вытащить в осознанность то, как они взаимодействуют друг с другом. Это очень круто помогает и ускоряет, а технарь, тимлид, он закрывает именно техничку, он помогает декомпозировать задачу, он помогает найти решения, он помогает разгрузить задачу, он берет на себя и организовывает code review и т.д. Он может сказать: “смотри, у нас там у Васи настроение не очень, я не смог к нему зайти, зайди ты, переговорите, попейте чай вместе, созвонитесь по зуму”. Ты можешь сказать в обратную сторону: “я зашел там на ретро, он что-то сильно погрустнел, мы не взяли его идею на реализацию фичи и он думает, что какую-то фигню сделал, меня он пока не услышал, но это не так важно. Попробуй ему донести, что вообще все классно, все довольны и он молодец”. И когда с двух сторон два основных игрока удерживают позицию, у них распределена зона ответственности, получается очень крепкий сетап. И получается, что даже если в какой-то момент продакт уходит или его увольняют, то дальше, поставив на место продакта вот эту базу с артефактами, которая появляется в процессе совместной работы, становится легко дальше ехать по тем же рельсам. Т.е. ничего не разваливается, у меня есть человек, который это может подтвердить, действительно, на этих рельсах можно долго ехать и дотащить продукт до разных стадий.
Т: Кстати тимлид подчиняется РО организационнно, он подчиняется СРО или они кроссфункционально работают?
С: В этой конфигурации есть два важных поинта - есть организационный, то есть как в компании заведено. Он может подчинятся СРО, либо, бывает, придумывают центр компетенций, где сидят самые топовые чуваки и решают сложные задачи. Это, на самом деле, не так важно. Здесь, на самом деле, мне кажется, важно, кому он подчиняется, в контексте того, кто ставит ему задачу, кто тратит его время. Потому что если возникает процесс, когда в обход РО, безусловно, не со зла и не специально, но происходит так, что тимлид нагружает себя работой, которая не связана напрямую с его продуктом, он соответственно подводит к риску текущий спринт плана и т.д. Потому что этим на 100% должен обладать РО - как мы движемся дальше, каковы потребности и что мы собираемся делать, потому что он держит связь с бизнесом, а тимлид не держит. И вот если тимлид держит связь с бизнесом, то это хаос.
Т: А чем это чревато и почему не стоит?
С: Тимлид еще хуже чем РО говорит нет. Он в основном парень добрый и готовый помочь, он может подсесть на крючек того, что бизнесу очень нравится, что быстро и вне очереди решаются все эти задачи. А это классные ощущения, как никотин, один раз и вообще по кайфу, и как едет, так и поехали, не будем менять процессы продуктового подхода. И дальше будет постоянное вхождение, тимлиду будет прилетать, он будет постоянно разрываться, будет передергивать кого-то из команды, у разработки и т.д. Доказан научный факт, что если человек не закончил задачу, ушел к другой, вернулся снова к предыдущей, то тратится больше ресурсов на привлечение сил и снова вкатывание в эту задачу. Это неэффективно и ломает процессы со всех сторон, это потеря денег, и не получается выкатить вовремя функционал.
Когда заниматься продуктовой работой?
Т: Смотри, у нас я прям, не знаю, продукты, в которых нет технического долга, нет беклога большого. Всегда продукт ты открываешь и там все пошло поехало, это еще если описано хоть что-то, а то бывает так, что там слово или тикеты падают. В общем продукты всегда захардкодены, какая-то вот такая штука которая работает. А когда вообще продуктовой работой заниматься, если то, что ты в основном делаешь, это берешь поступающие тикеты, описываешь истории, ходишь на всякие раунды, планирования, выделяешь квоты на разработку, споришь со всеми, что должно зайти, что нет и т.д.? И в итоге продуктовая работа-то когда, до продуктовой работы не доходит, что делать?
С: В этот момент нужно задать себе вопрос: “хочу ли я быть продуктом?”. Потому что дальше легче не будет, будет только хуже, потом количество команд плодится практически с геометрической прогрессией. Я думаю, дальше нужно реализовать историю с процессами, я так делал, это процесс и делегирование. Т.е. построить сетап, если мы видим что стал справляться с тимлидом, командой, delivery там распараллелил и все работает, то можно подумать - а кто тебе еще нужен для достижения такой цели? Если тебе нужно там высвободить 10 часов в неделю или даже 10 дней на продуктовую работу, то здесь можно конфигурировать дальше уже по-разному. Можно взять PM который заберет на себя рутинную работу или ассистента-помощника, на моей практике, помощники здорово разгружают. Можно выстроить процесс так, что даже без привлечения еще дополнительного ресурса, ты принимаешь еще меньше участия в каких-то мероприятиях, и в этот момент это можно команде продать. Мне кажется, это правильно, когда команда все больше погружается в бизнес, в бизнес-продукт, и за счет того, что ты принимаешь участия меньше, кто-то, как я уже говорил в самом начале, должен все равно это делать, не получится не погружаться, кто-то должен погрузиться. И здесь можно попробовать организовать это на команду, и этот момент сложен, это чаще всего больно. В этот момент может произойти так, что команда может вырасти, именно как команда, она будет похожа на те продуктовые команды, про которые пишут в книжках, которые бирюзовые, которые умеют организовываться, и еще и могут сами уволить РО, если все пошло не туда и не так. И в этот момент, когда ты выделяешь себе время на продуктовую, на бизнесовую часть, для команд это тоже плюс, потому что ты приходишь с новыми идеями, с новым видением, с новым апдейтом с рынка клиента. Ты их как бы вдохновляешь, даешь новую пищу для размышления. Приходит новый контент, а они выступают крепостью, на которую ты опираешься. Им круто, что они подросли, узнали больше. Где-то стало сложней, кто-то отстреливается и без этого, кому-то это вообще не надо. Это зачастую и есть причина увольнений некоторых людей по собственному желанию - потому что не все члены команды готовы жить вот в такой парадигме, что надо знать продукт, надо знать потребителя, надо знать бизнес, надо знать зачем мы это делаем. Это и хорошо может быть, но может и не получится, и будет совсем плохо, все развалится в тартарары. Если идти от сетапа с тимлидом, то, в принципе, не должно все развалится, точно все будет трещать, но не так, чтобы в тартарары улетело.
Продакт-менеджер, проджект-менеджер и product-owner. Разница функций.
Т: Давай подытожим предыдущий блок. Есть product-owner - владелец продукта , а кто такой продакт-менеджер в этом отношений?
С: Из практики, как у меня это было, продакт-менеджер ограничен некой ответственностью принятия решений внутри самого продукта. Т.е. он может быть больше ходит в поля, более операционно делает рутинную работу, РО тоже ходит в поля, но здесь уже как организуешь процесс. РО может получать результаты интервью уже в качестве документов, файлов, заметок или в аудио и еще каких-то форматах, и на базе этого делать вывод, либо получать выводы от продакта, который больше повидал, скажем так, в полях, и он ему приносит некоторые инсайты. Продакт может заниматься всей операционкой, связанной с командой.
Т: Давай переводить. Получается, product-owner - это владелец продукта, продакт-менеджер - это тот, кто менеджерит, управляющий продукта ,т.е. владелец выше управляющего. А тимлид - это уже техническая составляющая. Но есть же еще проджект-менеджер. Насколько он вообще, в твоем представлении, нужен в нормальном сетапе команды?
С: Мне кажется, в текущих реалиях, в текущем рынке они не особо нужны. Если мы говорим про продуктовую команду, про продуктовый подход, я бы здесь рассмотрел вместо проджекта – бизнес-аналитика, мне кажется, в этом больше смысла. Это дороже получается, потому что проджект или бизнес-аналитик или какой-то там еще аналитик это всегда дороже. С одной стороны, их наличие, мне кажется, делает выстрел не в голову, а в ногу, в плане развития продуктовой команды. С другой стороны, это более быстрый результат здесь и сейчас - любого взять нормального с головой бизнесового аналитика, он тебе закроет фронт работ.
Скрам-методология. Бирюзовые команды
Т: Ты упоминал скрам-методологию. Есть ли роль скрам мастера? Зачастую его приравнивают к проджекту, мол, человек, который такой активный, всех должен пинать и тд. Как быть с этим, у тебя в командах была такая роль или команда самоорганизующаяся ?
С: У меня скрамы были, я сейчас в достаточно большой компании работаю и у меня есть скрамы в каждой команде. Где-то один скрам-мастер на 2 команды, потому что уже все построено и процесс бежит. Они используют скрам-мастеров более точечно, они берут их на ретро, я их, бывает, привлекаю на обучение какое-то, когда у меня есть запрос на РО. Либо я вижу, что команда где-то проседает, я говорю: “ребята, давайте посмотрим что такое value stream mapping и почему это важно”.
Я однажды был и скрамом, и проджектом, и продактом, и product-owner’ом. Не развалился, но глаз дергается. То, что пишут, это хорошо, но это надо сильно адаптировать, исходя из контекста. Для себя, в своем маленьком видении, в моем мире, я бы проджектов оставил в 2010 году и они остались бы у меня для waterflow, где все красиво, но где речь не про деньги.
Поэтому появились потом скрамы, которые могут выстроить процесс. Из практики, из наблюдения, скрам мастера - это классный инструмент, но только в умелых руках, зачастую, представление о том, что может дать скрам команде очень ограниченное. Настрой нам, пожалуйста, скрам в jire и поставь регулярную встречу в календарь, и все, успех. Но такое ощущение, как-будто это не вся суть скрам мастера. Скрам мастер тоже стоит денег, он стоит неких ресурсов компании и командам, особенно в стартапах.
Вот сколько я себя наблюдаю, сколько я пишу постов в канале, все равно глобально возвращаемся к тому, кто заказывает, потому что если это дядька, который: “делаем сегодня это и мне на все остальное пофигу”, то тут ничего не поможет, все будет нервно, неуправляемо и немасштабируемо. Если вы попали в компанию с продуктовым подходом, уже пропитанным им на 100%, тогда становятся понятны роли и можно построить хороший пример того, как это должно быть. Но мне кажется, у нас сейчас таких компаний не то, чтобы много.
Поэтому, с одной стороны, клево когда он есть, с другой, у нас много суеты и мы хотим его на постоянку к себе, а он у нас на полгода, или на год, а что дальше? Поэтому, возвращаясь к адаптации того, что мы знаем из теоретической части, надо очень сильно смотреть на заказчика. Вот сколько я себя наблюдаю, сколько я пишу постов в канале, все равно глобально возвращаемся к тому, кто заказывает, потому что если это дядька, который: “делаем сегодня это и мне на все остальное пофигу”, то тут ничего не поможет, все будет нервно, неуправляемо и немасштабируемо. Если вы попали в компанию с продуктовым подходом, уже пропитанным им на 100%, тогда становятся понятны роли и можно построить хороший пример того, как это должно быть. Но мне кажется, у нас сейчас таких компаний не то, чтобы много.
Т: Ты сам поднял этот вопрос, про бирюзовость. Вот у меня было несколько подходов к этой организации, один раз мы даже на часть компании выкатили ее и это работало интересно очень, мы выросли за год, подняли где-то 1,2-1,5 миллиарда. А потом все ушли, потому что сменился владелец компании. Вопрос, что ты имел в виду, и как это помогает наш первоначальный вопрос решить? У меня такое ощущение, что почему-то в этой бирюзовости очень много нереального.
Маск говорит, что на марсе можно будет жить. Выглядит нереалистично и ученые говорят, что это ерунда полная, но есть те, кто в это верит. И мне кажется, что бирюзовая команда - это как свиток дракона в кунг-фу панде, это такой высший уровень, когда ты можешь с помощью этого инструмента решить проблему своей занятости, решить проблему своей операционки
С: Маск говорит, что на марсе можно будет жить. Выглядит нереалистично и ученые говорят, что это ерунда полная, но есть те, кто в это верит. И мне кажется, что бирюзовая команда - это как свиток дракона в кунг-фу панде, это такой высший уровень, когда ты можешь с помощью этого инструмента решить проблему своей занятости, решить проблему своей операционки. Это некая, может быть, заветная цель, к которой ты идешь step by step. О чем мы говорили, ты можешь от проджекта в 2010 году дорасти до какого-то там CPO, в то состояние прийти, когда у тебя есть бирюзовая команда. В моем понимании, бирюзовая команда нужна, когда у вас есть бирюзовые люди, которым это вообще надо, потому что если команда распадается, меняется, происходит ротация, когда вы предлагаете погрузится больше в продукт и в бизнес, это такой маленький обвес того, что нужно дать, чтобы она начала расти дальше, не говоря уже о стопроцентной бирюзовости. Когда команда самоорганизованная, это всегда такой холивар, в чем она самоорганизованная? Она способна прийти на берег или договориться о встрече? Ну, наверное, взрослые люди способны это сделать. Может ли эта команда организованно принять решение, что мы делаем в следующем спринте? Точно может. Может ли эта команда организованно принять решение, что мы делаем в следующем спринте с пользой для бизнеса? Сложнее ответить, но, наверное, может .Может ли вообще концепция бирюзовости быть такой, что все люди ответственны за результат. Я не верю, когда мы все ответственны за что-то.
Т: Это коммунизм своего рода, тогда никто ни за что не ответственный. Известная мантра каким образом что-то распилить - это сказать, что это общее.
Я тут одну таблицу открыл, хочу показать. Это такой файлик, когда мы развивали бирюзовость, это этапы развития в рамках спиральной динамики. Спиральная динамика - это первоначально появившаяся теория относительно этапа развития человека, его ценностей первоначально, а потом уже все остальное. И в рамках этой спиральной динамики выделяют разные уровни, структурные слои, в зависимости от того, где ты находишься. Что дает энергию сотруднику, в зависимости от уровня, разные будут энергетические слои.
Известная мантра каким образом что-то распилить - это сказать, что это общее.
Суть в том, что каждый из нас обладает разным набором вещей, которые нас двигают вперед, и я понял что для бирюзовой команды нужен человек, который очень много жизненных кризисов прошел, ведь любой переход - это кризис самоопределения, когда твои ценности меняются. Т.е. чтобы построить такую команду, которая придет и начнет делать, это надо делать с опытными людьми. Это меня расстроило, потому что нельзя это стимулировать, нельзя просто взять случайных людей, объединить их и сказать, мол, давайте заряжайте. Ничего не получится, пока они сами к этому не придут, этого не произойдет. Это разочаровывает, ведь это сложно, долго, это такая штука которая произойдет, только если повезет.
С: У меня сейчас пришла идея, пока ты говорил. Где больше всего бирюзовых команд? По моему опыту, среди команд фаундеров, стартапов, там от 2 до 4 человек, на мой вкус, идеально, и они самоорганизовались на базе идеи, и договорились между собой о сложных вещах - как делим деньги, кто за что отвечает, построили договоренности, каждый разбежался. А уже потом прибежали в конце недели, поделились, кто что сделал, скорректировали курс и пошли дальше бежать, здесь самое кайфовое и сложное - требовать выполнения договоренностей, а мы это капец как не умеем делать, я имею в виду людей в целом. Как экологично и эффективно добиться того, чтобы твой коллега, который с тобой в равных правах, в той же иерархии, что и ты, исполнил то, что он пообещал, и как разбирать непростые вопросы. Мне кажется, фаундеры - это бирюзовые команды.
Итоги
Т: Тогда возвращаясь к первоначальному сетапу. Как продакту перестать быть пушечным мясом в аджайл команде: соблюсти бизнес-требования и не поругаться с разработкой, коротко, как это сделать?
С: Если коротко и тезисно. Первое: начинать сотрудничество с квалифицированными заказчиками (с теми кто знает о продуктовом подходе). Дальше мы говорим нет и управляем ожиданиями. Строим процессы внутри команды и делегируем. Нужно добрать недостающих ресурсов. Нужно верить и продолжать, это очень важно.
Т: Я бы еще одну вещь написал - не знаю насколько ты и слушатели согласитесь. Продуктовая работа очень сильно про опыт, нельзя форсировать время получения опыта, ошибки, неправильные решения. Т.е. если ты возьмешь человека, дашь ему все идеальные инструменты и он пойдет работать, у него ничего не получится, просто потому что он не был в жизненных ситуациях. Кажется, чтобы качественно эту работу производить, нужно через все это пройти.
С: Соглашусь, это как журналистика, хороший журналист - это не тот, кто окончил журфак, а тот кто пожил, видел что-то, пережил что-то, что немаловажно. Разница между продактом и product-owner’ом - это кто сколько пожил.
PS спасибо за ваше время, если понравилось, то подписывайтесь на канал https://t.me/blackproduct там регулярно появляются новые стрим с C-level гостями.
2PS поделитесь в комментариях, как вам формат? что нужно улучшить? какие еще темы осветить?
Спасибо!
