Техническое задание: развитие бизнес-учебника

Актуальность: 2 августа 2026 года.

Статус реализации: волны 1–6 внедрены 2 августа 2026 года. Технические гейты, сборка и публикация пройдены; поведенческие результаты P3 накапливаются только после реального использования. Ручная проверка импорта CSV в Excel, LibreOffice и Google Sheets и тест нового пользователя остаются отдельной приёмкой.

1. Цель

Превратить действующий набор стандартов, маршрутов и шаблонов в учебно- практическую систему, в которой собственник бизнеса с командой 1–10 человек:

1. за 10–15 минут выбирает подходящий маршрут;
2. изучает только необходимый минимум;
3. сразу выполняет действие в своём бизнесе;
4. получает проверяемый артефакт или наблюдение;
5. связывает доказательство с гипотезой, решением, планом и метрикой;
6. может вернуться к материалу без повторного изучения всей системы.

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

2. Область работ

В область входят:

• стандарты и маршрутизаторы в docs/;
• рабочие шаблоны и CSV-заготовки в templates/;
• навигация, поиск и интерфейс VitePress;
• связи между понятиями, документами, шаблонами и результатами работы;
• учебные примеры, контроль освоения и поддержание актуальности.

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

3. Исходное состояние и вывод аудита

Система уже содержит сильное методическое ядро:

• три входных маршрута в START_HERE.md;
• единый язык доказательств и разграничение фактов, расчётов, сигналов, гипотез и мнений;
• полный управленческий цикл от паспорта бизнеса до ретроспективы решения;
• отдельные стандарты финансов, продаж, исследований, рисков, AI, права РФ, поддержки и отраслевых моделей;
• связанные рабочие шаблоны и табличные схемы;
• работающую VitePress-сборку, локальный поиск и тематическую навигацию.

Основные ограничения текущей версии:

1. Материалы сильнее как стандарты для опытного консультанта, чем как система самостоятельного освоения начинающим собственником.
2. Нет одного сквозного заполненного кейса, поэтому пользователь видит формы, но не всегда понимает требуемую глубину и качество ответа.
3. У документов нет единого учебного заголовка: «когда применять», «что нужно на входе», «сколько времени», «что получится», «какой следующий шаг».
4. Маршруты связаны ссылками, но нет единой визуальной карты артефактов, статусов и переходов между ними.
5. Большинство рабочих таблиц в Markdown и CSV не содержит демонстрационной строки; все HTML-таблицы нельзя скачать одинаковым способом.
6. Краткий глоссарий не покрывает значительную часть финансовых, продуктовых, инвестиционных и ИТ-аббревиатур.
7. Навигация поддерживается вручную одновременно в нескольких индексах и VitePress sidebar; сборка проверяет ссылки, но не полноту включения страницы в маршруты.
8. Правовые, налоговые, технологические и инвестиционные сведения быстро меняются; дата есть у документа, но не всегда у отдельного изменяемого утверждения.
9. Нет измерения того, помогает ли учебник пользователю принять решение и внедрить изменение, а не только прочитать страницу.

4. Принципы проектирования

• Один вопрос пользователя должен иметь один рекомендуемый вход.
• Теория сопровождается действием, примером, шаблоном и критерием готовности.
• Первый маршрут остаётся лёгким; углубление открывается по риску и стадии.
• Каждое существенное утверждение прослеживается до источника или помечается как гипотеза/мнение.
• Один канонический источник не дублируется в нескольких разделах.
• Примерные данные явно синтетические и не похожи на данные реального бизнеса.
• Автоматизация не создаёт второй источник истины и не усложняет Markdown.
• Для команды 1–10 человек стоимость ведения системы должна быть ниже пользы от решений, которые она улучшает.

5. Целевая архитектура пользовательского пути

вопрос собственника
→ короткая диагностика маршрута
→ одна учебная карточка
→ заполненный пример
→ пустой рабочий шаблон
→ действие в бизнесе
→ доказательство
→ решение и стоп-условие
→ метрика и дата пересмотра

Каждый основной документ должен отвечать на семь вопросов:

Поле	Требование	Пример результата
Когда применять	Ситуация и триггер	«Неясно, почему выручка не растёт»
Время	Оценка первого прохода	20 минут чтения + 60 минут работы
Вход	Минимальные данные	Банк, продажи, часы собственника
Действие	Один проверяемый шаг	Сверить вклад трёх направлений
Выход	Конкретный артефакт	Таблица экономики по направлениям
Готово, когда	Наблюдаемый критерий	Цифры воспроизводятся из источника
Дальше	Один основной переход	Зафиксировать решение в журнале

Значения времени являются ориентиром для планирования, а не обещанием срока.

6. Пакеты улучшений

P0. Таблицы: скачивание, примеры и безопасность данных

Цель — сделать каждую таблицу пригодной для немедленного использования.

6.1. Единый стандарт

Разделить таблицы на два типа:

• справочная таблица — содержит значения, сравнения или классификацию;
• рабочая таблица — предназначена для заполнения пользователем.

Для каждой таблицы независимо от типа:

• в веб-версии показывать кнопку «Скачать CSV» рядом с таблицей;
• формировать имя файла из адреса страницы и ближайшего заголовка;
• экспортировать видимые заголовки и строки в UTF-8 CSV;
• корректно экранировать запятые, кавычки и переносы строк;
• защищать поля, начинающиеся с =, +, - или @, от CSV/formula injection;
• сохранять текстовое пояснение единиц, периода, валюты и НДС рядом с таблицей;
• обеспечивать управление с клавиатуры и понятную подпись кнопки на мобильном.

Для рабочих таблиц дополнительно:

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

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

6.2. Реализация скачивания

Предпочтительный вариант — клиентский компонент VitePress, который добавляет кнопку ко всем отрендеренным Markdown-таблицам. Это устраняет необходимость вручную поддерживать десятки дублирующих CSV-файлов.

Отдельные CSV-файлы сохраняются для регулярных реестров и импорта:

• метрики;
• доказательства;
• гипотезы;
• эксперименты;
• риски;
• источники;
• меры поддержки.

6.3. Инвентаризация

Создать машинно проверяемый реестр таблиц:

ID	Страница	Заголовок	Тип	Пример	CSV	Владелец	Проверено
T-001	METRICS_AND_FINANCE.md	Базовые формулы	справочная	да	автоэкспорт	редактор финансов	дата

6.4. Критерии приёмки P0

• каждая Markdown-таблица на сайте имеет работающую кнопку скачивания;
• каждый рабочий шаблон содержит помеченный синтетический пример и пустую строку;
• CSV открывается в Excel, LibreOffice и Google Sheets без потери кириллицы;
• значения с опасным первым символом не исполняются как формулы;
• Markdown и CSV регулярных реестров имеют одинаковые поля и смысл;
• автоматический тест сравнивает число таблиц и число кнопок/экспортов;
• VitePress-сборка и проверка внутренних ссылок проходят.

P0. Справочник аббревиатур и терминологическая связность

Создать core/ABBREVIATIONS.md минимум со 100 сокращениями по направлениям: финансы, маркетинг и продажи, продукт/ SaaS, инвестиции, операции и риски, AI/ИТ/данные, право и налоги РФ.

Для каждой записи указать:

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

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

Критерий приёмки: минимум 100 уникальных записей; нет дубликатов ID; ссылки на якоря работают; справочник доступен из START_HERE.md, core/INDEX.md, общего INDEX.md, глоссария и sidebar.

P1. Быстрый выбор маршрута

Добавить в START_HERE.md диагностику из 6–8 вопросов:

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

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

Ввести три уровня глубины:

Уровень	Для кого	Результат	Лимит
Быстрый старт	первый вопрос или малый риск	один вывод и следующий шаг	30–60 минут
Рабочий маршрут	действующий бизнес	заполненный артефакт и решение	2–4 часа
Глубокая проверка	высокая цена ошибки	доказательства, сценарии, red team	по brief

P1. Сквозной учебный кейс

Создать один полностью вымышленный кейс малого ИТ-сервисного бизнеса и провести его через систему:

1. паспорт бизнеса;
2. brief аудита;
3. реестр из 8–12 доказательств;
4. экономика трёх направлений;
5. интервью клиента и карточка конкурента;
6. три конкурирующих диагноза;
7. backlog гипотез;
8. карточка одного эксперимента;
9. журнал решения;
10. план на 90 дней и недельный обзор;
11. ретроспектива с отрицательным или смешанным результатом.

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

P1. Радар предпринимательского опыта и «боли»

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

Обязательные источники для регулярного просмотра:

• vc.ru/marketing и vc.ru/ai — российские сигналы, комментарии и кейсы;
• Indie Hackers и MicroConf — небольшие цифровые бизнесы и SaaS;
• Y Combinator Library и Stripe Atlas Guides — практика запуска, денег, команды и инвестиционных условий;
• First Round Review — подробные интервью операторов;
• первичные founder post-mortem и архивы закрытых стартапов — причины, которые редко попадают в успешные кейсы.

Первичная выборка подтверждает полезность следующих механизмов, но не их универсальность:

• основатель Keepthescore описывает несколько неудачных проектов до появления продукта с органическим использованием и реальной оплатой; это поддерживает правило «оплата и повторное поведение сильнее списка ожидания» (кейс);
• кейс Flexiple показывает, что ручной процесс и простые таблицы могут подтвердить модель до дорогой разработки; это источник гипотезы «сначала работающий сервис, затем автоматизация» (кейс);
• опыт Famewall связывает рост с прямой поддержкой клиентов, но одновременно показывает выгорание, ошибку слепого копирования советов и сознательный выбор lifestyle-бизнеса вместо максимального MRR (кейс);
• post-mortem Fab связывает гиперрост с отсутствием устойчивой операционной модели; рекомендация по росту должна поэтому проверять маржу, денежный цикл, мощность и качество исполнения (post-mortem);
• данные Stripe Atlas за 2025 год показывают ускорение первых оплат у части новых компаний даже при снижении доли профинансированных стартапов; это поддерживает приоритет времени до первой выручки, но выборка ограничена клиентами Atlas (обзор);
• публикации в vc.ru/marketing регулярно сигнализируют о риске масштабировать лиды без экономики клиента (пример);
• материалы vc.ru/ai показывают повторяющиеся жалобы на неверно выбранный процесс, неполный учёт интеграции и отсутствие метрики качества; их цифры нельзя переносить без первичной проверки (пример).

Каждый кейс заносить в журнал по схеме:

контекст → исходная боль → действие → полная стоимость → срок
→ метрика до/после → что не сработало → скрытая цена → применимость
→ контраргумент → дешёвый локальный тест → дата повторной проверки

Перед рекомендацией обязательно ответить:

1. Совпадают ли стадия, модель, география, чек, канал и мощность команды?
2. Показана прибыль и денежный поток или только выручка/аудитория?
3. Учтены ли часы владельца, переделки, скидки, поддержка и стоимость капитала?
4. Что автор продаёт и какие неудачные попытки могли быть скрыты?
5. Какой риск появляется при успешном масштабировании?
6. Есть ли противоположный кейс и локальное поведенческое доказательство?

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

P1. Единая карточка документа

В начале основных стандартов внедрить одинаковый компактный блок:

Когда применять | Время | Вход | Результат | Шаблон | Следующий шаг

В конце — одинаковый блок:

Готово, когда | Что проверить | Что осталось неизвестным | Куда дальше

Сначала внедрить в BUSINESS_CONTEXT.md, BUSINESS_AUDIT.md, METRICS_AND_FINANCE.md, MARKET_RESEARCH.md, HYPOTHESES.md, DECISION_MAKING.md и OPERATING_CADENCE.md, затем распространить на остальные документы.

P1. Карта артефактов и единые ID

Добавить одну каноническую схему связей:

S-* источник → E-* доказательство → F-* находка/ограничение
→ H-* гипотеза → X-* эксперимент → D-* решение
→ P-* приоритет → M-* метрика → R-* ретроспектива

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

P2. Освоение и самопроверка

Для каждого тематического маршрута добавить:

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

Рекомендуемый цикл освоения — четыре недели:

Неделя	Тема	Действие	Доказательство
1	Контекст и деньги	собрать паспорт и сверить денежный поток	список неизвестных и cash runway
2	Клиент и продажи	разобрать потери и провести интервью	причины отказов и событие покупки
3	Ограничение и гипотезы	сравнить три диагноза	shortlist и один дешёвый тест
4	Решение и ритм	принять решение и запустить обзор	владелец, метрика, стоп-условие

P2. Полнота содержания

Добавить или усилить только те темы, которые меняют решения малого бизнеса:

• ценообразование и управление скидками;
• найм, мотивация и экономика роли;
• партнёрства и условия распределения риска;
• сервисное качество, жалобы и восстановление доверия;
• закупки, поставщики и концентрация цепочки поставок;
• продажа бизнеса, преемственность и личная финансовая устойчивость владельца;
• антикризисный 13-недельный cash-flow;
• AI-экономика эксплуатации, контроль качества и vendor lock-in.

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

P2. Актуальность и доказательность внешних утверждений

Для изменяемых юридических, налоговых, программных и инвестиционных сведений добавить рядом:

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

Сделать автоматический отчёт по просроченным датам и недоступным ссылкам. Недоступность сайта не должна автоматически означать прекращение программы; она создаёт задачу ручной проверки.

P2. Навигация и автоматические проверки

Устранить ручное расхождение между INDEX.md, тематическими индексами и VitePress sidebar:

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

P3. Измерение полезности учебника

Без сбора лишних персональных данных измерять:

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

Главная метрика — не просмотры, а доля маршрутов, завершившихся проверяемым управленческим решением.

7. Последовательность выполнения

Волна	Содержание	Зависимость	Результат	Условие остановки
1	Аббревиатуры, ссылки, инвентаризация таблиц	нет	устранены базовые барьеры понимания	ссылки и сборка проходят
2	Автоэкспорт CSV и примеры всех рабочих таблиц	инвентаризация	таблицы можно сразу скачать и применить	все таблицы покрыты тестом
3	Быстрый маршрут и карточки ключевых документов	волна 1	понятен минимальный путь	тестовый пользователь выбирает маршрут без помощи
4	Сквозной кейс и учебные задания	волна 3	показан стандарт качества результата	кейс проходит весь цикл без разрывов ID
5	Метаданные, генерация навигации и проверки свежести	волны 1–4	меньше ручного обслуживания	CI обнаруживает заданные нарушения
6	Аналитика полезности и редакционные улучшения	стабильный сайт	решения основаны на поведении пользователей	определён цикл ежемесячного review

Оценки трудоёмкости уточняются после инвентаризации таблиц и проверки VitePress-компонента. Не начинать одновременно больше двух волн.

8. Общие критерии готовности

• новый пользователь находит релевантный маршрут максимум за 15 минут;
• каждый ключевой документ приводит к одному артефакту или решению;
• заполненный пример и рабочий шаблон доступны рядом;
• все таблицы скачиваются в CSV и имеют пример заполнения;
• первые употребления аббревиатур ведут в единый справочник;
• существенная рекомендация прослеживается через ID до доказательства;
• внешние изменяемые утверждения имеют источник и дату проверки;
• нет битых внутренних ссылок и страниц вне навигации;
• VitePress-сборка проходит без ошибок;
• тестовый пользователь может пройти сквозной кейс без устного объяснения;
• итоговый review фиксирует изменённое, проверенное и оставшееся неизвестным.

9. Условия пересмотра плана

План пересматривается, если:

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

Ближайшее действие после реализации: провести тест маршрута с новым пользователем, вручную открыть контрольные CSV в Excel/LibreOffice/Google Sheets и через месяц выполнить первый review локальных метрик полезности.