НЕТЕХНИЧЕСКИЙ ТИМЛИД

Может ли не разработчик (продакт/проджект) быть эффективным руководителем разработчиков? Какие подводные камни могут быть?

Вот такой вопрос недавно получил в форме. И волею судеб, несколько раз встречался с ним на последних эфирах. Что ж, давайте разбираться.

У тимлида разработки, как правило, есть 3 основные зоны ответственности:

1. Команда – ресурсное управление, мотивация

2. Скоуп – сделать работу, которая ожидается от команды

3. Качество – технологическое качество продукта (архитектура, код) и QA. Иногда QA уходит куда-то в сторону

Функцию управления командой у тимлидов часто отбирают, уже научились с этим работать. Забирают себе ПМы, руководители следующего уровня (аля Engineering Manager) и т п.

Управление скоупом для нетехнаря – задачка выполнимая. Главное иметь какой-то общий технический кругозор, понимать бизнес и продукт, уметь в регулярный менеджмент. Есть здесь, правда, один камешек под водой. Надо уметь распознавать, когда технари втирают очки. А то бывает “Почему дедлайн просрочили? – Ой, там старое легаси, архитектура плохая, пришлось рефакторить …” и прочее блаблабла, да еще и с кучей технических терминов. Здесь бы помощник-технарь пригодился.

А вот с управлением качеством тут все не очень радужно. Это же и про код красивый, и про архитектуру правильную, и про управление техдолгом эффективное, и про конфликты технические. Тут без глубокого контекста уровня синьора не разберешься. Увы.

Итого примерно 50/50 получается. Часть задач и зон ответственности нетехнический тимлид закроет легко, а часть – с пробелами. Но эти пробелы можно нивелировать. И тут может быть 2 варианта:

1. Силами всей (или части) команды – как в Scrum нам говорят, команда сама за все отвечает, кросс-ревью, общие грумминги, архитектурные коммитеты и т д

2. Введением роли техлида/архитектора – отдаем ему вопросы про качество и частично про скоуп, и все складывается. Главное, только, чтоб верный человек был, чтоб доверять ему можно было. А то будет тоже самое “Ой, там старое легаси, архитектура плохая, пришлось рефакторить …”, только на максималках

Итого, резюмируя – ответ ДА, МОЖЕТ. Подводные камни есть, но они закрываются. А по статистике, продакты и проджекты как-то лучше справляются с менеджерской работой, чем технари. Нет у них такого к ней отвращения, и нет желания (и возможности) занырнуть в код и забыть обо всем вокруг. Даже на время.

Надеюсь, получилось ответить на вопрос.

P.S. А форма для новых вопросов все та же, никуда не девается. Пишите свои вопросы, будем разбираться!