Бизнес любого размера: самые критичные ошибки в процессах продукта/IT и как их исправить

Привет. Я Паша, CPO (директор по продукту). Работал на этой позиции и в стартапах, и в крупных компаниях с оборотами в сотни миллиардов рублей. А еще я не раз занимался консалтингом и насмотрелся на проблемы, которые бывают почти везде. Мне несколько раз приходилось строить процессы с нуля и несколько раз приходилось менять существовавшие до моего прихода. Давайте я расскажу, что это за проблемы и какие процессы должны быть.

Заранее отмечу, что большая часть того, что в посте, а еще многое другое, есть в моем небольшом телеграм-канале. Подписывайтесь, комментируйте.

Статья будет большая, поэтому, чтобы ее хоть как-то разнообразить, я к каждому разделу буду вставлять картинку, сгенерированную в ChatGPT. Очень любопытно, как ИИ будет рисовать проблемы. Будем с вами смотреть, хорошо ли он справляется.

Так или иначе, в любом бизнесе сейчас есть IT составляющая. Поэтому сделаем небольшой шаг назад и опишем два каноничных подхода к разработке сервисов: проектный и продуктовый.

Есть Заказчик (как правило, кто-то из менеджеров высокого звена), который придумывает продукт и рассказывает это менеджеру проекта, который задачу детализирует, расписывает, оценивает и несет в команду. А команда делает это за один подход или разделяет на много этапов, но решение на рынок выходит одним большим релизом.

Самые большие проблемы такого подхода:

- Топ-менеджер, который придумывает новый продукт - бутылочное горлышко. Это плохо масштабируемая история.

- Топ-менеджер, который рассказывает, что и как делать, не является целевым пользователем и может иметь вижн с неконсистентным для рынка решением.

- Редкие релизы - огромная проблема. Их сложно сводить вместе (много задач от ряда команд), тестировать, выкатывать, откатывать, доделывать. А еще и редкое получение обратной связи от рынка.

- Мнимый Scrum: водопад нарезают на водопадики и все думают, что это гибкий подход. Если не выкатывать частые релизы на продакшн, то не будет никакой гибкости. Только более хороший контроль по срокам.

Менеджер продукта прорабатывает десятки каналов информации: продуктовую аналитику, отчеты исследований, обратную связь от клиентов через техподдержку, соцсети, сторы, рыночные аналитические отчеты, конкурентный анализ, мировые тренды и тд.

Из этого следуют плюсы:

- Бутылочного горлышка нет, каждый продакт сам прорабатывает свой продукт. А с топ-менеджерами он только координируется/сверяется.

- Продакт выпускает решения, ориентированные на целевого пользователя: на нем проводятся исследования по построению карты его опыта, сбор потребностей, прогон сценариев по макетам и прототипам.

- Сбор отклика рынка происходит по метрикам частых релизов. Цена ошибки - двухнедельный спринт, а не полгода-год.

При этом есть и минусы:

- Скрам (методология гибкой продуктовой разработки) обходится дороже, чем в проектном подходе. Хоть это и многократно окупается, изначально все равно скрам дороже

- Менеджеры продукта, которые смогут потянуть подход bottom-up - довольно дорогие. Bottom-up - это когда продакт менеджеры проактивно приходят к топам и рассказывают, как планируют развивать бизнес и растить метрики, а не наоборот.

В целом, рынок давно понял, что продуктовый подход - это то, без чего нельзя работать эффективно. И начинают его внедрять. По факту, у многих в компаниях появляются люди, которые называются менеджерами проекта (или продакт оунерами), но при этом остаются Заказчики, которые определяют все развитие. Разработка нарезается на "спринты", но по своей сути, остается водопадом, порезанным на "водопадики", по итогам которых нет релизов в продакшн и сбора обратной связи через аналитику и ресерч (исследования).

Поэтому давайте в этой статье разберем проблемы, когда все думают, "у нас продуктовый подход", но, по факту, застряли в неэффективных меотдологиях 60х годов прошлого века.

Но до этого важно отметить 2 момента.

Первый - внедрение может быть затруднительным. Оно очень зависит от культуры компании. Не все Заказчики готовы потерять власть перестать напрямую влиять на изменения и превратиться в Стейкхолдеров или доменных экспертов. Не все команды готовы переходить в новую парадигму, когда от них много что зависит и они должны перейти от майндсета "нам говорят что делать - мы делаем" в майндсет "мы определили проблему или возможность и нам надо решить, что и как делать". Не все главы отделов (например, разработки, дизайна, тестирования) готовы к тому, что их людей раздали в команды и за главами остается только качество, скорость и развитие сотрудников, но никак не определение приоритетов и роадмапов.

Второй - не все может быть внедрено сразу из-за уровня зрелости компании. В большие или старые бизнесы очень тяжело что-то внедрить целиком и полностью. Не готовы люди, не готова инфраструктура (а без микросервисов невозможны и частые релизы). Тут главное поставить цель, понять шаги достижения цели по изменению процессов и идти к ней.

А теперь можно перейти к прикладному списку проблем. Сначала я вам пришлю оглавление, чтобы было проще навигироваться:

Проблема 1: Наличие Заказчика или Биздева

Проблема 2: отсутствие трекинга продуктовых и бизнес метрик

Проблема 3: отсутствие A/B-тестов

Проблема 4: отсутствие финмодели

Проблема 5: отстутсвие исследований

Проблема 6: нет валидации гипотез

Проблема 7: нет стратегии компании или хотя бы стратегии продукта

Проблема 8: непонимание аудитории и ценностного предложения

Проблема 9: нет фиксированного состава команд или часть команд находится в других отделах

Проблема 10: нет корректного каскадирования метрик

Проблема 11: отсутствие синхронизации между командами

Проблема 12: не минимизированы кросс-командные зависимости

Проблема 13: беклог наполняется из ограниченного числа источников

Проблема 14: Пишутся технические задания или функциональные требования вместо обозначения метрик, гипотез, контекста, юзер-стори

Проблема 15: Отсутствие PRD (Product Requirements Document)

Проблема 16: Не измеряется time to market

Проблема 17: после A/B-тестов нет постмортем анализа

Проблема 18: Отсутствие четкой системы приоритизации со скоррингом (ICE/RICE)

Проблема 19: у вас нет гипотез, а есть задачи

Проблема 20: Отстутсвие портрета пользователя

Проблема 21: наличие бизнес аналитиков и системных аналитиков в командах.

Проблема 22: наличие проектных менеджеров в командах

Проблема 23: в команде нет ретроспектив или они проводятся неправильно

Заказчик или биздев - это люди, которые приходят в команду и говорят, что и как делать. В продуктовом подходе продакт должен иметь все возможности решать самостоятельно, что делать. В ответственности продакта - рост его фокусных метрик и соответствие стратегии компании. И у него должны быть все инструменты, включая решение, какие будут приоритеты по задачам.

Тем не менее, приоритизация задач должна быть прозрачной и не основанной на чьей-то персоне, будь то продакт или биздев. Об этом мы поговорим позже.

Наличие биздева, который вместо продакта, дизайнера и прочих членов команды все продумывает, говорит о том, что продакт не может выполнять свою работу. А когда это внешний человек, он не участвует во всех мероприятиях команды. Не ходит на планирования, на дейлики, не описывает и не комментирует каждую задачу. И при отсутствии таких коммуникаций теряется очень много важного для продукта. Потом приходится что-то переделывать. То есть, замедлять бизнес. А еще биздев часто может только часть времени тратить на команду и у него может не быть всего контекста пользователей.

Тем более, продакту сложно брать на себя ответственность за результат, когда у него нет всех инструментов для реализации. Если к команде приходят и говорят, что делать извне, команда отвечает не за то, что метрики вырастут, а за то, чтобы сделать сказанное в срок. А это уже проектный подход, который неэффективен.

Я видел довольно большое количество компаний, которое принимает решение не на основе актуальных цифр.

Когда у вас происходят какие-то оффлайн продажи, о которых компания узнает через месяц - она теряет этот месяц. Ведь в первые дни что-то могло пойти не так. Рынок мог просесть, мог изменить условия конкурент, могли быть проблемы в процессах. А если об этом узнать только спустя 30 дней, вы не приобретете часть прибыли за это время.

Но если есть продажа товара или услуги - у вас должна быть воронка пользователей. Вы должны понимать, где он застревает. Вы должны понимать, где застревают люди, для которых характерен какой-то определенный атрибут. Например, устройство, операционная система, регион, возраст или канал привлечения.

Каналы привлечения и их эффективность тоже должны измеряться. Как и ROI каждой рекламной активности и кампании.

Метрик очень много, они каскадируются, ветвятся, зависят друг от друга. Они являются первоисточниками поиска проблем, по ним можно понять, какие могут быть гипотезы, они помогут оперативно реагировать на изменения. Они помогут сверять план с фактом.

Компания должна организовывать свою деятельность (от гипотез до стратегии), отталкиваясь, в том числе, и от метрик и показателей их роста.

Метрик много, как и их совокупностей, способов визаулизации, аналитики и принятия решений. Все это я уже описывал в отдельной статье. Главное, чтобы вы могли измерить каждый чих пользователя и на основе совокупности данных принимать верные решения.

Проблема 3: отсутствие A/B-тестов

Вся суть продукта - в быстрых релизах и проверке отклика рынок на них. Нужна программа лояльности с разными уровнями и бонусами? Быстро делаем MVP и запускаем A/B-тест, смотрим, меняется ли пользовательское поведение. Если они покупают лучше и больше, то наслаиваем туда новые и новые фичи. Если нет - значит, наш подход оказался не продуктивен и мы или откажемся, или все переделаем.

AB-тесты - это проверка гипотезы на долю аудитории. Метрики B-группы (тех, кто получил новую функциональность), сравниваются с контрольной группой, у кого ничего нового нет. И такой замер метрик с явным различием гарантирует, что показатели выросли не из-за колебаний рынка, а именно из-за новой фичи (ведь у нас есть нетронутая выборка А для сравнения).

То есть, понять, эффективна ли ваша гипотеза, нельзя без AB-тестов.

Конечно же, бывают ситуации, когда у вас слишком мало клиентов. Например, вы стартап или у B2B-компания среднего размера. Тогда бы набор статистически значимой выборки шел бы месяцами и это нельзя было бы назвать эффективным развитием продукта.

Для таких ситуаций есть метод продуктовой аналитики "causal impact" или можно сделать интервьюирование пользователей. Четких цифр они вам могут и не дать, но вы, по крайней мере, измеримо поймете, что новая фича работает как надо и драйвит бизнес.

Трекинг изменений после реализации гипотезы очень важен и не только для того, чтобы понять, что ваш продукт стал лучше. Вы получаете обратную связь и можете сравнить факт с планом. Эта информация позволит вам раз за разом строить все более и более точные прогнозы роста динамики метрик.

Проблема 4: отсутствие финмодели

Весь ваш бизнес должен быть разложен на каждый фактор, который влияет на доход.

Трафик, конверсия каждого канала, количество товаров или услуг на один заказ, количество заказов на пользователя, возвращаемость пользователей, частотность, средний чек и прочее.

А если у вас есть еще и оффлайн часть, туда же надо добавить количество офисов продаж, количество сотрудников в каждом офисе, эффективность каждого сотрудника, разложенную еще на десяток метрик.

Не забывайте о расходах: ФОТ, лицензии, комиссии, возвраты, реклама и прочее.

И только когда вы по месяцам распишете каждое значение каждой метрики (и фактические в прошлом, и прогнозные в будущем) и поймете, как оно работает совокупно, к вам придет осознание, чего не хватает бизнесу, как он реально работает и что нужно развивать в первую очередь. И кто за какой показатель должен отвечать (отсюда уже легко сформировать OKR/KPI).

Менеджеры продуктов же будут растить свою метрику. И у них будут уже целевые вполне осознанные показатели. Например, чтобы на товарах с доставкой сделать оборот 1 миллиард в месяц, ему не хватает подрастить средний чек и возвращаемость. Он поймет, что нужно идти пилить систему рекомендаций и кросс-продаж, а так же программу лояльности. Если после расчетов ему не хватит ресурсов, чтобы успеть все вовремя, он придет с четким планом. Попросит какое-то количество людей, которые помогут сгенерировать какое-то количество прибыли. И инвестор, фаундер или CEO сможет принять взвешенное решение - или добавлять бюджет или упростить цель. Или концептуально поменять подход: например, вложиться не в количество членов продуктовой команды, а в ребят, которые оптимизируют архитектуру и увеличат скорость разработки. Или не развиваться на внутреннем рынке, а выйти на внешний.

Без взвешенной модели и целевых метрик ваш бизнес будет развиваться довольно непрогнозируемо.

Мы уже немало поговорили про продуктовую аналитику. Но в ней есть ограниченность. Она отвечает только на один вопрос: "что?". Что происходит. То есть, где и у каких пользователей какая метрика плохая. Но только исследования могут ответить на вопрос "почему?".

Исследователь берет у продакта вопросы, на которые нужны ответы, формирует гайд и бриф (выборку и сценарий исследования), общается с клиентами, формирует отчет. И приносит результаты.

После исследования уже четко понятно, по каким причинам у вас низкие конверсии для различных сегментов пользователей (или для одного), что их раздражает, почему они не хотят возвращаться или не набирают большие корзины.

Исследований великое количество. Они бывают качественные, а бывают количественные. Качественные - это общение 1:1 с небольшим количеством респондентов (или с фокус-группой) в формате открытыых вопросов с развернутыми ответами. А количественные - это опросы с вариантами ответов, которые рассылаются на большую аудиторию.

С помощью количественника можно разбить аудиторию на сегменты. А потом с помощью качественного исследования построить их пользовательский путь и найти все точки роста. Или можно на качественнике поисследовать, как клиенты воспринимают новые фичи на этапе разработки макетов: тогда вам не придется тратить время разработки на то, чтобы что-то исправлять. Ведь вы это исправите после исследований, но до передачи в разработку.

Один раз я общался с ребятами, которые запустили бизнес про лидогенерацию в оффлайн магазины с EBITDA в 3 миллиарда рублей в год. Он кратно рос, потом стал большим и известным и его темп замедлился. Они решили выходить с ним на зарубежные рынки. Но пользователи пропадали, воспользовавшись продуктом, в среднем, три раза. И не было их контактных данных. И никто не понимал, почему так происходит и что делать. Потому, что первые три раза они вели себя как очень лояльные: часто пользовались и хорошо конвертировались. И не понятно, почему не возвращались. Я им посоветовал проводить дневниковые исследования. Взять 50 человек целевой аудитории, которые не пользовались их продуктом, дать им его и получать от них ежедневный отчет: ощущения, эмоции, желания, связанные с сервисом. То есть, исследования в этой ситуации были единственным вариантом измеримо понять точки роста бизнеса.

А однажды я запускал экспресс-доставку. И только исследования помогли мне понять, что такое для моей аудитории "быстро", в каких сценариях это нужно, сколько они готовы платить, каким должно быть качество сервиса. И только после исследования доля использования экспресс-доставки стала расти.

Кроме продукта, многие пользуются исследованиями: маркетинг, чтобы проверять концепции рекламы и трекать здоровье бренда. Контакт-центр, когда формирует tone of voice и скрипты оператора, аналитики ценообразования и многие, многие другие.

Не иметь в штате исследователей может сильно тормозить развитие вашего бизнеса.

Между придумыванием гипотез и их реализацией есть важный шаг - валидация. Хороший менеджер продукта - это не тот, кто пытается подтвердить каждую свою гипотезу, а тот, кто пытается ее опровергнуть.

Например, вы сгенерировали 50 гипотез после исследования. Обогатили ими беклог, в котором до этого было еще 100. Планируете следующий квартал. Понимаете, что можете взять только 15. И часть из них не выстрелит. Ведь по статистике, у сильных продактов выстреливает только 20% гипотез (выстреливает = достигает прогнозных метрик).

Не очень хочется работать квартал, а потом понять, что из 15 полезными оказалось только 3.

Для этого и существует валидация. Есть много видов исследований или продуктовой аналитики, которые помогут, не тратя много времени, проверить - зайдет рынку новая функциональность или нет.

В частности - RAT, riskiest assumptions tests. Это когда вы, как и в MVP, получаете обратную связь от рынка, но при этом не даете ценность. Их еще называют fakedoors. Например, на 5% аудитории выкатывается кнопка "купить в кредит". При нажатии пользователь получает сообщение "функция в разработке". Сделать такую кнопку можно за 10 минут. И быстро понять спрос через CTR (click through rate): посмотреть соотношение нажавших и увидевших. Если увидело 1000 человек, а нажали 10, то явно гипотеза так себе. А если увидело 1000 человек, а нажало 700, значит, интерес есть. И бизнес-потенциал.

Поэтому в ситуации, когда вы за квартал успеваете сделать только 15 фичей, возьмите на валидацию 30-35. За пару недель все проверите и половина из них наверняка отвалится. И компании не придется тратить деньги на их полноценную разработку, чтобы узнать, что от них метрики не вырастут.

Этот пункт будет довольно коротким. Вы должны понимать, что вы делаете, для кого, какие проблемы решаете, какие метрики вырастут и к чему вы хотите придти.

Без этого вы просто будете зарабатывать деньги. Причем не сможете за год или два сделать вещи, которые будут синергировать потому, что ваша деятельность будет идти вразнобой, а продукт будет напоминать лебедя, рака и щуку.

Например, когда я делал экосистему в сфере недвижимости, у нас кроме продажи квартир, были еще и продажи мебели, ремонта и различных услуг. К нам пришли продаваны другой компании и предложили интегрировать их быстрые кредиты в мой продукт. Я посчитал - эта штука дала бы неплохой краткосрочный буст нашим юзерам потому, что при покупке квартиры в ипотеку у них часто сходу нет денег на мебель. Но моя цель была не размениваться на подобные гипотезы, а создать комплексный пользовательский опыт. Быстрые кредиты не помогли бы мне развивать продажу не только квартир, но и домов, участков, дач, складов, машиномест. Не помогли бы в запуске аренды, ипотечного брокера, онлайн сделки и многого другого.

И спустя год-два у меня были бы быстрые кредиты и рост прибыли компании на 10%. Но не было бы захвата ниш на других рынках и роста в несколько раз.

Бывает наоборот. Я работал в одной из дочек Mail.ru и у нас была цель за год заработать как можно больше денег. Без оглядки на стратегию, синергию, долгосрок. Чем больше мы заработали бы, тем больше бы в нас инвестировали денег на следующий год. Мы этот посыл от инвесторов поняли и целились в быстрые доходы. Но подобное отсутствие стратегии тоже можно назвать своеобразной стратегией.

Нужно помнить, что стратегия - это не мотивационная бумажка, которая вдохновляет всю компанию покорять мир. Стратегия должна быть прикладным документом. Который начинается с причин и предпосылок, продолжается идеями и их доказательствами, а заканчивается понятными измеримыми высокоуровневыми задачами с понятными ответственными.

В общем, пока вы не поймете, к чему хотите глобально придти через год-два-три, то будете размениваться по мелочам. Пишите стратегии, реализуйте стратегии, меняйте мир!

Очень важно знать свою аудиторию. Однажды, еще до работы в сфере продукта, я работал в Bookmate. Я тогда был менеджером проектов. И спросил "а какая у нас аудитория?". А мне ответили, что наша аудитория - это все на свете. Что у нас 7 миллионов пользователей и все они разные. Есть дети, которые читают детскую литературу. Есть студенты. Есть пенсионеры. Есть много потребителей церковной литературы. И есть книги, которые читают все от подростков до стариков. Тогда я это воспринял, как должное.

И 5-7 лет спустя я начал работать директором по продукту в маркетплейсе товаров для здоровья. И там я тоже услышал такое же мнение. У нас десятки миллионов пользователей. И болеют, так или иначе, все - от младенцев до самых старых. Но я уже был готов к такому челленджу. Знал, что так не работает. И начал исследовать. Сначала мы с помощью продуктовых аналитиков сделали кластеризацию пользователей по ряду признаков: город, возраст, семейное положение, наличие детей, устройство, браузер и прочее. Потом кластеризовали их сценарии, то есть то, как они пользуются сервисом. У разных сегментов были разные сценарии. Мужчины из регионов в возрасте 25-34 года заходили через браузер на андроиде, искали 1-2 товара, клали в корзину и оформляли. Низкий средний чек, минимум кликов. Более возрастные делали примерно то же самое, только шагов было больше: они еще часто смотрели аналоги, чтобы найти цену пониже. А молодые матери сидели, в основном, с десктопа на Windows. Им так удобнее было видеть всю картину целиком: и рекомендации по применению, и противопоказания, и оценки/комментарии. Они делали вдумчивый выбор, ведь на них огромная ответственность - за здоровье ребенка.

Потом мы на основе этих данных провели большое исследование. Уточнили сегменты. Уточнили их сценарии. Уточнили их потребности. И очень хорошо поняли, для каких людей мы делаем продукт и какие проблемы решаем. И самое важное, в каком контексте находятся эти сегменты. В какой ситуации они покупают: когда хотят дешевле или когда хотят, чтобы все было в одном месте. Когда им срочно и плевать на цену, а когда они готовы подождать и сэкономить. Когда они закупаются при первых признаках болезни, а когда закупаются впрок. С какими проблемами сталкиваются, и чего им не хватает.

Мы осознали, кто наш клиент и что он хочет. Из-за чего он готов приходить к нам снова и снова. Мы осознали наше УТП (уникальное торговое предложение) и добавочную ценность. Мы начали таргетированно давать это в коммуникации, сделали ребрендинг и редизайн, начали подстраивать продукт под потребности целевых сегментов.

А потом подумали о тех, кто не охвачен. Слабо представленный, но сильно нуждающийся сегмент - это пенсионеры. Им тяжело работать с сайтами и приложениями, это не их паттерн. И для них я смог запустить отдельный канал - телефонный. Весь контакт центр мы переориентировали с ответов на продажу. Поменяли их KPI. Научили их помогать пользователям совершить покупку.

Если вам кто-то говорит, что у вас настолько разнообразная аудитория, что нельзя выделить сегменты, сценарии или ценностное предложение, знайте - это чушь. Если не знать и не ориентироваться на все это, вы будете делать продукт в отрыве от реальности и он будет работать неэффективно.

Не зря в скраме все ориентировано на bottom-up. Именно этот подход позволяет эффективно масштабировать цифровую часть бизнеса. Не зря атомарной частью является команда, а не сотрудник. У команды - ответственность и все инструменты. Команда проактивна. У нее есть бизнесовые KPI/OKR (а как иначе? ведь команды существуют, чтобы развивать бизнес). Разработка может и должна спрашивать у продакта, почему именно такие приоритеты: ведь они заинтересованы делать то, что поднимет их целевые метрики. У них на это должна быть завязана мотивация.

Но весь этот проактивный подход невозможен, если у вас нет сработавшейся команды, которая полностью находится в контексте.

Скрам говорит, что все команды между собой равны. Что команда, которая больше влияет на бизнес, не может быть приоритетней той, которая занимается поддержкой. Иначе постоянно при каких-то блокирующих факторах из менее влияющих на бизнес команд будут аллоцироваться люди в команды, которые на этот бизнес влияют в большей степени в данный момент. И в разное время это разные команды. Сейчас это может быть команда корзины потому, что там самые большие просадки конверсии. Через месяц это будет команда главной страницы потому, что она запускает новый продукт - акции. Потом это будет доставка потому, что внедряются новые способы.

И все это приведет к одному и тому же: люди будут болтаться туда-сюда. Толком не мотивированные на среднесрочные и долгосрочные результаты. Не будут понимать весь контекст команды, в которой оказались. Коллектив не будет спаянным и ответственным.

Команды должны быть фиксированные. Разумно 1-2 человек в команде ротировать раз в квартал. Так растет экспертиза, так снижается bus factor. Но это именно ротация, а не аллокация ресурсов.

То же самое касается и ресурсов, которые в других отделах. Например, если у вас в команде продакт, аналитики, разработчики, тестеры и девопс, а исследователи и дизайнеры - это товарищи из отдельного отдела, которые приходят по запросу, у вас проблемы. Потому, что они могут разрываться между несколькими направлениями. Им сложно коммититься на результат, переключаться между контекстами, чувствовать на себе ответственность сразу за несколько направлений. И, самое критичное - погружение в специфику команды. Когда оно не глубокое по 8 часов в день, больше времени тратится на задачи и результаты менее полезные тк сотрудник не понимает всех нюансов того, что делает.

Продакт постоянно организовывает исследования, постоянно синхронизируется с топами и другими командами по стратегии, метрикам, синергии. Смотрит рынок, отчеты. Продумывает вижн. И делится всем этим с командой. Они уже хорошо понимают пользователя, понимают, какую ценность нужно ему доставлять и как. Но, в тот же момент, дизайнер вообще в этом ничего не понимает и просто приходит то в одну команду, то в другую, чтобы порисовать картинки. Конечно, толку от такой работы очень мало.

Проблема 10: нет корректного каскадирования метрик

Мы уже говорили о проблемах, когда все подразделения похожи на персонажей басни крылова и тянут воз в разные стороны.

Можно представить стройку. Если каждый из строителей будет делать то, что кажется ему верным в данный момент времени, не согласовывая деятельность с остальными, дом построен не будет. Или будет, но очень поздно. Или не поздно, но не такой, как должен быть.

И с бизнесом так же. Любой бизнес стремится зарабатывать деньги. Но и это происходит по-разному. Кому-то важно кратно расти, кто-то хочет расти пусть и не кратно, но зато, чтобы операционная прибыль была положительной. Кто-то хочет расти, расширяя присутствие на рынке страны, а кто-то уже готов охватывать зарубежные. А кто-то хочет не зарабатывать много или окупаться, а нарастить клиентскую базу (особенно это может быть характерно для B2B). А потом этой базе продавать дополнительные услуги. И лучше пакетами или подписками.

Поэтому основной метрикой, конечно же, может быть доход. Но этот доход должен быть благодаря чему-то. Должна быть стратегия. Должна быть финмодель. И главную метрику (например, количество клиентов) вы должны уметь раскладывать на дочерние. Конверсия воронки. У разных этапов - разные ответственные. Например, начинаться она может с продажников, за ее середину отвечают продакты, а ее завершение приходится на логистику. Ваша клиентская база должна прирастать сильнее, чем происходит отток. Кроме воронки конверсий и оттока, могут быть ARPPU и доп продажи каждому клиенту. У них может быть определенная частотность.

В общем, чтобы развиваться по плану, мало написать стратегию. Нужно корректно эту стратегию каскадировать на все подразделения компании. И они должны вместе работать на единую цель.

Если есть KPI - это уже хорошо. По крайней мере, они могут понимать цифры, которых нужно достичь. Если есть OKR - лучше. Там каскадирование более осознанное и у сотрудников больше контекста. Помните, что OKR - система, которая не должна быть завязана на премирование. Вся философия OKR заключается в мотивации на достижение сверхрезультатов. Когда самая невероятная эффективность берется за 100% и при этом закрыть OKR на 70% считается крутым показателем. Но как только мы привязываем к этому премии, каждый свой показатель хочет занизить, чтобы с большей вероятностью получить премию. И тогда люди стремятся не в космос, а к очень приземленным целям.

Каскадируйте метрики, делайте это правильно (чтобы отделы и сотрудники работали на основную метрику) и правильно мотивируйте людей.

Синхронизация должна быть на всех уровнях.

Топ-менеджеры - это не просто набор людей с крутой экспертизой, каждый из которых драйвит свое направление. В первую очередь линейка C-level должна быть командой. Потому, что они единственные в компании люди, у которых есть все инструменты, чтобы принять любое решение и воплотить его в жизнь. У них отличный вижн и они должны часто общаться. Делиться планами, работать над процессами, думать над стратегией.

Дальше у нас идут отделы. Например, продукт регулярно должен синхронизироваться с маркетингом. Маркетинг должен уметь рассказывать клиентам про то, что делает продукт. Продукт получает много информации и должен делиться ей с маркетингом: про клиентов и особенности их поведения, про восприятие продукта и так далее. Кроме того, у них есть совместные задачи. Это может быть что-то глобальное, вроде редизайна, или что-то маленькое вроде лендингов. Но кроме операционных активностей, продукт должен понимать стратегию маркетинга и наоборот. Иначе сразу появится асинхрон в работе. То есть, важное, чтобы каждое подразделение, во-первых, имело стратегию и ее прикладное отражение в виде годового и квартальных роадмапов/целей, а во-вторых, рассказывало о нем другим направлениям.

Если же разбирать одно направление (например, продукт), то им внутри тоже надо уметь выстраивать коммуникации. Часто может быть, что несколько команд решают одну и ту же проблему. Например, сразу в нескольких продуктах происходит один и тот же процесс сбора обратной связи после покупки товара или услуги. Хорошо бы такие вещи делать одинаково и один раз, а не несколько раз.

Кроме того, команды должны делиться друг с другом информацией: итогами исследований, аналитикой данных и прочим. Кто-то возьмет себе на вооружение интересные поинты про клиентов, а кто-то возьмет на вооружение интересные процессы. Последние несколько лет я стараюсь организовывать для продуктовых команд внутренние питчинги, на которые они приходят и делятся своими планами. Показывают расчеты метрик, макеты и прочее. Собирают обратную связь, идеи и критику. Это и продакту полезно: он сделает продукт более крутым, и другим командам: они увидят чужие кейсы и это улучшит их опыт.

Особенно критично это в больших компаниях. Где разные продукты - это часть единого сервиса (например, команда поиска, команда личного кабинета, команда чекаута), либо где продукты поддерживают один процесс (например, CRM продавца товаров и CRM продавца услуг).

И в какой-то момент вам для внедрения ваших гипотез становятся нужны соседние команды: от кого-то получить данные, а кто-то должен у себя отобразить вашу фичу. И часто у других команд нет на это мотивации: у них свои процессы и свои целевые метрики. Или очень много входящих задач от других продуктов и они тонут в этих запросах.

Есть множество решений этой проблемы. Очень многие завязаны на информационной архитектуре. Если у вас микросервисы и нет зоопарка технологий, то команда А может сама писать код в репозиторий команды B. А те его ревьюят, деплоят и берут в поддержку.

Но большая часть решений так или иначе связана с бизнес-процессами. Например, сделать архитектурную модель данных на изолированных плагинах бизнес-процессов, а общие объединить в команду, которая занимается этим интерфейсом. И вот у вас уже не продакты поиска, карточки товара и корзины, а продакты товара, атрибутов, аналогов и отзывов. Конечно же, при этом важно, чтобы были ответственные и за метрики каждого шага воронки.

Или другой способ, который у меня был на практике: сначала я нанизал 15 команд на 3 "шампура" основных процессов клиентов, а потом часть каждой команды закрепил за соседними продуктами. То есть у нас есть, например, команды А, Б, В. В каждой по 10 разработчиков. Но на продакта А работает только 8 его разработчиков, а по 1 разработчику из команды А взяли себе продакты Б и В, но они им только ставят задачи. Все остальное (процессы и тп) остались, как есть в команде А. При этом продакту А досталось по 1 человеку из команд Б и В. Таким образом, у каждого из них суммарно по 10 человек, но нет необходимости ждать, пока кто-то возьмется за их задачи в соседней команде: они априори имеют там по 1 человеку.

Пожалуй, я объяснил немного сложно и путанно, но суть простая: кросс-командные зависимости (когда первая команда ждет, пока вторая сделает критичную функциональность для первой) - это плохо. Долго и неэффективно. Надо убирать такие зависимости и на это есть много способов. Ищите тот, который лучше всего подойдет именно вам.

Собственно, все мы хотим динамично развивать бизнес. Можно сколько угодно говорить о важности этого, но весь прикладной смысл в том, чтобы у команд были задачи, которые обеспечивают это развитие.

И нужно уметь их брать из многих источников.

Например:

Гипотез должно быть очень много, все они должны иметь оценку и четкую приоритизацию. То есть, в реализацию должны уходить те, которые в данный момент времени дадут компании максимальную ценность.

Давайте представим ситуацию: нам нужно сделать так, чтобы на экран выводился некий отчет. Без разницы, это для покупателя-физика, для клиента-юрлица или для сотрудника компании.

И в парадигме проектного подхода пишется техническое задание, частью которого являются функциональные требования. И там просто будет описано: выводить отчет, в этом отчете такие-то столбцы и такие-то строки и в ячейках такие-то данные. И дизайнер просто рисует некую табличку.

А в парадигме продуктового подхода пишутся User Stories или Job Stories, очень важными частями которых выступают цель и контекст. Указывается метрика, которая должна расти благодаря отчету. И мы обозначаем, какие выводы должен сделать пользователь, на что обратить внимание, какие могут быть развилки его сценария. И тут дизайнер тоже рисует табличку. Но в ней он уже может подсветить что-то, помочь пользователю сделать вывод. Какие-то данные могут быть выделены жирным. Или ячейки могут быть залиты красным/зеленым. Или могут появиться дополнительные опции, которые рождаются благодаря дополнительным сценариям. То есть, интерфейс становится полезным и помогает пользователю.

Например, если у нас это табличка с показателями сотрудников, которую смотрит их руководитель, интерфейс может ему не только обозначить, что у подчиненных какие-то навыки проседают, но и направить кого-то на профильное обучение, чтобы те самые навыки подтянуть.

Итого: ТЗ и ФТ не помогают понять задачи пользователя. А более богатые данные помогут делать продукт, который будет более удобен в использовании и поможет лучше сделать выбор и сконвертиться в целевое действие.

Более подробно (с примерами и шаблонами) это описано в моем канале тут.

Один из принципов Agile - Работающий продукт важнее исчерпывающей документации. К нему часто аппелируют, когда документацию не хотят писать вообще. Это неверно. Этот принцип про то, что какие бы у вас крутые документы ни были, если не разработан продукт, который нашел свой fit (нишу, удовлетворение потребностей рынка), то смысла в таких документах нет.

Документация должна быть. Но она должна быть полезной. Она решает несколько проблем:

Для описания эпиков существует такой формат, как PRD. Он существует в передовых западных компаниях (Google, facebook и тд). У каждого они немного отличаются, но процентов на 70-80 совпадают. Вы можете подобрать что-то свое. Главное, чтобы у исполнителей была самая полноценная информация.

Вариант, который я обкатал на нескольких компаниях, лежит вот тут. Пользуйтесь моим или делайте свой. Главное, чтобы была четкая и понятная документация, от которой отталкивается каждая команда.

Каждая команда должна становиться все более и более эффективной. Не зря мы в продуктовой парадигме стараемся делать релизы как можно чаще. И это развитие эффективности должно быть постоянным.

Но чтобы оно было, нужно начать его измерять.

Time to Market (t2m) - это метрика, которая показывает среднее время реализации задачи от начала работы над ней до полного релиза. Это значит, что при сокращении этого времени у нас будут более быстрые релизы (или за то же время между релизами мы сможем выкатывать больше гипотез на проверку). Значит, цена ошибки будет меньше.

Есть отдельная часть t2m, которая называется cycle time. Она измеряет время только delivery, то есть от начала разработки до релиза. То есть, часть t2m, которая касается только разработчиков, тестеров и девопсов.

Конечно же, в скраме есть множество метрик, которые помогают командам быть лучше. Например, focus factor - это отношение всех задач в спринте к тем, которые были там с самого начала. То есть, чем больше задач попало в спринт во время самого спринта, тем хуже. Значит, плохо планируемся. focus factor ниже 70% - показатель больших проблем в планировании.

Надо не забывать про цели спринта. Цель спринта должна быть одна (в идеале), должна ставиться по SMART и итогом спринта должен быть инкремент, который мы релизим и проверяем.

А еще все любят переходить на стори-поинты. Ведь скрам это рекомендует. Но при этом в работе команды ничего не меняется. А ведь стори-поинты - это первый инструмент в том, чтобы измерять эффективность работы команд. В человеко-часах это делать нельзя. Их всегда 40 на человека в неделю. А стори-поинты показывают сложность задачи. И динамика сгорания стори-поинтов в спринт показывает, что команда в одном спринте сожгла 30, в другом 35, а в следующем 42, то есть, эффективность улучшилась.

Вообще про метрики эффективности команды можно писать отдельную огромную статью и про это даже есть книги. Но самое важное из этих метрик - измерять time to market и улучшать его.

Улучшается он следующим образом: вы сначала раскладываете задачу на статусы (например, дизайн, исследования, разработка и тд). И указываете среднее время, которое задачи задерживаются на каждом этапе. И каждый этап можно ускорить, для этого нужно выписать идеи, как это сделать (обычно этим занимаются команды на ретроспективах). Нужно понять, что даст больший эффект. То есть, какие изменения наиболее простые и при этом позволят экономить много времени. Назначить ответственных за изменение и дедлайн. Например, договориться, что к следующей ретроспективе будет упрощен процесс каких-либо согласований.

Приведу 2 примера из моей практики.

В одной компании у нас был большой этап багфиксинга. Причем багфикс проходил в несколько итераций. Это было из-за низкого качества кода (немалая доля задач возвращалась тестерами в доработку разработчикам). Это происходило потому, что тестеры не могли сразу проверить весь код: они часто блокировались на старте сценария. Например, на этапе авторизации или поиска крашилось приложение. Мы договорились, что у нас появятся простенькие тест-кейсы от тестировщиков, чтобы разработчики могли самые простые, понятные и критические баги найти на своем этапе.

Таким образом, время разработки до передачи в тестирование выросло: ведь разрабам приходилось дополнительно проходиться по упрощенному чеклисту тестирования. Но время, которое уходит на фикс багов, сократилось в 5-6 раз. Это была большая победа.

Второй пример был в компании, в которой очень важно было участие юристов и бухгалтеров. Команды реализовывали продукт, который сильно регулируется законодательством. Поэтому все свои решения нужно было описывать, отправлять юристам и бухгалтерам, те их пару дней проверяли, давали обратную связь. Команды вносили правки и отправляли снова на ревью. И так 2-3 раза.

К чему мы пришли: мы договорились, что юристы и бухгалтеры будут ходить на планирования, стендапы и груминги. Они стали в 2 раза больше времени тратить на работу с командами (то есть, часа 4 в неделю вместо 2), зато мы примерно неделю начали экономить на этапе согласований. Нам даже не приходилось писать документацию, чтобы получить обратную связь: юристы и бухгалтеры комментировали идеи командой голосом: тут так можно, так нельзя, тут может быть штраф, но давайте рискнем.

Многие метрики работы команды важны. Но самая важная из них - это Time to Market.

Продакты при подготовке стратегии и роадмапов предполагают реализовать гипотезы, которые вырастят метрики на прогнозируемое ими значение. A/B-тест проводится, показывает, как себя чувствует продукт после релиза на долю аудитории, принимается решение об отказе, релизе на 100% или отправке в доработку.

Но при этом важно не забывать сравнивать прогнозное значение с фактическим (post mortem анализ). Нужно понимать, почему метрика не выросла так сильно, как должна была: это поможет лучше понимать пользователей и в будущем прогнозировать более точно.

Если же у какой-то команды регулярный недобор по значениям, значит, они оценивают неправильно или намеренно завышают оценки. Нужно уделить им внимание, помочь разобраться прогнозировать более корректно.

Итого, без работы над ошибками не поймете, где в процессе вы допустили неточность.

Часто бывает, что прибегает супербольшой босс и просит срочно сделать какую-то задачу. Говорит, что она сейчас самая важная. А то и несколько боссов прибегает. Задачи (а для них это задачи, а не гипотезы) не должны браться в работу без очереди просто потому, что их интересант обладает большим влиянием.

Команда работает на цель - рост определенной метрики. И каждая гипотеза, которая идет в работу, должна эту метрику растить.

Да и параметров у гипотезы много:

И со всеми этими параметрами надо работать. Для их учета и были придуманы различные методологии. Есть RICE, которая, в целом, проще, чем ICE, но при этом имеет ограничения - работает с ростом только одной метрики у одного сегмента аудитории. И есть ICE, которая более творческая, предполагает больше расчетов и при этом более гибкая. Чуть более подробно я разобрал в этом посте в телеграм.

Каждый параметр имеет свою оценку от 1 до 10. И перемножая их, вы получаете итоговый скорринговый балл, который зависит от охваченной аудитории, изменения метрики, уверенности в гипотезе и сложности реализации.

При их реализации может иметь место некая спекуляция, когда кто-то из продактов ленится или не обладает нужными знаниями. Всегда есть соблазн не идти считать математику на текущей модели продукта, а сказать "ну, по моим ощущениям, влияние гипотезы где-то на шестерочку". Такого быть не должно. Каждая оценка должна иметь под собой основания.

И даже уверенность в гипотезе. Не должно быть абстрактной "уверен наполовину, значит, ставлю 5 из 10". Даже у уверенности есть четкие индикаторы и они прописываются в модели оценки.

Таким образом, если к продакту прибегает бигбосс с языком на плече и, брызжа слюной, заставляет сделать супер-пупер важную штуку, продакт идет ее оценивать и ставит на свое место в порядке приоритетов. И бизнес развивается органично. На основе расчетов и данных, а не от чьего-то весомого мнения.

Разумеется, есть нюансы. С теми самыми бигбоссами лучше работать как с партнерами. Как правило, у них огромная экспертиза. Их тоже можно привлечь на оценку гипотезы. И если она далеко не на 1 месте, всегда можно сделать что-то, чтобы ее поднять выше. Править цифры, чтобы приподнять гипотезу - нельзя (в стиле а давай 5 поменяем на 6, она вверх и поднимется). Это неправильно и ломает всю концепцию непредвзятой приоритизации. Самое простое - это повлиять на оценку разработки. Придумать план, как проверить гипотезу, сделав более простую реализацию, а затем, при необходимости, развивать функциональность. Еще просто поднять уверенность в гипотезе. Ее просто нужно отдать на исследование. Тогда уверенность с 0,5 может измениться на 6, а то и 7. Тогда итоговый скорринговый балл может очень прилично вырасти.

Второй нюанс - у CEO всегда есть право вето. Потому, что CEO - это верхнеуровневый дядечка (или тетечка), который имеет очень хороший вижн, а еще знает много вещей, которые не знают продакты. И он вне очереди может вставлять задачи или наоборот, убирать из беклога.

Но на моей памяти такого не было. Отношения с CEO и с другими директорами на этапе защиты роадмапа всегда партнерские. И, честно говоря, я и продакты всегда по одному вылавливаем всех глав департаментов и показываем им стратегии/роадмапы, чтобы собрать обратную связь. И уже потом вносим правки, а затем собираем их на большую встречу, которая чаще является больше формальностью потому, что все задачи уже так или иначе всеми одобрены.

Но, в любом случае, какую бы методологию вы ни выбрали, приоритеты команд в вашей компании должны быть четко измеряемые и каждая гипотеза должна быть обоснована цифрами.

Нельзя жить в парадигме задач. Задача - это то, что нужно сделать в определенный срок и с определенным качеством.

Гипотезы всегда показывают, что мы предполагаем. И результат реализации гипотезы - это не галочка "а мы все в срок сделали", а рост метрики. Желательно до прогнозного значения или выше.

Гипотеза потому и гипотеза, что еще нужно доказать ее полезность. В то время, как задача выглядит какой-то непреложной сущностью.

Поэтому каждая гипотеза должна быть описана по шаблону : для кого мы какое изменение делаем, как это повлияет на метрики и как мы это проверим.

Например: я верю, что добавление чата в сервис повысит конверсию в покупку на 0,5% потому, что у пользователей появится более удобный им канал выяснения вопросов по товарам. Чтобы проверить это, мы реализуем чат, раскатаем его на 5% аудитории и в течение 2 недель будем держать A/B-тест.

Гипотезу нужно пытаться проверять как можно раньше. Особенно, если она комплексная. То есть, ее реализация состоит из нескольких этапов. Поэтому, после первого этапа проверки, мы можем понять, что она вовсе не растит метрики и развивать это направление смысла нет. Тогда мы от нее отказываемся и приступаем к следующей.

Живой пример - однажды мой продакт в маркетплейсе здоровья (где подавляющая доля товаров - это лекарства) хотел реализовать гипотезу, которая позволит проверить, как влияет отображение кол-ва купленных товаров всеми пользователи за последний месяц на уверенность в покупке.

Кажется абсолютно логичным. Если у пользователя есть сомнения между товарами А и Б, то он смотрит, что товар А купили 4000 раз, а товар Б купили 2 раза. Значит, многие пользователи по каким-то причинам выбрали товар А. Пользователь становится более уверен в своем выборе и лучше конвертируется в заказ. Кстати, о том, как пользователь делает выбор при покупке - читайте в этой статье.

Но реализация такой гипотезы заняла бы целый спринт. Сначала разработка, потом тестирование, потом багфиксинг, потом мердж веток репозитория, деплой. Если не выстрелит - 2 недели в трубу. И что же сделала команда? Они за 10 минут на фронте (без интеграции с бекендом) написали рандомизатор, который указывает случайные значения в поле количества покупок за последний месяц. Выкатили это на 5% и за пару дней поняли, что на конверсию нет ни малейшего влияния. Конкретно в сфере товаров для здоровья люди больше расчитывают на собственный опыт, рекомендацию врача и, возможно, цену или производителя. Так команда потратила 10-15 минут вместо двух недель, чтобы отстрелить бесперспективную гипотезу. А если она была бы задачей, то вы понимаете, что бы было. Ее бы делали 2 недели, отправили бы на продакшн. Так она еще и замусоривала бы интерфейс, который визуально стал бы чуть сложнее.

А бывает наоборот, гипотеза простая и маленькая, мы ее выкатываем и получаем инсайты о том, как можно ее чуть усложнить и это окажется еще более полезным бизнесу. Тогда мы ее дорабатываем.

А бывает, что мы к приоритетной гипотезе даже не приступим потому, что рынок поменялся и она перестала быть приоритетной.

Поэтому роадмап продукта - сущность приблизительная. По ходу работы команды постоянно появляются инсайты о продукте, пользователях, конкурентах, рынке. Сам рынок колеблется и меняются цены и условия. Умение подстроить роадмап гипотез под актуальные условия - это и есть гибкость. Конечно, он не должен меняться раз в пару недель. Это укажет на его плохую проработку. Но пару раз в квартал - вполне возможно.

И я напомню, что когда мы планируемый роадмап сделали полностью и четко в срок - это не бизнес-результат. Бизнес-результат, когда мы вырастили целевую метрику на заданное значение. А с помощью первоначального роадмапа или пару раз актуализированного - это уже не такие важные нюансы.

Мы уже говорили о том, что у вас должны быть сегменты пользователей. Но сегмент, который говорит, что у основной группы пользователей есть диапазон возрастов, пол, город и прочее, прочее, не означает, что вам этих входных данных будет достаточно, чтобы делать продукт, который ориентирован на пользователя.

Вам четко нужно знать его контекст, потребности, сценарии, драйверы и стоп-факторы. К чему он стремится и какие у него есть когнитивные искажения.

Все портреты пользователей должны быть выписаны (например, в конфлюенс) и на них должны быть ссылки в каждой задаче на дизайн и разработку.

Это развивает у команды эмпатию. Они делают решения, которые удовлетворяют сценариям клиента, помогают достичь его целей и не вызывают сложностей.

То есть, если у вас есть сегменты, вы должны все про них выяснить и донести до команды.

Любопытный факт. Есть ситуации, когда описание портрета пользователя невозможно или его еще нельзя собрать. Я изучал это в теории, но на практике никогда с таким не сталкивался.

Приведу два каноничных примера из статей и учебников.

Первый случай - это запуск стартапа. Вы еще не обладаете достаточной базой данных, чтобы делать вывод о своих клиентах и их поведении.

По факту, когда я запускал один стартап (точнее, был кофаундером и выступал в роли CPO), я опирался только на U&A ресерч. Мы нашли возможность получить большую базу данных потенциальных клиентов и запустили на них количественный опрос, по итогам которого смогли их просегментировать. А потом связались с характерными представителями уже понятной целевой аудитории и провели с ними интервью, составив понятный портрет.

Второй случай - Инстагам. Обычно именно его приводят в качестве примера. Говорят, что там очень разношерстная аудитория. В один и тот же момент времени публикацию делает мать-одиночка 40 лет из Африки, у которой трое детей и довольно низкая зарплата и китайский подросток 15 лет из обеспеченной семьи. Дальше добавляют, что они совершенно разные люди, но у них одна цель - сделать публикацию.

Этот кейс часто приводится как вводный к методологии JTBD (jobs to be done или работы, которые должны быть выполнены), которая рассказывает, что можно не ориентироваться на портреты пользователей, а на их сценарии. А точнее, "работы", на которые они "нанимают" продукт.

Вообще, как методика описательной части и генерации идей для обвязки продукта, JTBD - прекрасная методология, которой я часто пользуюсь. Потому, что ее ядро - это контекст пользователя, что очень важно в разработке продукта.

Но, если заглянуть чуть глубже, можно выяснить, что цель у матери-одиночки из Африки и у китайского подростка, действительно, одна: сделать публикацию. Но мотивация для этого совершенно разная. Китайскому подростку в этом возрасте очень важно окружение, социальные связи и его ощущение себя в обществе. Особенно, в семьях с доходом выше среднего часто приходится держать марку, то есть иметь одежду и аксессуары люксового уровня и иметь репутацию. Поэтому его соцсети - это инструмент получения общественного одобрения и закрепление своего образа.

А у матери-одиночки из Африки может быть совершенно другая мотивация. Она может хотеть найти себе мужчину. Она может хотеть не терять связь с семьей и друзьями, держать их в курсе новостей и знать, что у них происходит. Она может хотеть быть примером для детей. А может искать поддержки или вдохновения.

И есть много других сегментов - дети, блоггеры, художники или музыканты и так далее.

То есть, нельзя спорить с тем, что у максимально разношерстной публики Инстаграм одна цель - сделать публикацию. Но при этом (мое личное мнение), мотивация делать эти публикации у них разная.

Таким образом, и в случае стартапа, который еще не запустился, и в случае, когда аудитория очень большая и смешанная, все равно можно выделить сегменты, у которых разный опыт, мотивация, контекст, сценарии и инструменты.

Если у вас не описаны портреты пользователей или они не используются в каждой задаче - у вас есть потенциал для улучшения эффективности процессов.

Описание двадцать первой проблемы вызывает у меня хищную усмешку. Наконец-то у меня дошли руки развенчать мифы, о которые спотыкается 9 компаний из 10.

Кажется абсолютно логичным иметь таких аналитиков в штате. Есть бизнес-анализ (это когда мы разбираем, какие есть процессы, какие в них проблемы, какие обязательные шаги и тд и тп. А может быть, еще и делаем SWOT анализ конкурентов). И есть системный анализ (это когда у нас есть макеты и понятные шаги, кто-то расписывает для разработчиков, откуда брать данные, как их обрабатывать и что с ними делать дальше).

Но, удивительный факт, все это должен уметь делать мало-мальски опытный продакт менеджер.

Пойти узнать у различных бизнесов или пользователей об их процессах, сформировать BPMN, построить service blueprint, написать документацию или сделать постановку на дизайнера - это все то, что продакт умеет и обязан делать. Бизнес-аналитик тут не нужен.

Нанимал ли их я? Да, и первое время для меня это было удивительно. Ко мне приходили продакты и просили взять человека, который будет делать за них эту работу. Я стал задавать логичные вопросы - а вы мне тогда зачем, если бизнес-анализ будет делать отдельный человек? Давайте я его тогда найму, а вас уволю?

И после этого выяснилась любопытная деталь. Ребята это просят не из-за лени, а потому, что перегружены. Цели команд становятся все амбициознее, для покрытия этих целей нужно все больше ресурсов и вот ты не успеваешь моргнуть глазом, как у тебя 15 команд по 20 человек в каждой. Понятное дело, когда их 6-7 человек, очень просто прорабатывать задачи для такой небольшой команды. А с 20 ты уже захлебываешься и тебе нужен аналитик, чтобы выполнить первую часть твоей фазы Discovery.

То есть, продакты и компании хотят делить этот процесс последовательно. Первоначальный кусочек - бизнес-аналитик, а остальной кусочек подготовки гипотезы для разработки - менеджер продукта.

А на самом деле его надо делить параллельно. То есть, взять и вашу команду из 20 человек поделить напополам. И во вторую команду поставить продакта. Тогда у каждого продакта будет и время на эти задачи, и результат будет крутой благодаря высокой и комплексной квалификации.

И в этот момент CEO задумается - а зачем мне брать еще 15 продактов и делить количество команд на 2, когда я могу взять 15 бизнес-аналитиков для текущих 15 продактов, не делить команды, да еще и сэкономлю пару миллионов? И это кажется логичным, ведь бизнес-аналитик стоит в 2-3 раза дешевле продакта. Но и глубина, и польза его работы в 2-3 раза ниже. Сегодня мы сэкономили пару миллионов, а завтра из-за этого недозаработаем пару миллиардов.

Теперь перейдем к системным аналитикам.

Взять макеты и спецификации и написать код - это тоже могут и должны делать разработчики. Конечно, им может понадобиться какой-то ресерч. Полезть в описание API или в схемы технической архитектуры. Но при этом они эту работу сделают сами.

Представьте 2 параллельных вселенных.

В первой системный аналитик с зарплатой в 100 тысяч рублей продумывает техническую реализацию и передает задачу в команду из 6 разработчиков, каждый из которых получает 350 тысяч рублей. И все, что делают разработчики - это переводят русский язык из документа в язык программирования. Все детали уже определены системным аналитиком, который стоит в несколько раз дешевле.

А в другой вселенной команда разработчиков получает макеты, спецификации интерфейсов и бизнес-цель. Они сами принимают решение, что делать: писать ли новый микросервис, как балансировать нагрузку, как обрабатывать данные, чтобы их целевой клиент смог выполнить свой сценарий. Решают, как это сделать, чтобы вырастить целевую метрику команды. То есть, высококлассные специалисты сами принимают технические решения.

Конечно же, выглядит, что во вселенной без системного аналитика продукт получается лучше. Потому, что команда погружена в цель и контекст и сама принимает решение. Часто - во время брейнштормов и груминга.

Вот и получается, что если у вас есть системные или бизнес аналитики, то без них вам, скорее всего, в моменте обойтись не получится. То есть, они нужны, но указывают на большие процессные и ресурсные проблемы. Меняйте их на продактов и замеряйте рост эффективности - он точно будет.

Обратите внимание, что я писал только про бизнес и системных аналитиков. Продуктовые аналитики были и остаются очень важными фигурами в каждой продуктовой команде.

Этот пункт получится коротким. Проектные менеджеры, как и системные аналитики, перекочевали к нам из проектной парадигмы.

Это люди, которые тратят время на то, чтобы описать и поставить задачи разработчикам. Хотя описание целей пользователя и бизнес-процессов делается раньше и так даже лучше передавать задачу в разработку.

Еще проектный менеджер двигает статусы задачек в таск-трекере, спрашивает у разработки, сколько процентов они сделали и сколько осталось. Хотя разработчики сами вполне могут подвигать эти задачки и скооридинироваться на дейли митингах по своему прогрессу.

Опять же, когда к вам приходит задача от менеджера проекта, когда в ней есть описание и когда он за вас ее сам декомпозирует - на вас ответственность только за реализацию в срок. Ведь процесс обеспечивает кто-то другой.

А в продуктовой парадигме весь коммитмент разработчика покрыть цель спринта (то есть, бизнес-цель), он сам за это отвечает и уж точно может декомпозировать задачу и пододвинуть ее статус в Jira.

Скорее всего, проджект менеджер работает в паре с продактом в большой команде. И если ее поделить, опять же, проджект станет не нужен, как и бизнес-аналитик.

Если команда не разбирает свою работу, то процессы не будут улучшаться. Если никто не трекает операционные метрики и не собирает брейнштормы, то ничего не изменится.

Ретроспектива может быть в свободном формате в стиле "какие есть проблемы, что напрягает?". А может ориентироваться на показатели. Например, команда не смогла достичь цели спринта. нужно собраться и обсудить причины. Time to Market слишком большой на этапе раскатки в продакшн или большая доля откаченных обратно релизов - тоже нужно обсуждать не ретроспективе.

Голосовать за критичность проблем, обсуждать их, договариваться о решениях, ответственных и сроках. И смотреть на следующем ретро, порешались ли эти проблемы.

Стремление к росту эффективности операционных процессов должно быть постоянным. Так бизнес будет разиваться более динамично.

Не все компании описанные проблемы смогут решить. Где-то заморожен бюджет на найм или количество позиций. Где-то пока сотрудники морально не готовы. Где-то что-то пробовали, возможно, неправильно, но не зашло и снова никто не захочет начинать (так часто бывает, например, с внедрением OKR).

Главное эти проблемы понимать и иметь их план по их разрешению. А если они никогда не будут решены, то, как минимум, потому, что это невозможно, а не потому, что вы о них не догадывались или забили на них.

Статья вышла на 56 тысяч символов. Очень интересно, дочитал ли кто-то до конца? Если да, ставьте плюсики в комментарии, посчитаем, сколько нас.

И подписывайтесь на мой канал в телеграм, там еще интереснее - https://t.me/aroundproduct