Полюбите во мне программиста +7




Внимание! Текст – только для продавцов и руководителей! Программистам читать запрещено!

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

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

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

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

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

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

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

Пока не на 100% и не везде, но тенденция усиливается. Не все еще решаются требовать от программиста денег, пока просят «продукт».

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

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

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

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

Внимание, вопрос: когда в последний раз вы смотрели на результат труда программиста? Не на деньги, за которые этот труд был продан! На сам результат труда – какой-нибудь сайт, приложение, интеграцию, ERP-систему?

Результат вашего труда виден – это деньги. Вы прям их и делали – деньги. А кому виден результат работы программиста? Не, не так… Кому он вообще интересен?

Собственно, двум людям – клиенту/пользователю и самому программисту. Но и тут не всё так просто.

Клиенту интересно то, что он называет «результат» — чтоб работало, короче. Ну, примерно так, как договаривались. Чего там внутри – ему пофиг.

А внутри там… Ну, насрано, уж простите. Ступить боязно, как поле минное. А почему? Так потому, что не интересно никому, что там внутри. А по-честному, и что там снаружи – не интересно. Лишь бы акт подписали, или предоплату внесли, или подписку продлили.

Вот и остается единственное, что заставляет программиста нормальный код писать – назовём это «внутренний стержень». Нормальный код нужен только самому программисту. Правда, фиг поймешь, зачем.

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

Итак, программист пишет код и очень его любит. Этот код никто не видит, кроме программиста. Улавливаете уже? Внешний вид – формы, интерфейс – видит еще и клиент, иногда даже хвалит. Честно вам скажу: программист не особо гордится внешней формой, как правило. Она или нарисована автоматически, по декларативному описанию, или вообще к программисту отношения особого не имеет. Программист пишет код.

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

Теперь вы, наверное, всё поняли. Вы ж продавец. Как говорили великие, «если вы, продавая кирпичи, разговариваете с покупателем о его ревматизме – он покупает у вас».

Уделите 5 минут, посмотрите на интерфейс. Послушайте рассказ о том, как оно работает. Сделайте вид, что вам интересно. В код, конечно, смотреть не прошу – достаточно послушать про код. Ну, что он охрененный. И оценить не забудьте, только не переусердствуйте – фальшь не приветствуется.

И всё, он ваш. Программист, в смысле.

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

Если вы будете внимательнее к продукту, который делает программист, то этот продукт станет качественнее. Программист перестанет гадить в код, потому что ему, наконец-то – может, даже впервые в жизни – станет стрёмно.

Тут и внутренний стержень появится. Короче, всем хорошо.

Да, и – тсссс.




Комментарии (27):

  1. Malduan
    /#22129278 / +2

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

    • sergof
      /#22129364

      А что менеджер может сказать про код...

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

      • Malduan
        /#22129448

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

      • mixsture
        /#22131062

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

    • Jerry88
      /#22129416

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

      • rinace
        /#22129462

        вразумительно объяснит причины/следствия исправлений

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

        • Malduan
          /#22129490

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

        • kinall
          /#22129536

          Представьте, что вы делаете ремонт в квартире.
          Сначала вы наняли таджиков, которые за три дня поклеили обои, переложили плитку и постелили пол. Быстро? Быстро. Красиво? Красиво! Выглядит так, как вы хотели? Да. Гостей позвать можно? Конечно.

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

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

          Вот это и был рефакторинг.

          • rinace
            /#22129574

            Сорри, но аллегория, не очень. Как в общем то и любая аллегория.

            Имеем классическое определение.

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

            Ключевое словосочетание — новая функциональность.

            вы начнёте двигать мебель

            Мебель на новом месте это уже изменение функциональности и архитектуры начального проекта, никак не рефакторинг.
            Рефакторинг это например так — «Cнять обои и вместо белой штукатурки положить розовую. Поклеить обои ».

            Еще раз. Я понимаю, зачем рефакторинг программистам. Но я не могу понять, как бизнес дает на это деньги.
            Хотя конечно у меня есть подозрения зачем это делается, но это к программированию это не имеет никакого отношения.

            • NChechulin
              /#22129818

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

            • kinall
              /#22129838

              Ключевое словосочетание — новая функциональность.

              В моём примере её и не будет: квартира будет выглядеть абсолютно так же.

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

              Это будущие проблемы, которые появятся, если рефакторинг не провести.

              Рефакторинг это например так — «Cнять обои и вместо белой штукатурки положить розовую. Поклеить обои ».

              Вот именно. Я ж так и написал: ободрать всё до бетона и сделать заново, но надёжно — ведь розовая штукатурка крепче, чем белая, верно?

              • rinace
                /#22129908

                ведь розовая штукатурка крепче, чем белая, верно?

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


                А клиенту — та же самая комната. И пока меняют штукатурку и переклеивают обои — клиент живет где то в другом месте.

                По жизни рефакторинг он вот примерно такой ;-)

                • dreesh
                  /#22132362

                  И пока меняют штукатурку и переклеивают обои — клиент живет где то в другом месте

                  Для кода это не правда, он пользуется старым приложением.

                  • rinace
                    /#22132630

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

        • VolCh
          /#22133378

          Как инвестиции в обновление основных фондов или как возврат кредитов.

      • Malduan
        /#22129470

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

  2. /#22129318

    А что именно понимается под «нормальный код» и «гадить в код»?

  3. belyvoron
    /#22129320

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

  4. shadovv76
    /#22129418

    не плохой метод мотивации работника, если нельзя деньгами :)

  5. podde
    /#22129458 / -1

    fillpackart на минималках. Грустное зрелище.

    • tvr
      /#22131662

      У меня всегда было ощущение, что fillpackart и nmivan — это А-Янус и У-Янус, которые постоянно меняются местами.

    • fillpackart
      /#22132012

      Да вы охренели тут чтоли?!

      • podde
        /#22132018

        Некогда объяснять. Ставь +.

        • nmivan
          /#22132296

          А мне объясните? А то я не местный.

  6. Golex
    /#22129678

    Хороший интересный момент поймал nmivan! Даже прям вывод беднее чутка, чем само наблюдение. У нас же и в экономике и в общественной жизни то же самое: если все мерить на деньги то может и денег больше, хотя не факт, но ценность какая может и пропасть. Вот льготы монетизировали и деньги вроде есть, а льгот нет. Человеческая голова так устроена, как только слова нет (код, красота, качество, удобство пользователя, совесть, образование, вставьте свое), так сразу и явление пропадает. Мир сразу упрлощается.

    Специально для подобных точек зрения

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

  7. GamePad64
    /#22129810

    Статья описывает любое производство. Можно заменить программистов на авиастроителей, ничего не изменится.


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

  8. stokker
    /#22129836

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