[Из песочницы] Как организована работа в Amazon
Как и во многих других американских компаниях, организация рабочих процессов в Amazon построена на базовых принципах, основная цель которых — помочь сотрудникам принять правильное решение, основываясь на ценностях компании. Мы поговорили с продукт-менеджером в Amazon, который рассказал о том, каким принципам следуют в компании, как они помогают при выполнении задач, и через какие процессы проходит команда при разработке нового продукта. Ниже мы оставили ссылку на видео с полным интервью.
Миссия, видение и принципы Amazon
В моем понимании, миссия Amazon — быть самой клиентоориентированной компанией в мире. Все продукты, над которыми работает корпорация, разрабатываются с целью сначала сделать продукт для клиента, а потом уже увеличить его продажи.
Есть 14 принципов, которыми живет компания, и они используются во всех рабочих процессах. Эти принципы достаточно базовые, в них нет ничего особенного. Ими руководствуются при запуске нового продукта, во время собеседований, или когда даешь обратную связь коллеге. Их не заставляют заучивать, но когда ты работаешь в компании, хочешь-не хочешь начинаешь следовать этим принципам.
Многие из них идут врозь с друг с другом. Например, как Think Big и Bias for Action. Один говорит »Думай глобально», а другой — »Действуй, а не планируй». Таких принципов, конфликтующих друг с другом, на самом деле много. Но в этом и заложен весь смысл. Если бы сотрудники зацикливались на принципе Think Big, то все бы растягивали сроки. А если бы придерживались только Bias for Action — быстро бы выполняли маленькие проекты и не думали о больших.
Многие говорят, что культура Amazon — более требовательная. Люди приходят сюда, чтобы работать, учиться и развиваться. А когда устают, идут в Microsoft.
Это объясняется тем, что Amazon более динамичная, быстро растущая компания. Мы пытаемся расти в разных направлениях. А вот бизнес модель Boeing и Microsoft не меняется в течение многих лет. То же самое и у Google: их основным источником дохода остается поисковая система.
В Amazon же поощряется постоянное генерирование новых идей. В процессе разработки всегда очень много проектов. Когда заканчивается работа над одним продуктом, сразу же все переключаются на другой. И при этом внутри отделов всегда ставятся высокие цели по каждому проекту.
Процесс работы над продуктом
Первое, что ты должен сделать перед постановкой задачи, — протестировать гипотезу. Для этого используется MVP или MLP. На основе этих концепций составляется большой документ, который потом рассматривается всей командой. В документе должны быть выделены две вещи:
Как проект решит вопрос клиентов? В документе отводится 1 страница для того, чтобы лаконично объяснить идею и донести ее ценность.
Какие вопросы могут задать потребители по продукту? И технические вопросы: как будем монетизировать? Где закупать технические приспособления? Кто будет подрядчиком? В документе все должно быть описано в формате вопросов-ответов.
Если мы понимаем, что идея всем понравилась, она уходит в разработку. Продукт-менеджер составляет список требований, разбивая их на стадии релиза по Agile. Все организовано именно так для того, чтобы пошагово тестировать одну вещь и получать фидбэк.
Самое важное в команде — не ждать инструкций. Если ты приходишь к руководителю с какой-то проблемой, то у тебя уже должно быть решение. А менеджеру уже остается только дать обратную связь — хорошее ли решение ты нашел, или нет.
У команды всегда есть составленное расписание по дням, когда что будет завершено. Каждую неделю сотрудники собираются на обсуждение задач. Мы их показываем на дашборде со статусами — зеленый, желтый и красный.
Зеленый означает, что все хорошо, внимания к задаче не требуется. Желтый — что-то пошло не так, но мы знаем, как это исправить. Например, проект планировали закончить к 1 маю, но возникла проблема, которую постараемся решить к 1 маю. И красный — что-то пошло не так, и мы пока не знаем, как уложиться в сроки.
После этого каждый разработчик показывает демки с проделанной работой. Во время таких встреч у продукт-менеджера есть возможность дать фидбек и изменить траекторию выполнения задачи. Для остальных — возможность спросить совета у коллег, если непонятно, как решить одну из проблем. Еженедельные отчеты команд поддерживают культуру Agile, когда все пытаются выпустить что-то к релизу, а не тянут с этим целый год.
Когда проект готов, его одобряет продукт-менеджер и отправляет на следующий этап — тестирование. В компании есть внутренние тестировщики, которые проверяют, не сломается ли фича, и группа бета-тестировщиков, которые в свою очередь дают свой фидбэк. После их тестов, разработка выходит на релиз через пару дней. И на этом заканчивается работа над задачей.
Организация рабочих процессов в компании
Scrum — метод приоритезации задач на следующие 2–3 недели — на спринт.
Спринт — это такой краткосрочной забег, в котором ты говоришь:»Окей, следующие две недели мы сделаем вот эти 10 тасков. И будем работать только над ними и больше ни над чем». В этом есть свои плюсы и минусы. С одной стороны ты не отвлекаешься на другие задачи. Но приходится постоянно вносить дополнения, а их собирается за спринт довольно много.
В программировании нет такого, что ты просто сел и начал писать код. Сначала продукт-менеджер собирает все требования, описывает функции нового продукта. Затем все отправляется в дизайн. Программисты садятся и описывают, что им нужно будет сделать, исходя из требований, например, заинтегрироваться с системой, сделать определенный фреймворк и т.д. Третий этап — код в прогрессе, где сотрудник уже садится и начинает писать код. Затем тестирование. И последний этап — релиз.
И вот Kanban — это методология, в которой ты ставишь лимиты на каждый этап. В группе »требований» не может быть больше 3-х функций. Пока я не перенесу какую-нибудь из требований в дизайн, я не могу добавлять новые задачи.
То есть происходит регуляция потока задач. Если у тебя больше разработчиков, можно расширить задачи. Плюсы методологии в том, что она гибкая. Минус — может постоянно меняться приоритезация в отличие от Scrum. В любой момент можно включить задачу, которой до этого не было.
Оба подхода относятся к методологии Agile. Смысл ее в том, что ты все время разбиваешь большой релиз на маленькие куски и выпускаешь их как можно чаще, чтобы не делать то, что пользователю не нужно.
В Scrum мы каждую задачу оцениваем в поинтах. Их ничем не измеришь, это больше относительная величина. Например, задача на 4 поинта больше задачи, оцениваемой на 2. Такие поинты позволяют посмотреть, на сколько разработчик закрыл свою задачу.
В Kanban это сложнее.
Другое наше правило — брать в работу только 3 задачи. Если в команде 10 разработчиков, то все работают над этими задачами, никто не может взять новую. Потому что если каждый девелопер возьмет по одной задаче, которая займет по времени 2 месяца разработки, то релизов в месяц будет всего 2 соответственно.
Именно поэтому ставятся ограничения на минимум 3 задачи, над каждой из которых работает по 3 разработчика. При этом если кто-то освобождается, то он не может браться за новый проект. Он должен помочь коллегам завершить остальные поставленные на спринт задачи. И только после того, как проект ушел в релиз, можно брать новые таски.
