Встреча — инструмент управления, а не обязанность
Встреча оправдана только тогда, когда нельзя решить вопрос письменно. Хорошая встреча коротка, результативна и не требует продолжения. Всё, о чём договорились — зафиксировано письменно до того, как все разошлись.
Правило перед тем, как назначить встречу:
Можно ли решить это письменным сообщением? → Пишем, не встречаемся
Нужно ли присутствие всех приглашённых? → Приглашаем только тех, без кого нельзя
Ясна ли цель встречи одним предложением? → Если нет, встреча не готова
Подготовка: без этого встреча не начинается
Лучшие команды мира — от Amazon до McKinsey — единодушны: встреча готовится заранее. Участник, который пришёл «посмотреть что будет», крадёт время у всех остальных.
Обязательно до встречи:
· Цель встречи сформулирована одним предложением и отправлена всем участникам
· Повестка с временными блоками готова за 24 часа до встречи
· Материалы для обсуждения отправлены заранее — не открываются впервые на встрече
· Каждый участник знает, зачем он приглашён и какова его роль
- Участники пришли подготовленными — материалы прочитаны заранее
- Начало — секунда в секунду. Опоздание не ждут
- Роли определены: ведущий, секретарь, участники
- Первые 10 минут — объяснение, зачем все собрались
- Материалы открываются и читаются прямо на встрече
- Приглашены все «на всякий случай»
Правила хорошего тона на встрече
Культура встреч — зеркало культуры организации. То, что считается нормой за столом переговоров, становится нормой в работе. Эти правила не про вежливость — про уважение к времени и вниманию друг друга.
- Телефон убран или переведён в беззвучный режим
- Говорит один человек — остальные слушают
- Несогласие выражается вопросом, а не перебиванием
- Если тема уходит в сторону — ведущий возвращает к повестке
- Решения проверяются вслух: «Правильно ли я понял, что…»
- Время регламента соблюдается — ведущий следит за часами
- Работаем в ноутбуке параллельно с обсуждением
- Перебиваем говорящего или договариваем за него
- Принимаем решения без тех, кто должен был участвовать
- Уходим с встречи без понимания следующего шага
- Обсуждаем детали, которые касаются только двух человек
Форматы встреч и их назначение
Каждый тип встречи решает одну задачу. Смешивать форматы — значит не решать ни одну. Ежедневный стендап не место для обсуждения архитектуры. Стратегическая сессия не место для оперативных вопросов.
Ежедневный стендап — 15 минут стоя:
Что сделал вчера · Что делаю сегодня · Что мешает
Детальные обсуждения — после стендапа, отдельно
Рабочая встреча — 30–60 минут:
Один вопрос, одно решение, один ответственный на выходе
Показ результата клиенту — 45–90 минут:
Живой продукт · Сценарий пользователя · Явное «принято» в финале
Стратегическая сессия — 2–4 часа:
Подготовка за неделю · Фасилитатор · Письменные итоги в тот же день
Протокол встречи: стандарт записи
Протокол — не стенограмма. Это минимальная структура, которая позволяет любому, кто не присутствовал, понять что решили и что теперь делать. Пишется во время встречи, отправляется в тот же день.
Структура протокола:
Дата · Участники · Цель встречи
──
Решения (каждое отдельной строкой)
Задачи: что · кто · до когда
Открытые вопросы: что осталось нерешённым · кто разбирается
Следующий шаг: конкретное действие · дата · ответственный
- Протокол отправлен участникам до конца рабочего дня
- Каждая задача имеет имя и дату — не «команда» и не «скоро»
- Участники подтвердили получение и согласие с протоколом
- Протокол написан через неделю по памяти
- Задачи записаны без ответственного и без срока
- Встреча завершилась — никто не знает, что делать дальше
Статусный срез и итоговое демо
Два особых формата с чёткими правилами. Статусный срез — для синхронизации в процессе. Итоговое демо — для получения решения. Итоговое демо без явного «принято» или «не принято» — не состоялось.
Статусный срез — 15–20 минут:
Что сделано с прошлого раза · Что показываем сейчас · Риски и блокеры · Следующий шаг
Итоговое демо — 30–45 минут:
Цель релиза → Живой сценарий пользователя → Соответствие цели → Ограничения версии → «Принято?» — ждём ответа
Три правила любого демо:
1. Говорим о пользователе, а не о команде
2. Молчание во время показа запрещено — каждый экран комментируется
3. Закрытый вопрос в финале: «Принято?» — и ждём явного ответа
Жизненный цикл проекта — от первого разговора до сдачи
Каждый проект проходит через восемь этапов. На каждом — конкретный ответственный, конкретный результат и конкретный документ. Без артефакта этап не считается завершённым.
Правило перехода между этапами:
Следующий этап начинается только после того, как результат предыдущего зафиксирован письменно и согласован всеми участниками.
Устная договорённость — не результат этапа.
Интервью с клиентом
Первая встреча — не презентация возможностей, а глубокое исследование задачи клиента. Мы слушаем, а не рассказываем. Цель — понять контекст, ограничения и критерии успеха глазами клиента.
Ответственный: Аналитик + Руководитель проекта
Результат этапа: Заполненный опросник «Образ результата» · Краткий отчёт о задачах и ожиданиях клиента · Согласованный с клиентом список открытых вопросов
- Итог интервью отправлен клиенту на проверку в тот же день
- Клиент подтвердил, что его поняли правильно
- Определены все участники со стороны клиента
- Встреча прошла, письменного итога нет
- Команда начала обсуждать решение до понимания задачи
- Клиент не знает, что будет следующим шагом
Сбор и фиксация требований
Аналитик переводит слова клиента в структурированные истории пользователей. Каждое требование получает контекст, критерии проверки и согласование клиента. Без этого шага команда строит не то.
Ответственный: Аналитик
Результат этапа: Реестр историй пользователей с критериями приёмки · Карта зависимостей · Глоссарий терминов проекта · Подтверждение клиента
- Каждое требование — история пользователя с ролью и ценностью
- Клиент прочитал реестр и поставил подпись или дал письменное согласие
- Противоречия между требованиями выявлены и разрешены
- Требования зафиксированы как технические задачи без контекста
- Клиент не видел финальный список требований
- Нет критериев: как понять, что требование выполнено
Формирование рабочей группы
Под конкретный проект собирается команда с чёткими ролями и зонами ответственности. Каждый участник знает свой вклад, точки передачи и критерий своего результата. Неназначенная ответственность — это брошенная ответственность.
Ответственный: Руководитель проекта
Результат этапа: Матрица ответственности (кто · что · к кому передаёт) · Устав команды · Коммуникационный план · Согласованные правила работы
- Каждая роль знает свои входы, выходы и границы
- Определён единственный ответственный за итоговый результат
- Клиент знает, кто его основной контакт в команде
- Все отвечают за всё — значит, никто ни за что
- Участник узнал о своей роли в проекте в разгаре работы
- Нет договорённости о том, как принимаются решения внутри команды
Проектное решение и архитектура
Команда разрабатывает концепцию решения: как технически реализовать требования, какие ограничения учесть, какие альтернативы рассмотрены. Решение согласовывается с клиентом до начала разработки.
Ответственный: Технический руководитель + Аналитик
Результат этапа: Описание архитектуры решения · Оценка трудозатрат · Технические риски · Согласованные ограничения объёма · Одобрение клиента
- Решение объяснено клиенту языком результата, а не технологий
- Явно названо, что НЕ входит в объём и почему
- Клиент понимает, как решение соответствует его задаче
- Архитектура согласована внутри команды, но не с клиентом
- Границы объёма размыты — «доработаем по ходу»
- Технические риски не названы до начала разработки
Планирование и запуск
Формируется детальный план с контрольными точками, датами и ответственными. Клиент получает дорожную карту и понимает, когда и что увидит. Запуск фиксируется официально.
Ответственный: Руководитель проекта
Результат этапа: Дорожная карта с контрольными точками · Цель первого релиза · Даты промежуточных показов · Согласованный бюджет и ресурсы · Протокол запуска
Разработка и промежуточные показы
Работа ведётся итерациями. В конце каждой итерации — показ клиенту. Не «почти готово», а работающий результат. Обратная связь клиента входит в следующую итерацию.
Ответственный: Команда разработки · Владелец продукта (показы)
Результат каждой итерации: Рабочий прирост функциональности · Протокол показа · Обновлённый список задач · Статус по дорожной карте
- Показ идёт на живом продукте, а не на макетах
- Каждый показ заканчивается явным решением: принято / доработать
- Риски называются клиенту немедленно, а не в день сдачи
- Клиент видит результат только в конце проекта
- Команда «доделывает» за час до показа
- Обратная связь клиента теряется и не фиксируется
Тестирование и приёмка
Система проверяется по критериям, согласованным ещё на этапе требований. Клиент участвует в приёмочном тестировании. Только после явного подтверждения — переход к сдаче.
Ответственный: Специалист по качеству + Аналитик + Клиент
Результат этапа: Протокол тестирования · Закрытый реестр замечаний · Акт приёмки подписан клиентом · Документация для пользователей готова
- Тестирование идёт по сценариям из реальной работы клиента
- Каждое замечание имеет статус и срок устранения
- Клиент подтвердил, что его ожидания выполнены
- Тестирование провела только команда — клиент не участвовал
- Замечания зафиксированы, но без ответственного и срока
- Акт приёмки подписан до закрытия всех критичных замечаний
Сдача и передача в эксплуатацию
Финальный этап — не конец работы, а начало жизни продукта. Клиент и его команда обучены, документация передана, поддержка организована. Проект закрывается только после того, как клиент уверенно работает самостоятельно.
Ответственный: Руководитель проекта + Аналитик
Результат этапа: Обучение пользователей проведено · Документация передана · Поддержка организована · Итоговый отчёт по проекту · Разбор полётов с командой
Правила работы в проекте
Независимо от этапа — несколько правил, которые действуют всегда. Они не про технологии. Они про то, как мы относимся друг к другу и к работе.
- Каждое решение фиксируется письменно — устное не существует
- Плохая новость сообщается сразу, а не перед дедлайном
- Изменение объёма согласовывается до начала работ, а не после
- Каждая задача имеет ответственного и срок — иначе она не задача
- Клиент получает обратную связь о прогрессе минимум раз в неделю
- Начинать следующий этап без подписанного результата предыдущего
- Делать дополнительную работу без письменного согласования
- Скрывать риск или задержку «чтобы не расстраивать клиента»
- Считать задачу выполненной без проверки клиентом или критериями
- Обещать сроки без согласования с командой
Роль — это партия, а не должность
Роль имеет смысл, когда у неё есть вклад, границы, связи и результат. Действие роли оценивается не по занятости, а по тому, как оно усиливает целое.
Роль знает: что на входе → что делает → что на выходе → кто зависит от результата
Владелец продукта
владелец продукта отвечает за смысл релиза, демонстрацию ценности и связь с бизнес-целями. Он не просто ставит задачи — он переводит потребность в исполняемую логику.
- Формулирует цель релиза как изменение в поведении пользователя
- Готовит и проводит демо — показывает ценность, а не занятость команды
- Называет риски до того, как они стали проблемой
- Не принимает статус «готово» без сценария проверки
Разработчик
Разработчик отвечает за качество кода и за то, чтобы техническое решение отвечало на пользовательскую потребность — не только на постановку задачи.
- Уточняет цель до начала работы, а не после
- Сообщает о блокерах до дедлайна, не в день сдачи
- Код можно проверить и воспроизвести без автора
- Техническая сложность не оправдывает непонятность результата
Аналитик
Аналитик переводит потребность клиента или бизнеса в структуру: процесс, событие, роль, правило, артефакт. Он работает на стыке замысла и исполнения.
- Требование описано через сценарий, а не через список функций
- Документ понятен без автора рядом
- Граница между «входит в релиз» и «не входит» явная и согласована
- Обратная связь клиента попадает в продуктовую логику
От идеи — к первому результату
Требования не возникают сами. Их добывают, структурируют и передают по цепочке. Каждый участник отвечает за своё звено: превратить то, что получил, в понятный и проверяемый результат для следующего.
Цепочка ответственности:
Клиент формулирует задачи и желаемый результат
Аналитик переводит в структурированные истории пользователей
Владелец продукта приоритизирует в список задач релиза с целью
Команда декомпозирует в конкретные задачи с оценкой сложности
Релиз доставляет измеримый результат клиенту
Опросник: образ результата
Перед началом работы аналитик проводит структурированную сессию с клиентом. Цель — понять не «что хочет клиент», а «какую задачу он решает и каким видит успех». Ниже — ключевые вопросы для формирования образа результата.
Блок 1 — Текущая ситуация
· Опишите, как выглядит ваша работа сейчас — что происходит от начала до конца?
· Где чаще всего возникают задержки, повторения или потери информации?
· Что вы делаете вручную и хотели бы перестать делать?
· Как сейчас выглядит «хороший результат» — как вы понимаете, что всё сделано правильно?
Блок 2 — Желаемый результат
· Представьте, что прошло полгода и система работает идеально. Что изменилось в вашей работе?
· Что вы хотите видеть в первую очередь — сразу после запуска?
· Какой результат вы назовёте успехом через 3 месяца после внедрения?
· Есть ли результат, который вы точно не хотите получить?
Блок 3 — Ограничения и контекст
· Кто будет пользоваться системой — какие у них роли и уровень технической подготовки?
· С какими другими системами или процессами должна быть связана новая система?
· Что нельзя менять — какие процессы, правила или системы должны остаться как есть?
· Есть ли жёсткие сроки или внешние зависимости, которые влияют на проект?
Блок 4 — Приоритеты
· Если бы можно было сделать только одну вещь — что это было бы?
· Расставьте в порядке важности: скорость внедрения / полнота функций / надёжность / простота
· Кто в вашей компании должен одобрить результат и по каким критериям?
Шаг 1 — Сбор требований
Аналитик проводит структурированные сессии с клиентом. Цель — услышать и зафиксировать задачи и контекст так, чтобы потом точно передать их команде.
Форматы сбора: интервью по задачам клиента · наблюдение за текущим процессом · анализ используемых инструментов · разбор повторяющихся трудностей · совместное описание идеального состояния
- Аналитик задаёт вопросы «зачем» и «что изменится», а не «что добавить»
- Клиент описывает сценарий своими словами — аналитик записывает дословно
- Итоги сессии отправлены клиенту на проверку и подтверждение
- Аналитик пришёл с готовым решением вместо открытых вопросов
- Требования записаны в форме функций, а не потребностей клиента
- Клиент не подтвердил итог сессии
Шаг 2 — История пользователя
Каждое требование оформляется как история пользователя. Это не техническое задание — это обещание пользователю, упакованное в формат, понятный всей команде.
Формула истории пользователя:
Как [роль пользователя], я хочу [что сделать],
чтобы [какой результат получить]
Пример: Как менеджер по работе с клиентами, я хочу видеть все договорённости по клиенту в одном месте, чтобы не терять обещания между встречами.
Критерии приёмки:
Дано [с чего начинается сценарий] · Когда [что делает пользователь] · Тогда [что происходит в системе]
Критерии завершённости: разработано · проверено · принято владельцем продукта · задокументировано
- История написана языком пользователя, а не разработчика
- Критерии приёмки позволяют однозначно сказать «сделано»
- История умещается в один рабочий спринт
- «Добавить кнопку» — нет роли, нет ценности, нет контекста
- Критерии приёмки отсутствуют или написаны технически
- Одна история занимает весь спринт — нужно разбить
Шаг 3 — Передача владельцу продукта
Аналитик передаёт структурированный пакет требований. Владелец продукта проверяет соответствие стратегии, расставляет приоритеты и формирует список задач для релиза.
Пакет передачи: аналитик → владелец продукта
— Реестр историй пользователей с критериями приёмки
— Карта зависимостей между историями
— Первичная оценка сложности
— Открытые вопросы и риски
— Подтверждение клиента (подпись или запись сессии)
- Владелец продукта понимает каждую историю без помощи аналитика
- Зависимости между историями явно обозначены
- Самая важная история определена и войдёт в первый спринт
- Владелец продукта получил список задач без контекста
- Аналитик «устно объяснял» — письменного документа нет
- Требования не подтверждены клиентом
Шаг 4 — Приоритизация и список задач релиза
Владелец продукта расставляет приоритеты по ценности для пользователя и трудозатратам команды. Формируется список задач ближайшего релиза. Остальное — в общем списке для будущих циклов.
Матрица приоритетов:
Высокая ценность + Низкие затраты → делать в первую очередь
Высокая ценность + Высокие затраты → планировать и разбивать на части
Низкая ценность + Низкие затраты → делать при наличии ресурса
Низкая ценность + Высокие затраты → не делать
Шаг 5 — Передача команде: уточнение задач
Владелец продукта передаёт приоритизированный список команде на сессии уточнения. Команда задаёт вопросы, уточняет критерии, разбивает крупные истории и оценивает сложность в командном голосовании.
Правило разбивки: история с оценкой выше 13 → обязательно разделить
Оценка сложности: командное голосование по шкале 1-2-3-5-8-13
Результат уточнения: топ-15 историй детально проработаны и готовы к спринту
- Каждый в команде может объяснить историю своими словами
- Оценка сложности — согласие команды, а не решение руководителя
- Технические зависимости названы до начала спринта
- Команда узнаёт о задаче в день начала спринта
- Оценку проставил руководитель единолично
- «Разберёмся по ходу» — нет критериев до начала работы
Этап 1 — Цель релиза и бэклог
Релиз начинается с одного измеримого предложения. Не списка задач, не набора функций — а изменения в реальности пользователя. Если цель нельзя измерить — релиз нельзя запускать.
Формула Цель релиза:
«[Результат для пользователя] к [дата],
измеренный через [показатель],
для [целевой сегмент]»
Пример: «Сократить время онбординга с 14 до 5 дней к 30 сентября, измеренное средним временем прохождения, для B2B Enterprise»
- Цель — одно предложение с датой и метрикой
- Не более 3 стратегических фокусов на релиз
- Каждая задача бэклога связана с одним из фокусов
- «Улучшить продукт» — не цель релиза
- Бэклог сформирован до цели, а не после
- Задачи из разных направлений без общей логики
Этап 2–3 — Планирование и кик-офф
Совещание по планированию релиза — 4–8 часов. Вся команда + заказчики. Результат — письменный план с датами заморозок. Кик-офф на следующий день: публичное объявление целей.
Формула ёмкости спринта:
Доступные SP = скорость команды × количество спринтов × 0.80–0.85 (резерв 15–20%)
Обязательные даты: Заморозка функций = за 2 спринта до выпуска · Заморозка кода = за 1 спринт до выпуска
Этап 4–5 — Спринты и стабилизация
Разработка идёт итерациями по 2 недели. Каждый спринт заканчивается демо. График сгорания задач виден всей команде в рабочее время. Последний спринт — только тестирование, никаких новых функций.
Ритм спринта:
Ежедневно до 11:00 → стендап 15 мин: вчера · сегодня · блокеры
Середина спринта → уточнение задач 1–2 ч: уточнение следующих задач
Конец спринта → Review 1–2 ч: демо · Разбор полётов 1 ч: Продолжить / Прекратить / Начать
Стабилизирующий спринт: Заморозка функций пройден · только bug fix · тест откат к предыдущей версии за <10 мин
- график сгорания обновлён до 11:00 каждый день
- Блокер устраняется руководитель командыом в день обнаружения
- Изменение скоупа — только письменно, с компенсацией 1:1
- график сгорания не обновлялся 2 дня — никто не заметил
- В последний спринт добавили «незадачашую задачу»
- Ретроспектива отменена из-за нехватки времени
Этап 6 — Решение о выпуске
За 2–3 дня до выпуска. Руководитель команды + минимум один заказчик. Финальная проверка готовности по чек-листу: выпускаем или переносим. Решение перенести — не провал, а ответственность за качество.
Выпуск блокируют (без исключений):
— Нерешённые критические ошибки
— Не проверен откат к предыдущей версии
— Не назначен дежурный на сутки после выпуска
— Заказчики не уведомлены о дате и времени
— Выпуск запланирован в пятницу после 15:00
Этап 7 — Итоговое демо и выпуск
Развёртывание во вторник–четверг до 15:00. Мониторинг 48–72 часа. Итоговое демо — живой сценарий клиента, не слайды. Цель — получить явное «Принято». Без решения — демо не состоялось.
Структура итогового демо:
Контекст и цель релиза (5 мин) →
Живой сценарий пользователя (15–20 мин) →
Соответствие Цель релиза и метрикам (5 мин) →
Ограничения версии — честно (3 мин) →
«Принято?» — ждём явного ответа
- Показываем живой продукт, а не скриншоты
- Цель релиза зачитывается в начале и сверяется в конце
- После демо у клиента одно чёткое понимание результата
- Демо — набор слайдов без живого продукта
- Встреча завершилась без решения «принято / не принято»
- Метрики релиза не сравнили с целью
Этап 8–9 — Мониторинг и ретроспектива
48–72 часа после выпуска: дежурный следит за метриками. Не позднее 72 часов — разбор полётов. Письменный отчёт с конкретными улучшениями, исполнителями и сроками.
Критерии стабильности после выпуска:
Error rate < 1% · Latency ≤ baseline × 1.1 · Конверсия ≥ baseline
Триггер откат к предыдущей версии: Error rate > 5% в течение 30 мин или критический сбой > 20% пользователей
Формат ретроспективы (четыре вопроса):
Удалось · Узнали · Не хватало · Хотелось бы → 3–5 улучшений с именем и датой
Общий язык команды
Когда одно слово значит разное для разных людей — возникают ошибки, задержки и недовольство. Этот глоссарий — не академический словарь, а рабочая договорённость: что мы имеем в виду, когда произносим эти слова в нашей команде.
Базовые понятия
Продуктовое мышление
Гибкая разработка
Agile — это не методология и не набор инструментов. Это способ мышления: ценность — через работающий продукт, а не документы; люди — важнее процессов; реакция на изменения — важнее следования плану. Scrum — один из способов работать по принципам Agile.