Существует две школы мышления, когда речь идет об управлении командой: вы можете либо управлять против ошибок, либо управлять для успеха. Управление против ошибок означает возложение ответственности за каждое незначительное решение на одного менеджера. Опытный лидер команды может служить защитой, но когда все требует одобрения кого-то вышестоящего, это замедляет реализацию проектов. Управление для достижения успеха, с другой стороны, означает предоставление полномочий и ответственности отдельным членам команды. Каждый сотрудник отвечает (и принимает окончательные решения) за определенную часть каждого проекта. Именно такую модель управления приняло руководство приложения для общения в команде Asana: они распределяют полномочия по всей своей организации, состоящей из 110 человек, чтобы способствовать доверию, ответственности и быстрому принятию решений. Эту стратегию они называют «Зоны ответственности».
ОБРАБАТЫВАЮЩИЕ ПРОИЗВОДСТВА
Зоны ответственности компании Asana
Зоны ответственности (известные в Asana как AoRs) работают на основе теории, согласно которой текущие цели команды могут быть распределены по компании, чтобы кто-то постоянно двигал их вперед. Отдельные люди могут взять на себя ответственность за эти AoR и принимать решения о том, как улучшить конкретный аспект продукта или команды. Представьте себе компанию, единственная цель которой — устраивать вечеринки по случаю дня рождения. Выбор и закупка торта могут быть ОЗ. Ответственный за торт будет учитывать отзывы своих коллег по команде и клиента, но в конечном итоге он будет принимать решения о вкусе, стиле и размере торта. Команда будет доверять лидеру AoR по торту в принятии правильного решения, не вступая в длительные дебаты. Большинство компаний хотели бы иметь штатного эксперта по тортам, но AoRs Asana немного больше ориентированы на продукт.
Сэм Гоертлер — менеджер по продуктам в Asana, которая работала над приложением для Android и редизайном сайта. У нее два направления деятельности: простота продукта и непрерывное обучение менеджеров по продуктам. В роли гуру простоты продукта Asana она контролирует новые функции, чтобы убедиться, что они не усложняют работу пользователей. С другой стороны, в ее обязанности входит постоянное обучение, она организует выступления приглашенных спикеров, изучает и делится интересными тенденциями в мире управления продуктами. AoRs облегчает для Asana работу таких лидеров, как Гоертлер, над теми аспектами, которыми они увлечены, даже если они не связаны с их должностью. И, как отмечает Келси Ароян из маркетинговой команды Asana, философия AoR встроена в саму структуру продукта Asana: вы не можете поручить задачу более чем одному человеку.
«Вам действительно всегда нужен человек, который будет чувствовать ответственность за доведение проекта до конца, — говорит она. Когда вы сажаете более одного человека на место водителя, это приведет к нескольким спорам». Наряду с ответственностью, система AoR предлагает сотрудникам Asana шесть преимуществ:
- Документация
- Экспертиза
- Сотрудничество
- Прозрачность
- Данные
- Отражение
Документируйте то, что работает, и то, что не работает
Если вы не знакомы с сервисом, Asana — это облачное приложение для управления задачами. Оно позволяет командам видеть, над чем работают все остальные, а задачи можно назначать отдельным людям и прикреплять к проектам. Именно поэтому команда Asana использует публичную «Организацию» — общий список задач, который могут видеть все сотрудники, — в своем приложении для отслеживания AoRs: это естественное продолжение продукта, поскольку AoRs — это отдельные люди, ведущие проекты и задачи для всей команды. «Публичная» часть уравнения тоже важна. Ароян и Гоертлер обнаружили, что когда проекты документируются в открытом доступе, лучшие практики появляются в процессе развития как побочный продукт того, что каждый сотрудник узнает в процессе работы. Эти лучшие практики превращаются в документацию, на которую впоследствии может ссылаться вся команда. Например, Asana регулярно проводит запуски продуктов. Хотя ни один из двух запусков продукта не является абсолютно одинаковым, в каждом проекте есть свои константы.
Доводы «за» и «против», с трудом усвоенные в ходе предыдущих запусков продуктов, используются в последующих. «Я только что провела свой первый запуск нашего нового сайта для разработчиков», — говорит Ароян, которая владеет AOR по маркетингу платформы и клиентов. Помните: она маркетолог, а не менеджер проектов. Но вместо того, чтобы начинать с нуля, Ароян смогла скопировать список задач с предыдущего запуска продукта и использовать его в качестве основы. Благодаря предыдущим лидерам AoR, Ароян знала, с чего начать; она не попала в те же ловушки, что и ее предшественники. А поскольку этот список задач менялся в течение многих запусков, предшествовавших этому, он отражал опыт компании в отношении лучших способов запуска нового продукта. Прочтя список задач, которые перечислялись в шаблоне запуска, она нашла несколько полезных предупреждений из прошлых запусков. Одна из задач: «Сообщите команде разработчиков о дне запуска, а также о тех видах тикетов, которые обычно появляются при запуске нового сайта». Возможно, это не сразу приходит на ум каждому сотруднику отдела маркетинга в начале кампании, но AoRs настроил Ароян на успех.
Создайте сеть внутренних экспертов
«Я не только владею определенной областью продукта, но и знаю, к кому обратиться, когда у меня возникают вопросы о чем-то, что не входит в мою компетенцию», — говорит Гоертлер. У менеджера по продуктам Asana есть несколько историй о том, как прозрачность AoRs улучшила работу в компании. Например, когда команда создавала последнее приложение для iOS, они создавали его с нуля. Ближе к концу проекта они поняли, что им необходимо встроить регистрацию событий. Другими словами, собирать информацию о том, каких кнопок касались пользователи, когда они их касались и как часто, чтобы лучше понять, как люди использовали приложение. Поскольку это было новое приложение, в именовании событий должны были использоваться новые имена. Но, естественно, было бы полезно, если бы они в основном совпадали с другими названиями, используемыми для подобных событий в других продуктах Asana.
Здесь-то и пригодились AoRs: поскольку все в компании могут видеть, у кого какой AoR, они смогли найти человека из команды data science с AoR для «регистрации событий». «Было очень полезно иметь эксперта, который был хорошо знаком с нашим именованием событий на разных платформах, так что после запуска мы получили значимые данные», — говорит Гертлер. Вот еще один пример: Со временем люди перемещаются по компании и получают новые AoR. Службе поддержки бывает сложно отследить, кому должны быть адресованы важные отзывы клиентов. Если AoRs будут видны всем, это значительно упростит задачу, поскольку служба поддержки сможет проверить, кто в этот день управляет конкретной частью продукта, и передать отзыв непосредственно нужному человеку. В другом сценарии обратная связь по дизайну может просто проходить через ведущего дизайнера, где она может замедлиться или исчезнуть в почтовом ящике занятого человека. Таким образом, обратная связь попадает непосредственно к человеку в команде, который ближе всего к проблеме.
Задействуйте всех и поощряйте сотрудничество
Модель AoR поощряет инициативу. Если член команды видит что-то важное, над чем никто не работает, он или она может предложить это в качестве AoR и взять на себя инициативу, если их руководитель согласится. Ароян говорит, что недавно это произошло, когда один из членов ее команды захотел больше думать об устойчивых практиках в компании, и ему было поручено новое задание по устойчивому развитию. Этот подход также может привести к интересному межкомандному сотрудничеству. Ароян начинала в отделе подбора персонала, но недавно перешла в отдел маркетинга. Несмотря на смену названия, она сохранила за собой AoR для хакатонов, потому что хотела продолжать работать непосредственно с командой по продукту и рекрутингу над определенными программами. Это означает, что она сохраняет связь со своим прежним отделом и одновременно работает с новой командой, что должно помочь предотвратить обособление по мере роста компании. По словам Гертлера, это также позволяет людям расти в компании новыми способами. Традиционно считается, что человек добивается успехов, когда он начинает руководить людьми, говорит она. «Есть люди, которые вносят свой индивидуальный вклад в общее дело, но их не интересует путь руководителя», — говорит она. «Они могут продвигаться по карьерной лестнице, беря на себя все более и более важные задачи». Поскольку все точно знают, кто и что возглавляет, ясно, кто несет ответственность за успехи в AoR, когда команда достигает своей цели.
Продвижение прозрачности и подотчетности
Ароян подсчитала, что в Asana около 200 AoR на 110 сотрудников. Тот факт, что она смогла проверить это, иллюстрирует еще один момент в подходе к работе: когда все отслеживается и организуется прозрачным образом, это дает всем возможность знать, кто и за что отвечает. «Если сделать эту информацию полностью доступной для всех, то это действительно распределяет ответственность, — говорит Ароян. Если все знают, что должно быть сделано, то больше шансов, что другие люди, кроме менеджеров, заметят, если что-то не так с проектом». Любой сотрудник Asana может зайти и просмотреть все задачи по любому проекту и выяснить, отмечены они или нет».
Подкрепляйте свой прогресс полезными данными
Asana также делит каждый год на три части и устанавливает цели для каждой команды, которые должны быть достигнуты в течение этих трех периодов времени (они называют их «эпизодами»). Asana уделяет большое внимание ясности, поэтому наличие этих целей в определенные периоды времени позволяет понять, куда все движутся. Asana использует Looker, приложение для визуализации данных, чтобы отслеживать прогресс в достижении целей эпизода. Но это отслеживание появилось не сразу. В блоге Asana, посвященном бизнес-аналитике в компании, команда инженеров отмечает, что первый шаг к отслеживанию прогресса — это выяснение всех возможных видов доступных вам данных, а следующий шаг, по их словам, не заключается в немедленной настройке визуализации. Вместо этого дайте себе время, чтобы понять, что именно вам нужно. Они утверждают, что нужно дать команде возможность поиграть с данными, чтобы они могли понять, что именно они хотят знать. Когда Asana достигла этой ясности, они создали информационные панели, которые висят по всему офису. «Я всегда хочу знать, как моя работа непосредственно влияет на наши цели», — говорит Ароян.
Обдумайте свои результаты
Без рефлексии невозможно понять, правильно ли определены AoRs, и какая работа приносит какие результаты. Команды, которые понимают причинно-следственные связи в своей работе, — это команды, которые уделяют время дыханию. Не случайно Асана названа в честь слова, означающего «поза» в йоге, где дыхание является основой дисциплины. Время для дыхания, паузы и размышлений встроено в календарь компании, как показано в приведенном выше примере данных. Это также позволяет командам создавать такие шаблоны, которые Ароян нашла столь ценными, когда начинала свой первый запуск продукта. Если вы оглянетесь на свою работу, вы сможете вспомнить, что вы делали, чего не было в вашем плане, но что оказалось полезным, а также то, что вы хотели бы видеть в своем плане. Эти задачи можно зафиксировать в шаблоне для следующего раза.
Попробуйте AoRs со своей командой
Если ваша команда хочет внедрить Зоны ответственности, вот несколько пунктов действий для начала работы:
Разделите работу
Разделите работу вашей команды на проекты и, при необходимости, разделите эти проекты на зоны ответственности. Кто над какими частями работает? Кто должен быть ответственным?
Определите, кто обладает полномочиями
Проведите беседу о том, что значит передать полномочия по принятию решений по AoR тому, кому они поручены. Руководителям следует побудить себя отказаться от полномочий в пользу предоставления командам возможности принимать правильные решения, поощрения эффективности и инноваций и признания того, что некоторые ошибки неизбежно будут сделаны.
Если выяснится, что в какой-то области действует несколько человек, начните разговор о том, кто должен взять на себя инициативу. Поймите, что это более прагматичный подход и не означает, что один человек лучше справляется с задачей.
Сделайте свои оценки общеизвестными
Разместите эти зоны ответственности в каком-либо документе, доступном всем членам команды. По мере продвижения к минимальному жизнеспособному продукту вашей команды AoRs, общая папка Google Docs может быть достаточно хорошей. Кроме того, убедитесь, что это чья-то зона ответственности — следить за тем, чтобы все превращалось в задокументированный AoR.
Выберите измерения для своих целей
Договоритесь о том, как вы будете оценивать успешность выполнения АоР каждого сотрудника, и определите сроки оценки его работы в сравнении с поставленными целями. Убедитесь в том, что каждый сотрудник имеет право голоса в том, как будут оцениваться его AoR.
Обдумайте свои результаты
В конце временной шкалы, после сравнения целей и результатов, подумайте об ОР каждого человека и поищите способы их уточнения и улучшения. Обсудите, какие проекты предыдущего периода могли бы стать шаблонами для будущих проектов.
Промыть, повторить
Найдите задачи, которыми сейчас пренебрегают, и создайте новые зоны ответственности. Даже если сейчас никто не может взять на себя эти обязанности, это может быть полезным способом расширить возможности следующего сотрудника, дав ему обязанности, которые он будет выполнять, как только войдет в дверь.