fbpx
Что не так в команде 1 BE + 1 FE + 1 QA + 1 PM?

На днях мне пришло предложение попробовать себя от одной компании, имеющей центр разработки в Киеве. В глаза мне бросился состав команды, который я считаю очень рискованным и неэффективным: 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. Ведь даже в случае его отсутствия качество не должно пострадать.

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

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

Обсуждение (
Warning: A non-numeric value encountered in /sata1/home/users/xpinjecti/www/www.xpinjection.com/wp-includes/pomo/plural-forms.php on line 280

Warning: A non-numeric value encountered in /sata1/home/users/xpinjecti/www/www.xpinjection.com/wp-includes/pomo/plural-forms.php on line 280

Warning: A non-numeric value encountered in /sata1/home/users/xpinjecti/www/www.xpinjection.com/wp-includes/pomo/plural-forms.php on line 280

Warning: A non-numeric value encountered in /sata1/home/users/xpinjecti/www/www.xpinjection.com/wp-includes/pomo/plural-forms.php on line 280

Warning: A non-numeric value encountered in /sata1/home/users/xpinjecti/www/www.xpinjection.com/wp-includes/pomo/plural-forms.php on line 280

Warning: A non-numeric value encountered in /sata1/home/users/xpinjecti/www/www.xpinjection.com/wp-includes/pomo/plural-forms.php on line 280
6)

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

в маленькой команде нужны только девы и тим лид, смысл набирать брать всяких QA и PM??? На начальном этапе нужны только люди которые будут делать продукт.

Это может ударить как по бюджету так и по коммуникациям в команде. 🙂

Можно просто на каждую позицию по 3-4 взять, это уменьшит bus factor

Это на самом деле самый лучший вариант, если бы не одно НО. В текущих реалиях backend и frontend развились до такой степени независимо, что серьезные full stack разработчики встречаются не чаще единорогов. 🙂 Поэтому я не предлагаю этот вариант как рабочий для большинства проектов.

Еще один вариант трансформации который уменьшает bus factor и увеличивает эффективность брать t-shape cross functional team members.
Пример: 1 fronted 1 backend 1 PM 1 QA -> 1 full stack TL, 1 full stack SE , 1 full stack SE + DevOps, 1 QA+Automation

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Мы используем файлы cookies для различных целей, включая аналитику и персонализированный маркетинг. Продолжая пользоваться сайтом, вы соглашаетесь на использование файлов cookies. Подробно ознакомиться с правилами работы с файлами cookies можно здесь

принять
Pkv Games BandarQQ Online Terbaik Dengan Deposit Super Modern permainan paling populer di situs poker online terbaik di indonesia di situs bukaqq Poker Online Aman dan Terpercaya slot online