Когерентность мышления продуктовой команды

Цепочка создания ценности в IT:
Определение потребности (неважно, создание ли это продукта или заказная разработка) -> Задача на создание решения, закрывающего потребность -> Реализация задачи -> Поставка решения -> Поддержка и развитие решения (если повезет).
На каждом этапе к тому, что за решение в итоге получится, прикладывают руки N разных людей.
Давайте разберемся, что при этом происходит.
---
Потребность - не очень конкретное понятие. Для начала работ по созданию продукта нужно преобразовать это понятие в список требований (и хорошо бы не "как делать", а "что хотим получить"). И специально обученные люди (скажем, при неплохом раскладе это совместная команда из маркетинга+производства) начинают эти требования кристаллизовывать.
Для простоты путь это будут два человека: Вася и Петя.

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

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

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

После того, как Вася с Петей хорошо потрудились и сформулировали требования, это получились очень хорошие, на 90% цельные непротиворечивые требования (Вася с Петей - классные профессионалы в своей области). Остальные 10% требований будут играть роль ЛРЩ (лебедя, рака и щуки). И уводить итоговый продукт в сторону СКВ (сферического коня в вакууме). То есть это по сути потери.

И неважно, что они договорились и записали все в одном документе. Для каждого из них это свой индивидуальный документ. Для Васи-маркетолога в этом документе написано на 10% другое, чем для Пети-аналитика.
<в реальности для Пети-аналитика в этом документе будет чаще не на 10, а на 50% написано другое, чем для Васи-маркетолога>

Есть сформулированные требования - это хорошо, можно разрабатывать решение.
Большого смысла расписывать процесс разработки нет, главное, что в создание продукта _значительный_ вклад вносят несколько человек. Ну минимум три ). Полное пересечение их представлений о требованиях, записанных в документе, будет, при неплохом раскладе, процентов 50 от общего объема. Еще 25% - пересечение кругов двух людей из трех и оставшиеся 25 - ЛРЩ (СКВ) (потери). Грубо, учитывая уже изначальную неидеальность требований, степень сферичности коня в вакууме у продукта (то есть общие потери) на этом этапе будут не меньше 40%.
---
Теперь рассмотрим более реальный вариант.
При формулировке требований когерентность мышления Васи и Пети об обсуждаемых потребностях составляет 50%.
Три разработчика, реализующие полученные требования, полностью когерентны относительно этих требований на 30%, еще на 40 - частично когерентны (пересечение двух кругов из трех) и на 30% - ЛРЩ.
Общие потери у продукта будут уже в районе 70%.
---
Самое печальное, что практически никто не будет это признавать за потери - люди честно работали, честно выполнили требования. Но по факту, для бизнеса - это потери. Это непопадание в потребности, это размывание продукта, его стержня, это поддержка несвойственных функций, это дополнительные точки сбоя, это дополнительные затраты на поддержку/рефакторинг/тестирование программного кода, это ухудшение TTM, это усложнение деплоя, это увеличение затрат по техподдержке и эксплуатации. (В итоге эти 40-70% потерь превратятся во все 90-99, но про это тс-с-с!!!)

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

В крупных компаниях практически всегда есть жесткое разделение зон ответсвенности. В телекоммуникационных компаниях, например, сейчас тренд подгонять эти зоны ответственности подразделений под классификацию eTOM.
Но при этом, чем сильнее разделены структуры, отвечающие за бизнес, технический анализ, разработку, техподдержку и эксплуатацию, тем компании несут больше потери.
---
А теперь мысленно масштабируйте это понимание происходящего на разработку нескольких связанных продуктов. И на разработку инфраструктурных продуктов, их связывающих. И на прослойку в виде какого-нибудь архитектурного комитета (а как иначе хоть как-то координировать продуктовые команды).
Тут кроме всего прочего еще 100% будет реализация одинаковых фич в разных командах, непереиспользование кода, как с этим ни борись, недоанализ и недопрограммирование. А как вы думаете, как низкая когерентность мышления продуктовой команды влияет на bus-фактор? Думаю, расписывать не стоит.

Но это еще не все )))
У меня есть еще одна плохая новость:
Это все влияет не только на количество потерь из-за высокой СКВ продукта. Это (укрупнение команд, разграничение зон ответственности) неизбежно приводит к самым прямым потерям - потерям рабочего времени.
Причина, собственно, та же, и, я думаю, вы уже догадались, в чем дело: чем сильнее различается внутреннее представление о задаче у людей, тем им нужно больше времени, чтобы договориться хотя бы до всеми приемлемых формулировок. И потратить на это больше психической энергии (это важно, чуть позже может покажу почему). Чем более жестко разделены по зонам ответсвенности подразделения, задействованные в процессе, тем больше нужно времени (и энергии) потратить на коммуникации.
Наверное, все, кто работает в крупных компаниях, страдают от количества совещаний/обсуждений - они могут занимать, в зависимости от структуры организации и стиля управления, до 50-80% рабочего времени людей, влияющих на развитие продукта.
---
(А знаете в чем одно из фундаментальных отличий заказной разработки от продуктовой? В том, что весь этот праздник жизни оплачивает заказчик. У компании-разработчика при этом минимум ответственности и рисков (в краткосрочной перспективе). Но и доходов тоже минимум.)
---
В итоге:
Продукты, как ни странно, получаются часто даже рабочие и иногда их возможностями даже процентов на 10-20 пользуются. (Крупные решения рабочими становятся сильно реже (и/или сильно дольше)).
Очень часто от взаимодействия с той частью продукта, которая все-таки используется, кровь бежит из всех возможных мест.
Многие из этих продуктов рано или поздно полностью переписываются, часто не один раз.
Это, с одной стороны, конечно, плохо. Но это нормально. И в целом неизбежно.
И говорить можно только о том, как эти потери уменьшить. Хотя бы чтобы кровь не бежала.
И это достижимо, иногда даже на практике.

Хорошая новость: подобное притягивается.

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

В формулировке Аристотеля он звучит так: «природа ничего не делает напрасно и во всех своих проявлениях избирает кратчайший или легчайший путь».

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

Какие принципы управления позволяют это реализовать на практике:

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

Это необходимые, но, естественно, не достаточные принципы. Умные книжки по управлению тоже надо читать. Например, Элияху Голдтратта (и далеко не только "Цель").

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

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

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

• PO должен уметь разговаривать на одном языке с бизнесом, четко понимать, что ему нужно, мыслить категориями прибыли (навыки: основы фин. грамотности, основы маркетинга);
• PO должен уметь вести проектную деятельность: устав проекта (цели, границы, действующие лица), организационная схема проекта, план управления проектом (ИСР, контрольные точки, критерии достижения целей, риски, границы проекта и т.д.), календарный план (навыки: управление проектами).
• PO должен очень хорошо понимать ЦА (целевую аудиторию) продукта, ее потребности, ее привычки, сценарии использования продукта, включая окружение, обстоятельства (понимать Продукт "снаружи"), действовать на опережение (навыки: бизнес-анализ, UX, психология);
• PO должен уметь разговаривать на одном языке с разработчиками, хорошо разбираться в архитектуре продукта, взаимодействии модулей продукта, используемых при его производстве инструментах (понимать Продукт "изнутри") (навыки: знания в области программной инженерии, знание методологий разработки ПО, принципов CI, devops);
• Мало того, PO должен быть лидером продуктовой команды (задавать тон при разработке архитектуры, выборе инструментов (например, используем опенсорс или пишем свою кодовую базу) и технологий.
• PO должен уметь эмоционально "заряжать" команду разработчиков (навыки: психология, лидерство)
• Ну, и PO должен быть творческой личностью и неплохим оратором.

В идеале это должен быть один человек, чтобы на самом первом этапе исключить потери (когерентность мышления = 100%). Но, согласитесь, в одном человеке все это совместить практически нереально! Наверное, такие примеры есть, но это точно исключения. Возможно, Стив Джобс был одним из таких исключений. По крайней мере, это был один из лучших Product Owner-ов.

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

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

Несколько тезисов о классификаторах и методологиях с этой же позиции, без пояснений:

Agile манифест в качестве принципов - добро;
Конкретная Agile методология в качестве закона - ад;
ITIL как справочник лучших практик - ок;
ITIL как культ поклонения или свод законов - зло;
eTOM как "выравниватель" описания бизнес-процессов - ок (мне кажется, это по большей части нужно для упрощения продаж ПО, автоматизирующего бизнес-процессы);
Построение оргструктуры предприятия на основе классификации eTOM - зло (хоть меня за это камнями и закидают).
Продолжите ряд.