Почему я не хотел бы выполнять роли продакта, разработчика, архитектора

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

КПЗ "Potentional energy landscape"

Почему я не хочу выполнять роли продакта, разработчика, архитектора

Продакт

Почему я не хотел бы быть продактом?

Продакт в своей предпринимательской части - предсказатель. Он реверс-инжинирит надсистему и выдвигает гипотезы о концепции использования целевой системы - какой функционал надо обеспечивать, какой сервис было бы круто, чтобы целевая система предоставляла (как конструктивное рассмотрение).

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

  1. либо чьи-то невыявленные интересы
  2. либо неоптимальный выбор концепции использования из-за недостатка данных

И вот очень не хочется оказаться тем, кто ошибся. Но это неизбежно.

Разработчик

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

И вот очень не хочется оказаться тем, кто ошибся. Но это неизбежно.

Архитектор

И снова здесь то же самое.

Приходится выбирать как в Сауз Парке в серии про выборы талисмана школы (сезон 8, эпизод 808).

И вот очень не хочется оказаться тем, кто ошибся. Но это неизбежно.

Как мы концепцию системы разрабатывали

У нас в команде есть специалист из предметной области с большим опытом проектирования и строительства складов с различной степенью автоматизации.

Концептуальные решения на уровне целевой системы (система сборки заказов для дарксторов) разработаны им. Принципы принятия решений - относительная инженерная простота и стоимость владения на горизонте 5 лет.

Можно сказать, что он выступает в ролях и разработчика целевой системы и ее же архитектора.

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

Наверное, надо в практику разработки концепции добавить больше генеративных методов из того же ТРИЗа, чтобы разнообразить предлагаемые варианты и расширить область пространства решений, в которых ведется поиск/оптимизация.

На этом все.

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

2 лайка

Так в каждой роли надо принимать весьма и весьма непопулярные решения. Так про каждую роль можно рассказать ))) Ничего не останется )))

У вас в проектах есть явная таблица разделения ответственности между ролями продакт-разработчик-архитектор?