Вы уже знаете, что наша компания периодически выпускает книги, включая переводные, различных авторов по ИТ-менеджменту. Управление ценностью и её потоком является в настоящее время одной из центральных идей различных источников. Ценность доносится до пользователя через некоторый продукт, его потребление в достаточно широком смысле.
В процессе работы над очередной книгой удалось сформулировать несколько вопросов, связанных с масштабом того, что мы собираемся называть продуктом.
“Опята”
Представим себя маленьким, но амбициозным финтех стартапом, опаздывающим на пару лет на рынок беспошлинных трансграничных переводов. Мы думаем, что прекрасно представляем свой сервис и его ценность для пользователей, формируем бодрую команду специалистов по международным финансам, юристов, разработчиков. Ставим в её главе владельца продукта и команда начинает свою работу. Мы разрабатываем приложение, являющееся фронтом нашей услуги, устойчивую бэкенд инфраструктуру и боремся за рынок, для начала опубликовывая и рекламируя свой сервис в ограниченном наборе стран.
Через некоторое время мы понимаем, что нашим клиентам в процессе перевода средств важно не только переводить деньги, но и конвертировать валюты. При этом, на самом деле, тут возможны два бизнес-способа: прямая конвертация фиатных валют между собой, и конвертация в криптовалюты или в долговые инструменты.
Что мы должны сделать? Поручить этот новый поток существующей команде, ведь эта функция важна и актуальна именно для трансграничных переводов? Сформировать новую продуктовую команду, которая будет отвечать за конвертацию валют и развивать её?
Если идем по первому пути, то этот отдельный стрим потребует отдельной структуры управления, т.к существующая команда и так уже покрыла стикерами все доступные стены и её расширение скажется на управляемости. Если мы создаем отдельную команду, то как провести ответственность за точки пересечения этих команд? Они будут использовать одно приложение (по крайней мере, на старте), одни и те же данные, у них будут разные и противоречивые интересы и скорость развития.
Источники говорят, что “все можно решить в диалоге двух умных людей”, но у этих “умных людей” отличающиеся приоритеты и мотивация. Им платят за разное, если говорить совсем грубо. Что же, похоже, вам придется верить в определенное благоразумие и продолжить верить в людей. Вы ведь доверяли им ранее?
Практика разработки приложений сейчас говорит свое “нет” совместно используемой инфраструктуре, как минимум на всех слоях выше физики, т.к. именно это технически позволяет свободу преобразования и эксперимента, минимизирует разрушения от “fail fast”. Вопрос с данными тоже можно как-то разрешить. Это будет означать, что мы будем кроме поддержки команд (финансирования) будем финансировать и всю связанную инфраструктуру, включая дублирующиеся элементы архитектуры приложений. Но это, как мне видится, все же меньшее из зол.
“Водораздел”
Ситуацию можно усложнить. Правительства государств, справедливо опасаясь потери контроля над финансовыми потоками и потерей фискальных платежей, вводят требования к предоставлению наших финансовых услуг на их территории. В результате напряженных переговоров, посвященных сохранению возможности вести дела, мы принимаем решение разбить наш сервис на три самостоятельных инфраструктурных решения, действующих в азии, еврозоне, америках, соответственно. Внутри этих регионов хранятся и обрабатываются данных резидентов, услуги между регионами проходят по отдельному каналу, в соответствии принятыми законодательными ограничениями.
Это все ещё один продукт и одна команда, или три продукта и три команды? Очевидно, что они через некоторое время после разделения будут работать и развиваться обособленно. Но это несколько вырожденный для повышения наглядности пример.
Ситуация может быть тоньше и ближе многим корпоративным заказчикам, если мы проиллюстрируем эту коллизию иначе: у нас был продукт в виде коробочного ПО и мы зарабатывали на его продаже, и сегодня мы начали предоставлять его в форме SaaS. Но существующие версии продукта у наших заказчиков являются кастомизированными: если причесывать их под одну “стандартную гребенку”, то мы или не угадаем с затратами, или заказчики будут недовольны утерей части кастомизации. Поддержка и развитие различающихся версий, это тот же продукт или уже иной?
Что, если у заказчиков противоречащие друг другу требования?
Если один заказчик платит в 10 раз больше второго, то его запросы становятся в десять раз более приоритетными?
Если мы пойдем путем разделения, то у базового коробочного продукта и инсталляций есть общие элементы, общий код, восприятие единого продукта заказчиком, лицензионная информация. Объявить существующие инсталляции презренным legacy отстоем и продать новую версию услуги заказчику “еще раз”?
“Атом”
Пусть мы предоставляем ERP как SaaS. Что делать “продуктом”: всю мегасистему целиком? Отдельные её модули, т.к они предоставляют заказчикам очевидную ценность? Как поступать с важными элементами сложных систем, на которых мы не зарабатываем, можно ли делать их продуктами?
Например, если мы производим и продаем алкогольную продукцию, то система легального учета сырья, сертификатов, готовой продукции существенно влияет на финансы, складской учет и логистику, регламентированную отчетность, маркировку, электронный документооборот с госорганами. Мы точно не зарабатываем на этом, но требования законодательства важно соблюдать комплексно, это требует разработки, преобразований, инфраструктуры и тому подобное. Особенно, если мы работаем более чем в одной стране, и область требует непрерывного системного управления и надзора
Будет ли искомым критерием продукта совокупность возможности монетизации и возможностей по обособлению предметной инфраструктуры?
Если мы решим назвать пока не монетизированный “проект” (деятельность плюс инфраструктура) продуктом, то как приоритезировать поступающие запросы развития, как определить бюджет? Как сравнивать ценность монетизируемых и не монетизируемых продуктов, при их конкуренции за ресурсы? Снова стремиться к полному разделению людей и инфраструктуры?
“Вопросы. Вопросы, требующие ответов. … “
Коллеги, подскажите, в какой “настольной книге владельца продукта” про это можно почитать? Изобретать велосипед на практике придется в любом случае, но, если говорить персонально, то пока, кроме классического финансово-проектного анализа разных альтернатив, других идей нет. Считать нужно многое и, насколько это возможно, часто, оценивая риски и влияние изменений деловой среды.
Вопрос, как мне кажется, совсем не про ИТ, но от этого он не становится менее интересным.
