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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Тимлид

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как расти?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Интересные статьи

Интересные статьи

Здравствуйте. Я уже давно не пишу на php, но то и дело натыкаюсь на интернет-магазины на системе управления сайтами Битрикс. И я вспоминаю о своих исследованиях. Битрикс не любят примерно так,...
В этой статье поделюсь опытом отбора идей для развития функционала наших продуктов и расскажем, как удержать основные векторы развития. Мы разрабатываем автоматизированную систему расчетов (АС...
На сегодняшний день у сервиса «Битрикс24» нет сотен гигабит трафика, нет огромного парка серверов (хотя и существующих, конечно, немало). Но для многих клиентов он является основным инструментом ...
Тема статьи навеяна результатами наблюдений за методикой создания шаблонов различными разработчиками, чьи проекты попадали мне на поддержку. Порой разобраться в, казалось бы, такой простой сущности ка...
Один из самых острых вопросов при разработке на Битрикс - это миграции базы данных. Какие же способы облегчить эту задачу есть на данный момент?