РАЗДЕЛ 8
СРОКИ И РИСКИ
СРОКИ И РИСКИ
Студия дизайна интерьеров CONTRAST | ТЮМЕНЬ
Зачем этот раздел
В CONTRAST сроки — это не просто даты в календаре.
Это показатель того, насколько управляем проект.
Это показатель того, насколько управляем проект.
PM не отвечает за эстетику и дизайн-решения. PM отвечает за:
- фиксацию сроков и условий;
- контроль полноты и формального стандарта результата;
- раннее выявление рисков;
- корректную коммуникацию с дизайнером и клиентом;
- включение управленческих протоколов (в т.ч. «Красной зоны»).
РАСЧЁТ СРОКОВ ПОЛНОГО ДИЗАЙН-ПРОЕКТА CONTRAST
с учётом презентаций и согласований
Мы считаем управляемый, здоровый проект, где:
- каждый этап презентуется;
- клиент участвует в согласованиях;
- нет форс-мажоров;
- правки — в рамках этапов;
- паузы по инициативе клиента в срок не входят.
Срок: 5–10 рабочих дней
(в зависимости от вовлечённости клиента)
📌 В срок проекта не входит
📌 Старт проекта — после утверждения ТЗ
(в зависимости от вовлечённости клиента)
📌 В срок проекта не входит
📌 Старт проекта — после утверждения ТЗ
Работа студии:
7–10 рабочих дней
Презентация + согласование:
3–5 рабочих дней
Итого по этапу:
➡️ 10–15 рабочих дней
7–10 рабочих дней
Презентация + согласование:
3–5 рабочих дней
Итого по этапу:
➡️ 10–15 рабочих дней
Работа студии:
Рассчитывается исходя из количества помещений. 6 дней+1д. на помещение.
Презентация + обсуждение:
3–5 рабочих дней
Итого по этапу:
➡️ 10–15 рабочих дней
Рассчитывается исходя из количества помещений. 6 дней+1д. на помещение.
Презентация + обсуждение:
3–5 рабочих дней
Итого по этапу:
➡️ 10–15 рабочих дней
Работа студии:
Рассчитывается исходя из количества помещений. 3 дня+2д. на помещение.
15–25 рабочих дней (в зависимости от метража и количества помещений)
Презентации + правки:
5–10 рабочих дней
Итого по этапу:
➡️ 20–35 рабочих дней
Рассчитывается исходя из количества помещений. 3 дня+2д. на помещение.
15–25 рабочих дней (в зависимости от метража и количества помещений)
Презентации + правки:
5–10 рабочих дней
Итого по этапу:
➡️ 20–35 рабочих дней
Работа студии:
20–30 рабочих дней
Проверка + согласование:
3–5 рабочих дней
Итого по этапу:
➡️ 23–35 рабочих дней
20–30 рабочих дней
Проверка + согласование:
3–5 рабочих дней
Итого по этапу:
➡️ 23–35 рабочих дней
Работа студии:
10–15 рабочих дней
Уточнения:
3–5 рабочих дней
Итого:
➡️ 10–20 рабочих дней
10–15 рабочих дней
Уточнения:
3–5 рабочих дней
Итого:
➡️ 10–20 рабочих дней
Работа студии:
5–15 рабочих дней
Уточнения:
3–5 рабочих дней
Итого:
➡️ 10–15 рабочих дней
5–15 рабочих дней
Уточнения:
3–5 рабочих дней
Итого:
➡️ 10–15 рабочих дней
Фиксации и отслеживания сроков по договору
Фиксируй этапы и отслеживай сроки согласно договору по каждому проекту
Внутри каждого этапа есть подэтапы, проверки, презентации и согласования. спланировать и рассчитать сроки внутри этапа поможет Калькулятор предварительного расчета сроков
Принципы работы PM со сроками
1.1. Что считается зафиксированным сроком
Срок считается установленным и обязательным, только если выполнены все условия одновременно.
Срок считается зафиксированным, если:
☐ срок указан письменно
(почта / чат проекта / задача / CRM);
☐ указан конкретный этап проекта;
☐ указана точная дата сдачи;
☐ обозначен формат результата, который считается сданным.
Пример корректной фиксации срока
«Этап “Концепция”:
срок сдачи — 24.03.2026
формат — PDF-альбом концепции»
Пример НЕзафиксированного срока
❌ «Ориентируемся на конец недели»
❌ «Попробуем сделать к пятнице»
❌ «Давайте быстро, как получится»
❗️ Если хотя бы один пункт отсутствует —
срок не считается обязательством дизайнера и не может использоваться в KPI.
1.2. Обязанности PM по срокам
PM — владелец сроков проекта.
Это означает, что PM обязан:
До старта этапа
☐ зафиксировать сроки этапа письменно;
☐ донести сроки дизайнеру до начала работы;
☐ обозначить формат результата;
☐ проверить, что условия для выполнения срока существуют
(ТЗ, стандарт, норма правок).
В ходе этапа
☐ отслеживать изменения условий;
☐ выявлять риски заранее, а не в день дедлайна;
☐ при изменении условий пересматривать срок.
При риске или изменениях
☐ зафиксировать изменение условий письменно;
☐ скорректировать срок;
☐ уведомить дизайнера и клиента.
❗️ Если срок не был зафиксирован PM — он не может считаться нарушенным дизайнером.
1.3. Что НЕ является сроком
Следующие формулировки не считаются сроками и не имеют управленческой силы:
❌ устные договорённости
❌ «примерно», «ориентировочно», «постараемся»
❌ ожидания клиента без фиксации
❌ внутренние планы без доведения до команды
❌ дедлайн «в голове PM»
Также не является срывом срока, если:
1.4. Связь сроков и условий
В CONTRAST действует базовое правило:
Сроки — это производная от условий. Меняются условия → меняются сроки.
К условиям относятся:
Итоговое правило раздела
Срок — это не обещание “любой ценой”.
Срок — это результат корректно зафиксированных условий.
Срок считается установленным и обязательным, только если выполнены все условия одновременно.
Срок считается зафиксированным, если:
☐ срок указан письменно
(почта / чат проекта / задача / CRM);
☐ указан конкретный этап проекта;
☐ указана точная дата сдачи;
☐ обозначен формат результата, который считается сданным.
Пример корректной фиксации срока
«Этап “Концепция”:
срок сдачи — 24.03.2026
формат — PDF-альбом концепции»
Пример НЕзафиксированного срока
❌ «Ориентируемся на конец недели»
❌ «Попробуем сделать к пятнице»
❌ «Давайте быстро, как получится»
❗️ Если хотя бы один пункт отсутствует —
срок не считается обязательством дизайнера и не может использоваться в KPI.
1.2. Обязанности PM по срокам
PM — владелец сроков проекта.
Это означает, что PM обязан:
До старта этапа
☐ зафиксировать сроки этапа письменно;
☐ донести сроки дизайнеру до начала работы;
☐ обозначить формат результата;
☐ проверить, что условия для выполнения срока существуют
(ТЗ, стандарт, норма правок).
В ходе этапа
☐ отслеживать изменения условий;
☐ выявлять риски заранее, а не в день дедлайна;
☐ при изменении условий пересматривать срок.
При риске или изменениях
☐ зафиксировать изменение условий письменно;
☐ скорректировать срок;
☐ уведомить дизайнера и клиента.
❗️ Если срок не был зафиксирован PM — он не может считаться нарушенным дизайнером.
1.3. Что НЕ является сроком
Следующие формулировки не считаются сроками и не имеют управленческой силы:
❌ устные договорённости
❌ «примерно», «ориентировочно», «постараемся»
❌ ожидания клиента без фиксации
❌ внутренние планы без доведения до команды
❌ дедлайн «в голове PM»
Также не является срывом срока, если:
- изменилось ТЗ;
- добавились правки сверх нормы;
- клиент задержал согласование;
- условия были изменены и зафиксированы PM.
1.4. Связь сроков и условий
В CONTRAST действует базовое правило:
Сроки — это производная от условий. Меняются условия → меняются сроки.
К условиям относятся:
- Техническое задание;
- утверждённые решения;
- бюджет и ограничения;
- количество раундов правок;
- скорость обратной связи клиента;
- дополнительные объёмы работ.
- если условия изменились —срок обязан быть пересмотрен;
- если срок не пересмотрен —это управленческая ошибка PM;
- если условия не зафиксированы —срок считается недействительным.
Итоговое правило раздела
Срок — это не обещание “любой ценой”.
Срок — это результат корректно зафиксированных условий.
2.1. Базовый принцип
PM управляет условиями →
дизайнер управляет результатом.
Если PM не обеспечил условия:
2.2. Что относится к условиям проекта
К условиям проекта относятся все параметры, влияющие на сроки и качество:
2.3. Что PM обязан предоставить дизайнеру ДО старта этапа
2.3.1. Зафиксированные сроки этапа
PM обязан предоставить дизайнеру:
☐ название этапа;
☐ дату старта;
☐ дату сдачи;
☐ формат результата (что считается «сдано»).
❗️ Сроки фиксируются только письменно.
Без письменной фиксации этап не стартует.
2.3.2. Стандарт результата по этапу
PM обязан:
☐ передать дизайнеру актуальный стандарт студии;
☐ зафиксировать, по какому стандарту принимается этап;
☐ обозначить, кто принимает результат (PM / ведущий дизайнер / техконтроль).
PM не интерпретирует стандарт — он обеспечивает, чтобы дизайнер его получил.
2.3.3. Техническое задание и ограничения
До старта этапа PM обязан:
☐ передать утверждённое ТЗ;
☐ зафиксировать бюджет и ограничения;
☐ донести особенности клиента (красные зоны, чувствительные моменты).
Если ТЗ:
2.3.4. Норма раундов правок
PM обязан заранее зафиксировать:
☐ количество допустимых раундов правок по этапу;
☐ что считается одним раундом;
☐ что считается выходом за норму.
Пример базовой логики:
считается изменением условий проекта.
2.3.5. Роли и коммуникация
PM обязан чётко обозначить:
☐ кто общается с клиентом;
☐ по каким вопросам дизайнер не общается с клиентом;
☐ что сроки и деньги — зона ответственности PM.
Если дизайнер вынужден:
2.4. Чек-лист PM перед стартом этапа
Перед запуском этапа PM обязан подтвердить:
☐ сроки зафиксированы письменно;
☐ стандарт передан;
☐ ТЗ утверждено;
☐ норма правок обозначена;
☐ роли и коммуникация понятны;
☐ риски проговорены.
Если хотя бы один пункт = «НЕТ» —
этап не запускается.
PM управляет условиями →
дизайнер управляет результатом.
Если PM не обеспечил условия:
- срок не считается обязательством дизайнера;
- снижение KPI дизайнера недопустимо;
- ответственность остаётся на стороне PM.
2.2. Что относится к условиям проекта
К условиям проекта относятся все параметры, влияющие на сроки и качество:
- Техническое задание (ТЗ);
- состав этапа и формат результата;
- стандарт студии по этапу;
- сроки этапа;
- норма раундов правок;
- бюджет и ограничения;
- роли и коммуникация;
- зафиксированные риски.
2.3. Что PM обязан предоставить дизайнеру ДО старта этапа
2.3.1. Зафиксированные сроки этапа
PM обязан предоставить дизайнеру:
☐ название этапа;
☐ дату старта;
☐ дату сдачи;
☐ формат результата (что считается «сдано»).
❗️ Сроки фиксируются только письменно.
Без письменной фиксации этап не стартует.
2.3.2. Стандарт результата по этапу
PM обязан:
☐ передать дизайнеру актуальный стандарт студии;
☐ зафиксировать, по какому стандарту принимается этап;
☐ обозначить, кто принимает результат (PM / ведущий дизайнер / техконтроль).
PM не интерпретирует стандарт — он обеспечивает, чтобы дизайнер его получил.
2.3.3. Техническое задание и ограничения
До старта этапа PM обязан:
☐ передать утверждённое ТЗ;
☐ зафиксировать бюджет и ограничения;
☐ донести особенности клиента (красные зоны, чувствительные моменты).
Если ТЗ:
- противоречивое,
- неполное,
- «в процессе уточнения» —
2.3.4. Норма раундов правок
PM обязан заранее зафиксировать:
☐ количество допустимых раундов правок по этапу;
☐ что считается одним раундом;
☐ что считается выходом за норму.
Пример базовой логики:
- планировка — до 2 раундов;
- концепция — до 2 раундов;
- визуализация — до 2 раундов;
- чертежи — 1 раунд.
считается изменением условий проекта.
2.3.5. Роли и коммуникация
PM обязан чётко обозначить:
☐ кто общается с клиентом;
☐ по каким вопросам дизайнер не общается с клиентом;
☐ что сроки и деньги — зона ответственности PM.
Если дизайнер вынужден:
- объяснять задержки;
- договариваться о сроках;
- обсуждать бюджет —
2.4. Чек-лист PM перед стартом этапа
Перед запуском этапа PM обязан подтвердить:
☐ сроки зафиксированы письменно;
☐ стандарт передан;
☐ ТЗ утверждено;
☐ норма правок обозначена;
☐ роли и коммуникация понятны;
☐ риски проговорены.
Если хотя бы один пункт = «НЕТ» —
этап не запускается.
3.1. Базовый принцип работы с рисками
Риск — это сигнал к действию, а не проблема, которую нужно “потерпеть”.
PM не ждёт:
3.2. Что считается риском по срокам и качеству
Риском считается любая ситуация, при которой:
Риск — это управленческая категория.
3.3. Ранние сигналы риска (PM обязан их видеть)
PM должен насторожиться, если появляется хотя бы один сигнал:
3.4. Контрольные точки PM в ходе этапа
PM обязан проверять этап не только в конце.
Контрольная точка №1
30–40% времени этапа
PM проверяет:
Контрольная точка №2
Середина этапа
PM проверяет:
концепция не зафиксирована;
PM думает «главное — успеть».
Контрольная точка №3
За 5–6 рабочих дней до дедлайна
PM задаёт ключевой вопрос:
«Я бы показал это клиенту уже сейчас?»
✔️ Да → этап управляем
❌ Нет → ранняя красная зона
❗️ Если до дедлайна ≤ 3 рабочих дней и есть сомнение —
это автоматическая красная зона.
3.5. Что PM обязан сделать при первом риске
При появлении риска PM обязан:
1️⃣ запросить промежуточный результат
2️⃣ проверить полноту и формальный стандарт (не эстетику)
3️⃣ зафиксировать риск для себя
4️⃣ принять решение:
3.6. Связь рисков и сроков
Если риск выявлен заранее:
3.7. Чек-лист профилактики (коротко)
PM регулярно проверяет:
☐ результат появляется вовремя
☐ направление зафиксировано
☐ правки в норме
☐ нет надежды «дожать потом»
☐ есть уверенность в результате
Если хотя бы один пункт под вопросом —
риск уже есть.
Итоговое правило раздела
Лучший PM — не тот, кто спас проект,
а тот, кто не довёл его до спасения
Риск — это сигнал к действию, а не проблема, которую нужно “потерпеть”.
PM не ждёт:
- «может, успеем»,
- «давай ещё пару дней»,
- «пока не критично».
3.2. Что считается риском по срокам и качеству
Риском считается любая ситуация, при которой:
- срок этапа может быть сорван;
- результат может не соответствовать стандарту студии;
- PM перестаёт быть уверен в управляемости этапа.
- Типовые источники рисков
- изменение или размытость ТЗ;
- дополнительные правки сверх нормы;
- задержка обратной связи клиента;
- противоречивые вводные;
- новые ограничения по бюджету;
- зависимость от третьих лиц;
- высокая эмоциональность клиента;
- неопределённость направления дизайна.
Риск — это управленческая категория.
3.3. Ранние сигналы риска (PM обязан их видеть)
PM должен насторожиться, если появляется хотя бы один сигнал:
- дизайнер говорит: «пока сыро, но потом соберём»;
- результат есть, но направление всё ещё «ищется»;
- PM откладывает просмотр промежуточного результата;
- появляется надежда «дожмём в последние дни»;
- правки начинают накапливаться;
- нет ощущения, что этап «собирается».
3.4. Контрольные точки PM в ходе этапа
PM обязан проверять этап не только в конце.
Контрольная точка №1
30–40% времени этапа
PM проверяет:
- появляется ли форма результата;
- соответствует ли направление стандарту;
- уверен ли дизайнер в выбранном решении.
- результата ещё «почти нет»;
- дизайнер сомневается;
- направление плавает.
Контрольная точка №2
Середина этапа
PM проверяет:
- зафиксировано ли направление;
- укладываемся ли в норму правок;
- нет ли ощущения «мы всё ещё ищем».
концепция не зафиксирована;
PM думает «главное — успеть».
Контрольная точка №3
За 5–6 рабочих дней до дедлайна
PM задаёт ключевой вопрос:
«Я бы показал это клиенту уже сейчас?»
✔️ Да → этап управляем
❌ Нет → ранняя красная зона
❗️ Если до дедлайна ≤ 3 рабочих дней и есть сомнение —
это автоматическая красная зона.
3.5. Что PM обязан сделать при первом риске
При появлении риска PM обязан:
1️⃣ запросить промежуточный результат
2️⃣ проверить полноту и формальный стандарт (не эстетику)
3️⃣ зафиксировать риск для себя
4️⃣ принять решение:
- корректируем условия
- или готовимся к включению красной зоны
3.6. Связь рисков и сроков
Если риск выявлен заранее:
- срок может быть скорректирован без конфликта;
- KPI дизайнера не ухудшается;
- проект остаётся управляемым.
- возникает аврал;
- включается красная зона в последний момент;
- PM теряет управляемость.
3.7. Чек-лист профилактики (коротко)
PM регулярно проверяет:
☐ результат появляется вовремя
☐ направление зафиксировано
☐ правки в норме
☐ нет надежды «дожать потом»
☐ есть уверенность в результате
Если хотя бы один пункт под вопросом —
риск уже есть.
Итоговое правило раздела
Лучший PM — не тот, кто спас проект,
а тот, кто не довёл его до спасения
4.1. Роль PM на этапе проверки
PM не оценивает дизайн и не правит эстетику.
PM проверяет:
он выходит за свою роль.
4.2. Что именно проверяет PM
4.2.1. Формальный допуск этапа
PM обязан убедиться, что этап вообще может считаться готовым.
Проверка:
☐ этап и сроки зафиксированы письменно;
☐ текущая версия обозначена как финальная для сдачи;
☐ формат результата соответствует договору;
☐ понятно, что именно сейчас сдаётся клиенту.
❗️ Если хотя бы один пункт = «НЕТ» —
этап не допускается к сдаче.
4.2.2. Полнота альбома (базовая проверка PM)
PM проверяет комплектность, а не качество.
☐ все помещения / зоны присутствуют;
☐ все листы, предусмотренные этапом, собраны;
☐ нет пустых, недособранных или «временных» страниц;
☐ нет логических дыр (пропущенные зоны, несобранные решения).
❗️ Неполный альбом =
этап не готов, независимо от срока.
4.2.3. Соответствие формальному стандарту
PM проверяет:
☐ структура альбома соответствует стандарту студии;
☐ формат подачи соблюдён (PDF, состав, порядок);
☐ учтены зафиксированные ограничения ТЗ;
☐ нет явных противоречий ранее утверждённым решениям.
📌 PM не оценивает уровень дизайна,
он проверяет, что дизайнер работал в заданных рамках.
4.2.4. Контроль условий и правок
PM обязан проверить:
☐ количество раундов правок в норме;
☐ выход за норму зафиксирован как изменение условий (если был);
☐ изменения ТЗ отражены письменно;
☐ сроки скорректированы при необходимости.
❗️ Если были изменения, но нет фиксации —
PM обязан зафиксировать их до сдачи этапа.
4.3. Контрольный вопрос PM (ключевая точка)
После формальной проверки PM задаёт себе один вопрос:
«Я готов отправить это клиенту под стандарт CONTRAST?»
✔️ Да → этап допускается к сдаче
❌ Нет → этап считается рисковым
Если:
до дедлайна ≤ 3 рабочих дней
и есть сомнение в уровне
➡️ автоматически включается протокол “Красная зона проекта”.
4.4. Решение PM по этапу
PM обязан зафиксировать одно из решений:
☐ этап готов к сдаче клиенту;
☐ требуется точечная доработка;
☐ требуется включение красной зоны.
Решение принимается до коммуникации с клиентом
и фиксируется письменно.
4.5. Что PM запрещено делать на этапе проверки
❌ править дизайн и эстетику
❌ «чуть-чуть улучшать» результат
❌ тянуть до последнего дня
❌ сдавать «чтобы успеть»
❌ отдавать слабый результат без управленческого решения
4.6. Связь проверки этапа и сроков
Итоговое правило раздела
PM — последняя управленческая точка перед клиентом.
Если здесь допущена слабина — дальше система не спасёт.
PM не оценивает дизайн и не правит эстетику.
PM проверяет:
- полноту результата;
- соответствие формальному стандарту;
- соблюдение зафиксированных условий;
- управляемость этапа по срокам и рискам.
он выходит за свою роль.
4.2. Что именно проверяет PM
4.2.1. Формальный допуск этапа
PM обязан убедиться, что этап вообще может считаться готовым.
Проверка:
☐ этап и сроки зафиксированы письменно;
☐ текущая версия обозначена как финальная для сдачи;
☐ формат результата соответствует договору;
☐ понятно, что именно сейчас сдаётся клиенту.
❗️ Если хотя бы один пункт = «НЕТ» —
этап не допускается к сдаче.
4.2.2. Полнота альбома (базовая проверка PM)
PM проверяет комплектность, а не качество.
☐ все помещения / зоны присутствуют;
☐ все листы, предусмотренные этапом, собраны;
☐ нет пустых, недособранных или «временных» страниц;
☐ нет логических дыр (пропущенные зоны, несобранные решения).
❗️ Неполный альбом =
этап не готов, независимо от срока.
4.2.3. Соответствие формальному стандарту
PM проверяет:
☐ структура альбома соответствует стандарту студии;
☐ формат подачи соблюдён (PDF, состав, порядок);
☐ учтены зафиксированные ограничения ТЗ;
☐ нет явных противоречий ранее утверждённым решениям.
📌 PM не оценивает уровень дизайна,
он проверяет, что дизайнер работал в заданных рамках.
4.2.4. Контроль условий и правок
PM обязан проверить:
☐ количество раундов правок в норме;
☐ выход за норму зафиксирован как изменение условий (если был);
☐ изменения ТЗ отражены письменно;
☐ сроки скорректированы при необходимости.
❗️ Если были изменения, но нет фиксации —
PM обязан зафиксировать их до сдачи этапа.
4.3. Контрольный вопрос PM (ключевая точка)
После формальной проверки PM задаёт себе один вопрос:
«Я готов отправить это клиенту под стандарт CONTRAST?»
✔️ Да → этап допускается к сдаче
❌ Нет → этап считается рисковым
Если:
до дедлайна ≤ 3 рабочих дней
и есть сомнение в уровне
➡️ автоматически включается протокол “Красная зона проекта”.
4.4. Решение PM по этапу
PM обязан зафиксировать одно из решений:
☐ этап готов к сдаче клиенту;
☐ требуется точечная доработка;
☐ требуется включение красной зоны.
Решение принимается до коммуникации с клиентом
и фиксируется письменно.
4.5. Что PM запрещено делать на этапе проверки
❌ править дизайн и эстетику
❌ «чуть-чуть улучшать» результат
❌ тянуть до последнего дня
❌ сдавать «чтобы успеть»
❌ отдавать слабый результат без управленческого решения
4.6. Связь проверки этапа и сроков
- если этап не прошёл проверку —срок не является аргументом для сдачи;
- сдвиг срока ради качества —управленческое решение, а не ошибка;
- сдача слабого результата ради дедлайна —нарушение стандарта студии.
Итоговое правило раздела
PM — последняя управленческая точка перед клиентом.
Если здесь допущена слабина — дальше система не спасёт.
Что это
Красная зона — это управленческий режим,
который включается, если есть риск отдать слабый результат
или сорвать срок этапа.
Если есть сомнение — проект уже в красной зоне.
Когда включается автоматически
Проект в красной зоне, если выполнено хотя бы одно:
Главное правило
Качество важнее формального срока.
Сдвиг этапа ради результата — норма.
Первые действия PM (строго)
1️⃣ Остановить сдачу этапа
— ничего не отправлять клиенту «как есть».
2️⃣ Зафиксировать факт
«Результат этапа не соответствует стандарту студии».
3️⃣ Определить тип проблемы
(один основной):
Подключение Анны (обязательно)
PM пишет только так:
«Анна, проект в красной зоне. 2−3 пункта, где результат не дотягивает до стандарта.
Нужен вердикт:
— точечная доработка
или
— пересборка этапа со сдвигом срока".
Анна:
Допустимые решения (только 3)
Выбирается один вариант:
A. Точечная доработка
— если можно быстро поднять качество.
B. Сдвиг срока этапа
— если результат сырой и не отражает уровень студии.
C. Дробление результата
— клиенту показывается только готовая часть.
❌ Других вариантов нет.
Коммуникация с клиентом
PM говорит только про стандарт, не про проблемы:
«Мы можем отдать результат в срок, но он не соответствует стандарту CONTRAST.
Нам важно отдать сильный результат, поэтому предлагаем [выбранный вариант]."
Запрещено в красной зоне
❌ отдавать слабый результат
❌ ночные авралы
❌ «доделаем как есть»
❌ молчать до последнего
❌ тянуть Анну без формата
После выхода из красной зоны PM обязан передать Екатерине:
Связь с KPI
Финальное правило PM
Если ты думаешь, включать ли красную зону —
значит, её уже нужно включать.
Красная зона — это управленческий режим,
который включается, если есть риск отдать слабый результат
или сорвать срок этапа.
Если есть сомнение — проект уже в красной зоне.
Когда включается автоматически
Проект в красной зоне, если выполнено хотя бы одно:
- до дедлайна ≤ 3 рабочих дней;
- результат не дотягивает до стандарта студии;
- дизайнер сомневается, но тянет до последнего;
- PM понимает, что будет аврал;
- «стыдно показывать» клиенту.
Главное правило
Качество важнее формального срока.
Сдвиг этапа ради результата — норма.
Первые действия PM (строго)
1️⃣ Остановить сдачу этапа
— ничего не отправлять клиенту «как есть».
2️⃣ Зафиксировать факт
«Результат этапа не соответствует стандарту студии».
3️⃣ Определить тип проблемы
(один основной):
- эстетика
- нехватка времени / ресурса
- размытое или изменившееся ТЗ
Подключение Анны (обязательно)
PM пишет только так:
«Анна, проект в красной зоне. 2−3 пункта, где результат не дотягивает до стандарта.
Нужен вердикт:
— точечная доработка
или
— пересборка этапа со сдвигом срока".
Анна:
- даёт вердикт;
- не спасает руками;
- не отвечает за сроки.
Допустимые решения (только 3)
Выбирается один вариант:
A. Точечная доработка
— если можно быстро поднять качество.
B. Сдвиг срока этапа
— если результат сырой и не отражает уровень студии.
C. Дробление результата
— клиенту показывается только готовая часть.
❌ Других вариантов нет.
Коммуникация с клиентом
PM говорит только про стандарт, не про проблемы:
«Мы можем отдать результат в срок, но он не соответствует стандарту CONTRAST.
Нам важно отдать сильный результат, поэтому предлагаем [выбранный вариант]."
Запрещено в красной зоне
❌ отдавать слабый результат
❌ ночные авралы
❌ «доделаем как есть»
❌ молчать до последнего
❌ тянуть Анну без формата
После выхода из красной зоны PM обязан передать Екатерине:
- где был пропущен контроль;
- какой сигнал появился поздно;
- что нужно усилить в системе.
Связь с KPI
- красная зона ≠ провал дизайнера;
- сдвиг срока по красной зоне ≠ срыв;
- нарушение протокола = управленческая ошибка PM.
Финальное правило PM
Если ты думаешь, включать ли красную зону —
значит, её уже нужно включать.
6.2. Что считается изменением условий проекта
Изменением условий считается любое действие или обстоятельство, влияющее на объём работ, качество или скорость выполнения этапа.
К изменениям условий относятся:
если оно влияет на работу, это изменение условий.
6.3. Обязанности PM при изменении условий
При любом изменении условий PM обязан:
1️⃣ зафиксировать изменение письменно
2️⃣ определить влияние на:
4️⃣ уведомить:
дизайнера (внутри проекта),
клиента (по почте).
❌ Запрещено:
6.4. Как PM фиксирует изменение условий (обязательно)
6.4.1. Внутри команды (PM → дизайнер)
PM использует стандартный скрипт фиксации изменений, в котором указывает:
6.4.2. Для клиента (по электронной почте)
PM направляет уведомление, а не запрос разрешения.
В письме обязательно указывается:
если иное не предусмотрено договором.
6.5. Когда продление сроков ОБЯЗАТЕЛЬНО
PM обязан продлить срок этапа, если:
6.6. Когда продление сроков НЕ ухудшает KPI
Продление сроков не влияет на KPI дизайнера, если:
без изменения условий и без сигнала о риске.
6.7. Что НЕ является продлением сроков
Следующее не считается корректным продлением:
❌ устные договорённости
❌ «давай пока подвинем» без фиксации
❌ перенос сроков задним числом
❌ надежда, что клиент «и так поймёт»
Без фиксации — нет продления, нет защиты.
6.8. Связь с договором
Продление сроков при изменении условий:
Итоговое правило раздела
Изменения без фиксации = хаос.
Фиксация без продления сроков = риск.
Фиксация + продление сроков = управляемый проект.
Изменением условий считается любое действие или обстоятельство, влияющее на объём работ, качество или скорость выполнения этапа.
К изменениям условий относятся:
- изменение или дополнение Технического задания;
- изменение ранее утверждённых решений;
- дополнительные правки сверх нормы;
- задержка обратной связи клиента;
- появление новых ограничений (бюджет, материалы, технологии);
- добавление новых помещений / функций;
- изменения, возникшие на этапе реализации.
если оно влияет на работу, это изменение условий.
6.3. Обязанности PM при изменении условий
При любом изменении условий PM обязан:
1️⃣ зафиксировать изменение письменно
2️⃣ определить влияние на:
- объём работ,
- срок этапа,
- KPI дизайнера
4️⃣ уведомить:
дизайнера (внутри проекта),
клиента (по почте).
❌ Запрещено:
- «впихивать» изменения в старые сроки;
- надеяться, что команда «как-нибудь успеет»;
- продлевать сроки задним числом.
6.4. Как PM фиксирует изменение условий (обязательно)
6.4.1. Внутри команды (PM → дизайнер)
PM использует стандартный скрипт фиксации изменений, в котором указывает:
- что изменилось;
- по какой причине;
- как было / как становится;
- новый срок;
- что это изменение не ухудшает KPI дизайнера.
- изменение не существует,
- срок считается прежним,
- PM теряет управляемость.
6.4.2. Для клиента (по электронной почте)
PM направляет уведомление, а не запрос разрешения.
В письме обязательно указывается:
- факт изменения условий;
- причина;
- было / стало по срокам;
- новый срок сдачи этапа.
если иное не предусмотрено договором.
6.5. Когда продление сроков ОБЯЗАТЕЛЬНО
PM обязан продлить срок этапа, если:
- ТЗ изменилось после старта этапа;
- количество правок превысило норму;
- клиент задержал согласование;
- были изменены ранее утверждённые решения;
- добавился объём работ;
- проект входил в «красную зону» и принято решение о сдвиге срока ради качества.
- продление срока — обязательное действие PM;
- сохранение старого срока — нарушение системы.
6.6. Когда продление сроков НЕ ухудшает KPI
Продление сроков не влияет на KPI дизайнера, если:
- изменение условий зафиксировано PM;
- дизайнер сообщил о риске заранее;
- правки вышли за норму;
- клиент задержал решения;
- срок был скорректирован до фактического срыва.
без изменения условий и без сигнала о риске.
6.7. Что НЕ является продлением сроков
Следующее не считается корректным продлением:
❌ устные договорённости
❌ «давай пока подвинем» без фиксации
❌ перенос сроков задним числом
❌ надежда, что клиент «и так поймёт»
Без фиксации — нет продления, нет защиты.
6.8. Связь с договором
Продление сроков при изменении условий:
- предусмотрено договором;
- не требует отдельного допсоглашения;
- может фиксироваться в электронной переписке.
Итоговое правило раздела
Изменения без фиксации = хаос.
Фиксация без продления сроков = риск.
Фиксация + продление сроков = управляемый проект.
ШАБЛОНЫ ПИСЕМ О ПРОДЛЕНИИ СРОКОВ
Добрый день, [Имя клиента].
Информируем вас, что в рамках проекта по адресу [адрес объекта] были зафиксированы изменения ранее утверждённых решений / Технического задания по этапу «[название этапа]».
В связи с увеличением объёма работ сроки выполнения данного этапа подлежат пересмотру в соответствии с условиями Договора.
Было: Срок сдачи этапа — [старая дата]
Становится: Новый срок сдачи этапа — [новая дата]
Изменение сроков связано исключительно с корректировками, внесёнными после утверждения предыдущей версии [этапа/ технического задания], и не влияет на качество разрабатываемого проекта.
Если у вас есть вопросы — будем рады их обсудить.
С уважением, [Имя Фамилия] Менеджер проекта Студия CONTRAST [контакты]
Информируем вас, что в рамках проекта по адресу [адрес объекта] были зафиксированы изменения ранее утверждённых решений / Технического задания по этапу «[название этапа]».
В связи с увеличением объёма работ сроки выполнения данного этапа подлежат пересмотру в соответствии с условиями Договора.
Было: Срок сдачи этапа — [старая дата]
Становится: Новый срок сдачи этапа — [новая дата]
Изменение сроков связано исключительно с корректировками, внесёнными после утверждения предыдущей версии [этапа/ технического задания], и не влияет на качество разрабатываемого проекта.
Если у вас есть вопросы — будем рады их обсудить.
С уважением, [Имя Фамилия] Менеджер проекта Студия CONTRAST [контакты]
Добрый день, [Имя клиента].
В ходе работы по этапу «[название этапа]» количество правок превысило норму, предусмотренную Договором.
Дополнительные правки увеличивают объём работ, в связи с чем сроки выполнения этапа корректируются.
Было:
Срок сдачи — [старая дата]
Становится:
Новый срок сдачи — [новая дата]
Изменение сроков зафиксировано в рабочем порядке и соответствует условиям Договора.
Мы продолжаем работу над проектом в обновлённых условиях.
С уважением,
[Имя Фамилия]
Менеджер проекта
Студия CONTRAST
В ходе работы по этапу «[название этапа]» количество правок превысило норму, предусмотренную Договором.
Дополнительные правки увеличивают объём работ, в связи с чем сроки выполнения этапа корректируются.
Было:
Срок сдачи — [старая дата]
Становится:
Новый срок сдачи — [новая дата]
Изменение сроков зафиксировано в рабочем порядке и соответствует условиям Договора.
Мы продолжаем работу над проектом в обновлённых условиях.
С уважением,
[Имя Фамилия]
Менеджер проекта
Студия CONTRAST
Добрый день, [Имя клиента].
Сообщаем, что в период ожидания обратной связи / согласований по этапу «[название этапа]» выполнение работ было приостановлено.
В соответствии с условиями Договора срок выполнения этапа продлевается на количество дней ожидания решений Заказчика.
Было:
Срок сдачи — [старая дата]
Становится:
Новый срок сдачи — [новая дата]
После получения всех согласований работа продолжается в штатном режиме.
С уважением,
[Имя Фамилия]
Менеджер проекта
Студия CONTRAST
Сообщаем, что в период ожидания обратной связи / согласований по этапу «[название этапа]» выполнение работ было приостановлено.
В соответствии с условиями Договора срок выполнения этапа продлевается на количество дней ожидания решений Заказчика.
Было:
Срок сдачи — [старая дата]
Становится:
Новый срок сдачи — [новая дата]
После получения всех согласований работа продолжается в штатном режиме.
С уважением,
[Имя Фамилия]
Менеджер проекта
Студия CONTRAST
Добрый день, [Имя клиента].
Фиксируем изменение сроков выполнения этапа «[название этапа]» по проекту [адрес объекта].
Новый срок сдачи этапа: [дата]
Изменение связано с корректировками условий проекта и соответствует положениям Договора.
С уважением,
[Имя Фамилия]
Менеджер проекта
Студия CONTRAST
Фиксируем изменение сроков выполнения этапа «[название этапа]» по проекту [адрес объекта].
Новый срок сдачи этапа: [дата]
Изменение связано с корректировками условий проекта и соответствует положениям Договора.
С уважением,
[Имя Фамилия]
Менеджер проекта
Студия CONTRAST
1.Письмо отправляется сразу, как зафиксировано изменение условий
2.Формулировка — уведомление, а не просьба
3.Всегда:
2.Формулировка — уведомление, а не просьба
3.Всегда:
- указывать было / стало
- писать спокойно, без оправданий
