Нужно ли руководителю разработки писать код?
Встречал разные мнения на этот счет Разброс большой от «руководитель отдела код писать не должен» до «руководитель должен написать все ядро проекта».
Как историю вижу я?
Если коротко: «да, руководителю команды/отдела разработки точно стоит писать код».
Давайте изучим вопрос подробнее.
Какая главная задача руководителя разработки? На мой взгляд, руководитель должен обеспечить поставку кода, решающего проблемы заказчика, вовремя и с требуемым качеством.
Что для этого нужно? Эффективная команда, готовая решать задачи по созданию кода Грамотно выбранный стек технологий и инструментарий Оптимальный и понятный процесс разработки Корректная работа над требованиями
С первым пунктом можно разобраться без решения задач в коде самостоятельно, так как это про найм.
Выбор стека технологий можно доверить команде и понадеяться, на их техническую экспертизу, опыт и знание технологий. В целом, ничего страшного не произойдет, но с большой вероятностью вы столкнетесь с тем, что получите спор о том, какой стейт-менеджер использовать, что взять в качестве ORM. И решать этот спор и принимать решение придется уже руководителю. Отвечать за последствия в виде неожиданного vendor lock, баги фреймворка тоже.
Оптимизация процесса разработки - это большая и бесконечная задача. Здесь очень важны детали, контекст и то, что происходит во время реализации проекта. И здесь, по моему мнению, лучше один раз увидеть, чем сто раз услышать.
Можно проводить опросы, встречи тет-а-тет, смотреть на трекеры и метрики, и в итоге самому сесть за задачу и на себе прочувствовать все, о чем говорят разработчики. Только при таком погружении руководитель может сесть в одну лодку с командой и пойти на одной волне.
Можно говорить, что это просто трата времени, но эта трата времени позволит избежать ситуации, когда ваши советы будут из разряда: «делай хорошо, а плохо не делай».
На одной из моих прошлых работ мы придерживались релизного цикла «1 день - 1 релиз». И в какой-то момент релизы начали задерживаться и выходит 1 раз в 2 дня или даже в три. История про релиз таски 48 часов подряд становилась не историей. Начался анализ процесса методом «сверху» и кроме вариантов: быть внимательнее, лучше тестировать, делать задачи без багов ничего не приходило в голову ни одной из сторон, участвующих в релизном процессе. Советы эти были не рабочие.
Тогда я сделал задачу, отправил ее в прод и провел пару дней в роли релиз-инженера. И взгляд изнутри позволил найти проблемы с неожиданной стороны, связанной с архитектурой и устройством проекта, связанностью кода. В итоге все выросло в большие задачи на апдейт архитектуры и процесс наладился.
В моем случае на понимание проблемы ушло несколько дней без нудных разговоров и рассказа очевидных вещей команде.
Так как вы управляете процессом написания кода, то будет не лишним знать его изнутри. Вы не обязаны писать большие фичи и делать крупные задачи, достаточно мелких правок, багов и небольших фичей.
Разделять и понимать трудности команды - это иметь возможность улучшить результаты реальными методами.
· 31.01
Поддерживаю, тезис, что руководитель точно должен писать код. Как руководиль небольшой команды, это мне позволяет точнее и правильнее описывать задачи для команды.. давать рекомендации по решению.. на лидовских и отчетных синках давать честную оценку по статусу работ.. да, написание кода не должно быть на равных с разработчиками в команде.. но то до чего у других не дотягиваются руки, снижать тех долг и по мелочи причесывать..можно брать безболезненно. )
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён