Ведущий разработчик — не зря «ведущий». Эту фразу я услышал на одной из конференций по IT-менеджменту и задался вопросом, а почему «не зря»? Именно он подтолкнул меня написать эту статью.
Оценивая свой опыт я могу сказать, что основные характеристики ведущего разработчика можно свести к 3 пунктам:
- Думает не только о своей грядке, но и обо всем огороде (это ключевое качество). Готов выстраивать стандарты и следить за их исполнением.
- Отлично знает свой язык и фреймворк, превосходно разбирается в архитектуре, имеет солидный опыт работы за плечами. «Солидность» это не обязательно означает время проведенное за клавиатурой, важно количество и качество написанных проектов.
- Хочет и может аргументированно доносить свое мнение, отстаивать его и искать компромисс при необходимости.
Помимо написания кода (остается основной обязанностью), ведущий участвует в подборе команды и развитии ее в нужном направлении, поиске технических решений наболевших или приближающихся проблем, следит за безопасностью и целостностью системы, а также регулярно банит безумные идеи менеджеров или других разработчиков.
Одной из сильнейших его сторон является целостная картина мира, в которой совершенно точно определено, что такое хорошо и что такое плохо. Это позволяет быстро принимать решения и без колебаний воплощать их в жизнь. Эта уверенность заразительна и позволяет завоевать авторитет в глазах менеджеров, у которых уже не все так просто и понятно. Ведь кроме технических «лучше», «надежнее» и «быстрее» на уровне менеджмента появляются всякие «заказчик не захочет», «инвестор не оценит» и всевозможные «Вася обидится». Когда менеджер слышит «нет, тут нужно делать только так, потому что 1, 2 и 3» — он вздыхает с облегчением. Выбор становится очевиден и ответственность падает с его плеч.
Год назад я ушел с позиции ведущего разработчика окончательно и решил сделать небольшую ретроспективу своих самых досадных ошибок. Итак:
Ошибка номер 1. Оверменеджмент
Был у меня случай года три назад. Помимо моих коллег, которые получали задачи напрямую от менеджера, к нам пришел разработчик в один из моих проектов и задачи ему ставил уже я. Чтоб погрузить его в работу я провел с ним 3 дня по 14 часов подряд рассказывая и показывая все, убеждаясь, что он все правильно понял. Это принесло результат, и дальше все задачи ставились напрямую сразу с решением: открой такой то модуль, допиши вот там и вот там такую-то функцию, подключи вот эту библиотеку и т.д… В целом это работает и сразу же приносит плоды, но:
- Отнимает огромное количество времени в ущерб вашим собственным задачам
- Снимает ответственность за результат с сотрудника. Это вы сказали, что именно сделать, а значит, если не сработало, то он радостно вам об этом сообщит, мол, ищите другое решение.
- Отучает сотрудника думать и мешает ему развиваться
Через 9 месяцев я обнаружил себя беременным очень уставшим от такого режима работы, а сотрудник так и не поднялся на необходимый уровень квалификации.
Правильнее ставить задачи на достаточно высоком уровне, чтоб человек сам искал решения и нес за них ответственность. На вопрос «как это сделать?» всегда нужно отвечать «А сам как думаешь? Есть идеи?», таким образом стимулируется работа мысли в нужном направлении. Ответ можно подсказывать, но только убедившись, что человек сам себе уже задал этот вопрос и провел анализ.
Ошибка номер 2. Уступки руководителю в техническом решении
В какой-то момент моему руководителю понравилась одна из новых нашумевших технологий (нет, не та нашумевшая технология, о которой вы подумали). Ее внедрение подрывало целостность системы, создавало ненужное разделение фронтов работы и в целом навсегда замедляло скорость разработки. Для меня это было очевидно уже тогда, но красивый внешний вид демки и желание поэкспериментировать взяло верх над руководством, меня правдами и неправдами убедили, и мы внедрили это. Понимание того, что это было ошибкой дошло до руководства где-то спустя год-полтора.
Я сделал вывод, что своему к чутью нужно относиться с уважением, доверять ему и защищать его.
Глубоко внутри вы понимаете почему вы так чувствуете. Нужно уметь вытаскивать из себя это понимание, а затем формулировать из него аргументы.
Ошибка номер 3. Недостаток эмпатии и токсичность
Когда ты проводишь с компьютером огромное количество времени и увлечен тем, что делаешь, можно вообще забыть о том, что вокруг тоже люди. Они не идеальны, но у всех есть свое позитивное намерение в отношении того, что они делают. Это положительное намерение важно видеть всегда и во всем. Это помогает сохранять благожелательное отношение в ситуациях, когда человек допускает ошибку. Я постоянно слышу истории о том, как сениоры без капли сострадания в пух и прах разносят результаты стараний своих менее опытных коллег, чем повергают их в уныние и лишают мотивации работать. Проанализировав свой опыт я понял, что и сам себе такое иногда позволял, хоть и без каких-то крайних форм.
Говоря о токсичности, отдельно хочется заметить, что кроме слишком жесткой критики есть и другие формы, которые могут в той или иной мере негативно сказываться на желании работать с вами. Сама по себе токсичность очень заразна и можно легко подхватить ее от своих коллег, поэтому я в какой-то момент решил исповедовать принцип «не пропускай зло дальше себя» (выявляй и подавляй в первую очередь в себе самом) и составил список проявлений, которые можно счесть токсичностью (в основу лег доклад на TED «7 смертных грехов коммуникации»):
- Сплетни. Всем хочется иногда немного посплетничать, но в больших масштабах сплетники отвратительны
- Осуждение. Сложно общаться с человеком, который тебя осуждает. Особенно если известно, что он заранее будет осуждать любой поступок.
- Негативность. Бывают такие люди, которых не радует вообще ничего и никогда.
- Нытье. Жалобы на жизнь допустимы только в гомеопатических количествах.
- Оправдания. Перекидывание вины, отказ от ответственности.
- Приукрашивание. Постоянные преувеличения, к которым склонны многие люди, когда говорят о проектах, своем опыте, своих знаниях. Любые преувеличения со временем склонны сливаться в сплошное вранье.
- Догматизм. Когда говорящий не разделяет где проверенный факт, а где его субъективное мнение, и поливает вас сплошным потоком, выдавая его целиком за доказанную правду. Полная противоположность научной дискуссии.
Ошибка номер 4. Игнорирование заинтересованных сторон
У твоего руководителя есть коллеги на одном с ним уровне и выше. Они могут быть друзьями или неприятелями. Твое законное влияние на решения руководителя не всегда может им нравиться, а сами решения не всегда идут в одном русле с их интересами. Когда ты программист ты вообще не обращаешь на это никакого внимания и даже не задумываешься об этом. Как правило, твой руководитель будет тебя инкапсулировать от этих вещей пока это возможно. В какой-то момент ты можешь обнаружить, что тебя изящно покалывают самыми неожиданными и неочевидными вещами люди, которые, которые на первый взгляд вообще не имеют отношения к твоей работе. Вообще с этим можно жить, но если оппонент искушен, то, вполне возможно, тебе очень скоро захочется переехать в другой кабинет, побольше работать из дома или вообще поменять работу.
Избежать таких ситуаций можно, если заранее учитывать, кто еще заинтересован в проекте, который ты реализуешь, какой уровень влияния на этот проект, какие цели стоят перед заинтересованной стороной, какие опасения и надежды могут возникнуть в процессе работы. Опасения нужно развеивать, нельзя оставлять их расти. Надежды же нужно оправдывать. В целом, стратегия определяется следующим путем:
- Низкое влияние и низкий интерес: можно позволить себе ничего не предпринимать
- Низкое влияние и высокий интерес: нужно информировать об изменениях, планах и т.д.
- Высокое влияние и низкий интерес: аналогично
- Высокое влияние и высокий интерес: нужно плотно работать, даже если вы в разных отделах и/или на разных уровнях.
Ошибка номер 5. Переоценка своих возможностей
Это свойственно всем в той или иной мере, и ваш руководитель скорее всего об этом знает. Тем не менее, иногда и он может недооценить объемы предстоящей работы и скорость ее выполнения. Это звучит банально, но именно это неоднократно было причиной, по которой мой руководитель испытывал разочарование и я вместе с ним. Я легко могу вспомнить несколько ситуаций, когда я отвечал, что мы можем сделать это за полдня, и потом сидел над задачей всю неделю вместе с выходными. За это время задача могла утратить актуальность, или можно было бы сделать другие, более важные задачи. Мне очень помогла привычка не давать оценку сразу. Если вопрос не гипотетический, а конкретный, то стоит взять какое-то время на построение оценки и желательно учесть возможные риски. После знакомства с оценкой по трем точкам мне стало намного легче делать аргументированный вывод о необходимых затратах времени и, самое главное, сама оценка стала намного более приближенной к реальности.
Подводя итоги, я могу сказать, что ведущий разработчик волей-неволей сталкивается с горизонтом достаточно агрессивной и неизвестной для него среды менеджмента. Для эффективного выполнения своей работы (а если быть откровенным, то и просто для того чтобы «выжить») ему необходимо быстро разобраться в основах этого ремесла и проанализировать основные проблемы, с которыми пришлось столкнуться его предшественникам, и постараться их избежать.
Автор: Cypher3000
