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

Я не думаю, что это так.

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

Именно в такой среде я работал над платформой управления университетом в Нигерии.

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

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

Этот опыт привёл к модели CAPE: Crisis-first prioritisation, Architecture as incentive, Parallel data infrastructure и Extensibility by design.

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

C – Приоритизация кризиса в первую очередь

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

Именно так обстояло дело с приёмом студентов.

Тогда онбординг новых студентов был в основном ручным. Студентам нужно было проходить приём и регистрацию с помощью бумажных форм, разрозненных проверок и помощи сотрудников почти на каждом этапе. Кто-то приезжал издалека, многие сталкивались с жёсткими дедлайнами. Если система не выдерживала нагрузку, студенты оставались за бортом. Поэтому сначала был онбординг.

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

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

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

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

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

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

A – Архитектура как стимул

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

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

Просто. Но это держит всю систему.

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

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

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

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

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

P – Параллельная инфраструктура данных

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

Здесь ситуация была именно такой. У стейкхолдеров не было единого представления обо всём процессе.

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

Поэтому мы создавали отчётность одновременно с рабочими процессами.

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

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

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

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

Стройте рабочий процесс и модель видимости вместе. Не просите руководство вести машину вслепую и обещайте дашборд потом.

E – Расширяемость по замыслу

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

Потом случился COVID.

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

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

Студенты были дома. Обучение остановилось. Выручка снизилась. Учреждению не нужен был идеальный ответ. Ему нужен был самый быстрый жизнеспособный вариант.

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

Именно это и означает расширяемость на практике.

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

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

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

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

CAPE ценна не потому, что звучит красиво. Она ценна потому, что последовательность выдерживает проверку.

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

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

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

Если говорить честно, самый трудный принцип на практике — это Architecture as Incentive. Приоритизация кризиса в первую очередь — это решение, которое принимается один раз, в начале. Расширяемость — это привычка, которую можно встроить в стандарты со временем. Architecture as incentive требует более сложной вещи: достаточно убеждённости, чтобы сделать поведение не подлежащим обсуждению в самом продукте, а не решать его downstream с помощью мягкого напоминания или кампании.

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

Если вы уже строите экономно, в Лагосе, в Западной Африке, на рынке, где фраза «у нас не было бюджета сделать иначе» — это не тезис для разговора, а обычный вторник, я не говорю вам, что ограничения полезны. Вы и так это знаете.

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

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

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

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

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

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