Отложено — тоже решение

1. C1Проба с лимитом

   1. Задать лимит
   2. Попробовать
   3. Оставить или прекратить

   Перестать платить: на этом ещё ничего не построено

2. C2Платформа, идентификация, язык

   1. Сравнить
   2. Решить
   3. Первый сервис на этом
   4. Всё на этом

   До отмеченного шага решение свободно пересматривается

3. C3Обещание, за которое клиент может спросить

   1. Спроектировать
   2. Записать в договор
   3. Эксплуатировать

   Возврата нет. Проверять заранее.

И «да», и «нет» — решения, и оба что-то после себя оставляют: запись, ответственного, дату, следующее действие. Предложение, не получившее ни того ни другого, не оставляет ничего. В это состояние дешевле всего что-то положить и дороже всего в нём держать, потому что ни в одном отчёте оно не видно: у отсутствия нет артефакта.

00 / Прошедшие дни измеряют календарь, а не решение

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

Длительность — симптом с несколькими причинами, и реакции на них противоположные:

• ждёт зависимость, которая действительно ещё не разрешилась, — правильно, и стоит сказать вслух;
• отложено, потому что в этом квартале есть что подумать поважнее, — тоже правильно, и это самостоятельное решение;
• ждёт информацию, которую никому не поручили найти, — не хватает запроса;
• ждёт суждение, за которое никто не отвечает, — не хватает ответственного;
• ждёт, потому что ответ «нет», а говорить его никто не хочет, — не хватает «нет».

Последнее стоит назвать прямо. «Нет» — это решение: оно освобождает тех, кто ждал, его можно оспорить и можно пересмотреть, когда что-то изменится. Тишина не делает ничего из этого, а стоит столько же.

01 / Пауза, понятная со стороны

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

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

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

02 / Процесс задаёт обратимость, а не цена

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

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

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

• Пробы с лимитом. Согласуйте лимит, а не инструмент: столько людей, столько времени, столько денег, и вот вопросы, на которые мы рассчитываем ответить. Откат — не продлить. Процесса им нужно меньше всего, а зарегулируют их чаще всего.
• Структурные выборы. Платформа, идентификация, язык, модель данных. Обратимы, пока на них не построено первое, и необратимы после — поэтому они заслуживают записанных критериев, альтернатив и срока proof of concept, а не разговора.
• Обещания. Всё, что доходит до клиента обязательством: требование в договоре, выпущенная мобильная сборка, отправленное письмо, разрушающая миграция. Здесь вопрос не в том, стоит ли это денег, а в том, какова ваша позиция, если это окажется ошибкой, и существовать она должна в письменном виде заранее. План релиза — это план возврата — тот же аргумент на уровне одного деплоя.

03 / Заявка на инструмент — это два утверждения, а слышно одно

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

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

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

04 / Выяснить и решить — разная работа

«Оценить X» одним пунктом смешивает четыре разные вещи: хотим ли мы знать, кто выясняет, к какому сроку и что мы делаем с ответом. Теряется четвёртая, потому что первые три похожи на движение. Исследование заканчивается, ответ ложится в комментарий, а решение, которое он должен был питать, не случается: вопрос отвечен, и ничего не решено.

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

05 / У самого процесса есть цена

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

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

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