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

Статья предназначена для начинающих IT-предпринимателей и SPM (software project/product manager). Если вы успешный предприниматель, но вам не хватает IT-экспертизы, то для вас статья также может быть полезна. Осторожно, лонгрид.

Кейс боли

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

Глядя на опыт товарищей-предпринимателей, которые успешно зарабатывают на заказной разработке с помощью Agile, он находит себе CTO, который берет на себя найм команды и организацию разработки. А сам CEO ищет экспертов из отраслей и начинает с ними генерить идеи стартапов на основе подписных SaaS продуктов. Когда хорошая идея найдена, CTO подбирает команду. Эксперт подключается к работе в роли постановщика задач, команда пилит продукт. CEO нанимает директора по продажам, маркетолога, и вместе с ними ищет клиентов.

Таким образом CEO запускает несколько разных проектов. Внезапно, на один из проектов находится первый клиент - из крупного b2b, приносит сразу в районе 1 млн руб MRR. CEO останавливает остальные проекты, и перебрасывает все силы и всю команду на этот проект, организует для него всю операционку по аккаунтингу и техподдержке. И его нисколько не смущает, что несколько десятков миллионов рублей, потраченных на остановленные проекты выброшено в мусорку. Ведь один из проектов оказался успешным!

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

На клиентов из малого b2b никто внимания особо не обращает - они тихо покупают и пользуются. Всё внимание коллектива CEO направляет на крупных b2b-клиентов, которые приносят больше всего выручки и генерят больше всего хотелок. Доходит до "смешного" - хотелки зашиваются в договор оказания услуг на этапе продажи вместе с дедлайнами и штрафами за их невыполнение. В какой-то момент CEO всерьез начинает задумываться о том, чтобы упаковывать продукт в виде коробочных решений, потому что крупный b2b это просит. Команда недоумевает - мы всё ещё делаем свой SaaS-продукт? Но продолжает пилить, потому что CEO так сказал.

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

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

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

В чем проблема и как её решать?

Мораль этой истории в том, что даже если у вас супер классные delivery-процессы и действительно крутая команда разработки, но при этом у вас проблемы где-то в бизнесовой части, вам это всё не поможет. Я считаю, что профессионализм SPM заключается в первую очередь в том, что он умеет предотвращать неадекватный возврат инвестиций в разработку. SPM-профессионал от SPM-специалиста отличается не наличием большого практического опыта применения модных Agile-фреймворков и/или проектных методологий, а умением понимать реальные потребности бизнеса в разработке, отличать его хотелки от реальных проблем.

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

Бизнес

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

И если одним словом, то бизнес - это деньги, прибыль. Это такая деятельность, в результате которой появляется прибыль, а не убыток. Целью любого бизнеса является прибыль, которая в пределе = выручка минус расходы. Выручка (она же оборот, revenue) - это количество денег, которое бизнес собирает с рынка за определенный период. В самом простом варианте это средний чек за продукт, помноженный на кол-во продаж. Когда мы отнимаем расходы определенного типа из выручки, получается определенный тип прибыли.

Например, есть переменно-прямые расходы (ППР). Они же прямые расходы, расходы по прямым, переменные расходы, варкосты (varcost), себестоимость. Это такие расходы, которые прямо-пропорционально зависят от продаж. Есть продажи - есть ППР. Нет продаж - ППР равны нулю. Для примера, в традиционном бизнесе это сырье, закупочная стоимость. В IT-бизнесе это CAC (цена привлечения платящего клиента), процент продавцу. После вычета ППР образуется валовая прибыль. Она же валовый доход, маржинальный доход (gross margin).

Есть условно-постоянные расходы (УПР). Они же косвенные расходы, операционные расходы, фикскосты (fixcost), опэксы (OpEx). Есть продажи или нет продаж - УПР всё равно есть. Но без них бизнес в принципе не работает, потому что кто-то (что-то) должен делать (обеспечивать, поддерживать) оборот. Обычно это офис, фонд оплаты труда, и т.п. Эти расходы всё же зависят от продаж, но не напрямую, а косвенно. Например, чем больше у вас торговых точек, тем больше нужно персонала. После вычета УПР из валовой прибыли образуется операционная прибыль. Она же EBIT/DA, операционный доход. Ну и дальше вычитаются все остальные расходы, чтобы получить чистую прибыль: кредиты, налоги, сборы, списания, амортизации.

Есть ещё один важный для нас сейчас вид расхода: капитальные затраты. Они же капэксы (CapEx). Они бывают разные. Нас интересует те, которые про основные средства (ОС). Их ещё можно назвать инвестициями в основные средства. Если вы закупите какой нибудь коробочный софт, например, bitrix24, то в бухгалтерии он скорее всего пройдет как закупка основных средств. Если же вы купите тот же bitrix24 в виде подписки, то она пойдет в УПР.

И если все вышеперечисленные расходы бизнес несет для того, чтобы получить соответствующий вид прибыли, то инвестиции в основные средства не предназначены для получения прибыли в моменте. Они нужны для того, чтобы увеличить эффективность бизнеса за счет сокращения УПР. Это очень важно понять. Дело в том, что средний чек, ППР и, соответственно, маржинальность бизнеса целиком и полностью диктуется рынком и поделать с этим ничего нельзя. Можно сделать ресегментацию, сменить рынок, но невозможно изменить маржинальность бизнеса в конкретном сегменте. Как предприниматель, вы можете в существующем продукте/сегменте существенно влиять только на два параметра: УПР и кол-во продаж. Любые успешные усилия по изменению ППР или среднего чека приводят к появлению нового продукта технологически (continuous innovations) или рыночно (discontinuous innovations).

Пример бизнеса на кофе

Если вы не имеете предпринимательского опыта, то это всё может показаться сложным. Поэтому я приведу простой пример. Кофейный автомат, в котором многие из вас когда нибудь покупали горячий вкусный кофе утром по дороге на работу. Давайте представим, что у вас нет кофейного автомата, но вы хотите заработать на продаже свежего кофе. Средний чек - 35 руб, это цена вашего продукта (одного стаканчика кофе). Допустим в сутки покупатели выпивают 40 таких стаканчиков. В месяце 28 рабочих дней, значит месячная выручка с бизнеса на одной точке: 35 * 40 * 28 = 39.2 тыс руб. Себестоимость одного стаканчика кофе - 8 руб 75 коп. Это значит, что с каждой проданной порции кофе вы забираете в виде валовой прибыли 75% (8.75 руб себестоимости поделить на 35 руб цена порции кофе и умножить на 100%). Вроде бы очень крутая маржинальность. Но не спешите с выводами, посмотрите на УПР такой точки.

Аренда - 5.8 тыс руб, прочие УПР (бензин и т.п.) - 1.5 тыс руб, зарплата баристы - 15 тыс руб (кто будет работать за такую ЗП???). Итого УПР точки - 22.3 тыс руб. Операционная прибыль точки: 39.2 тыс руб (месячная выручка) минус 9.8 тыс руб (ППР) минус 22.3 тыс руб (УПР) = 7.1 тыс руб. Операционная доходность точки, её ещё можно назвать рентабельностью, рассчитывается также в процентах, как и маржинальность: 18% (7.1 тыс руб операционной прибыли делить на 39.2 тыс руб выручки и умножить на 100%). Вроде бы всё ещё в пределах нормы для российских реалий. Путем увеличения кол-ва торговых точек, вы можете растить бизнес. Например, с 10 таких точек вы уже будете зарабатывать 71 тыс руб операционной прибыли.

Бизнес-ценность продукта

Но вот вы смотрите на зарплату, с позволения сказать, баристы, который забирает 38% выручки (15 тыс руб ЗП делить на 39.2 тыс руб), не считая всяких соц взносов, НДФЛ и геморроя с текучкой (найм, обучение и т.д.). Что если купить кофейный автомат и сэкономить на зарплате?

Нормальный кофейный автомат стоит 450 тыс руб. Также является продуктом, а с точки зрения бизнеса - основным средством производства, эксплуатируется 5 лет (потом надо покупать новый). Полностью заменяет баристу, то есть снижает УПР. В данном случае сильно снижает. Расчет возврата инвестиций в пределе отвечает на вопрос "Как быстро вернутся вложения в этот автомат?". Делим инвестиции на зарплату баристы и получаем кол-во месяцев: 450/15 = 30 месяцев (2.5 года). Получается, что заменив баристу на автомат, вы повысили рентабельность точки с 18% аж до 56%, но вы её увидите только через 2.5 года, когда инвестиции в автомат полностью вернутся в виде сэкономленной операционной прибыли. Или, как ещё говорят, отобьются за 2.5 года.

Можно рассчитывать и по-другому. Например, расходы на автомат отобьются менее, чем за два года, если распределять на это всю операционную прибыль, а не только ту ее часть, которая раньше уходила на зарплату баристы. Более того, расчеты могут быть неправильные, но давайте не будем придираться. Мы хотим понять сам принцип: при правильном их использовании инвестиции снижают УПР. В случае с разработкой это обычно не приводит к увольнению операционных сотрудников. Инвестиции в разработку позволяют убрать ограничения роста в операционном процессе, открывая возможности масштабирования бизнеса. Есть ещё одна проблема бизнеса, которая решается за счет инвестиций, но об этом чуть позже.

Расходы на разработку

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

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

По моему мнению, это зависит от роли разработчиков в конкретный момент времени. Если они уже запилили продукт, и работают в качестве второй/третьей линии техподдержки, время от времени подчищая баги и архитектуру продукта, то это УПР. Если они находятся в процессе разработки какого-то важного бизнес-заказа, то это инвестиции. Логично и систему вознаграждения построить соответствующую. Например, если продукт в бой пока ещё не выведен (идет разработка первой версии), логично платить только из бюджета конкретного релиза (проекта). Когда продукт уже в бою, то нужно вводить какой-то фикс за его сопровождение и поддержку из соответствующих фондов УПР. Если одновременно и активная разработка релиза (проект) и поддержка продукта в бою, то это одновременно и вознаграждение из бюджета проекта и фикс из фондов УПР.

Резюме по бизнесу

Итак, расходы на разработку - это не переменно-прямые затраты (var cost). Маржинальный доход не увеличится от сокращения расходов в разработку. Если, конечно, вы не продаете аутсорсинг разработки (или проекты). К условно-постоянным затратам (fix cost) её можно отнести только в случае поддержки/сопровождения. Активная же разработка достаточно больших функциональных блоков - это как минимум кап затраты, потому что так вы хотя бы можете снизить налогооблагаемую базу. Но если это просто капэксы, то не совсем понятно как мерить её ценность для бизнеса? Поэтому, в идеале, разработка - это инвестиции, о возврате которых желательно подумать до того, как вы начали их тратить.

Продукт

Я уже несколько раз употребил слово продукт, и пока ещё не дал его определения. Но это слово уже прозвучало в двух совершенно разных контекстах. Стаканчик кофе - продукт, и кофейный автомат тоже продукт, который производит стаканчик кофе, как продукт. Если представить себе разработчиков кофейного автомата, то какой продукт они пилят? Может быть они пилят одновременно оба? Для кофейного автомата вопрос может быть и абсурдный. Но если мы посмотрим на то, чем занимаются современные продуктовые команды в IT-разработке, то абсурдным может показаться не вопрос, а ответ на него.

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

Таким образом, продукт - это то, что можно обменять на деньги. Добровольно эти деньги отдадут за какую-то ощутимую пользу, выгоду, ценность. Этим продукт существенно отличается от проекта. Проект по существу имеет лишь три параметра: объем работ, бюджет и срок. Тогда как у продукта может быть много важных параметров, которые отражают его ценность для заказчика. Более подробно о 4-х основных рыночных типа продукта я рассказываю в отдельной статье. В этой же статье мы подразумеваем, что IT-разработка - это всегда 1-й тип продукта, проект.

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

Высокий УПР, как проблема бизнеса

Эту категорию я уже упомянул ранее. Например, биллинг 30-ти b2b-клиентов ежемесячно требует на 2-3 дня выключить секретаря и старшего менеджера техподдержки, которые вручную выгружают и обрабатывают статистику поведения клиентов в системе, чтобы затем сгенерировать и выставить счета на оплату. Да, они жалуются CEO, что этот ручной мартышкин труд содержит риск ошибки, из-за чего всё приходится по нескольку раз перепроверять, и поэтому давно уже пора всё автоматизировать. CEO в свою очередь успешно "кормит их завтраками", потому что он вообще-то им за эту работу платит зарплату.

Но главное - CEO понимает, что возврат инвестиций от этой разработки будет неадекватный по следующей причине. Допустим разработка биллинга будет стоить 1 млн руб. После внедрения трудозатраты сотрудников на биллинг будут сокращены до нуля. В результате, сотрудники выдохнут и распределят освободившееся время на отдых и другие задачи. Зарплата у них не изменится, увольнять их никто не собирается. Какой был смысл тратить 1 млн руб? В чем выгода? Непонятно.

Друге дело, когда бизнес активно растет и в течение года в вышеприведенном примере количество клиентов вырастет в 10 раз (30 -> 300). Тогда биллинг становится проблемой, узким местом, блокирующим рост бизнеса. Скорее всего, биллинг будет не единственной проблемой, поэтому есть смысл говорить о некотором перечне узких мест, которые заблокируют рост на разных этапах в некоторой последовательности. Это уже вполне конкретная потребность бизнеса в интеграции каких-то средств автоматизации конкретных бизнес-процессов с понятной бизнес-ценностью. Причем решением этих проблем могут быть как своя кастомная разработка, так и готовые решения, подписные сервисы. А может быть и некоторый микс.

Пользовательский опыт, как проблема бизнеса

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

Всё это нельзя назвать дополнительной ценностью продукта, потому что на самом деле каждую из этих задач пользователи уже успешно решают без соответствующего функционала. Однако, автоматизация и разработка помогают решать эти задачи быстрее и удобнее. Улучшение пользовательского опыта (UX/CX - user experience / customer experience) становится очевидной задачей бизнеса с достаточно легко просчитываемым возвратом инвестиций, когда мы успешно расшили узкие места в операционке и обнаружили, что привлекаемые в маркетинговых каналах клиенты оказываются всё более и более капризными и требовательными. Почему так происходит?

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

1. Приготовили бюджет, активно ищут решение, вследствие чего неплохо знают рынок.
2. Состряпали своё решение, рынок знают плохо.
3. Признают наличие проблемы, но ничего не делают для её решения.
4. Отрицают наличие проблемы, хотя при её выявлении соглашаются потратить деньги на решение.
5. Отрицают наличие проблемы, и не хотят покупать решение, даже если проблема проявляется.

Рынок естественным образом переключается на новое решение последовательно по этим 5-ти категориям: от 1 к 5. И чем ниже по списку, тем меньше острота проблемы и, соответственно, меньше готовности менять свои привычки и потребительский опыт. И если первые/вторые жаловались на неудобства, но покупали и пользовались неудобными версиями продукта (как, например, вышеупомянутый MVP стоматологической CRM-системы), то третьи и дальше жалуются и отказываются переключаться с текущих проблемных решений на предлагаемое. Им требуется сильно повышать скорость, привлекательность, удобство и т.п. составляющие UX/CX.

Кроме сугубо рыночной классификации клиентов, есть ещё личностная потребительская характеристика, которая принадлежит каждому человеку и не меняется в различных контекстах/моментах, ситуациях потребления и сохраняется даже с течением времени:

1. Технологические энтузиасты. Эти клиенты покупают и пользуются продуктом, даже если не получают никакой ценности. Их привлекает сам подход, новая технология. В любом рынке есть 1-2% таких клиентов. Они очень любопытные и всегда охотно экспериментируют.
2. Ранние последователи. В отличие от технологических энтузиастов, эти клиенты хотят получить радикальное преимущество за счет нового продукта. На рынке есть 12-15% таких клиентов. Они хотят и любят быть первопроходцами, и по этой причине достаточно легко принимают риск и меняют свои привычки.
3. Ранний массовый рынок. 30-35% клиентов на рынке. Держат нос по ветру, позитивно реагируют на новые продукты. Но, в отличие от ранних последователей, они не готовы рисковать, чтобы получить какую-то выгоду для себя. Они ищут мягкий безопасный эволюционный путь развития.
4. Поздний массовый рынок. Также 30-35% клиентов. Негативно реагируют на инновации. Однако, когда распробуют, без проблем расстаются со своими привычками и принимают новое.
5. Отстающие. ~15% клиентов. Покупают новый продукт только потому, что больше не могут пользоваться старым.

Каждая следующая категория требует всё более и более хорошего UX/CX, а также расходов на привлечение. Казалось бы, зачем заморачиваться с 3-5 типами? Причины две: там находится 85% рынка и они будут вас поддерживать деньгами даже тогда, когда 1-2 убегут в другой рынок. Более подробно про эти типы клиентов рекомендую почитать в книге Джеффри Мура, "Преодоление пропасти".

Границы продукта

Как правильно выделять продукты в разработке? В идеале - от рынка:

1. Делаем сегментацию рынка, выделяем целевые сегменты
2. Под каждый целевой сегмент делаем управленческий расчет продукта, в результате чего может получиться 1+ продуктов в одном сегменте
3. Под каждый продукт составляем список узких мест с кратким описанием проблемы по каждому
4. Ранжируем узкие места по степени их влияния по мере роста в сегменте, прикидываем адекватный бюджет на расшивку каждого
5. Грубо прикидываем решения по каждому узкому месту (или некоторым из них)

Получилось понятное всей команде описание продукта и его бэклог.

Однако, есть проблема. Продуктов может получиться 20-30 и выделять под каждый из них самостоятельный PnL нерационально. Нужно проанализировать и сравнить операционные процессы продуктов, чтобы выявить группы продуктов с одинаковыми (или почти одинаковыми) процессами. Каждую из этих групп есть смысл объединить в продуктовый мини-бизнес, у которого будет независимый операционный штат и своя команда разработки. Более подробно о продуктовых семействах рекомендую посмотреть митап про границы продукта (45 мин).

Бизнес-результат как продукт

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

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

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

1. Для начала выделяем бизнес-результат, который заказчик ожидает получить после внедрения продукта в свой операционный процесс.
2. Выясняется 1+ реальных целей проекта, каждую из которых раскладываем на роли, чей UX/CX нужно поменять, чтобы добиться нужного бизнес-результата.
3. Для каждой роли расписываем UX/CX и/или операционный процесс с гипотезами в формате "если" - "то".
4. Наконец, описываем функционал, который требуется для реализации UX/CX и/или операционного процесса. Желательно это делать в формате бэклога продукта, чтобы можно было выделить функционал, который нужен для их проверки гипотез и поднять его повыше для снижения рисков в первую очередь.

Таким образом вы получите mind map, который связывает желаемый для заказчика бизнес-результат с функциональными требованиями. У такого процесса есть побочные позитивные эффекты. Например, нецелевой проблемный заказчик проявляется и сливается. Целевой напротив ловит ценные для него инсайты и получает вау-эффект. По этой причине есть смысл проводить такой опрос до заключения договора на этап анализа и разработки техзадания. Более подробно про impact mapping рекомендую посмотреть митап Пикулева и Бындю (85 мин).

Резюме по продукту

Итак, есть 4 основных типов продукта: проект (индивидуальное решение), готовое решение, товар и сервис. IT-разработка всегда относится к проекту. Расходы на разработку - это инвестиции, которые возвращаются через рост бизнеса, который стал возможен благодаря этой разработке. Есть два типа ограничений роста бизнеса, которые расшиваются с помощью IT-разработки: низкая удовлетворенность клиента в виде плохого UX/CX и высокие операционные издержки. До тех пор, пока у вас нет идеи масштабировать бизнес, у вас нет и ограничений роста, а значит есть риск получить неадекватный возврат инвестиций в разработку.

Заказчик

Может ли физическое лицо заказать разработку? Нет, если только он (она) не преследует какие-то бизнес-цели, пусть даже самые далекие. Поэтому IT-разработка всегда про бизнес-ценность и у неё должен быть соответствующий возврат инвестиций.

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

Таким образом, причина проблем в разработке в том, что заказчик, который реально отвечает за возврат инвестиций в разработке:

1. В полной уверенности, что расходы на разработчиков - это УПР, и поэтому видит проблему неадекватного возврата инвестиций слишком поздно.
2. Отгорожен от принятия решений в разработке на 1+ человек, и поэтому не может увидеть всю абсурдность этих решений, ошибочно полагая, что причины неадекватного возврата инвестиций заключаются в низкой квалификации персонала.

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

ЛПР

Самый простой совет, который обычно трудно осуществить на практике - найдите человека на стороне заказчика, на которого лично повесили решаемую бизнес-проблему. Трудно потому, что про IT-разработку с разработчиками, как правило, разговаривают другие люди, которые представлются ЛВР-ами и ЛПР-ами. А того самого реального ЛПР-а, которого я сокращенно называю ЛДПР-ом (лицом действительно принимающим решение), на встречах с разработчиками нет.

Так происходит из-за связки: бизнес-проблема -> бизнес-решение -> бизнес-требования -> техническая реализация. На ЛДПРа свешали ответственность за бизнес-проблему. У одной проблемы может быть несколько решений, которые могут тестироваться и реализовываться последовательно или параллельно по принципу - где получилось, там и раскатываем в операционку. ЛДПР, в свою очередь, делегирует реализацию какого-то решения (очевидно связанного с разработкой) на своих подчиненных, которых мы собственно и видим как представителей бизнеса в IT-разработке. Подробнее об иерархии принятия решения на стороне заказчика при продаже проектов предлагаю посмотреть этот ролик (7 мин).

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

Сломаный телефон в разработке

ЛПР-ы и ЛВР-ы часто не считают нужным говорить с командой/подрядчиком не то, что о ЛДПР-е - даже о связке "бизнес-проблема -> бизнес-решение" не говорят. Зачем? Разработчикам надо знать только ту роль, которую они выполняют в проекте - техническая реализация бизнес-требований по части функционала. Всякие бизнесовые вопросы применения этого функционала, по распространенному мнению, излишни и даже вредны. Как-то раз на presale-сессии я задал вопрос представителю бизнеса заказчика (типичный ЛПР): "Как вы поймете, что проект успешен?". Ответ: "Сравним полученный фукнкционал с техзаданием с помощью независимой экспертизы." К слову, там вышеописанный бутерброд был декомпозирован ещё сильнее: ответственность за реализацию решения распилили по разным людям на бизнес-требования (BRD) и техзадание (Design/Spec), которое принесли на presale как фиксированный и единственный источник информации для разработчиков.

Представляете? Между командой разработки и ЛДПР-ом может быть 2+ человека. И если это растояние никак не сократить, то лучше сразу слиться, дабы не попасть в водоворот разборок о нецелевом расходовании средств из-за того самого неадекватного возврата инвестиций. Механика попадания в такую ситуацию наверняка знакома каждому, кто хоть раз участвовал в коммерческой разработке, когда, условно говоря, для вскапывания пары клумб проектируется и изготавливается уникальный экскаватор. Так происходит из-за цепочки сломаного телефона: бизнес-аналитик снимает хотелки с ЛДПРа, дополняет своими идеями и формирует BRD. Системный аналитик с архитектором читают этот BRD и пишут архитектуру и спеки, воплощая туда лучшие инструменты и практики. Разработчики пилят код, костыляя с тестировщиками там, где что-то упустили на предыдущих шагах.

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

Изменчивые бизнес-требования

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

Дело в том, что в этой схеме принятия решений скрыта принципиальная проблема, ошибка. Водопадный подход к доведению до разработчиков "готового" к реализации проекта базируется на том, что функциональные требования не изменятся. Следовательно, целевые бизнес-процессы и целевой UX/CX уже заранее известны. Без существенного риска так можно сказать лишь тогда, когда соответствующий функционал был разработан и апробирован в операционке. Однако, если заказчик в лице его компетентной иерархии, которая рождает все эти великолепные документы, осведомлен о наличии такого функционала, зачем надо снова тратить деньги на его разработку и реализацию? Почему нельзя взять и внедрить то, что уже существует и доказало свою эффективность?

Чаще всего всё таки функционала нет и заказчику достоверно известен только текущий UX/CX и его существующие бизнес-процессы, которые оставляют желать лучшего. А целевой UX/CX представляет из себя разной степени риска гипотезы вида: если делать что-то иначе, будет иной (нужный) результат. Эти гипотезы неизбежно инвалидируются при попытке отгрузить функционал в реальную операционку бизнеса, что неизбежно приводит к изменению функциональных требований. Таким образом реальный процесс разработки - это совместное с заказчиком хождение разработчиков по кругу в поиске такого UX/CX и таких бизнес-процессов, которые позволят получить необходимое изменение в бизнесе заказчика.

Я приведу реальный пример, чтобы эта теория стала понятнее. Есть учебный центр дистанционного повышения квалификации узких дипломированных специалистов. Обучение длится 9 месяцев, средний чек - 70 тыс руб, средний поток - 20 чел. Проблема бизнеса в том, что полуручное администрирование учебного процесса на XLS-файлах и Skype-чатах не дает вести больше одного потока одновременно. Поскольку этот продукт являлся на тот момент основным бизнес-драйвером роста, увеличение кол-ва одновременных потоков было приоритетной бизнес-задачей. Заказчик в лице главного тренера учебного центра посмотрел существующие на тот момент LMS на рынке и в силу особенностей курса (для практики требуется специальный инструмент парной работы), принял решение пилить свою LMS со специализированными виртуальными сессионными залами. Кейс достаточно старый - 2014-2015 год. 20 чел * 70 тыс руб = 1.4 млн. руб (один поток). 5 потоков одновременно дают +5.6 млн руб выручки. Бюджет в тот момент не считали, но думаю, что около 6 млн руб можно было согласовать на старте - отбивается примерно за год.

Роли распределились следующим образом. Тренер оставил за собой ответственность за принятие решения о готовности к запуску 2+ потоков (проблема бизнеса), а также за применимость сессионных комнат к парной практике. Ему было важно добиться работоспособности комнат без необходимости студентам применять сложные манипуляции с приложениями видеосвязи на своих смартфонах. Разработку остального функционала LMS он доверил администратору учебного центра, который отвечал за исполнение учебного процесса, и поэтому прекрасно понимал, где и в каких местах надо что-то менять, чтобы можно было запускать больше потоков без риска отказа студентов от учебы и потери выручки. Таким образом, роль ЛДПР-а осталась у тренера, а администратор разгружал его от возни с 80% вполне понятного функционала LMS, большая часть которого была скопирована с существующих на рынке продуктов LMS, чатов и систем видеосвязи.

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

Таким образом, даже при копировании существующего функционала и существующего UX/CX, бизнес-требования претерпевают изменения, не говоря уже о новом функционале и UX/CX, где изначальные бизнес-требования скорее всего будут сильно меняться. Не глупо ли пытаться снизить риски путем тщательной детализации бизнес-требований? Гораздо лучше поступить иначе: держать бизнес-требования и техзадание в таком формате, чтобы это всё можно было пилить итеративно и достаточно легко корректировать в процессе реализации. При этом каждый функциональный кусочек должен быть качественным, сделанным до конца, иначе такую итеративную разработку нельзя назвать профессиональной.

Роль аналитика

Бывает так, что заказчик действительно точно знает, что хочет, потому что он уже проверил и получил необходимые изменения в UX/CX и операционке на макетах и прототипах и ему действительно надо всё это только автоматизировать. Например, ПО для медицинского оборудования, где экспериментировать далеко не всегда возможно. Однако, такие "исключения" лишь подтверждают правило: чтобы разработать прототипы, заказчик привлек экспертов и вместе с ними ходил по кругу в поиске правильных бизнес-требований, которые затем уже принес разработчикам ПО и им осталось только их технически реализовать.

Но чаще заказчик всё таки не знает, что хочет. И поэтому многие бизнес-аналитики допускают очень серьезную ошибку в разработке - напрямую спрашивают у заказчика, что он хочет и оформляют это в виде функциональных бизнес-требований. Аналитик думает, что его роль в том, чтобы систематизировать видение заказчика по части функционала продукта в целостную непротиворечивую картинку с помощью, например, UML-диаграмм. Результатом работы аналитика в таком случае является техническое задание на разработку. Часто в паре с аналитиком работает UX/UI-дизайнер, чтобы заказчик перед подписанием технического задания увидел, как будет выглядеть его будущий продукт. Затем заказчик отдает это техзадание на оценку нескольким подрядчикам и выбирает того из них, кто предлагает лучшее соотношение цена-качество.

В результате получается, как в анекдоте. 30е годы. В колхоз приходит новый трактор. Все, открыв рты, восхищенно осматривают его со всех сторон, удивляясь чуду. Но вот подходит старейшина и говорит: "Да, трактор хорош. Одного железа сколько, а колёса какие, а оси. Но вот непонятно, куда тут лошадь запрягать?". Догадываетесь, кто будет виноват, когда несколько лошадей сдохнут при попытке вспахать поле таким образом?

Пример из реальной практики на эту тему. Учебное заведение заказывает систему дистанционного обучения для своих клиентов. Бизнес-аналитик подрядчика опрашивает сотрудников учебного заведения, чтобы спроектировать процесс зачисления учащихся на поток. Те просят сделать так, чтобы формы документов при заполнении на экране выглядели также, как они выглядят на бумаге. Аналитик всё тщательно фиксирует и передает в разработку. Возражение о том, что на мобильных телефонах это будет практически невозможно приводит к фиксации этого факта в ТЗ: только десктопы.

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

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

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

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

Владелец продукта

Мы разобрались, что ЛДПР - это человек, который единолично отвечает за решение проблемы бизнеса. На рынке разработки ПО сейчас очень распространен термин владелец продукта, его можно использовать как синоним. Однако, я намеренно избегаю этого по той причине, что ооочень часто его понимают неправильно с вполне конкретными неприятными последствиями.

В продажах, особенно сложных продуктов и услуг, очень важным является проход к ЛПРу через разного рода промежуточных исполнителей. Потому что очень неприятно потратить много времени и денег на работу с человеком, который в итоге говорит нечто вроде "мне всё нравится, теперь я пойду согласовывать это с начальством". Тут мы понимаем, что решение на самом деле принимаются теми людьми, в потребностях которых мы рискуем ничего не понимать. В IT-разработке тот же принцип. Если с командой разработчиков общается промежуточный исполнитель, то очень высокий риск запилить не то. Разработчики это видят как абстрактный безтолковый менеджмент, у которого семь пятниц на неделе, из-за чего им постоянно приходится без конца всё переписывать и рефакторить, и в итоге они же оказываются крайними за долгую неэффективную разработку.

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

Термин владелец продукта (product owner, сокр. PO) пришел из Scrum-фреймворка, где эта роль формализована минимально необходимым набором правил и ограничений. И не смотря на это, PO часто назначают с грубыми нарушениями этих правил, в результате чего возврат инвестиций оставляет желать лучшего. Чаще всего нарушаются правила про уважение решений PO со стороны организации и единоличность этой роли (sole person, not a comittee). Однако, из этих правил и ограничений действительно трудно бывает понять, как же правильно выделить роль PO?

Представим, что таксист пришел в автосалон покупать автомобиль, чтобы перейти с аренды на свое авто. Из предложенных ниже вариантов выберите человека, который подходит к роли PO по отношению к этому продукту:

1. Покупатель - самозанятый таксист
2. Продавец - сотрудник автосалона
3. Директор по развитию бизнеса на автомобилях под такси - сотрудник автосалона
4. Главный инженер - сотрудник завода-производителя
5. Директор по развитию бизнеса на производстве автомобилей - сотрудник завода-производителя

Чтобы найти правильный ответ, давайте вспомним, что в данном случае автомобиль относится к инвестициям в основные средства производства и их возврат должен происходить через снижение УПР и/или улучшение UX/CX. Тогда PO - это тот человек, который отвечает за решение проблемы бизнеса, непосредственно связанной с УПР и/или UX/CX. Значит, правильный ответ зависит от бизнеса, в контексте которого мы рассматриваем автомобиль, как продукт.

Если речь идет о маленьком таксомоторном бизнесе, где условный таксист, как самозанятый, зарабатывает деньги на перевозке пассажиров, то правильный вариант - первый. Сейчас он каждый день отдает деньги за аренду чужого автомобиля, допустим, 2.4 тыс руб / день (52.8 тыс руб в месяц, 633 тыс руб в год). Покупка нового автомобиля ему обойдется в 1 млн руб, после чего он будет тратить условные 70 тыс руб в год на его обслуживание, ремонт, и т.д. Значит эта покупка отобьется у него примерно за 2 года, если все остальные показатели его бизнеса не изменятся.

Если речь идет о бизнесе условного автосалона по перепродаже этих автомобилей, то правильный ответ - третий. Допустим, что раньше они зарабатывали процент с услуг дружественных СТО по переоборудованию под такси, сейчас они вывели на рынок новый продукт - автомобиль под такси как готовое решение со спец программой гарантийного сервиса и заменой автомобиля по trade-in по истечению гарантийного срока. Теперь директор, который отвечает за развитие бизнеса в сегменте таксистов-самозанятых, в том числе занимается переработкой пост-продажного сервиса (UX/CX), чтобы повысить LTV и виральность в сегменте.

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

Area Product Owner

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

В приведенном выше примере про самописную LMS для запуска 2+ одновременных потоков учебного центра, администратору выделили область продукта (area), решение о готовности к релизу по которой всё равно принимал тренер, который и был в том примере реальным владельцем продукта. Администратор учебного центра при этом был APO и разгружал тренера от необходимости готовить с разработчиками детальные требования по функционалу LMS помимо сессионных комнат для практики. Позже, когда большая часть функционала продукта была разработана, в проекте появился ещё один APO, который стал больше общаться с разработчиками, чем администратор. Это был продакт-менеджер, который отвечал за привлечение и продажи курсов.

В пределе, области продукта/бизнеса (area) могут выделяться всего из четырех категорий:

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

Главное, чтоб при этом не происходил сломаный телефон и снижение ROI из-за чрезмерных расходов на координацию и запиливание ненужного. А именно это часто и происходит. Любые роли-прокладки между ЛДПРом (реальным PO) и командой разработки неизбежно начинают заниматься субоптимизацией со всеми вытекающими. Сотрудники не должны заменять/представлять ЛДПРа в IT-разработке. Они должны разгружать его так, чтобы сохранять за ним ответственность за бизнес-ценность.

Статья в разработке...