Как делать карьеру программисту, не решая задачи бизнеса

    Статья Программист не должен решать задачи бизнеса вызвала неслабое обсуждение (и даже ответ с прямо противоположным утверждением).

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

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

    В своей первой статье на Хабре я рассматривал ситуацию с позиции нанимателя (бизнеса), и объяснял, принципы, которыми руководствуюсь, чтобы найти людей, которые решат задачи бизнеса. И почему это так важно.

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

    Disclamer
    Речь будет идти о примерах бизнеса, где технологии не являются конкурентным преимуществом. Совпадения с реальными людьми случайны. Примеры приведены для технической карьеры без ответвлений в сторону продукта, ПМства, продаж, то есть, Junior -> Middle -> Senior -> Lead dev -> Tech lead -> Architect -> Chief architect -> CTO.

    Постановка задачи


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

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

    Конфликт


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

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

    И тут есть острейший конфликт. Потому, что своевременные, надежные, прогнозируемые, дешевые и хорошо поддерживаемые решения делаются на проверенных временем технологиях. Условно, если админка вашего интернет магазина с ядром на ASP.NET написана на WebForms, и авторы кода все еще с вами и не собираются уходить, то панель управления новосозданной рекомендательной системы тоже стоит писать на WebForms, хоть связка .NET Core + Angular + TypeScript в 1000 раз лучше, да и вообще WebForms это зашквар. Ведь, команда, написавшая 500 форм, напишет 501-ую быстро, надежно, обходя грабли. И бизнес получит хорошее решение.

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

    Понятно, что названная ситуация утрирована. Но суть остаётся той же вне зависимости от домена и технологий.

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

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

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

    Пути решения


    Итак, вот представим себе момент, когда программист осознал, что бизнес от него захотел ещё чуть-чуть подеградировать (ладно, скажем, отсрочить свое развитие) ради общего дела. Что можно сделать?

    Подчиниться. И потерять в своих интересах. Комментарии излишни.

    Прямо пойти на конфликт. Так и сказать, мол я вам не раб. Хотите примитивный копипастный код с глубоким знанием бухучета, — ищите дурака. А я такое делать не буду. Возможно, один раз прокатит. Но о карьере тут говорить не приходится.

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

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

    Тут то мы и рассмотрим несколько увлекательных историй.

    История 1. Про руководителя департамента Василия


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

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

    Флагманский продукт департамента Василия, — автоматизированное рабочее место (АРМ) фьючерсного трейдера, помог заработать очень много денег, а за годы эксплуатации в нем выловили почти все баги, и дополировали до блеска. Из проблем было то, что он являлся десктоп приложением для Windows (в то время, как все вокруг перешли на веб), и в качестве СУБД использовал MSSQL, что, по мнению Василия, тоже было каменным веком, ведь реляционные СУБД использовали, пока люди не научились делать нормальные базы.

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

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

    Спустя два года решение было в проде. Свежие фреймворки, MongoDB, DDD, работа из браузера, ни единого байта из терминала для фьючерсов… Правда, горы копипасты, архитектура, не позволяющая интегрировать алгоритмы без костылей, переписанные с 0 модули, где элегантные алгоритмы из фьючерсного АРМ были заменены тоннами бойлерплейт кода. Василий, правда, неплохо поднял свой авторитет. Опционное АРМ еще долго приводили в пример другим менеджерам. Спустя пару лет Василий таки попал в опалу, но это уже другая история.

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

    История 2. Про лид дева Антона


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

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

    История про архитектора Ивана


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

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

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

    Итог


    Хотите вы этого или нет, но ради карьеры, $ и возможности заниматься интересными для себя вещами придется, как минимум, говорить и думать о ценности для бизнеса. Да, можно ее приносить, не приносить, или даже приносить отрицательную. Но в этой системе отношений чем длиннее выглядит контролируемая вами цепочка создания ценности для того, кто платит, тем сильнее будет переговорная позиция и возможность делать то, что вы хотите, а не декларируете.
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 85

      +11
      История 1:
      Вы вообще хоть когда-нибудь видели 20 летний легаси проект? Он работает да. И часто неплохо работает. Но там костыль на костыле и как и почему оно работает уже обычно никто не знает. Перетаскивать такое на другую платформу это пусть страданий и боли. Да-да писать only Win сейчас это тупик. Телефоны, маки без них проиграешь. В вашем примере трейдер точно хочет и то и другое.
      Иногда надо говорить все, точка. Пришло время переписать. Если у бизнеса есть время и деньги на такое это же великолепно.
      Срок жизни развивающегося проекта в 20 лет это уже перебор. За это время изменилось примерно все.

      История 2:
      Про басфактор вы тоже не слышали? Внутреннее обучение, лекции от Антона, митапы для поговорить. Да-да это все потеря денег и вообще разработчики работать должны, а не за пиццей обсудать уже сделанные вещи. Зато команда будет в курсе что почему и как сделано.
      Если вам достался разработчик уровня FAANG используйте его правильно. Он на самом деле может клевые вещи делать.

      История про архитектора Ивана:
      Что это у вас за сеньеры которые не в курсе общего виденья? Это же их прямая работа. Знать на каком-то уровне всю или хотя бы большую часть кодовой базы своей команды разработки.
      И опять тот же басфактор. Кто мешал потратить время на то чтобы сеньры разобрались во всем? Просто ставить им задачи из разных частей проекта. Будет не так быстро, зато басфактор вырастет. И увольнения пары человек можно будет не бояться.
        +4
        Ок, проясню немного, чтобы не плодить домыслы.
        История 1: 20 лет было карьере Василия, а продукту было года 4, причем до него Василий с командой уже имели опыт написания АРМ для фьючерсного трейдинга, и тот, продукт, о котором идет речь, уже был переписанной версией с учетом архитектурных проблем и костылей. Ну а насчет желаний трейдеров работать со смартфона, — такое требование не имеет смысла, ведь трейдеры в данном случае это люди на зарплате, и работают исключительно со своих корпоративных рабочих станций. Разве что, могло бы иметь место какое-то простенькое веб-приложение для отчетности, чтобы главный трейдер и топ-менеджеры могли посматривать, но не более.

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

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

          2. Это проблема руководстсва и менеджеров, а не Антона. Он любит и умеет писать код и проектировать системы. Он этим и занимается. Бегать и организовывать всё остальное должны менеджеры. От него только подготовиться и рассказать другим разработчикам. Что-то еще требовать от разработчика в таком случае это лишнее.

          3. Басфактор 1. Почему один человек все решает? Почему никто не в курсе что сеньеры не в курсе всего проекта и у них нет задач на разобраться и допилить доселе неизвестные им куски? Чем там вообще менеджеры занимаются? Почему все сложное свалено на одного, а остальные просто безвольные кодеры своих маленьких кусочков (не факт но очень похоже с виду)?

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

            Раз так хотите подискутировать о том, как решать задачу, обратную теме поста, то давайте, почему нет)


            Решение с закручиванием гаек вроде этого https://m.habr.com/ru/post/501244/comments/#comment_21595022 кажется самым простым. В частности, технические менеджеры, которые прожимают нерадивых технарей, разводя стукачество, это шаг к тому, чтобы перестать требовать от программиста ценности бизнесу, а требовать исполнения конкретных задач.


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

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

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

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

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

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

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


          • Авиационный инженер, вынужден думать о бизнесе. Почему, например, сейчас много широко-физюляжных самолетов, которые летают медленно-медленно, а нет больше чего-нибудь вроде конкорда? Да потому, что дизайн современных самолетов — это образец максимизации прибыли. Инженер — "художник я так вижу и никому не обязан" в авиации долго не продержится. Хотя бы на инженеров Маска посмотрите, не думают они о бизнесе?
          • Инженер, строящий мост (напр. главный инженер) — только об этом и думает. О том как сделать мост дешевле, как ввести его в эксплуатацию быстрее и как на нем научит себя и персонал делать это лучше для следующего моста.
          • Художник, рисующий на коробке выполняет заказ от отдела маркетинга. Это вроде как по аналогии — мид девелопер. А вот если он руководитель студии, то получается кто-то типа Темы Лебедева — и опять же думает о бизнесе.
          • Врач хирург очень даже думает о бизнесе, особенно если у него частная практика. Возможно в РФ это не так наглядно, но в США это очень и очень актуально. Вам будут прописывать препараты, за которые врач получает комиссию, вам будут назначать обследования, которые не обязательны, но за них практика или госпиталь получают доп. оплату.

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


          • История #1 — проблема в том, что судя по вашему описанию для технического руководителя нет никого, кто бы мог проверить его утверждения и разобраться в том, что он предлагает. Часто в таких ситуациях крупные компании проводят анализ проекта и нанимают внешних контракторов для аудита.
          • История #2 — умение продавать себя и свои решения — ключевое отличие тех, у кого будет карьера и тех, у кого ее скорее всего не будет. Антон молодец, а опять же проблема в том, что руководитель Антона не занимался долгосрочным планированием.
          • История #3 — с Иваном, опять та же самая проблема, что и с Антоном. Руководитель не озаботился тем, чтобы выполнять свои должностные обязанности с обзавестись долгосрочным планом поддержки продукта и развития команды.

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


          В общем позвольте с вами не согласиться. Бизнес компания существует для бизнеса. Т.е. деловая группа людей (вся группа) существует для дела (бизнес — это ведь дело).


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

            0
            В том то и суть, что одно дело в идеале. А другое, — как происходит по факту. Многие ЛПР в бизнесе могут заменить практически любого подчиненного, и за счет этого дыры латаются, а недобросовестные сотрудники выводятся на чистую воду при погружении в тему руководства. А вот с ит это не работает. Увы.
              0

              Почему ИТ — исключение?

                0
                Потому, что в нетехнологическом бизнесе, как правило, основатель или СЕО может прийти, согнать любого сотрудника (оператора, маркетолога, продажника, а, почитав мануалы недельку, даже юриста и бухгалтера) с его рабочего места, и более-менее сносно его подменить. А вот сесть и пофиксить баг в коде как-то не особо выйдет. Или считаете по-другому?
                  0

                  Я лично считаю по-другому, да. Попробуйте "сносно подменить" актера на съемочной площадке. Или переводчика с китайского. Или преподавателя йоги.

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

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

                        0
                        Так важно ж не «уметь управлять шагающим экскаватором», а «уметь отличить человека, который им хорошо управляет от того, кто управляет плохо».

                        Это гораздо проще и работает даже с актёрами, до какой-то степени.

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

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

                          Написано было "Потому, что в нетехнологическом бизнесе, как правило, основатель или СЕО может прийти, согнать любого сотрудника [...] с его рабочего места, и более-менее сносно его подменить.". С этим тезисом я и спорил.


                          А вот с программистами — не работает.

                          Это много с кем не работает.

                            0
                            Это много с кем не работает.
                            Теоретически — да, а практически — не совсем: гениального авиаконструктора вы, глядя на него, от обычного инжинера не отличите… но их нужно-то не немного и можно смотреть на репутацию.

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

                            А вот в ИТ-индустрии… фактически весь отдел для вас — чёрный ящик.
                              0
                              А вот уже обычного качественного инжинера от долбоёба, который всё неправильно рассчитывает — вы отличить можете.

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

                                0

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

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

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

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

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

                  Художник, рисующий на коробке выполняет заказ от отдела маркетинга. Это вроде как по аналогии — мид девелопер. А вот если он руководитель студии, то получается кто-то типа Темы Лебедева — и опять же думает о бизнесе.

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

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

                  Мои знакомые врачи стали врачами, потому что хотели людей лечить, а не чтобы бумажки заполнять или денег заработать.
                    +4
                    Врач хирург очень даже думает о бизнесе, особенно если у него частная практика. Возможно в РФ это не так наглядно, но в США это очень и очень актуально. Вам будут прописывать препараты, за которые врач получает комиссию, вам будут назначать обследования, которые не обязательны, но за них практика или госпиталь получают доп. оплату.
                    Мои знакомые врачи стали врачами, потому что хотели людей лечить, а не чтобы бумажки заполнять или денег заработать.
                    Не спорьте, горячие эстонские парни. Достаточно сопоставить два факта:
                    1. Лидеры в рейтинге готовности к эпидемии 2019го года — США и Великобритания (в этом порядке).
                    2. Лидеры по количеству умерших — также США и Великобритания (в этом порядке).

                    И да — это прекрасно кореллирует с тем, что в США и Великобритании «врач хирург очень даже думает о бизнесе», всё правильно.

                    Иначе результаты были бы другими.

                    Так что лучше сюда врачей не привлекать — иначе сильно далеко уйдёте от темы.
                  +1
                  Что можно сделать?
                  Свалить.
                    +2

                    "Василий… дорос от младшего программиста до руководителя департамента.… И все еще пописывал код, чтобы оставаться в форме."


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

                      0

                      Вот-вот. Зачем руководителю знать, чем живут его подчиненные? Он должен быть ни сном, ни духом — тогда-то в магазине всё будет хорошо!

                        +1

                        В точку! А KPI придумали дураки. Как трУсы — тормоза. :-))

                          0

                          А гэнти гэмбуцу — японцы!

                        0

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

                          0

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


                          Я пока еще не ставлю как на Reddit'e тег /s в конце, но чувствую, что уже вот-вот, уже совсем скоро без него никак. :-)

                        +7
                        Краткий пересказ «Бизнес тебя использует, а ты будь хитрее и используй его».
                          +1
                          единственный правильный подход в случае «кровавого ентерпрайза», любой другой подход — это глупость, всю ценность забирают эффектинвые менеджеры
                          0
                          О, я как раз в роли Ивана сейчас. Только мне никто и ничего не предлагает, а на мои запросы отвечают — ну не будет тебя, закроем проект и всё.
                            0

                            Значит не в роли Ивана, раз так говорят, или блефуют) Роль Ивана подразумевает, что сказать то так могут, но вот поступить, — с жадности удавятся.

                              +1
                              95% всей системы написано мной, других компетенций такого уровня нет. Но большой и кровавый энтерпрайз может позволить себе закрыть проект, у него их сотни. Ну или классика жанра — нанять человека с оплатой 3х, чтобы он во всем этом разобрался :)
                            +1
                            Не хватает историй про то, как Валера разобравшись в бизнесе, рассказал заказчику, что тому уже год пудрят мозги и ушел работать к нему напрямую. А Гоша разобравшись в бизнесе, открыл свою фирму, уведя у прежнего работодателя часть клиентов.
                              0

                              Еще должна быть история о том, что Гоше на тот момент было 36 лет и его резюме не смогло пройти через HR заказчика.

                              +2
                              Наука — это удовлетворение своего любопытства за государственный счёт

                              Был один кейс у знакомых:
                              — Получили заказ на разработку, срок — 12 месяцев. Работу поручили команде под управлением гениального (вот серьёзно) программиста Феди. За 6-7 месяцев было готово процентов 80 функционала. И тут вышла новая перспективная технология/ЯП. Федя пошёл к руководству и расписав преимущества технологии предложил переписать на ней с нуля почти готовое решение. Не знаю, чем он мотивировал — повышением качества, скорости безопасности, тем что руководству премию дадут, будут уступать место в автобусе или ещё что… В общем, приняли решение остановить разработку, за месяц изучить новую технологию и потом на ней реализовать решение.
                              Через 3-4 месяца предсказуемо случился факап: технология оказалась сложнее, решение не совсем подошло и тд. Пришлось увольнять Федю, срочно созывать всех более-менее свободных программистов и обещать им премии если они успеют вовремя
                                0
                                Пришлось увольнять Федю

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

                                Так что да, если ЛПР не может здраво оценивать риски от идей «все переписать» — бизнесу это рано или поздно выходит боком. А вот дающим эти идеи — не обязательно, более того, им с точки зрения их личной выгоды может быть крайне выгодно эти идеи давать и продавливать.
                                  0
                                  Вообще-то достаточно было спросить коллег Феди что они думают о новой технологии.
                                    +1
                                    Скорее всего не помогло бы. Разве что, после ухода Феди можно было бы пробить его коллег на чувство вины, что тоже бы делу не помогло.

                                    Ведь в пользу поддержки идей Феди (если под коллегами подразумеваем его подчиненных) сыграло бы два фактора.
                                    1) В коллективах программистов авторитет сильно коррелирует с техническим уровнем (в чем причины этого, — тема для отдельной статьи). И, скорее всего Федя стал руководителем не за победы в подковерных войнах, а за реальное экспертное превосходство. Соответственно, против, скорее всего, мог бы выступить только человек с амбициями занять место Феди, но таких, по моему опыту, в коллективах программистов мало. И, поэтому, большинство бы поддержало его. Ведь, если все вокруг уважают Федю, и признают его превосходство, то подвергать его идеи сомнению при менеджере, — хороший шанс прослыть выскочкой и идиотом для всего коллектива.
                                    2) Я хз, был ли в доле или с большим завязанным на результат бонусом Федя, но, скорее всего, у его коллег таковых завязок не было точно. И поэтому, выбирая между «получать пол года зп за рутинный труд на известных технологиях» и «за пол года получить ту же зп и при этом изучить новую крутую технологию под менторингом Феди, пусть и с риском для бизнеса», выбор был бы очевиден.
                                      0
                                      Ну если суммарный опыт коллектива превышает опыт Феди, то наверняка там найдётся кто-то кто уже использовал эту технологию, либо у кого-то есть друг, который использовал. И если технология кривая и неудачная, то он вряд ли бы порекомендовал её.

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

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

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

                                        И если технология кривая и неудачная, то он вряд ли бы порекомендовал её.

                                        А кто вам сказал, что технология кривая и неудачная?
                                        Или кто вам сказал, что явно видно, что технология не подойдет к имеющемуся use case? Вы всерьез полагаете, что это вот так сразу само по себе видно? Нет, это вещи, над прояснением которых нужно вдумчиво (и зачастую еще и долго) работать.

                                        Авторитаризм тут вообще не при чём. Стоит опросить любое количество разработчиков по любой новой технологии, плюс-минус подходящей к текущей ситуации — и быстрые ответы без долгого детального разбора полётов (с написанием proof of concept, а то и нескольких) будут все без исключения сводится к «мне нравится» или «мне не нравится». Какой процент тех или других ответов будет — вообще не важно, всё равно это всё голословно.

                                        Именно поэтому нужно в первую, вторую, и даже третью очереди — анализировать риски, особенно исчислимые риски. И если в первом приближении всё ок — то, по необходимости, еще и второе и последующие приближения оценивать, через исследовательские proof of concept.
                                          0
                                          Так называемые «новые технологии» это как правило часто, что изобретено 5 лет назад, а то и раньше. Более того, опыт в похожих технологиях и общий разработческий опыт тоже полезен.
                                          Скажем если я раньше работал с batch processing и новая технология тоже связана с batch processing, то мой опыт очень даже релевантен.

                                          На счёт ОБС вы не правы. Реальный опыт, а не теоретическое философствование, крайне важен. Более того, бывают технологии настолько неудачные, что они не применимы ни при каких обстоятельствах.

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


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

                                          Именно поэтому нужно в первую, вторую, и даже третью очереди — анализировать риски, особенно исчислимые риски. И если в первом приближении всё ок — то, по необходимости, еще и второе и последующие приближения оценивать, через исследовательские proof of concept.


                                          Анализировать риски несомненно надо, но это опять же это не бедный Федя, кто будет всем заниматься и писать все proof of concepts, а вся команда должна быть вовлечена. Так и только так.
                                            0

                                            Подскажите где берется время на исследования, proof of concept, etc?
                                            Вводная: обычный бизнес, то есть колво разрабов на минимум, на расширение отдела нет денег, хотелки расписаны на месяцы вперед. Не лукойл, не гугл.

                                              0
                                              Подскажите где берется время на исследования, proof of concept, etc?

                                              Нигде не берется, при таких вводных самое нормальное (и чаще всего применяемое) — это «ничего не трогаем и не меняем, если вообще можем ничего не трогать и не менять».

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

                                        ЛПР никогда нет может оценить такой риск. Если он действительно ЛПР, а не менеджер чего-то там.

                                        +1

                                        Ну кстати говоря, если там работает старое доброе правило, что 80 процентов работы делается за 20 процентов времени, то фейл бы их ждал в любом случае :)

                                        +1
                                        Насколько я понял, во всех трех рассказах программисты «думали о бизнесе...», о своем бизнесе. :-)
                                        Вообще-то проблема в программировании в том, что нет простых и понятных метрик для «хорошего кода».
                                        Т.е. кода, который легко расширяется и легко поддерживается.
                                        Более-менее отдаленно похожее на правду можно выудить из «процента покрытия тестами».
                                        Да и то, очень отдаленно.
                                        Т.е. грубо говоря, чтобы «управлять программистами», нужно понимать что и как они пишут.
                                        А работающий в данный момент времени продукт ни о чем не говорит.
                                        Т.к. может оказаться, что стоимость изменений сопоставима с «переписыванием с нуля».
                                        Но мало кто «вот прям щас» дать точную оценку не сможет.
                                        Поэтому и получаем «программист должен решать проблемы бизнеса».
                                        Т.е. оценивать не только стоимость изменений, но и говорить, какие изменения наиболее выгодные.
                                        Обычно бизнес прибегает и кричит, как в анекдоте, «сделайте мне кастрацию»! :-)
                                          +4
                                          Более-менее отдаленно похожее на правду можно выудить из «процента покрытия тестами».

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

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

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

                                                Написано, что практически всё было бесполезно, включая то, что можно заменить на тайпскрипт

                                                  0
                                                  Делать оно практически ничего полезного не делало

                                                  Фраза относится к предыдущему существительному, т.е. к 100% покрытию тестами.
                                                    0

                                                    Я понял. Мне не понятно зачем заменять 50% покрытия тестами на тайпскрипт, если пользы нет? Или эта такая квантовая польза: если подтверждают корректность программы тесты, то это подтверждение бесполезно, а если тайпскрипт, то полезно?

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

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

                                                        В такой интерпретации понятно. Спасибо.


                                                        А покрытие какое стало после этого? Просто одно дело, когда функция написана с активным использованием приведений типов и юнит-тесты тупо проверяли, что результат при sum(1, 2) равен результату при sum("1", 2) и sum("1", "2") и другое если флоу функций были разными при разных типах параметров: передали строку — обрабатываем как CSS селектор, передали DOM элемент — обрабатываем как DOM и т. п.

                                                          0
                                                          А покрытие какое стало после этого?

                                                          Такое же и осталось. Там очень простой код был — вполне рядовой фронтэнд, который просто получает не особо сложные данные и просто их показывает, до типа-перегрузок методов через проверки typeof/instanceof, слава богам, никто не добрался.
                                              +1
                                              Я не говорю, что процент покрытия дает точную оценку. Но от неё (процента покрытия) еще как-то можно отталкиваться. Грубо говоря, если что-то измениться, то какие-нибудь тесты упадут.
                                              Выкинув юнит-тесты на мороз, как менеджер сможет оценить сколько потребуется времени на внесение изменений, если вся команда «уйдет» и будет набрана новая.
                                              Понятно, что ситуация утрированная. Но я, как минимум с такой столкнулся.
                                              Пришел на легаси проект, откуда уволились все программисты (был вопрос денег, перестали платить премии). Большая половина тестов была поломана, вроде бы как года три уже.
                                              Документация описывала, состояние пятилетней давности. БД вообще никто никогда не описывал.
                                              Внедряли новый функционал, который не был дописан.
                                              В общем все те, кто кричит «юнит-тесты не нужны», я бы посадил на этот проект без права увольнения.
                                              P.S. Раньше этот проект сопровождали 3-5 разработчиков. Сейчас я один. Благо новых фичь больше не было. Только правка багов. Сейчас взяли команду, которая переписывает все с нуля.
                                              Думаю будет такое же дремучее легаси, но там хотя бы фронт-енд и бакенд разделены.
                                                0
                                                Ну так и я столкнулся, я ж про это и написал. Прихожу на проект, проект на стадии «больше чем proof of concept, меньше чем MVP». Покрытие тестами — 100%. Ничего, кроме юнит-тестов — нет. Оригинальные разработчики благополучно свалили в закат. И что в итоге?

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

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

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

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

                                                0
                                                А работающий в данный момент времени продукт ни о чем не говорит

                                                Не ожидал встретить такое здесь.

                                                –1
                                                И отжал бизнес по-максимуму.


                                                аж поперхнулся. Прям отжал бизнес?
                                                  +5
                                                  По моему все эти конфликты восходят к Марксу.
                                                  Бизнес — (толстый дядька в цилиндре) хочет денег, чтобы сидеть в шезлонге и потягивать мартини, и он с удовольствием бы обошелся без программиста.
                                                  Программист — (паренек в джинсах и майке) хочет развлекаться за счет дядьки в цилиндре. И он с удовольствием бы занимался своими проектами или просто исследованиями если бы деньги падали с неба.
                                                  Данный конфликт фундаментален, так что можно только писать статьи-рецепты как перетянуть одеяло в одну сторону. Теперь ждем статью «Как программиста заставить решать задачи бизнеса, так чтобы он думал, что делает карьеру»..
                                                    0
                                                    Вся суть. Таки да. Падали бы деньги с неба я бы фигню всякую писал бы. Вроде игрушек.
                                                    0
                                                    Мне кажется, что дискуссия заходит в тупик. Решать или не решать задачи бизнеса — это вопрос не о деньгах, а о власти. Ведь власть — это и есть право решать значимые для бизнеса вопросы, неся за это персональную ответственность за результаты принятых решений. Естественно, получая при этом несравненно большие объем и качество различных благ.

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

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

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

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

                                                        +1
                                                        Если ради этого надо загнать коллег или подчиненных, то почему бы и нет?
                                                        Потому что на новом уровне человека без команды просто «сожрут». Те у кого команда будет. Так что человек, умеющий в игру во власть будет-таки поддерживать команду… но в первую очередь, конечно, себя. Тут ничего не поделаешь.
                                                          0
                                                          Все просто — без команды нет власти. Если Вас интересуют подробности, то рекомендую ознакомиться с книгой Никколо Макиавелли «Государь» (1513 год). В процессе чтения этой книги только нужно вместо слова «государь» подставлять «руководитель», а вместо слова «народ» — «коллектив».
                                                            0

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

                                                              +1
                                                              У нас был сотрудник который очень хорошо умел «во власть» и было видно как ему некомфортна регулярная научная работа. Т.е. возможно он была бы хорошим менеджером, но таких должностей у нас нет, а должность завлаба ему не светила. В результате он поругался почти со всеми с кем мог, ушел на работу в некую IT-контору на регулярную должность, там ситуация повторилась, сейчас сотрудник в зарубежной конторе и всё идет к увольнению. Увы — менеджер-начальник без своей команды никому не нужен.
                                                                0
                                                                А как думаете, в кровавом энтерпрайзе он смог бы найти себе место, чтобы ставить задачи и контролировать их выполнение, а пипл менеджат пусть специально обученные люди? Или не смог бы смирится с рамками и рутиной, в которую там загоняют менеджеров?
                                                                  0
                                                                  У вас есть вакансия? )) Если соберется возвращаться — могу вам прислать, скажете мне спасибо или нет — не знаю.
                                                                  На новом заграничном рабочем месте тоже зреет конфликт — начальник сотрудника слегка присваивает себе его достижения (по его словам) — для KPI. Это кстати кусочек пресловутого «умения во власть» — что человек видит это. С мозгами там всё очень хорошо. ИМХО таким людям надо свою контору организовывать, чтобы не было начальников вообще.
                                                                    0
                                                                    ИМХО таким людям надо свою контору организовывать, чтобы не было начальников вообще

                                                                    Как? Думаете вот так сходу это реально?
                                                                      0
                                                                      Ну… у меня был знакомый — с детства спекулировал алкоголем и чем придется. Работал в каких-то конторах по найму — но быстро начинал там работать на себя с предсказуемым результатом. Потом организовал свою контору ну и лет 15 себя хорошо чувствовал. Потом рынок его деятельности схлопнулся, он пошел куда-то работать — хватило его месяца на три. Это я к чему — кто-то же организует какие-то конторы.
                                                                        0
                                                                        За эти 15 лет он так и был малым бизнесом? Или выстроил что-то большое и оно рухнуло?
                                                                          0
                                                                          Малым, но с вполне так хорошей прибылью — товарищ купил несколько квартир и несколько хороших авто.
                                                                            0
                                                                            Я к тому, что если нет цели и понимания, как построить что-то большое, где, как сейчас модно говорить «можно выйти из операционки», то бизнес ли это? Или просто выполнение работы 1-3 наемных сотрудников с положением в карман всей маржи? Ну а прибыль размером в несколько квартир и машин за пятнадцать лет делает и линейный персонал с 0 подчиненных в технологических компаниях.
                                                                              0
                                                                              «можно выйти из операционки» А что это значит?
                                                                              Скорее второе — ну не 1-3 сотрудника, а скорее 10.
                                                                              Сейчас попробую залезть в чужой карман и посчитать. )
                                                                              Три квартиры + две машины это где-то 25 млн. Это всё уже давно, т.е. было куплено лет за 7-8. Это соответствует личной среднемесячной ЗП в 300т+на веселое житье и частую покупку дорогих шмоток. Т.е. по нынешним меркам это около 500 тыс.
                                                                              Думается не так много линейных сотрудников получающих такие ЗП.
                                                                                0

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


                                                                                Ну а касательно зп, да, 500 это выше линейного персонала. Где-то $5к, думаю, потолок.

                                                                                  0
                                                                                  А! Ну да. Если конторой в 10 человек не заниматься, то либо она утонет либо перейдет к шустрому менеджеру. Типично когда кто-нибудь из сотрудников организует свою аналогичную контору и уводит половину сотрудников.
                                                                                    0
                                                                                    Типично когда кто-нибудь из сотрудников организует свою аналогичную контору и уводит половину сотрудников.

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

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

                                                            Only users with full accounts can post comments. Log in, please.