Оценивая свой опыт, могу сказать, что основные характеристики ведущего разработчика можно свести к 3 пунктам:
- Думает не только о своей грядке, но и обо всем огороде (это ключевое качество). Готов выстраивать стандарты и следить за их исполнением.
- Отлично знает свой язык и фреймворк, превосходно разбирается в архитектуре, имеет солидный опыт работы за плечами. «Солидность» не обязательно означает время проведенное за клавиатурой, важно количество и качество написанных проектов.
- Хочет и может аргументированно доносить свое мнение, отстаивать его и искать компромисс при необходимости.
Помимо написания кода (остается основной обязанностью), ведущий участвует в подборе команды и развитии ее в нужном направлении, поиске технических решений наболевших или приближающихся проблем, следит за безопасностью и целостностью системы, а также регулярно банит безумные идеи менеджеров или других разработчиков.
Одной из сильнейших его сторон является целостная картина мира, в которой совершенно точно определено, что такое хорошо и что такое плохо. Это позволяет быстро принимать решения и без колебаний воплощать их в жизнь. Эта уверенность заразительна и позволяет завоевать авторитет в глазах менеджеров, у которых уже не все так просто и понятно. Ведь кроме технических «лучше», «надежнее» и «быстрее», на уровне менеджмента появляются всякие «заказчик не захочет», «инвестор не оценит» и всевозможные «Вася обидится». Когда менеджер слышит «нет, тут нужно делать только так, потому что 1, 2 и 3» — он вздыхает с облегчением. Выбор становится очевиден и ответственность падает с его плеч.
Чуть более года назад я ушел с позиции ведущего разработчика окончательно и решил сделать небольшую ретроспективу своих самых досадных ошибок. Итак:
Ошибка номер 1. Оверменеджмент
Был у меня случай года три назад. Помимо моих коллег, которые получали задачи напрямую от менеджера, к нам пришел разработчик в один из моих проектов, и задачи ему ставил уже я. Чтоб погрузить его в работу, я провел с ним 3 дня по 14 часов подряд, рассказывая и показывая все, убеждаясь, что он все правильно понял. Это принесло результат, и дальше все задачи ставились напрямую сразу с решением: открой такой то модуль, допиши вот там и вот там такую-то функцию, подключи вот эту библиотеку и т.д… В целом это работает и сразу же приносит плоды, но:
- Отнимает огромное количество времени в ущерб вашим собственным задачам
- Снимает ответственность за результат с сотрудника. Это вы сказали, что именно сделать, а значит, если не сработало, то он радостно вам об этом сообщит, мол, ищите другое решение.
- Отучает сотрудника думать и мешает ему развиваться
Через 9 месяцев я обнаружил себя
Правильнее ставить задачи на достаточно высоком уровне, чтоб человек сам искал решения и нес за них ответственность. На вопрос «как это сделать?» всегда нужно отвечать «А сам как думаешь? Есть идеи?», таким образом стимулируется работа мысли в нужном направлении. Ответ можно подсказывать, но только убедившись, что человек сам себе уже задал этот вопрос и провел анализ.
Ошибка номер 2. Уступки руководителю в техническом решении
В какой-то момент моему руководителю понравилась одна из новых нашумевших технологий (нет, не та нашумевшая технология, о которой вы подумали). Ее внедрение подрывало целостность системы, создавало ненужное разделение фронтов работы и в целом навсегда замедляло скорость разработки. Для меня это было очевидно уже тогда, но красивый внешний вид демки и желание поэкспериментировать взяло верх над руководством, меня правдами и неправдами убедили, и мы внедрили это. Понимание того, что это было ошибкой, дошло до руководства где-то спустя год-полтора.
Я сделал вывод, что к своему чутью нужно относиться с уважением, доверять ему и защищать его.
Глубоко внутри вы понимаете, почему вы так чувствуете. Нужно уметь вытаскивать из себя это понимание, а затем формулировать из него аргументы.
Ошибка номер 3. Недостаток эмпатии и токсичность
Когда ты проводишь с компьютером огромное количество времени и увлечен тем, что делаешь, можно вообще забыть о том, что вокруг тоже люди. Они не идеальны, но у всех есть свое позитивное намерение в отношении того, что они делают. Это положительное намерение важно видеть всегда и во всем. Это помогает сохранять благожелательное отношение в ситуациях, когда человек допускает ошибку. Постоянно слышны истории о том, как сениоры без капли сострадания в пух и прах разносят результаты стараний своих менее опытных коллег, чем повергают их в уныние и лишают мотивации работать. Проанализировав свой опыт я понял, что и сам себе такое иногда позволял, хоть и без каких-то крайних форм.
Говоря о токсичности, отдельно хочется заметить, что кроме слишком жесткой критики есть и другие формы, которые могут в той или иной мере негативно сказываться на желании работать с вами. Сама по себе токсичность очень заразна и можно легко подхватить ее от своих коллег, поэтому я в какой-то момент решил исповедовать принцип «не пропускай зло дальше себя» (выявляй и подавляй в первую очередь в себе самом) и составил список проявлений, которые можно счесть токсичностью (в основу лег доклад на TED «7 смертных грехов коммуникации»):
- Сплетни. Всем хочется иногда немного посплетничать, но в больших масштабах сплетники отвратительны
- Осуждение. Сложно общаться с человеком, который тебя осуждает. Особенно если известно, что он заранее будет осуждать любой поступок.
- Негативность. Бывают такие люди, которых не радует вообще ничего и никогда.
- Нытье. Жалобы на жизнь допустимы только в гомеопатических количествах.
- Оправдания. Перекидывание вины, отказ от ответственности.
- Приукрашивание. Постоянные преувеличения, к которым склонны многие люди, когда говорят о проектах, своем опыте, своих знаниях. Любые преувеличения со временем склонны сливаться в сплошное вранье.
- Догматизм. Когда говорящий не разделяет, где проверенный факт, а где его субъективное мнение, и поливает вас сплошным потоком, выдавая его целиком за доказанную правду. Полная противоположность научной дискуссии.
Ошибка номер 4. Игнорирование заинтересованных сторон
У твоего руководителя есть коллеги на одном с ним уровне и выше. Они могут быть друзьями или неприятелями. Твое законное влияние на решения руководителя не всегда может им нравиться, а сами решения не всегда идут в одном русле с их интересами. Когда ты программист, ты вообще не обращаешь на это никакого внимания и даже не задумываешься об этом. Как правило, твой руководитель будет тебя инкапсулировать от этих вещей, пока это возможно. В какой-то момент ты можешь обнаружить, что тебя изящно покалывают самыми неожиданными и неочевидными вещами люди, которые, которые на первый взгляд вообще не имеют отношения к твоей работе. Вообще с этим можно жить, но если оппонент искушен, то, вполне возможно, тебе очень скоро захочется переехать в другой кабинет, побольше работать из дома или вообще поменять работу.
Избежать таких ситуаций можно, если заранее учитывать, кто еще заинтересован в проекте, который ты реализуешь, какой уровень влияния на этот проект, какие цели стоят перед заинтересованной стороной, какие опасения и надежды могут возникнуть в процессе работы. Опасения нужно развеивать, нельзя оставлять их расти. Надежды же нужно оправдывать. В целом, стратегия определяется следующим путем:
- Низкое влияние и низкий интерес: можно позволить себе ничего не предпринимать
- Низкое влияние и высокий интерес: нужно информировать об изменениях, планах и т.д.
- Высокое влияние и низкий интерес: аналогично
- Высокое влияние и высокий интерес: нужно плотно работать, даже если вы в разных отделах и/или на разных уровнях.
Ошибка номер 5. Переоценка своих возможностей
Это свойственно всем в той или иной мере, и ваш руководитель скорее всего об этом знает. Тем не менее, иногда и он может недооценить объемы предстоящей работы и скорость ее выполнения. Это звучит банально, но именно это неоднократно было причиной, по которой мой руководитель испытывал разочарование и я вместе с ним. Легко можно вспомнить несколько ситуаций, когда я отвечал, что мы можем сделать это за полдня, и потом сидел над задачей всю неделю вместе с выходными. За это время задача могла утратить актуальность, или можно было бы сделать другие, более важные задачи. Мне очень помогла привычка не давать оценку сразу. Если вопрос не гипотетический, а конкретный, то стоит взять какое-то время на построение оценки и желательно учесть возможные риски. После знакомства с оценкой по трем точкам мне стало намного легче делать аргументированный вывод о необходимых затратах времени и, самое главное, сама оценка стала намного более приближенной к реальности.
Резюме
Подводя итоги, могу сказать, что ведущий разработчик волей-неволей сталкивается с горизонтом достаточно агрессивной и неизвестной для него среды менеджмента. Именно это место становится новой точкой роста, так как техническая сторона работы вопросов вызывает уже не так много: инвестиции в инфраструктуру делаются регулярно, технический долг гасится своевременно, архитектура развивается гармонично и грамотно. Однако, для эффективного выполнения своей работы (а иногда и просто для того чтобы «выжить») необходимо быстро разобраться в основах управления проектами и командой, проанализировать основные проблемы своих предшественников на аналогичных позициях, и постараться избежать их или решить заблаговременно.
Комментарии (31)
reinvent
31.05.2019 19:59-4Возможно, ошибка 0 — мало прочитано нужных книг по менеджменту.
b00b1ik
31.05.2019 21:29+2Советы с книгами уже какой-то страшный баян, это надо просто любить читать, а не думать.
Для нормального вхождения в тематику ведущего, а не просто «награждением» таким званием и пусть сам разбирается, достаточно пару дней с человеком пообщаться, это может быть PM или CTO. Опыт надо передавать, в том числе и такой.
L0NGMAN
01.06.2019 02:04+2И каких вы именно посоветовали бы?
Calc
03.06.2019 18:59Др. Деминг? Хотя уже попсой становится, но истоки и вариации знать надо.
На самом деле книги помогу только структурировать имеющийся опыт, без практики они практически бесполезны.
reinvent
04.06.2019 10:39Для всех подходят разные в зависимости от стиля управления. Мне сильно помогла книга Лалу «Открывая организации будущего». И, наверное, крики известных бизнесменов. Периодически вижу, как специалистов делают начальниками, но они остаются специалистами. И от этого зачастую плохо всем: и подчинённым, и им самим
L0NGMAN
01.06.2019 02:05+2Ещё большая проблема, остаётся мало времени писать код :(
JPEG
01.06.2019 11:12+3Если это проблема, значит рано уходить в менеджмент. Возможно, еще хочется работать руками, возможно бизнес требует восьмирукость, возможно команда уважает только код, возможно еще нет никаких разумных управленческих процессов. Причин много, а результат один: пиши код блеать.
mapron
01.06.2019 17:02Я может спорную вещь, для обсуждения, но по-моему, «уходить в менеджмент» можно по-разному. В компании с развитой структурой управления, опытный разработчик может не просто тупо «идти наверх» в «большие дяди», т.к существуют:
— Технические эксперты (иногда «архитекторы» ) — следят за обучением новичков, взаимодействием с другими отделами по коду, а так же принимают участие во всех общих технических решениях;
— Аналитики (которые могут быть весьма технически подкованы, и так же уделять время на разработку каких-то фич)
— Менеджеры продукта (которые уже решают более приближенные к бизнесу задачи)
В общем я не могу сказать что кто-то из них «главнее» или «важнее» (хотя может в каких-то авторитарных конторах и есть четкое подчинение этих ролей).
Так на мой взгляд, если человек хочет именно оставаться разработчиком, а на него скидывают обязанности по ПМству или подобному, то это косяк системы управления, нужно разделять роль «ведущего разработчика», иначе можно просто потерять специалиста от недовольства.JPEG
01.06.2019 22:59Согласен полностью, если есть возможность, то расти можно и нужно. Но чаще вот это вижу: «Principal. Not senior senior» https://blog.dbsmasher.com/2019/01/28/on-being-a-principal-engineer.html
В крупных компаниях принципалы хоть и есть, но решают они немного, если вдруг «нормальный менеджер» не согласен.
Quber
01.06.2019 07:55Мне очень помогла привычка не давать оценку сразу.
Увы, но у нас руководитель не дает такой возможности. Хоть какая-то оценка должна быть сразу.Cypher3000 Автор
01.06.2019 09:23+1Нужно объяснить ему разницу, которая возникает при правильной и неправильной оценке, и показать как это на практике портит ему жизнь. А потом просто попросить 15 минут на оценку, если задача больше чем на два часа.
411
01.06.2019 08:49+8Я так подумал, поанализировал свой опыт и опыт коллег и понял, что ваши пункты с обратной стороны крайности тоже минусы, возможно более очевидные:
1) Недоменеджмент
2) Неприятие введения новых технологий/новых технических идей от других
3) Постоянное сопереживание всем, недостаточная строгость/излишняя мягкость и вежливость
4) Попытки всем угодить
5) Недооценка своих возможностей
Хоть ещё одну статью пиши по каждому из пунктов.
Кстати пункты 2 и 4 как в вашем, так и в обратном списке тесно связаны и являются противоречиями друг другу в некоторых контекстах. Но бывают ситуации, когда они возникают и одновременно.
Из своего опыта сталкивался с 4 и 5 из вашего списка в своём опыте, из обратного с 1, 4 и 5 (то есть с 4 и 5 обе крайности были в деле). На одном из проектов встречался с командным проявлением пункта два из обратного списка, решения всегда принимались в сторону использования проверенных инструментов, даже для неподходящих для этого задач.
Выделить какой-то самый важный пункт не могу из этих списков, мне кажется одна из важных проблем на данной позиции будет «неумение анализировать результат своих решений и действий». Ошибаться будут все и всегда, важно вовремя обнаруживать и исправлять эти ошибки.Cypher3000 Автор
01.06.2019 09:24+1Полностью согласен с вами, что тут любая крайность будет ошибкой.
Shpiler
01.06.2019 09:02+2Насчёт оверменеджемнта стоит быть аккуратнее в суждениях. Есть и джуны и просто люди без большого опыта в этой сфере или те, у кого ещё с момента трудоустройства не успело сформироваться понимание идей проекта (а оно может формироваться ооочень медленно). Джунам ответственность надо вводить плавно и контроллируемо, с нехваткой опыта — перепроверить решения на этапе "как ты будешь это делать" и не стесняться править.
Тут могла бы быть притча о двух тимлидах в одной компании, но уверен, у вас и так есть свои точно такие жеCypher3000 Автор
01.06.2019 09:28Отчасти это так. Важно понимать какой уровень делегирования и какой уровень контроля нужен этому конкретному человеку. Уровень делегирования определяется только опытностью сотрудника, уровень контроля зависит от сроков, важности и т.д.
Но сам факт того, что у джуна нет опыта не значит, что его не нужно приучать думать.
По поводу плавно и контролируемо — соглашусь.
Кстати, расскажите притчу о двух тимлидах, интересно :D
yannmar
01.06.2019 13:17+1Хорошая статья — толковая и добрая что-ли.
Есть ещё популярная ошибка #7 — недооценка важности инвестиций в инфраструктуру, в гигиену кода, консистентность дизайна и так далее. Отдачу от вложений в это почти не возможно оценить и иногда это становится огромной проблемой, превращая разработку в непрерывную боль у разработчиков.mapron
01.06.2019 17:06+1А разве ведущий разработчик определяет, выделить ли на техдолг время или нет? Он может менеджменту регулярно долбить, «названивать» «Эй, у нас копится техдолг, надо им заняться пока не прорвало», но если на уровне культуры всей компании на это не выделяется время, то никакие разовые меры «ну вот мы вам дали 2 недели на рефакторинг в прошлом году, ничего не изменилось, вы снова ноете» — не помогут.
Разумным мне кажется разрешить всем командам закладывать 20% времени (1 из 5 спринтов, или 2 дня из 2 недель) на задачи технического долга. Если этим заниматься регулярно, то он не только копиться не будет, может даже будут и ощутимые для бизнеса результаты.
fetis26
03.06.2019 14:29я лично глубоко убежден, что не должно быть какого-то отдельного времени для решения техдолга. он должен удаляться в ходе решения текущих задач постепенно.
yannmar
03.06.2019 21:04+1Это работало в старые добрые времена, когда все кодили и коммитили как хотели. А сейчас ведь есть процесс: таска -> бранча на таску -> затем пул реквест с ревью. Подмешать туда левого кода нет ни особой возможности ни желания. Все проблемы нынче обрабатываются явно.
fetis26
04.06.2019 08:04А сейчас ведь есть процесс: таска -> бранча на таску -> затем пул реквест с ревью
да, и если тебе для того чтобы правильно запилить фичу надо сделать рефакторинг, ты берешь и рефакторишь. а не откладываешь это на потом. вот о чем речь.
Karl_Marx
01.06.2019 14:38Технология из пункта 2 — это микросервисы? :)
Cypher3000 Автор
02.06.2019 10:57Нет, микросервисы давно уже были к тому времени и в них-то как раз я ничего плохого не вижу.
Usul
03.06.2019 06:25В целом я согласен с ошибкой #3, но вот в этом моменте вы ошибаетесь:
Когда ты проводишь с компьютером огромное количество времени и увлечен тем, что делаешь, можно вообще забыть о том, что вокруг тоже люди. Они не идеальны, но у всех есть свое позитивное намерение в отношении того, что они делают.
Увы, позитивные намерения есть далеко не «у всех». Для очень многих людей основной приоритет — напрягаться как можно меньше. Сделай тяп-ляп, создай видимость работы, а там, глядишь, разгребать завалы поставят кого-нибудь другого.
Если вы работаете в стабильной компании, и технический персонал совместно с менеджментом на ранних этапах выявляет таких халтурщиков и не допускает их к работе — вот тогда с некоторым допущением можно сказать, что у всех оставшихся есть позитивные намерения.
Подвох в том, что значительная часть задачи по выявлению таких деятелей лежит как раз на ведущем разработчике. Поэтому, ИМХО, лид должен по-умолчанию предполагать, что работник компетентен и выполняет задачи на совесть. Но при этом отношение должно быть «доверяй, но проверяй». Если человек не оправдывает доверия, надо от него избавляться или, в крайнем случае, переводить на наименее ответственную работу. Иначе, если принять как постулат позитивное отношение каждого человека к работе и полагаться на эмпатию, на вас в итоге свесят всех халтурщиков, и вы будете разгребать за ними культурные слои. Приблизительно как в ошибке #1. Испытано на собственном опыте…
А ведь есть еще люди которые не просто умеют в ИБД, но еще и мастерски перевешивают свои косяки на других (soft skills в курилке с начальником и все такое). Есть люди, живущие в альтернативной реальности, где они являются мега-разработчиками или мега-руководителями, а все факты, указывающие на обратное, — это ложь и провокация. И да, в этой альтернативной реальности они могут иметь офигенно позитивные намерения. Если подойдете к таким персонажам с эмпатией и займетесь поиском позитива, вами не просто воспользуются. Вас будут вертеть на известно каком органе.
А токсичности быть не должно, это да. Надо уметь выявлять коллег такого сорта и очень быстро с ними прощаться. Безо всякой токсичности ;)
По всем остальным пунктам с вами согласен. Спасибо за статью!
Peter03
#6 — Воспринимать работу как нечто личное. Надо помнить что это просто работа и мир не остановится если даже ваш проект исчезнет без следа. Следуйте принципам — живи и дай жить другим. Если интересный проект и всех прёт работать на 100% то ок, но на обычном проекте и 80% тоже нормально.
ofigenn
А если это личный проект, выросший во что-то большее? А "он сидит и безразлично портит код своими жирными пальцами"!
vadimr
Надо отпустить код, как говорят в таких случаях психологи применительно к любой зависимости :) Проще всего это сделать, получив за исходный текст программы деньги.
barbanel
Тогда:
git clone
chicago1
Где-то читал, что хорошо жить с мыслью, что тебя завтра могут запросто уволить. Решает пару весомых задач одновременно. Во-первых держит тебя готовым к переменам (именно они для многих являются катализатором депрессии), во-вторых ты всегда готовишься к худшему, а значит всегда не смотря ни на что держишь себя в форме. В нашем случае не в спортивной, а готовым пройти собеседование. А в третьих ты не воспринимаешь работу как нечно личное.
fetis26
это похоже на адаптированную версию кодекса бусидо