Всем привет. Знакомые, коллеги, друзья, часто спрашивают меня, как построить команду. «Вот ты свои строишь так, что они спустя некоторое время горы сворачивают, хотя отдельные сотрудники не являются гениями. Как ты это делаешь?» Как‑то само получалось, решил написать о своем опыте в серии статей. Надеюсь зайдет. Это первая, про специализацию и кросс‑функциональность, про то, кто должен быть в команде.

Спойлер: никак, идеальная команда — редкость, но можно сделать свою почти идеальной.

Что такое идеальная команда?

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

Ответ очень простой. Посмотреть по сторонам, и понять, что ваша идеальная команда на самом деле рядом с вами, это ваша команда. Да, там могут быть поправки на культуру компании и особенности отдельных сотрудников. Но если нет критической ситуации, то ваша идеальная команда, на самом деле, рядом с вами и вы ее часть.

Почему так получается?

Есть такая штука как Scrum Guide, в котором написано про кросс‑функциональные команды. Излишние цитаты ни к чему, много сказано на эту тему. В контексте данной статьи важно, что порой мы слишком увлекаемся индивидуальной кросс‑функциональностью в ущерб именно командной. Да, есть фуллстек разработчики. Да, в командах можно работать без наличия какой‑то специальности, типа аналитиков или тестировщиков. Сам одно время работал так, знаю, о чем говорю. Но ситуации, когда все делают всё, не видел нигде, кроме стартапов или небольших контор на этапе становления. Потом все равно специализация начинается.

Туда же история с T‑Shape сотрудниками. Хорошо работает до определенного предела. Когда мы решаем простые и средние задачи, то в целом индивидуальная универсальность работает и команда реально перформит. Но как только встречается какая‑то узкоспециальная история, приходится звать на помощь сумрачного Васю, I‑Shape, который и общаться не всегда нормально общается, и знать про другие вопросы ничего не хочет. Сидит у себя в каморке и делает что‑то непонятное. А иногда нужен непонятный Иван Иванович, который явно ничем полезным не занимается, глубоко ничего не знает, но умеет переводить с русского на русский. Это человек‑прочерк, у него только верхняя палочка от буквы Т. При этом он действует как клей, соединяющий людей воедино.

Видел, что хорошо работает подход с разумной специализацией как в римском легионе: где мы задаем набор правил, ролей, помогаем команде правильно организовать свою работу и тогда она сможет правильно делать правильные вещи, сама развиваться, сама достигать новых вершин. Когда Римская Империя задавала перцу всем своим соседям, она не была идеальной. И отдельные ее руководители не были идеальными. И отдельные римские легионеры не были идеальными. Средний римский воин был порой слабее карфагенянина или какого‑нибудь галла. А вот легион за счет правильной организации их на голову делал. Другими словами, разумная специализация.

Специализация бывает по уровню в профессии, по ролям, по технологиям.

Кто лучше сеньор, мидл или джун?

Сеньор. Круче него никого нет. Он сам тянет сложные темы и других за собой ведет. Только, если у вас команда из одних сеньоров, то у вас может не быть нужного количества сложных направлений. Они скучают, воюют друг с другом, пишут грустные истории про перекладывание json‑ов за кофе в крупной корпорации.

Джуны. Много джунов при должной организации и наличии Stack Overflow богоподобны. Есть даже стратегия Zerg rush: «наймем много дешевых джунов, пару сеньоров и захватим мир». Стратегия интересная, только работает в ограниченном наборе случаев, когда у вас есть хороший бренд, стажеры, что называется, стоят за забором, проекты временные и не слишком сложные. Этой стратегией вы сжигаете своих сотрудников и свою команду.

А если работаете вдолгую, то на самом деле нужны все, в разных пропорциях. Кто‑то делает и сложные задачи, а кто‑то простые. В зависимости от размера команды, это 1–2 сеньора на сложные вещи и архитектуру, 3–4 мидла на «тащить» и остальные джуны на простые задачи и на вырост.

Но, допустим, есть члены команды, что они будут делать.

Какие роли нужны?

В моей картине мира должны быть те, кто отвечают на следующие 4 вопроса:

• Что мы хотим и с каким приоритетом?

  • Обычно это заказчик или продуктолог (Product)

• Как мы можем это сделать и на каких технологиях?

  • Обычно это техлид, техмен, архитектор (Tech)

• Как это организовать?

  • Обычно это проджект (Project)

• Кто это будет делать?

  • Ресурсный руководитель, ну или сами инженеры (Resource, Team, Function)

На какие вопросы еще отвечают?

• Кто придумывает что‑то? То есть делает Дискавери (продуктовое или техническое исследование)

  • Его можно назвать Владельцем/Овнером (Owner)

• Кто реализовывает что‑то? То есть делает Деливери (продуктовая или техническая реализация)

  • Его можно назвать Руководителем/Менеджером (Manager)

Если скомбинировать, то получим вот такие варианты ролей. И бывает, что на эти вопросы отвечает один человек. А бывает несколько разных. И их можно объединять, например, вот так.

Так все-таки, специализация или универсализация?

Мне нравится статья Мартина Фаулера по этому поводу.
Кратко. Речь идет про команды, ориентированные на результат, а не на деятельность. По сути, внутри команды действительно нет разделения по специальностям (аналитик, разработка, тестирование и т. п.), а все являются универсалами в истинном смысле этого слова. Там же про числа Данбара, принцип Безоса про две пиццы, закон Миллера и т. п.

Мы с вами живем в нашем несовершенном мире больших и не очень больших приложений, работающих на многих устройствах и платформах. Да, могут быть инженеры, которые и требования пишут, и тестируют, и проектируют, и, даже, код пишут. Кстати, получается быстро до определенного предела. Дальше у ребят появляется специализация, как минимум, разработчик‑тестировщик, а, обычно, еще и по платформам: фронты (desktop + touch), мобилки (Android + iOS), бекэнды на разных языках. Понятно, что за счет технологий и кросс‑платформенности это множество можно схлопнуть, но все‑таки не в 0. А еще где‑то бродят дизайнеры, аналитики и прочие важные специальности помимо разработки.

А примеры будут?

Дисклеймер. Работает там, где я работал, у вас может быть другой набор профилей специалистов. Если, например, у вас standalone разработка, то профиль может быть совершенно иной.

Привожу два примера в виде сводной таблицы. В реальности их гораздо больше.

Пример 1. Маленькая команда. Работает, когда нужно что‑то запустить на всех платформах сразу (фронты и мобилки).

Достоинства:

• Относительно быстро и легко собрать на короткой дистанции (до 3 месяцев). Быстро сделали, сдали дела и разбежались

• Обычно собирается, чтобы быстро затащить какую‑нибудь фичу и далее передать ее на баланс существующей команды

• Если нанимается сеньор‑универсал, то его производственная мощность может быть эквивалентна как раз этой команде

Недостатки:

• Bus‑factor, на каждой специальности по 1 человеку. Если кто‑то заболел или ушел в отпуск, работа может встать.

• Все, что из этого следует

Пример 2. Средняя команда, которая может не только запускать, но и поддерживать неограниченно долгое время на всех платформах сразу (фронты и мобилки).

Достоинства:

• Можно собрать на базе маленькой, и постепенно развивать

• Может запускать и поддерживать одновременно

• Все еще управляемая

• Можно шарить избытки ресурсов

• Можно играть в кроссплатформенность на уровне мобилок или фронтов

Недостатки:

• Узкое горлышко на этапе дискавери, если кто‑то из дизайнеров или аналитиков будет отсутствовать, то могут быть небольшие проблемы

• Продуктолог может быть перегружен, поэтому ему требуется помощник для проработки краевых кейсов

• Лид может быть перегружен, если у него нет сеньоров в команде

Дальше можно поговорить про команды еще большего размера, но внутри них обычно появляются подкоманды со своей специализацией. Она может быть и неформальной, но она обязательно есть. Еще команду могут «накачивать» ресурсами, чтобы потом на ее базе отпочковать еще несколько, делают что‑то типа фабрики команд.

Заключение

И все‑таки, как собрать команду? И какую команду собирать? Для этого нужно ответить на следующие вопросы:

• Какие задачи должна решать команда?

• На сколько они сложные и простые?

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

• Узкие или широкие специалисты?

• Большая или маленькая команда?

Я отвечаю на эти вопросы так: вначале нужно посмотреть на фронт работ и планировать формирование команды исходя из него. Неважно, это короткий проект или работа на несколько лет, нужно понимать, что мы хотим делать. А уже из этого искать ребят. В моем опыте задачи обычно делятся на 10–20% сложных задач, 50–60% задач среднего уровня, 20–40% рутинных, может быть, даже неинтересных опытным специалистам, но которые тоже нужно делать. Роли могут быть разными и называться они могут как угодно, но должны отвечать на вопросы: что и как мы делаем, что нужно делать в первую очередь, а что может подождать. Как в технологиях, так и в продукте. Удобнее двигаться командами небольшого или среднего размера, где есть разумная специализация. Если у вас другой опыт, поделитесь в комментах.

Есть еще вопросы о том, как развивать команду, как мотивировать, делегировать и т. п. Об этом в следующий раз.

Минутка саморекламы. Меня зовут Саша Колесников. Много лет работаю в ИТ, преподаю и все такое. Побывал на разных позициях от рядового разраба до большого менеджера. И у нас в стране, и за рубежом. Когда‑то давно писал на Хабре на технические темы. Решил вернуться с менеджерскими.

Если статья полезна и хочется получать апдейты раньше публикаций на Хабре, подписывайтесь на бложик.