С утра агентство увидело дыру в графике: у клиента менялся продуктовый бриф, а команда уже ушла в продакшен. До дедлайна — 48 часов. Риск не был «неожиданным»: его просто не держали в системе.

Что сработало в этот раз:
1. На старте проекта ввели риск-реестр на 5 пунктов: бриф, доступы, согласования, контент, окно на правки.
2. Для каждого риска — владелец, триггер и срок проверки.
3. Любое изменение брифа после запуска — сразу в статус «hold» до подтверждения от PM и клиента.
4. Ежедневно — 10-минутный риск-стенд: что горит, что может сорвать срок, кто закрывает.

📌 Вывод простой: риск ловится не «чувством», а точкой входа в процесс. Если у риска нет владельца и триггера, он уже стал проблемой.

Система, которая видит отклонение раньше команды, экономит не время — она экономит срыв.

SLA можно ставить двумя способами: по обещанию или по возможности системы.

Кейс агентства: клиент просит «ответ в течение часа». Команда ставит SLA = 1 час на всё. Итог предсказуем: в пике 30–40% запросов нарушают срок, потому что нет приоритизации, резервов и окна на эскалацию.

Второй подход — считать SLA от процесса:
1) входящий запрос классифицируется за 10 минут;
2) обычный — ответ до 4 часов;
3) срочный — до 1 часа, но только через триггер;
4) эскалация через 15 минут, если нет владельца;
5) исключения фиксируются отдельно.

Разница простая: первый SLA выглядит красиво в договоре, второй живёт в операционке.

Если SLA не связан с мощностью команды, он превращается в штрафной лист. Если связан — в управляемый регламент. 📌

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

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

Собрали регламент по 5 блокам:

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

2. Роли
Кто отвечает за бриф, кто утверждает сроки, кто фиксирует риски. Без двойных трактовок.

3. Шаги
Порядок действий по минутам, а не “потом разберёмся”.

4. SLA
Срок ответа на бриф, срок согласования, дедлайн на обратную связь. Если срок нарушен — что происходит дальше.

5. Исключения
Что делать, если клиент не дал данные, команда перегружена, задача срочная. ⚠️

Итог: меньше ручных уточнений, меньше срывов на старте, проще контролировать загрузку.

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

ЕЮ Иванов продолжает кошмарить АффПапу, конторку, которая накинула говна на вентилятор этим летом. Тогда в AffPapa не знали, с каким говном идут бодаться, поэтому заслуженно проиграли. 😏

На этот раз ЕЮ зарегал товарный знак AffPapa — совсем скоро имя компании будет официально принадлежать ему. Чтобы убедиться в трушности мува, переходим по ссыл-Очке и вводим серийный номер: 2026793242. Там видим, что заявка на регистрацию подана лично Евгением Юрьичем.

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

В арбитраже денег нет 💵

Риск не видно в отчёте, пока он не стал просрочкой.

Кейс: в агентстве 14 проектов, срыв по срокам рос 3 месяца подряд. Причина оказалась не в команде, а в метриках контроля.

Что отслеживали:
— % задач, ушедших за SLA;
— среднее отклонение от плана по неделе;
— долю задач без владельца;
— число возвратов на доработку;
— возраст задач в статусе «в работе» > 5 дней.

Порог срабатывания:
— SLA breach > 12%;
— tasks without owner > 0;
— rework rate > 18%;
— 2 недели подряд рост drift по плану.

Когда эти цифры свели в один дашборд, риск стал виден за 7–10 дней до срыва. 📊

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

SLA не ставят “на глаз”. Его собирают из 3 входов: объем, риск, цена задержки.

Кейс: агентство ведет лидогенерацию для B2B-клиента. До SLA было: “отвечаем быстро”. Итог — спорные ожидания, просрочки, хаос в чатах.

Чек-лист фиксации SLA:
1. Описать типы запросов: лид, правка, инцидент, согласование.
2. Для каждого типа задать время реакции и время решения.
3. Отдельно прописать рабочие часы и что считается паузой клиента.
4. Назначить владельца SLA: кто отвечает за контроль.
5. Добавить эскалацию: через сколько минут/часов подключается тимлид.
6. Зафиксировать формат подтверждения: чат, таск-трекер, письмо.
7. Привязать штраф/компенсацию только к тем SLA, которые можно измерить 📌

Если SLA нельзя проверить по логам — это не SLA, а обещание.