Пять ошибок, которые я допустил как ведущий разработчик

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

image

Оценивая свой опыт, могу сказать, что основные характеристики ведущего разработчика можно свести к 3 пунктам:

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

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

Одной из сильнейших его сторон является целостная картина мира, в которой совершенно точно определено, что такое хорошо и что такое плохо. Это позволяет быстро принимать решения и без колебаний воплощать их в жизнь. Эта уверенность заразительна и позволяет завоевать авторитет в глазах менеджеров, у которых уже не все так просто и понятно. Ведь кроме технических «лучше», «надежнее» и «быстрее», на уровне менеджмента появляются всякие «заказчик не захочет», «инвестор не оценит» и всевозможные «Вася обидится». Когда менеджер слышит «нет, тут нужно делать только так, потому что 1, 2 и 3» — он вздыхает с облегчением. Выбор становится очевиден и ответственность падает с его плеч.

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

Ошибка номер 1. Оверменеджмент


Был у меня случай года три назад. Помимо моих коллег, которые получали задачи напрямую от менеджера, к нам пришел разработчик в один из моих проектов, и задачи ему ставил уже я. Чтоб погрузить его в работу, я провел с ним 3 дня по 14 часов подряд, рассказывая и показывая все, убеждаясь, что он все правильно понял. Это принесло результат, и дальше все задачи ставились напрямую сразу с решением: открой такой то модуль, допиши вот там и вот там такую-то функцию, подключи вот эту библиотеку и т.д… В целом это работает и сразу же приносит плоды, но:

  • Отнимает огромное количество времени в ущерб вашим собственным задачам
  • Снимает ответственность за результат с сотрудника. Это вы сказали, что именно сделать, а значит, если не сработало, то он радостно вам об этом сообщит, мол, ищите другое решение.
  • Отучает сотрудника думать и мешает ему развиваться

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

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

Ошибка номер 2. Уступки руководителю в техническом решении


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

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

Ошибка номер 3. Недостаток эмпатии и токсичность


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

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

  • Сплетни. Всем хочется иногда немного посплетничать, но в больших масштабах сплетники отвратительны
  • Осуждение. Сложно общаться с человеком, который тебя осуждает. Особенно если известно, что он заранее будет осуждать любой поступок.
  • Негативность. Бывают такие люди, которых не радует вообще ничего и никогда.
  • Нытье. Жалобы на жизнь допустимы только в гомеопатических количествах.
  • Оправдания. Перекидывание вины, отказ от ответственности.
  • Приукрашивание. Постоянные преувеличения, к которым склонны многие люди, когда говорят о проектах, своем опыте, своих знаниях. Любые преувеличения со временем склонны сливаться в сплошное вранье.
  • Догматизм. Когда говорящий не разделяет, где проверенный факт, а где его субъективное мнение, и поливает вас сплошным потоком, выдавая его целиком за доказанную правду. Полная противоположность научной дискуссии.

Ошибка номер 4. Игнорирование заинтересованных сторон


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

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

Ошибка номер 5. Переоценка своих возможностей


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

Резюме


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

Comments 31

  • UFO just landed and posted this here
      +4

      А если это личный проект, выросший во что-то большее? А "он сидит и безразлично портит код своими жирными пальцами"!

        +3
        Надо отпустить код, как говорят в таких случаях психологи применительно к любой зависимости :) Проще всего это сделать, получив за исходный текст программы деньги.
          0
          Тогда:
          git clone
          +6
          Где-то читал, что хорошо жить с мыслью, что тебя завтра могут запросто уволить. Решает пару весомых задач одновременно. Во-первых держит тебя готовым к переменам (именно они для многих являются катализатором депрессии), во-вторых ты всегда готовишься к худшему, а значит всегда не смотря ни на что держишь себя в форме. В нашем случае не в спортивной, а готовым пройти собеседование. А в третьих ты не воспринимаешь работу как нечно личное.
            +1

            это похоже на адаптированную версию кодекса бусидо


            Каждое утро думай о том, как надо умирать. Каждый вечер освежай свой ум мыслями о смерти. И пусть так будет всегда. Воспитывай свой разум. Когда твоя мысль постоянно будет вращаться около смерти, твой жизненный путь будет прям и прост. Твоя воля выполнит свой долг, твой щит превратится в стальной щит.
          –6
          Возможно, ошибка 0 — мало прочитано нужных книг по менеджменту.
            +3
            Советы с книгами уже какой-то страшный баян, это надо просто любить читать, а не думать.
            Для нормального вхождения в тематику ведущего, а не просто «награждением» таким званием и пусть сам разбирается, достаточно пару дней с человеком пообщаться, это может быть PM или CTO. Опыт надо передавать, в том числе и такой.
              +2
              И каких вы именно посоветовали бы?
                0
                Др. Деминг? Хотя уже попсой становится, но истоки и вариации знать надо.
                На самом деле книги помогу только структурировать имеющийся опыт, без практики они практически бесполезны.
                  0
                  Для всех подходят разные в зависимости от стиля управления. Мне сильно помогла книга Лалу «Открывая организации будущего». И, наверное, крики известных бизнесменов. Периодически вижу, как специалистов делают начальниками, но они остаются специалистами. И от этого зачастую плохо всем: и подчинённым, и им самим
                +2
                Ещё большая проблема, остаётся мало времени писать код :(
                  +5

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

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

                      Согласен полностью, если есть возможность, то расти можно и нужно. Но чаще вот это вижу: «Principal. Not senior senior» https://blog.dbsmasher.com/2019/01/28/on-being-a-principal-engineer.html


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

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

                  Увы, но у нас руководитель не дает такой возможности. Хоть какая-то оценка должна быть сразу.
                    +1
                    Нужно объяснить ему разницу, которая возникает при правильной и неправильной оценке, и показать как это на практике портит ему жизнь. А потом просто попросить 15 минут на оценку, если задача больше чем на два часа.
                    +10
                    Я так подумал, поанализировал свой опыт и опыт коллег и понял, что ваши пункты с обратной стороны крайности тоже минусы, возможно более очевидные:
                    1) Недоменеджмент
                    2) Неприятие введения новых технологий/новых технических идей от других
                    3) Постоянное сопереживание всем, недостаточная строгость/излишняя мягкость и вежливость
                    4) Попытки всем угодить
                    5) Недооценка своих возможностей

                    Хоть ещё одну статью пиши по каждому из пунктов.

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

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

                    Выделить какой-то самый важный пункт не могу из этих списков, мне кажется одна из важных проблем на данной позиции будет «неумение анализировать результат своих решений и действий». Ошибаться будут все и всегда, важно вовремя обнаруживать и исправлять эти ошибки.
                      +1
                      Полностью согласен с вами, что тут любая крайность будет ошибкой.
                      +3

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

                        0
                        Отчасти это так. Важно понимать какой уровень делегирования и какой уровень контроля нужен этому конкретному человеку. Уровень делегирования определяется только опытностью сотрудника, уровень контроля зависит от сроков, важности и т.д.
                        Но сам факт того, что у джуна нет опыта не значит, что его не нужно приучать думать.
                        По поводу плавно и контролируемо — соглашусь.
                        Кстати, расскажите притчу о двух тимлидах, интересно :D
                        +2
                        Хорошая статья — толковая и добрая что-ли.

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

                          Разумным мне кажется разрешить всем командам закладывать 20% времени (1 из 5 спринтов, или 2 дня из 2 недель) на задачи технического долга. Если этим заниматься регулярно, то он не только копиться не будет, может даже будут и ощутимые для бизнеса результаты.
                            0

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

                              +2
                              Это работало в старые добрые времена, когда все кодили и коммитили как хотели. А сейчас ведь есть процесс: таска -> бранча на таску -> затем пул реквест с ревью. Подмешать туда левого кода нет ни особой возможности ни желания. Все проблемы нынче обрабатываются явно.
                                0
                                А сейчас ведь есть процесс: таска -> бранча на таску -> затем пул реквест с ревью
                                да, и если тебе для того чтобы правильно запилить фичу надо сделать рефакторинг, ты берешь и рефакторишь. а не откладываешь это на потом. вот о чем речь.
                          0
                          Технология из пункта 2 — это микросервисы? :)
                            0
                            Нет, микросервисы давно уже были к тому времени и в них-то как раз я ничего плохого не вижу.
                            +1
                            Тема злободневна и стара как этот мир-)
                            Интересно было бы развернуть и систематизировать имеющуюся теорию и опыт, хотябы на уровне «продвинутых чайников».
                              0
                              И получить на выходе 125-ю книгу «Как стать эффективным лидером»)
                              +2
                              В целом я согласен с ошибкой #3, но вот в этом моменте вы ошибаетесь:
                              Когда ты проводишь с компьютером огромное количество времени и увлечен тем, что делаешь, можно вообще забыть о том, что вокруг тоже люди. Они не идеальны, но у всех есть свое позитивное намерение в отношении того, что они делают.

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

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

                              Подвох в том, что значительная часть задачи по выявлению таких деятелей лежит как раз на ведущем разработчике. Поэтому, ИМХО, лид должен по-умолчанию предполагать, что работник компетентен и выполняет задачи на совесть. Но при этом отношение должно быть «доверяй, но проверяй». Если человек не оправдывает доверия, надо от него избавляться или, в крайнем случае, переводить на наименее ответственную работу. Иначе, если принять как постулат позитивное отношение каждого человека к работе и полагаться на эмпатию, на вас в итоге свесят всех халтурщиков, и вы будете разгребать за ними культурные слои. Приблизительно как в ошибке #1. Испытано на собственном опыте…

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

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

                              По всем остальным пунктам с вами согласен. Спасибо за статью!

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