Задача — это не просьба.
Задача — это инструкция с однозначным результатом.
Если результат можно интерпретировать по-разному — задача поставлена плохо.

Большинство проблем в проектах появляются не из-за сложности работы, а из-за плохой постановки задач. Когда задача поставлена плохо:

• исполнитель делает не то, что ожидалось;
• появляется бесконечный цикл правок;
• теряется время;
• растёт раздражение клиента и команды;
• PM вынужден постоянно «переобъяснять» задачу.

И наоборот, хорошо поставленная задача экономит часы коммуникации и снижает количество ошибок почти до нуля.

Задача — это минимальная единица работы в проекте, которая имеет:

• понятный результат;
• исполнителя;
• срок;
• контекст;
• критерии готовности.

Если хотя бы одного элемента нет — это не задача, а просто сообщение. Главная ошибка новичков в том, что они пишут «сделать баннер» и считают, что этого достаточно. Для исполнителя это не задача, а вопросы: Какой баннер? Для чего? В каком формате? Какие тексты? Какой стиль? Какие размеры?

Задача: Разработать лендинг для продвижения продукта X.
Цель: Сбор заявок на продукт.
Структура:

• первый экран с оффером;
• блок преимуществ;
• блок кейсов;
• форма заявки.
• Материалы:тексты в приложении;
• изображения из брендбука.

Форматы: Desktop + mobile.
Срок: 12 мая, 18:00.
Критерии готовности:

• макет согласован клиентом;
• подготовлены версии для разработки.

Хорошая задача всегда состоит из 7 элементов

1. Название задачи (конкретно)

2. Контекст (зачем это нужно)

Один и тот же запрос может означать разные вещи.

Например, сделать сайт, может означать:

• маркетинговый лендинг;
• корпоративный сайт;
• интернет-магазин;
• внутренний портал;
• презентационный сайт.

Без контекста задача не существует.

3. Результат (что должно получиться)

4. Материалы (все, что есть):

• тексты;
• изображения;
• ссылки;
• брендбук;
• референсы.

5. Ограничения (то, что нельзя нарушать):

• бренд;
• размеры;
• сроки;
• технические требования.

6. Срок (конкретные дата и время)
Не «срочно», не «вчера».

7. Критерии готовности (амый важный элемент)
Описывает как понять, что задача выполнена.

Критерии готовности важнее всего. Без критериев:

• исполнитель считает задачу завершённой;
• PM считает, что работа не готова;
• клиент недоволен;
• начинается цикл правок.

Например:

Разработчик думает не картинками, а логикой. Хорошая структура для задач разработчику:

• описание функционала;
• пользовательский сценарий;
• входные данные;
• ожидаемый результат;
• edge cases (исключения).

Дизайнеру важны: цель, аудитория, референсы, ограничения.

PM не должен «додумывать» за исполнителя. PM должен проверять:

• совпадает ли результат с задачей;
• выполнены ли критерии;
• нет ли скрытых допущений.

Как задачи связаны с планированием
Если задача плохо поставлена — планирование бесполезно. Потому что сроки считаются для несуществующей реальности.

Задачи — это язык общения внутри проекта. Если задачи написаны плохо — проект разваливается на уровне коммуникации. Если задачи написаны хорошо — проект становится управляемым, даже если он сложный.

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