История внедрения разработки и перехода организации от водопада к гибкой и бережливой

Начало конца?

Был конец 2018 года, и инженеры уходили толпами. Мы потеряли семь инженеров за несколько месяцев из-за одного проекта. Наш оборот достиг 38%.

Это было началом массового исхода, и на горизонте стоял организационный крах.

Что происходило?

Предполагалось, что мы будем на твердой дороге. Продукт провел двухнедельные спринты и провел все церемонии схватки перед T. Мы провели 1: 1 со всеми инженерами. По любым стандартам организации у нас все должно было быть хорошо.

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

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

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

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

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

Достаточно было достаточно. Скорость ухода была неустойчивой и еще не закончилась. Как технический менеджер, близкий к команде, я знал, что несколько разработчиков активно искали другую работу.

Нам пришлось внести изменения.

Кто мы? Продукт или разработка?

Организационная структура компании практически не изменилась с момента ее основания. Хотя компания увеличилась почти на 600%, ее процессы и структуры не соответствовали требованиям. Структура была почти такой же, как и у его стартапов.

«Инженерного» отдела не было. Это был просто «Продукт», в который входили все менеджеры по продукту, дизайнеры и инженеры в рамках единой организационной единицы. У инженеров не было отдельного бюджета, OKR, KPI или даже дорожной карты.

В результате Продукт был единственным авторитетом в отношении всего.

Это привело к нескольким проблемам

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

В результате система накопила значительный технический долг за годы, что сделало разработку даже таких элементарных вещей, как изменение цвета кнопки на всех страницах, колоссальным усилием. У нас была шутка над этим - мы назвали это «несущим CSS», потому что мы каким-то образом знали, что существует критическая бизнес-логика, зависящая от цвета этой кнопки.

Это затрудняло выделение ресурсов и планирование. Мы разделили взаимозаменяемый бюджет с Product, а это означало, что, когда инженер уходил, это распределение часто исчезало, переходя либо в дизайн, либо в продукт, или исчезало сразу.

Из-за этого было трудно повышать зарплату людям. Наши разработчики столкнулись с существенной разницей в оплате труда из-за неэффективной практики найма на период бурного роста компании. Многие из них были почти на 30–50% ниже рыночных, некоторые - на 50% выше рыночных. В некоторых случаях разница в зарплате у людей одного уровня составляла до 60%!

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

Отсутствие голоса

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

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

Частично проблема заключалась в уровне их навыков. Начинающие менеджеры по продуктам в конечном итоге скармливали инженерам информацию или проекты без единого видения конечной цели. В результате вещи были построены как отдельные элементы или как незначительные дополнения к существующим системам. Когда пришло время создать pièce de résistance, связав их вместе в синергетическое целое, это было невозможно, потому что они не были созданы для интеграции или отделения от других частей системы.

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

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

Инженеры нуждались в четком голосе.

Как мы туда попали?

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

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

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

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

Я пришел подготовленным. У меня было все, от желаемых организационных диаграмм до карьерных лестниц и бюджетов. Я говорил о структуре команды, процессах разработки со всеми, кто меня слушал.

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

В конце концов, мы заручились поддержкой заинтересованных сторон и сформировали команду PED - продукт, инжиниринг и дизайн как отдельные отделы, работающие совместно. Я стал техническим директором, отвечающим за недавно сформированный инженерный отдел и всех его разработчиков.

Это означало, что у нас был наш голос, наша автономия и наш бюджет.

Первая остановка: справедливая компенсация

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

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

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

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

В некоторых случаях разговоры превращались в планы повышения производительности. Некоторые сотрудники улучшились и преуспели. Другие этого не сделали и расстались с нами. Я позаботился о том, чтобы часть зарплаты уходящих сотрудников была реинвестирована обратно в текущую команду, что позволило мне повысить уровень сотрудников, которые работают хорошо или улучшаются.

Имена дают власть - сила приходит с ответственностью

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

Номера для всех

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

Нам повезло. К концу 2018 года был опубликован отчет Состояние DevOps за 2018 год, в котором был представлен простой в использовании набор показателей, которые мы могли бы использовать в качестве основы для нашей культуры измерения. Как заядлый поклонник книги Ускорение, это было отличным напоминанием о существовании набора принципов инженерного успеха.

Мы взяли четыре основных:

  • Время цикла.
  • Среднее время восстановления.
  • Частота развертывания.
  • Измените частоту отказов.

Раньше мы не измеряли ничего из этого. Я посмотрел на некоторые инструменты, чтобы получить их, но они были сложными, не совсем то, что нам было нужно, или были дорогими. У нас просто не было ресурсов для их изучения. Кроме того, внезапное увеличение затрат на сотни или тысячи долларов было не самой лучшей идеей прямо в момент создания инженерного отдела. Сначала нам нужно было проявить себя.

Мы использовали подход «сделай сам». Я немедленно написал bash-скрипт, который взял наши данные о фиксации Git и рассчитал по ним частоту развертывания. Я также написал второй сценарий, который взял те же данные Git и оценил частоту отказов изменений, ища такие слова, как «исправление», и сравнивая их с частотой развертывания.

Я также реализовал процесс ручного документирования каждого инцидента или сбоя, включая сроки, когда он начался, когда он был обнаружен, когда он был устранен, какова была основная причина и какие действия были предприняты впоследствии. Это было задокументировано в выпуске Github, который был полностью доступен всем инженерам. Благодаря этому у нас было среднее время восстановления - по крайней мере, вручную.

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

Результаты были не очень хорошими

Оглядываясь на данные за 2018 год в качестве ориентира, результат оказался, мягко говоря, неутешительным.

Частота развертывания составляла 0,25 в день. Это означает, что мы развертывали в среднем один раз в четыре дня. Если копнуть глубже в цифры, то часто это были небольшие настройки и исправления ошибок - развертывание функций происходило намного реже.

Наша частота сбоев при изменении составляла 25%, что означало, что каждое четвертое развертывание требовало исправления. Если посмотреть на данные до 2018 года, то в какой-то момент частота отказов при внесении изменений достигла 400%, что означает, что каждое развертывание приводило к четырем исправлениям.

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

Наше время выполнения составило 14 дней - по совпадению, такая же продолжительность, как и у спринта. Думаю, работа всегда занимает отведенное время!

Получение бережливого производства

Принципы DevOps и Lean во многом пересекаются. Основы Post-Agile просто не меняются. Уменьшение размера пакета, создание и управление циклами обратной связи, итерация - это все, что мы могли сделать.

Однако технология не позволяла этого. Если бы я сказал нашей команде: «Мы должны развертывать каждый день», это было бы невозможно без значительного негативного воздействия на нашу производительность.

Наше развертывание заняло почти полчаса. У нас не было постановочной среды. Наши тесты регулярно терпели неудачу по случайным причинам.

Это была проблема курицы и яйца - как нам улучшить наш процесс, улучшить наши технологии, улучшить наш процесс, улучшить наши технологии…?

Начнем с принципов - в первую очередь - небольшие партии

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

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

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

Решение? Создайте возможность.

Функция, помеченная на помощь

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

Это оказалось не так просто, как кажется. За прошедшие годы в системе было задействовано множество техник псевдо-пометки. Некоторые вещи использовали переменные ENV, другие использовали жестко запрограммированные условные проверки и многое другое. У нас даже были столбцы, которые представляли флаги функций для данной таблицы!

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

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

Когда у нас появился уровень сервиса и модель данных, управляющие всеми флагами функций на нашей платформе, расширение ее функциональности с еще большей мощностью стало легким. Мы добавили A / B-тестирование, опции флагов и многое другое!

Поскольку интерфейс был построен в общем виде, мы могли легко заменить его более надежной библиотекой пометок в дальнейшем без проблем.

Развертывание! = Выпуск

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

Неожиданный сюрприз

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

Всегда было напряжение между построением вещей правильно, построением правильных вещей и построением вещей сразу.

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

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

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

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

Небольшие размеры партий = больше партий = больше накладных расходов

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

Почему?

Наши развертывания были болезненными. Потребовалось от 30 до 45 минут полного внимания разработчика, объединения PR, написания примечаний к выпуску и выполнения дымовых тестов.

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

Частота развертываний в этой модели была низкой. Это происходило всего несколько раз в неделю, и каждое развертывание по-прежнему было относительно большим и рискованным.

Нам нужно было сократить накладные расходы на создание пакета / развертывания.

Автоматика на помощь

Я написал инструмент на bash, чтобы автоматизировать этот утомительный процесс, по крайней мере, для некоторых из наших развертываний. Инструмент, который мы назвали Patchy, позволял любому инженеру создать выпуск из единого PR и развернуть его прямо в производственной среде с помощью одной команды.

Например, запуск ./patchy.sh 6486 приведет к развертыванию PR # 6486.

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

Patchy сократил время, необходимое разработчику для развертывания, с 30 минут до одной минуты. Хотя само развертывание заняло примерно 15 минут, разработчик просто запустил его в режиме «выстрелил и забыл».

Результаты были мгновенными. Частота развертывания снизилась с 0,25 в день до в среднем 6,5 в день. В процессе развертывания было задействовано больше разработчиков. Исчезли 15–20 очередей по связям с общественностью. У нас даже были дни, когда мы достигали нулевого PR без снижения нашей производительности или производительности.

Увеличить размер пакета развертывания

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

У нас были «развернутые поезда», в которых инженеры по очереди «исправляли» свои PR. Эти поезда развертывания иногда работали часами - инженер запускал Patchy для своего PR, отправляя деплой автоматически, а как только это было сделано, другой инженер запускал Patchy для своего PR, и так далее и тому подобное. Это привело к потоку изменений, которые, хотя и были хороши на первый взгляд, свидетельствовали о неэффективности.

Я переписал Patchy в сценарий Ruby, добавив возможность указывать несколько PR для развертывания.

Включив в Patchy возможность развертывания нескольких элементов в автоматическом режиме, мы смогли снизить стоимость развертывания нескольких элементов за счет небольшого увеличения размера пакета развертывания.

Результат: снижение частоты развертывания примерно до 3 в день без сопутствующего уменьшения объема изменений. Количество фактически выпущенных товаров нисколько не уменьшилось.

Я внимательно следил за частотой отказов изменений и не заметил никакого увеличения. Люди по-прежнему были осторожны, чтобы не подвергать свои релизы риску: доверие к своим инженерам окупается!

Patchy V2 просто устранил накладные расходы на развертывание нескольких вещей.

Итерация по метрикам

Примерно в это же время я смог обновить наши возможности отслеживания. JIRA выпустила новые типы проектов (спасибо, Atlassian!), которые позволили мне автоматически устанавливать отметки времени и другие элементы в зависимости от того, когда элементы переходили в определенные статусы. Это позволило мне автоматически рассчитать время цикла, отличая его от времени выполнения заказа.

Я также реализовал автоматический мониторинг времени безотказной работы, используя комбинацию Pingdom и Statuspage. Это позволило нам проводить базовые проверки сервера, которые выполнялись раз в минуту и ​​отправляли нам предупреждение, если наш сайт возвращал какие-либо проблемы.

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

Дело не только в технологиях

Многие люди приравнивают DevOps к технологиям. Когда они слышат «DevOps», они думают о Docker, Kubernetes и т. Д. Некоторые думают о практиках - контейнеризации, оркестровке и т. Д.

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

Одним из главных препятствий на пути перехода к модели DevOps в нашей организации было наше собственное мышление в отношении изменений, владения и ответственности.

Это пришлось изменить.

Двусмысленность и неизвестное

«Ух, требования изменились».

«Изменить» стало плохим словом.

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

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

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

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

Сделать проблему видимой

Иногда нет лучшего способа показать проблему, чем визуально.

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

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

Решение проблемы

Теперь, когда проблема была очевидна, я мог ее решить.

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

Однако короткие сроки выполнения заказа привели к еще большей неоднозначности требований. Я провел серьезное обучение 1: 1 с инженерами, руководителями и менеджерами по продуктам, чтобы преодолеть нежелание работать с меньшими деталями. Я научил их, какие вопросы нужно задавать, какие проблемы они должны искать, и какие решения они могут найти самостоятельно.

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

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

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

Планирование на будущее против планирования на будущее

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

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

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

В среде, где изменения - единственная константа, зачем пытаться создать 12-месячный план развития?

Неудача - это вариант, и чертовски хороший

Все изменения, которые мы внесли в нашу культуру и технологии, принесли огромную пользу - потерпеть неудачу стало дешево.

Снижение стоимости неудач позволило нам использовать возможности, которые ранее могли быть невероятно рискованными или требовали тщательного планирования в прошлом. Неважно, если вы ошиблись, если сбой легко исправить, или если масштаб и влияние ограничены.

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

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

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

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

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

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

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

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

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

Содействие децентрализованному контролю

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

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

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

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

Мы начали с малого

Мы начали с малого. Мы предоставили возможности принятия решений людям, доказавшим свою компетентность. Мы достаточно ограничили объем, чтобы не сбиться с пути и легко оправиться от неверных решений.

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

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

Культура была не для всех

Когда вы определяете культуру, некоторые люди соглашаются, а некоторые - нет.

Это было долгое путешествие. К сожалению, не все последовали за нами в этом путешествии.

Некоторые люди просто не умеют работать с двусмысленностью или явно не хотят такой рабочей среды. Это нормально.

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

Я желаю удачи тем, кто отказался от участия!

Стоило ли?

Все ли эти усилия сработали? Были ли они вообще полезны? Ответ - твердое да!

Организационная культура

Компания использовала инструмент под названием 15Five, чтобы проводить еженедельный опрос команды, чтобы узнать, как прошла их неделя. Я добавил дополнительные вопросы из опроса по организационной культуре Accelerate Westrum в 15Five, чтобы оценить результаты команды инженеров.

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

По мере того как мы пережили культурный сдвиг, результаты в среднем упали с 3,1 до 4,3. Это был огромный скачок, который означал, что мы на правильном пути.

Удержание

Наши показатели удержания также значительно улучшились. В том году уволились только трое разработчиков - двое по личным причинам и один по соображениям производительности.

Люди больше не уходили из-за нашей компании.

Доставка

Наша доставка значительно улучшилась как по скорости, так и по качеству.

Мы работали по всем показателям в три-пять раз лучше, чем когда-либо раньше.

Наш цикл сократился до трех дней. Уровень отказов при внесении изменений остался ниже 2%. Наша частота развертывания колебалась около 3,5 развертываний в день после внедрения инструментов пакетного развертывания. Мы ввели объем изменений в качестве счетчика и постоянно выпускали около 120–180 пул-реквестов в месяц.

Мы выпустили множество изменений, которые привели к значительному увеличению удержания, привлечения клиентов и доходов. Бизнес был счастлив - они видели ощутимый прогресс и стабильные результаты.

Технология

Что касается технологий, мы значительно повысили стабильность, производительность, масштабируемость и безопасность наших систем. Мы разработали подсистемы, которые помогли нам развиваться еще быстрее - системы проектирования, библиотеки модульных компонентов, изолированные подсистемы и т. Д.

Обеспечение ценности для бизнеса не в ущерб техническому качеству, а техническое качество не в ущерб доставке ценности для бизнеса. Сработало слаженно.

Это не конец!

Всего за один короткий год мы кардинально изменили принципы работы организации, занимающейся разработкой. Внесенные нами изменения оказались эффективными. Сегодня мы выпускаем обновления несколько раз в день, и в любой момент времени мы проводим несколько экспериментов и тестов.

Более того, то, как мы работаем, привело к улучшению работы всей компании. Компания теперь лучше сотрудничает и более согласована, чем когда-либо. Межведомственное сотрудничество активно развивается, и оно улучшается с каждым днем.

Я очень жду того, что принесет следующий год!