https://semenov.life/mind_cohe...
Пишу конкретно про IT компании, но в принципе это все справедливо для любых более-менее крупных компаний.
За очень редкими исключениями, КПД всех крупных IT компаний по использованию ресурсов (а именно, своего производственного персонала) крайне мал. Не больше, скажем, 20%. А скорее еще меньше.
Компании годами усердно борются за повышение эффективности, потом годами - с результатами этого усердия и далее по спирали.
Не верите?
Поехали
Мышление человека перерабатывает входящую информацию о задаче в свое внутреннее представление об этой задаче
Цепочка создания ценности в IT:
Определение потребности (неважно, создание ли это продукта или заказная разработка) -> Задача на создание решения, закрывающего потребность -> Реализация задачи -> Поставка решения -> Поддержка и развитие решения (если повезет).
На каждом этапе к тому, что за решение в итоге получится, прикладывают руки N разных людей.
Давайте разберемся, что при этом происходит.
---
Потребность - не очень конкретное понятие. Для начала работ по созданию продукта нужно преобразовать это понятие в список требований (и хорошо бы не "как делать", а "что хотим получить"). И специально обученные люди (скажем, при неплохом раскладе это совместная команда из маркетинга+производства) начинают эти требования кристаллизовывать.
Для простоты путь это будут два человека: Вася и Петя.
(здесь должна быть картинка с Васей и Петей за думой, предлагаю представить ее)
Насколько они одинаково понимают потребность? Как повезет. Это измерить невозможно, но совершенно точно не одинаково. Просто потому, что такова природа людей: у каждого человека _абсолютно_ уникальная внутренняя картина мира. (Кто-то называет ее коконом восприятия.) Как-нибудь отдельную статью на эту тему напишу, ее можно раскрывать с разных сторон - психология, социология, эзотерика, нейробиология и даже квантовая физика.
Здесь просто зафиксируем, что мышление человека перерабатывает входящую информацию о задаче в свое внутреннее представление об этой задаче, это внутреннее представление у каждого уникально.
Можно назвать пересечение восприятия одной и той же информации разными людьми, например, ментальной синхронизацией или еще как-то, но мне, как физику, больше нравится термин "когерентность мышления".
В одном и том же документе для Васи-маркетолога написано другое, чем для Пети-аналитика.
И вот есть два человека и два представления о задаче. Давайте нарисуем внутреннее представление каждого человека в виде круга. Полностью эти круги совпадать не будут никогда. Степень их пересечения зависит от множества факторов (социальных, географических, политических и еще кучи всего). Представим, что нам повезло и это пересечение 90% (для пары маркетолог/разработчик это практически нереально, но нам прям свезло, так свезло).
После того, как Вася с Петей хорошо потрудились и сформулировали требования, это получились очень хорошие, на 90% цельные непротиворечивые требования (Вася с Петей - классные профессионалы в своей области). Остальные 10% требований будут играть роль ЛРЩ (лебедя, рака и щуки). И уводить итоговый продукт в сторону СКВ (сферического коня в вакууме). То есть это по сути потери.
И ваще неважно, что они договорились и записали все в одном документе. Для каждого из них это свой индивидуальный документ. Для Васи-маркетолога в этом документе написано на 10% другое, чем для Пети-аналитика.
<в качестве спойлера: для Пети-аналитика в этом документе будет чаще не на 10, а на 50% написано другое, чем для Васи-маркетолога>
<в качестве еще одного спойлера: но все-таки стоит дальше почитать>
Практически никто не будет это признавать за потери - люди честно работали, честно выполнили требования...
Есть сформулированные требования - это хорошо, можно разрабатывать решение.
Большого смысла расписывать процесс разработки нет, главное, что в создание продукта _значительный_ вклад вносят несколько человек. Ну минимум три ). Полное пересечение их кругов представления о требованиях, записанных в документе, будет при неплохом раскладе процентов 50 от общей площади. Еще 25% - пересечение кругов двух людей из трех и оставшиеся 25 - ЛРЩ (СКВ) (потери). Грубо, учитывая уже изначальную неидеальность требований, степень сферичности коня в вакууме у продукта (то есть общие потери) на этом этапе будут не меньше 40%.
---
Теперь рассмотрим более реальный вариант.
При формулировке требований когерентность мышления Васи и Пети об обсуждаемых потребностях составляет 50%.
Три разработчика, реализующие полученные требования, полностью когерентны относительно этих требований на 30%, еще на 40 - частично когерентны (пересечение двух кругов из трех) и на 30% - ЛРЩ.
Общие потери у продукта будут уже в районе 70%.
---
Самое печальное, что практически никто не будет это признавать за потери - люди честно работали, честно выполнили требования. Но по факту, для бизнеса - это потери. Это непопадание в потребности, это размывание продукта, его стержня, это поддержка несвойственных функций, это дополнительные точки сбоя, это дополнительные затраты на поддержку/рефакторинг/тестирование кода, это ухудшение TTM, это усложнение деплоя, это увеличение затрат по поддержке и эксплуатации. (В итоге эти 40-70% потерь превратятся во все 90-99, но про это тс-с-с!!!)
Вообще, конечно, не я один такой умный и люди давно работают над увеличением этого процентажа (осознанно или нет): agile, итерации + демо с обратной связью и корректировкой требований и множество других техник. Все техники нужны далеко не только потому, что рынок быстро меняется и меняются потребности, как пишут в учебниках по скраму - больше это нужно именно для того, чтобы Вася-маркетолог как можно раньше обнаружил, что в документе для Пети-аналитика записано не совсем то.
Чем сильнее разделены структуры, отвечающие за бизнес, разработку, техподдержку и эксплуатацию, тем больше потери.
Можете порисовать разные варианты пересечений внутреннего представления о задаче у команды из нескольких человек, убедитесь лично, что при увеличении команды _гарантированно_ ухудшаются качественные характеристики продукта (в отличие от количественных) и увеличиваются потери.
Чем сильнее разделены структуры, отвечающие за бизнес, технический анализ, разработку, техподдержку и эксплуатацию, тем больше потери.
---
А теперь мысленно масштабируйте это понимание происходящего на разработку нескольких связанных продуктов. И на разработку инфраструктурных продуктов, их связывающих. И на прослойку в виде какого-нибудь архитектурного комитета (а как иначе хоть как-то координировать продуктовые команды).
Тут кроме всего прочего еще 100% будет реализация одинаковых фич в разных командах, непереиспользование кода, как с этим ни борись, недоанализ и недопрограммирование. А как вы думаете, как низкая когерентность мышления продуктовой команды влияет на bus-фактор? Думаю, расписывать не стоит.
Продукты, как ни странно, получаются часто даже рабочие и иногда их возможностями даже процентов на 10-20 пользуются.
Но это еще не все )))
У меня есть еще одна плохая новость:
Это все влияет не только на количество потерь из-за высокой СКВ продукта. Это (укрупнение команд, разграничение зон ответственности) неизбежно приводит к самым прямым потерям - потерям рабочего времени. Причина, собственно, та же, и, я думаю, вы уже догадались, в чем дело: чем сильнее различается внутреннее представление о задаче у людей, тем им нужно больше времени, чтобы договориться хотя бы до всеми приемлемых формулировок. И потратить на это больше психической энергии (это важно, чуть позже может покажу почему). Чем более жестко разделены по зонам ответсвенности подразделения, задействованные в процессе, тем больше нужно времени (и энергии) потратить на коммуникации. Наверное, все, кто работает в крупных компаниях, страдают от количества совещаний/обсуждений - они могут занимать, в зависимости от структуры организации и стиля управления, до 50-80% рабочего времени людей, влияющих на развитие продукта.
---
(вот это отметить, под спойлером: А знаете в чем одно из фундаментальных отличий заказной разработки от продуктовой? В том, что весь этот праздник жизни оплачивает заказчик. У компании-разработчика при этом минимум ответственности и рисков (в краткосрочной перспективе). Но и доходов тоже минимум.)
---
В итоге:
Продукты, как ни странно, получаются часто даже рабочие и иногда их возможностями даже процентов на 10-20 пользуются. (Крупные решения рабочими становятся сильно реже (и/или сильно дольше)).
Очень часто от взаимодействия с той частью продукта, которая все-таки используется, кровь бежит из всех возможных мест.
Многие из этих продуктов рано или поздно полностью переписываются, часто не один раз.
Это, с одной стороны, конечно, плохо. Но это нормально. И в целом неизбежно.
И говорить можно только о том, как эти потери уменьшить. Хотя бы чтобы кровь не бежала.
И это достижимо, иногда даже на практике. Я даже знаю как ;)
Проблема в том, что это в большей части искусство, чем наука. Это искусство управлять.
Хорошая новость: подобное притягивается.
Один из основополагающих законов нашей Вселенной, из которого математически выводятся все известные законы физики (по крайней мере, механики, оптики и термодинамики, это я точно по лекциям помню) - это Принцип наименьшего действия. В формулировке Аристотеля он звучит так: «природа ничего не делает напрасно и во всех своих проявлениях избирает кратчайший или легчайший путь».
Этот принцип несомненно применим и к социологии. Люди больше стремятся взаимодействовать с теми людьми, при общении с которыми затрачивается меньшее количество энергии (психической в данном случае). С кем проще договориться, найти общий язык, в том числе по рабочим вопросам.
Что это значит в профессиональном плане: люди естественным образом стремятся объединиться по принципу одинаковости подходов к разработке, анализу, похожести способа мышления. Естественным образом формируются мини-социумы людей, комплементарных друг другу (Гумилев использовал этот термин в контексте этносов, но в отношении людей он тоже справедлив), обладающих достаточно высокой когерентностью мышления.
---
Наиболее эффективным способом уменьшения потерь явно является увеличение когерентности мышления продуктовой команды, тут даже к бабке не ходи. Проблема в том, что это в большей части искусство, чем наука. Это искусство управлять.
Умные книжки по управлению тоже надо читать.
Какие принципы управления позволяют это реализовать на практике:
- Формирование команд по принципу комплементарности входящих в нее людей.
- Высокий уровень психологической грамотности руководителя: умение на уровне ощущений определять совместимость людей, когерентность их мышления.
- Свобода формирования команд - самоорганизация команд, возможность максимально легко перейти из одной команды в другую. Например, говнокодеры (говнокодеры - это собирательный образ, означает людей, которые делают все "в лоб", не сильно заморачиваясь анализом) будут тянуться друг к другу, образовывать микро-команды - эти команды можно смело целиком увольнять.
- "Сквозной" человек/группа (роль product owner). О нем чуть подробнее ниже.
Это необходимые, но, естественно, не достаточные принципы. Умные книжки по управлению тоже надо читать. Например, Элияху Голдтратта (и далеко не только "Цель").
Вы много знаете примеров крупных компаний и продуктов, где есть настоящие (а не формальная роль) Product Owner-ы?
Немного подробнее про роль Product Owner-а, потому она критически важна как для создания, так и для последующей жизни продукта.
Любая система находится в равновесном состоянии тогда, когда ее энтропия максимальна.
Поэтому вполне логично, что любой продукт, любая идея со временем стремится к "расползанию" (к состоянию сферического коня в вакууме). Чем больше людей продукт затрагивает, тем сильнее это стремление.
По сути, главная задача этой роли PO - задавать "внутренний стержень" продукта, его экосистему и в дальнейшем предотвращать это "расползание" - не дать продукту превратиться в СКВ.
Это сделать очень непросто, находясь под давлением одновременно со стороны инвесторов, пользователей и разработчиков продукта.
На мой взгляд, для выполнения этой задачи нужно обладать вот каким списком навыков и компетенций:
PO должен уметь разговаривать на одном языке с бизнесом, четко понимать, что ему нужно, мыслить категориями прибыли (навыки: основы фин. грамотности, основы маркетинга);
PO должен уметь вести проектную деятельность: устав проекта (цели, границы, действующие лица), организационная схема проекта, план управления проектом (ИСР, контрольные точки, критерии достижения целей, риски, границы проекта и т.д.), календарный план (навыки: управление проектами).
PO должен очень хорошо понимать ЦА (целевую аудиторию) продукта, ее потребности, ее привычки, сценарии использования продукта, включая окружение, обстоятельства (понимать Продукт "снаружи"), действовать на опережение (навыки: бизнес-анализ, UX, психология);
PO должен уметь разговаривать на одном языке с разработчиками, хорошо разбираться в архитектуре продукта, взаимодействии модулей продукта, используемых при его производстве инструментах (понимать Продукт "изнутри") (навыки: знания в области программной инженерии, знание методологий разработки ПО, принципов CI, devops);
Мало того, PO должен быть лидером продуктовой команды (задавать тон при разработке архитектуры, выборе инструментов (например, используем опенсорс или пишем свою кодовую базу) и технологий.
PO должен уметь эмоционально "заряжать" команду разработчиков (навыки: психология, лидерство)
Ну, и PO должен быть творческой личностью и неплохим оратором.
В идеале это должен быть один человек, чтобы на самом первом этапе исключить потери (когерентность мышления = 100%). Но, согласитесь, в одном человеке все это совместить практически нереально! Наверное, такие примеры есть, но это точно исключения. Возможно, Стив Джобс был одним из таких исключений. По крайней мере, лучших Product Owner-ов я не знаю.
На практике лучший вариант - это коллаборация из двух человек. Один - с направленностью в бизнес (но это не отменяет высокую техническую грамотность), другой - с направленностью в производство. И для продукта критически важно, насколько когерентно мышление этих людей.
Вы много знаете примеров крупных компаний и продуктов, где есть настоящие (а не формальная роль) Product Owner-ы? Я не говорю, что этого не бывает, но почему-то мне кажется, что бывает толко в компаниях, выросших из стартапов (или в продуктах, выросших из внутренних стартапов компании).
Конкретная Agile методология в качестве закона - ад
Несколько тезисов о классификаторах и методологиях с этой же позиции, без пояснений:
Agile манифест в качестве принципов - добро;
Конкретная Agile методология в качестве закона - ад;
ITIL как справочник лучших практик - ок;
ITIL как культ поклонения или свод законов - зло;
eTOM как "выравниватель" описания бизнес-процессов - ок (мне кажется, это по большей части нужно для упрощения продаж ПО, автоматизирующего бизнес-процессы);
Построение оргструктуры предприятия на основе классификации eTOM - зло (хоть меня за это камнями и закидают).
Продолжите ряд.
В качестве финальной фразы:
Интерферирует только когерентное излучение.
Оценили 0 человек
0 кармы