Как и во многих других американских компаниях, организация рабочих процессов в Amazon построена на базовых принципах, главная цель которых — помочь сотрудникам принимать правильные решения, исходя из ценностей компании.
Мы поговорили с продакт-менеджером Amazon, который рассказал о том, какими принципами руководствуется компания, как они помогают им выполнять задачи и какие процессы проходит команда при разработке нового продукта.
Ниже мы оставили ссылку на видео с полным интервью.
Миссия, видение и принципы Amazon
На мой взгляд, миссия Amazon — стать самой клиентоориентированной компанией в мире.Все продукты, над которыми работает корпорация, разрабатываются с целью сначала сделать продукт для клиента, а затем увеличить его продажи.
Есть 14 принципов, по которым живет компания, и они используются во всех рабочих процессах.
Эти принципы довольно базовые, в них нет ничего особенного.
Их используют при запуске нового продукта, во время интервью или при отзыве коллеге.
Их не заставляют заучивать, но когда ты работаешь в компании, хочешь ты того или нет, ты начинаешь следовать этим принципам.
Многие из них противоречат друг другу.
Например, «Думай масштабно» и «Предвзятость ради действия».
Один говорит: «Думай масштабно», другой говорит: «Действуй, а не планируй».
На самом деле существует множество таких принципов, которые противоречат друг другу.
Но в этом вся суть.
Если бы сотрудники были одержимы принципом «Думай масштабно», то все бы растягивали сроки.
И если бы они придерживались только «Предвзятости ради действия», они бы быстро завершали небольшие проекты и не думали о больших.
Многие говорят, что культура Amazon более требовательна.
Люди приходят сюда работать, учиться и развиваться.
А когда им надоедает, они идут в Microsoft. Это связано с тем, что Amazon — более динамичная и быстрорастущая компания.
Мы стараемся развиваться в разных направлениях.
Но бизнес-модель Boeing и Microsoft не менялась уже много лет. То же самое и с Google: их основным источником дохода остается поисковая система.
Amazon поощряет постоянное генерирование новых идей.
В процессе разработки всегда много проектов.
Когда работа над одним продуктом заканчивается, все сразу переключаются на другой.
И при этом перед каждым проектом внутри подразделений всегда ставятся высокие цели.
Процесс разработки продукта
Прежде чем ставить задачу, первое, что вам следует сделать, — это проверить свою гипотезу.Для этой цели используется MVP или MLP. На основе этих концепций составляется большой документ, который затем просматривается всей командой.
В документе должны быть освещены две вещи: Как проект решит проблему клиента? В документе отведена 1 страница, чтобы кратко объяснить идею и передать ее ценность.
Какие вопросы могут задать потребители о продукте? И технические вопросы: как будем монетизировать? Где купить технические устройства? Кто будет подрядчиком? Все в документе должно быть описано в формате вопросов и ответов.
Если мы понимаем, что идея всем понравилась, она уходит в разработку.
Менеджер по продукту составляет список требований, разбивая их на этапы Agile-релиза.
Все организовано именно так, чтобы шаг за шагом протестировать что-то одно и получить обратную связь.
Самое главное в команде – не ждать указаний.
Если вы пришли к своему менеджеру с проблемой, значит, решение у вас уже должно быть.
А менеджер может только дать обратную связь – нашли вы хорошее решение или нет. В команде всегда есть график дней, когда что будет выполнено.
Каждую неделю сотрудники собираются для обсуждения задач.
Выводим их на дашборд со статусами – зеленый, желтый и красный.
Зеленый означает, что все в порядке и никакого внимания к задаче не требуется.
Желтый – что-то пошло не так, но мы знаем, как это исправить.
Например, проект планировалось завершить к 1 мая, но возникла проблема, которую мы постараемся решить к 1 мая.
И красный — что-то пошло не так, и мы пока не знаем, как уложиться в срок.
После этого каждый разработчик показывает демо-версии проделанной работы.
Во время таких встреч у менеджера по продукту есть возможность дать обратную связь и изменить траекторию выполнения задачи.
Для других — это возможность попросить совета у коллег, если неясно, как решить одну из проблем.
Еженедельные отчеты команды поддерживают культуру Agile, где каждый пытается выпустить что-то вовремя, а не тянуть с этим целый год. Когда проект готов, продакт-менеджер утверждает его и отправляет на следующий этап — тестирование.
В компании есть внутренние тестировщики, которые проверяют, не сломается ли функция, и группа бета-тестеров, которые, в свою очередь, дают свои отзывы.
После их испытаний через пару дней разработка выйдет в свет. И на этом работа над задачей заканчивается.
Организация рабочих процессов в компании
Scrum — это метод расстановки приоритетов задач на ближайшие 2-3 недели — в спринте.Спринт — это краткосрочный забег, в котором вы говорите: «Хорошо, следующие две недели мы выполним эти 10 задач.
И мы будем работать только над ними и ничем больше».
В этом есть свои плюсы и минусы.
С одной стороны, вы не отвлекаетесь на другие задачи.
Но нам приходится постоянно вносить дополнения, а их за спринт собирается довольно много.
В программировании не бывает такого, чтобы вы просто садились и начинали писать код. Сначала продакт-менеджер собирает все требования и описывает функции нового продукта.
Дальше все переходит в дизайн.
Программисты садятся и описывают, что им нужно будет сделать исходя из требований, например, интегрироваться с системой, создать некий фреймворк и т. д. Третий этап — это код в работе, где сотрудник уже садится и начинает писать код. Потом тестирование.
И последний этап – освобождение.
А Канбан — это методология, в которой вы устанавливаете ограничения для каждого этапа.
В группе «требования» не может быть более 3-х функций.
Пока я не перенесу часть требований в дизайн, я не могу добавлять новые задачи.
То есть поток задач регулируется.
Если у вас больше разработчиков, вы можете расширить задачи.
Плюсы методики в том, что она гибкая.
Минус — расстановка приоритетов может постоянно меняться, в отличие от Scrum. В любой момент вы можете включить задачу, которой раньше не было.
Оба подхода относятся к методологии Agile. Смысл его в том, что вы постоянно разбиваете большой релиз на мелкие части и выпускаете их как можно чаще, чтобы не делать того, что пользователю не нужно.
В Scrum мы оцениваем каждую задачу в баллах.
Их ничем нельзя измерить, это скорее относительная величина.
Например, задача на 4 балла выше задачи с оценкой 2. Такие баллы позволяют увидеть, насколько разработчик выполнил свою задачу.
В Канбане сложнее.
Другое наше правило — брать на себя только 3 задачи.
Если в команде 10 разработчиков, то над этими задачами работают все, никто не может взять на себя новую.
Потому что если каждый разработчик возьмет на себя одну задачу, на разработку которой уйдет 2 месяца, то релизов в месяц будет соответственно всего 2. Именно поэтому накладываются ограничения минимум на 3 задачи, над каждой из которых работают 3 разработчика.
Более того, если кого-то выпускают, то он не может взяться за новый проект. Он должен помочь своим коллегам выполнить оставшиеся задачи, поставленные на спринт. И только после выхода проекта можно браться за новые задачи.
Теги: #Карьера в ИТ-индустрии #ИТ-компании #ИТ-компании #amazon #Amazon Web Services #корпоративная культура #постановка целей #работа в команде
-
Railsclub 2017. Материалы
19 Oct, 24 -
Какие Решения Для Iiot Есть У «Ростелекома»?
19 Oct, 24
