Командная работа и планирование целей в Amazon

Автор: Руслан Гафаров

Amazon нельзя назвать полностью горизонтальной компанией. Да, в сравнении с компаниями, которые появились в 60-80-х годах, у Амазон более свободная структура управления. Но если сравнивать их с Facebook и другими молодыми командами, то самый большой интернет-магазин мира располагается где-то посередине между иерархичными и горизонтальными структурами.

Состав команды

Размер одной команды в Amazon в среднем 10-15 человек.

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

Вся команда сидит в одном офисе, так у них есть возможность видеть, кто и чем занимается, на какой стадии решения задачи находится. Есть возможность работать удаленно, но большинство предпочитают офисную работу.

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

С точки зрения профессионального общения в Amazon царит инженерный подход, здесь доминируют инженеры. Им важно, чтобы специалисты на других ролях разговаривали с ними на одном языке, чтобы новички показывали, что хотят разобраться в теме, прикладывали усилия. Когда приходит новый человек к нему относятся с посылом: «Покажи, что ты умеешь. Если ничего не умеешь, покажи, чему хочешь научиться и через полгода покажи результат».

Здесь полезно общаться с тимлидами и программистами более высокого уровня, которые делают важную часть продукта. Это помогает быть в фокусе и лучше понимать задачи.

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

Каждая команда может использовать для себя те инструменты, которые для нее удобны. Главное, чтобы они прошли проверку отдела безопасности, потому что клиенты, особенно в Amazon Web Services, очень требовательны к безопасности. Например, многие используют Skype, а вот Slack не прошел проверку по безопасности.

Как я рассказывал в предыдущей статье об Амазон, здесь все стараются сделать сами. Например, есть внутренняя, но необязательная к использованию, платформа для общения между командами. Пока она сыровата, но сотрудники пользуются ею, потому что хотят дать фидбэк, который поможет развить проект. Если захотят, они могут перейти на другую площадку.

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

Постановка целей

Постановка целей компании и команд внутри нее в Амазон, – это взаимный процесс. Руководители компании, совет директоров утверждают план на следующий год. Они обсуждают над какими проектами будут работать, а какие могут отложить.

В это же время проходит похожий процесс внутри команд. Каждый участник заполняет документ «Что я хочу сделать в следующем году», и предлагает свои идеи для разработки. Во многих подразделениях сидят люди с горящими глазами, которые только и ждут, чтобы их спросили: «Что будем делать?». Такие предложения проходят несколько фильтров и попадают к вице-президентам, которые согласовывают идеи и утверждают или отклоняют их, а потом возвращают командам по принципу: «Сами придумали – сами делаем».

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

Амазон живет по документам

Здесь почти не делают презентации. Для того, чтобы прислать кому-то презентацию нужна весомая причина. Их используют, когда нужно что-то показать пользователям. Но для внутренних задач компания применяет документы в разных форматах: пресс-релиз, работа над ошибками и т.д.

Например, пресс-релиз пишут даже тогда, когда хотят показать новую идею, еще до работы над проектом. Менеджеры компании говорят: «Опиши это так, будто уже показываешь результат пользователям на пресс-конференции».

Центрального хранилища документов, которое автоматически собирает все материалы, в корпорации нет. Поэтому нет возможности посмотреть все документы, которая создала команда за определенный период времени. Но команда может самостоятельно вручную загружать доки во внутреннюю систему типа Википедии. Там публикуют все, что описывает как работает система, материалы, которые получили согласование, и те, которые не пошли в продакшн, но их изучение будет полезным по мнению сотрудников.

Работа над ошибками

Один из механизмов, который придумали Джефф Безос и руководство компании – это работа над ошибками. После любого проекта, который признан неприбыльным, провальным, люди, отвечающие за этот проект, заполняют специальный документ – Correction of errors. Ошибкой считают даже те события, которые были незаметны для пользователей, но через несколько итераций могли бы повлиять на них. При любом явном промахе в Amazon заполняют Correction.

У этого документа есть определенный формат, который помогает разобраться, что произошло и найти корневую причину ошибки.

Первый вопрос: «Почему это случилось?»

Второй вопрос: «Еще раз подумайте и ответьте на первый вопрос»

Вопрос повторяют 5 раз, чтобы сотрудник не просто написал отмазку, а действительно задумался и выяснил реальную причину проблемы.

Работа над ошибками – это процесс, который говорит человеку: если что-то случится, то ты будешь долго и упорно работать над тем, чтобы это исправить, просто так не забудут.

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

Обычно такие отчеты пишут тимлиды команд. Но они могут привлекать любого участника по своему усмотрению. Например, крутой инженер, который может написать любой отчет без подсказок и помощи, распределяет написание разных частей документа по коллегам, чтобы они тоже научились это делать. Иногда работу над ошибками дают заполнить Junior инженерам, которые пока вообще мало что умеют. Так развивают чувство собственности и ответственности, чтобы когда кого-то из сотрудников захотят повысить, у них уже были навыки, необх��димые для новой должности.

Работу над ошибками проверяют коллеги более высокого уровня.

Все самые свежие инсайты мы публикуем в телеграм-канале t-do.ru/maliktrip и на моей личной странице в Инстаграм.

ИсточникАвтор: Руслан Гафаров