Product Discovery для сервисных компаний

• Глава 1.1: Введение. От теории к практике
  • 1. Ключевые идеи из курса (Взгляд теоретика)
  • 2. Что это значит для нас (Взгляд практика из сервисной компании)
  • 3. Сравнительная таблица целей
  • 4. Наш основной процесс
• Глава 2.1: Что такое Product Discovery? Определение для практиков
  • 1. Ключевые идеи из курса (Академическое определение)
  • 2. Что это такое для нас (Рабочее определение)
  • 3. Сравнение фокусов при оценке рисков
  • 4. Диаграмма трансформации запроса
• Глава 2.2: Зачем на самом деле нужно Product Discovery?
  • 1. Ключевые идеи из курса (Аргументы для продуктовой компании)
  • 2. Что это дает нам (Аргументы для сервисной компании)
  • 3. Сравнение: “До” и “После” внедрения Discovery
  • 4. Диаграмма ценности: два пути пресейла
• Глава 2.3: Процесс Product Discovery. Теория и практика
  • 1. Ключевые идеи из курса (Классический процесс)
  • 2. Как этот процесс выглядит у нас (Линейный пресейл-процесс)
  • 3. Сравнение процессов в виде таблицы
  • 4. Наша воронка пресейла
• Глава 3.1: Команда для Product Discovery. Роли в сервисной компании
  • 1. Ключевые идеи из курса (Классическая продуктовая команда)
  • 2. Наша команда (Дуэт Продаж и Технологий)
  • 3. Роли и обязанности в нашей команде
  • 4. Диаграмма взаимодействия
• Глава 4.1: Понимание потребностей. Кого мы на самом деле слушаем?
  • 1. Ключевые идеи из курса (Фокус на конечном пользователе)
  • 2. Наша реальность (Фокус на бизнес-заказчике)
  • 3. Сравнение объектов исследования
  • 4. Диаграмма смещения фокуса
• Глава 4.2: User Persona. Адаптируем для работы с клиентом
  • 1. Ключевые идеи из курса (Портрет конечного пользователя)
  • 2. Наша версия — «Портрет Ключевого Стейкхолдера»
  • 3. Шаблон «Портрета Ключевого Стейкхолдера»
  • 4. Диаграмма влияния стейкхолдеров
• Глава 4.3: Empathy Map. Структурируем информацию от клиента
  • 1. Ключевые идеи из курса (Сопереживание пользователю)
  • 2. Наша версия — «Карта Воркшопа»
  • 3. Шаблон «Карты Воркшопа»
  • 4. Диаграмма трансформации информации
• Глава 4.4: Интервью с клиентом. Как задавать правильные вопросы
  • 1. Ключевые идеи из курса (Вопросы для пользователей)
  • 2. Наш подход — «Технический воркшоп-интервью»
  • 3. Наш чек-лист вопросов для воркшопа с клиентом
  • 4. Диаграмма “Воронка вопросов”
• Глава 4.5: Дополнительные техники. Где еще брать информацию?
  • 1. Ключевые идеи из курса (Анализ данных и конкурентов)
  • 2. Наши источники информации
  • 3. Таблица адаптации техник
  • 4. Диаграмма “Наши источники истины”
• Глава 5.1: Определение проблемы. Формулируем скоуп проекта
  • 1. Ключевые идеи из курса (Поиск и формулировка проблемы)
  • 2. Наша цель — определить скоуп, а не «проблему»
  • 3. Шаблон для определения скоупа (Scope Statement)
  • 4. Диаграмма “Сужение фокуса”
• Глава 5.2: Приоритизация. Как договориться с клиентом о MVP
  • 1. Ключевые идеи из курса (Фреймворки для бэклога)
  • 2. Наша цель — приоритизация для продажи, а не для разработки
  • 3. Адаптация фреймворка MoSCoW для переговоров
  • 4. Диаграмма “Процесс согласования MVP”
• Глава 6.1: Поиск решений. От креатива к архитектурному эскизу
  • 1. Ключевые идеи из курса (Время для креатива)
  • 2. Наша цель — быстро прийти к одному рабочему варианту
  • 3. Сравнение подходов к поиску решения
  • 4. Диаграмма “От проблемы к оценке”
• Глава 6.2: Мозговой штурм. Проектируем решение вместе с клиентом
  • 1. Ключевые идеи из курса (Классический мозговой штурм)
  • 2. Наш формат — «Архитектурный воркшоп»
  • 3. Правила нашего «Архитектурного воркшопа»
  • 4. Диаграмма “Процесс воркшопа”
• Глава 6.3: Mind Map. Декомпозируем решение для оценки
  • 1. Ключевые идеи из курса (Карта для идей)
  • 2. Наш формат — «Карта работ» (Work Breakdown Structure)
  • 3. Пример нашей «Карты работ»
  • 4. От Карты работ к итоговой оценке
• Глава 6.4: Working Backward. Описываем цели и видение проекта
  • 1. Ключевые идеи из курса (Техника Amazon)
  • 2. Наша адаптация — «Описание будущего решения» в ТКП
  • 3. Шаблон «Описания будущего решения»
  • 4. Диаграмма “От видения к реализации”
• Глава 6.5: Role-Storming. Проверяем наше предложение на прочность
  • 1. Ключевые идеи из курса (Штурм в роли пользователя)
  • 2. Наша адаптация — «Предзащита коммерческого предложения»
  • 3. Сценарий «Предзащиты ТКП»
  • 4. Диаграмма “Цикл усиления предложения”
• Глава 6.6: Техника “Что, если?”. Выявляем и отрабатываем риски
  • 1. Ключевые идеи из курса (Генерация идей через ограничения)
  • 2. Наша адаптация — «Анализ рисков»
  • 3. Наш чек-лист вопросов “Что, если?” для анализа рисков
  • 4. Диаграмма “От риска к плану”
• Глава 7.1: Валидация решения. Защищаем коммерческое предложение
  • 1. Ключевые идеи из курса (Всесторонняя проверка)
  • 2. Наша валидация — это успешная защита ТКП
  • 3. Чек-лист для успешной защиты (валидации) ТКП
  • 4. Диаграмма “Процесс валидации ТКП”
• Глава 8.1: Прототипирование. Визуализируем идею для клиента
  • 1. Ключевые идеи из курса (Прототип для проверки гипотез)
  • 2. Наша цель — прототип как инструмент продажи
  • 3. Сравнение целей прототипирования
  • 4. Диаграмма “Путь прототипа к контракту”
• Глава 8.2: Зачем использовать прототипирование? Наши причины
  • 1. Ключевые идеи из курса (Причины для продуктовой компании)
  • 2. Наши причины (Прототип как инструмент продажи)
  • 3. Сравнение выгод от прототипирования
  • 4. Диаграмма “Ценность прототипа в пресейле”
• Глава 8.3: Типы прототипов. Выбираем подходящий для продажи
  • 1. Ключевые идеи из курса (Классификация прототипов)
  • 2. Наши типы прототипов для пресейла
  • 3. Таблица: Какой прототип для какой задачи?
  • 4. Диаграмма “Выбор прототипа для пресейла”
• Глава 8.4: Техники прототипирования. Как быстро сделать наглядный прототип
  • 1. Ключевые идеи из курса (Разнообразие техник)
  • 2. Наши техники для пресейла
  • 3. Таблица: Техники и их применение
  • 4. Диаграмма “Процесс создания прототипа для пресейла”
• Глава 8.5: Подготовка вопросов. Что спрашивать у клиента при демонстрации прототипа
  • 1. Ключевые идеи из курса (Вопросы для пользовательского тестирования)
  • 2. Наш подход — «Вопросы для согласования»
  • 3. Чек-лист вопросов для демонстрации прототипа клиенту
  • 4. Диаграмма “Цикл обратной связи при демонстрации прототипа”
• Глава 8.6: Процесс демонстрации прототипа. От показа к согласованию
  • 1. Ключевые идеи из курса (Этапы тестирования)
  • 2. Наш процесс — «Демонстрация и согласование»
  • 3. Чек-лист для проведения демонстрации прототипа
  • 4. Диаграмма “Итеративный процесс согласования”
• Глава 9.1: Получение согласия и выравнивание. Наша цель — подписанный контракт
  • 1. Ключевые идеи из курса (Внутреннее согласование)
  • 2. Наша цель — согласие клиента и контракт
  • 3. Ключевые документы для получения «Buy-in» от клиента
  • 4. Диаграмма “От Discovery к контракту”
• Глава 10.1: Непрерывное Discovery. Развитие отношений и допродажи
  • 1. Ключевые идеи из курса (Постоянное улучшение продукта)
  • 2. Наша адаптация — «Развитие проекта и клиента»
  • 3. Применение принципов Discovery после контракта
  • 4. Диаграмма “Цикл развития клиента”
• Глава 11.1: Заключение. Discovery как инструмент успеха
  • 1. Ключевые идеи из курса (Благодарность и пожелания)
  • 2. Наше заключение (Главный вывод для R&D/Presale)
  • 3. Ключевые принципы нашего Discovery (Краткое резюме)
  • 4. Призыв к действию

Глава 1.1: Введение. От теории к практике

1. Ключевые идеи из курса (Взгляд теоретика)

Автор курса представляет Product Discovery как линейный, пошаговый процесс для создания успешных продуктов. Основные этапы, которые он выделяет:

• Определение процесса: Что такое Discovery и зачем он нужен.
• Команда: Кто должен участвовать в процессе.
• Понимание пользователя: Создание портретов (User Persona), карт эмпатии (Empathy Map), проведение интервью для выявления нужд.
• Определение проблемы: Анализ и приоритизация найденных проблем.
• Поиск решений: Использование креативных техник для генерации идей (мозговой штурм, Working-Backward и т.д.).
• Валидация и прототипирование: Создание прототипов и их тестирование с пользователями.
• Согласование: Презентация решения стейкхолдерам.

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

2. Что это значит для нас (Взгляд практика из сервисной компании)

Для нас, как для сервисной компании, цели и акценты в этом процессе кардинально меняются. Мы не ищем “продукт-мечты” для миллионов. Наша задача — решить конкретную бизнес-проблему конкретного клиента с выгодой для нашей компании.

Product Discovery для нас — это в первую очередь инструмент пресейла и управления рисками.

Наши ключевые цели:

1. Продать экспертизу: Мы показываем клиенту, что не просто пишем код, а вникаем в его бизнес и предлагаем оптимальное решение. Это отличает нас от бодишопов.
2. Превратить хаос в порядок: Берем невнятный запрос (“хотим что-то с нейросетями”) и превращаем его в четко очерченный, понятный и оценимый проект.
3. Снизить риски: Заранее выявляем технические и бизнес-проблемы, чтобы не столкнуться с ними в середине проекта. Это защищает и нас, и клиента от провала.
4. Обосновать цену: Результаты Discovery — это прямое доказательство, почему проект стоит именно столько.

Поэтому, проходя этот курс, мысленно заменяйте слово “продукт” на слово “проект”, а “пользователь” на “клиент”.

3. Сравнительная таблица целей

4. Наш основной процесс

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

  flowchart TD
    A[Нечеткий запрос от клиента] --> B{Процесс Discovery: воркшопы, анализ, эскиз архитектуры};
    B --> C[Четко очерченный скоуп работ];
    C --> D[Подготовка документов: КП, SOW];
    D --> E[Подписанный контракт];

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

Глава 2.1: Что такое Product Discovery? Определение для практиков

1. Ключевые идеи из курса (Академическое определение)

Автор определяет Product Discovery как процесс, состоящий из двух ключевых частей:

1. Понять проблемы и нужды пользователей.
2. Проверить (валидировать) идеи решений для этих проблем до начала полноценной разработки.

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

2. Что это такое для нас (Рабочее определение)

В контексте сервисной компании это определение слишком абстрактно. Мы не “ищем проблемы на рынке”, мы работаем с конкретным запросом от конкретного клиента.

Для нас, Product Discovery — это структурированный консалтинговый процесс (часто платный), который превращает бизнес-идею клиента в готовый к реализации проект.

Это не столько “поиск истины”, сколько процесс согласования видения, ожиданий и ограничений между нашей командой и командой клиента. Его главная задача — ответить не на абстрактный вопрос “что делать?”, а на предельно конкретный: “Что именно мы будем делать в рамках этого проекта за эти деньги и в эти сроки?”.

Discovery — это наш способ перевести диалог с клиентом из плоскости “пофантазируем” в плоскость “посчитаем и спланируем”.

3. Сравнение фокусов при оценке рисков

Классическая теория говорит о проверке трех типов рисков. Мы проверяем те же риски, но под другим углом.

4. Диаграмма трансформации запроса

Эта диаграмма иллюстрирует, как Discovery превращает абстракцию в конкретику.

  graph TD
    subgraph "Вход"
        A["Идея или проблема клиента<br><i>(e.g., 'Хотим внедрить GenAI для аналитики')</i>"]
    end
    subgraph "Выход"
        D["Технико-коммерческое предложение<br><i>(Конкретный скоуп, архитектура, смета, план)</i>"]
    end
    A --> B{<strong>Процесс Discovery</strong>};
    B --> C["-Анализ требований<br>-Технические воркшопы<br>-Эскиз архитектуры<br>- Определение скоупа MVP"];
    C --> D;

Таким образом, для нас Product Discovery — это не исследование, а проектирование будущего контракта.

Глава 2.2: Зачем на самом деле нужно Product Discovery?

1. Ключевые идеи из курса (Аргументы для продуктовой компании)

Автор приводит несколько причин, почему необходимо проводить Product Discovery:

• Получить раннюю обратную связь: Проверить соответствие продукта рынку (product-market fit) без больших вложений в разработку.
• Сэкономить ресурсы: Инвестиции в Discovery в десятки раз дешевле, чем исправление ошибок после релиза или создание никому не нужного продукта.
• Быть гибким (Agile): Возможность быстро изменить продукт или даже целевой рынок на основе полученных данных.
• Лучше понимать и доносить ценность: Глубокое понимание нужд пользователя помогает маркетингу лучше продавать продукт и обосновывать его цену.

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

2. Что это дает нам (Аргументы для сервисной компании)

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

Для нас Discovery — это не про то, чтобы сделать “правильный” продукт, а про то, чтобы продать “правильный” проект и не уйти в минус.

Вот наши главные причины:

1. Это инструмент продаж. Discovery — это по сути платная (или как минимум очень ценная) консалтинговая услуга. Она позволяет нам продавать не “часы разработчиков” по низкой ставке, а дорогостоящую экспертизу по решению бизнес-проблем. Результаты Discovery (схемы, аналитика, прототипы) — это прямое обоснование цены будущего контракта.

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

3. Это инструмент фиксации скоупа. Главный враг любого аутсорс-проекта — это “scope creep” (раздувание границ). Discovery позволяет нам вместе с клиентом четко определить и задокументировать, что входит в проект, а что — нет. Этот документ (SOW) — наша главная защита в будущем.

4. Это инструмент построения доверия. Проводя Discovery, мы из простого “исполнителя” превращаемся в “партнера-консультанта”. Клиент видит, что мы вникаем в его проблемы, и начинает доверять нашей экспертизе. Это основа для долгосрочных отношений и будущих допродаж.

3. Сравнение: “До” и “После” внедрения Discovery

4. Диаграмма ценности: два пути пресейла

  graph TD
    subgraph "Путь 1: Пресейл без Discovery"
        A[Запрос клиента] --> B["Быстрая оценка<br>(на глазок)"] --> C["Подписание контракта<br>с размытым скоупом"] --> D["<strong>Высокий риск<br>конфликтов и убытков</strong>"]
    end
    subgraph "Путь 2: Пресейл с Discovery"
        E[Запрос клиента] --> F{"`Процесс Discovery`"} --> G["Четкий скоуп<br>и обоснованная оценка"] --> H["<strong>Подписание выгодного<br>и понятного контракта</strong>"]
    end

Глава 2.3: Процесс Product Discovery. Теория и практика

1. Ключевые идеи из курса (Классический процесс)

Автор курса предлагает простой 8-шаговый процесс, который ведет от сбора команды до поставки решения:

1. Собрать команду для Discovery.
2. Понять нужды пользователя.
3. Определить проблему или потребность.
4. Найти возможные решения.
5. Проверить (валидировать) решения.
6. Создать прототип приоритетного решения.
7. Презентовать решение стейкхолдерам для получения поддержки.
8. Поставить решение (начать разработку).

Этот процесс логичен, но он описывает идеальный мир, где у команды есть время и ресурсы на последовательное выполнение всех шагов.

2. Как этот процесс выглядит у нас (Линейный пресейл-процесс)

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

Вот наши реальные этапы:

1. Квалификация (1-2 дня): Первый контакт с клиентом (звонок, встреча). Наша цель — быстро понять, есть ли у клиента реальная потребность и бюджет, и стоит ли нам вообще вкладывать время в этот пресейл. Это наш фильтр.

2. Сбор данных и воркшопы (1-2 недели): Серия технических встреч с командой клиента. Здесь мы объединяем шаги 2, 3 и 4 из курса: слушаем, задаем вопросы, вытаскиваем требования, ограничения, бизнес-цели и вместе накидываем первые идеи решений.

3. Внутренняя проработка и оценка (1 неделя): Наша команда (Presale/R&D инженер, архитектор) анализирует собранную информацию. Здесь мы делаем то, что в курсе называется “валидация” и “прототипирование”, но на уровне концепции: рисуем верхнеуровневую архитектуру, выбираем стек, определяем границы (скоуп) MVP и делаем предварительную оценку трудозатрат.

4. Подготовка ТКП (3-5 дней): Самый важный этап, которого нет в курсе. Мы упаковываем результаты нашей работы в пакет документов: Коммерческое предложение (КП), Описание работ (SOW), предварительный план проекта.

5. Защита и согласование: Презентуем наше предложение клиенту. Это аналог шага 7 из курса. Наша цель — не просто получить “buy-in” (согласие), а получить подпись на контракте.

3. Сравнение процессов в виде таблицы

4. Наша воронка пресейла

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

 ------------------------------------------------------------+
|                                                            |
|         Входящий запрос от клиента (10)                    |
|                                                            |
+------------------------------------------------------------+
  \                                                         /
   +--------------------------------------------------------+
   |                                                        |
   |    Квалификация (прошли первичный фильтр) (8)          |
   |                                                        |
   +--------------------------------------------------------+
     \                                                    /
      +----------------------------------------------------+
      |                                                    |
      |         Проведены технические воркшопы (5)         |
      |                                                    |
      +----------------------------------------------------+
        \                                                 /
         +------------------------------------------------+
         |                                                |
         |     Подготовлено коммерческое предложение (3)  |
         |                                                |
         +------------------------------------------------+
           \                                            /
            +------------------------------------------+
            |                                          |
            |               Подписан контракт (1)      |
            |                                          |
            +------------------------------------------+

Глава 3.1: Команда для Product Discovery. Роли в сервисной компании

1. Ключевые идеи из курса (Классическая продуктовая команда)

Автор курса предлагает делить команду на две группы:

• Основная команда (Core Team): Это те, кто непосредственно ведет процесс Discovery. Включает в себя:
  • Продакт-менеджера (лидер процесса)
  • UX-дизайнера и исследователя
  • Технического лида
  • Иногда — бизнес-аналитика.
• Группа поддержки (Supporters Team): Стейкхолдеры, которых нужно регулярно информировать и от которых нужно получать данные. Это высшее руководство, другие продуктовые команды, маркетинг и т.д.

Эта модель хорошо работает в больших продуктовых компаниях со сложной структурой.

2. Наша команда (Дуэт Продаж и Технологий)

В реалиях сервисного бизнеса и пресейл-процесса наша команда гораздо компактнее и мобильнее. У нас нет разделения на “основную” и “поддерживающую” команду, у нас есть единая проектная команда пресейла.

В 95% случаев эта команда — связка из двух ключевых фигур:

• Менеджер по продажам (Sales Manager): Наш ответ на “бизнес-стейкхолдера” и “маркетинг”. Он владеет коммерческой частью сделки.
• Presale/R&D Инженер: Наш гибрид “продакт-менеджера”, “техлида” и “бизнес-аналитика”. Он отвечает за техническую и содержательную часть.

Привлекаемые эксперты: Для сложных проектов мы точечно привлекаем:

• Solution Architect: Когда нужна проработка комплексной архитектуры.
• Профильный эксперт: Например, Data Scientist, DevOps-инженер или специалист по IoT, если проект требует глубокой узкоспециализированной экспертизы.

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

3. Роли и обязанности в нашей команде

4. Диаграмма взаимодействия

Эта схема показывает, как распределяются потоки информации в нашей пресейл-команде.

  graph TD
    Client[Клиент]
    Sales[Менеджер по продажам]
    Presale[Presale/R&D Инженер]
    Architect[Solution Architect]

    Client -- Бизнес-запрос, бюджет, сроки --> Sales
    Sales -- Организация встреч, коммерческая часть --> Client
    Sales -- Вводные данные по сделке --> Presale
    Presale -- Технические воркшопы, сбор требований --> Client
    Client -- Техническая информация, ограничения --> Presale
    Architect -- Консультации, утверждение архитектуры --> Presale
    Presale -- Запрос на экспертизу --> Architect
    Presale -- Техническая часть ТКП, оценка --> Sales
    Sales -- Финальное коммерческое предложение --> Client

Глава 4.1: Понимание потребностей. Кого мы на самом деле слушаем?

1. Ключевые идеи из курса (Фокус на конечном пользователе)

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

• Создание портретов (Personas) и карт эмпатии (Empathy Maps).
• Проведение интервью, опросов и фокус-групп.
• Анализ записей сессий и продуктовой аналитики.

Ключевой посыл автора: на этом этапе не нужно пытаться подтвердить свои идеи. Нужно с открытым разумом исследовать проблемы и потребности конечных пользователей (end-users).

2. Наша реальность (Фокус на бизнес-заказчике)

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

Поэтому мы должны четко переопределить объект нашего исследования.

Наш «пользователь» на этапе Discovery — это сам клиент:

• Менеджеры, которые отвечают за KPI.
• Инженеры, которые будут поддерживать решение.
• Маркетологи, которым нужно продавать продукт.
• Руководители, которые выделяют бюджет.

Мы ищем не «боли пользователя» (user pains), а «боли бизнеса» (business pains):

• Где компания теряет деньги?
• Какие процессы неэффективны и почему?
• Какие стратегические цели (KPI) нужно достичь?
• Какие технические ограничения и легаси-системы мешают развитию?

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

3. Сравнение объектов исследования

4. Диаграмма смещения фокуса

Эта диаграмма показывает, как меняется основной объект нашего внимания.

  graph TD
    subgraph "Классический Discovery"
        A(Продукт) --> B(Конечный пользователь)
        B -- "Обратная связь, 'боли'" --> A
    end
    subgraph "Наш Discovery (Пресейл)"
        C(Проектное решение) --> D(<b>Бизнес-заказчик</b>)
        D -- Требования, ограничения, KPI --> C
        D -- косвенно представляет --> E(Конечный пользователь)
        C -.-> E
    end

В следующих разделах мы разберем, как применять конкретные инструменты к нашему главному “пользователю” — клиенту.

Глава 4.2: User Persona. Адаптируем для работы с клиентом

1. Ключевые идеи из курса (Портрет конечного пользователя)

Автор определяет User Persona как полувымышленного персонажа, основанного на исследованиях, который представляет вашего текущего или идеального клиента.

Цели создания User Persona в классическом подходе:

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

Автор предлагает использовать готовые шаблоны, например, в Miro, для создания таких портретов.

2. Наша версия — «Портрет Ключевого Стейкхолдера»

Мы не создаем портреты вымышленных конечных пользователей. Это не имеет смысла, так как мы не можем проверить наши гипотезы о них. Вместо этого мы создаем профили реальных людей в компании клиента, с которыми мы ведем переговоры. Назовем этот инструмент «Портрет Ключевого Стейкхолдера».

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

Этот инструмент помогает нам:

• Лучше готовиться к переговорам.
• Понимать, на каком языке говорить с каждым из участников (техническом, финансовом, бизнес-языке).
• Заранее определять потенциальных противников и союзников проекта внутри компании клиента.
• Формировать наше коммерческое предложение так, чтобы оно отвечало на запросы каждого ключевого стейкхолдера.

3. Шаблон «Портрета Ключевого Стейкхолдера»

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

4. Диаграмма влияния стейкхолдеров

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

  graph TD
    subgraph "Наше Проектное Решение"
        A(Предложение)
    end
    subgraph "Стейкхолдеры клиента"
        B(<b>CEO/Бизнес-лидер</b>)
        C(<b>CTO/Технический директор</b>)
        D(<b>Линейный менеджер/Владелец процесса</b>)
    end
    A -- "Поможет ли это нам заработать больше?" --> B
    A -- "Насколько это надежно и совместимо с нашей инфраструктурой?" --> C
    A -- "Упростит ли это работу моей команды? Уложимся ли в сроки?" --> D

Глава 4.3: Empathy Map. Структурируем информацию от клиента

1. Ключевые идеи из курса (Сопереживание пользователю)

Автор представляет Карту Эмпатии (Empathy Map) как визуальный инструмент, чтобы понять, что пользователь говорит, думает, делает и чувствует. В отличие от User Persona (которая отвечает на вопрос “кто наш пользователь?”), Карта Эмпатии отвечает на вопрос “каков мир нашего пользователя?”.

Классическая карта включает блоки:

• Что он видит (Sees)?
• Что он говорит (Says)?
• Что он делает (Does)?
• Что он слышит (Hears)?
• Что он думает и чувствует (Thinks & Feels), включая его “боли” (Pains) и “цели” (Gains).

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

2. Наша версия — «Карта Воркшопа»

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

Назовем наш аналог «Карта Воркшопа».

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

Мы не пытаемся угадать, что клиент “чувствует”. Мы фиксируем факты, требования, проблемы и цели, которые были озвучены или явно следуют из контекста.

3. Шаблон «Карты Воркшопа»

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

4. Диаграмма трансформации информации

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

  graph TD
    A[Поток информации с воркшопа<br>- Высказывания<br>- Описания процессов<br>- Скрытые опасения<br>- Бизнес-пожелания] --> B{"Применяем структуру<br>«Карты Воркшопа»"};
    B --> C[Структурированные данные<br><b>Требования:</b> Python, интеграция с SAP/Salesforce.<br><b>Процессы as-is:</b> Ручной сбор в Excel.<br><b>Риски:</b> Сопротивление персонала, стоимость поддержки.<br><b>Бизнес-цели:</b> Сократить время на 95%, повысить точность.];
    C --> D[Основа для<br>технического задания и<br>коммерческого предложения];

Глава 4.4: Интервью с клиентом. Как задавать правильные вопросы

1. Ключевые идеи из курса (Вопросы для пользователей)

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

• Всегда иметь цель: Четко понимать, что вы хотите узнать (например, почему низкая конверсия, какие фичи добавить и т.д.).
• Предпочитать интервью опросам: Живое общение дает более глубокое понимание, чем сухие ответы в анкете.
• Говорить с достаточным количеством людей: Не делать выводы на основе мнения одного-двух человек.
• Задавать открытые вопросы: Особенно о прошлом опыте, чтобы избежать фантазий и получить реальные факты.

Этот подход нацелен на исследование рынка и поведения большой группы конечных пользователей.

2. Наш подход — «Технический воркшоп-интервью»

В нашем случае “интервью” — это не исследование, а целенаправленный сбор требований в рамках рабочей встречи (воркшопа). Мы говорим не с сотней анонимных пользователей, а с 3-5 ключевыми стейкхолдерами со стороны клиента, и у нас обычно всего несколько встреч, чтобы получить всю необходимую информацию.

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

Поэтому мы используем комбинацию вопросов:

• Открытые вопросы — чтобы понять общую картину и бизнес-контекст.
• Закрытые и уточняющие вопросы — чтобы получить конкретные факты, цифры и технические детали.

3. Наш чек-лист вопросов для воркшопа с клиентом

Это не исчерпывающий список, а скорее каркас для подготовки к встрече. Вопросы нужно адаптировать под конкретный проект.

4. Диаграмма “Воронка вопросов”

Хороший воркшоп-интервью строится по принципу воронки: от общего к частному.

  graph TD
    A["<b>Начало встречи:</b> общие, открытые вопросы<br><i>'Расскажите о вашей проблеме...'</i><br><i>'Каких целей вы хотите достичь?'</i>"] --> B["<b>Середина:</b> конкретизирующие вопросы о процессах и технологиях<br><i>'А как именно работает этот шаг?'</i><br><i>'Какой протокол использует это API?'</i>"]
    B --> C["<b>Уточняющие вопросы и резюмирование</b><br><i>'Правильно ли я понимаю, что вам нужно...?'</i><br><i>'Итак, ключевые требования это А, Б и В.'</i>"]
    C --> D["<b>Конец встречи:</b> вопросы о дальнейших шагах<br><i>'Кто примет решение?'</i><br><i>'Когда нам ждать ответа?'</i>"]

Глава 4.5: Дополнительные техники. Где еще брать информацию?

1. Ключевые идеи из курса (Анализ данных и конкурентов)

Автор предлагает еще несколько техник для сбора информации о пользователях:

• Записи сессий (Session Recordings): Анализ видеозаписей реальных взаимодействий пользователей с продуктом (сайтом или приложением) для выявления проблемных мест, неэффективных сценариев и точек “затыка”.
• Аналитика данных (Data Analytics): Изучение количественных данных о поведении пользователей (конверсии, отказы, время на странице), чтобы найти аномалии и паттерны.
• Анализ конкурентов (Competitor Analysis): Изучение продуктов конкурентов для поиска идей и понимания рыночных стандартов.

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

2. Наши источники информации

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

• Вместо “Записей сессий” → “Демонстрация экрана”. Мы просим ключевого сотрудника клиента (будущего пользователя системы) в режиме реального времени показать нам, как он сейчас выполняет свою работу. Это “живая” запись сессии, где можно сразу задавать уточняющие вопросы. Это один из самых ценных источников инсайтов.

• Вместо “Продуктовой аналитики” → “Запрос отчетов и выгрузок”. У нас нет доступа к их Google Analytics, но мы можем попросить: “Пришлите, пожалуйста, пример отчета, который вы собираете вручную” или “Можете ли вы сделать выгрузку из базы данных по этим параметрам за последний месяц?”. Эти данные часто показывают реальные проблемы лучше любой аналитики.

• Вместо “Анализа конкурентов” → “Анализ окружения”. Мы анализируем две вещи:

  1. Конкурентов нашего клиента (если это важно для проекта): “А как эту проблему решают ваши конкуренты?”
  2. Наших конкурентов на этом проекте: “Кто еще претендует на этот контракт? Это другая аутсорс-компания или внутренняя команда разработки клиента?” Понимание этого помогает нам правильно позиционировать наше предложение.

• Наши главные “другие техники”:

  1. Изучение документации: Запрашиваем и внимательно читаем все, что есть: старые ТЗ, схемы баз данных, описания API, должностные инструкции. Это кладезь информации.
  2. Технический Proof of Concept (PoC): Если есть критически важная техническая гипотеза (например, “сможем ли мы интегрироваться с их древней ERP-системой?”), мы можем предложить сделать небольшой, изолированный PoC, чтобы проверить ее. Это снимает огромный пласт рисков.

3. Таблица адаптации техник

4. Диаграмма “Наши источники истины”

Для составления качественного коммерческого предложения мы опираемся на информацию из разных источников.

  graph TD
    subgraph "Информация от людей"
        A[Воркшопы и интервью]
    end
    subgraph "Информация из документов"
        B[RFP / ТЗ / Внутренняя документация]
    end
    subgraph "Информация из систем"
        C[Живая демонстрация работы ПО]
        D[Отчеты и выгрузки данных]
    end
    subgraph "Информация от нас (проверка гипотез)"
        E[Результаты нашего PoC]
    end
    A & B & C & D & E --> F{<strong>Полная картина для<br>коммерческого предложения</strong>}

Глава 5.1: Определение проблемы. Формулируем скоуп проекта

1. Ключевые идеи из курса (Поиск и формулировка проблемы)

Автор предлагает следующий процесс для определения проблемы:

1. Собрать все проблемы: Выписать все проблемы, потребности и желания, выявленные на этапе исследования.
2. Найти паттерны: Сгруппировать похожие проблемы, которые упоминались несколькими пользователями.
3. Четко определить: Сформулировать проблему в виде понятного утверждения (Problem Statement).
4. Валидировать: Проверить правильность формулировки с ключевыми стейкхолдерами и клиентами.
5. Приоритизировать: Решить, какие проблемы будут решаться в первую очередь, а какие уйдут в бэклог.

Для этого предлагается использовать различные фреймворки, например, “Jobs to be Done” (JTBD), чтобы структурировать информацию.

2. Наша цель — определить скоуп, а не «проблему»

В нашем контексте этот процесс имеет гораздо более прагматичную цель. Клиент часто приходит с целым списком проблем и “хотелок”. Если мы попытаемся решить их все, проект станет безразмерным и неподъемным.

Поэтому наша задача — не просто “определить проблему”, а определить и согласовать с клиентом границы (scope) первого проекта / MVP.

“Определение проблемы” для нас — это процесс, в ходе которого мы:

1. Выслушиваем все проблемы клиента (собираем требования).
2. Помогаем ему выбрать 1-2 самые критичные проблемы, решение которых даст максимальный эффект в кратчайшие сроки.
3. Формулируем решение этих проблем в виде четкого, ограниченного набора работ.

Хорошо определенный скоуп, особенно раздел “Что НЕ входит в скоуп”, — это наша главная защита от недопонимания, конфликтов и раздувания бюджета в будущем. Это самый важный артефакт этапа Discovery.

3. Шаблон для определения скоупа (Scope Statement)

Это упрощенный шаблон, который можно и нужно включать в каждое коммерческое предложение или SOW (Statement of Work).

4. Диаграмма “Сужение фокуса”

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

  graph TD
    A["<b>Весь список проблем и хотелок клиента:</b><br>- автоматизировать отчеты<br>- мобильное приложение<br>- предсказания на AI<br>- интеграция с 1С<br>- ..."] --> B{Процесс Discovery и приоритизации};
    B --> C["<b>Выбранные проблемы для MVP:</b><br>- Долгий сбор отчетов<br>- Ошибки в данных"];
    C --> D["<b>Четко очерченный скоуп</b><br><i>In Scope:</i> Интеграция с SAP/SF, веб-отчет.<br><i>Out of Scope:</i> Мобильное приложение, AI, 1С."];
    D --> E[Основа для SOW и контракта];

Глава 5.2: Приоритизация. Как договориться с клиентом о MVP

1. Ключевые идеи из курса (Фреймворки для бэклога)

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

В качестве основного инструмента он подробно разбирает фреймворк RICE:

• Reach (Охват): Скольких людей затронет эта фича?
• Impact (Влияние): Насколько сильно она их затронет?
• Confidence (Уверенность): Насколько мы уверены в своих оценках охвата и влияния?
• Effort (Усилия): Сколько времени и ресурсов это займет?

Формула (Reach * Impact * Confidence) / Effort дает скоринговый балл для каждой фичи. Этот подход отлично работает в продуктовых компаниях, где есть доступ к данным и возможность оценить эти параметры.

2. Наша цель — приоритизация для продажи, а не для разработки

Для нас фреймворки вроде RICE избыточны и непрактичны. У нас нет данных для оценки Reach и Impact, а Confidence всегда будет низкой. Наша задача — не составить идеальный бэклог на год, а быстро согласовать с клиентом адекватный скоуп для первого контракта (MVP).

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

Наш главный критерий приоритизации — максимальная видимая ценность для бизнеса клиента при минимальных затратах и рисках (как для нас, так и для него).

3. Адаптация фреймворка MoSCoW для переговоров

Для диалога с клиентом лучше всего подходит простой и понятный фреймворк MoSCoW. Он не требует сложных расчетов и легко воспринимается нетехническими специалистами.

Мы проводим с клиентом воркшоп, где вместе распределяем все его “хотелки” по четырем категориям.

4. Диаграмма “Процесс согласования MVP”

Этот воркшоп — ключевой момент в формировании скоупа. Он превращает разрозненные “хотелки” в структурированный план.

  graph TD
    A["Весь список 'хотелок' клиента"] --> B{"Проводим воркшоп по приоритизации (MoSCoW)"};
    B --> C["<b>Must Have</b><br>(Формирует скоуп для MVP)"];
    B --> D["<b>Should/Could Have</b><br>(Формирует план развития и идеи для будущих контрактов)"];
    B --> E["<b>Won't Have</b><br>(Формирует раздел 'Out of Scope' в контракте)"];
    C & D & E --> F[<strong>Согласованный и понятный план работ</strong>];

Глава 6.1: Поиск решений. От креатива к архитектурному эскизу

1. Ключевые идеи из курса (Время для креатива)

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

Этот подход (дивергентное мышление) направлен на то, чтобы не упустить потенциально лучшее или самое инновационное решение, рассмотрев все возможные варианты.

2. Наша цель — быстро прийти к одному рабочему варианту

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

a) Решают согласованную проблему клиента. б) Вписываются в его ограничения (бюджет, существующая инфраструктура, предпочтения по стеку). в) Являются для нас понятными, оценимыми и прибыльными.

“Решение” для нас на этом этапе — это не детальный проект, а архитектурный эскиз (high-level design). Это схема из нескольких блоков, показывающая основные компоненты системы и как они будут взаимодействовать.

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

3. Сравнение подходов к поиску решения

4. Диаграмма “От проблемы к оценке”

Эта диаграмма показывает наш сфокусированный процесс работы над решением.

  graph TD
    A[Согласованный скоуп MVP] --> B{"Внутренний технический воркшоп<br>(Presale инженер + Solution Architect)"};
    B --> C["<b>Архитектурный эскиз</b><br>(High-level design)<br><i>Основные компоненты и связи</i>"];
    C --> D["Выбор технологического стека"];
    C --> E["Декомпозиция и оценка трудозатрат<br>(человеко-часы)"];
    D & E --> F[<strong>Основа для технической части<br>коммерческого предложения</strong>];

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

Глава 6.2: Мозговой штурм. Проектируем решение вместе с клиентом

1. Ключевые идеи из курса (Классический мозговой штурм)

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

• Правильный состав: Пригласить основную команду, можно — лояльных пользователей и экспертов. Важно — не звать высшее руководство, чтобы люди не боялись высказывать “глупые” идеи.
• Фокус на одной проблеме: Одна сессия — одна проблема.
• Поощрение любых идей: Не критиковать, генерировать как можно больше вариантов, даже самых диких.
• Использовать техники: Например, “тихий мозговой штурм”, когда все сначала пишут идеи на стикерах, а потом обсуждают.

Цель — максимально расширить пространство возможных решений.

2. Наш формат — «Архитектурный воркшоп»

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

Поэтому мы проводим не “мозговой штурм”, а структурированный архитектурный воркшоп. Он может быть как внутренним (только наша команда), так и совместным с техническими специалистами клиента.

Ключевые отличия:

• Цель: Не “много идей”, а один согласованный архитектурный эскиз для оценки.
• Участники: Нам как раз нужны “начальники” — технический директор, ведущий архитектор со стороны клиента. Именно они являются носителями ключевых ограничений и принимают решения.
• Критика: Правило “не критиковать” отменяется. У нас наоборот — конструктивная критика на основе ограничений (бюджет, стек, безопасность, сроки) является главным рабочим инструментом.

3. Правила нашего «Архитектурного воркшопа»

4. Диаграмма “Процесс воркшопа”

  sequenceDiagram
    participant PE as Presale Инженер
    participant Client as Тех. спец. клиента
    PE->>Client: Давайте нарисуем, как это может работать. Вот наши ограничения: стек Python, бюджет $50k.
    loop Совместное проектирование
        PE->>PE: Рисует на доске: [Веб-сервер] -> [База данных]
        Client->>PE: Комментирует: "У нас уже есть кластер PostgreSQL, давайте его использовать. Новый не нужен."
        PE->>PE: Исправляет схему: [Веб-сервер] -> [Существующий PostgreSQL]
        Client->>PE: "А где будет аутентификация? У нас есть свой SSO."
        PE->>PE: Добавляет компонент: [Веб-сервер] -> [Интеграция с SSO]
    end
    PE->>Client: В целом так? Это решает задачу и укладывается в ограничения?
    Client->>PE: Да, похоже на то.
    PE->>PE: Фотографирует доску (фиксирует результат для оценки)

Глава 6.3: Mind Map. Декомпозируем решение для оценки

1. Ключевые идеи из курса (Карта для идей)

Автор представляет Mind Map (интеллект-карту) как визуальный и более увлекательный способ проведения мозгового штурма. Процесс прост:

1. В центре пишется проблема или тема (например, “Увеличить конверсию продукта А”).
2. Участники добавляют ветви с идеями, как можно решить эту проблему (например, “поменять картинки”, “ускорить сайт” и т.д.).

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

2. Наш формат — «Карта работ» (Work Breakdown Structure)

Мы не используем Mind Map для генерации идей. Для нас это неэффективная трата времени на этапе пресейла. Вместо этого мы используем саму визуальную структуру Mind Map для совершенно другой задачи — для декомпозиции уже согласованного архитектурного эскиза.

Наш аналог — это «Карта работ». По сути, это графическое представление Work Breakdown Structure (WBS) — иерархической структуры работ по проекту.

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

3. Пример нашей «Карты работ»

Вот как может выглядеть Mind Map для нашего примера с проектом автоматизации отчетов. Это внутренний документ, который составляет Presale инженер, возможно, консультируясь с тимлидами.

  mindmap
  root((Проект: Автоматизация отчетов))
    ("Backend (120h)")
    ::icon(fa fa-cogs)
      ("API (40h)")
        ("Метод для SAP (16h)")
        ("Метод для Salesforce (16h)")
        ("Метод для выгрузки отчета (8h)")
      ("Worker (56h)")
        ("Сбор данных (24h)")
        ("Трансформация (24h)")
        ("Сохранение в БД (8h)")
      ("База данных (24h)")
        ("Схема таблиц (8h)")
        ("Миграции (16h)")
    ("Frontend (80h)")
      ::icon(fa fa-desktop)
      ("Страница отчета (40h)")
        ("Верстка таблицы (16h)")
        ("Реализация фильтров (24h)")
      ("Аутентификация (40h)")
        ("Интеграция с SSO клиента (40h)")
    ("DevOps (40h)")
      ::icon(fa fa-server)
      ("Настройка CI/CD (24h)")
      ("Развертывание в Staging (8h)")
      ("Развертывание в Production (8h)")

4. От Карты работ к итоговой оценке

Эта карта — прямой путь к смете проекта.

1. Создаем Карту работ: Наш Presale инженер или архитектор строит Mind Map, как в примере выше.
2. Оцениваем каждую ветку: Напротив каждой конечной задачи (“листа”) ставится предварительная оценка в часах.
3. Суммируем: Все оценки по веткам суммируются, давая общую оценку по компонентам (Backend, Frontend) и по всему проекту (в примере: 120 + 80 + 40 = 240 часов).
4. Добавляем буферы: К “чистой” оценке разработки (240ч) добавляется время на тестирование (QA), управление проектом (PM) и буфер на риски. Стандартная практика — добавлять 30-50% к чистой оценке.
   • Пример: 240ч + 40% (96ч) = 336 часов.
5. Получаем итоговую оценку: Эта цифра (336 часов) умножается на нашу внутреннюю ставку и превращается в стоимость проекта в коммерческом предложении.

Глава 6.4: Working Backward. Описываем цели и видение проекта

1. Ключевые идеи из курса (Техника Amazon)

Автор описывает известную технику Amazon “Working Backward” (Работать от обратного). Ее суть в том, чтобы до начала разработки написать внутренний пресс-релиз, анонсирующий запуск уже готового продукта.

Структура пресс-релиза:

• Название продукта.
• Ключевые выгоды в одной строке.
• Саммари: какую проблему решает и как.
• Цитата представителя компании.
• Информация о том, как начать пользоваться.
• Цитата вымышленного довольного клиента.

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

2. Наша адаптация — «Описание будущего решения» в ТКП

Мы, конечно, не пишем пресс-релизы для каждого проекта. Но мы используем саму идею — описать конечный результат так, как будто он уже готов — для формулирования ключевого раздела в нашем технико-коммерческом предложении (ТКП).

Этот раздел можно назвать “Видение и цели проекта” или “Описание предлагаемого решения”.

Его задача — продать идею проекта бизнес-стейкхолдерам клиента (CEO, коммерческому директору — тем, кто выделяет деньги), говоря с ними на языке выгод, а не технических фич. Этот текст должен быть простым, убедительным и коротким.

3. Шаблон «Описания будущего решения»

Этот текст пишется в самом начале ТКП, сразу после указания названия проекта. Он должен “зацепить” читателя и объяснить суть в 5-6 абзацах.

Проект: Автоматизация процесса подготовки ежемесячной отчетности

Для кого: Для руководителей и аналитиков отдела продаж компании “Клиент-Нейм”.

Существующая проблема: В настоящее время сотрудники отдела аналитики тратят до 40 человеко-часов каждый месяц на ручной сбор данных из систем SAP и Salesforce и их сведение в Excel. Этот процесс не только трудоемок, но и подвержен человеческим ошибкам, что может приводить к принятию решений на основе неверных данных.

Предлагаемое решение: Мы предлагаем разработать и внедрить автоматизированную систему “ReportMaster”, которая полностью исключит ручной труд из процесса подготовки отчетов.

Как это будет работать: Уполномоченный сотрудник сможет в любой момент зайти в простой и понятный веб-интерфейс, выбрать необходимый период и одним нажатием кнопки сгенерировать готовый отчет. Система автоматически заберет актуальные данные из SAP и Salesforce, объединит их и представит в виде удобной таблицы, готовой для анализа и выгрузки.

Ключевые выгоды для вашего бизнеса:

• Сокращение трудозатрат на подготовку отчета на 98% (с 40 часов до 1 часа в месяц).
• Повышение точности данных до 100%, исключение риска человеческой ошибки.
• Ускорение принятия решений за счет возможности получать актуальные данные в любой момент, а не ждать конца месяца.

Представьте слова вашего руководителя отдела продаж: “С системой ReportMaster мы перестали тратить время на рутину и наконец-то можем заниматься тем, что действительно важно — анализировать данные и находить новые возможности для роста, будучи уверенными в цифрах, на которые мы смотрим.”

4. Диаграмма “От видения к реализации”

Этот раздел в ТКП — ключевой для получения согласия от бизнес-заказчика.

  graph TD
    A["<b>Описание будущего решения</b><br>(Раздел в ТКП, написанный на языке выгод)"] --> B["Согласование с бизнес-заказчиком (ЛПР)"];
    B -- "Да, это именно то, что нам нужно!" --> C["Подписание контракта"];
    C --> D["Разработка технического решения<br>в полном соответствии<br>с согласованным видением"];

Глава 6.5: Role-Storming. Проверяем наше предложение на прочность

1. Ключевые идеи из курса (Штурм в роли пользователя)

Автор описывает Role-Storming как веселую и интерактивную технику мозгового штурма. Суть в том, что участники перестают быть собой и начинают играть роль определенного пользователя (User Persona).

Цель — раскрепостить участников и заставить их думать с точки зрения клиента. Автор утверждает, что, играя чужую роль, люди с большей вероятностью предлагают нестандартные (“out of the box”) идеи, которые они побоялись бы высказать от своего имени. Этот метод используется для генерации креативных идей по решению проблем пользователя.

2. Наша адаптация — «Предзащита коммерческого предложения»

Мы не играем в “конечных пользователей” и не пытаемся генерировать креативные идеи на этом этапе. Мы используем сам принцип ролевой игры для гораздо более прагматичной цели — для стресс-теста нашего готового коммерческого предложения (ТКП) перед его отправкой клиенту.

Мы проводим внутреннюю встречу, которую называем «Предзащита ТКП». На ней разные члены нашей команды играют роли ключевых стейкхолдеров клиента (технического директора, финансового директора и т.д.).

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

3. Сценарий «Предзащиты ТКП»

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

4. Диаграмма “Цикл усиления предложения”

Эта встреча превращает хороший черновик ТКП в “пуленепробиваемое” предложение.

  graph TD
    A[Черновик коммерческого предложения] --> B{"Проводим внутреннюю<br>предзащиту (Role-Storming)"};
    B --> C["Выявляем слабые места:<br>- неубедительная аргументация<br>- неотвеченные вопросы<br>- неучтенные риски"];
    C --> D["Дорабатываем ТКП:<br>- Усиливаем техническое обоснование<br>- Добавляем раздел FAQ<br>- Корректируем оценку с учетом рисков"];
    D --> E[<strong>Сильное и выверенное<br>коммерческое предложение</strong>];
    E --> F[Уверенная презентация клиенту];

Глава 6.6: Техника “Что, если?”. Выявляем и отрабатываем риски

1. Ключевые идеи из курса (Генерация идей через ограничения)

Автор представляет технику “Что, если…?” (What If) как метод для стимулирования креативности во время мозгового штурма. Команда задает себе гипотетические, часто экстремальные или ограничивающие вопросы, чтобы выйти за рамки привычного мышления.

Примеры вопросов из курса:

• “Что, если мы представим новый, более дешевый продукт?”
• “Что, если у нас будет только 10 секунд, чтобы привлечь внимание клиента?”

Цель — спровоцировать генерацию нестандартных идей и решений.

2. Наша адаптация — «Анализ рисков»

Мы не используем эту технику для фантазирования. Мы применяем ее с прямо противоположной целью: не для поиска идей, а для целенаправленного поиска и анализа потенциальных рисков проекта.

Для нас вопросы “Что, если…?” — это главный инструмент для стресс-тестирования нашего будущего решения и плана проекта. Этот процесс является обязательной частью нашей внутренней проработки перед финализацией оценки и отправкой ТКП клиенту.

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

3. Наш чек-лист вопросов “Что, если?” для анализа рисков

Это внутренний чек-лист для Presale инженера и архитектора на этапе оценки проекта.

4. Диаграмма “От риска к плану”

Этот процесс превращает страхи и неопределенность в конкретные пункты плана и сметы.

  graph TD
    A[Готовый архитектурный эскиз] --> B{"Проводим внутренний<br>анализ рисков 'Что, если...?'"};
    B --> C[Формируем список<br>потенциальных рисков проекта];
    C --> D{Для каждого риска разрабатываем<br>план митигации};
    D --> E["- Добавить время в оценку (буфер)<br>- Провести дополнительное исследование/PoC<br>- Четко прописать в контракте (Out of Scope)<br>- Подготовить план "Б""];
    E --> F[<strong>Надежный план проекта и<br>обоснованная, защищенная смета</strong>];

Глава 7.1: Валидация решения. Защищаем коммерческое предложение

1. Ключевые идеи из курса (Всесторонняя проверка)

Автор рассматривает валидацию решения как многогранный процесс, который идет до создания полноценного прототипа. Он предлагает проверить (валидировать) идею решения с четырех точек зрения:

1. Техническая возможность: Можем ли мы в принципе это построить?
2. Бюджет: Соответствует ли стоимость решения ожиданиям бизнес-стейкхолдеров?
3. Интеграция: Впишется ли это решение в существующий технологический ландшафт компании?
4. Пользовательская ценность: Понравится ли это решение конечным пользователям? (проверяется через интервью и опросы).

Этот подход очень разумен, так как рассматривает не только техническую, но и бизнес-составляющую.

2. Наша валидация — это успешная защита ТКП

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

Решение считается нами “валидным”, если мы получили устное или письменное согласие по всем ключевым пунктам от всех ответственных лиц со стороны клиента.

• Техническая валидация происходит, когда CTO клиента говорит: “Да, эта архитектура выглядит разумно и вписывается в наш ландшафт”.
• Финансовая валидация происходит, когда CFO клиента говорит: “Да, эта цена и условия нас устраивают”.
• Бизнес-валидация (аналог пользовательской) происходит, когда будущий владелец продукта говорит: “Да, это решение закроет наши проблемы”.

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

3. Чек-лист для успешной защиты (валидации) ТКП

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

4. Диаграмма “Процесс валидации ТКП”

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

  graph TD
    A[Готовое ТКП] --> B{Презентация и защита<br>перед всеми стейкхолдерами клиента};
    B -- "Как это будет работать?" --> C[<b>Техническая валидация</b><br>Обсуждаем архитектуру с CTO];
    B -- "Сколько это стоит?" --> D[<b>Финансовая валидация</b><br>Обсуждаем смету и ROI с CFO];
    B -- "Что это нам даст?" --> E[<b>Бизнес-валидация</b><br>Обсуждаем выгоды и сроки с ЛПР];
    C & D & E --> F{Получаем принципиальное согласие<br>от всех ключевых лиц};
    F -- "Да, нас все устраивает" --> G["<strong>Решение валидировано</strong><br>(Контракт уходит на подписание)"];
    F -- "Нужны правки в X" --> A;

Глава 8.1: Прототипирование. Визуализируем идею для клиента

1. Ключевые идеи из курса (Прототип для проверки гипотез)

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

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

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

2. Наша цель — прототип как инструмент продажи

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

Для нас прототип — это мощный инструмент коммуникации и продажи. Его основная задача:

• Сделать идею осязаемой: Перевести абстрактные слова и схемы в нечто, что можно увидеть и потрогать (даже если это просто кликабельный макет).
• Согласовать ожидания: Убедиться, что клиент и мы одинаково понимаем, как будет выглядеть и работать будущее решение.
• Убедить клиента: Показать, что мы не только понимаем его проблему, но и знаем, как ее решить, и можем это наглядно продемонстрировать.
• Снизить риски недопонимания: Лучше показать и получить обратную связь на макете, чем на готовом продукте.

Таким образом, для нас прототип — это не “тест”, а “демонстрация”.

3. Сравнение целей прототипирования

4. Диаграмма “Путь прототипа к контракту”

Эта диаграмма показывает, как прототип становится частью нашего пресейл-процесса.

  graph TD
    A["Идея решения<br>(из архитектурного эскиза)"] --> B{"Создаем прототип<br>(макет, PoC)"};
    B --> C[Демонстрируем прототип<br>ключевым стейкхолдерам клиента];
    C -- "Понятно, это то, что нужно!" --> D[Клиент соглашается с видением];
    D --> E[<strong>Подписание контракта</strong>];
    C -- "Непонятно / Не совсем то" --> B(Итерация прототипа)

Глава 8.2: Зачем использовать прототипирование? Наши причины

1. Ключевые идеи из курса (Причины для продуктовой компании)

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

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

Все эти причины сводятся к снижению рисков разработки и повышению шансов на успех продукта на рынке.

2. Наши причины (Прототип как инструмент продажи)

Для нас, как для сервисной компании, прототипирование имеет совершенно иные, но не менее важные причины. Мы используем прототип не для снижения рисков разработки (это произойдет позже, на этапе проекта), а для снижения рисков продажи и повышения ее эффективности.

Вот наши главные причины использовать прототипирование на пресейле:

1. Ускорение продажи: Прототип позволяет быстрее донести сложную идею до клиента и получить его согласие. Это сокращает цикл сделки, так как клиент быстрее принимает решение.
2. Снижение рисков недопонимания: Слова и схемы могут быть интерпретированы по-разному. Прототип — это визуальный язык, который исключает разночтения и гарантирует, что мы и клиент одинаково понимаем, что будет сделано.
3. Повышение доверия и демонстрация экспертизы: Создание прототипа показывает клиенту нашу серьезность, профессионализм и способность не только говорить, но и делать. Это укрепляет его доверие к нам как к партнеру.
4. Обоснование цены: Когда клиент видит, как будет выглядеть и работать решение, он лучше понимает его ценность и готов платить за нее. Прототип помогает обосновать стоимость проекта.
5. Инструмент для сбора уточняющих требований: В процессе демонстрации прототипа клиент часто сам формулирует новые, более точные требования или замечает нюансы, которые не были озвучены ранее. Это позволяет нам уточнить скоуп до подписания контракта.

3. Сравнение выгод от прототипирования

4. Диаграмма “Ценность прототипа в пресейле”

Эта диаграмма показывает, как прототип становится катализатором для принятия решения клиентом.

  graph TD
    A[Абстрактное описание решения] --> B{Создание прототипа};
    B --> C[Визуализация идеи для клиента];
    C --> D[Согласование ожиданий и устранение недопониманий];
    D --> E[Повышение доверия к нашей экспертизе];
    E --> F[Ускорение процесса принятия решения клиентом];
    F --> G[<strong>Подписание контракта</strong>];

Глава 8.3: Типы прототипов. Выбираем подходящий для продажи

1. Ключевые идеи из курса (Классификация прототипов)

Автор отмечает, что в индустрии нет единой классификации прототипов, но выделяет основные типы:

• Low-fidelity (Низкая детализация): Самый простой и быстрый тип. Обычно это бумажные наброски или простые макеты без функциональности. Цель — быстро проверить концепцию.
• High-fidelity (Высокая детализация): Прототипы, максимально приближенные к финальному продукту по внешнему виду и функциональности. Требуют больше времени и ресурсов.
• Live Data Prototypes: Прототипы, работающие с реальными данными.
• Feasibility Prototypes: Прототипы для проверки технической реализуемости (аналог PoC).

Ключевая мысль: выбор типа прототипа зависит от целей и стадии проекта.

2. Наши типы прототипов для пресейла

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

1. Скетч / Бумажный прототип (Low-fidelity):

   • Описание: Быстрые наброски на бумаге, доске или в Miro. Показывают общую структуру и последовательность экранов.
   • Когда используем: Для внутренних обсуждений, очень ранних идей, или когда нужно быстро зафиксировать логику взаимодействия с клиентом прямо на встрече.
   • Цель: Согласовать общую концепцию, не тратя время на детали.

2. Кликабельный макет (Mid-fidelity):

   • Описание: Интерактивный макет, созданный в специализированных программах (Figma, Axure). Имитирует переходы между экранами, но без реальной логики и данных. Может быть стилизован под будущий UI.
   • Когда используем: Наш основной рабочий инструмент для демонстрации клиенту. Позволяет наглядно показать пользовательский путь, согласовать UI/UX и получить конкретную обратную связь.
   • Цель: Визуализировать пользовательский опыт, согласовать внешний вид и логику взаимодействия.

3. Визуальный макет (High-fidelity):

   • Описание: Полноценный дизайн, максимально приближенный к финальному продукту по внешнему виду, но без функциональности. Часто это просто набор статичных картинок.
   • Когда используем: Редко, только для очень дорогих и сложных проектов, где важен каждый пиксель, или когда клиент очень требователен к дизайну. Требует привлечения дизайнера.
   • Цель: Продать идею через безупречный внешний вид.

4. Технический Proof of Concept (PoC):

   • Описание: Минимально работающий код, демонстрирующий ключевую техническую возможность или интеграцию. Может быть без UI.
   • Когда используем: Когда есть критическая техническая гипотеза, которую нужно проверить до подписания контракта (например, возможность интеграции с уникальной системой клиента, производительность сложного алгоритма).
   • Цель: Снять технические риски, доказать реализуемость решения.

3. Таблица: Какой прототип для какой задачи?

4. Диаграмма “Выбор прототипа для пресейла”

Эта диаграмма поможет быстро определить, какой тип прототипа нужен для конкретной ситуации.

  graph TD
    A[Есть критическая техническая гипотеза,<br>которую нужно проверить?] -- Да --> B[Создаем <b>Технический PoC</b>];
    A -- Нет --> C[Нужна демонстрация UI/UX<br>для согласования с клиентом?];
    C -- Да --> D[Создаем <b>Кликабельный макет</b>];
    C -- Нет --> E[Достаточно <b>Скетча / Бумажного прототипа</b><br>для внутренних целей или быстрой фиксации];
    B --> F[Презентация клиенту];
    D --> F;
    E --> F;

Глава 8.4: Техники прототипирования. Как быстро сделать наглядный прототип

1. Ключевые идеи из курса (Разнообразие техник)

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

• Бумажные прототипы (Paper Prototypes): Самый быстрый и дешевый способ. Используется на ранних стадиях для проверки концепции. Недостаток — отсутствие интерактивности.
• Вайрфреймы (Wireframes): Схематичные макеты, созданные в специализированных программах. Фокусируются на структуре и расположении элементов, без деталей дизайна. Помогают согласовать структуру.
• Мокапы (Mockups): Статичные, но уже визуально проработанные макеты. Показывают, как будет выглядеть интерфейс, но без интерактивности.
• Интерактивные прототипы (Interactive Prototypes): Макеты, имитирующие реальное взаимодействие с продуктом. Позволяют пользователю “потрогать” интерфейс. Требуют больше времени на создание.

Курс подчеркивает, что выбор техники зависит от стадии проекта и требуемой детализации.

2. Наши техники для пресейла

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

1. Скетчинг / Бумажное прототипирование:

   • Описание: Быстрые наброски интерфейса на бумаге, доске или в Miro. Могут быть очень грубыми.
   • Когда используем: Для внутренних обсуждений, фиксации идей на лету во время воркшопа с клиентом. Позволяет быстро проверить, правильно ли мы поняли логику взаимодействия.
   • Инструменты: Бумага, маркеры, Miro, Figma (режим Freehand).

2. Вайрфрейминг (Wireframing):

   • Описание: Схематичные макеты, фокусирующиеся на структуре и расположении элементов интерфейса. Обычно черно-белые, без деталей дизайна.
   • Когда используем: Для согласования структуры и логики интерфейса с клиентом, когда не нужно отвлекать его на цвета и шрифты. Помогает убедиться, что все необходимые элементы присутствуют и расположены логично.
   • Инструменты: Figma, Axure, Balsamiq.

3. Кликабельные макеты (Interactive Mockups):

   • Описание: Интерактивные прототипы, созданные в специализированных программах. Имитируют переходы между экранами, нажатия кнопок, заполнение форм. Могут быть как низкодетализированными (вайрфреймы с интерактивностью), так и высокодетализированными (с элементами дизайна).
   • Когда используем: Наш основной инструмент для демонстрации клиенту. Позволяет наглядно показать пользовательский путь, согласовать UI/UX и получить конкретную обратную связь. Создает ощущение “живого” продукта.
   • Инструменты: Figma (режим Prototype), Axure, Adobe XD.

4. Технический Proof of Concept (PoC):

   • Описание: Минимально работающий код, демонстрирующий ключевую техническую возможность или интеграцию. Может быть без UI или с очень простым UI.
   • Когда используем: Для проверки критических технических гипотез (например, возможность интеграции с уникальной системой клиента, производительность сложного алгоритма, работа с новым оборудованием IoT).
   • Инструменты: Любой язык программирования, IDE, тестовые стенды.

3. Таблица: Техники и их применение

4. Диаграмма “Процесс создания прототипа для пресейла”

  graph TD
    A[Согласованный скоуп и архитектура] --> B{Выбираем технику прототипирования<br>исходя из цели и бюджета пресейла};
    B -- Нужна демонстрация UI/UX? --> C[Создаем <b>Кликабельный макет</b><br>или <b>Вайрфрейм</b>];
    B -- Нужна техническая проверка? --> D[Создаем <b>Технический PoC</b>];
    C --> E[Демонстрация клиенту];
    D --> E;
    E --> F[Получение обратной связи и<br>уточнение требований];

Глава 8.5: Подготовка вопросов. Что спрашивать у клиента при демонстрации прототипа

1. Ключевые идеи из курса (Вопросы для пользовательского тестирования)

Автор подчеркивает важность правильных вопросов для эффективного тестирования прототипов. Он предлагает список из 30 вопросов, разделенных на категории:

• Общее впечатление: Вопросы о первом впечатлении и общем восприятии прототипа.
• Юзабилити-тестирование: Вопросы о простоте использования, навигации, понятности интерфейса.
• Вопросы, специфичные для задачи: Вопросы, связанные с выполнением конкретных сценариев (например, “Пожалуйста, купите продукт из каталога”).

Ключевые рекомендации: не перегружать пользователя вопросами (3-5 вопросов на задачу), фокусироваться на конкретных сценариях. Цель — получить обратную связь для улучшения продукта.

2. Наш подход — «Вопросы для согласования»

Мы не проводим “тестирование” в классическом смысле, так как у нас нет доступа к конечным пользователям. Мы проводим демонстрацию прототипа ключевым стейкхолдерам клиента.

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

Мы задаем вопросы, которые помогают нам:

• Уточнить скоуп: Правильно ли мы поняли функциональность?
• Подтвердить ценность: Видит ли клиент, как это решение поможет его бизнесу?
• Снять возражения: Есть ли что-то, что вызывает сомнения или не устраивает?
• Получить согласие: Готов ли клиент двигаться дальше?

3. Чек-лист вопросов для демонстрации прототипа клиенту

Этот чек-лист поможет вам провести эффективную демонстрацию и получить нужную информацию.

4. Диаграмма “Цикл обратной связи при демонстрации прототипа”

  graph TD
    A[Прототип готов] --> B{Демонстрация клиенту<br>и задаем вопросы};
    B --> C[Получаем обратную связь<br>и уточнения];
    C -- "Все отлично, двигаемся дальше!" --> D[Финализируем ТКП и готовимся к контракту];
    C -- "Нужны правки / Есть новые идеи" --> E[Дорабатываем прототип/решение<br>и/или уточняем скоуп];
    E --> B(Повторная демонстрация при необходимости)

Глава 8.6: Процесс демонстрации прототипа. От показа к согласованию

1. Ключевые идеи из курса (Этапы тестирования)

Автор предлагает 7-шаговый процесс тестирования прототипов, который включает:

1. Определение цели и скоупа тестирования: Что именно мы хотим проверить?
2. Выбор тестировщиков: Кто будет тестировать прототип (идеальная целевая аудитория)?
3. Создание прототипа: Выбор типа и техники прототипирования.
4. Выбор метода тестирования: Как пользователи будут взаимодействовать с прототипом (модерируемое/немодерируемое, удаленное/личное).
5. Проведение тестирования: Непосредственно сессии с пользователями.
6. Анализ результатов: Сбор и интерпретация данных.
7. Итерации: Внесение изменений в прототип/продукт на основе полученной обратной связи.

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

2. Наш процесс — «Демонстрация и согласование»

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

Наш процесс состоит из следующих этапов:

1. Подготовка к демонстрации:

   • Определить цель: Что мы хотим получить от этой демонстрации? (Например, подтверждение логики, согласование UI, снятие технических вопросов).
   • Выбрать прототип: Какой тип прототипа (кликабельный макет, PoC) наилучшим образом соответствует цели.
   • Подготовить вопросы: См. Главу 8.5. Вопросы должны быть направлены на получение конкретной обратной связи и подтверждения.
   • Выбрать участников: Приглашаем ключевых стейкхолдеров клиента, которые принимают решения или являются экспертами в своей области.

2. Проведение демонстрации:

   • Введение: Кратко объясняем, что это за прототип, что он показывает и что мы хотим получить от встречи.
   • Демонстрация: Показываем прототип, даем клиенту возможность “потрогать” его (если интерактивный).
   • Активное слушание: Задаем подготовленные вопросы, внимательно слушаем ответы, фиксируем все комментарии, вопросы и возражения.
   • Фиксация: Делаем заметки, скриншоты, записываем встречу (с разрешения клиента).

3. Анализ и итерации:

   • Внутреннее обсуждение: Наша команда (Presale инженер, Sales Manager, возможно, архитектор) обсуждает полученную обратную связь.
   • Принятие решений: Что из полученного фидбека критично? Что можно учесть? Что выходит за рамки скоупа?
   • Внесение правок: Корректируем прототип, архитектурный эскиз, скоуп или оценку в ТКП.

4. Дальнейшие шаги:

   • Согласование с клиентом: Если были значительные правки, возможно, потребуется повторная демонстрация. Если все хорошо — переходим к финализации ТКП и контракта.

3. Чек-лист для проведения демонстрации прототипа

4. Диаграмма “Итеративный процесс согласования”

  graph TD
    A["Подготовка к демонстрации<br>(Цель, прототип, вопросы)"] --> B{Проведение демонстрации<br>и сбор обратной связи};
    B -- Обратная связь<br>от клиента --> C["Анализ и итерации<br>(Внутреннее обсуждение, корректировка)"];
    C -- "Нужна повторная демонстрация?" --> B;
    C -- "Готово к финализации ТКП" --> D[Финализация ТКП<br>и подготовка к подписанию контракта];

Глава 9.1: Получение согласия и выравнивание. Наша цель — подписанный контракт

1. Ключевые идеи из курса (Внутреннее согласование)

Автор курса описывает этап “Получение согласия и выравнивание” (Get buy-in and alignment) как презентацию разработанного решения внутренним стейкхолдерам компании (руководству, другим отделам) с целью получения бюджета и одобрения на дальнейшую разработку.

Ключевые рекомендации:

• Демонстрировать прототип: Наглядно показать, как будет работать решение.
• Опираться на данные: Представлять количественные и качественные данные, полученные в ходе исследования и тестирования.
• Фокусироваться на бизнес-влиянии: Объяснять, как решение повлияет на ключевые метрики компании (например, рост использования продукта, продление лицензий).

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

2. Наша цель — согласие клиента и контракт

Для нас “получение согласия” — это не внутренний процесс, а финальный этап пресейла, направленный на получение официального согласия от клиента на наше предложение. Конечная цель этого этапа — подписанный контракт.

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

Мы используем все наработки предыдущих этапов Discovery (понимание проблемы, архитектурный эскиз, оценка, прототип) для создания убедительного пакета документов и проведения финальной презентации.

3. Ключевые документы для получения «Buy-in» от клиента

Результатом этапа Discovery является не просто идея, а пакет документов, который клиент может изучить и подписать.

4. Диаграмма “От Discovery к контракту”

Эта диаграмма показывает, как все этапы Discovery ведут к финальному результату — подписанному контракту.

  graph TD
    A[Результаты Discovery:<br>- Согласованный скоуп<br>- Архитектурный эскиз<br>- Оценка трудозатрат<br>- Прототип] --> B{Подготовка пакета документов};
    B --> C["Коммерческое предложение (КП)"];
    B --> D["Statement of Work (SOW)"];
    B --> E[План проекта];
    C & D & E --> F{Презентация и согласование<br>с клиентом};
    F --> G[<strong>Подписание контракта</strong>];

Глава 10.1: Непрерывное Discovery. Развитие отношений и допродажи

1. Ключевые идеи из курса (Постоянное улучшение продукта)

Автор курса вводит концепцию “Непрерывного Discovery” (Continuous Discovery). Основная идея заключается в том, что процесс Discovery не заканчивается после начала разработки продукта. Напротив, это постоянный цикл, в котором продуктовые команды продолжают искать новую информацию о потребностях пользователей, даже когда продукт уже создается или даже запущен.

Цели непрерывного Discovery:

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

Это позволяет продукту постоянно развиваться и оставаться актуальным на рынке.

2. Наша адаптация — «Развитие проекта и клиента»

Для нас, как для сервисной компании, концепция “непрерывного Discovery” трансформируется в постоянное развитие отношений с клиентом и поиск возможностей для расширения сотрудничества.

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

• Управление изменениями (Change Requests): Любой запрос клиента на изменение или добавление функционала — это мини-цикл Discovery. Мы понимаем потребность, оцениваем решение, согласовываем скоуп и стоимость.
• Допродажи (Upsale/Cross-sale): Постоянное взаимодействие с клиентом позволяет выявлять новые “боли” и задачи, которые могут стать основой для новых проектов или расширения текущего контракта.
• Укрепление партнерских отношений: Мы остаемся для клиента не просто “исполнителем”, а стратегическим партнером, который постоянно ищет пути для улучшения его бизнеса.

Таким образом, “непрерывное Discovery” для нас — это непрерывный процесс развития клиента и проекта.

3. Применение принципов Discovery после контракта

Те же принципы, которые мы использовали на пресейле, применимы и после подписания контракта.

4. Диаграмма “Цикл развития клиента”

Эта диаграмма показывает, что подписание контракта — это не конец, а начало нового цикла взаимодействия.

  graph TD
    A[Подписанный контракт] --> B{Реализация проекта};
    B --> C{"Постоянное взаимодействие с клиентом<br>(PM, Account Manager)"};
    C -- Выявление новых потребностей<br>и возможностей --> D["Новый цикл Discovery<br>(для допродаж, новых проектов)"];
    D --> E[Новый контракт / Доп. соглашение];
    E --> B;

Глава 11.1: Заключение. Discovery как инструмент успеха

1. Ключевые идеи из курса (Благодарность и пожелания)

Автор курса благодарит за прохождение обучения и выражает уверенность, что теперь у вас есть все необходимые навыки для проведения Product Discovery. Он признает, что первый опыт может быть волнительным, но призывает применять полученные знания на практике, обещая, что только так можно стать экспертом. Автор также просит оставить отзыв о курсе.

2. Наше заключение (Главный вывод для R&D/Presale)

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

Главный вывод: Product Discovery для нас — это не просто модный термин из мира стартапов, а жизненно важный инструмент для сервисной компании. Это не про абстрактное “создание продукта”, а про конкретные шаги к успешной продаже и реализации проекта.

Используя принципы Discovery, вы сможете:

• Продавать не “часы”, а решения: Позиционировать себя как эксперта, способного решить бизнес-проблемы клиента.
• Строить долгосрочные отношения: Завоевывать доверие клиента, становясь для него стратегическим партнером.
• Избегать убыточных проектов: Минимизировать риски недопонимания, раздувания скоупа и технических проблем.
• Повышать прибыльность: Обосновывать стоимость своих услуг и заключать более выгодные контракты.

3. Ключевые принципы нашего Discovery (Краткое резюме)

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

• Фокус на клиенте: Наш “пользователь” на этапе пресейла — это бизнес-заказчик. Мы решаем его проблемы и отвечаем на его вопросы.
• Прагматизм: Цель — продать проект, а не найти идеальное решение. Мы ищем “достаточно хорошее” решение, которое можно оценить и реализовать.
• Скоуп — наше всё: Четкое определение “In Scope” и “Out of Scope” — наша главная защита от недопонимания и конфликтов.
• Прототип — инструмент продажи: Визуализация идеи помогает согласовать ожидания и убедить клиента.
• Риски — это возможности: Мы активно выявляем риски и закладываем их в план и смету, превращая потенциальные проблемы в контролируемые факторы.
• Контракт — главный KPI: Все наши усилия на этапе Discovery ведут к подписанию юридически обязывающего документа.

4. Призыв к действию

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

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

Удачи вам в ваших проектах! Пусть каждый Discovery заканчивается подписанным контрактом и довольным клиентом.