Дисклеймер: пост хоть и публичный, но пишу его в первую очередь для себя, ни на что не претендую, ничего не жду.
КПЗ: Паттерны в архитектуре
В рамках курса Системная инженерия есть задание описать какую-либо практику, используемую в работе, в формате описания паттерна.
Я в работе регулярно сталкиваюсь с тем, что во вновь образуемой проектной команде надо определить, кто будет продактом, кто проджектом, а ГИПом. Пробовали разные комбинации, сейчас остановились на том, что продакт и проджект для нашей специфики (малые команды, ранние стадии ЖЦ продукта) должны быть в одном лице.
Имя паттерна
Продакт и проджект в одном лице
Тип паттерна
Оргархитектурный
Ситуация/контекст
Старт нового проекта, необходимо назначить роли продакта, проджекта (как эксплуатанта организации проекта) и ГИПа (как главного по инженерным решениям целевой системы в проекте), распределить зоны ответственности, а также порядок распоряжения ресурсами.
Проблема
У этих трех ролей есть противоположные желания в интересах:
- продакт хочет побольше функционала, чтобы удовлетворить побольше потребностей внешних проектных ролей
- проджект хочет поменьше функционала, чтобы вписаться по ресурсам
- ГИП хочет делать то, что знает и умеет делать, не хочет делать неведомое
Другая проблема уже связана с агентами - каждый хочет быть поглавнее.
Решение
Роли продакта и проджекта назначаем на одного агента, а не на разных. ГИПа назначаем на второго агента. Первого агента назначаем главным в проекте, он принимает решения.
Соображения/влияние/силы
В небольших проектах решение назначить роли продакта и проджекта на одного агента снижает transaction cost на договаривание этих двух ролей, снижает стоимость принятия решения. С точки зрения надежности это не очень - выходит из строя этот агент - лишаемся функционала сразу двух ролей. С точки зрения масштабирования это тоже не очень - получается у двух функциональных блоков (у двух практик) слишком высокая связность, надо развязывать.
Но на наших стадиях “жизненного цикла” продукта и на нашем масштабе проектов скорость важнее масштабируемости.
Последствия
При масштабировании придется разделять роли на разных людей, более подробно прописывать практики, зоны ответственности, а также кто кем и как может распоряжаться.
Известные использования
В некоторых командах Яндекса это используют: https://academy.yandex.ru/journal/prodakt-i-prodzhekt-v-chem-raznitsa
На этом все.
Спасибо мне за внимани-е :)