Разрушение силосов: как повысить устойчивость вашей команды и избежать «фактора автобуса»

Вы когда-нибудь слышали о таком понятии, как «фактор автобуса»? Если нет, позвольте мне вас с ним познакомить. Фактор автобуса — это простая идея, не требующая сложного понимания.

Просто задайте себе вопрос: сколько членов вашей команды должны внезапно стать недоступными (например, из-за несчастного случая или спонтанного отпуска), чтобы работа вашей команды полностью остановилась?

Разумеется, никто не хочет, чтобы с кем-то случались неприятности, поэтому лучше представить более лёгкий сценарий. Когда люди уходят в запланированные отпуска, получают повышение или покидают работу, обычно остаётся время на передачу знаний и документов. Но что, если ваш коллега немного переборщил на мальчишнике и оказался застрявшим в другой стране без доступа к ресурсам? (Более оптимистичная альтернатива попаданию под автобус.) Сможет ли ваша команда продолжить работу и выполнить обязательства перед заинтересованными сторонами, если этот сотрудник окажется недоступным?

Во многих дисфункциональных командах, с которыми я сталкивалась, фактор автобуса зачастую равен единице. Потеря даже одного члена команды может привести к полной остановке или серьёзным задержкам в работе. Естественно, даже высокоэффективные Agile-команды могут столкнуться с трудностями при временной утрате одного из членов. Однако работа не прекратится полностью: оставшиеся члены команды смогут взять задачи на себя и продолжат двигаться вперёд, в конечном итоге доставив функциональный продукт.

Силосы вредят не только потому, что мешают синергии, возникающей от командной работы, но и потому, что создают значительные риски для вашего продукта или проекта. Но означает ли это, что все члены команды должны стать мастерами на все руки и глубоко разбираться в тонкостях работы друг друга? Должны ли UX-дизайнеры проходить курсы по Python, а тестировщики изучать цифровой маркетинг? Хотя расширение навыков всегда полезно, это не всегда наиболее практичное использование времени и ресурсов. И нет, вашим backend-разработчикам не нужно становиться экспертами в Photoshop или Figma.

Тем не менее важно, чтобы члены команды знали роли друг друга, понимали, где хранятся ключевые данные, и были знакомы с основными контактами. Рассмотрим несколько гипотетических сценариев, чтобы показать, как работает команда с силосами и без них в различных ситуациях.

Знакомьтесь, Линда

Линда работает UX-дизайнером в команде разработки приложений. Большую часть своих дизайнов она создаёт в Adobe XD, а прототипы собирает в InVision. Команда усердно работает над новой функцией, уже анонсированной для клиентов и вызвавшей значительный интерес в СМИ. Линда — единственный UX-дизайнер в команде, и сейчас она завершает дизайн пользовательского интерфейса для этой долгожданной функции. Но вот в понедельник утром Линда не приходит на работу, и её телефон недоступен.

Представьте себе, что команда Линды работает в силосах, где каждый сосредоточен только на своей части продукта. Владелец продукта пишет спецификации (и было бы удивительно, если бы такая команда могла написать правильные пользовательские истории), а iOS- и Android-разработчики программируют, пока QA-тестировщики проверяют их работу. Когда Линда пропадает, разработчики не могут продолжать, и работа замирает, пока команда ищет замену. Новому дизайнеру потребуется несколько дней, чтобы понять проблему, изучить предыдущие версии приложения и создать новые дизайны с нуля. Функция задерживается, и клиенты остаются разочарованными.

Линда возвращается через два дня и объясняет, что оказалась в домике у бабушки у озера, где из-за грозы пропало электричество. С разряженным телефоном она не смогла вызвать такси или предупредить коллег. Все рады, что с Линдой всё в порядке, но заинтересованные стороны недовольны задержкой релиза.

Теперь представим, как этот же сценарий разворачивается в коллективной команде. Когда Линда не появляется на работе, её коллеги не начинают сами заниматься дизайном. Однако у всех есть доступ к Adobe XD и InVision, они знают, где Линда хранит свои работы, и легко находят её последнюю версию, сохранённую накануне. Оказывается, дизайны почти завершены, а функциональность новой функции понятна всем благодаря кликабельному прототипу, который Линда закончила в пятницу. У владельца продукта есть замечания по паре кнопок, но исправить их — задача на 30 минут, с которой легко справляется дизайнер из другой команды. Кроме того, Линда ведёт гайдлайны дизайна на общем диске, что позволяет любому дизайнеру быстро подключиться и завершить работу. Несмотря на беспокойство о Линде, работа продолжается, и приложение выпускается в срок.

Выводы

Чем более изолированно работают члены вашей команды, тем выше риски. Жизнь непредсказуема, и хотя я надеюсь, что никто не попадёт под автобус, всегда остаётся вероятность болезней, семейных чрезвычайных ситуаций или даже сценариев в духе фильма «Мальчишник в Вегасе» (татуировки на лице и тигры, не так ли?). Разрушение силосов не обязательно означает, что все члены команды должны работать над всем. Это означает, что они смогут поддерживать друг друга в случае необходимости. Вот несколько шагов, чтобы разрушить силосы:

• Используйте общие папки для рабочих документов и требуйте от команды хранить там все материалы, включая промежуточные результаты. Такие сервисы, как Google Drive, Box, Dropbox и SharePoint, помогут легко организовать общее хранилище.

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

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

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

• Разрабатывайте вертикально срезанные пользовательские истории. Обычно они требуют совместной работы нескольких членов команды с разными навыками, способствуя взаимному обучению и пониманию инструментов друг друга.