← К списку разделов
#### §7.05 Стадии и этапы проекта: логическое и физическое время **Время:** 60 мин чтение + 40 мин = 100 мин **Что узнаешь:** как планировать не «до дедлайна», а «до результата», и почему календарь без стадий порождает хаос --- **В одном предложении:** стадии — это логические вехи проекта, где каждая следующая невозможна без приёмки предыдущей; физическое время - это сколько дней прошло, логическое время - это на какой стадии вы сейчас, и эти два времени живут по разным законам. --- **Сигнатура понятий:** - **Стадия** — это логически завершённый фрагмент проекта с чётким критерием входа и критерием выхода; переход на следующую стадию возможен только после приёмки - **Этап** — это часть стадии, которая может выполняться параллельно или последовательно внутри одной стадии; этап не требует отдельной приёмки, но имеет промежуточный результат - **Логическое время** — это измерение прогресса в единицах «стадий завершено / стадий осталось»; не зависит от календаря - **Физическое время** — это измерение прогресса в календарных единицах (дни, недели, месяцы); зависит от ресурсов, но не гарантирует результат --- **Мем, который снимается.** «У нас два месяца, значит, через два месяца будет готово». Этот мем - главная причина срыва сроков. Команда получает бюджет в 8 недель и сразу делит его пополам: 4 недели на разработку, 4 недели на тестирование. Но «разработка» — это не стадия, это процесс. Стадия звучит иначе: «система учёта задач собирает данные из трёх источников и отображает их в одном отчёте». Критерий выхода: менеджер видит отчёт без ручной сводки. Пока этого нет, стадия не закрыта, сколько бы недель ни прошло. Логическое время тикает только когда результат достигнут. Физическое время тикает всегда и часто тикает вхолостую. --- **Определение из источника.** В Pack стадии и этапы определены как элементы временной структуры системного разбора (ответ на вопрос «когда?» из §7.01). Связь с §2.07 (жизненный цикл): жизненный цикл — это модель, которая описывает, через какие стадии проходит система от задумки до вывода. Стадии проекта — это практическое применение жизненного цикла к конкретной задаче. **Правило 3–5 стадий:** любой проект, который нельзя разбить на 3–5 стадий, либо слишком мал (это задача, не проект), либо слишком большой (его нужно разбить на подпроекты). Меньше 3 - вы упустили промежуточные приёмки. Больше 5 - вы путаете стадии с этапами. **Каждая стадия содержит:** 1. Критерий входа - что должно быть готово, чтобы начать (ответ на «зачем эта стадия»). 2. Результат - что будет создано (ответ на «что»). 3. Процесс - как создаётся (ответ на «как»). 4. Критерий выхода - как понять, что стадия завершена и можно переходить дальше. **Логическое vs физическое время:** - Логическое: «Мы на стадии 2 из 4, приёмка пройдена, переходим к стадии 3». - Физическое: «Прошло 3 недели из 8, осталось 5 недель». - Проблема: когда планируешь только по физическому времени, команда движется «до дедлайна», а не «до результата». Дедлайн наступает, результата нет. --- **Развитие мысли.** Декомпозиция работы по стадиям одновременно декомпозирует риск: каждая стадия снижает одну зону неопределённости. Стадия 1: «Что мы строим?» - неопределённость требований. Стадия 2: «Как это работает?» - неопределённость технологии. Стадия 3: «Работает ли для пользователя?» - неопределённость применимости. Если вы пропускаете стадию, неопределённость не исчезает, она переносится в следующую стадию и растёт. **Связь с таблицей 3×3 (§7.03):** временная ось таблицы вынесена в стадии. Когда вы заполняете таблицу, вопрос «когда?» звучит как «на какой стадии эта роль вступает в игру?» Создатель активен на ранних стадиях (задумка и создание). Оператор активен на стадиях эксплуатации. Пользователь активен начиная со стадии, где результат впервые доступен. Если роль появляется «с самого начала», вы не разбили на стадии достаточно чётко. **Связь с системным разбором (§7.01):** ответ на «когда?» — это не дата, это стадии. Каждая стадия — это мини-разбор: зачем эта стадия, что в ней создаётся, как создаётся, когда считается готово. Системный мыслитель не говорит «Рассчитаем на две недели». Он говорит: «Стадия 1 - неделя, результат X, критерий Y. Стадия 2 зависит от приёмки стадии 1». **Почему приёмка между стадиями критична?** Без приёмки стадии сливаются в бесконечный процесс. Команда «почти закончила» первую стадию, начала вторую «параллельно», и через месяц непонятно, что работает, а что нет. Приёмка — это жёсткая граница: результат либо принят, либо нет. Нет, значит, стадия не закрыта, следующая не начинается. --- **Метод - минимальный шаг.** Практика «Разбивка одного проекта на стадии» (40 мин): 1. Выберите текущий проект или задачу, которая занимает больше недели (5 мин). 2. Определите 3–5 стадий. Для каждой запишите: критерий входа, результат, критерий выхода. Не пишите даты, только логику (20 мин). 3. Проверьте: можно ли начать стадию N+1, не закончив стадию N? Если да, это не стадии, это этапы внутри одной стадии. Пересмотрите (10 мин). 4. Поставьте физическое время: сколько дней нужно на каждую стадию при текущих ресурсах. Сравните с календарным бюджетом. Если физическое время превышает бюджет, либо уменьшите объём, либо добавьте ресурсы, но не сжимайте стадии (5 мин). --- **Пример из жизни.** Команда из трёх человек решила создать внутренний инструмент для учёта рабочего времени. Срок - 6 недель. **Физическое планирование (провал):** Недели 1–3 - разработка. Недели 4–5 - тестирование. Неделя 6 - запуск. Через 5 недель оказалось, что «разработка» закончилась без документации, тестирование выявило архитектурный изъян, и запуск отложен на месяц. **Логическое планирование (успех):** - Стадия 1: Прототип интерфейса (1 неделя). Вход: требования согласованы. Результат: кликабельный макет. Выход: 3 из 3 пользователей понимают, как вносить время. - Стадия 2: Интеграция с источниками данных (2 недели). Вход: макет принят. Результат: данные тянутся из двух систем. Выход: данные корректны для 10 тестовых записей. - Стадия 3: Отчётность и приёмка (1 неделя). Вход: данные корректны. Результат: менеджер видит отчёт без ручной сводки. Выход: отчёт использован в реальной встрече. - Стадия 4: Развёртывание и документация (1 неделя). Вход: отчёт принят. Результат: система доступна команде, есть инструкция. Выход: 2 человека успешно внесли время по инструкции. Общий срок - 5 недель, но каждая стадия имеет приёмку. Команда закончила за 5 недель, потому что архитектурный изъян обнаружен на стадии 2 (интеграция), а не на стадии 5 (запуск). --- **Типичная ошибка.** «Стадии — это формальность, мы и так знаем, что делать». Нет. Стадии защищают от когнитивной иллюзии прогресса. Команда, которая «почти закончила» три стадии одновременно, на самом деле не закончила ни одну. Стадии принуждают к честности: либо результат есть и прошёл приёмку, либо его нет. Вторая ошибка - планирование по физическому времени вперёд. «Давайте назначим даты, а затем придумаем, что вложить в эти даты». Это приводит к сжатию: стадия, которой нужно 2 недели, получает 1 неделю, потому что «дедлайн горит». Результат: приёмка не пройдена, стадия переписывается. Логическое время первично: определите стадии и содержание до расчёта физического времени. --- **Степени мастерства:** 1. **Объясняю.** Могу назвать 3–5 стадий любого проекта и объяснить, чем логическое время отличается от физического. Критерий: один раз разбил реальный проект на стадии с критериями выхода. 2. **Умею.** Перед началом проекта всегда определяю стадии и проверяю, что следующая зависит от приёмки предыдущей. Критерий: есть запись «проект + 3–5 стадий + критерии выхода». 3. **Навык.** Автоматически замечаю, когда планирование скатывается к физическому времени без логических вех. Критерий: регулярно корректирую планы команды, переводя их с «дедлайнов» на «стадии». 4. **Мастерство.** Проектирую систему стадий для организации: шаблоны, чеклисты приёмки, критерии перехода. Критерий: есть кейс, где внедрение стадий сократило количество переработок или срывов сроков. --- **Проверка себя.** - Понимание: вы можете объяснить, почему «две недели на разработку» - это не стадия, а физическое время, и как превратить её в стадию с критерием выхода. - Поведение: перед началом любого проекта длительностью более недели вы определяете 3–5 стадий и только после этого назначаете календарные даты. - Застревание: если вы ловите себя на мысли «у нас неделя до дедлайна, а мы только на полпути», скорее всего, вы планировали по физическому времени без логических вех. Остановитесь. Пересмотрите стадии. --- **Что дальше.** Стадии показывают, когда что происходит. Каждая стадия производит результат. Следующий подраздел - о том, что именно производится: Альфа и рабочий продукт.
← Предыдущий раздел
Следующий раздел →