"Что ты выпустил в прошлом квартале?"
"Когда вы это зарелизите?"
"Настоящие художники продают"
Внутри технологических компаний все любят выпускать продукт, ещё бы, это кульминация большого количества креативности и тяжелой работы от дизайнеров, программистов и многих других людей, а когда продукт удаётся, он ещё и оставляет след во вселенной. Неудивительно, что такое количество процессов в технологических компаниях завязано именно на релиз.
Но должно ли так быть? Особенно с учётом того как изменился сам процесс релиза за последние пару десятилетий?
Вот неполный список проблем которые могут возникнуть когда всё ориентированно вокруг выпуска продукта:
- Команда выпускает ограниченные или незначительные вещи с целью сказать, что они что-то зарелизили
- Команда A релизит больше чем Команда Б и следовательно выглядит более компетентной несмотря на то, что задачи команды Б сложнее.
- Команды выпускают вещи которые ничему не учат их компанию
- Команда манипулирует (или очень вольно анализирует) данными чтобы оправдать необходимость запуска
- Команда не получает возможностей чтобы делать работу хорошо из-за постоянных требований срочного релиза
- Члены команды получают (или не получают) повышения, продвижения и похвалы основываясь на том как часто выпускается продут
И сколько бы я не говорил с коллегами из других компаний мы удивлялись с каким количеством схожих проблем сталкиваемся и начали задумываться есть ли более подходящий способ понять что мы движемся вперёд чем регулярные релизы.
Обучение вот то, что приходило в головы чаще всего. Компании которые учатся быстрее с наибольшей вероятностью придут к успеху в долгой игре. Это не оригинальная идея, но пока не видно чтобы большинство внедряли её в свои процессы.
И если это так, то как мы можем переориентировать процесс разработки на обучение?
Провокационный подход может быть в приоритизации открытия чего-то нового как наиболее важного регулярного результата работы инженерных, продуктовых и дизайн команд.
Скажем, вы менеджер, руководитель или кто-то ещё заинтересованный в продукте компании. Вот типичный отчёт о работе который вы привыкли видеть от лидера команды разработки.
Сентябрь
Запустили рекомендации фильмов
Наняли 2-х разработчиков
Нашли 30 багов
Выпустили групповые фильтры в бету
Набросали черновик плана по интернализации
Описанные в более структурированном виде такие отчёты могут принимать форму OKRs (Objectives & Key Results) или KPIs (Key Performance Indicators). И несмотря на то, что такие отчёты полезны для того чтобы показывать, что команда не сидит сложа руки, они не ведут к пониманию, что всё это даст компании.
Что заставило команду запустить рекомендации фильмов и что это значит для бизнеса? Что дадут два дополнительных разработчика? На что повлияло исправление багов? Что мы надеемся узнать от выпуска фильтров в бету и как мы узнаем, что должны их запускать на всех пользователей? Что мы узнали о интернализации в разрезе того как она увеличит наш бизнес или насколько сложно будет её запустить?
Список наподобие того, что сверху это вуаль которая маскирует как мало знаний на самом деле мы получаем. Другими словами, может казаться, что вы движетесь вперёд (что хорошо) за счёт игнорирования того, что вы практически не приносите изменений (что плохо). Что если вместо составления такого списка каждую неделю, месяц или квартал вы бы составляли что-то вроде этого:
Сентябрь
Что мы узнали: убирание шагов из нашего онбординга не уменьшает растерянность пользователей. Вместо этого поправили текст так чтобы пользователи чувствовали, что они прогрессируют и получили больший доход (ссылка на детали)
Стоимость изучения: Один исследователь, один фронтендер для прототипирования, неделя календарного времени и $2000 на оплату участникам исследования
Дальнейший план: вывести новый текст на продакшен в течении месяца
Что нужно для продолжения: Некоторая помощь в переводах. Мы это зааутсорсим.
Что мы узнали: У нас в приложении есть целая вкладка — Театры, которая используется только одним процентом пользователей. А ещё, у нас есть дополнительный функционал — Друзья, спрятанный в под-меню и который регулярно используется почти половиной всех пользователей. Мы не уверены, что выйдет если мы заменим Театры на Друзей, но кажется это нужно сделать.
Стоимость изучения: Один ПМ, один день копания в данных.
Дальнейший план: Запустить эксперимент по добавлению вкладки Друзья на место вкладки с Театрами и посмотреть как это повлияет на цифры.
Что нужно для продолжения: У нас в группе нет выделенного аналитика данных и было бы круто его нанять, но пока не наняли кто-то из нас может выделять день в неделю на работу с данными.
Что мы узнали: Наши проекты занимают как минимум на 30% больше времени чем должны из-за устаревшего процесса сборки у которого слишком много зависимостей. В дополнении к тому что мы тратим деньги из-за затягивания проектов мы ещё и теряем людей которые уходят из-за фрустрации.
Стоимость изучения: мы заплатили цену медленной разработкой и выгоранием людей в течении как минимум пары лет.
Дальнейший план: мы только что выделили две недели времени разработки чтобы разобраться с проблемами и оценить, чего нам будет стоить их починка. Мы надеемся выделить приоритетный список проблем которые будет легче всего сделать с наибольшим результатом и бросить на них все силы.
Что нужно для продолжения: нам нужна поддержка от руководства компании где-то на месяц пока мы это всё чиним. Это означает, что мы тормозим текущую разработку и нам не нужно будет объяснять почему. Это важная работа в которой участвует вся компания.
Что мы узнали это ключевая ценность и то, что потенциально интересно многим людям в компании. Стоимость изучения это момент где можно оптимизировать и понять эффективность. Трата года разработки несёт за собой значительно большие риски чем запуск небольшого эффективного теста. Дальнейший план позволяет людям узнать результат того, что мы узнали и как это влияет на движение вперёд. И, наконец, что нужно для продолжения показывает, что менеджер, руководитель или любой человек за пределами команды разработки могут сделать чтобы помочь.
Конечно это грубый набросок и он требует немало итераций и доработок, но мне нравится, что хотя у нас достаточно легитимных и нелегетимных извинений для отложенного релиза, у нас нет ни одного повода не учиться. Другими словами, команда может потратить целый квартал или больше ничего не выпуская даже если они делают всё правильно. Однако, если они не узнают ничего нового на регулярной основе они с большой вероятностью делают-то что-то не так.
А ещё мне нравится как переориентация на обучение заставляет людей думать совершенно новым образом:
"Какой минимальный функционал нужен для релиза?" становится "Как мы можем узнать X наиболее быстро?"
"Что мы хотим выпустить в следующем квартале?" становится "Что наиболее важно узнать о нашем продукте в следующем квартале?"
"Как нам чаще релизить?" становится "Как нам ускорить темп нашего обучения?"
Это, конечно, не означает, что вы должны перестать задавать вопросы о релизах, но запуск продукта становится просто другим путём к тому чтобы что-то узнать наравне с исследованиями, прототипированием и большим количеством других методов. Релиз это всё ещё то к чему вы хотите прийти в конечном итоге, но это больше побочный продукт того методичного экспериментирования и исследования которое проводится вами и всеми командами в компании.
Некоторые из тех компаний которые уже сейчас быстро обучаются и эволюционируют однозначно ввели в процессы какую-то часть этих идей, будь то неформально или случайно. И если вы читаете и думаете про себя "мы уже всё это делаем!", то здорово. Если, однако, такое смещение приоритетов, звучит как что-то свежее и интересное — поговорите о ней со своей командой и подумайте, что вам нужно сделать чтобы попробовать это на паре проектов.