Практика в формате архитектурного паттерна

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

КПЗ: Паттерны в архитектуре

В рамках курса Системная инженерия есть задание описать какую-либо практику, используемую в работе, в формате описания паттерна.

Я в работе регулярно сталкиваюсь с тем, что во вновь образуемой проектной команде надо определить, кто будет продактом, кто проджектом, а ГИПом. Пробовали разные комбинации, сейчас остановились на том, что продакт и проджект для нашей специфики (малые команды, ранние стадии ЖЦ продукта) должны быть в одном лице.

Имя паттерна

Продакт и проджект в одном лице

Тип паттерна

Оргархитектурный

Ситуация/контекст

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

Проблема

У этих трех ролей есть противоположные желания в интересах:

  • продакт хочет побольше функционала, чтобы удовлетворить побольше потребностей внешних проектных ролей
  • проджект хочет поменьше функционала, чтобы вписаться по ресурсам
  • ГИП хочет делать то, что знает и умеет делать, не хочет делать неведомое

Другая проблема уже связана с агентами - каждый хочет быть поглавнее.

Решение

Роли продакта и проджекта назначаем на одного агента, а не на разных. ГИПа назначаем на второго агента. Первого агента назначаем главным в проекте, он принимает решения.

Соображения/влияние/силы

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

Но на наших стадиях “жизненного цикла” продукта и на нашем масштабе проектов скорость важнее масштабируемости.

Последствия

При масштабировании придется разделять роли на разных людей, более подробно прописывать практики, зоны ответственности, а также кто кем и как может распоряжаться.

Известные использования

В некоторых командах Яндекса это используют: https://academy.yandex.ru/journal/prodakt-i-prodzhekt-v-chem-raznitsa

На этом все.

Спасибо мне за внимани-е :)

В итоге функционала получаете побольше или поменьше? ?

В балансе:)

Тут нужно перечитать подраздел ПСМ про конфликт интересов. Хотя “понимаемый и явный конфликт интересов – это половина решения проблемы”. В малых проектах до чёртиков конфликтующих интересов, и нормально люди справляются. В больших проектах цена ошибки велика и работают факторы разведения этого конфликта по разным людям: приходится явно готовить обоснования решений при договорённостях, ошибки в рассуждениях видны третьим ролям и могут быть исправлены.

Кроме того продакт – это букет ролей (должность ведь), не знаю что там с “проджектом” по этой линии совмещения ролей.