- PVSM.RU - https://www.pvsm.ru -
Ведущий разработчик — не зря «ведущий». Эту фразу я услышал на одной из конференций по IT-менеджменту и задался вопросом, а почему «не зря»? Именно он подтолкнул меня написать эту статью.
Оценивая свой опыт я могу сказать, что основные характеристики ведущего разработчика можно свести к 3 пунктам:
Помимо написания кода (остается основной обязанностью), ведущий участвует в подборе команды и развитии ее в нужном направлении, поиске технических решений наболевших или приближающихся проблем, следит за безопасностью и целостностью системы, а также регулярно банит безумные идеи менеджеров или других разработчиков.
Одной из сильнейших его сторон является целостная картина мира, в которой совершенно точно определено, что такое хорошо и что такое плохо. Это позволяет быстро принимать решения и без колебаний воплощать их в жизнь. Эта уверенность заразительна и позволяет завоевать авторитет в глазах менеджеров, у которых уже не все так просто и понятно. Ведь кроме технических «лучше», «надежнее» и «быстрее» на уровне менеджмента появляются всякие «заказчик не захочет», «инвестор не оценит» и всевозможные «Вася обидится». Когда менеджер слышит «нет, тут нужно делать только так, потому что 1, 2 и 3» — он вздыхает с облегчением. Выбор становится очевиден и ответственность падает с его плеч.
Год назад я ушел с позиции ведущего разработчика окончательно и решил сделать небольшую ретроспективу своих самых досадных ошибок. Итак:
Был у меня случай года три назад. Помимо моих коллег, которые получали задачи напрямую от менеджера, к нам пришел разработчик в один из моих проектов и задачи ему ставил уже я. Чтоб погрузить его в работу я провел с ним 3 дня по 14 часов подряд рассказывая и показывая все, убеждаясь, что он все правильно понял. Это принесло результат, и дальше все задачи ставились напрямую сразу с решением: открой такой то модуль, допиши вот там и вот там такую-то функцию, подключи вот эту библиотеку и т.д… В целом это работает и сразу же приносит плоды, но:
Через 9 месяцев я обнаружил себя беременным очень уставшим от такого режима работы, а сотрудник так и не поднялся на необходимый уровень квалификации.
Правильнее ставить задачи на достаточно высоком уровне, чтоб человек сам искал решения и нес за них ответственность. На вопрос «как это сделать?» всегда нужно отвечать «А сам как думаешь? Есть идеи?», таким образом стимулируется работа мысли в нужном направлении. Ответ можно подсказывать, но только убедившись, что человек сам себе уже задал этот вопрос и провел анализ.
В какой-то момент моему руководителю понравилась одна из новых нашумевших технологий (нет, не та нашумевшая технология, о которой вы подумали). Ее внедрение подрывало целостность системы, создавало ненужное разделение фронтов работы и в целом навсегда замедляло скорость разработки. Для меня это было очевидно уже тогда, но красивый внешний вид демки и желание поэкспериментировать взяло верх над руководством, меня правдами и неправдами убедили, и мы внедрили это. Понимание того, что это было ошибкой дошло до руководства где-то спустя год-полтора.
Я сделал вывод, что своему к чутью нужно относиться с уважением, доверять ему и защищать его.
Глубоко внутри вы понимаете почему вы так чувствуете. Нужно уметь вытаскивать из себя это понимание, а затем формулировать из него аргументы.
Когда ты проводишь с компьютером огромное количество времени и увлечен тем, что делаешь, можно вообще забыть о том, что вокруг тоже люди. Они не идеальны, но у всех есть свое позитивное намерение в отношении того, что они делают. Это положительное намерение важно видеть всегда и во всем. Это помогает сохранять благожелательное отношение в ситуациях, когда человек допускает ошибку. Я постоянно слышу истории о том, как сениоры без капли сострадания в пух и прах разносят результаты стараний своих менее опытных коллег, чем повергают их в уныние и лишают мотивации работать. Проанализировав свой опыт я понял, что и сам себе такое иногда позволял, хоть и без каких-то крайних форм.
Говоря о токсичности, отдельно хочется заметить, что кроме слишком жесткой критики есть и другие формы, которые могут в той или иной мере негативно сказываться на желании работать с вами. Сама по себе токсичность очень заразна и можно легко подхватить ее от своих коллег, поэтому я в какой-то момент решил исповедовать принцип «не пропускай зло дальше себя» (выявляй и подавляй в первую очередь в себе самом) и составил список проявлений, которые можно счесть токсичностью (в основу лег доклад на TED «7 смертных грехов коммуникации» [1]):
У твоего руководителя есть коллеги на одном с ним уровне и выше. Они могут быть друзьями или неприятелями. Твое законное влияние на решения руководителя не всегда может им нравиться, а сами решения не всегда идут в одном русле с их интересами. Когда ты программист ты вообще не обращаешь на это никакого внимания и даже не задумываешься об этом. Как правило, твой руководитель будет тебя инкапсулировать от этих вещей пока это возможно. В какой-то момент ты можешь обнаружить, что тебя изящно покалывают самыми неожиданными и неочевидными вещами люди, которые, которые на первый взгляд вообще не имеют отношения к твоей работе. Вообще с этим можно жить, но если оппонент искушен, то, вполне возможно, тебе очень скоро захочется переехать в другой кабинет, побольше работать из дома или вообще поменять работу.
Избежать таких ситуаций можно, если заранее учитывать, кто еще заинтересован в проекте, который ты реализуешь, какой уровень влияния на этот проект, какие цели стоят перед заинтересованной стороной, какие опасения и надежды могут возникнуть в процессе работы. Опасения нужно развеивать, нельзя оставлять их расти. Надежды же нужно оправдывать. В целом, стратегия определяется следующим путем:
Это свойственно всем в той или иной мере, и ваш руководитель скорее всего об этом знает. Тем не менее, иногда и он может недооценить объемы предстоящей работы и скорость ее выполнения. Это звучит банально, но именно это неоднократно было причиной, по которой мой руководитель испытывал разочарование и я вместе с ним. Я легко могу вспомнить несколько ситуаций, когда я отвечал, что мы можем сделать это за полдня, и потом сидел над задачей всю неделю вместе с выходными. За это время задача могла утратить актуальность, или можно было бы сделать другие, более важные задачи. Мне очень помогла привычка не давать оценку сразу. Если вопрос не гипотетический, а конкретный, то стоит взять какое-то время на построение оценки и желательно учесть возможные риски. После знакомства с оценкой по трем точкам [2] мне стало намного легче делать аргументированный вывод о необходимых затратах времени и, самое главное, сама оценка стала намного более приближенной к реальности.
Подводя итоги, я могу сказать, что ведущий разработчик волей-неволей сталкивается с горизонтом достаточно агрессивной и неизвестной для него среды менеджмента. Для эффективного выполнения своей работы (а если быть откровенным, то и просто для того чтобы «выжить») ему необходимо быстро разобраться в основах этого ремесла и проанализировать основные проблемы, с которыми пришлось столкнуться его предшественникам, и постараться их избежать.
Автор: Cypher3000
Источник [3]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/razrabotka/319450
Ссылки в тексте:
[1] TED «7 смертных грехов коммуникации»: https://www.ted.com/talks/julian_treasure_how_to_speak_so_that_people_want_to_listen
[2] по трем точкам: https://habr.com/ru/post/248325/
[3] Источник: https://habr.com/ru/post/454306/?utm_campaign=454306
Нажмите здесь для печати.