Карточка почти дошла до колонки «Готово», но редактор ещё не принял текст, а две ссылки ведут не туда. Исполнитель считает работу законченной; команда видит незакрытые проверки. Definition of Done (DoD, «определение готовности») задаёт общий стандарт: какие условия должны выполняться до того, как результат можно назвать готовым. В Scrum правило относится к качеству Инкремента продукта. Для повторяющихся задач вне разработки команда может взять сам принцип общего стандарта и составить собственный список проверок. От требований одной статьи общий стандарт отличается областью действия: его применяют к серии похожих результатов и проверяют вручную перед завершением карточки.
Что означает общий стандарт готовности
Definition of Done в Scrum Guide означает формальное описание состояния Инкремента, который соответствует требуемым для продукта мерам качества. Общее определение даёт участникам одинаковое понимание завершённой работы. Элемент бэклога, не соответствующий DoD, нельзя считать частью Инкремента. Термин пришёл из Scrum, поэтому переносить его на любую карточку без оговорки было бы неточно.
За пределами Scrum команда может использовать практическую адаптацию: договориться об обязательном минимуме для серии однотипных результатов. Например, контент-команда считает статью подготовленной к публикации, когда редактор принял текст, факты сверены с источниками, ссылки открываются и метаданные заполнены. Конкретный список команда определяет сама. Он не становится официальным правилом Scrum для редакции и не превращает канбан-доску в Scrum-систему.
Общий стандарт нужен там, где слово «готово» разные участники понимают по-разному. Автор закончил черновик, редактор завершил проверку, а ответственный за публикацию получил файл без обложки. Если команда различает состояния «Написано», «На проверке» и «Готово», последнее должно иметь согласованную границу. Иначе колонка сообщает только мнение человека, который передвинул карточку.
Стандарт описывает результат и доказательство, а не каждое движение исполнителя. Формула «ссылки проверены» слаба: непонятно, какие ссылки и как обнаружить ошибку. Проверяемый вариант: «внутренние ссылки статьи открывают страницы, соответствующие анкорам; редактор отметил проверку в карточке». Для правила важен наблюдаемый итог. Способ проверки может быть ручным, если команда не настроила автоматизацию.
Чем DoD отличается от соседних правил
DoD относится к завершению серии работ по общему стандарту, критерии приёмки описывают результат отдельной задачи, а Definition of Ready (DoR, «определение готовности к работе») помогает решить, можно ли задачу брать в работу. У правил разные моменты применения. Команда может использовать их вместе, не дублируя один и тот же список в трёх местах.
| Правило | Когда применяют | Что проверяют на примере статьи |
|---|---|---|
| Definition of Ready | До начала работы | Есть тема, адресат, цель и доступные исходные материалы. |
| Критерии приёмки | При проверке конкретной статьи | Раскрыт согласованный вопрос, приведён нужный пример и выдержан формат задания. |
| Definition of Done | Перед признанием результата готовым | Текст принят редактором, факты и ссылки проверены, метаданные подготовлены. |
Когда нужны критерии приёмки
Критерии приёмки нужны, когда конкретная задача обещает результат со своими условиями. Для статьи о Definition of Done таким условием может быть сравнение DoD с DoR и критериями приёмки на одном примере. Для следующей статьи условие будет другим. Общий стандарт редакционной проверки при этом сохраняется, если команда не пересмотрела его осознанно.
Не добавляйте в общий DoD требование «сравнить DoD с DoR»: оно относится только к текущему материалу. Поместите частное условие в описание карточки. При проверке результата редактор сначала сверит содержание с заданием, затем применит общий минимум качества. Когда условия задачи меняются, команде не приходится переписывать стандарт для всех статей.
Когда проверяют входную готовность
Входную готовность проверяют перед началом работы: исполнитель должен понимать, какой результат нужен и на каких исходных данных его готовить. DoR полезен как название такого рабочего соглашения, но Scrum Guide не устанавливает обязательный артефакт с этим именем. Для редакции достаточно спросить, определены ли тема, читатель и источник обязательных фактов.
Карточка может быть готова к работе и ещё далека от выполнения DoD. Если материалов нет, задачу лучше уточнить в бэклоге до начала работы, чем переносить её на этап исполнения и ждать ответа в середине процесса. Граница между входом и выходом показывает, где именно возникло ожидание.
Как составить общий стандарт
Общий стандарт составляют из повторяющихся обязательных проверок, которые защищают результат от известных возвратов или ошибок. Команда просматривает недавно завершённые задачи, выписывает причины возврата и отделяет общие условия от требований одного заказа. Затем каждый пункт получает наблюдаемый результат, место доказательства и ответственного за проверку. Первая версия остаётся короткой: список ещё предстоит испытать на реальной работе.
Какие проверки повторяются у команды
Повторяющиеся проверки ищут в конкретных возвратах. Если статьи возвращались из-за неподтверждённых чисел, в стандарт попадает сверка чисел с источниками. Если ссылки вели на соседнюю тему, нужен пункт о соответствии анкора целевой странице. Пожелание «писать интересно» не даёт исполнителю и редактору одинакового способа проверки.
Для первой редакционной версии можно взять такие пункты. Таблица показывает рабочий пример, а не универсальный шаблон Definition of Done.
| Категория | Проверяемый пункт | Доказательство | Кто сверяет |
|---|---|---|---|
| Факты | Числа и продуктовые утверждения сверены с указанными источниками | Ссылки на источники рядом с утверждениями | Автор, затем редактор |
| Ссылки | Каждая внутренняя ссылка открывается и ведёт к теме анкора | Открытые целевые страницы | Автор |
| Редактура | Замечания редактора обработаны; итоговый текст принят | Решение редактора в согласованном канале | Редактор |
| Подготовка | Заголовок, описание и обложка соответствуют финальному тексту | Заполненные материалы для публикации | Ответственный за публикацию |
Как сделать каждый пункт проверяемым
Проверяемый пункт называет объект, наблюдаемое условие и способ подтверждения. «Текст качественный» оставляет решение на вкус проверяющего. «Все фактические числа сверены с источниками, а расхождения исправлены» даёт понятное действие, хотя итоговую редакторскую оценку всё равно нельзя заменить одной отметкой.
Не требуйте одинакового доказательства для разных объектов. Для ссылки достаточно открыть целевую страницу и сравнить её с анкором; для экспертного утверждения может понадобиться первоисточник; для принятия текста требуется решение редактора. Если пункт нельзя проверить в разумном рабочем процессе, его надо уточнить либо исключить. Отметка без основания не делает материал готовым.
Кто поддерживает общий список
Общий список согласует команда, которая выполняет и принимает работу; назначенный владелец правила следит, чтобы версия оставалась актуальной. В контент-процессе владельцем может быть редактор. Его задача — собрать предложения после возвратов, обсудить изменения с авторами и объяснить, с какой работы действует новая формулировка.
Не превращайте каждое замечание по одной статье в новый постоянный пункт. Если требование связано с особым заказом, оно остаётся в карточке этого заказа. Если ошибка повторяется у разных материалов и имеет одинаковую проверку, пункт заслуживает места в общем стандарте. Договорённость должна быть доступна исполнителям до начала следующей задачи.
Как проверить первую версию на работе
Первую версию DoD проверяют вручную на нескольких повторяющихся задачах: исполнитель проходит пункты, редактор сравнивает отметки с результатом, а команда записывает неработающие формулировки. Проба нужна для настройки правила, а не для объявления процента успешности по маленькой выборке. Изменения вносят после разбора конкретных пропусков и лишних проверок.
Какие карточки взять для пробы
Для пробы возьмите карточки с разными форматами внутри одного процесса: инструкцию, обзор и обновление существующей статьи. У каждой должен быть тот же основной редакционный маршрут. Если один материал требует особого согласования, внесите его отдельно как критерий конкретной задачи. Не пытайтесь охватить одним DoD весь маркетинг, поддержку и разработку.
Покажите стандарт автору до начала работы. Автор заранее увидит, какие подтверждения понадобятся; редактор получит ту же версию списка. После проверки сравните не количество галочек, а случаи, в которых правило не помогло принять решение. Одного примера пропуска достаточно, чтобы обсуждать формулировку, но недостаточно для статистического вывода о процессе.
Что записать после проверки
После проверки записывают карточку, спорный пункт, обнаруженный результат и решение по правилу. Запись нужна, чтобы не править общий список по памяти. Рабочий журнал можно вести в одном согласованном месте; карточка остаётся источником деталей конкретной задачи.
| Карточка | Что обнаружили | Решение для общего правила |
|---|---|---|
| Инструкция | Ссылки открываются, но один анкор обещает другой материал | Уточнить пункт: проверять и открытие, и соответствие анкора |
| Обзор | Пункт об обложке не применим к обновлению без новой обложки | Указать область применения либо решение об исключении |
| Обновление статьи | Редактор принял текст, но версия для публикации не совпала с принятой | Добавить сверку финальной версии перед отправкой |
Таблица иллюстрирует возможный пробный разбор, а не результаты работы клиента Канбано. После пробы команда оставляет только обязательные повторяющиеся проверки. Возврат из-за частного требования исправляют в карточке, не раздувая общий DoD.
Как применять DoD вне разработки
Вне разработки DoD можно использовать как рабочую адаптацию общего стандарта для серии результатов. Для контент-команды результатом служит подготовленная к публикации статья. Редакция сама определяет момент готовности: принятие текста, подготовку материалов и передачу ответственному за публикацию. Публикация на сайте может быть отдельным этапом, если именно так устроен процесс команды.
| Общий минимум для статей | Условие только этой статьи |
|---|---|
| Факты сверены с указанными источниками | Сравнить DoD, DoR и критерии приёмки |
| Внутренние ссылки открываются и соответствуют анкорам | Показать пример правила для контент-команды |
| Редактор принял финальную версию текста | Не выдавать адаптацию вне Scrum за официальный артефакт |
| Заголовок, описание и материалы публикации готовы | Использовать заданный адрес и согласованный заголовок |
Общий минимум не подменяет критерии приёмки. Статья может пройти проверку ссылок и метаданных, но всё ещё не отвечать на главный вопрос своего задания. Тогда редактор возвращает карточку на доработку. Обратная ситуация тоже возможна: тема раскрыта, но финальная версия не подготовлена к публикации. Команда должна заранее назвать, какой именно результат колонка «Готово» обещает следующему участнику.
Что оставить условием конкретной задачи
Условием конкретной задачи оставляют тему, формат, нужный источник, особое согласование и любые требования, которые не повторяются у всей серии. Например, обзор сервисов может требовать одинаковых критериев сравнения, а инструкция — проверенного порядка действий. Общий стандарт отвечает за повторяющееся качество подготовки, но не описывает содержание каждого будущего материала.
Когда частное условие перестаёт быть частным, владелец правила обсуждает его перенос в общий минимум. Решение принимают по реальным возвратам и затратам на проверку. Иначе список растёт от случайных исключений, а исполнитель механически отмечает пункты, не читая их.
Как закрепить DoD на канбан-доске
DoD закрепляют на доске как ручное рабочее правило: общую версию хранят в выбранном командой доступном месте, короткие повторяющиеся проверки переносят в чек-лист карточки, а доказательства оставляют в описании или вложениях. Перед переносом карточки в «Готово» человек сверяет пункты. Канбано предоставляет доски, колонки, карточки, описания, чек-листы и вложения; отдельного подтверждённого объекта DoD или автоматической блокировки перехода в этой схеме нет.
Где хранить общий стандарт
Общий стандарт должен лежать там, где команда найдёт действующую версию до начала работы. Место выбирают участники: доступный документ или отдельная договорённость внутри рабочего пространства. В карточке конкретной статьи оставьте ссылку на общую версию либо короткую применимую выдержку. При обновлении стандарта владелец сообщает, какие карточки уже ведутся по старой версии.
Условия перехода между колонками можно закрепить как правила потока. Общее DoD отвечает на вопрос о конечном результате, а правило колонки может дополнительно определять, кто переносит карточку и что означает промежуточное «На проверке». Названия и количество колонок команда задаёт под свой процесс; развести состояния доски можно до переноса проверок в карточки.
Что перенести в чек-лист карточки
В чек-лист карточки переносят только короткие повторяющиеся действия: сверить факты, проверить ссылки, получить решение редактора, подготовить материалы публикации. Частные требования задания оставляют в описании карточки. Если команде нужно подробнее собрать критерии проверки, отдельная инструкция поможет не превращать один пункт в набор расплывчатых пожеланий.
Доказательство не обязательно помещать в текст галочки. Ссылку на источник можно указать в описании, файл обложки приложить к карточке, а решение редактора зафиксировать в согласованном месте процесса. Перед сдачей исполнитель сопоставляет отметку с доступным доказательством. Интерфейс Канбано не оценивает качество источника и не решает за редактора, принят ли текст.
Когда перемещать карточку в «Готово»
Карточку перемещают в «Готово» после ручной проверки применимых обязательных пунктов и условий самой задачи. Если факт не подтверждён, ссылка не открывается или редактор ещё не принял текст, карточка остаётся на рабочем этапе либо возвращается на доработку по согласованному процессу. Отметка в чек-листе не должна заменять реальное решение ответственного человека.
Одна граница готовности полезна и для измерения сроков: команда должна одинаково понимать момент окончания работы, прежде чем зафиксировать точку готовности для расчёта lead time. Сам DoD не рассчитывает метрику. Если команда считает завершением публикацию, а доска отмечает готовность после редактуры, данные о сроке будут отвечать на другой вопрос.
Какие ошибки делают правило формальным
Правило становится формальным, когда пункты нельзя проверить, список обрастает частными требованиями или галочки ставят без результата. Исправление начинается с конкретной карточки: какую ошибку правило пропустило, какое доказательство ожидали и кто должен был принять решение. Общий стандарт меняют после разбора пропущенной ошибки.
Почему длинный список перестают проверять
Длинный список перестают проверять осмысленно, когда в нём смешаны обязательный минимум, пожелания и условия отдельных задач. Исполнитель видит одинаковые флажки у простого обновления и сложного исследования. Команда связывает каждый общий пункт с повторяющимся риском или требованием качества; остальные требования переносит в конкретные карточки.
Например, «сверить все факты с источниками» нужно и для короткой новости, и для большого обзора. «Сравнить семь сервисов» относится к одному обзору. Если пункт перестал применяться к типовым результатам, владелец правила обсуждает его удаление. Короткий DoD не означает мягкий: он оставляет только то, без чего команда действительно не называет работу законченной.
Как фиксировать исключения
Исключение фиксируют рядом с конкретной карточкой: какой пункт неприменим, по какой причине и кто согласовал решение. Молчаливая галочка скрывает расхождение между правилом и результатом. Если исключение повторяется, команде нужно уточнить область действия пункта и обновить общую версию.
Редактор может принять статью без новой обложки, когда обновляется только текст и прежнее изображение остаётся актуальным. В карточке достаточно отметить решение и причину; в общем стандарте следует уточнить, когда проверка обложки обязательна. Запрет на исключения ради видимости строгости не делает стандарт точнее.
Definition of Done работает, когда каждый участник может назвать одинаковую границу готовности и показать результат проверки. Начните с повторяющихся возвратов, запишите короткий общий минимум и проверьте его на реальных карточках. Для канбан-доски достаточно ручной сверки перед финальной колонкой; ответственность за качество остаётся у команды, а не у перемещения карточки.
Если хотите испытать правило на собственной доске, создать карточку DoD можно для одного повторяющегося процесса и пройти её проверки вручную.