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

    image


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


    Лычки


    image


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


    • Juinor — тут меньше всего проблем с определением, начинающий программист, который только-только выучил теорию, возможно, сделал пару pet проектов. Ну или только выпустился из университета.


    • Middle — Middle — опытный программист. Разбирается, а не просто знает стек-технологии, которые использует каждый день.


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



    Хочешь не хочешь


    image


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


    Как это происходит


    Давайте разберем классический кейс, и на его примере посмотрим, как происходит решение проблем бизнеса. Прилетает задача — нужно сделать новый сайт, ничего особенного. Если упростить, то задача прилетает по такой цепочке: руководитель компании -> 1-& руководитель более низкого звена -> менеджер -> Тим Лид и дизайнер (как правило два разных отдела, поэтому задача ставиться параллельно) -> senior и/или сразу всем исполнителям. Есть два варианта дальнейших действий:


    Кейс 1. Можно просто делать, что скажут, "тупо кодить" — то есть просто все делают в рамках своих прямых обязанностей — Тим Лид обсуждает с бизнесом и заводит задачки в джире, senior продумывает архитектуру и берет на себя наиболее сложные участки, junior верстает, а middle делает обычные задачи, возможно, и сложные вещи вместе с Senior (для упрощения, все Full Stack).


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


    Что в итоге?


    image


    В рамках первого варианта, когда все "тупо кодят" — в итоге решается проблема бизнеса. Другой вопрос, что она решается не эффективно — 100% срывы сроков, костыли, передача ответственности друг другу, потом, как правило, очень долгое исправление правок и добавление "новых пожеланий заказчика". Все потому, что делали задачу, как поставил ее бизнес. Никто не сказал, что так не нужно делать — все работали как "винтики" в рамках своих компетенций и не лезли решать проблему бизнеса. Здесь не было команды. После таких проектов, как правило, отношения к разработчикам не очень. Бизнесу важен результат. Умные руководители после этого как раз нанимают Senior, которые готовы решать проблемы бизнеса.


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


    Инфраструктурные проекты


    В комментариях к статье, ссылку на которую я приводил в самом начале, советуют перейти на инфраструктурные проекты. Что там как раз можно просто кодить. Это обманчиво. Разработчики так же решают проблемы бизнеса, внутренние. Это точно такие же товарно-денежные отношения. И проблемы такие же, как и при работе над внешним продуктом компании. Другой вопрос, что, как правило, инфраструктурные проекты пишут по первому кейсу. Отсюда и результат. Но даже здесь решаются проблемы бизнеса, и программист принимает участие в решениях.


    Команда


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


    Решение проблем бизнеса != продажи


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


    Программист не должен задумываться о том КАК будут продавать, но он должен задумываться о том ЧТО будут продавать. От принятия чисто архитектурных решений (которые зачастую Senior и продумывает), скорости отклика, логики работы, дизайна (да, перед его разработкой программисту НУЖНО участвовать в проектировании интерфейса) и т.п. — зависит качество конечного продукта. Даже инфраструктурный проект продают, но внутри компании. От качества конечного продукта зависит эффективность компании и соответственно персональные плюшки (не только материальные).


    Исключения


    image


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


    Вывод


    image


    Программист ДОЛЖЕН решать проблемы бизнеса? Да, должен. На уровне своих компетенций, должности и опыта. Программист должен ПРОДАВАТЬ? Нет конечно, хотя навык далеко не бесполезный, особенно на высоких позициях. Можно ли просто кодить? Конечно, можно. Может ли Senior просто кодить? Нет, на просто кодить можно взять мидла.

    Only registered users can participate in poll. Log in, please.

    Согласны?

    • 71.1%Да518
    • 24.8%Нет181
    • 4.1%Свой вариант в комментариях30
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 313

      +19

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

        +12

        Ну, в каком-то смысле, это именно так.


        (особенно если вместо "бизнеса" поставить "потребителя")

          +4
          на самом деле там треугольник: бизнес — клиенты — сотрудники. решать надо «проблемы» всех 3 частей.

          и да, бизнес это не всегда про «продать» товар, это вполне может быть и благотворительность или какой нибудь исследовательский. тогда и цели/проблемы другие.
            +1
            Четыре части!!! Себя! Себя же забыли!
            +5
            Есть байка о рабочем на оптическом заводе. Кажется про Германию
            начала 20 века. Он полировал внутреннюю поверхность какого-то прибора которая не влияла на работу прибора и не была видна потребителю. Когда его спросили зачем он это делает, полировка ведь не будет видна. Он ответил, что бог-то видит.
            Мотивы как работников так и потребителей, которые в другой ипостаси работники, в какой-то мере иррациональны. Наука о человеке не точная наука вообще ни разу.
            Сеньоры и миддлы, решая проблемы бизнеса, создают проблемы которых до решения проблемы у них не было. В долгосрочной перспективе игра с нулевой суммой. Все умрут, солнце погаснет. У потребителя и у работника должны быть какие-то общие долгосрочные цели, что-бы игра для них была вин-вин.
              0
              У потребителя и у работника должны быть какие-то общие долгосрочные цели

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

                0
                Кто платит деньги за продукт — тот и потребитель.
                Если деньги вам идут непосредственно от новозеландской конторы — пожалуй, да, общие цели у вас есть.
                  0
                  Кто платит деньги за продукт — тот и потребитель.

                  Кому платит?


                  Если деньги вам идут непосредственно от новозеландской конторы — пожалуй, да, общие цели у вас есть.

                  Какие же?

                    0
                    Кому платит?


                    Ваша зарплата из каких средств формируется?

                    Какие же?


                    У вас — продолжать получать деньги. У них — продолжать делать свою работу с помощью вашего продукта. Но это не точно.
                      +1
                      Ваша зарплата из каких средств формируется?

                      Оу, это длинная цепочка. Новозеландская контора платит не мне, и даже не моему работодателю.


                      У вас — продолжать получать деньги. У них — продолжать делать свою работу с помощью вашего продукта.

                      Так это же две разные цели, а не "общая цель".

                        +1
                        это длинная цепочка. Новозеландская контора платит не мне, и даже не моему работодателю


                        Человечество придумало много разных вариантов товарно-денежных отношений, не все можно описать одной фразой ;)

                        Так это же две разные цели, а не «общая цель».


                        Ну нет и ладно ;) Можно сказать, что общая цель — продолжать заниматься тем же. Стабильность, наше всё. В древнем Риме у патрициев и рабов были общие цели? Но Рим просуществовал дольше, чем любая экономическая теория.
                          +2
                          Человечество придумало много разных вариантов товарно-денежных отношений

                          Тогда непонятно, зачем уточнение "если деньги вам идут непосредственно от новозеландской конторы".


                          Можно сказать, что общая цель — продолжать заниматься тем же.

                          Неа, она не общая, она раздельная.


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

                            0
                            Тогда непонятно, зачем уточнение «если деньги вам идут непосредственно от новозеландской конторы».


                            Это если хочется найти соответствие между четким и простым утверждением из учебника и унылой реальностью. Если хочется найти несоответствие — так и 2**2 == 3.999(9) на некоторых калькуляторах.
                              +1

                              В такой записи — и в математике вполне тождественны

                  0
                  Денег заработать, очевидно же.
                    +1

                    В этом смысле "у потребителя и у работника" (почти) всегда есть "какие-то общие долгосрочные цели".

                    0
                    Цели — не знаю, интересы — да много. По крайней мере, в высокой конъюнктуре рынка и низких транзакционных издержках.

                    Вообще, интересно, вы своим вопросом «подсветили», что мне лично мало нравится слово «цель», и почему это так (термин «долгосрочная цель» напоминает оксюморон).
                      0
                      интересы — да много.

                      Какие же?

                +1
                Так рабочий и решает проблемы бизнеса, просто самые базовые.
                  0
                  Скорее, не проблемы, а задачи.
                  0

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

                  +6

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


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

                    +2

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

                    +11

                    Решать проблемы бизнеса — да. Решать задачи бизнеса — нет! Это неравнозначные понятия. Задачи бизнеса — это то что решается бизнес-планированием, продажами и всем этим. Проблемы — это как раз сфера деятельности ИТ — автоматизация, повышение эффективности некоторых процессов, снижение издержек в бизнес-процессах.


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

                      +6

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


                      Да, это даже решит бизнес-задачу, но "настоящий сеньор" спросит "а какую бизнес-задачу решаем?" и узнав, что это уменьшение времени заполнения трёх форм, может предложить, например, одну форму для операции или одно заполнение ФИО на всю сессию работы с клиентом, если он хочет несколько операций совершить, а то и подтягивание ФИО из базы по предъявлению, например, карты этого банка или паспорта. А то и вообще предложит создать веб и/или мобильное приложение самообслуживания клиентов.


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

                        +1
                        Ну опять таки «бизнес-задача» и «задача бизнеса» это абсолютно два разных понятия. «Бизнес-задача» может быть, кстати, вообще не связана с, как таковым, бизнесом, это корректней называется как «кейс», или что-то вроде того.
                          0
                          А я запутался. Вы не могли бы строго описать и разделить эти вещи?
                            0

                            "Задача бизнеса" это из разряда "увеличить продажи за год на 100%" или "выйти за год на международный рынок, обеспечив за год не менее 20% доходов с него". "Бизнес-задача" — "обеспечить присутствие продающей площадки в англоязычном сегменте Интернета", которая трансформируется в техническую, например, "интернационализировать и локализовать под English US/UK русскоязычный сайт". И вот тут сеньор, получив техническую задачу, может спросить "а какую бизнес-задачу решаем?" и получив ответ "обеспечить присутствие продающей площадки в англоязычном сегменте Интернета" предложить, например, написать отдельную версию сайта с нуля. Или подрядить веб-студию, хорошо знакомую с целевыми рынками, а не пытаться самим выяснять культурные и правовые нюансы. или просто "давайте зарегаемся на и там продавать, а если пойдёт, то уже будем думать дальше"

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

                        И да всё же слово «должен» не имеет смысла за пределами контракта и закона. Зачем вам приучать людей брать на себя не чем не обеспеченные обязательства?
                          +7

                          Чет какая то каша.
                          Зачем нужны все эти ваши грэйды, если в итоге все мешается в кучу?
                          Даже сама подача "тупо кодить"… Это как? В итоге с таким полходом и получаются те самые костыли… Грэйды эти и нужны, чтобы отделить функционалов и механиков от архитекторов и аналитиков. Которые, кстати, тоже не должны лезть в "что продавать"… А должны обсуждать хотелки и бить по рукам бизнесу, так как от "бизнеса" можно ожидать, порой, фантасмогорически нереальный поток сознания. Там тоже люди, которым надо оправдывать свою зарплату.
                          И все эти "а давайте.." стоят тоже денег…
                          Итого.
                          Бизнес должен генерить идеи о том что и кому и как продать
                          Аналитики должны оценить затраты, требуемые ресурсы (которых как правило нет) и довести до бизнеса.
                          Архитекторы должны составить план как, чем, кем, когда, на чем.
                          Программисты должны реализовать в рамках девопса.
                          Все.
                          Все остальное — муть

                            +7
                            Грэйды эти и нужны, чтобы отделить функционалов и механиков от архитекторов и аналитиков.

                            Неа, не нужны для этого грейды. Для этого нужны специальности. "Архитектор" — это не грейд, это специальность или профессия.

                              +1

                              Ну или, как минимум, роль. Которую вполне может выполнять сеньор.

                              +2
                              Как правильно уже сказали — грейды ту не при чем. Грейды — это всего лишь тарифная сетка. Причем, она может перекрываться по минимальным-максимальным значениям и один человек с более высоким грейдом в деньгах может иметь столько же, сколько другой с более низким грейдом.

                              Так тимлид может занимать должность ведущего просто потому что в данный момент нет свободных должностей главного. Но по деньгам получать как главный.

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

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

                                –3
                                Зачем нужны все эти ваши грэйды


                                Затем, чтобы всегда была готовая формальная причина платить меньше.
                                +1
                                Работая в технической поддержке и дойдя до определенного уровня по должности, например, самый главный эксперт технической поддержки (аналог серьора) моим руководством предоставляется возможность самому вникать в проблему у подразделений, решить проблему самому и уведомить руководство о её решении или предлагать варианты решения проблемы, если там что-то серьёзное, либо выности на обсуждение вышестоящего начальства, участвуя потом в реализации, если это катается технической поддержки в дальнейшем. Не вижу особой разницы с программистами в этом вопросе и не понимаю с чего вдруг такие обсуждения пошли. Всё IT всегда решал и будет решать проблемы бизнеса, предлагая варианты их решения.
                                  +2
                                  Честно говоря я так и не понял в чем вы по большому счету не согласны с автором предыдущей статьи, кроме заголовка. Т.к. написали плюс минус примерно то-же самое.

                                  Тут похоже просто произошло недопонимание терминов между сторонами.
                                    +7
                                    Неуверен, попаду ли комментарием в тему, но статья навела на мысли, хочется порассуждать.

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

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

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

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

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

                                        +8
                                        В интересах заказчика всегда нанять 1го человека, который сделает все

                                        … это пока заказчик не упирается в бас-фактор или невозможность распараллелить что-то.

                                        +3

                                        Всё гораздо проще: вынуть программиста (продавца, менеджера, директора) из бизнеса и пусть зарабатывают себе на жизнь как заблагорассудится. А покамест в обойме — пусть все трое пашут как миленькие на благо общего дела и, как СЛЕДСТВИЕ — своего кармана.
                                        Разве есть другие варианты?

                                          +3
                                          Хорошо бы для начала договориться об определениях и чётко обозначить, что такое проблемы бизнеса и задачи бизнеса. В зависимости от определения проще разобраться, должен ли этим заниматься специалист того или иного профиля.
                                            +3
                                            Все эти лычки «джуниор», «сеньор» и тд условны и, в большинстве случаев, значат лишь количество опыта и размер зарплаты.
                                              +1

                                              "Лычки" позволяют хоть и в широком диапазоне, но хоть как то идентифицировать "уровень" исполнителя. Далеко не всегда зарплата и опыт (если мы говорим про размер, ну например 5 или 10 лет опыта) идентификатор. Может ли быть размер зарплаты "сеньора", а навыки далеко нет? Конечно и что удивительно — это не редкость. Может ли быть большой опыт, а фактически человек очень мало знает и умеет? Тоже может и тоже не редкость.

                                                +2
                                                Да, что эти ваши сеньоры вообще могут. Я понимаю ещё какой-нибудь программист-вицепрезидент, главный архитектор ПО (который ваяет интернет магазины на PHP) или Java-джедай хотя бы
                                                  +3
                                                  Я еще видел Амбассадоров modx и js-ниндзя
                                              0
                                              может быть нужно просто выполнять свою работу качественно? или руководство никогда ошибается?
                                                +3
                                                может быть нужно просто выполнять свою работу качественно?

                                                Тут, знаете ли, важный вопрос — а где кончается "своя работа" и что такое "качественно".

                                                  0
                                                  Так это же просто. Там же где она началась.

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

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


                                                    Впрочем, да, просто надо договариваться.

                                                0
                                                своя работа ограничена должностной инструкцией, качественно-чтоб потом не переделывать. а то, что коней на переправе меняют, кодера не должно волновать, от этого страдает бизнес.
                                                  +2
                                                  своя работа ограничена должностной инструкцией

                                                  Это плохо сочетается с "руководство не ошибается". Потому что инструкцию ту тоже руководство писало.


                                                  качественно-чтоб потом не переделывать

                                                  … видимо, рефакторинг надо заклеймить как признак некачественной работы.


                                                  то, что коней на переправе меняют, кодера не должно волновать

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

                                                    0
                                                    Это плохо сочетается с «руководство не ошибается». Потому что инструкцию ту тоже руководство писало.

                                                    Дело не в том, что оно писало что-то, а в том, что написанное оторвано от реальности в угоду формальности, а вменяемое не вменяемо.

                                                    … видимо, рефакторинг надо заклеймить как признак некачественной работы.

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

                                                      +2
                                                      написанное оторвано от реальности в угоду формальности

                                                      И? Если "своя работа ограничена инструкцией", как написано в комменте, на который я отвечал, то какая разница, оторвана ли инструкция от реальности?


                                                      в рефакторинге ключевое слово — контролируемый и оно относится к изменению условий жизни.

                                                      Я не понимаю, что вы хотите сказать. Рефакторинг — это, неизбежно, переделка. Если "делать качественно — это чтобы не переделывать", то рефакторинг — это признак того, что раньше было сделано некачественно.

                                                  0

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


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

                                                    0

                                                    Ну, одно дело "проблемы", а другое — "задачи"...

                                                      –3
                                                      Слушайте, хватит уже второй статьей разводить бред от непонимания, что такое должностные обязанности и что такое проблемы бизнеса?

                                                      Я понимаю, что на хабре в основном айтишники и им это приятно, что мол разработчики ворочат бизнес на кончиках пальцев, но я как и айтишник и бизнесмен скажу вам, что разработка программного обеспечения и проблемы бизнеса — это СОВЕРШЕННО РАЗНЫЕ понятия. Конечно же будет пересечение, но только БИЗНЕС диктует развитие бизнес ценностей.

                                                      Разработчик как профессионал должен выполнять поставленные задачи и реализовывать их качественно, СОГЛАСНО ТЗ. Это его должностные обязанности.

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

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

                                                      И теперь скажите, ГДЕ у разработчика и КАКИЕ бизнес проблемы?
                                                        0
                                                        Слушайте, хватит уже второй статьей разводить бред от непонимания, что такое должностные обязанности и что такое проблемы бизнеса?

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


                                                        Разработчик как профессионал должен выполнять поставленные задачи и реализовывать их качественно, СОГЛАСНО ТЗ. Это его должностные обязанности.

                                                        А вот это ТЗ, которое он реализует, оно зачем?

                                                          0
                                                          А почему вы считаете, что вы правильно понимаете, что такое «проблемы бизнеса», а остальные — нет?

                                                          Как минимум потому что имею отношение к созданию и развитию бизнеса.

                                                          А вот это ТЗ, которое он реализует, оно зачем?

                                                          Чтобы создавать бизнес ценности, которые хочет реализовать бизнес. То есть поймите, направление идет сверху вниз, а не наоборот. Хотите указывать бизнесу, какие создавать ценности — кто же мешает стать техническим директором, архитектором и прочее?

                                                          PS. И не надо пожалуйста передергивать факты?) Это видно на IT форуме.
                                                            0
                                                            Как минимум потому что имею отношение к созданию и развитию бизнеса.

                                                            Это значит только то, что у вас есть видение "проблем бизнеса", которое верно в рамках вашего бизнеса. Не более.


                                                            Чтобы создавать бизнес ценности, которые хочет реализовать бизнес.

                                                            … а это не решение проблем-задач бизнеса разве?


                                                            Хотите указывать бизнесу, какие создавать ценности

                                                            Нет, не хочу. Но это не значит, что я их — ценности — не создаю.


                                                            И не надо пожалуйста передергивать факты?

                                                            Факты? Какие факты? Я пока вижу только суждения и мнения, не более того.

                                                              –2
                                                              Это значит только то, что у вас есть видение «проблем бизнеса», которое верно в рамках вашего бизнеса. Не более.
                                                              Это по-моему очевидно, нет?

                                                              … а это не решение проблем-задач бизнеса разве?
                                                              Проблемы и задачи — совершенно разные вещи, это раз. Решение задач — да, для этого и нанимают персонал.

                                                              Нет, не хочу. Но это не значит, что я их — ценности — не создаю.
                                                              Вы разницу видите между планированием и реализацией? Между планированием и решением? Между проблемами и задачами? Это же причино-следсвенные зависимости.

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

                                                                Нет. Потому что статьи — они не про ваш бизнес, а про бизнес вообще, но вы все равно говорите, что они неправильные.


                                                                Проблемы и задачи — совершенно разные вещи, это раз.

                                                                Разные, но связанные. Большая часть задач (в моем личном опыте наблюдения) — это решение тех или иных проблем.


                                                                Вы разницу видите между планированием и реализацией?

                                                                Вижу. Из этой разницы, однако, никак не следует, что люди, занимающиеся планированием, или люди, занимающиеся реализацией, не создают ценностей.


                                                                Я обращаю внимание на то, что основываясь на непонимании простых понятий

                                                                И вы делаете то же самое.

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

                                                                    … а как же декомпозиция, так близкая сердцу программиста?

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

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

                                                                          –3
                                                                          это уже от программиста зависит и его навыков. отсебятину, программисту, лепить непозволительно.
                                                                            +1

                                                                            С каких пор декомпозиция работы — это отсебятина?

                                                                              0
                                                                              с таких, что мнение программиста может не совпадать с мнением руководства
                                                                                +1

                                                                                Если у руководства было мнение о декомпозиции, оно могло бы его и выразить, правда?

                                                                                  –3
                                                                                  руководству важен результат, а не то, какими путями задача решается. я вас задел за живое чтоль?
                                                                                    +1
                                                                                    руководству важен результат, а не то, какими путями задача решается.

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

                                                                                      –2
                                                                                      например, использование инструментов конца 90-х, а на преобретение современных-денег нет. вот и нужно изобретать ещё один трудозатратный велосипед. редкий руководитель делает инвестиции в образование своих поданных.
                                                                                        0

                                                                                        "Например" чего?

                                                                                          –1
                                                                                          например эдо, вещь нужная, но дорогая, как при внедрении, так и в эксплуатации, а хочется бесплатно. вот вам и задачи бизнеса.
                                                                                            0

                                                                                            Я не очень понимаю, пример чего вы пытаетесь привести.

                                                                                              –1
                                                                                              ну тогда ещё раз прочитайте, и проведите декомпозицию
                                                                                                0

                                                                                                Ничего не изменилось.

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

                                                                                                  А это здесь к чему, простите?

                                                                                                    0
                                                                                                    просто сделал вам комплимент. это я к тому, что иногда сам бизнес не знает как решить проблему, а предоставляет это технорям, и если будет неудача, то легко свалить на криворуких программистов, а если взлетит, то программистам простое спасибо.
                                                                                                      +4

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

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

                                                                                                          Так выберите одно.


                                                                                                          то с вашего позволения предлагаю закончить

                                                                                                          Неа, я вам такого позволения не дам.

                                                                                                            –1
                                                                                                            за то я вам это предоставляю, не благодарите, программист-исполнитель, а не законотворец.
                                                                                                              0

                                                                                                              Вы меня с кем-то перепутали.

                                                                                                                0
                                                                                                                ничего нельзя перепутать с трамвайной ручкой. минусите дальше
                                                                                                                  –1
                                                                                                                  вы несете откровенный бред, пытаясь съехать с темы, такой неудбной, особенно в той части, что действительно типичный представитель бизнеса ведет свой диалог именно так. программисты должны решать и задачи бизнеса и свои задачи. и желательно бесплатно.
                                                                                                                  когда вам указывают на то, что нечего перекладывать ответственность на других, что «бизнес» должен найти, подготовить и нести ответственность за решение проблемы сам, а все остальные (не только программеры) это решение должны реализовать в рамках своих обязанностей лезете в бутылку и там надуваете щеки.
                                                                                                                    +1

                                                                                                                    А по-моему, вы то ли меня с кем-то путаете, то ли читаете в моих словах то, чего я не писал.


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

                                                                                                                    Именно как?


                                                                                                                    программисты должны решать и задачи бизнеса и свои задачи.

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


                                                                                                                    и желательно бесплатно.

                                                                                                                    А этого ни я, ни (разумный) бизнес не ожидает.


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

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


                                                                                                                    «бизнес» должен найти, подготовить и нести ответственность за решение проблемы сам

                                                                                                                    Не, не должен. Почему бы?


                                                                                                                    Или вы считаете, что программист не несет ответственности за то, что его код работает так, как ожидалось в поставленной задаче?


                                                                                                                    все остальные (не только программеры) это решение должны реализовать в рамках своих обязанностей

                                                                                                                    А чем определены, собственно, "рамки обязанностей"?

                                                                                                                      –1

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


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

                                                                                                                        +1
                                                                                                                        Да где вы видели "разумный бизнес"…

                                                                                                                        На работе.


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

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


                                                                                                                        Именно представитель от бизнеса. Должен. Это его обязанности.

                                                                                                                        А, простите, где конкретно эти обязанности записаны?


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

                                                                                                                        Вы считаете себя грамотным программером?


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

                                                                                                                          +1
                                                                                                                          Да где вы видели «разумный бизнес»… только в книжках. В реалиях взять любую контору что коммерческую, что гос.контору везде одно — получить максимум прибыли/плюшек при минимуме затрат.


                                                                                                                          Это нормально для бизнеса.
                                                                                                                          Другое дело, как определяется этот минимум. И что в этот минимум входит.

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

                                                                                                              Бизнес: загрузка сервера в пике превышает 95%. Это проблема и с этим надо что-то делать.

                                                                                                              Заметьте — в данном случае бизнес понятия не имеет как эту проблему решать. Но он ее четко формулировал.

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

                                                                                                              в модуле ххххх слишком часто производятся операции с датами что занимает 27% процессорного времени модуля.
                                                                                                              в модуле уууууу при каждом запуске производится чтение из dtaara что занимает 18% процессорного времени
                                                                                                              в модуле zzzzzz слишком много переоткрытий файлов, 36% процессорного времени
                                                                                                              в модуле wwwww постоянно происходит формирование sql запроса на лету — 29% процессорного времени.

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

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

                                                                                                              И это «внеплановые» задачи. Т.е. их надо как-то вклинивать в свой план так, чтобы основное не страдало.

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

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

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

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

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

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

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

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

                                                                                                                      В конечном итоге, когда в последний раз менял работу, был выбор — мелкая конторка, которая занималась разработкой плагинов к системе архитектурного проектирования (плагины в основном направлены на осмечивание проекта и выгрузку данных в 1С). Удаленная работа, неплохие деньги, но… Полтора землекопа и полное отстутствие сколь бы то ни было внятной перспективы сколько это проживет и куда движется.
                                                                                                                      И тут в последний момент звонок из банка — давайте встретимся, поговорим. Пошел чисто ради интереса. Разговор получился очень доброжелательный — в теми людьми с которыми сейчас работаю. Рассказал чем занимался и что умею, мне рассказали что и как у них. И понял что ХОЧУ! Хочу тут работать. Несмотря на лютый легаси, кровавый энтерпрайз, несмотря на новый язык (RPG), абсолютно незнакомую платформу (IBM i, она же AS/400)…
                                                                                                                      Но тут настолько все четко организовано во всех отношениях. И отношения бизнес — разработка построены на взаимопонимании и стремлении к нахождению взаимоудовлетворяющих решений.

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

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

                                                                                                                          Естественно, что приветствуется проактивность и не приветствуется позиция «я человек маленький, хожу сюда за зарплатой».

                                                                                                                          Проактивность материально стимулируется — в прошлом году объявили повышение ФЗП на 5%. Конкретные цифры на усмотрение руководителей подразделений.
                                                                                                                          Позиция руководителей была такая — повысить всем на 5% скучно. Так что выбираем достойных и повышаем им. Без ложной скромности — мне повысили на 25% :-)
                                                                                                                          Плюс индивидуальные коэффициенты для рассчета годовых бонусов (базовый — 15% от годового оклада). Личный коэффициент по итогам работы может достигать 1.5. В целом это достаточно ощутимо в денежном выражении.
                                                                                                                          Т.е. с тебя требуют по максимуму, но и материально стимулируют если есть отдача.

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

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

                                                                                                                        0
                                                                                                                        Ни разу такого не слышал.

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

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

                                                                                                                        Только так можно обеспечить сдачу проекта в срок без адских преодолений и бессонных ночей за монитором.
                                                                                                                          0

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


                                                                                                                          Ну и тяжёлая артиллерия есть: отмена спринта. Отменяем проект и начинаем планировтаь новый.

                                                                                                                            0
                                                                                                                            Ну тут от ситуации зависит. Где-то пройдет. Где-то нет.

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

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

                                                                                                                            Сейчас тоже такое бывает — задачи идут валом, есть план. И если по какой-то из них заказчик вдруг начинает вертеть хвостом и менять хотелки, ему просто говорится — есть утвержденное BRD, работаем по нему. Хотите что-то еще — делаейте новую заявку на разработку и в очередь (BRD — оценка — FSD — разработка — тестирование — внедрение). Мы поставим в план и сделаем.
                                                                                                                            Очень, кстати, дисциплинирует, в том числе и заказчика. А то был случай когда с отчетом, который делается за неделю провозились два месяца (аналитик 4 раза ТЗ передалывал). Заказчик начал выделываться на бизнестесте — «а вот тут у нас три клиента в отчет не попадают, а нам кажется что должны попадать». Делаю полный трейслог, показываю — «у вас были сформулированы условия отбора клиентов, эти трое не проходят вот по таким параметрам». Заказчик «а давайте условия поменяем»… И начинается подгонка под ответ…
                                                                                                                            Вот такого надо избегать всеми силами.
                                                                                    –1
                                                                                    Декомпозиция и делегирование — вещи разные. Вы путаете.
                                                                                      0

                                                                                      А при чем тут делегирование?

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

                                                                                          Нет, не понимаю.


                                                                                          И да, если бизнес — это набор обязанностей, а не задач, то откуда берутся задачи?

                                                                                            –1
                                                                                            Это следствие. Это как законодательная и исполнительная власть, только с минимальными полномочиями.

                                                                                            Бизнес менеджемент издает законы, программисты и другие их исполняют.

                                                                                            Если вы делаете и то и другое, значит вы просто совмещаете разные должности. Но у вас рано или поздно начнутся конфликты между исполнителем и законодателем в одном лице в виде «7 линий перпендикулярных друг другу».
                                                                                              0
                                                                                              Бизнес менеджемент издает законы, программисты и другие их исполняют.

                                                                                              Смотрите. Вот написано было: "задача у бизнеса одна-получить прибыль". Это, в вашем примере, закон? Или что?

                                                                                                0
                                                                                                Это аксиома) Да, можно сказать закон. Она неизменна и вокруг нее, цели, идеи и создается команда)

                                                                                                Или вы считаете, что учредитель открывает джиру, читает эту задачу и чешет репу как ее выполнить?)
                                                                                                  0
                                                                                                  Это аксиома) Да, можно сказать закон.

                                                                                                  Вот вы только что написали:


                                                                                                  Бизнес менеджемент издает законы, программисты и другие их исполняют.

                                                                                                  Получается, что бизнес-менеджмент издает закон "получить прибыиль", программисты и другие этот закон выполняют. Так? Или нет?

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

                                                                                                      Нет, это в вашем понимании. Я же специально спросил, и вы ответили, что да, закон.

                                                                                                        –2
                                                                                                        То есть вы в своих вопросах выражаете только мнение собеседника, удобное вам?)
                                                                                                          –1

                                                                                                          Нет, я выражаю то, что я понял. Я потому и спрашиваю, что не уверен в своем понимании.

                                                                                    +2

                                                                                    Канонически получение прибыли — цель бизнеса, а не задача. Задачи направлены на достижение цели, например "построить завод, запустить и продавать продукцию выше себестоимости" или "написать софт, продавать его выше себестоимости" и т. п.

                                                                                    0
                                                                                    Нет. Потому что статьи — они не про ваш бизнес, а про бизнес вообще, но вы все равно говорите, что они неправильные.
                                                                                    А бизнес вообще не включает мой бизнес? Вы себе противоречите.

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

                                                                                    Вижу. Из этой разницы, однако, никак не следует, что люди, занимающиеся планированием, или люди, занимающиеся реализацией, не создают ценностей.
                                                                                    Создание ценностей и решение бизнес проблема — вещи разные.
                                                                                      0
                                                                                      А бизнес вообще не включает мой бизнес? Вы себе противоречите.

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


                                                                                      Опять же причина следствие, не мешайте в кучу.

                                                                                      А какая разница, что причина, а что следствие? В итоге решив одно, все равно решаем другое.


                                                                                      Создание ценностей и решение бизнес проблема — вещи разные.

                                                                                      Разные. Но решение бизнес проблемы обычно создает ценность.

                                                                                +2

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

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

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

                                                                              +1

                                                                              А кто может написать качественное ТЗ для программиста? Не говоря о том, что чаще всего именно ТЗ нет.

                                                                                0
                                                                                Вот хуже нету когда нет ни ТЗ, ни документации по написанному коду. Тогда и возникают ситуации (описанные в одной их статей по этой теме) когда «никто кроме васи» не знает как и почему работает этот древний модуль.

                                                                                Это очень неправильный подход.
                                                                                  +1

                                                                                  Ну вот как раз senior должен и предложить вести документацию нормальную, если её нет. Как человек, который знает или должен знать, что она должна быть.

                                                                                    0
                                                                                    Согласен.
                                                                              0

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

                                                                                0
                                                                                Все задачи бизнеса решает менеджер.

                                                                                Сам?

                                                                                  0
                                                                                  Задачи да, это его обязанность. А вот реализует их разработчик.
                                                                                  И я так и не увидел вашей позиции, только вопросы на вопросы. Складывается ощущение троллинга.
                                                                                    0
                                                                                    Задачи да, это его обязанность. А вот реализует их разработчик.

                                                                                    Как можно решить задачу, не реализовав соответствующую функциональность?


                                                                                    И я так и не увидел вашей позиции, только вопросы на вопросы. Складывается ощущение троллинга.

                                                                                    https://habr.com/post/501244/#comment_21595174

                                                                                      0
                                                                                      Как можно решить задачу, не реализовав соответствующую функциональность?
                                                                                      Скажите, кто принимает решение в вашем теле о том, чтобы идти по земле, ноги или мозг?
                                                                                      И теперь скажите вы считаете, что именно ноги занимаются решением КУДА идти? Вот КУДА — это и есть проблемы бизнеса, а перемещение — это выполнение уже заданных КУДА.
                                                                                        +1
                                                                                        И теперь скажите вы считаете, что именно ноги занимаются решением КУДА идти?

                                                                                        Я считаю, что именно ноги занимаются решением задачи "доставить меня в точку".


                                                                                        У нас точно не случилось путаницы между решением задачи (solution) и принятием решения (decision)? Потому что это два совершенно разных процесса.

                                                                                          –1
                                                                                          «Задача бизнеса», о которой писали выше — это design. К задачам как таковым это имеет непрямое отношение.
                                                                                            0
                                                                                            «Задача бизнеса», о которой писали выше — это design.

                                                                                            А, простите, из какого формального общепринятого определения вы это взяли?

                                                                                              0
                                                                                              Да хоть отсюда, например: utmagazine.ru/posts/8985-biznes-zadachi

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

                                                                                              Причем тут вообще программист?
                                                                                                0
                                                                                                Да хоть отсюда, например: utmagazine.ru/posts/8985-biznes-zadachi

                                                                                                О, спасибо.


                                                                                                "Постоянные задачи бизнеса – это такие задачи, которые предприятие будет осуществлять на протяжении всего периода своего развития. [...] Так, например, задачей косметической компании является выпуск косметики."


                                                                                                Если посмотреть на компанию-разрабочика ПО, то ее "постоянной задачей бизнеса" является выпуск ПО. Следовательно, разработчик внутри решает "постоянную задачу бизнеса".


                                                                                                Что, собственно, и надо было доказать.


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

                                                                                                Прекрасно. Вот вы создали дизайн/архитектуру. Эта ваша задача увеличения прибыли — она решена? В том смысле, что прибыль увеличилась?

                                                                                                  0
                                                                                                  Хорошо, разработчик написал код, без дизайна и архитектуры, он решил задачу бизнеса?)
                                                                                                    0

                                                                                                    Если прибыль увеличилась — то да, решил.

                                                                                                      0
                                                                                                      Ключевое слово здесь — качество. Вот как раз-таки к чему мы и пришли.
                                                                                                      Его не будет.
                                                                                                        0
                                                                                                        Ключевое слово здесь — качество.

                                                                                                        Этого "ключевого слова" в вашей задаче не было:


                                                                                                        Например, стоит задача увеличения прибыли на 1 млн рублей.

                                                                                                        … вы, кстати, не ответили на вопрос:


                                                                                                        Вот вы создали дизайн/архитектуру. Эта ваша задача увеличения прибыли — она решена? В том смысле, что прибыль увеличилась?
                                                                                                      +1
                                                                                                      То, что дизайнеры и архитекты тоже «решают проблемы бизнеса», не отменяет того факта что и программисты тоже это делают.
                                                                                  0
                                                                                  Проблема/задача у бизнеса только одна-получить прибыль.
                                                                                  Почему-то многие думают, что для того что-бы заработать нужно делать крутой софт и решать реальные проблемы, у меня плохие новости:
                                                                                  можно ПРОДАТЬ имитацию чего угодно (по красивому привлечь инвестиции).

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

                                                                                    Алгоритм (в грубом виде, без подробного рассмотрения каждого пункта) прост:
                                                                                    0. Ожидание.
                                                                                    1. Возникает проблема.
                                                                                    2. Ее фиксирует инженер технической поддержки, оценивает ее уровень.
                                                                                    3. Выполняет поиск ее решения.
                                                                                    4. Решает или передает информацию о проблеме на уровень выше для дальнейшего решения.
                                                                                    5. При накоплении множества мелких однотипных проблем или при высоком уровне важности единичных проблем бизнес решает, что требуется решение со стороны программиста и ставит перед ним задачу.
                                                                                    6. Программист решает задачу на основании имеющихся данных.
                                                                                    7. Возврат к пункту 0.
                                                                                      +1
                                                                                      Не смог пройти мимо.
                                                                                      Четко по инструкции действовали проектировщики и эксплотанты Boing 737 Max8.
                                                                                      Каждый на своей позиции не выходил за рамки своей компетенции и в принципе ей соответствовал. Более того, пока не погибло больше 3х сотен человек, все довольно успешно решали бизнес, задачи и проблемы.
                                                                                        0
                                                                                        Как, собственно, это относится к программисту, который является обычным конечным исполнителем?
                                                                                        В статье всё собрали в одну кучу создав образ «мифического программиста», который и в бизнесе разбираться должен и оценивать правильность решения и что-то еще сам придумывать и проблемы решать, но это уже не программист и этими обязанностями занимается обычно не один человек, во всяком случае, в любой крупной компании (ниже про это хорошо написано).
                                                                                      +5
                                                                                      в статье пример небольшого проекта (сайты могут быть крупными порталами, но по контексту сайт из примера видимо не из таких) который делается силами небольшой команды. В таких условиях роль каждого специалиста увеличивается и его зона ответственности тоже.

                                                                                      Но так не всё работает. Как минимум крупный интерпрайз так не работает. Об этом уже писали, я ещё раз сакцентирую внимание на том что для каждой отрасли есть свои специалисты. Бизнес-аналитики/продакт овнеры собирают требования. Архитекторы делают архитектуру. Девы — делают по этому инпуту систему. Допустим я — участник команды которая делает микросервис, один из 15 типов. Нам дают описание — вот такой АПИ сервиса. В этом случае делаете Х, в этому — Y. Всё. И технологии уже выбраны — база такая, брокер сообщений такой, язык программирования такой, фреймворк такой.
                                                                                      Где тут решать проблему бизнеса? Прийти и рассказать что я могу по-разному написать возврат json-а? Более того, если я сделаю что-то не по требованиям, допустим сделаю другую аутентификацию — вряд ли кто-то будет рад этой «инициативе».

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

                                                                                      Сегодня на хабре была статья про Боинг. habr.com/ru/post/501256

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

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

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

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


                                                                                            Ну, если конечно, ты планируешь делать бизнес-таски, а не идёшь на роль "оптимизатора наносекунд"

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

                                                                                              >Ну, если конечно, ты планируешь делать бизнес-таски, а не идёшь на роль «оптимизатора наносекунд»

                                                                                              кто такой «оптимизатор наносекунд»?
                                                                                              Мне сложно представить чтобы от знаний домена на уровне «во саду ли в огороде» был какой-то толк.
                                                                                              Конечно, верить что ты-де не просто винтик, и не просто код пишешь а решаешь проблемы бизнеса — само собой более приятно ))
                                                                                                0
                                                                                                кто такой «оптимизатор наносекунд»?

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


                                                                                                Мне сложно представить чтобы от знаний домена на уровне «во саду ли в огороде» был какой-то толк.

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

                                                                                                  0
                                                                                                  занятный пример про карту, спасибо. А с чем это связано, такие отмены?

                                                                                                  Вы имели в виду толк от программиста который работает над банковской системой или который интегрирует оплату картой на сайте?
                                                                                                  Это полезное знание. Вот только как таких раздобыть? :) Я работаю в аутсорсе, как-то не удаётся освоить хорошо какой-то домен.

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

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


                                                                                                    Тут больше про внедрение оплаты на сайт. В банках такие вещи обычно знают :)

                                                                                          0
                                                                                          Где тут решать проблему бизнеса?

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

                                                                                            0

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

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

                                                                                              Так это ровно обратно решению проблем бизнеса как раз.


                                                                                              да чтоб не меньше тысячи шкурок принес.

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

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

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


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

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


                                                                                          И под командой я подразумеваю не пару кодеров, которые реализуют проект, а всю компанию.

                                                                                          Когда в проекте сотня-две-три человек — команды нет и быть физически не может. Есть отделы, кланы и группы, как бы они не самоназывались и как бы не вещали про "one team".
                                                                                          Нижнюю границу "тут уже не команда" определить затрудняюсь, но чую, что она невысока и касается нескольких десятков человек. Возможно, не более двух.

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

                                                                                                +1
                                                                                                Программист должен ПРОДАВАТЬ? Нет конечно, хотя навык далеко не бесполезный, особенно на высоких позициях. Можно ли просто кодить? Конечно, можно. Может ли Senior просто кодить? Нет, на просто кодить можно взять мидла.

                                                                                                Вы противоречите сами себе. Сеньор получается не программист?
                                                                                                  +2

                                                                                                  Множество умений не состоит только лишь из "продавать" и "кодить".

                                                                                                  0
                                                                                                  Программист должен решать проблемы бизнеса
                                                                                                  Соглашусь с заголовком статьи только в одном случае: если бизнес, в свою очередь, качественно решает проблемы/задачи пользователя, а не впаривает ему с помощью отделов маркетинга/продаж всякую каку, заботясь лишь о собственной/личной прибыли и ублажении инвесторов.
                                                                                                    0
                                                                                                    В той статье, где программист не должен париться проблемами бизнеса, при голосовании автора полностью поддержали более 60% респондентов, а в это статье, главный тезис которой в общем-то противоположный, автора поддержали более 70%. Возникает вопрос, какова репрезентати́вность голосования и вообще что оно отражает. Возможные варианты:
                                                                                                    — красноречие авторов склоняет читателей на свою сторону, хабралюди — это люди, в общем-то, с ещё несложившимися мировоззрениями, на их мнение можно легко повлиять, красноречиво выразив свою точку зрения;
                                                                                                    — в целом голосовать склонны более те читатели, которые настроены позитивно к теме статьи, а те, что отрицательно, — скорее воздержатся от голосования.
                                                                                                    Как по вашему мнению, для чего проводится голосование и что оно отражает, есть ли в нём какие-то более интересные факты, чем те что на поверхности?
                                                                                                      +4
                                                                                                      Да не, все ок. Если внимательно почитать статьи, то они плюс/минус об одном и том-же. Разница в терминологии. В первой «проблемы бизнеса» — это продавать продукт и все согласны что это не работа программиста, а во второй «проблемы бизнеса» — это делать продукт и все согласны что это работа программиста.
                                                                                                        0
                                                                                                        В первой «проблемы бизнеса» — это продавать продукт и все согласны что это не работа программиста

                                                                                                        … кроме тех, кто сразу не согласен, что "проблемы бизнеса" — это "продавать продукт".

                                                                                                      0
                                                                                                      Программист никому ничего не должен! Он делает только то, что считает нужным!
                                                                                                        0
                                                                                                        Он кот? ;)
                                                                                                          +1

                                                                                                          Да об этом даже книги написаны! Как пасти, чем прикармливать.

                                                                                                        +1
                                                                                                        Как-то какой-то американский президент пришёл в НАСА. В вестибюле он встретил уборщика, который что-то тёр тряпкой. «Что ты делаешь, мой друг?» — «Я запускаю ракеты в космос!»
                                                                                                        Этот пример обычно приводится на семинарах по тимбилдингу, просто вспомнилось.


                                                                                                        Кому и что должен программист решается в каждом конкретном случае, исходя из должности, должностных инструкций, корпоративной культуры, личности программиста и его планов на дальнейшее развитие. Где-то достаточно, чтобы сотрудник отсидел положенные 8 часов, выдал «на гора» N строк кода. Где-то сотрудники вовлекаются в процесс, чтобы делались удобные на выходе решения.
                                                                                                          0
                                                                                                          А вот это похоже на правду — увидел уборщика, который тёр тряпкой, и спросил, что он делает. Руководство программистов зачастую такое же тупое
                                                                                                          +2

                                                                                                          Отличное мнение, коллега, только с моей колокольни вы упускаете одну важную деталь.


                                                                                                          Дело в том, что бизнес САМ идентифицирует какая у него проблема (а зачастую решение тоже определяет) и отдаёт её разработчику-проблематологу в виде указания "решай вот эту проблему" (зачастую добавляя "вот таким-то образом").


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


                                                                                                          — Мы аэропорт, мы терпим убытки. Это от того, что мы мало продаём.
                                                                                                          — Но…
                                                                                                          — Мы приняли решение что наша проблема решится если засадить взлётно-посадочную полосу картошкой.
                                                                                                          — Эээ… Но…
                                                                                                          — Никаких но, решай проблему бизнеса. Вот проблема, вот тебе даже способ решения. Иди вскапывай ВПП и сажай картошку.
                                                                                                          (через время)
                                                                                                          — Взлетающий самолёт увяз в грязи, мы неделю его вытаскивали, все рейсы отменились, мы терпим убытки! Кто там занимался этой проблемой?
                                                                                                          — Я, но эм…
                                                                                                          — Уволен!

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

                                                                                                            0

                                                                                                            Бизнес действительно сам идентифицирует какая у него проблема, как правило (все же с низу вверх так же прилетает, другой вопрос слушают/не слушают). Но то что касается неверной идентификации и дальнейших шишек в сторону программистов — это фактически первый кейс который я описал. Если это происходит постоянно, тут вступает в игру Грейд — если я Senior то это повод уволиться (Да, тут зависит конечно от человека). Если Junior, то повод молча проглатывать и нарабатывать больше опыта, потому что я понимаю — чем больше опыта, тем лучше будет следующая компания. А если не брать радикальные методы, можно просто всегда стелить себе соломку — разработчик понимает что проблема идентифицирована не правильно, либо реализация не решит эту проблему => письменно предлагает альтернативы => их не принимают и говорят что лучше знают => начинают лететь шишки, а в ответ отправляется макулатура которую отправляли перед тем как приступить к разработке.

                                                                                                              +3

                                                                                                              Поправьте меня если я ошибаюсь, но по-моему вы только что предложили НЕ решать проблемы бизнеса :)

                                                                                                                0

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

                                                                                                                  0

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

                                                                                                                    0

                                                                                                                    В данном случае ты либо переделываешь, либо делаешь по другому, и решаешь эту проблему.

                                                                                                                      0

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

                                                                                                                    0

                                                                                                                    Давайте для простоты на берегу договоримся что "не эффективно" не связано с техническими скиллами. У нас разработчик сферический в вакууме, который всё знает, всё умеет и багов не допускает. :)


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


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

                                                                                                              0
                                                                                                              Бизнесу помогает бизнес-аналитик
                                                                                                              Программист лишь следует полученному ТЗ
                                                                                                                +2

                                                                                                                Предположим что есть человек который пишет ТЗ, оно к нам прилетает. В нем есть конкретные сроки, но вы понимаете — озвученный функционал не сделать за указаное время (очень частая ситуация). Ваши дальнейшие действия? Просто следовать полученному ТЗ?

                                                                                                                  0

                                                                                                                  Откуда сроки, когда его еще не видел и не оценивал исполнитель?

                                                                                                                    +2

                                                                                                                    Исходит из:


                                                                                                                    Программист лишь следует полученному ТЗ
                                                                                                                  0

                                                                                                                  Даже если оно неполное, противоречивое или явно (для программиста) не приведёт к достижению и решению обозначенных в нём целей и задач?

                                                                                                                    0

                                                                                                                    Будет оценка, декомпозиция, рефайнмент с продактом и аналитиком: тогда все и всплывет. И самое главное, все это никак не связано с бизнесом, обычная работа обычного программиста.

                                                                                                                      0

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

                                                                                                                  +2
                                                                                                                  Какая муть! Программист это специалист в первую очередь. Чтобы он по своей инициативе решал несвойственные ему задачи он должен быть или мотивирован по самое нехочу или быть совладельцем бизнеса чьи проблемы ему нужно решать.
                                                                                                                  То, что в команде нет толковых продукт овнеров со знанием технического стека не проблема разработчика. Зачастую бизнес и сформулироать то не может какие у него проблемы.
                                                                                                                    –2
                                                                                                                    Чтобы он по своей инициативе решал несвойственные ему задачи

                                                                                                                    А почему вы считаете, что написание кода — это несвойственная программисту задача?

                                                                                                                      –1
                                                                                                                      Несвойственная задача это решать проблемы бизнеса, для этого есть отряд менеджеров и замдиректоров. А то получается как проблема бизнеса так к программисту бегут, а как делить дивиденты так программисты не причем. Давайте долю чтобы человек чувствовал отдачу от вложения интеллектуального капитала. Пока что только манипуляции.
                                                                                                                        +1
                                                                                                                        А то получается как проблема бизнеса так к программисту бегут, а как делить дивиденты так программисты не причем.

                                                                                                                        Дивиденты это скорее о вложении своего капитала. И я бы не сказал что программистам запрещено это делать.

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

                                                                                                                          То есть вы думаете, что когда программист код пишет, он это делает просто так, а не чтобы решить проблему (или задачу) бизнеса?


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


                                                                                                                          как делить дивиденты так программисты не причем

                                                                                                                          Ну так вообще-то зарплата есть. Которая платится с доходов компании.


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

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


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

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

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

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

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


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

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


                                                                                                                                Не, можно и за долю, не вопрос. Только когда проблем/задач нет, доли тоже не будет. Или, что веселее, когда два месяца пилили, а оно проблему не решило — значит, пилили бесплатно. Хорошо?


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

                                                                                                                                Ну давайте заменим "завтра" на "через год". Все равно это проблема для бизнеса. Кто ее решать будет? Отряд менеджеров или программист?


                                                                                                                                (А переработки и другие следствия "никудышного менеджмента" решаются оплатой переработок по ТК.)

                                                                                                                                  0

                                                                                                                                  Вы путаете "проблемы бизнеса" с формализацией трудовых задач для работника. Работник не предполагает работать плохо, но не стоит втягивать его в управленческие вопросы без его согласия и соотв.компенсации. и эта компенсация как и обязанности в дополнение, а не вместо обычных. А когда проблем/задач нет это значит, что они качественно решены и следовательно доля(в сумме) должна вырасти, а не отмениться, вы ж партнеры уже, что за кидок ?!)

                                                                                                                                    0
                                                                                                                                    Вы путаете "проблемы бизнеса" с формализацией трудовых задач для работника.

                                                                                                                                    С чего вы это взяли?


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

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


                                                                                                                                    А когда проблем/задач нет это значит, что они качественно решены и следовательно доля(в сумме) должна вырасти, а не отмениться, вы ж партнеры уже, что за кидок

                                                                                                                                    За что доля-то, если не делаешь ничего?

                                                                                                                                      0
                                                                                                                                      «Проблемы бизнеса» это всегда управленческие проблемы: управление требованиями, мотивацией, персоналом, стратегией, тактикой, планированием. Если бизнес не справляется с управлением, то это не ответственность работника.
                                                                                                                                        0
                                                                                                                                        «Проблемы бизнеса» это всегда управленческие проблемы

                                                                                                                                        Из какого формального общепринятого определения вы это взяли?


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

                                                                                                                                          +1
                                                                                                                                          но ведь программист не может быть экспертом по всем доменам бизнеса сразу.

                                                                                                                                          Прибегает представитель бизнеса со словами «у меня проблема, с завтрашнего дня налоги надо платить вот так, а не так, как было»


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

                                                                                                                                          Не, можно и за долю, не вопрос. Только когда проблем/задач нет, доли тоже не будет. Или, что веселее, когда два месяца пилили, а оно проблему не решило — значит, пилили бесплатно. Хорошо?


                                                                                                                                          в стартапах порой берут в долю. И может кому-то такое и подходит, почему бы и нет?
                                                                                                                                          Есть 2 варианта:
                                                                                                                                          1) исполнитель в доле. Тогда он решает проблемы бизнеса, и делит как успехи так и поражения.
                                                                                                                                          2) исполнитель — просто исполнитель, он превращает требования в код. В таком случае он не обязан решать проблемы бизнеса. Уточнить требования у BA — ок, но это всё.
                                                                                                                                          Вы же по сути хотите чтобы программист получал ставку из варианта 2) но при этом выполнял работу из варианта 1)
                                                                                                                                          это двоемыслие, типа «возьмите себе обязанности без бенефитов».
                                                                                                                                            0
                                                                                                                                            ну хз, программист должен иметь экспертизу в бухучете, я правильно понял?

                                                                                                                                            Нет, не должен. Зачем?


                                                                                                                                            В таком случае он не обязан решать проблемы бизнеса.

                                                                                                                                            Он обязан, в доступном ему объеме, решать поставленные ему задачи. Нет?


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


                                                                                                                                            Вы же по сути хотите чтобы программист получал ставку из варианта 2) но при этом выполнял работу из варианта 1)

                                                                                                                                            Я? Нет,