Как переориентировать процесс разработки: Релизы или Обучение

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

«Что вы выпустили в прошлом квартале?»

«Когда это планируете выпустить?»

У глагола «выпускать» (ship) долгая история в мире разработки программного обеспечения и, еще до этого, в физическом мире. В общем понимании он означал «транспортировку чего-либо на судне», а в мире ПО – «записать программу на ленту/CD и отправить потребителю». Сейчас это просто «релиз» и, как правило, не всегда это конечная форма продукта.

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

Вот вам неполный список проблем, с которыми вы можете столкнуться, если все у вас нацелено на релизы:

• Команды реализуют плохие или не оказывающие влияние функции только для того, что бы организовать выпуск.
• Команда А выпускает больше команды Б и, таким образом, кажется более компетентной, даже если у команды Б задачи более сложные, а процессы более строгие.
• Команды делают вещи, которые ничему компанию не учат.
• Команды манипулируют или очень вольно интерпретируют данные, чтобы оправдать выпуск.
• Командам не дают достаточного времени на лучшую работу из-за постоянных требований выпустить релиз как можно быстрее
• Членам команды дают (или не дают) повышения, похвалы или другие поощрения в связи с тем, как часто (или редко) выпускаются продукты.

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

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

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

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

[notice]

Сентябрь

Запущены рекомендации фильмов

Нанято 2 инженера.

Исправлено 30 багов.

Выпустили бету с совместными фильтрами.

Составили продуктовый план для международного запуска.

[/notice]

Такие отчеты в больших компаниях могут принимать форму OKR (Objectives & Key Results) или KPI (Key Performance Indicators).

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

Список, показанный выше, это, в лучшем случае, техническая инвентаризация, а в худшем просто завеса вокруг того, насколько мы мало понимаем. Другими словами, он может заставить вас думать, что все движется вперед (хорошо!). За счет того, что производимая разница почти не ощущается (плохо!). Что если использования таких типовых отчетов каждую неделю/месяц/квартал, вы будете делать что-то типа такого:

[notice]

Сентябрь

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

Стоимость обучения: Один исследовать, один дизайнер для прототипирования, одна неделя и 2,000 долларов  на исследование.

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

Что необходимо для реализации: Помощь в переводе – мы отдадим это на аутсорс.

Что мы узнали: У нас есть целая закладка в приложении – Театры – которой регулярно пользуется только 1% пользователей. Кроме того у нас есть функция – Друзья — погребенная в меню, и ей регулярно пользуется почти половина пользователей. Мы не уверены в эффекте, но здравой кажется идея поменять закладку Театры на Друзей.

Стоимость обучения: Один ПМ, один день анализа данных.

План реализации: Запустить эксперимент по размещению Друзей вместо Театров и оценить эффект по метрикам.

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

Что мы узнали: Сборка нашего проекта занимает как минимум на 30% больше времени, чем следовало бы, из-за устаревшего процесса со множеством зависимостей. Кроме дополнительного времени, мы теряем инженеров и дизайнеров из-за этого.

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

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

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

[/notice]

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

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

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

«Что минимально мы можем выпустить?» превращается в «Как мы можем узнать Х наиболее быстро?».

«Что мы хотим выпустить в следующем квартале?» в «Что для нас важнее всего узнать о продукте в следующем квартале?».

«Как релизить более часто?» в «Как мы можем ускорить наше обучение?»

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

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