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



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

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

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

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

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

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