Bus factor и рассеивание зоны ответственности: все про всё vs узкая специализация
Многие знакомы с понятием bus factor («фактор автобуса»). Оно означает количество участников проекта, после потери которых («попадания под автобус») вы не сможете завершить проект в срок. Это очень важный фактор, который надо учитывать при распределении задач. Значение bus factor, равное двум или трем, — неплохой показатель для команды. Если bus factor равен двум, то проект встанет при потере (например, одновременном уходе в отпуск) двух сотрудников, то есть временное отсутствие одного сотрудника мы сможем легко пережить.
Поддержание bus factor на должном уровне — задача, которой необходимо уделять внимание. Есть множество приемов, которые помогают сотрудникам делиться рабочей информацией: ревью выполненных задач коллегами, документирование работы, групповые обсуждения. Не буду останавливаться на методах, в каждом проекте они свои в зависимости от специфики задач и команды.
О чем мне действительно хочется поговорить — это о концепции «универсального солдата». Многие руководители пропагандируют идею, что при работе над проектом каждый сотрудник должен уметь выполнить любую задачу. Основные аргументы в защиту этой идеи таковы:
- Если ваши рабочие инструменты в порядке и вы документируете то, что делаете, любому сотруднику на проекте не составит труда доделать задачу за коллегу.
- Когда все могут делать всё, у вас нет незаменимых людей, вы можете безболезненно пережить увольнения или временное отсутствие подчиненных.
- Вы можете часто перетасовывать людей и задачи, и никто из вашей команды не будет скучать.
Как-то мне довелось управлять командой, в которой эта идея была доведена до абсолюта. Действительно, каждый участник команды мог выполнить любую задачу, все на проекте документировалось как надо. Людям не приходилось скучать, занимаясь одним и тем же. Но у этого подхода были свои недостатки: на документирование всего и вся уходило очень много времени, и часто игра просто не стоила свеч. Никто из команды не мог внятно и ответственно рассказать о какой-то части проекта, потому что все переходили из одной предметной области в другую и плохо представляли, как выглядит картина в целом. Все были не в состоянии продумать и структурировать решение для очередной задачи за короткий срок, потому что никто не был погружен в задачу с головой, и многие решения оказывались поверхностными.
Бывают проекты, в которых нужен именно такой подход. Например, по каким-то причинам у вас большая текучесть кадров, или вы выполняете краткосрочные проекты, или проекты в целом несложные и важно их выполнять быстро и эффективно, без необходимости что-то изобретать. Но на долгих и сложных проектах я лично предпочитаю, чтобы у участников команды была узкая специализация.
Все по-настоящему классные решения в работе, которые я видела, будь то решения программиста, дизайнера или менеджера, принимались людьми, которые проникались проблемами, лежащими в их зоне ответственности, до мозга костей. Если вы закрепите за кем-то определенный круг задач, со временем человек начнет относиться к этим задачам с большим энтузиазмом, потому что это будет полностью его личная сфера ответственности. Одно дело — закончить задачу, которая досталась тебе после кого-то по наследству, другое — развивать то, во что ты уже вложил много своих сил и времени.
Мое личное мнение: у каждого человека, участвующего в проекте, должна быть своя специализация, та область, в которой именно он будет экспертом, если в рамках проекта это возможно. Несомненно, надо следить за тем, чтобы у каждого члена команды на всякий случай был дублер, также надо соблюдать «гигиенический минимум» обмена знаниями. Однако не стоит постоянно переключать людей с одной предметной области на другую, если проект позволяет этого не делать. Проанализируйте ситуацию в команде и найдите баланс.
