Программист не должен решать задачи бизнеса

Подозреваю, что во многом это связано с вашим путём в программировании. Pl/sql, bitrix — это про бизнес. Да и c# во многом тоже.
Возможно, надо сменить область.

Но вцелом, если вы хотите поменять что-то, то надо говорить с теми, кто платит.

Как человек, который в науке не только занимается собственно наукой (выполнение исследований и разработка методов), но и воплощает эти самые методы в ПО, а также передаёт задачи на реализацию чисто программистам, которые не занимаются исследовательской деятельностью, отвечу вам, что у вас не определено, что является «задачей бизнеса» или «научной задачей». Из этого путаница в проведении границ деятельности, а значит — её интеграции в систему процессов.
Если вы даёте такое определение по признаку принадлежности всему научному процессу, тогда под определение подпадает практически любая деятельность, составляющая этот процесс. В том числе и обслуживание приборов (калибровка, замена компонент и т.д.). Очевидно, это не является научной деятельностью, т.к. на калибровку есть методика, регламент и инструкции, как минимум. Как максимум — сервисный инженер.

Ваш пример — следствие системного пробела любой нашей индустрии. А именно — перехода от «задач бизнеса» к техническим задачам, в т.ч. программирования. Причин у этой проблемы много. Основная причина — люди не мыслят и не работают в концепции «спецификация-реализация». Спецификация постулирует, что должно происходить, какими функциями и методами обладать результат, и ничего не говорит о способах и методах их реализации. Это как раз задача реализации разработать технические методы, удовлетворяющие спецификации.
В деятельности вообще и разработке в частности ничем не ограничивается количество уровней, на котором может действовать отношение «спецификация-реализация». Т.е. объект, который на одном горизонтальном уровне выполняет роль реализации одновременно может выполнять и роль спецификации для объекта на подлежащем уровне. Спецификация выражается системой требований на языке предметной области. И выражается так, чтобы вообще никак не ограничивать возможности реализации, в частности — даже не заикаться об архитектуре реализации, а говорить исключительно по своей епархии.

Вы ведь заметили, что говорите о ТЗ, т.е. техническом задании? А я заметил, что вы не говорите в терминах требований. Пробел почти любой нашей индустрии и подавляющего большинства бизнесов — в пропускании ключевого этапа разработки — разработки требований, т.е. разработки спецификации. Все сразу пытаются перепрыгнуть в техническое задание. В действительности, это просто стремление заказчика переложить заботы по разработке требований и спецификации на технический уровень, где эти проблемы, часто, нерешаемы.
А не решаемы они потому, что спецификация и требования выражают и выводятся из методов бизнеса, являющихся ответственностью и епархией заказчика. И если заказчик эти методы не разработал, то реализовывать, фактически, ещё нечего: сперва требуется разработать методы его бизнеса и из них выстроить методики. Именно их отсутствие является основной причиной провала так называемых программных проектов.
Проверить некорректность прыжка через разработку требований элементарно: ТЗ пишется в терминах той области техники и технологии, в которых требуется осуществить реализацию спецификации. А спецификация — в принципе, нет. Она пишется в терминах предметной области (в терминах бизнеса), дающих определение результату, в том числе и методам его получения. Более того, спецификация и система требований использует язык методики решения задач предметной области.
Задача разработки архитектуры — это задача, решаемая и на уровне спецификации, и на уровне реализации. Например, у каждого сетевого протокола есть своя архитектура. У каждой системы и программы, реализующих некоторый сетевой протокол — тоже своя архитектура. Первая — ответственность разработчика спецификации, вторая — разработчика реализации.

Применительно к научной деятельности, научный процесс выполняет запрос процессу разработки ПО. В этом запросе передаётся вычислительный метод, который требуется реализовать, требования к возможностям эксплуатации и интеграции. Этот запрос разработчик (не детализирую конкретные роли) своими силами переводит в техническое задание, в котором вычисляет и выбирает конкретные технические решения, формулируя систему задач на программирование.
Вычислительный метод — это результат научной деятельности. Например, решение многих задач машинной графики выполняется применением методов аналитической геометрии и физики. Затем уже эти решения оптимизируются и на уровне математики, и на уровне алгоритмов. И только потом этот результат изысканий можно реализовывать программно, т.к. получена спецификация.
Например, точно по такому же принципу построены методы оптимизации, исследование операций, теория баз данных, теория языков и компиляции, и т.д. И там вовсе не про программный код для их реализации, а про вывод и конструирование всех этих теорий и их методов вместе с их доказательствами корректности и характеристик. Потому что без них ни теория, ни метод не являются таковыми: доказательства — это гарантия их работоспособности от их разработчика, предоставляемая другому разработчику, который будет их реализовывать.
При этом прямая обязанность заказчика — организовать обучение разработчика ПО тем методам и той части предметной области, которые определяют спецификацию и требования, переданых в запросе на реализацию. Ну а прямая обязанность разработчика — освоить реализуемые методы, изложенные спецификацией, требованиями и методиками предметной области в запросе на разработку.
Как видите, проблема с «решением задач бизнеса» возникла из-за неумения бизнеса решать собственные задачи, т.е. формировать методы и методики их решения и выражать их в виде спецификаций и требований, годных для реализации. А также — из-за программистов, не умеющих работать по спецификации и требованиям.

Техника и технология не требуют от бизнеса иметь компетенции подрядчика, реализующего его запросы. А от подрядчика — знать бизнес заказчика. Вместо этого есть технология, представленная стандартным набором методов и видов деятельности, позволяющих заказчику работать с подрядчиком в условиях отсутствия пересечения по знаниям предметной области.

Чтоб вы понимали масштаб проблемы, то даже в ГК РФ в статьях касательно договоров ничего нет про подход на основе спецификации, требований, т.е. результата, возникающего в результате разработки. Там сразу говорится про ТЗ. И ведь никто даже не задумывается, что для визирования ТЗ (т.е. взятия на себя ответственности) заказчику необходимо иметь компетенции подрядчика, т.к. ТЗ пишется в терминах реализации, которыми заказчик и не должен владеть! Очевидно, это системная проблема, заложенная в законодательство, и даже просто нарушение здравого смысла: если у заказчика есть необходимые компетенции, зачем ему обращаться к подрядчику? А если нет, то и визировать ТЗ он не имеет права ввиду отсутствия требуемых компетенций.

Ох. У вас отечественная специфика. Сочувствую.

Я пока в open source проектах, исследования для которых финансируются созданными для этого фондами. И открыто и неформально и итоги исследований нужны.

Вообще в исследовательской сфере очень сильна формализация

О какой формализации вы говорите, если в результате научной деятельности даже спецификации созданных методов не делают в подавляющем большинстве случаев? И по западным стандартам, статья — это вообще научный отчёт формата «вопрос-метод-результат-обсуждение», где на метод часто выделяется абзац или два. Если бы в научной деятельности была формализация, не было бы такой вакханалии ни в научном языке, ни в научных методах и самой методологии науки, ни в методиках, разрабатываемых на их основе, ни в критериях и правилах рецензирования.
Взять, например, хроматографию и масс-спектрометрию. В них, хотя бы, есть утверждённый свод терминов, периодически обновляемый. Однако, как и везде, деятели, соприкасающиеся с этими методами исследований, да и часто сами экспериментаторы, в него даже не заглядывали. А если и заглядывали, то смыла не поняли или забыли. И при этом спокойно занимаются рецензированием статей, публикующими методы для хроматографии или масс-спектрометрии. Разумеется, на выходе получается не научная деятельность, а чисто социальная, когда есть разные религиозные кланы, борющиеся между собой.

То, о чём вы говорите касательно проектной документации, давно превратили в бюрократию, и к формализации никакого отношения не имеет. Как и к собственно выполнению методик ведения и выполнения проектов. Ну а про профанацию научной деятельности и методы прикрывания этого даже говорить не хочется. Только есть один хороший тренд: бизнес видит, кто действительно отвечает на научные вопросы, и потом к ним обращается, и не только достойно платит, а ещё и в свои патенты включает. А те, кто занимаются профанацией научной деятельности, постепенно отсеиваются и остаются на задворках.

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

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

Парни, «решать проблемы бизнеса» — это не придумывать фантики и думать, как лучше что-то продать. Решать проблемы бизнеса — это понимать, что делает ваш софт, как люди им пользуются, и проектировать софт таким образом, чтобы он качественно решал проблемы/задачи этих людей. И да, это ответственность в том числе и сеньора. На этом уровне программист должен не безмозгло кодить по спецификации, а понимать, что он делает, для чего он делает, принимать решения по тем моментам, которые спецификацией не охвачены, вносить (или предлагать вносить, в зависимости от принятых в его компании полномочий) в спецификации коррективы, если он видит в этом потребность, и так далее.
Точно так же и инженер, который проектирует мост, должен учитывать такие отнюдь не творческие, а сугубо бизнесовые вещи, как выделенный на строительство бюджет, доступность/стоимость определённых материалов, эксплуатационные требования.

Перепродать труд дизайнера, архитектора, электронщика и программиста в форме отделяемых результатов, не? Это кроме Маска (там практически коробочная сборка из сторонних компонент: единицы измерения-то метрические, чтобы исключить ошибки и проблемы перевода). Напомню, фундамент капитализма — это частная собственность на средства производства. Сотрудник — тоже средство производства.

Кому это неинтересно, тот не нанимается в бизнес.

В ситуации дефицита кадров программиста может вообще ничего не волновать. Бизнесом больше, бизнесом меньше — какая разница?

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

Так что не надо столь сильных обобщений. Да, отчасти всё так. Просто это должно волновать не каждого программиста. И не с каждой задачей.

В хорошо поставленном бизнесе программист только исполнитель

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

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

Очень не хватает специально обученных аналитиков, архитекторов — прослойки, которая сможет учесть все бизнес-процессы, текущую архитектуру, и дополнит ТЗ рекомендациями по решению задачи.
Без такой прослойки вмешательство в бизнес-процессы отдается на откуп программистам, многие из которых понятия не имеют о бизнес-процессах в компании, даже доступа к этой информации не имеют.
В итоге имеем то, что имеем: реализацию через одно место.

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

Это решение скорее не задач бизнеса, а проблем бизнеса.

В 90-е годы в «соросовских» учебниках по экономике похожие вещи писали про (сферического в ваккуме) предпринимателя, решающего свои внутренние вопросы в виде получения прибыли и пр этом случайно приносящего пользу обществу…

В результате выстраиваются иерархии, иерархии иeрархий и вырастает тот самый кровавый ынтырпрайз, в котором никто ни за что не отвечает и живёт в своём круге комфорта. И оно всё работает (пока в бизнесе есть деньги), но крайне неэффективно и многие из него бегут в мелкие стартапы, где «бизнес» сидит под боком и ты ощущаешь, что ты не мелкий винтик в неповоротливом механизме и по сути ни на что особо не влияешь, а видишь реальный результат своих действий (или бездействия) на KPI бизнеса чуть ли не каждую итерацию. Но это не для тех, кто любит копаться в своей песочнице с минимумом внешних раздражителей.

Кодит кодировщик. Джун, максимум мидл. С соответствующим уровнем квалификации и оплаты.

На мой взгляд, как программиста с 20+ стажем который уперся в потолок «инженерной ветки» развития, творчество в программировании и творчество в управлении — это несколько разные вещи. И если я например не умею управлять командой, это не значит что я не могу разработать хорошую архитектуру.

Вот и я по той же причине уже давно не работаю на дядю. Не интересно.