Маша

Есть довольно плохой способ понять, хватает ли людей команде. Посчитать людей.

В команде десять человек. Бизнес недоволен скоростью. Значит, давайте наймём ещё пять.

Было десять. Стало пятнадцать. На бумаге производительность должна вырасти процентов на пятьдесят.

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

И UI/UX, кстати, тоже Маша.

Тестирование держится на Игоре. В DevOps два человека знают, где примерно лежит Kubernetes, но если действительно что-то случится, начинается коллективное изучение документации.

И вот у нас уже пятнадцать человек.

Но четырнадцать из них периодически ждут Машу.

Удивительная масштабируемость. Мне нравится для таких случаев очень простая штука — матрица компетенций.

Берём людей по вертикали. По горизонтали пишем то, что реально нужно команде: backend, frontend, аналитика, QA, автотесты, DevOps, UI/UX.

И ставим условные уровни:

1 — что-то знаю. 2 — могу нормально работать. 3 — могу вытащить сложную задачу и научить остальных.

Получается такая МРТ команды.

До неё кажется: «Нам нужен ещё backend-разработчик».

После неё: «У нас вообще-то четыре backend-разработчика. Нам нужен второй человек, который понимает аналитику, потому что если Маша уйдёт в отпуск, продукт тоже немного уйдёт в отпуск».

И дальше появляется T-Shape.

Название умное, мысль очень простая.

У каждого должна быть своя глубокая специализация.

Backend должен хорошо знать backend.

QA — тестирование.

Аналитик — аналитику.

Но вокруг основной профессии желательно уметь ещё немного жить.

Backend-разработчик может посмотреть pipeline.

QA способен написать автотест. Аналитик понимает базовый UX. Frontend может разобраться, почему запрос до backend вообще не доехал.

Не для того, чтобы превратить всех в людей-оркестров. Я вообще не очень верю в человека, который одинаково хорошо пишет Java, рисует интерфейсы, строит Kubernetes и после обеда проводит CustDev.

Скорее всего, он просто одинаково плохо делает всё сразу.

T-Shape нужен для другого.

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

И чтобы отпуск одного человека не становился событием уровня disaster recovery.

Есть ещё одна полезная часть. Смотреть надо не только на людей, но и на будущую работу.

Берём backlog хотя бы на полгода. Группируем задачи. Интеграции. Маленькие доработки. Большие изменения. Инфраструктура. Масштабирование.

И примерно считаем, сколько каждой компетенции там потребуется.

Только не надо верить в идеальные часы.

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

Есть встречи. Инциденты. Отпуска. Переключения. «Можно на пять минут?». И задача, которая почему-то была маленькой до первого merge request.

Поэтому расчёт всё равно будет приблизительным.

Но даже приблизительный расчёт сильно лучше метода: «Мне кажется, нужен ещё разработчик».

Я сейчас вообще всё меньше начинаю проектирование команды с вакансии.

Сначала хочется понять, где команда сломается, если завтра исчезнет один человек.

А потом уже открывать HeadHunter.

Потому что иногда вам нужен ещё один разработчик.

А иногда вам просто нужен ещё один человек, который знает то, что сейчас знает только Маша.