Об продукт в ИТ-команде Это будет серьезный пост, который мож | Господин Архитектор

Об продукт в ИТ-команде

Это будет серьезный пост, который может показать разработку с той стороны, с которой на нее никогда не смотрели. Аутсорсинга не касается, так что в этом случае можно пропустить. Для остальных - затравка:
- если вы согласны, что ИТ-команда разрабатывает и релизит продукт (сайт, приложение)
- если вы согласны, что компания зарабатывает, продавая доступ к этому сайту/приложению
- если вы согласны, что product owner владеет, собственно, разработкой
- то вам точно стоит это прочитать: вы ошибаетесь. Заодно вы узнаете, каким KPI можно измерять вклад ИТ-отдела в бизнес компании.

[15 min+]

Я постараюсь донести свою мысль в аналогии, сравнением двух вымышленных компаний. О них ниже.

Пусть компания "А(грегатор)" - ИТ-"стартап", который делает сайт-агрегатор по страховым полисам. Компания "Б(исиклеты)" - собирает из комплектух и продает велосипеды. Обе эти компании очень похожи - это b2c бизнес, в котором есть реклама, продажи, производство. Только в "А" это производство - ИТ-ное, а в "Б" - железячное в пространстве и времени.

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

Есть такой показатель, COGS(cost of goods sold), или, по-русски - себестоимость проданных юнитов. Чем ниже себестоимость, тем больше прибыль на каждой сделке при прочих равных. Для этого оптимизируется склад, непрерывно отбираются и меняются поставщики, ускоряется сборка, чтобы производство тратило как можно меньше денег на каждый велосипед. Тут есть нюансы, но в общем и целом нет вопросов, выглядит здраво, да? Ну, потому что так это устроено везде.

Теперь вернёмся к нашим компьютерам, в компанию "А". Там есть ИТ-команды, как и много где. Давно ли вы видели задачи у ИТ-команд "сократить себестоимость"? Нет, такая задача иногда встречается, но будем честными - вряд ли они поднимаются в бэклоге по приоритету куда-то в область важных, если только вы не разоряете свою компанию чеками на AWS. Да и вообще не очень понятно, каким образом ИТ-команда, проедая зарплату и добавляя все новые фичи в продукт, работает над СНИЖЕНИЕМ себестоимости? И себестоимости чего? Учитывая, что себестоимость для ИТ это операционные расходы на поддержание сервиса, тестирование фич (а их все больше), и т.п.. Фантастика какая-то, нереально.

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

ИЛИ НЕТ?

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

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

Компания "А" продает страховки. Основное ценностное предложение в данном случае (value) - СОСТОЯНИЕ ЗАСТРАХОВАННОСТИ, вот что принесет пользователю сделка на сайте.
Составляющие ценности, повышающие удовлетворенность клиента - это ЭКОНОМИЯ (агрегатор предложений) и СВОЕВРЕМЕННОСТЬ (выбрал и купил прямо на сайте).
А продукт - это не сайт и не мобильное приложение. Продукт это СОВОКУПНОСТЬ ВСЕХ СТРАХОВОК, КОТОРЫЕ МЫ ПРОДАЕМ/ПРОДАЛИ.