Лестница развития разработчика. Критерии успеха.

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

Правильное разделение зон ответственности - ключ к мотивации и эффективности команды. Было бы глупо отдавать проектирование новичкам и надеяться на то, что они не будут вызывать конфликтов.

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

“Лестница” технических специалистов

В целом принято следующее разделение специалистов по уровню компетенции:

  • Технический директор
  • Тимлид (TeamLead)
  • Ведущий разработчик (Senior Developer)
  • Разработчик (Middle Developer)
  • Начинающий разработчик (Junior Developer)

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

К примеру, нельзя ставить на должность TeamLead-а специалиста, плохо умеющего коммуницировать и решать конфликтные ситуации.

Как организовать разделение должностей

Когда вы будете продумывать иерархию должностей, для каждой найдите ответы на три вопроса:

  • Какова будет мотивация роста на более высокую должность?
  • Какие будут правила для наказаний?
  • Каковы будут критерии отбора на должность?

Ваши сотрудники должны будут чётко понимать: что нужно, чтобы получить ту или иную должность, как понять, что ты успешно работаешь на своей позиции, а за какие ошибки по головке не погладят.

Никогда не получится донести концепцию за один раз, правила игры нужно внедрять планомерно, проговаривая и обозначая их в каждой сложной ситуации. На достижение понимания нужно порядка одного-двух месяцев, а первые ощутимые результаты будут примерно через 4 месяца - самые активные сотрудники придут к Вам со своими инициативами, в рамках общих правил.

Пример разделения ответственностей

“Умная голова сто голов кормит, а худая и себя не прокормит”, и любая компания является отражением подхода его руководства.
Поэтому разделение ответственностей начинается с руководства, и для руководства также должны быть свои правила и мотивации. 
Ниже будет рассмотрен пример такого разделения. Вы можете прочитать его детально, или только пробежать глазами интересную Вам часть. 
На чтение ниже описанной инструкции у вас уйдёт не более 7 минут, но она даст вам целостное понимание возможной структуры компании.

Технический директор

Идеальный техдир - это:

  • Провидец, который заранее подстелил соломку где нужно
  • Специалист, который обладает обширными связями с технарями
  • Управленец, который формулирует KPI и развивает по ним производственные отделы

Его функция - чтобы всё работало, и работало хорошо.

Зона ответственности

  • Инфраструктура (чтобы не было простоев и трений)
  • Регламенты (чтобы задачи выполнялись эффективно)
  • Развитие сотрудников (чтобы всех хватало под задачи)

Куда возможен рост

  • Руководитель проекта - если интерес к проектам
  • Руководитель производства - если интерес к организации и KPI
  • Генеральный директор - если интерес к бизнесу и обширным связям

Тимлид

Тимлид - это технический специалист, который руководит одной из технических команд в компании. В идеале это должен быть:

  • Сфокусированный на людях разработчик
  • Имеющий большой опыт в своей и смежных темах
  • Умеющий формулировать мысли
  • Имеющий публикации на профильных ресурсах

Проверить, что специалист умеет выражать свои мысли очень просто: проверьте, как он уже делал это, и дайте ему простенькую коммуникационную задачку. Пусть он объяснит что-то сложное, сформулирует русским языком какой-то план решения или ему подобное.

Зона влияния тимлида

  • 2-3 человека в своей команде
  • право писать тз, описывать АПИ и стандарты
  • право рулить проектом или его значительной частью целиком
  • распределять задачи (а следовательно, и формулировать их)

Зона влияния - это, собственно, то, ради чего сотрудник работает. То, что он делает каждый день, и то, что составляет суть его работы. 
Одновременно с этим зона влияния - это заслуженная привилегия. Ненамеренное вмешательство в неё - худший из пороков для руководителя, который может привести к ухудшению отношений. Старайтесь не влезать в зону влияния подчинённых без их согласия и/или объяснённой причины.

Одновременно с этим, вмешательство в зону влияния может быть наказанием за ошибку.

Ответственность тимлида

  • Качество, сроки, пригодность к экспулатации выпускаемого продукта
  • Отчуждаемость задач, технических заданий, документации

Как расти тимлиду?

  • Растить свою команду
  • Разрабатывать действительно хорошие стандарты
  • Прикрывать своих ребят и своё руководство
  • Знакомиться со специалистами в отрасли

Очень важно донести до сотрудника как ему расти, и согласовать эти стратегические направления с ним. Они будут меняться и адаптироваться под конкретного человека, его личные жизненные цели, но суть будет оставаться той же.

Не является тимлидом...

  • Специалист, который плохо выражает свои мысли
  • Сотрудник, который оправдывается
  • Про*бывает согласования решений

Конечно “и на старуху бывает проруха”, и было бы некорректно за разовую ошибку увольнять сотрудника. Но если тимлид хочет расти - ему нельзя допускать перечисленные ошибки. Потому что выше по лестнице требования только выше.

Ведущий разработчик

Идеал ведущего разработчика

  • “Мужик, сказал - сделал” - верность своему слову и желание, чтобы его слову верили
  • Делает работу быстро и без багов
  • Хорошо знает свой стек технологий, хотя может и ошибаться в соседних

Ответственность

  • Качество, срок выполнения конкретной задачи
  • Инициатива в случае сомнений
  • Согласование любых изменений относительно поставленной задачи

Как расти?

  • Чётко вести документацию, описания задач
  • Расширять кругозор
  • Закрыть инфраструктурный вопрос для компании
  • Полгода в позиции ведущего
  • Позитивные отзывы об оформлении тикетов и ответов на них со стороны других разработчиков и тимлида
  • Писать публикции на профильных ресурсах

Не является ведущим разработчиком

  • Специалист, который на каждую мелочь отбивается фразой “этого не было в тз/задаче”.
  • Специалист, который лжёт
  • Специалист, у которого после завершения задач более 30% от истраченного времени уходит на исправления

“Средний” разработчик

Как расти middle разработчику?

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

Требования к “среднему” разработчику

  • знает основные технологии, необходимые для разработки
  • пишет решения в общем код-стайле
  • хорошо знает основы программирования (например, самое банальное: обнуляет переменные перед использованием)
  • комментирует код

Не миддл-разработчик - это тот, кто:

  • не умеет отлаживать (аякс, код, инфру)
  • не умеет гуглить
  • не подписан хотя бы на хабр

Начинающий (Junior) разработчик

Требований к начинающему разработчику кроме живого интереса и готовности учиться выдвигать нерационально. В большей степени всё упирается в готовность или неготовность взять на себя все сложности обучения новичка у руководства.

Как расти начинающему разработчику?

  • учиться, учиться, учиться!
  • безбажно закрыть 5 тикетов
  • рекомендация от 2х ведущих разработчиков, их готовность взять джуниора к себе в команду как миддла
  • от трёх месяцев в позиции джуниора