Правильное разделение зон ответственности - ключ к мотивации и эффективности команды. Было бы глупо отдавать проектирование новичкам и надеяться на то, что они не будут вызывать конфликтов.
Итак, ниже приведён рецепт для крупного веб-продакшна или агенства, в котором работает более 10 сотрудников. Для подобного производства характерны часто меняющиеся требования, относительно маленькое время на принятие решения и быстрое развитие технологической отрасли (за 2-3 года происходит серьёзная смена или развитие имеющихся парадигм). Поэтому команда прежде всего должна быть гибкой и замотивированной адаптироваться.
“Лестница” технических специалистов
В целом принято следующее разделение специалистов по уровню компетенции:
- Технический директор
- Тимлид (TeamLead)
- Ведущий разработчик (Senior Developer)
- Разработчик (Middle Developer)
- Начинающий разработчик (Junior Developer)
В каждой компании в эти термины вкладывают свой смысл. И тут может скрываться корень больших бед, ведь соль не в названиях, а в иерархии и зонах ответственности.
К примеру, нельзя ставить на должность TeamLead-а специалиста, плохо умеющего коммуницировать и решать конфликтные ситуации.
Как организовать разделение должностей
Когда вы будете продумывать иерархию должностей, для каждой найдите ответы на три вопроса:
- Какова будет мотивация роста на более высокую должность?
- Какие будут правила для наказаний?
- Каковы будут критерии отбора на должность?
Ваши сотрудники должны будут чётко понимать: что нужно, чтобы получить ту или иную должность, как понять, что ты успешно работаешь на своей позиции, а за какие ошибки по головке не погладят.
Никогда не получится донести концепцию за один раз, правила игры нужно внедрять планомерно, проговаривая и обозначая их в каждой сложной ситуации. На достижение понимания нужно порядка одного-двух месяцев, а первые ощутимые результаты будут примерно через 4 месяца - самые активные сотрудники придут к Вам со своими инициативами, в рамках общих правил.
Пример разделения ответственностей
“Умная голова сто голов кормит, а худая и себя не прокормит”, и любая компания является отражением подхода его руководства.
Поэтому разделение ответственностей начинается с руководства, и для руководства также должны быть свои правила и мотивации.
Ниже будет рассмотрен пример такого разделения. Вы можете прочитать его детально, или только пробежать глазами интересную Вам часть.
На чтение ниже описанной инструкции у вас уйдёт не более 7 минут, но она даст вам целостное понимание возможной структуры компании.
Технический директор
Идеальный техдир - это:
- Провидец, который заранее подстелил соломку где нужно
- Специалист, который обладает обширными связями с технарями
- Управленец, который формулирует KPI и развивает по ним производственные отделы
Его функция - чтобы всё работало, и работало хорошо.
Зона ответственности
- Инфраструктура (чтобы не было простоев и трений)
- Регламенты (чтобы задачи выполнялись эффективно)
- Развитие сотрудников (чтобы всех хватало под задачи)
Куда возможен рост
- Руководитель проекта - если интерес к проектам
- Руководитель производства - если интерес к организации и KPI
- Генеральный директор - если интерес к бизнесу и обширным связям
Тимлид
Тимлид - это технический специалист, который руководит одной из технических команд в компании. В идеале это должен быть:
- Сфокусированный на людях разработчик
- Имеющий большой опыт в своей и смежных темах
- Умеющий формулировать мысли
- Имеющий публикации на профильных ресурсах
Проверить, что специалист умеет выражать свои мысли очень просто: проверьте, как он уже делал это, и дайте ему простенькую коммуникационную задачку. Пусть он объяснит что-то сложное, сформулирует русским языком какой-то план решения или ему подобное.
Зона влияния тимлида
- 2-3 человека в своей команде
- право писать тз, описывать АПИ и стандарты
- право рулить проектом или его значительной частью целиком
- распределять задачи (а следовательно, и формулировать их)
Зона влияния - это, собственно, то, ради чего сотрудник работает. То, что он делает каждый день, и то, что составляет суть его работы.
Одновременно с этим зона влияния - это заслуженная привилегия. Ненамеренное вмешательство в неё - худший из пороков для руководителя, который может привести к ухудшению отношений. Старайтесь не влезать в зону влияния подчинённых без их согласия и/или объяснённой причины.
Одновременно с этим, вмешательство в зону влияния может быть наказанием за ошибку.
Ответственность тимлида
- Качество, сроки, пригодность к экспулатации выпускаемого продукта
- Отчуждаемость задач, технических заданий, документации
Как расти тимлиду?
- Растить свою команду
- Разрабатывать действительно хорошие стандарты
- Прикрывать своих ребят и своё руководство
- Знакомиться со специалистами в отрасли
Очень важно донести до сотрудника как ему расти, и согласовать эти стратегические направления с ним. Они будут меняться и адаптироваться под конкретного человека, его личные жизненные цели, но суть будет оставаться той же.
Не является тимлидом...
- Специалист, который плохо выражает свои мысли
- Сотрудник, который оправдывается
- Про*бывает согласования решений
Конечно “и на старуху бывает проруха”, и было бы некорректно за разовую ошибку увольнять сотрудника. Но если тимлид хочет расти - ему нельзя допускать перечисленные ошибки. Потому что выше по лестнице требования только выше.
Ведущий разработчик
Идеал ведущего разработчика
- “Мужик, сказал - сделал” - верность своему слову и желание, чтобы его слову верили
- Делает работу быстро и без багов
- Хорошо знает свой стек технологий, хотя может и ошибаться в соседних
Ответственность
- Качество, срок выполнения конкретной задачи
- Инициатива в случае сомнений
- Согласование любых изменений относительно поставленной задачи
Как расти?
- Чётко вести документацию, описания задач
- Расширять кругозор
- Закрыть инфраструктурный вопрос для компании
- Полгода в позиции ведущего
- Позитивные отзывы об оформлении тикетов и ответов на них со стороны других разработчиков и тимлида
- Писать публикции на профильных ресурсах
Не является ведущим разработчиком
- Специалист, который на каждую мелочь отбивается фразой “этого не было в тз/задаче”.
- Специалист, который лжёт
- Специалист, у которого после завершения задач более 30% от истраченного времени уходит на исправления
“Средний” разработчик
Как расти middle разработчику?
- сделать и защитить решение для компании (библиотеку, модуль)
- учить основополагающие технологии
- учить все возможные методы отладки
- улучшать качество своего кода
Требования к “среднему” разработчику
- знает основные технологии, необходимые для разработки
- пишет решения в общем код-стайле
- хорошо знает основы программирования (например, самое банальное: обнуляет переменные перед использованием)
- комментирует код
Не миддл-разработчик - это тот, кто:
- не умеет отлаживать (аякс, код, инфру)
- не умеет гуглить
- не подписан хотя бы на хабр
Начинающий (Junior) разработчик
Требований к начинающему разработчику кроме живого интереса и готовности учиться выдвигать нерационально. В большей степени всё упирается в готовность или неготовность взять на себя все сложности обучения новичка у руководства.
Как расти начинающему разработчику?
- учиться, учиться, учиться!
- безбажно закрыть 5 тикетов
- рекомендация от 2х ведущих разработчиков, их готовность взять джуниора к себе в команду как миддла
- от трёх месяцев в позиции джуниора
