Сигналы от системы
Crash-driven Discovery
Краши и постмортемы — это четкие сигналы о том, что нужно исправить или переписать. Редко когда постмортем указывает на что-то совершенно новое, но иногда это происходит, если внимательно проанализировать, как пользователи пострадали от краша или как они приспосабливались к нему, пока команда чинила долгоживущую проблему. Определение паттернов в постмортемах — это то, что команды редко делают систематически, поскольку постмортемы приходят спорадически. Не упустите большую картину.
Crash-driven discovery имеет серьёзный недостаток: смещает внимание команды на самые громкие и самые свежие сбои, а не на самые крупные возможности. Кроме того, это максимально запаздывающий индикатор.
Cost
Стоимость в долларах — очевидный сигнал. Облачный счет заменяет отсутствие revenue north star. Но не останавливайтесь на оптимизации запроса в БД или на сокращении трафика между VPC. Посмотрите на P&L бизнес-юнита (если доступен), на контракты с поставщиками команды, на строчки облачного счета — или попросите у кого-то доступ к информации о затратах. Для каждого центра затрат поймите, что выигрывает команда, если «аутсорсит» эту функцию, и что это означает — принять её в зону ответственности команды. Это исследование работает и в обратную сторону: что из текущей зоны ответственности стоит отдать вендору, облачному сервису или другой команде. Ключевой вывод: решение между покупкой и разработкой — это не одноразовое решение. Его можно пересматривать, как меняются масштаб, состав команды, технология и рынки.
Собственные издержки команды
Это другой вид стоимости — часто невидимый, иногда даже для самих участников. Toil есть в каждой команде, и он почти никогда не приоритизируется. Но вы это уже знали. Ловушка: издержки команды — это не издержки пользователей. Устранение первых улучшает unit economics, устранение вторых — пользовательский опыт.
Сигналы от пользователей
Continuous Discovery
Раньше автор утверждал, что привязанные пользователи «не имеют лучшего видения идеального состояния инструментов» и что «чрезмерная опора на пользовательские интервью вредна для управления платформой». Суть: если спросить у людей, что они хотят, они попросят более быстрых лошадей. Это остается правдой, но это не причина не говорить с пользователями. Continuous discovery — это постоянный диалог:
- Разговаривайте с N пользователями в неделю/месяц/квартал. Задавайте вопросы примерно такого содержания:
- Расскажите мне пошагово о недавней задаче, которая включала нашу платформу.
- Какие три главные боли вы испытываете при работе с платформой?
- Что для вас означает решение этих проблем?
- Кто ещё столкнулся с такой проблемой?
- Углубляйтесь в боли. Помните: почти у каждой реальной проблемы уже есть workaround. Если workaround нет — боль не острая.
- Подвергайте сомнению предложенные решения. Поймите, почему они хотят именно эти решения и не ограничены ли они текущим дизайном.
- Документируйте боли. Индексируйте их по частоте упоминаний.
Коротко: пользовательские интервью должны быть сосредоточены на совместном понимании проблемного пространства. Дизайн решений — это совсем другое дело.
Перегруженные use-cases
Это любимый эвристический метод. У некоторых платформ есть любопытное свойство: пользователи используют их для задач, для которых они никогда не были предназначены. Потратьте время на то, чтобы понять, почему пользователи предпочитают вашу платформу альтернативам, даже если она не была для этого спроектирована. Воспринимайте перегруженные use-cases как прототипы, которые ваши пользователи построили для вас. Лакмусовая бумажка для внедрения простая: есть ли эту же проблему у других пользователей?
Partner-to-Prototype
Перегруженные use-cases открываются постфактум. Partner-to-prototype — это то же самое, но организованное намеренно: команда и пользователи вместе прототипируют решение на вашей платформе. Прототип — это не обещание, что фича войдет в платформу, это просто совместное исследование. Лакмусовая бумажка та же: кто ещё из пользователей имеет эту проблему?
Сигналы от организации
OKRs
Еще один очевидный сигнал — списываю для полноты. Если у команды есть OKR (или он спустился сверху), эта работа уже придумана. Поздравляем! К следующему.
Heuristic повторений менеджера
Простой и иногда эффективный метод: если вы слышите от менеджера (или его менеджера, или выше) одну и ту же тему дважды за неделю, за этим скрывается неразрешённая проблема. Хорошая причина вести заметки на 1:1, или читать сгенерированные LLM версии. На мой взгляд, это самый слабый способ придумать работу. Причина: чем выше в иерархии, тем дальше от пользователей и выше риск строить на основе HiPPO (мнения самого высокооплачиваемого человека).
Migration Debris
Любое крупное изменение платформы требует миграции, и те, кто руководил critical migration, знают: adoption имеет толстый хвост — как знаменитая кривая из «Crossing the Chasm». Innovators, early adopters, early & late majority и наконец laggards. Отстающие команды, которые медлят или вообще не переходят на новое предложение — это важный сигнал. Они показывают, почему предложение неполное и какой ещё нужна работа.
Раньше было аргументировано, что внутренние платформы должны обслуживать более широкую аудиторию, чем только median user. Debris миграции указывает на пользователей, которых не обслуживает решение для «медианы».
Сигналы от индустрии
Descriptive Writing Leads to Prescriptive Writing
Идеирование сложно, но это часть работы инженера уровня Staff — придумать свежие идеи, как улучшить существующую систему, и предложить их в prescriptive форме (например, RFC). Любимый способ генерировать идеи — описать существующую систему (коллегам, пользователям, новичкам — выбирайте аудиторию). Напишите design document для системы, которая уже существует, и сравните с state-of-the-art системами, решающими похожую или смежную задачу. Этот акт описания обнажает решения, которые больше не имеют смысла. Это writing-as-thinking в лучшем виде.
Lag Is Your Arbitrage
Есть реальная ценность в том, чтобы быть в курсе трендов индустрии — open-source релизы, блоги других компаний, research papers, доклады конференций. Но есть более острый способ их читать и использовать для придумывания работы. Любой computing домен колеблется между циклами bundling и unbundling. Вычисления и хранилище bundled в data warehouse, потом split в data lakes, теперь bundling снова в lakehouse engines. Переход от monolith к microservices уступает место modular monolith. Внутренние платформы качаются в том же направлении, но с задержкой — идеям нужно время, чтобы пропагандироваться. Эта задержка — не баг, это возможность. Она позволяет импортировать обоснование конвергенции индустрии и доказательства — public postmortems, успешные миграции, comparative benchmarks, abandoned positions конкурентов. Вы получаете доказательства без затрат на их генерирование и пропускаете позиции, которые индустрия уже бросила. Failure case — слишком много задержки: вы не хотите быть в stragglers, отстающих при внедрении тренда.
Какой сигнал когда
Одиннадцать сигналов — слишком много, чтобы действовать одновременно. Ранжируйте их по двум осям: насколько много аргументов сигнал даёт бесплатно и leading он или lagging.
На одном конце сигналы, которые приходят уже аргументированные. Postmortem уже имеет аудиторию и заключение. Cost center уже выражен в долларах. OKR отслеживает работу, которая уже придумана. Это дешевые в реализации сигналы, но они запаздывают в разной степени.
На другом конце сигналы, для которых нужно самому построить аргумент. Lag arbitrage дает самое сильное обоснование и самое слабое положение, потому что доказательства из вне компании. Manager-repetition heuristic дает ноль доказательств, но имеет some standing. Continuous discovery дает боли пользователей, но превратить их в спецификацию — на вас.
Overloaded use-cases посередине, поэтому они фаворит. Сигнал leading, аргумент уже построен и работает в production. Partner-to-prototype покупает те же доказательства дороже — придется строить самим. Migration debris — то же, но на миграцию позже: laggards это lagging signal о только что пройденной миграции и leading для следующей. Descriptive writing не дает ни аргумента ни urgency, но лучше всего шансов заметить решения, которые молча устарели.
Заключительное замечание
Это не проблема нехватки сигналов. Они всегда работают и список выше неполный. Failure mode для engineering-led платформенной команды — не пустой backlog, а backlog собранный из самых громких сигналов — обычно краша, иногда skip-level. Придумывание работы — это меньше о поиске сигнала, чем о способности объяснить, почему этот, а не другие десять.