09 Мар 2016
Правильное разделение зон ответственности - ключ к мотивации и эффективности команды. Было бы глупо отдавать проектирование новичкам и надеяться на то, что они не будут вызывать конфликтов.
Итак, ниже приведён рецепт для крупного веб-продакшна или агенства, в котором работает более 10 сотрудников. Для подобного производства характерны часто меняющиеся требования, относительно маленькое время на принятие решения и быстрое развитие технологической отрасли (за 2-3 года происходит серьёзная смена или развитие имеющихся парадигм). Поэтому команда прежде всего должна быть гибкой и замотивированной адаптироваться.
В целом принято следующее разделение специалистов по уровню компетенции:
В каждой компании в эти термины вкладывают свой смысл. И тут может скрываться корень больших бед, ведь соль не в названиях, а в иерархии и зонах ответственности.
К примеру, нельзя ставить на должность TeamLead-а специалиста, плохо умеющего коммуницировать и решать конфликтные ситуации.
Как организовать разделение должностей
Когда вы будете продумывать иерархию должностей, для каждой найдите ответы на три вопроса:
Ваши сотрудники должны будут чётко понимать: что нужно, чтобы получить ту или иную должность, как понять, что ты успешно работаешь на своей позиции, а за какие ошибки по головке не погладят.
Никогда не получится донести концепцию за один раз, правила игры нужно внедрять планомерно, проговаривая и обозначая их в каждой сложной ситуации. На достижение понимания нужно порядка одного-двух месяцев, а первые ощутимые результаты будут примерно через 4 месяца - самые активные сотрудники придут к Вам со своими инициативами, в рамках общих правил.
“Умная голова сто голов кормит, а худая и себя не прокормит”, и любая компания является отражением подхода его руководства.
Поэтому разделение ответственностей начинается с руководства, и для руководства также должны быть свои правила и мотивации.
Ниже будет рассмотрен пример такого разделения. Вы можете прочитать его детально, или только пробежать глазами интересную Вам часть.
На чтение ниже описанной инструкции у вас уйдёт не более 7 минут, но она даст вам целостное понимание возможной структуры компании.
Идеальный техдир - это:
Его функция - чтобы всё работало, и работало хорошо.
Зона ответственности
Куда возможен рост
Тимлид - это технический специалист, который руководит одной из технических команд в компании. В идеале это должен быть:
Проверить, что специалист умеет выражать свои мысли очень просто: проверьте, как он уже делал это, и дайте ему простенькую коммуникационную задачку. Пусть он объяснит что-то сложное, сформулирует русским языком какой-то план решения или ему подобное.
Зона влияния тимлида
Зона влияния - это, собственно, то, ради чего сотрудник работает. То, что он делает каждый день, и то, что составляет суть его работы.
Одновременно с этим зона влияния - это заслуженная привилегия. Ненамеренное вмешательство в неё - худший из пороков для руководителя, который может привести к ухудшению отношений. Старайтесь не влезать в зону влияния подчинённых без их согласия и/или объяснённой причины.
Одновременно с этим, вмешательство в зону влияния может быть наказанием за ошибку.
Ответственность тимлида
Как расти тимлиду?
Очень важно донести до сотрудника как ему расти, и согласовать эти стратегические направления с ним. Они будут меняться и адаптироваться под конкретного человека, его личные жизненные цели, но суть будет оставаться той же.
Не является тимлидом...
Конечно “и на старуху бывает проруха”, и было бы некорректно за разовую ошибку увольнять сотрудника. Но если тимлид хочет расти - ему нельзя допускать перечисленные ошибки. Потому что выше по лестнице требования только выше.
Идеал ведущего разработчика
Ответственность
Как расти?
Не является ведущим разработчиком
Как расти middle разработчику?
Требования к “среднему” разработчику
Не миддл-разработчик - это тот, кто:
Требований к начинающему разработчику кроме живого интереса и готовности учиться выдвигать нерационально. В большей степени всё упирается в готовность или неготовность взять на себя все сложности обучения новичка у руководства.
Как расти начинающему разработчику?