Что считать выполненным: определение Done для команды

«Готово» — самое обманчивое слово в командной работе. Разработчик говорит «готово», когда код написан. Редактор — когда текст отправлен на вычитку. Менеджер — когда клиент принял работу и подписал акт. Пока эти «готово» не совпадают, задачи возвращаются, а «почти сделано» висит неделями.

Почему «готово» у всех разное

Каждый оценивает выполненность со своей позиции. Тот, кто делал работу, видит её законченной, как только его часть позади. Тот, кто принимает, ждёт результата, которым можно пользоваться. Между этими точками — проверка, правки, публикация, передача, и именно там задачи застревают.

Признаки того, что у команды нет общего понимания Done:

• задачи, отмеченные выполненными, возвращаются в работу;
• на встречах звучит «почти готово» — и так несколько недель подряд;
• перед сдачей клиенту выясняется, что «мелочи» никто не сделал;
• одни и те же замечания на проверке повторяются из задачи в задачу.

Каждый такой возврат стоит дороже, чем кажется. Исполнитель уже переключился на другую задачу, и чтобы доделать «мелочь», ему нужно заново вспомнить контекст. А тот, кто принимает работу, теряет доверие к статусу «выполнено» и начинает перепроверять всё подряд.

Что такое определение Done

Термин пришёл из Scrum: Definition of Done — общий для команды список условий, которые должны выполняться для любой задачи определённого типа, прежде чем её можно назвать сделанной. Это не пожелание, а договорённость: если хотя бы один пункт не выполнен, задача не закрывается.

Хорошее определение Done снимает споры. Не нужно обсуждать, достаточно ли проверен текст или протестирована функция, — достаточно открыть список и посмотреть, все ли пункты отмечены.

При этом определение Done нужно не только командам, работающим по Scrum. Оно полезно везде, где работа проходит через несколько рук: в агентстве, редакции, поддержке, бухгалтерии.

Определение Done и критерии приёмки

Их часто путают. Критерии приёмки описывают, что должно получиться в конкретной задаче: «форма отправляет заявку, письмо приходит менеджеру». Определение Done описывает, через что проходит любая задача этого типа: «код прошёл ревью, изменения описаны в заметках к релизу». Первое отвечает на вопрос «что сделать», второе — «как понять, что сделано полностью».

Обычно нужны оба. Критерии приёмки пишет постановщик в описании задачи, а определение Done живёт в шаблоне и одинаково для всех задач своего типа. Вместе они отвечают на вопрос, когда задачу можно закрыть, без споров и уточнений.

Как составить определение Done

1. Соберите тех, кто делает и принимает работу. Определение, придуманное руководителем в одиночку, будут обходить.
2. Выпишите, что происходит после «я закончил». Проверка, правки, согласование, публикация, уведомление — всё, что обычно делается до того, как результатом действительно можно пользоваться.
3. Оставьте только проверяемые пункты. «Качественно» — не пункт. «Вычитано вторым человеком» — пункт.
4. Разделите по типам работ. У статьи, релиза и задачи для клиента разный путь до Done, поэтому одного общего списка обычно не хватает.
5. Запишите туда, где идёт работа. Определение в документе, который никто не открывает, не работает. Оно должно быть внутри задачи.

На первую встречу хватит получаса и общего документа. Не стремитесь к идеальной формулировке: определение Done — рабочий инструмент, его можно и нужно править. Ниже — примеры, от которых удобно оттолкнуться.

Пример: разработка

• Код прошёл ревью у второго разработчика
• Тесты проходят, изменения проверены на тестовом стенде
• Изменения описаны в заметках к релизу
• Исходная задача закрыта и связана с релизом
• Тот, кто просил изменение, знает, что оно вышло

Пример: контент

• Текст вычитан вторым человеком
• Обложка и иллюстрации согласованы
• Ссылки и факты проверены
• Материал опубликован и добавлен в рассылку или анонс
• Ссылка на публикацию оставлена в задаче

Пример: работа для клиента

• Результат показан клиенту и принят им
• Правки внесены и подтверждены
• Файлы переданы в согласованном формате
• Закрывающие документы отправлены

Если времени на всё это нет

Начните с одного типа задач — того, на котором чаще всего бывают возвраты. Запишите три-четыре пункта, поработайте с ними пару недель и дополните тем, что всплывёт на практике. Определение, выросшее из реальных ошибок, приживается лучше придуманного заранее.

Задача сделана не тогда, когда вы закончили свою часть, а тогда, когда результатом можно пользоваться.

Как не превратить Done в бюрократию

Определение Done полезно, пока оно короткое и живое. Как только оно разрастается в регламент на две страницы, его перестают читать.

• Несколько пунктов на тип задачи. Пять–семь обычно достаточно. Если пунктов больше, часть из них, скорее всего, относится к отдельным задачам, а не к каждой.
• Не для мелочей. Задаче «переслать счёт» определение Done не нужно. Оно для работы, которая проходит через несколько рук.
• Пересматривайте. Раз в квартал или после заметной ошибки посмотрите, какие пункты помогают, а какие отмечают не глядя.
• Делайте пункты видимыми. Чек-лист внутри задачи работает лучше, чем правило, которое нужно помнить.
• Не путайте Done с контролем. Определение Done — договорённость команды о том, что значит «сделано», а не инструмент проверки людей. Если с его помощью ищут виноватых, пункты начнут отмечать формально.

Когда пункт неприменим

Бывает, что пункт к задаче не относится: внутренней правке не нужен анонс, а черновику — согласование с клиентом. Договоритесь, что такие пункты не удаляют молча, а отмечают с короткой пометкой «не требуется». Так видно, что о пункте подумали, а не забыли.

Как это сделать в DoneBy

1. Сделайте шаблон списка. Заведите список с типовой задачей, в которой чек-лист — ваше определение Done, и сохраните его как шаблон. Шаблоны списков есть в тарифах «Команда» и «Бизнес».
2. Используйте чек-лист в каждой задаче. Пункты определения Done отмечаются прямо в карточке, а прогресс виден в строке задачи. Технически в чек-листе может быть до 200 пунктов, но для определения Done обычно хватает пяти–семи.
3. Назначьте того, кто принимает. Исполнитель делает работу, а последний пункт чек-листа — «принято» — отмечает проверяющий. Упоминание через @ в комментарии сообщит ему, что задача готова к проверке.
4. Пригласите клиента гостем. В роли «Гость» человек видит только списки, которыми с ним поделились, может комментировать и отмечать свои задачи — пункт «принято клиентом» можно отдать ему самому.
5. Автоматизируйте последний шаг. Когда задачу закрывают, DoneBy отправляет вебхук task.completed: по нему можно, например, уведомить бухгалтерию или обновить статус в другой системе. Вебхуки доступны в тарифах «Команда» и «Бизнес».
6. Разбирайте сделанное вместе. Выполненные задачи собираются в блок «Сделано» внизу списка. По нему удобно на встрече пройти, что принято за неделю, и заметить, какие пункты определения Done чаще всего вызывают вопросы.

Если у разных типов работ разное определение Done, держите их в разных шаблонах: «Статья», «Релиз», «Задача клиента». При создании списка выбирайте подходящий — и нужный чек-лист окажется в задачах с первого дня.

Подробнее: подзадачи и чек-листы, списки и шаблоны, роли в пространстве, вебхуки.

Вывод

Общее определение Done — дешёвый способ убрать целый класс проблем: возвраты, вечное «почти готово» и сюрпризы перед сдачей. Составьте его вместе с теми, кто делает и принимает работу, оставьте только проверяемые пункты и положите внутрь задач в виде чек-листа. И помните, что определение — инструмент, а не регламент: пересматривайте его, когда оно перестаёт помогать. Хороший признак того, что всё работает, — слово «готово» снова означает одно и то же для всех.