Как стать автором
Обновить

Комментарии 506

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

Как вариант.
На текущей работе, кстати, не напрягают. Но это редкость.

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


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

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

Поподробнее?

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

Перекатиться на си и раст?
К языку это вообще не имеет отношения.
Инфраструктурные задачи можно и bash-скриптами решать.

Утрированно — да

Блин, может это мне и нужно…
Смеётесь? Производители джинсов и лопат — главные выгодополучатели «золотой лихоравдки». За ваши «кирпичики» платят до тех пор, пока они нужны для постройки своего или продаются. Просто не всем дано осознать, что при любом раскладе, работая за деньги, они решают задачи бизнеса — осознанно или неосознанно, напрямую или опосредованно (ВУЗы, например).

И всё сводится только к «мне это интересно/не интересно/противно».
«Тыжпрограммист» получает «много» только потому, что его труд приносит 10х+ «много», иначе работодатель — «наивный инвестор».

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

А ТЭО (техник-экономическое обоснование) настоящие инженеры уже не пишут?

А когда оно от инженеров вот прямо точно попадало в цель? Эти тэо часто просто гадание на кофейной гуще.

Это уже дело десятое :) Но оно именно о сравнении денежных потоков (читай о бизнесе) при том или ином варианте технического решения бизнес-задачи. Или даже не технического, а административного типа издания приказа по компании, там где предлагалось какие-то технические решения внедрять

Инженеры, которым руководитель поставил задачу "ты — пишешь ТЭО"?
Инженеры, которые метят в руководители?
Просто очень рукастые и очень переживающие за дело инженеры?
Да.


А вот все ли инженеры к ним относятся и какова точность и качество полученного ТЭО — вопросы не менее важные.

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

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

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

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

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

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

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

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

Наука в реальности (во всяком случае та, за которую платят) — это тоже бизнес. Потому что все равно есть кто-то, кто платит зарплаты и дает деньги. Просто там другие требования и другие метрики.


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


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


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


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

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


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

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

Действительно, сейчас ситуация именно такая (с тенденцией к дальнейшему ухудшению). Однако это не данность, а результат прививания «административной» и «деловой» (в плохом смысле слова — не по Отто и не по Сименсу) субкультур к той области человеческой деятельности, которая возникла и развивалась по другим правилам, где эти субкультуры не нужны и не приносят ничего, кроме вреда (вплоть до полного извращения исходного смысла существования научных учреждений).

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

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

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

а потом как в анекдоте про блох. Под целевую тему будет подгоняться все что угодно, вплоть до анализа размера и качества козявок в носу.

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

НЛО прилетело и опубликовало эту надпись здесь
Сделай оба варианта, первый сделай личным бизнес-проектом)
Вообще в исследовательской сфере очень сильна формализация

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

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

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

С моей колокольни сеньор — это не про бизнес.
Бизнес — это продажа. Купить "птичье молоко", обернуть в фантик и продать подороже.
Сеньор просто классно умеет делать фантик.
И вы абсолютно правильно заметили, если человек готов придумывать фантик, может ему и не нужно быть сеньором.

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

То есть, быть профессионалом своего дела. Как и любой другой профессионал своего дела, бизнесмен, директор завода или главврач.
Но директор завода не выбирает способ лечения, так же как и программист не разрабатывает бизнес-план.

Программист и не должен разрабатывать бизнес-план. Это должны делать продукт-овнеры + бизнес аналитики.
Есть хороший реальный пример из строительства: архитекторы и подрядчики.
Архитекторы обрисовывают «прекрасные формы» здания, а подрядчики потом матерятся как это построить.
Настоящий архитектор знает возможности и ограничения существующих технологий.
Есть программисты которые могут разобраться в существующей проблеме, выработать правильное решение которое решает проблемы пользователя и не создает новых. При это тут нет ни слова про продажи и бизнес, чисто инженерный подход. Но если проблема большая то в одиночку ее решить либо невозможно, либо долго, поэтому тут нужна система приоритезации и распределения задач, а также программисты которые будут фигачить таски по спецификации. Кто из них при этом «настоящий» программист?
А никто, один архитектор, другой строитель. Чтобы построить большое здание нужны оба.

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

Вы про правильных архитекторов или про реальных?
Я про реальных, из опыта людей связанных со строительством в России.
Поэтому для постройки чего-то сложного привлекаются иностранные архитектурные бюро, где есть архитекторы-дизайнеры, архитекторы-инженеры, и еще куча людей которые продумывают процесс возведения целиком и по чертежам которых реально построить здание без внесения изменений по ходу строительства.
из опыта, иностранные бюро привлекаются
— ради форса и понта
— в раздутых бюджетах проще спрятать распил
— размазывание коллективной ответственности, международная юрисдикция позволяет сделать привлечение, как минимум, нетривиальным делом
— и только уже в конце, не столько сложное, сколько разворовывание выросших вдесятеро от начального бюджетов. На которые всё же надо что-то показать, что простояло бы гарантийные сроки, средствами деградировавшей инженерной школы
Вспоминается миниатюра Райкина:
Я прихожу к директору, я говорю:
— Кто сшил костюм? Кто это сделал? Я ничего не буду делать, не буду кричать, я только хочу в глаза ему посмотреть.
Выходит сто человек. Я говорю:
— Ребята, кто сшил костюм?
Они говорят:
— Мы!
Я говорю:
— Кто это «мы»?
Они говорят:
— У нас узкая специализация. Один пришивает карман, один — проймочку, я лично пришиваю пуговицы. К пуговицам претензии есть?
— Нет! Пришиты насмерть, не оторвёшь! Кто сшил костюм? Кто вместо штанов мне рукава пришил? Кто вместо рукавов мне штаны пришпандорил? Кто это сделал?
Они говорят:
— Скажите спасибо, что мы к гульфику рукав не пришили.
Представляете? Их – сто, а я – один. И все стоят, как пуговицы: насмерть. И я сказал:
— Привет, ребята! Вы хорошо устроились!

Т.е. всё равно должен быть на каком-то уровне человек, который проследит за тем, чтобы все эти кусочки кода стояли на своих местах, а в целом проект можно было «носить».
Ну для этого должен быть продакт менеджер.
Архитектор направления?

Зависит от масштаба проекта. Если его пилят три человека, то четвёртый — архитектор, — может увеличить затраты на разработку наполовину, например.

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

Затраты на разработку не меняются — тут как договоришься с заказчиком, так и будет. А вот сумму делить на N+1 это да. Но эффективность разработки при этом тоже повышается. Просто потому что есть человек, который берет на себя массу «оргвопросов».
Решать проблемы бизнеса — это понимать, что делает ваш софт, как люди им пользуются, и проектировать софт таким образом, чтобы он качественно решал проблемы/задачи этих людей.
Это, видимо, в какой-то параллельной Вселенной. А в этой я вижу, что единственное, чем обычно бизнес занимается — это максимизацией своей прибыли, а не решением проблем пользователя. Если дешевле засрать мозги юзерам новыми свистоперделками и рекламой — нам выкатят именно это, а не более качественный продукт.

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

Грустный у вас мир. Занятно, что у меня наблюдаемая окрестность в отношении еды и кино совершенно другая.

НЛО прилетело и опубликовало эту надпись здесь
есть ли есть лучшая альтернатива
Это очень важная оговорка. Чем бизнес крупнее, тем более он монополизируется. В качестве примера по «сайтикам по продажам» — Авито в РФ или OLX на Украине. Формально есть альтернативные площадки по продажам. Но по факту упомянутые — настолько вошли в обиход, что конкурентов у них нет. Ну просто из-за базы пользователей. Вот ОЛХ недавно сменил дизайн, много где напортачив. Например, он перестал влезать в экраны меньше 1280px. Как вам такой user-friendly? Туда же набивший оскомину Скайп — они там как выкатят обнову, так хоть плачь. Вот просто хочется сказать: «ну ребята, ну не трогайте дизайн — народ привык, бабушки наизусть изучили где какая кнопка...» Но нет — маркетологи, следуя догмам методичек по воздействию на психику юзеров, считают что «освежить» лицо сервиса — оно полезно… А из-за того, что культура кодинга падает, получается фейспалм. Люди в ярости, стучат кулаками по столу, но продолжают жрать кактус пользоваться ОЛХ/Скайпом etc., ибо «все сидят там — куда ж я денусь?».
НЛО прилетело и опубликовало эту надпись здесь
для получения большего числа лояльных покупателей нужно улучшать сайт
Всё так. Я сам веб-мастер и сам очень люблю эргономику. Но… редко её вижу. Чего далеко ходить — вон у Хабра с недавних пор появился прилепленный топ-бар с менюшкой. Меня бесит. Ибо лично я ей не пользуюсь вообще, а текст оно загораживает.

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

Сотрудник — собственник своей рабочей силы в капитализме. И противостояение собственников рабочей силы с собственниками средств производства — одна из основных движущих сил капитализма.

Вы про перепродажу труда, а комментарий Dekmabot, на который я отвечал — про перепродажу продукта.

Разве MS-DOS не являлась той самой перепродажей? Купить ОС у одного, продавать другим.

Да, Гейтс, как и любой бизнесмен, занимался в том числе перепродажей.
Но коммерческий успех Microsoft начался не с MS-DOS, а с Бейсиков, написанных самим Гейтсом для всех популярных моделей ПК. (За год до появления MS-DOS выручка MS уже составляла более $2M.) Монополию на рынке ПК им принесли Windows и Office, также разработанные самостоятельно.
купить "птичье молоко"

У кого? Другого бизнеса? Значит есть бизнес который производит птичье молоко?

Программист не пишит код ради кода, он решает задачи. И если нанимает программиста бизнес, ему нужно решать задачи бизнеса.

Это правильно с точки зрения бизнеса, но не всем это интересно.
Кому это неинтересно, тот не нанимается в бизнес.
НЛО прилетело и опубликовало эту надпись здесь
+1
Есть такая вещь, называется «требования», они могут быть подробными или общими, но они во-первых должны быть и во-вторых их должен формулировать отнюдь не программист.
Вот дальше воплощать эти требования должен программист, при этом как эти требования решают задачи бизнеса его в идеале не должно волновать вообще.

А требование о том где должны хранится данные, и на каком языке программа вообще должна быть написана кто должен писать? Есть требование, сервис должен "работать", и держать 1000rps, но достаточно ли этого программисту?

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

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

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

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

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

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

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

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

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

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

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

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

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


Нюансы, как я понимаю, именно в определении того, что является своим делом для программиста уровня senior. Для меня, равно как для правительства, например, России, принимающего и утверждающего образовательные и профессиональные стандарты, туда входит далеко не только чисто программирование ("создание программного кода в соответствиии с техническим заданием (готовыми специфиакциями)), но разработка требований и спецификаций, и разработка архитектуры, и тестирование...


Т.е. вы понимаете и эти принципы, и роли

Принципы понимаю, роли — смутно. Что нужно сделать — знаю, кто что должен делать "по науке" — нет. Нередко я реализовывал весь (кроме вывода из эксплуатации) цикл какой-то задачи полностью самостоятельно, начиная от идеи типа "давайте будем оказывать такую-то услугу, наша лицензия от регулятора это позволяет, а мы это не делаем" и заканчивая автоматизацией отчётности этому регулятору, включая оценку затрат и сроков окупаемости. Бизнес-задача это или нет — создание нового источника доходов для компании из "ничего"?


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

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

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

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

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

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

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

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

Решать задачи бизнеса, а не думать за бизнес, как владельцу бизнеса заработать больше денег.


Пускай владелец думает, как ему заработать больше денег — и ставит задачи.


P.S. Если программист и владелец бизнеса — одно лицо — разумеется, задача остается прежней.

Именно. И сейчас обычно говорят первое, а подразумевают второе.
думать «вместе» с владельцем. предлагать свою экспертизу для улучшения решения проблемы бизнеса/клиента.
Владелец будет при этом делиться появившимися доходами?
Зависит от владельца и от вашего контракта. И как раз таки у сениоров относительно часто бывают бонусы зависящие от оборота/прибыли фирмы.

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

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

Чем больше доход у владельца, тем больше он готов вернуть «в оборот» в компанию для мотивации персонала

С чего бы это? Многие владельцы живут по принципу «не надо чинить исправные вещи», и если все хорошо и безоблачно, то они скорее задумаются о вертолётах и шубохранилищах покупке конкурентов и агрессивном маркетинге, расширении штата, чем о новых бонусах для технарей.

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

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

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


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

Зачем гугл там делает эти свои бесплатные рестораны и топовые офисы

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

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

Нюансов много. Если бизнес покупался ради клиентской базы, то да. А вот если ради технологий…

есть "готов" и есть "инициирует сам".


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


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


Вы говорите только про второй пункт. Я же — про оба сразу

ДМС, печеньки, кофе, обеды, спортзалы и техника — это не доход, а условия работы.


И я не слышал, что где-то можно было бы сказать "Давайте вы не будете мне покупать 2 монитора по 30 дюймов, а купите 2 по 21, а разницу выплатите деньгами" или "А давайте я печеньки есть не буду, я их не ем, а разницу возьму деньгами"

Программист при этом будет рисковать собственными средствами?
Именно!
В США очень популярно часть зарплаты выдавать акциями. В прямом виде владелец делится доходами а программист рискует собственными средствами.
В Европе реже, но тоже уже встречается.
Консультанты, в каковом качестве тут предлагается поработать программисту, часто рискуют собственными средствами?
Ну так консультанту при этом за его консультации дают зарплату и премии, а не долю в бизнесе, как тут выше предложили сделать для программиста. О чём же и речь.

Если это входит в рабочий договор:


"Чувак, давай мы вместе будем думать, как моему делу заработать больше денег, а ты с этого свой рублик получишь" — не вопрос! Договор, потом вместе подумаем.


Но подразумевается-то другое: "Чувак, тыжпрограммист, придумай, как этим твоим айти срубить мне побольше бабла?"


P.S. А еще бывает, что ты придумываешь, как заработать бизнесу побольше денег, рассказываешь об этом на совещании, твой менеджер рассказывает об этом директору… и получает премию за тебя.
P.P.S. Еще и не так бывает…

Еще и не так бывает…

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

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

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

Что, прямо так в трудовом договоре и записано? Или только про оптимизацию и повышение качества кода?

Вы знаете у меня в трудовом договоре и про оптимизацию и повышение качества кода тоже ничего не написано. И что мне теперь перестать этим заниматься?

Где-то у меня точно написано что-то вроде "выявление узких мест и недостатков автоматизируемых бизнес-процессов и предоставление рекомендация по их улучшению"

Заметьте — рекомендаций. А дальше что скажут — то и делать.

Специфика IT и программирования в том, что обязанности очень трудно формализовать. Я ещё ни одной удачной должностной инструкции не встречал. Обычно там нечто не конекретное и неизмеримое, по которому можно устроить «итальянскую забастовку».
У меня в трудовом договоре написано нечто вроде «должен разрабатывать программное обеспечение». Для того и было весьма долгое собеседование, чтобы понять что я могу делать это «нечто» примерно на уровне ожиданий фирмы.
Если же Вы ищете место, где надо «писать код по готовому ТЗ», то и такое место легко найдёте. Просто ЗП будет несколько ниже.
Для того чтобы решать задачи бизнеса программист должен писать не программы, а бизнес-план.

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

"Боли" это что-то новенькое =) Обычно это называют "проблемами". =) Что опять таки тоже не задачи, и по сути вы говорите именно о них.

НЛО прилетело и опубликовало эту надпись здесь

Задачи программисту должен ставить менеджер. Он же должен объяснять, как его работа будет влиять на конечные задачи бизнеса.
Вот, допустим, вы программист. Я, как бизнесмен, прихожу к вам и говорю, напишите мне соц. сеть, которая порвёт фейсбук и заработает миллиарды. Я вам за это зарплату буду платить. Не можете? Ну какой же вы сеньор, если не способны решить задачи бизнеса!

А я отвечу что-то вроде "а какую задачу решаем?"

Как какую? Заработать миллиард владельцу бизнеса! Ну и вам чтобы на зарплату хватало.

Это цель бизнеса, а не задача.

Вам владелец бизнеса, который, кстати, зарплату платит, такую задачу поставит. Решайте ее как хотите. Вы же сеньор, должны участвовать в достижении целей бизнеса.
Вы не путаете сеньора с совладельцем бизнеса?
Путаю не я, а владельцы бизнеса или топ-менеджеры, с которыми автору статьи приходится работать.
Ну так не нанимайтесь на такую работу, проблем то.
Если должностные обязанности — решить как заработать миллиард, то это весьма особые скиллы и образование. Если у Вас нет желания эту работу делать, ищите другие вакансии. С другой стороны, за такое и платят больше.
Так это сейчас я опытный, знаю чего хочу и не пойду на такую работу.
А когда ты зеленый, но все вокруг в один голос говорят что задача сеньора — грубо говоря, зарабатывать миллиард владельцу, то им веришь.
Aeternamens все правильно написал. Я вам сходу назову 5 известных компаний в РФ, в которых я работал или был на собесе. И там мне говорили что я думать круглые сутки, как помочь бизнесу. Повышать продажи, приносить прибыль.
Чувствуете? Не писать лучше код или улучшить доступность сервисов, а думать о прибыли.
Разумеется, может мне не повезло и таких компаний с кривыми ожиданиями в РФ всего 10 штук, и я попадал во все из них. Но сомнительно.

А когда ты зеленый, но все вокруг в один голос говорят что задача сеньора — грубо говоря, зарабатывать миллиард владельцу, то им веришь.

Но с другой стороны, вот ты молодой и зелёный, тебя взяли на работу сеньором, где тебе платят зарплату сеньора, но там от тебя требуют думать, как помочь бизнесу, хотя ты хотел просто писать код.
Так вот, разве это не круто, что тебя вытащили из норы, встряхнули и заставили влезть в сферу, от которой ты хотел убежать, как школьник от медсестры с прививками, но зато которая даст тебе пачку дорогих профессиональных скиллов? При этом, минуточку, совсем не бесплатно, и главное, в молодости — тогда, когда ты хоть и будешь ныть, но на самом деле станешь профессиональнее, и потом в итоге получишь куда больше дивидендов от этого?
И я о том же! Сталкивался неоднократно с таким подходом, когда собственник бизнеса считает, что сотрудники должны сами придумать как им заработать денег, да побольше. Как правило, в этом случае перекладывается с больной головы на здоровую. То есть у собственника, видимо, проблемы с развитием бизнеса, сам он не знает, как их решить, и считает, что сотрудники должны все сделать за него. Ведь им же за это деньги платят. Задачи ставятся абстрактные, а спрос идет о том, где результат, в материальном выражении.
Такой собственник, похоже, хочет получить бизнес-консультанта по цене и на правах наёмного работника. В 2003 в отношении некоторых моих знакомых такое прокатывало…
Нормальное желание — максимизировать выгоду минимизировав расходы.
Максимизировать сиюминутную выгоду, получив навыки решения проблем в стиле «найти лоха», которые потом будут мешать, испортить репутацию на рынке труда, что заставит поднять зарплатные обещания…
Ну то такое. Существование кучи компаний, много-много лет работающих в таком стиле, доказывает, что он вполне себе жизнеспособен.
Я вам сходу назову 5 известных компаний в РФ, в которых я работал или был на собесе. И там мне говорили что я думать круглые сутки, как помочь бизнесу. Повышать продажи, приносить прибыль.
Чувствуете? Не писать лучше код или улучшить доступность сервисов, а думать о прибыли.

Несоответствие вакансии и должности встречается очень часто, и хорошо, когда Вы это распознали на собеседовании, и хуже когда после. И это не обязательно «повышать продажи», бывает ведь и так, что в вакансии C#, а работать надо на C++.
В любом случае есть только 2 варианта — согласиться пробовать новую для себя сферу (возможно, с повышением зарплаты), или вежливо отказаться.
А когда ты зеленый, но все вокруг в один голос говорят что задача сеньора — грубо говоря, зарабатывать миллиард владельцу, то им веришь.
А другие сеньоры рядом были? Что говорили они?
Так и говорили) Они сами в это искренне верят.
Но я наконец понял, что мнение других людей может быть неправильным для меня.
Посмотрите результаты опроса и почитайте комментарии, все считают по-разному.
“Opinions are like assholes, everyone has one but they think each others stink.” © кто-то.
Я вам сходу назову 5 известных компаний в РФ, в которых я работал или был на собесе. И там мне говорили что я думать круглые сутки, как помочь бизнесу. Повышать продажи, приносить прибыль.
А они сами в это верили? Или говорили просто потому что «так надо» было говорить?
А вот это не знаю.
Кто-то правда верит.
Кто-то может считать что так он будет казаться менее нужным в глазах бизнеса и боится признаться.

На такую задачу я могу предложить купить биткоинов, например :)

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

… а знаете, чем (в числе прочего) отличается хороший senior от плохого? Тем, что знает, какие задачи он не может решить.

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

Угу. Это называется "объяснить задачи бизнеса", после чего они их и будут решать.


Кстати, если владелец бизнеса собирается мне объяснять, как мне разрабатывать ПО, возможно, кто-то из нас не на своем месте.

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

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

Он знает какие задачи:


  • не может решить
  • не хочет решать
  • не будет решать

И может объяснить руководству:


  • почему задачу решать не нужно
  • почему задачу решать бессмысленно
  • почему задачу решать вредно

:)

… и еще миллион способов отказаться от задачи.

Вот да. Код пишет кодировщик. Это уровень джуна, максимум мидла.

Разработчик решает задачу. Это немножко другое.
Согласно моему трудовому договору и должностной инструкции, я не обязан «решать задачи бизнеса», под формулировку «решать задачи/проблемы бизнеса» можно подвести всё, что угодно.
Идти туда, где занимаются инфраструктурой, а не бизнес логикой.
Таких мест работы/отделов в фирмах/должностей не очень много, но они есть.
Как раз сейчас занимаюсь инфраструктурой, гораздо приятнее

Ну вот вы и нашли своё текущее место. Бизнес тут ни при чём.
Рад за вас.

Только если эта инфраструктура не часть продукта, который этот бизнес продает, иначе точно также могут тягать и зачастую даже в интересах инфраструктурщика сходить, а то сеньор все косяки свалит на него)

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

В моем случае такой бизнес-проблемой в компании NobleProg Ltd (которая специализируется на разных корпоративных IT-курсах) было большое количество по сути заваленных (превратившихся в чистую лекцию без практики) курсов. У заказчиков отдел безопасности в последний момент говорил «нет», или их просто не предупреждали, что нужно открыть доступ к какому-либо из внешних ресурсов или поставить какую-то программу на компьютеры учащихся. Мое решение: сделать так, чтобы для участия в курсах не требовалось ничего, кроме браузера. Сделал шаблоны виртуальных машин с VNC, научил менеджеров их клонировать на наших серверах, поставил NoVNC на веб-сервер, готово. С тех пор на моей памяти был только один сорванный из-за службы безопасности курс (в одном банке блокируют все вебсокеты, так как не умеют отслеживать утечки и атаки, связанные с ними).

Общее впечатление от статьи: автору не повезло, поскольку его заставляли решать задачи, которые он решать не умеет или не может.
Это решение скорее не задач бизнеса, а проблем бизнеса.
инфраструктура — это тоже бизнес, только у него другой заказчик.
На мой взгляд есть две совершенно независимые задачи:
— на основании потребностей бизнеса сформулировать ТЗ/требования
— на основании ТЗ/требований написать программу

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

Первая задача решается аналитиком, вторая разработчиком.

А вариант "на основании потребностей бизнеса написать программу" полностью исключаете?

НЛО прилетело и опубликовало эту надпись здесь

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

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

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

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

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

Правильно ли я Вас понял — уборщица тоже должна думать о бизнесе?

Притча о камнетёсах
Однажды по пыльной дороге шел путник и за поворотом, на самом солнцепеке, в пыли, увидел человека, тесавшего огромный камень. Человек тесал камень и очень горько плакал… Путник спросил у него, почему он плачет, и человек сказал, что он самый несчастный на земле и у него самая тяжелая работа на свете. Каждый день он вынужден тесать огромные камни, зарабатывать жалкие гроши, которых едва хватает на то, чтобы кормиться. Путник дал ему монетку и пошел дальше. И за следующим поворотом дороги увидел еще одного человека, который тоже тесал огромный камень, но не плакал, а был сосредоточен на работе. И у него путник спросил, что он делает, и каменотес сказал, что работает. Каждый день он приходит на это место и обтесывает свой камень. Это тяжелая работа, но он ей рад, а денег, что ему платят, вполне хватает на то, чтобы прокормить семью. Путник похвалил его, дал монетку и пошел дальше. И за следующим поворотом дороги увидел еще одного каменотеса, который в жаре и пыли тесал огромный камень и пел радостную, веселую песню. Путник изумился. «Что ты делаешь?!!» – спросил он. Человек поднял голову, и путник увидел его счастливое лицо. «Разве ты не видишь? Я строю храм!»

Прекрасно её знаю. Только это про мотивацию персонала.


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

не та призма у вас.


Задача бизнеса не просто как можно меньше тратить, а получить максимально прибыли при минимальных затратах.


Если перевести на программирование, но задача программиста написать как можно более эффектиный код с меньшими трудозатратами. И тут вы начинаете балансировать:


  • с одной стороны, самый эффективный код — код, не исполььзующий библиотек-прослоек и написанный фактически на машинных кодах
  • с другой стороны, меньшие трудозатраты — переиспользование библиотек и использование языков/фреймворков, позволяющие вам писать функционал быстрее

Способность программиста не просто видеть, но понимать и применять это и отличает (как один из пунктов) мидла от сеньёра.

Так должна ли уборщица думать о бизнесе?

Холодная вода — 1 сантик
Горячая вода — 5 сантиков
Бумажное полотенце — 5 сантиков
Туалетная бумага(обычная) — 1 сантик
Туалетная бумага( не рвущаяся) — 5 сантиков
Жидкое мыло — 5 сантиков
Открыть дверь туалета — 1 сантик
Какое поле для думания о бизнесе, и это только туалет, а возьмем коридор:
Пройти по коридору не обруганным матом — 5 сантиков
Пройти обруганным матом 1 сантик
Пройти молча — 1 фертинг:-)

Больше денег, точнее прибыли- это не задача бизнеса, а цель

Так должна ли уборщица думать о бизнесе?

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

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


И только если она сама заранее подумала, до всех бумаг и объяснений "как тут убираться" — то да, тогда это она подумала

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

Вот именно так и было. Ценили и платили, за то что директору не нужно расписывать в указах «быть улыбчивой, не быть вахтёром, не протирать мониторы грязной тряпкой», а можно поставить задачу «сделать чисто» и получить решение.
— Каменщик, каменщик в фартуке белом,
Что ты там строишь? кому?
— Эй, не мешай нам, мы заняты делом,
Строим мы, строим тюрьму.

Валерий Брюсов

ваша позиция — я не хочу думать "зачем" я это делаю, я просто хочу делать что скажут. В армии такой подход — единственно верный, в бизнесе чаще всего — нет.
Но все люди разные, и много в том яисле и таких, как вы. Все прекрасно это понимают, поэтому есть должности Тим Лид, Продакт Менеджер и ещё куча других, которые любят думать над бизнес-задачами и превращать их в отформатированные таски в джире для таких как вы.

Хороший исполнитель, это как качественная шестеренка в большой машине. Но хочешь больше творчества — тим лид, архитектор/менеджер и т.д.

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

И большой вопрос, что именно происходит на этих совещаниях с бизнесом. Я периодически принимаю в них участие и, обычно, вижу свою роль в том, чтобы вовремя сказать «Подождите минутку, коллеги: если мы будем делать вот так, то всё сдохнет очень мучительной смертью. Может мы упростим вот здесь и здесь, это выкинем как ненужное, а вот этим озаботим коллег, отвечающих за смежную систему?»

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

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

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

Возможно, у меня с вами и автором разное видение того, что такое «задачи бизнеса». В моём понимании, в контексте возмущения «не хочу решать задачи бизнеса, хочу программировать», это все противоположное решению программистских задач красиво, интересно, с проявлением творчества, перепробовав энное количество подходов и выбрав лучший, bleeding edge и state of art. То есть все, чему как раз и мешают «граничные условия»: мы не можем переписать это легаси на последней версии языка, потому что оно просто приносит деньги, и нужно просто латать некоторое количество багов в неделю, а не делать проект лучше, это бизнесу не нужно.

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

Бизнес любит тех, кто ему помогает. Если вы решаете его проблемы, то бизнес это ценит и отвечает взаимностью.

Конечно, никто не мешает вам сидеть серой мышкой, работать с 9 до 17 и что-то там программировать, но тогда и отношение бизнеса к вам будет соответствующее.
НЛО прилетело и опубликовало эту надпись здесь

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

попробуйте посмотреть в сторону DDD, где программист работает вместе с бизнесом
Я наверно старею :), но мне буржуйская терминология «сеньор-помидор» (прям как в Чиполлино) всегда режет слух… В принципе здесь ответ и заключается. Я ставил себя на место бизнесмена и приходил к выводу, что для стабильного зарабатывания денег лучше нанимать не плохо управляемых гениев, а легко-заменяемых программистов-винтиков. Соответственно под этот конвейер определенным образом настроив бизнес-процессы. Поэтому да, за редким исключением сама система этих рангов заточена на решение бизнес-задач, на конвейер по сути.
НЛО прилетело и опубликовало эту надпись здесь
Вот и я по той же причине уже давно не работаю на дядю. Не интересно.
Программист должен решать задачи бизнеса, занимаясь при этом своим делом, — т.е. программированием.

Тавтология? Да, но увы, не всем доступная.
Вам тогда не в программирование надо, потому что это прикладная область. Вам тогда в компьютер сайнс надо.

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

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


Нет, я не бизнес. Я сеньор, тимлид, техлид, или как это еще можно назвать… Я бухаю с генеральным и поэтому мне доступны знания с другого берега. Например nivorbud совершенно прав про "винтиков": бизнесу не нужны гении, не нужны даже инженеры. Ему нужны легко заменяемые и управлемые винтики. Увы опять.

бизнесу не нужны гении, не нужны даже инженеры. Ему нужны легко заменяемые и управлемые винтики.

Откуда столько догматизма?) Ведь разный есть бизнес. И, как правило, все от конкурентного преимущества зависит. Условно, если бизнес зарабатывает на изготовлении пластиковых окон, и программист ему нужен для поддержания сайта и допиливания 1С, то да, гении задаром не нужны. Но есть ведь небольшое (да, реально небольшое) количество бизнесов, где идет прямая конкуренция ИТ-решений, как, например, HFT-фонды, где самый быстрый робот отнимает долю рынка мгновенно после запуска, или создание и продажа софта с высокой инженерной сложностью, как СУБД, движки для создания игр или компьютерное зрение, или работа с закупкой рекламы в реальном времени. Что-то у меня есть сомнения, что на легко управляемых посредственностях заработаешь хоть $1 в таких сферах.

Бизнес платит программисту за его работу. А будет ли написанная программа решать задачи бизнеса — проблема грамотно поставленного тз и менеджера или владельца бизнеса.
То, что вы там бухаете с генеральным, не делает вас хранителем секретных знаний. Даже генеральному может быть пофиг на бизнес, если он не его владелец. Заведите свой бизнес, очень много нового узнаете.

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

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

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

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

Когда я был ТимЛидом в маленькой компании так и было — я был всеми и сразу.
Програмный инженер создает автоматы как продукт интеллектуальной деятельности, которые встраиваются в деловые процессы и обеспечивают их деятельность, более или менее, частично или приципиально. Ситуации по отношению к автоматизации разные.
Должен или не должен это вопрос договоров (фактических), в частности, включающую отвественность и отдачу от произведенного интеллектуального продукта.
Если некоторые управляющие участники обесценивают продукт работы програмного инженера, входящий в общий продукт, то возникает подобная статья.
Или переоценки программного инженера стоимости своего продукта, так тоже бывает.
Как следствие не-договоренности.
Да разумеется программист не должен решать задачи бизнеса. Программист вообще никому ничего не должен, помимо уже взятых на себя обязательств. Да и труд у нас исключительно добровольный.

Другое дело, что бизнес не должен, (и самое главное — не будет) особо платить программисту, если тот не решает его задачи. Неособо — будет, и такой работы на самом деле много, в том числе и программистской. Идите к тем, кому нужны работники делать работу руками за деньги, а не к тем, кто ищет способных-креативных-инициативных. Контор первого типа весьма хватает.
Инженер, который строит мост, должен ли вообще задумываться о том, как этот мост будет окупаться? Вообще нет, его задача — спроектировать и построить мост, который уложится в сроки, в смету и простоит указаное по плану количество лет.
Извините, но этот пример, как и следующие — полная чушь. У вас есть непонимание того, что значит «задачи бизнеса». Инженеру не нужно продавать — на это есть продажники. Инженеру нужно делать так, чтобы его решение соответствовало требованиям.

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

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

Не знаю, на мой взгляд как раз таки работа сениора и заключается в том чтобы объяснить почему «некрасиво с точки зрения кода и архитектуры» в результате приведёт к проблемам для того самого бизнеса и к потере денег.

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

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

Инженер, который строит мост, должен ли вообще задумываться о том, как этот мост будет окупаться? Вообще нет, его задача — спроектировать и построить мост, который уложится в сроки, в смету и простоит указаное по плану количество лет.

И неужели при этом инженер не должен думать как сделать этот мост так чтобы пользоваться им было «удобно и комфортно»? На мой взгляд должен. И это как раз и есть «решать проблемы бизнеса».
НЛО прилетело и опубликовало эту надпись здесь
Ну вот точно так же на мой взгляд и с кодом. Просто писать код по ТЗ это задача для «инженеров», то есть миддлов/джуниоров. А сениор он и является тем самым «архитектором», который должен думать о том чтобы в первую очередь «мост стоял», но чтобы при этом он ещё и был «удобным».

А вот что считать «удобным» в каждом конкретном случае сениорам расказывают менеджеры/ПО/UX-специалисты и кто там ещё есть из всей этой братии.

П.С. Ну или кто по вашему должен брать на себя роль такого вот «архитектора» в разработке софта?
НЛО прилетело и опубликовало эту надпись здесь
Не их задача решать что правильно, а что нет.

А чья тогда? Сеньор — это, по сути, одна из самых высоких технических компетенций в команде. Он тоже решает, что правильно, а что нет. И если ему приносят ТЗ, которое по его мнению, «х...», в его ответственности почёркать, написать, где и почему х..., и как должно быть на самом деле, и вернуть на доработку.
Сеньоры тоже должны писать по ТЗ. Не их задача решать что правильно, а что нет.

Кто там решает это вопрос отдельный. И зависит скорее от того как выглядит иерархия и организация процессов. Архитекторы тоже не всё сами решают.

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

И самое главное если по вашему сениоры о таком думать не должны, то кто тогда должен о таком думать? Ну вот кто у вас на фирме занимается такими вещами? Неужели вообще никто?
НЛО прилетело и опубликовало эту надпись здесь
Если нет, то он решает в рамках поставленного ТЗ.

Ну то есть если у вас сениору положат на стол абсолютно бредовое ТЗ, то он молча будет по нему работать и даже не попытается предложить более адекватный вариант?

Из того что получается хня, не его забота.

Вот честно, не понимаю как так можно работать. Это же себя не уважать…

Сеньер не архитектор. Это параллельные ступени в моем понимание. Кто-то идёт кодить, а кто-то идёт в архитекторы.

Так архитект(назовём его так чтобы отличать от архитекторов в строительстве) он действительно совсем другими вещами занимается. Он грубо говоря следит чтобы архитектура всего проекта в порядке была. И скажем следить за usablity/логичностью/адекватностью того что там требуется в каждом отдельном ТЗ у него обычно просто времени не хватит.

НЛО прилетело и опубликовало эту надпись здесь
Да да и да. На все вопросы

Но тогда чем такой сениор отличается от миддла? Зачем платить ему больше зарплаты если миддл с задачей «просто написать код по ТЗ» обычно справляется не хуже.

Лично меня? Коробит.

Ну вот опять же не знаю как для вас, а лично меня что бездумно делать по бумажке напрягает гораздо сильнее чем даже «думать как продать продукт».

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

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

Ну это вечная история о том, что разные люди понимают эти термины по-разному, а каких-то стандартизованных определений нет.


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


Если ТЗ уже положили и утвердили (даже после возражений синьора о том, что в нем есть проблемы) — ну окей, кто платит тот и заказывает музыку, сделаем. Желательно только иметь документально подтвержденные (в виде сохраненной переписки, например) свидетельства того, что "а я же говорил!". Чтобы когда (и если) все все-таки грохнется, синьора не сделали крайним в духе "А чо ты не предупреждал? Говоришь, предупреждал? Я не помню, не было такого".

Синьор может решать задачи по проекту в целом, в принципе он может написать все с нуля в одиночку (вопрос лишь во времени) и оно взлетит.

Если человек исключительно пишет по готовым ТЗ, то в моём понимании это не «решать задачи по проекту в целом». То есть даже если он в теории на такое и способен, то он всё равно это не делает. То есть мы имеем сениора, который решает исключительно миддловские задачи…

Вопрос в детализации ТЗ. Там обычно не прописывают технических деталей (ну или может мне просто не везло видеть полные качественные ТЗ). Обычно там просто хотелки в духе "система должна обрабатывать стотыщ запросов в секунду, иметь вот такие и такие типы операций, админский интерфейс должно позволять настраивать вот это и это, а формула для работы вот такая".


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


По мне это все и есть сеньорская работа

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

Как правило прописываются метрики удобности и комфортности — время отклика, или необходимый набор операций. ЧТО надо сделать, а не КАК.


А как именно их достигать технически — это уже задача разработчика. И как раз тут должны решать синьоры-помидоры-архитекторы.

А задать вопрос "а зачем нам это надо? Может есть готовые решения? Или можно решить проще? " — это чья работа?

ну как бы… позиций программистов слишком много, чтобы утверждать так обо всех.
хороший релевантный вашему сравнению вариант: сео.
да, непрограммист, который решает задачи именно бизнеса.
отсюда можно вывести сотни похожих вариаций вебкодеров, когда код и архитектура решений говно, но пипл хавает, поэтому…
>Авиациионный инженер не должен думать, как же компании надо будет окупать рейсы
смотря какой. гражданский именно об этом и думает. военной авиации — немного другие задачи.

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

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

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

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

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

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

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

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

Берём одно и то же ТЗ, например на разработку платёжной системы и даём двум сеньорам. Один только что закончил аналогичную, другой всю жизнь делал интеграцию с 1С. Первый уточнит пару деталей, а потом сделает так, что заказчика устроит (после небольших правок).


Второй начнёт работу, начнёт разбираться в предметной области и плакать о том, как «меняются требования». «Ой, а вы не сказали про X, это новое требование и оно разрушит всю архитектуру». Конечно не сказали, это платежная система для банка, все подобные системы за последние 20 лет умеют X, это стандарт де-факто, о котором все знают.


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

Ох какой знакомый пример. Делал софт для MPOS терминала, не имея вообще опыта в этом. Ух у нас чуть ли не месяц ушел чтобы сделать функционал отмены операции. Потому что оказывается там надо было ref number проставлять не новый, а такой же как у отменяемой операции. Нигде про это не сказано в документации, так как для тех, кто в этой сфере работает, это считается очевидным. А для нас, людей со стороны, это вылилось в огромную трату нервов и времени, и конечно все сроки полетели.

Есть сениор, который может в паттерны, архитектуры, подходы.

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

Я видел подобные условия, но в 100% случаев с моей стороны прокатывало добавление встречного пункта, например:
Дополнения к первоначальной спецификации, предлагаемые со стороны Заказчика, которые вводят новый функционал, либо изменения описанного в спецификации, вносятся путём подписания дополнительного соглашения к настоящему договору, с утверждением стоимости и сроков выполнения этих работ.
Согласен. Вполне себе рабочий вариант.
НЛО прилетело и опубликовало эту надпись здесь

А это как? Подрядчик вправе требовать изменения стоимости, но Подрядчик несёт риск удорожания (то есть всё что свыше изначальной цены из договора — за счёт Подрядчика?) Это будет стоить дороже на n рублей, но мы сами себе заплатим?

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

Чтобы не повторяться, также см. habr.com/ru/post/501244/#comment_21595036

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

Формулировка как формулировка. Да, с одной стороны цена действительно фиксируется на стадии подписании договора. Но, с другой стороны, цена не ограничена потолком, если будет экономически обоснована.

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

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

Правильно ли я понял, что заказчик может уточнять (считай, менять требования), а исполнитель при этом не может уточнять сроки? Решение простое — предложить свой вариант договора, а если откажутся — это не самый последний заказчик на земле.

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

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

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

Зависит от задачи. В большинстве случаев это симбиоз ролей аналитика и разработчика — первый проанализирует, что нужно сделать, а последний срубит те идеи первого, которые по каким-то причинам неосуществимы. Иногда эти две роли может совмещать один человек. Но чаще двое — менеджер как половина аналитика и разработчик как вторая половина аналитика :)

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

Ещё раз. Это не категория, это роль.


Категории условно три — джуниор, мидл, сеньор. Они обозначают мастерство. К примеру, сеньор рубист, джуниор js или мидл аналитик. У одного человека обычно несколько категорий, но себя он ассоциирует с самой старшей.


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

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

Для начала оцениваю интеллект — если тупой, то прекращаю сотрудничество. Кстати, употребление более одного раза в разговоре по существу ссылок на свой профессиональный уровень является приговором о полной профнепригодности.

Далее. Если человек умный, то смотрю на уровень его любознательности. Если человек ждет, что ему принесут все на блюдечке, то расстаемся через некоторое время (это время нужно для того, чтобы вдруг у человека появится интерес). Просто нет желания в будущем постоянно пинать умного человека.

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

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

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

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

Это младший инженер. Старший как раз и будет участвовать в совещаниях, обсуждая плюсы и минусы сования большого двигателя под крыло Боинга 737.
Художник с детства мечтал о том, как его рисунок на коробке хлопьев будет способствовать увеличению продаж?

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

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

Кроме того, что программист не хочет, есть же ведь что-то, что он хочет? Идеальный вариант — искать такую работу, где будут платить за то, что и так хочется делать.
В «дикой природе» такой вариант очень редко встречается. Успешные случаи для технических специалистов (не управление) — это очень хорошая экспертиза в какой-то области. Тогда к человеку приходят с деньгами, ради этой экспертизы. Другими словами — когда рынок его, а не работодателя.

Гораздо чаще ситуация, когда есть «задачи бизнеса» с одной стороны, и деньги, примерно с той-же стороны.
Хорошая архитектура решения, поддерживаемый код и так далее — это же всё часть решения. То есть, всё это нужно делать в рамках решения задачи бизнеса.

Инженер, который строит мост, должен ли вообще задумываться о том, как этот мост будет окупаться?


У инженеров в ходу есть термин «технико-экономическое обоснование». Когда есть несколько вариантов, которые «укладываются в известные требования», берут эти требования, эти варианты, и идут к заказчику с вопросами, ответы на которые, позволят выбрать итоговый вариант. И эти вопросы — всегда на более высоком уровне, нежели работа инженера. Инженер не обязан понимать тонкости, но умение сформулировать вопрос — ключевое.

Если инженер не умеет, он скорее всего — просто хороший рабочий, мастер.
Если программист не умеет — он кодер.

Я осознал что мне наплевать, как бизнес будет монетизировать мой труд. Пусть этим занимаются менеджеры, продажники, маркетологи и product owner.

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

Я бы посоветовал разработчикам, которые думают о проблемах бизнеса, открыть свой бизнес и думать о нем, это будет полезнее для всех.

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

А значит гении типа Фабриса Беллара это просто мидлы?

Ты серьёзно ждёшь ответа от человека, который не сечёт разницу, между мидлом и сеньёром про какого-то там Беллара?

Это же могут прочитать дети и люди с ранимой психикой.

И тут я понял, что решать задачи бизнеса — думать о том, как принести работодателю больше прибыли.

А почему вы вдруг решили, что ваше понимание того, что такое "решать задачи бизнеса" — оно правильное?


Потому что, скажем, для меня "решать задачи бизнеса" — это писать ПО, которое помогает людям делать их работу. Надо, скажем, кому-то считать коробки на складе — а мы ему сканер, которым он штрих-коды напикал и все уже где-то в отчете у главного лежит. Или, еще лучше, на телефон сфотографировал стопку коробок, а компьютерное зрение их посчитало.


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


Вот оно, решение задачи бизнеса.


И знаете, что самое забавное? Это задача не только senior software developer. Это задача — иногда не напрямую, иногда через несколько (десятков) прослоек — вообще любого разработчика, который работает в прикладной разработке.


А совсем не "думать о том, как принести работодателю больше прибыли".


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

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

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

Ну это тоже, да.

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