Глава 1.Успехов не один, а три 🥇

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

Команда теряла чужие правки при вливе в релизную ветку — провёл для неё курс по гиту. Шесть занятий, все дошли, оценка 4,8. Через месяц правки теряются ровно как раньше. Написал инструкцию по релизу, положил в базу знаний — в чате спрашивают то же самое. В статусе зелено, результата нет. Знакомо? 🦗

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

Три успеха

Первый: сделали как обещали — приёмка (acceptance). Курс проведён, инструкция написана, сервис работает, фича в проде. Это работа первой книги.

Второй: начали пользоваться — использование (adoption). Пришли и досидели. Инструкцию открывают. Завели свои данные. Тут отваливается большинство затей.

Третий: стали работать иначе — изменение (outcome). Перестали терять правки. Перестали спрашивать то, что написано. Выбросили свою табличку. Проблема ушла.

Первый — в основном от тебя и команды. Второй — попал ли ты в людей. Третий — верно ли понял проблему и попал ли в неё решением.

Как это выглядит на разных затеях

Третий столбец — тот, ради которого всё затевалось. Первый — тот, о котором отчитываются 🧾

Ловушка 🪤

Обещал третье, меришь первым.

«Выпустили курс» — зелёная галочка. Спрашиваешь: стало лучше? — «Оценка 4,8». Оценка меряет вежливость аудитории, а не изменение работы.

С инструкцией то же: «написана, вот ссылка». А открывали её шесть раз, три из них — ты сам, пока правил вёрстку 💀

Первый успех получить проще всего. Празднуют громче всего тоже его 🎉

Что делать прямо сейчас

Возьми свою затею и запиши три строки. До старта, не после.

1. Сделали — что готово и когда.
2. Пользуются — кто, что делает и как часто.
3. Работают иначе — что изменится и как ты это увидишь.

Не пишется третья — проблему ещё не назвали точно, это глава 2. Не пишется вторая — не понял, кто эти люди и чем им платить, это глава 5. Пишется только первая — поздравляю: пока это список задач, а не ставка 🎰

Глава 2.Сначала проблема, потом решение 🔎

К тебе приходят не с проблемой. К тебе приходят с решением.

«Сделайте бота». «Нужен курс по гиту». «Давайте соберём чек-лист доступов для новичков». «Надо собираться раз в неделю по проблемам клиентов».

Это уже ответ. Вопрос потерялся по дороге 🕳

Подними запрос до проблемы

Три вопроса, которые возвращают разговор на место:

• Что случилось? Не «что хотите», а что реально произошло в последний раз.
• Как часто? Один раз в жизни или каждую пятницу.
• Что будет, если не делать? Если ответ «ну ничего» — вопрос закрыт.

«Сделайте кнопку выгрузки в Excel» после трёх вопросов превращается в: каждый понедельник человек полтора часа руками сводит три отчёта, потому что ему нужен один файл для директора.

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

Смотри, как человек справляется сейчас

У любой живой проблемы есть обходной путь (workaround). Табличка в экселе, личный чат, «спрошу Марину», записка на мониторе.

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

Спрашивай не «нужен ли вам инструмент», а «покажи, как ты делаешь это сейчас».

Главный соперник — «оставить как есть»

Ты сравниваешь свою затею с чужими затеями. Люди сравнивают её с ничегонеделанием 🛋

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

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

Как понять, что ты застрял в решении

• обсуждаешь, каким будет интерфейс, а не чью жизнь он меняет;
• на вопрос «зачем» отвечаешь «ну это же удобно»;
• проблему называешь через отсутствие своего решения: «у нас нет чек-листа», «у нас нет бота». Это не проблема. Это отсутствие фичи.

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

Что делать

Напиши про свою затею одну строку: что происходит, как часто и что из-за этого теряется. Без слов «сделать» и «внедрить».

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

Не пишется строка — идти дальше рано. Ты пока не знаешь, что чинишь 🤷

Глава 3.Из тридцати проблем выбери одну ✂

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

Сравнивай проблемы, а не решения

Частая ошибка: спорить «курс или инструкция». Это спор про решения, он бесконечный.

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

Четыре вопроса на каждую проблему

• Скольких задевает? Двоих или всю команду.
• Во что обходится ждать? Считай в том, что теряется: часы, деньги, нервы, клиенты.
• Насколько уверен? Видел сам, слышал от троих или предположил в душе.
• Что дешевле — проверить или дальше терпеть? Иногда проверка стоит час, а терпеть будем ещё квартал.

Третий вопрос обычно и решает. Громкая проблема с нулевой уверенностью — это чужое мнение, а не факт.

Когда уверенность высокая

«Мне кажется» — ноль. Один попросил — мнение. Несколько независимых историй — сигнал. След, который был до твоего вопроса — переписка, задача, потраченное время, обходной путь, — вот это высокая уверенность. Люди делают руками или платят своим временем — выше не бывает.

Две ловушки 🪤 Три повтора от одного человека — всё ещё один сигнал. И это уверенность в проблеме: доказательство решения — глава 9.

Пример

На столе три проблемы — именно проблемы, а не «что сделаем».

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

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

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

Когда всё срочно

Если у тебя пять задач с высшим приоритетом, приоритетов у тебя нет 🚦

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

Что делать

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

Возьми одну. Остальным скажи «не сейчас» — вслух, тем, кто их принёс 🙅

Глава 4.Гипотеза вместо хотелки 🎰

Проблему выбрал. Теперь выбери не любимое решение, а проверяемую ставку.

Хотелка и гипотеза

Хотелка: «надо написать инструкцию по релизу».

Гипотеза (hypothesis): «если у новичка будет инструкция на одну страницу, он проведёт первый релиз без чужой помощи — сейчас так делают двое из десяти, хочу шесть».

У гипотезы есть исход: через месяц видно, попал или нет.

Формула простая:

Если сделаем X для Y, то Z изменится с A до B.

X — что делаем. Y — для кого. Z — что должно поменяться в их поведении. A и B — как есть сейчас и как хотим.

Гипотеза — пометка геолога на карте: «считаю, что здесь нефть и вот примерно сколько» 🗺 Это не месторождение; вышку по такой пометке не ставят.

Откуда брать цифры, если данных нет

Обычный вопрос: «а где я возьму эти двое из десяти?»

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

Точность тут не нужна. Нужен порядок величины и честная отметка «до», иначе потом нечем будет доказать, что стало лучше 📏

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

Гипотеза — не цель проекта

Цель проекта: «выпустить инструкцию к 20-му». Это про то, что ты сделаешь.

Гипотеза: «после инструкции новички перестанут дёргать команду на первом релизе». Это про то, что изменится у людей.

Первое ты контролируешь. Второе — нет, поэтому оно и называется ставкой.

Гипотез обычно несколько

На одну проблему выпиши три решения, а не одно любимое. Правки теряются — шпаргалка, новый порядок влива, проверка перед мержем. Спроси про каждое:

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

Это и есть ICE (impact, confidence, ease), о которой говорят на встречах: не баллы, а три честных вопроса. Как таблица со средним баллом она врёт — цифры там всё равно из головы 🎲

Что делать

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

Назвал риск сразу — отлично, есть что проверять, и следующие главы как раз про это.

И главное про планы. Хотелка в плане остаётся гипотезой — просто вокруг неё уже назвали сроки и собрали людей, и признавать ошибку теперь дороже 💀

Глава 5.Ценность одному, работа другому ⚖

«Все согласовали, а никто не пользуется» — самая обидная концовка. И самая частая.

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

Четыре роли, а не «пользователи»

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

Иногда это один человек. Чаще — четверо разных, и интересы у них не совпадают.

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

Поговорил только с руководителем — получил красивую идею и мёртвую встречу 👻

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

Механизм провала

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

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

Сверху разумно, снизу — лишняя работа. Через две недели поля заполняются как попало, и данные, ради которых всё затевалось, годятся только для отчёта о наличии данных 🧾

Посчитай цену в его валюте 🪙

Возьми того, кто платит усилием, и считай:

• сколько минут в день;
• сколько раз придётся вспомнить о новом порядке;
• что он должен перестать делать по-старому;
• чем рискует, если ошибётся.

Минута в день — четыре часа в год на человека. Иногда нормально. Иногда за эти четыре часа ты покупаешь отчёт, который никто не откроет.

Три способа расплатиться

Убрать работу. Лучший вариант: данные берутся сами, поле подставляется, отчёт собирается без человека.

Обменять. Два часа на курс — минус дежурство в этот день. Новое поле — минус старая табличка, которую больше никто не ведёт.

Дать пользу тому же человеку. Не «начальник увидит статистику», а «ты перестанешь объяснять одно и то же по три раза».

Ни один способ не подходит — честный вывод такой: затея живёт на твоём личном авторитете. Ровно до того дня, пока ты за ней следишь ⏳

Пользовательская история (user story) 📝

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

Как [роль], я хочу [что делать], чтобы [зачем ему это].

Плохо: «Как пользователь, я хочу форму, чтобы было удобно». Роль безымянная, «что» — это наш интерфейс, «зачем» — вода.

Хорошо: «Как тимлид, я хочу открыть чек-лист доступов новичка, чтобы в первый день не выяснять по чатам, кому писать».

Три проверки строки:

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

Под историей — критерии приёмки (acceptance criteria): две-три строки, по которым работу принимают, а не «сделано красиво». Удобно писать их как «когда … тогда …»: когда тимлид открывает чек-лист для нового сотрудника, тогда видит список доступов под его роль и того, кто их выдаёт. Списком наблюдаемых условий — тоже нормально, формат тут не догма.

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

Не путай с гипотезой: история говорит что и для кого мы делаем, гипотеза — что из-за этого изменится и на сколько 🎰 История без гипотезы — просто аккуратно оформленная хотелка.

Что делать

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

Не получается закончить фразу — переделай обмен: убери работу, компенсируй её или дай пользу тому же человеку.

И договорись вслух, а не намёком: кто, что делает и с какого дня. Это уже обязательство, а про него — следующая глава 🤝

Глава 6.Разговор, который даёт правду 🎤

Спросишь «нужен ли тебе курс по гиту» — услышишь «конечно, полезно». Спросишь «будешь пользоваться сервисом» — «обязательно».

Люди не врут. Они вежливо отвечают на вопрос про будущее, которого не знают.

Спрашивай про прошлое

Прошлое проверяемо, будущее — нет.

• «Расскажи, как ты в последний раз с этим влип».
• «Что делал, когда это случилось?»
• «Сколько времени ушло? Кого дёргал?»
• «Почему до сих пор не поменял?»

Из ответов про прошлое вытаскиваешь факты: как часто, сколько стоит, какой обходной путь. Из ответов про будущее — только настроение собеседника 🌦

Не продавай свою идею

Как только ты сказал «мы хотим сделать X», разговор закончился. Дальше человек будет обсуждать твоё X, а не свою жизнь. Из вежливости — хвалить.

Идею оставь на потом. Сначала — как оно устроено сейчас.

Пять-восемь разговоров

Магической цифры нет. Есть признак: на пятом-шестом человеке ты перестаёшь слышать новое. Все повторяют одно и то же — можно останавливаться.

Каждый рассказывает разное — не беги за новыми интервью. Проверь, не смешал ли ты разные роли или разные проблемы.

Обязательство — валюта разговора 🤝

Вот главное, ради чего вообще стоит идти к людям. Слова бесплатны. Обязательство (commitment) — это когда человек отдаёт что-то своё, и потому оно чего-то стоит.

Отдать он может три вещи:

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

Лестница снизу вверх: «интересно» → «пришлю пример» → прислал → «зайду в четверг» → зашёл → позвал коллегу → выделил своего человека. Первые ступени ничего не весят, дальше начинается что-то похожее на правду 🪜

Только не переоценивай. Обязательство доказывает, что человек готов участвовать, — и всё. Прийти можно из вежливости или потому, что попросил начальник. Что решение нужное и им будут пользоваться, доказывает уже проверка (гл. 9).

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

Фиксируй как договорённость, а не как пожелание: кто, что делает и к какому сроку. «Ок, в четверг в 15:00, приносишь свой случай» — и в календарь. Размытое «давай как-нибудь» не обязательство, а способ вежливо отстать.

Согласился на словах, но ничего не прислал и не пришёл — это ответ, самый честный из всех. Не спорь с его словами и не уговаривай: запиши как факт и учти в решении 💀

Что делать

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

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

Глава 7.Что проверять первым 🧠

Гипотеза есть. Под ней куча предположений, и каждое может оказаться неправдой.

Проверять всё подряд — долго и незачем. Проверять надо то, из-за чего вся затея рассыпается.

Выпиши, во что ты веришь

Затея: сделать внутренний сервис, куда команды сами заносят статус своих проектов.

Во что ты веришь, даже если не заметил, — это допущения (assumptions):

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

Пять допущений — пять мест, где всё может лечь 🧨

Четыре места, где чаще всего ошибаются

Проверь свой список по четырём вопросам — почти всё попадает в один из них:

• Нужно ли это вообще? Главный и самый частый риск.
• Смогут ли этим пользоваться? Понятно ли, дойдут ли до конца.
• Сможем ли мы это сделать? Руками, силами, за разумное время.
• Сможем ли мы с этим жить? Правила, безопасность, поддержка, время людей.

Про пункт нечего сказать — это не «риска нет». Это значит, что ты о нём не думал.

Найди то, которое убивает

Задай про каждое один вопрос: если это неправда, затея имеет смысл?

• «Не нужно видеть чужой статус» — не имеет. Значит, кандидат.
• «Не готовы заносить свой» — не имеет. Тоже кандидат.
• «Не сможем поддерживать» — тоже кандидат, если без поддержки всё встанет сразу.

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

Проверяй не то, что удобно

Классика: сделать красивый интерфейс и «проверить удобство», хотя вопрос был не в удобстве, а в том, станет ли кто-то это заполнять.

Ещё классика: спросить у тех, кто и так согласен. Проверка, где ты заранее знаешь ответ, — не проверка, а самоуспокоение 🛋

Держи одно допущение на проверку

Одна проверка — один вопрос. Иначе получишь «вроде зашло» и не поймёшь, что именно зашло: тема, формат, время или ты сам.

Хочется проверить три вещи сразу — значит, проверок будет три. Обычно они короткие.

Что делать

Выпиши список «во что я верю». Обведи то, что убивает затею и о чём знаешь меньше всего.

Это и есть предмет следующей главы: как проверить именно его максимально дёшево.

Глава 8.Самая дешёвая проверка ⛏

Правило простое: чем меньше знаешь, тем меньше ставь.

Нефть сначала ищут разведочной скважиной: узкой, быстрой и дешёвой. Вышку ставят, когда нефть уже нашли 🛢

Твоя затея — то же самое. Вопрос не «как строить», а «какой самый дешёвый тест даст ответ».

Думай задом наперёд

Обычный ход: придумал, сделал, посмотрел, что вышло.

Рабочий ход обратный: что хочу узнать → по чему это будет видно → что минимально нужно для этого построить.

Тогда объём работы задаёт вопрос, а не фантазия. После этого хода затея часто резко уменьшается 🤏

Лестница 🪜

Снизу вверх, по стоимости:

1. Разговор. Пять человек, полчаса. Проверяет, есть ли проблема.
2. Набросок. Страница текста, схема на салфетке, экран в презентации. Проверяет, понимают ли люди идею и своё место в ней.
3. Объявление до реализации (fake door). Кнопка «хочу попробовать», встреча или форма записи есть, самой штуки пока нет. Рядом честно написано: проверяем интерес, готовим запуск. Реакция и есть сигнал, стоит ли идти дальше.
4. Руками (concierge). Делаешь то же самое вручную для трёх человек. Проверяет, нужен ли результат.
5. Полуручное (wizard of oz). Снаружи выглядит как сервис, внутри — ты и таблица. Проверяет сценарий целиком.
6. Нормальная реализация. Когда дешёвая проверка уже дала причины вкладываться.

Большинство затей умирает на второй-третьей ступени. И это хорошая новость: они умирают за неделю, а не за квартал 🎉

Минимальное — не халтурное

Частая подмена: «это же MVP, поэтому криво». Нет.

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

Минимальность — про объём, а не про качество. Один сценарий, но целиком и без стыда.

Кода может не быть вообще

Внутренний дайджест — рассылка руками по пятницам, а не сервис.

Чек-лист доступов новичку — страница в гуглдоке, которую после каждого выхода дополняет тот, кто вчера ругался.

Совещание по проблемам клиентов — получасовой созвон троих с одним живым случаем, а не новый ритуал для всей компании.

Курс — одна встреча на сорок минут вместо программы на месяц.

Если руками невыносимо и не масштабируется — правильно. Ты и не собирался так жить, ты собирался узнать 🔍

Что делать

Возьми допущение из прошлой главы и придумай проверку на неделю или дешевле.

Дороже недели — спроси, что можно выкинуть из проверки: сценарий, роль, ручной шаг.

Цикл всегда один и тот же: проверил → сравнил с порогом → решил, что дальше. Не «сделал и посмотрел», а проверил и решил.

И запомни, чем меряется скорость затеи. Не тем, сколько ты сделал, а тем, как быстро превращаешь незнание в знание ⏱

Глава 9.Какое доказательство достаточно, когда людей десять 🔬

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

Сигналы, которые чего-то стоят

От слабого к сильному:

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

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

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

Порог назначай до старта ⏳

До проверки, а не после, запиши: что будет считаться «получилось». Это порог (success criteria).

«Из десяти, кому это нужно, минимум шестеро используют сценарий в следующий раз без напоминания, и минимум двое приносят свой случай».

Получил четверых вместо шести — это не «почти получилось». Это «не получилось, разбираемся». Иначе ты просто двигаешь ворота после удара ⚽

Смотри на каждого, а не на среднее

Пятнадцать человек — не статистика, а пятнадцать историй. Средний процент их прячет.

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

Отсутствие доказательства — не доказательство отсутствия

Четверо из восьми — не «не работает» и не «работает». Это «пока не знаю».

Тогда следующий шаг не «делаем большой запуск», а ещё одна короткая проверка, которая снимает конкретную неясность.

Что делать

Перед проверкой запиши одну строку: сколько человек, что именно делают, за какой срок и при каких условиях.

Эту строку покажи тому, с кем потом будешь обсуждать результат. Тогда спор про «успешно или нет» закончится, не начавшись 🤝

Глава 10.Не делать — нормальный результат 🗑

После проверки бывает три исхода: делаем, меняем ставку, не делаем.

Сухая скважина — обычный результат разведки 🕳 Провал — вышка там, где нефти нет.

Третий исход считают провалом только те, кто путает работу с активностью.

У затеи должна быть кнопка «выбросить»

Начинать умеют все. Ценность в другом: уметь остановить. Кроме кнопки «сделать» (build) у тебя всегда должна быть кнопка «выбросить» (kill).

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

Поэтому дешёвая проверка нужна не ради экономии. Она нужна, чтобы у тебя осталась свобода сказать «не делаем» ✊

Что ты покупаешь отказом

Проверка стоила неделю. Полная реализация стоила бы месяц твой и месяц команды. Отказ — это сэкономленные два месяца и не испорченные людям привычки.

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

Как отказаться и не выглядеть слабым

Не «не получилось». А так:

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

Здесь есть цифра, причина и следующий шаг. Это доклад о работе, а не оправдание 🎤

Поменять ставку

Часто проблема настоящая, а решение не то. Тогда меняется одно из трёх — это и есть поворот (pivot):

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

Не поражение и не начало с нуля. Ты потратил неделю и сузил поиск.

Когда отказываться нельзя

Есть работа, которую делают без всяких проверок: требования закона, безопасность, потеря данных, договорные обязательства. Тут вопрос не «нужно ли», а «как выполнить требование нормально и без лишней работы» 🚨

Не называй это проверкой спроса. Это обязательная работа, её надо довезти.

Что делать

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

Формулировка «ну, пока отложим» в этот список не входит. Это способ не принимать решение и тащить затею в бэклоге ещё год 🧊

Глава 11.Отсюда — в первую книгу 🚪

Проверка закончилась. Дальше три двери: не делаем, проверяем ещё, заводим проект.

Эта книга ведёт тебя до третьей двери и сдаёт с рук на руки.

Что переносить в проект

Из проверки в проект должно уехать не только «делаем», а всё, ради чего затевалось:

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

Без этого проект живёт своей жизнью: команда довозит объём работ, а зачем — помнит только автор. Через месяц он в отпуске, и остаётся объём 🏖

Дальше работает другая дисциплина

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

Одно замечание на стыке: не заводи проект до проверки — если только работа не обязательна по закону, безопасности или договору. Иначе устав превращается в красивое оформление догадки 🎀

Обратная дверь

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

Для этого не нужен пересмотр всего плана. Нужен один вопрос на статусе: то, что мы хотели изменить, всё ещё то самое?

Что делать

Заполни первую заготовку из приложения В и приложи её к проекту первой строкой. Это тот случай, когда полстраницы экономят три спора.

Глава 12.Запустил ≠ пользуются 🦗

Ты объявил. Ссылка есть. Тишина.

Самая частая причина нуля — не «плохо сделано». Люди не узнали, не поняли, зачем это им, или уткнулись на первом шаге и ушли.

Анонс, который работает 📣

Плохо: «в четверг курс по гиту».

Хорошо: «в четверг за сорок минут разберём, почему у нас теряются правки, приносите свой случай».

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

Дальше — три вещи, которые дают больше, чем самый красивый текст:

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

Первые пять минут

Человек пришёл. Что он делает в первые пять минут и что ему мешает?

Регистрация с паролем. Форма на четырнадцать полей. Просьба «сначала прочитайте инструкцию». Каждое препятствие теряет часть людей 🚧

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

Первая неделя ⏳

Запуск — не точка, а неделя. На эту неделю нужен дежурный: тот, к кому идут с «а как тут», и кто чинит на ходу.

Без дежурного каждый затык превращается в тихий отказ. Человек не жалуется, он просто возвращается к старому способу.

Где это лежит

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

Прибей ссылку туда, где люди уже бывают: шапка канала, закреплённое сообщение, первая строка в задаче 📌

Что делать

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

Пять строк. Не документ.

Глава 13.Где пробка 🚧

Всё запустилось, но еле ползёт. Инстинкт — добавить усилий везде: больше анонсов, больше материалов, больше напоминаний.

Чаще всего сильнее всего мешает одно место. Начни с него.

Ищи, где копится очередь

Пробка (bottleneck) выглядит просто: перед ней всё скапливается, за ней — пусто.

• Волонтёрство упирается не в желающих, а в человека, который назначает встречу.
• Курс — не в контенте, а в согласовании даты.
• Сервис — не в разработке, а в том, что данные некому завести.
• Инструкция — не в тексте, а в том, что её не находят.

Спроси себя: чего ждут люди прямо сейчас? Ответ и есть пробка 🐢

Не улучшай то, что и так не мешает

Ускорил то, что и так успевало, — не изменилось ничего, только очередь перед узким местом выросла.

Написал ещё три страницы инструкции, хотя её не находят, — стало три ненайденные страницы вместо одной.

Самая обидная работа: сделано много, результат нулевой 🥱

Сначала выжми, потом расширяй

Прежде чем просить ресурсы, посмотри, чем узкое место занято зря.

Согласование ждёт человека, который согласует всё подряд? Дай ему решать только спорное, остальное — по умолчанию.

Данные некому завести? Импортируй половину сам, оставь людям пять минут.

Часто пробку снимают не новыми людьми, а тем, что убирают с неё лишнюю работу 🧹

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

Не заваливай пробку работой

Если согласование переваривает две затеи в неделю, не неси туда пять: очередь вырастет, а проходить будет всё те же две. Остальные будут просто стоять и портиться.

И да: человек, загруженный на сто процентов, становится пробкой при первой неожиданности 🔥

Запасы — это замороженные деньги 🧊

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

У тебя склад тоже есть. Полфичи. Недописанный курс. Черновик инструкции. Три пилота на паузе. Это и есть запасы (inventory, WIP) — всё уже стоило времени и не вернуло ничего.

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

Отсюда правило: меньше начинай, больше закрывай. Закрыть — это довести до использования, поменять ставку или сказать «не делаем». Всё остальное — склад, даже если в отчёте это «в работе».

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

И если пробка — ты сам, не бери новое, пока не закрыл предыдущее.

Что делать

Нарисуй путь от «человек услышал» до «человек пользуется» и отметь, где очередь.

Чини одно место. Потом смотри снова: пробка переезжает, это нормально.

Глава 14.Разбор продуктом, а не процессом 🔦

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

Полезно. Но главный вопрос другой: во что мы верили и что из этого оказалось неправдой?

Четыре строки

• Во что верили. «Люди не знают гит».
• Что оказалось. «Гит знают, не знают наш релизный порядок».
• Что это меняет. Курс был не про то; нужна страница про порядок.
• Следующая ставка. Проверить, уйдут ли вопросы, если дать страницу про порядок.

Это и есть разбор. Пятнадцать минут и полстраницы ⏱

Не ищи виноватого

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

Как только разговор сползает на «кто предложил» — разбора не будет, будет защита. Люди перестанут приносить идеи, а неудачные затеи начнут тихо доживать в углу, чтобы никто не заметил 🙈

Разбираем решение и данные. Не человека.

Что делать с результатом

У разбора три честных исхода:

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

Любой из трёх лучше, чем «ну, вроде норм» и молчание.

Узнай свою контору

Пара признаков, что разбирать вам придётся часто:

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

Начни с одного вопроса вслух и вовремя: что должно измениться и как мы это увидим.

Что делать

После каждой затеи — четыре строки. Храни их в одном месте.

Через полгода это будет самый полезный документ в компании: список того, во что вы верили зря, и то, что вы вместо этого узнали 📚

Приложение А.Одна затея целиком: история курса 🎬

Случай условный, грабли настоящие. В скобках — главы книги.

На планёрке прилетело: «надо обучить ребят гиту, они мержат через жопу». Решение принесли готовым, проблему назвать забыли (гл. 2). Спрашиваю, что случилось: за месяц дважды потеряли чужие правки в релизной ветке.

Ровно тот случай, ради которого написана первая глава: курс можно провести отлично и всё равно не попасть в проблему (гл. 1).

Проблем вокруг нашлось штук десять. Взял одну: потерянные правки. Повторяется, ломает релиз, остальное подождёт (гл. 3). Гипотеза: если семеро будут вливать ветку по одному сценарию, потери за месяц уйдут с двух до нуля (гл. 4).

Пошёл к людям. Не «хотите курс?» — курс бесплатный, хотят все. Спрашивал, как в последний раз влипли (гл. 6). Пять разговоров — и картина другая: гит они знают, а нашего релизного процесса не знает никто.

Роли разошлись (гл. 5): сидеть на курсе разработчикам, а конфликты перестанет разгребать тимлид. Цену платит один, пользу получает другой. Договорился заранее и вслух: два часа в рабочее время, дежурство по багам в этот день на тимлиде — это уже обязательство, а не «постараемся».

Опасное допущение было не «интересно ли», а «изменит ли разбор чужого конфликта привычку» (гл. 7). Проверил дёшево: собрал троих на сорок минут и разобрал их живое слияние (гл. 8). Порог назначил заранее: двое из троих в следующем слиянии идут по новому сценарию и могут объяснить его коллеге (гл. 9). Пошли все трое, двое потом принесли свои случаи. Полный курс на четыре занятия готовить не стал: сделал один урок и грубый план остальных (гл. 10). И слава богу ⚡ готовые четыре пришлось бы выбрасывать.

Дальше начался обычный проект: договорились, зачем и для кого, что в него не входит и по чему поймём, что готово (гл. 11).

Запуск чуть всё не убил (гл. 12). Первый анонс звучал «в четверг курс по гиту» — не записался никто. Переписал: «в четверг за сорок минут разберём, почему у нас теряются правки, приносите свой случай», и попросил тимлида сказать это голосом на планёрке. Пришли шестеро ✊

Теории на занятии не было вообще: разобрали три настоящих слияния. И тут план поехал. Выяснилось, что спорят не про команды гита, а про очередь — кто вливает первым перед релизом. Вторую половину занятия перестроил на ходу; четверо потом назвали её главным куском.

Одним занятием не кончилось — попросили продолжение. Дальше я собирал не программу, а гипотезы: каждый урок проверял одну. «Разберутся по шпаргалке без меня» — подтвердилось, урок не понадобился. «Сами начнут разбирать чужие конфликты» — не подтвердилось, переписал.

Двое попросили не инструкцию на две страницы, а шпаргалку в три строки. Написал и бросил в чат. Там её никто не находил; ссылка в шапке канала это починила (гл. 13).

Через месяц ни одной потерянной правки. Для победного отчёта рано, но шестеро идут по сценарию, а двое просят такой же разбор по релизам. Это сильный сигнал, не финальный успех. И меряю я не «провёл курс», а потерянные правки (гл. 1).

Не подтвердилось исходное объяснение: дело было не в знании гита, а в отсутствии общего процесса. Поэтому следующая ставка — не второй курс, а страница релизного сценария (гл. 14).

Приложение Б.Короткие разборы 🗂

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

Новый порядок код-ревью

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

Кросс-командная договорённость

Проблема: задача между двумя командами стоит неделю, потому что «ждём их». Кого спросить: по два человека с каждой стороны и того, кто будет разруливать споры. Дешёвая проверка: три задачи проводим по новому порядку вручную, с одним дежурным. Успех: передача занимает день, никто не ходит договариваться лично. Где ложится: договорились руководители, а передают задачи исполнители.

Инструкция

Проблема: один и тот же вопрос приходит в чат каждую неделю. Кого спросить: тех, кто спрашивал, и того, кто устал отвечать. Дешёвая проверка: ответить одному человеку письменно и дать этот текст следующему. Успех: человек делает задачу, не заходя в чат. Где ложится: текст есть, но его не находят; лечится местом, а не объёмом.

Внутренний сервис на десяток человек

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

Чек-лист доступов новичку

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

Еженедельное совещание по проблемам клиентов

Проблема: жалобы клиентов знает поддержка, а чинят их совсем другие люди и не скоро. Кого спросить: поддержку, того, кто чинит, и того, кто отпускает людей на час. Дешёвая проверка: три недели, полчаса, три человека, один живой случай за встречу. Успех: у каждого разобранного случая есть владелец, следующий шаг и срок, и хотя бы один случай дошёл до починки или изменения процесса. «Проблемы клиентов чинят» — это итог, его видно позже. Где ложится: превращается в отчётный ритуал, куда носят статусы вместо проблем 💤

Пет-проект

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

Спорное место в фиче

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

Приложение В.Четыре заготовки 🧰

Заполняются за полчаса. Сухо и без разговорности — это формы, а не текст.

1. Страница затеи

• Проблема (факт): что происходит, как часто, что теряется.
• Кого задевает: роли и имена.
• Обходной путь сейчас: как справляются без нас.
• Цена ожидания: что будет, если отложить на три месяца.
• Гипотеза: если сделаем X для Y, то Z изменится с A до B.
• Цифра «до»: откуда взята.
• Во что верим: список допущений.
• Самое опасное допущение: одно.
• Как люди узнают: где скажем, кто озвучит, что человек делает в первые пять минут.
• Как увидим успех: сделали / пользуются / работают иначе — по строке на каждый.

2. Сценарий разговора

• Расскажи, как ты в последний раз с этим столкнулся.
• Что именно ты делал? Что произошло дальше?
• Сколько времени ушло? Кого пришлось дёргать?
• Как ты справляешься с этим сейчас?
• Почему до сих пор не поменял?
• Что было бы, если бы это исчезло совсем?
• Просьба об обязательстве: пришли пример / покажи экран / зайди в четверг.
• Записать: кто, что делает, к какому сроку. И сделал ли.

Правило: не рассказывать свою идею до последнего вопроса.

3. Пользовательские истории

Плоский список, каждая история — одна строка:

• Как [роль], я хочу [что делать], чтобы [зачем ему это].

Под каждой — критерии приёмки, две-три строки. Удобная форма, но не обязательная:

• Когда [действие того же человека из истории], тогда [что он получает].

Проверка перед тем, как отдать в работу:

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

4. Карточка проверки

• Что проверяем: одно допущение.
• Как: способ и его стоимость в днях.
• Участники: сколько человек и кто именно.
• Срок: от и до.
• Порог: сколько человек, что делают, за какой срок и при каких условиях.
• Что не ухудшаем: что нельзя сломать по дороге.
• Решение по итогу: делаем / меняем ставку / не делаем.

Порог заполняется до старта. После старта поле не редактируется.

Приложение Г.Словарь и чек-лист 📕

Словарь по-пацански

Проблема (problem) — то, что уже происходит с людьми. Не «у нас нет сервиса», а «данные расходятся в трёх табличках».

Решение (solution) — способ починить. Их всегда несколько, и первый обычно самый дорогой.

Гипотеза (hypothesis) — ставка: если сделаем X для Y, то Z изменится с A до B.

Допущение (assumption) — то, во что ты веришь молча. Самое опасное — то, при провале которого затея бессмысленна.

Пользовательская история (user story) — как [роль], я хочу [что делать], чтобы [зачем]. Что и для кого делаем; на сколько это изменит жизнь — уже гипотеза.

Критерии приёмки (acceptance criteria) — «когда … тогда …», по чему принимаем работу.

Проверка (experiment) — способ узнать дёшево. Не первый релиз, а покупка информации.

Обязательство (commitment) — человек отдал своё: время, репутацию или ресурс. Весит больше любого мнения, но доказывает только готовность участвовать, а не спрос.

Порог (success criteria) — условие, назначенное до старта: цифра, действие или срок. Чтобы потом не спорить, получилось ли.

Обходной путь (workaround) — как люди справляются сейчас. Хорошая зацепка, чтобы проверить, настоящая ли боль.

Приёмка (acceptance) — сделали то, что обещали. Первый из трёх успехов.

Использование (adoption) — люди начали пользоваться. Второй.

Изменение (outcome) — люди стали работать иначе, проблема ушла. Третий, ради него всё.

Объявление до реализации (fake door) — запись, кнопка или встреча есть, самой штуки пока нет. Честно предупреждаем, что готовим запуск.

Руками (concierge) — делаем то же самое вручную для троих, без кода.

Кнопка «выбросить» (kill) — решение остановить затею. Работает только там, где проверка стоила недорого.

Поворот (pivot) — та же проблема, другая ставка: аудитория, решение или масштаб.

Пробка (bottleneck) — место, где всё копится. Пока не расшита, остальные улучшения бесполезны.

Цена ожидания (cost of delay) — что теряем, если отложим на три месяца.

Запасы (inventory, WIP) — всё начатое и не закрытое: не доведённое до использования, не изменённое и не остановленное. Деньги, которые уже потратили и ещё не вернули.

ICE (impact, confidence, ease) — три вопроса при выборе: сколько изменится, откуда знаем, сколько стоит первый шаг. Полезен как список вопросов, вреден как таблица с баллами.

Lean Canvas — одностраничник про продукт и бизнес на девять блоков. Нам целиком не нужен: половина блоков про деньги и продажи. Ближайший наш аналог — страница затеи из приложения В.

Чек-лист спорного места 🥊

Когда спор идёт по кругу, семь вопросов за десять минут:

1. Чью проблему решаем? Имя, а не «пользователей».
2. Что человек делает сегодня вместо этого?
3. Что должно измениться в его поведении?
4. Откуда мы знаем, что это так? Факт, наблюдение или ощущение?
5. Как проверить дешевле, чем сделать?
6. Что будет считаться успехом и когда посмотрим?
7. Что мы не сделаем, если возьмём это?

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