Проект и продукт: рабочая система

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

Проект, продукт и процесс

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

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

Ответственность ролей

Продакт

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

Проджект

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

Владелец бизнеса или заказчик

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

Команда

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

Роль — это ответственность, а не должность. Для каждого решения должен существовать один понятный владелец.

Цикл работы

01. Зафиксируйте проблему

Опишите наблюдаемое текущее состояние, кого оно касается и почему действовать нужно сейчас.

Плохо: «Нужно внедрить CRM».

Лучше: «Запросы из Telegram остаются в личных чатах; руководитель не видит следующий шаг и часть обращений теряется».

02. Определите результат

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

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

03. Назначьте владельца

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

04. Выберите первый объём

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

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

05. Выполните и покажите

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

06. Примите результат

Приёмка сверяет результат с заранее записанными критериями. Новое пожелание не маскируется под дефект: оно попадает в отдельное решение об изменении объёма.

07. Измерьте и решите

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

Минимальные артефакты

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

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

Хорошая задача

Карточка задачи должна позволить другому человеку начать работу без пересказа в личном чате.

Минимум:

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

Задача «исправить CRM» не готова к работе. Задача «сохранять источник Telegram для нового лида и показать его в карточке; старые лиды не изменять» задаёт проверяемый результат и границы.

Как выбирать подход

Последовательный

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

Нужны: согласованные границы, план вех, управление изменениями и формальная приёмка.

Итерационный

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

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

Потоковый

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

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

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

Приоритет без магии

Перед началом элемента ответьте:

1. Какой результат или риск он меняет?
2. Для кого и насколько сильно?
3. На каких фактах основана уверенность?
4. Сколько времени и дефицитных ресурсов потребуется?
5. Что мы не сделаем, если выберем его?

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

Риски и изменения

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

Для значимого риска зафиксируйте:

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

Запрос на изменение содержит не только пожелание, но и влияние на объём, срок, стоимость, риски и уже принятые решения. Только после этого владелец результата принимает или отклоняет изменение.

Метрики трёх уровней

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

Рабочий ритм

Ежедневно или по событию

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

Еженедельно

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

После этапа

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

Встреча не считается результатом. Результат встречи — принятое решение, обновлённая сущность или назначенное действие.

Пример одного контура

Проблема: компания ведёт обращения в почте и телефонии, а задачи — отдельно; руководитель не видит историю клиента.

Результат первого этапа: новое обращение создаёт или находит контакт, сохраняет источник, назначает владельца и формирует следующую задачу.

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

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

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

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

Антипаттерны

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

Стартовый чек-лист

Перед запуском проверьте:

1. Проблема описана наблюдаемым фактом.
2. Результат и способ проверки согласованы.
3. Есть один владелец решения.
4. Первый объём проходит целиком реальный сценарий.
5. Задачи имеют критерии и границы.
6. Значимые риски имеют владельцев.
7. Изменения проходят через явное решение.
8. После поставки назначена проверка эффекта.

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

Источники

• PMI: что такое проект и жизненный цикл проекта
• PMI: PMBOK Guide, актуальная редакция
• Официальный Scrum Guide
• Принципы Agile Manifesto

Материал проверен 19 июля 2026 года. Подход нужно адаптировать к риску, масштабу, договорным обязательствам и зрелости конкретной команды.