Чувствуй и реагируй. Как создавать продукты, нужные людям именно сейчас - Джош Сейден Страница 41

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

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

КЛЮЧЕВЫЕ МОМЕНТЫ ПОДХОДА «ПОЧУВСТВОВАТЬ И ОТРЕАГИРОВАТЬ» ДЛЯ МЕНЕДЖЕРОВ

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

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

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

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

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

Глава 7

Непрерывное все

Делайте меньше, но чаще

AutoTrader UK является крупнейшим рекламным сайтом с объявлениями о продаже автотранспортных средств в Великобритании. Компания, основанная в 1977 году как печатное издание, запустила свой первый веб-сайт в 1996 году. А с июня 2013 года она полностью перешла на цифровой формат, закрыв свой печатный бизнес. Как сообщает компания, теперь AutoTrader UK контролирует более 80 % доли рынка[72]. Перед переходом компании на цифровой формат группа разработчиков создавала обновления веб-сайта раз или два в год. Когда цифровой сервис стал единственной целью команды, она удвоила этот темп до квартального. Как и следовало ожидать, каждый раз, когда команда выпускала новые функции продукта, покупатели отвечали обратной связью. Но не всегда эта обратная связь была положительной.

Менеджеры могли бы легко разочароваться от негативных отзывов или списать их со счетов, потому что они противоречили их установкам. Вместо этого они воспринимали такие отклики как возможность чему-нибудь научиться: «Каждый раз, когда мы запускаем новое обновление, мы видим, где мы были правы, а где нет. И чем чаще мы будем применять новые идеи, тем быстрее мы сможем обучаться и вносить корректировки». Они начали задаваться вопросом: «Почему же мы учимся только четыре раза в год? Почему бы не делать это четыре раза в неделю?»

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

Люди, изучающие процессы, восхищаются идеей потока – как вы создаете его, как поддерживаете, как достигаете экономических преимуществ от его продвижения. Ключевым моментом является то, что эффективный поток работы от организации к рынку, если все делается верно, создает множество преимуществ. AutoTrader UK решила оптимизировать поток обучения, получая более быструю обратную связь. Иначе говоря, компания хотела запустить и поддерживать двусторонний разговор со своим рынком.

Есть еще одно преимущество в увеличении темпа: снижение потерь, связанных с задержкой, – если функция окажется ценной для покупателей, внедрив ее на рынок раньше, вы получите больше пользы. И наоборот, чем дольше вы медлите с выпуском, тем меньше ценности вы сможете предоставить. Та ценность, которую вы упускаете, является потерями, связанными с задержкой.

Таким образом, существуют веские экономические причины для оптимизации вашей работы в поставке новых идей на рынок. Это относится ко всем идеям – и к воплощенным в программном обеспечении (например, новая функция на сайте), и к тем, которые никак не относятся к нему, например изменение цен или новые маркетинговые ходы. В современных компаниях при реализации многих из этих идей полагаются на программное обеспечение, но, как вы узнаете в данной главе, эти процессы выходят далеко за рамки простой оптимизации команды разработчиков программного обеспечения. Если мы нацелены создать эффективный поток, мы должны заглянуть за пределы функционирования технологических команд и рассмотреть всю организационную систему.

Рассмотрение инфраструктуры потока

Для начала давайте поговорим о некоторых технологических приемах, которые современные команды применяют для создания инфраструктуры потока. Мы будем опираться на эти знания, чтобы оценить, как бизнес-команды работают в этой новой среде «непрерывного всего».

ОЦЕНКА ДВИЖЕНИЯ DEVOPS: ТЕХНИЧЕСКАЯ ОСНОВА ПОТОКА

Одной из интересных вещей, появившихся в мире технологий за последние десять лет, является направление DevOps (акроним от англ. «development» – разработка и «operations» – операции) – набор идей и процессов, которые позволяют командам выпускать надежное программное обеспечение быстро и с меньшими рисками, чем прежде. DevOps – технический и инфраструктурный уровень того, о чем мы говорили на протяжении всей книги, поэтому стоит потратить несколько минут на основные концепции этого направления и оценку влияния, которое оно оказывает на организации.

Для большинства людей за пределами технологической индустрии «программные операции» являются невидимой и неясной функцией. Однако за операциями стоят люди, которые создают и поддерживают операционную среду, в которой работают программные сервисы и продукты. Они настраивают серверы, сети и базы данных, устанавливают и поддерживают программное обеспечение, которое обеспечивает работоспособность всей инфраструктуры, справляется с перебоями, и (что наиболее важно для обсуждения) задействуют новые версии для программного обеспечения, создаваемого командами по разработке продуктов.

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

Представьте, что вы являетесь тестировщиком обеспечения качества. Вы привыкли получать добротное новое программное обеспечение примерно каждый месяц. Это означает, что у вас есть много времени на проверку, прежде чем прибудет новое программное обеспечение. А теперь представьте, под каким давлением вы окажетесь, когда разработчики начнут поставлять вам программное обеспечение каждые две недели или каждый день, а может, и много раз за день. Единственный способ