«Сделайте красиво», «проверьте аналитику» и «подготовьте к запуску» звучат как поручения, но каждый участник команды может понять их по-своему. В книге постановка задачи — общая работа двух сторон: автор описывает контекст и ожидаемый результат, исполнитель читает условие, задаёт вопросы и принимает обязательство только после прояснения. Плохо сформулированная задача не становится понятнее от того, что её внесли в трекер.
Что должно быть в задаче
- Цель и исходная ситуация. Какую проблему решает работа? Что известно из данных или исследований сейчас и по какому показателю проверите изменение?
- Результат и границы. Что нужно передать: экран, документ, решение, проверку гипотезы? Что обязательно входит в работу, а что пока нет?
- Этапы и критерии приёмки. Как будет двигаться работа и по каким признакам постановщик примет каждый важный результат?
- Контекст и ограничения. Где исходные материалы, тексты и примеры? Какие решения уже приняты, от кого зависит работа и к кому идти с вопросами?
- Заказчик, исполнитель и срок. Кто ставит задачу и принимает правки, кто отвечает за выполнение, когда нужен результат и когда проверить промежуточный итог?
Пример: одна задача, два прочтения
Представим, что команда готовит демонстрацию нового продукта. Это условный пример: его задача — показать разницу в формулировке.
«Подготовь демо к пятнице».
«К пятнице, 12:00, подготовь десятиминутную демонстрацию для команды продаж. Сейчас коллеги не могут самостоятельно показать первый сценарий клиенту. Используй тестовый аккаунт из описания проекта; покажи регистрацию, первый полезный сценарий и ограничение текущей версии. Результат — ссылка на работающий сценарий и план показа. В четверг проверим его вместе: два коллеги из продаж должны суметь провести показ без подсказок. Правки собираю и принимаю я».
Вторая формулировка длиннее, зато у исполнителя есть ориентир для решений и способ проверить эффект. Если показ регистрации не работает, это блокер. Если хочется добавить ещё пять функций, цель помогает удержать объём. А репетиция выявит проблемы до разговора с клиентом.
Проверка постановщика
- Я связал задачу с целью проекта и показал исходную ситуацию.
- Описал результат, границы работы, этапы и способ приёмки.
- Дал ссылки на материалы, тексты и примеры; назвал зависимости и ограничения.
- Назвал одного заказчика, который принимает работу и собирает правки.
- Согласовал с исполнителем срок и промежуточную проверку.
Проверка исполнителя
Принять задачу — не значит молча согласиться с любым текстом. Перед стартом полезно пересказать ожидаемый результат своими словами и задать вопросы: что считать готовым, какие материалы отсутствуют, что делать при конфликте приоритетов, кто принимает решение при задержке зависимой команды. Если срок выглядит нереальным, это стоит обсудить до начала работы, а не в день сдачи. После передачи своей части работы исполнитель помогает не потерять первоначальный замысел на следующих этапах.
Попросите исполнителя коротко назвать результат, критерий готовности и ближайший шаг. Если ответы отличаются от ваших ожиданий, поправьте задачу сейчас.
Шаблон, который можно скопировать
Карточка задачи
Цель и исходное значение: что хотим изменить и как сейчас?
Результат: что должно появиться или измениться?
Готово, когда: проверяемые критерии приёмки.
Не входит: что сознательно оставляем за рамками?
Этапы и материалы: шаги, ссылки, примеры, зависимости.
Заказчик и исполнитель: кто ставит, принимает и выполняет?
Срок и проверка: когда нужен результат и когда сверяемся?
После запуска: чем проверим влияние на цель?
Форма может быть короче или длиннее — в зависимости от задачи. Главное, чтобы она помогала двум сторонам договориться, а не превращалась в обязательную анкету ради анкеты.
Когда закрывать задачу
Принять сделанный артефакт и увидеть эффект — разные шаги. После выпуска проверьте, повлияло ли решение на цель и исчезла ли исходная проблема. Если нет, по результатам проверки нужна следующая итерация или решение отказаться от идеи. Работа не должна навсегда оставаться «готовой» только потому, что карточку закрыли в трекере.