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

Кейс: "мне Клод заменяет аналитика и архитектора" - вещает вам разработчик.

Что это означает для менеджера: разработчик просто пытается стать более значимым и создать выжженную поляну вокруг себя с целью повышения оклада.

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

То есть то, что разработчик видит аналитика в Клоде, это аналитик другого толка, аналитик по поиску пути технического решения в рамках его собственной задачи, которая - сюрприз - влетела из пайплайна управления требованиями, против которого им ведётся деструктивная деятельность такими заявлениями.

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

Спойлер: Нет, на самом деле Клод всего лишь хороший пират типового пути. Он не создаёт ничего нового. Типового - не значит лучшего или оптимального.

И тут мы подходим к тому, что в цепочке порождения ценного продукта/сервиса все таки нужны люди.

Кто у нас поставщик ценностей рынка в команде при коммуникации с рынком? Очевидно, что продажники и маркетологи.

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

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

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

Иногда в компании есть архитектор и аналитики, которые преобразуют стратегию и бизнес требования на технический язык, где разработчик чувствует себя понявшим то, что за него давно поняли те, кто по процессу управления требованиями впереди него отфильтровали и преобразовали для него в съедобный вид на его языке.

Уверены ли вы что нейронки способны это правильно сделать за вас?

P.S.: Oracle заменил людей на ИИ и качество продуктов/сервисов катастрофически поехало вниз.