Раз в месяц просмотрите, где работа по сайту остановилась: замечание не передали, исполнитель ждал ответ, исправление опубликовали без проверки. Выберите конкретную причину ожидания и договоритесь, что изменить в следующем месяце.
Для разбора нужны результаты reChecker и ваш список задач. Достаточно нескольких реальных случаев; весь поток сообщений за месяц пересказывать не требуется.
Начните с прошлой договорённости и незавершённых задач
Выберите постоянную дату разбора, например первый рабочий день месяца. Сначала откройте решение предыдущего месяца: выполнили ли обещанный шаг и где это видно? Если нет, выясните, что помешало, прежде чем добавлять новый список правил.
Затем возьмите одну завершённую задачу и одну незавершённую. Если был сбой, можно добавить его. Если сбоев не было, не нужно создавать учебную аварию ради состава встречи.
Для каждого случая найдите адрес, исходный результат, передачу исполнителю, публикацию и проверку после неё. Если часть дат неизвестна, так и отметьте. Порядок ведения источников есть в статье о списке исправлений.
Разберите одно конкретное ожидание
Учебный пример: замечание о старой цене найдено 3 сентября, но задача завершена только 18 сентября. Не делайте общий вывод «команда работает медленно» — посмотрите историю.
| Дата | Что произошло |
|---|---|
| 03.09 | Владелец заметил старую цену на /services |
| 04.09 | Редактор получил задачу без утверждённой новой цены |
| 12.09 | Менеджер подтвердил значение после отдельного вопроса |
| 15.09 | Изменение опубликовано |
| 18.09 | Владелец проверил страницу и закрыл задачу |
Здесь есть два понятных ожидания: согласование цены и проверка после публикации. Спросите участников, какие сведения и решения им требовались. Не подставляйте предполагаемую причину вместо ответа.
В «Контроле сайта» можно найти технические результаты и даты, но сервис не знает автоматически все действия вашей команды. Их берут из задачи и сообщений участников. Событие в кабинете также не показывает, когда человек прочитал внешнее уведомление.
Запишите один новый порядок с человеком и сроком
Для примера цены подойдёт решение: «Менеджер прикладывает утверждённое значение до передачи задачи редактору. Владелец проверяет опубликованную страницу в ближайший согласованный рабочий день».
Не меняйте сразу все этапы. Выберите тот пробел, который подтверждён историей и действительно мешал. Если у исполнителя не было URL, добавляйте адрес в задачу; если терялось время публикации, попросите сообщать его вместе с ответом о выполнении.
Решение должно содержать ответственного и способ проверки. Фраза «быстрее реагировать» не говорит, кто и что делает. Можно записать: «Анна проверит применение нового порядка на следующей задаче цены и сохранит пример к ноябрьскому разбору».
Для проверки исправлений используйте готовый порядок после публикации. Если привычный шаг уже работает, оставьте его без дополнительной отчётности.
На следующем случае проверьте, помогло ли изменение
Когда появится подходящая задача, примените договорённость. Сохраните короткий результат: цена была утверждена до передачи, редактор не запрашивал её повторно, после публикации указан адрес и итог проверки.
Если рабочее время не измеряли, не заявляйте сэкономленные часы. Достаточно подтверждённого изменения: исчез конкретный недостающий ответ или стало понятно, кто проверяет результат.
Если новый порядок не применили, спросите почему. Возможно, он был неудобен, человек не знал о нём или случай требовал другого решения. На следующем месячном разборе начните с этой записи и уточните правило. Полезный итог — действующая договорённость на реальной задаче, а не ещё одна памятка, которую никто не открывает.