Ваша команда оптимизирована под проблему, которой нет

Примерно год назад мы оказались в ситуации, что код теперь пишется быстрее, чем когда-либо до этого. А фичи стали выходить быстрее? Гарвард посчитал на данных Jellyfish по 718 компаниям: с AI-агентами кода стало на 30% больше, а закрытых задач — всего на 12%. В ресёрче это связывают с этапами вокруг кода: на сам код инженеры тратят 30–40% времени, но ревью PR стало занимать почти в полтора раза дольше. Так было тогда, возможно, сейчас побыстрее.

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

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

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

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

Сначала ускорились разработчики. Следом - дизайнеры: интерфейс теперь собирается недели, а не за сколько-то спринтов. Потом аналитики: ad-hoc запрос или мини-ресёрч, который раньше стоил дни, сейчас стоит часы. Каждый "цех" стал быстрее на своём участке конвейера.

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

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

При этом скорость доставки результата пользователю растёт в разы медленнее, чем объём кода. И вроде бы все ускорились, но вся система по прежнему, ну плюс-минус, та же что была. Всё потому что..

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

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

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

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

Кстати, странно, что еще не появились AGIle коучи (простите, не удержался от каламбура).

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

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

Теперь, когда порог входа в инструменты дизайна, аналитики и ресёрчей - снизился, у разработки есть:

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

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

Единая воронка гипотез. Гипотезу может завести любой. Шаблон один для всех: проблема, данные, ожидаемый эффект, стоимость, как проверим. Ставки разбираются на общем ревью по одним критериям, и вес аргумента не зависит от роли. Последнее слово при разногласии остаётся за продактом — но с объяснением, почему мы действуем так, а не иначе.

Прежде всего, да, я понимаю, что и тема огромная, и топ-4 совета тут очень сложно назвать, так как много и частных кейсов, и сложных моментов. Приходите в телегу (@stvlpotapov) или в комментарии, давайте пообсуждаем!

Если бы мы с командой сейчас находились в точке, где всё работает по принципу "делаем только то, что продакт принёс", вот какие советы я б себе дал:

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

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

2. Выделить разработчикам время на discovery. Фиксированную долю, а не «если останется».

4. Через квартал стоит замерить пульс. Сколько гипотез появилось, сколько из них проверено, как изменился путь от идеи до релиза, какая доля ставок пришла не от продакта.

Такие дела

Что думаете?