На днях мне пришло предложение попробовать себя от одной компании, имеющей центр разработки в Киеве. В глаза мне бросился состав команды, который я считаю очень рискованным и неэффективным: 1 backend разработчик, 1 frontend разработчик, 1 QA и 1 PM. В фейсбуке разгорелась дискуссия и нашлись люди, которые считают такой состав вполне себе жизнеспособным. Поэтому я решил описать чуть подробнее в чем суть проблемы и какие риски несет такая команда.

Первая проблема заключается в так называемом bus factor (количество людей, которых должен сбить автобус, чтобы у вашего проекта были большие проблемы). Значение 1 считается очень рискованным, потому что в случае ухода специалиста (в отпуск, другую компанию, на больничный и т.д.) команда не может больше реализовывать функциональность пока не будет найдена адекватная замена. Чем сложнее и больше объем задач на этом специалисте, тем больше усугубляется указанный риск, потому что заменить его становится еще тяжелее. В рассматриваемой команде этот фактор равен 1 во всех направлениях.

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

Следующая проблема в балансировке нагрузки между frontend и backend. В случае наличия единственного специалиста в одной из областей он может стать серьезным bottleneck, особенно если наткнется на технологическую проблему в одной из задач, которая застопорит его работу. В итоге зачастую возникают простаивания других специалистов или реализация задач с меньшим приоритетом.

Ну и наконец, не очень эффективно иметь PM на такую крошечную команду. Создается ощущение, что это скорее part-time работник Excel и JIRA, который стоит между заказчиком и командой. Некоторые компании решают сделать “оптимизацию” и дать одному PM целый пучок таких проектов на “присмотреть”. Это значительно уменьшает вовлеченность и в случае проблем на одном проекте внимание к другим проектам уменьшается до минимума.

Это все хорошо, но что делать, если в компании так заведено и считается нормой? Есть несколько вариантов снижения указанных рисков и улучшения эффективности.

Вместо PM в рамках одной команды отлично работает позиция Team/Tech Lead вместо PM. Он перекрывает риски по разработке и в то же время выполняет функции part-time PM. При этом, как выделенный Lead на проекте, он на 100% вовлечен и ведет команду к успеху. Team/Tech Lead является технически грамотным в разработке, поэтому можно избежать формата мини-галеры с погонщиком.

Можно объединить 2 такие команды в одну и удвоить количество специалистов в каждом направлении. Таким образом получится гораздо проще балансировать нагрузку и при этом избегать проблем из-за bus factor. В итоге получаем команду следующего состава: 1 TL, 2 BE, 2 FE, 2 QA. В сумме это 7 человек и с точки зрения эффективности коммуникаций работает все еще отлично.

Следующей мерой может быть распределение QA роли между всеми участниками команды. Это не только позитивно влияет на качество, но и существенно повышает эффективность, потому что waste на исправления сводится к минимуму, а больший фокус идет на закладывание качества с самого начала. В этом случае можно даже сократить количество выделенных QA инженеров до 1. Ведь даже в случае его отсутствия качество не должно пострадать.

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

Никто не говорит про то, что изначальный обсуждаемый состав команды вообще неработоспособный и не может существовать. Просто он накладывает ряд ограничений и таит в себе множество рисков…