Страшный, но часто сбывающийся сон руководителя проектов: ставишь коллеге задачу, а результат получаешь не тот, что нужно. 

Возьмем например систему по защите персональных данных, к которой может подключиться любой желающий: от ИП Иванова, до налогового органа, как в этот раз. Руководитель проекта хочет понять, как подключить к системе такую крупную организацию и ставит коллеге задачу: “опиши варианты подключения пользователей к системе”.

При такой постановке равны шансы получить ответ как в электронном письме, так и в таблице. Ещё может случиться лонгрид на три страницы печатного текста. Также есть шанс не узнать нужной информации об особенностях подключения налоговой к системе, так как в задаче об этом ни слова. Итог: если результат оказался не тот, то задачу уточнят, ответственный всё переделает, теряя время и желание работать, а руководитель останется недоволен и засомневается в компетенциях коллеги.

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

1. Задача начинается с глагола

Плохой пример: «договор оказания услуг».

Сразу хочется бежать и уточнять, что надо сделать. Подготовить? Согласовать? Найти? 

Хороший пример: «согласовать договор оказания услуг».

Действие, которое нужно выполнить, понятно и постановщику и исполнителю и всем, кто прочитал формулировку.

2. Из формулировки понятно, какой результат ожидается

Плохой пример: «проанализируй варианты ИТ-решений»

Что должно стать результатом анализа. Текст? Таблица? Презентация? Непонятно.

Хороший пример: “подготовь таблицу с вариантами ИТ-решений и их преимуществами”

При одном прочтении задачи вырисовывается образ того, что получится в итоге.

3. В формулировке НЕ описана технология

Плохой пример: “Подготовь таблицу с вариантами ИТ-решений, которая будет содержать следующие столбцы: ИТ-решение, преимущество, минусы, затраты в рублях, комментарий. Таблицу также нужно сравнить с той, что делали в прошлом году и учесть расхождения”

Лучшее, враг хорошего. Не увлекайтесь с передачей образа результата в задаче и переписыванием технологии, алгоритма, описания результата. Через множество дополнительной информации трудно пробраться к сути задачи и понять, что сделать.

Хороший пример: “Подготовь таблицу с вариантами ИТ-решений и их преимуществами”

А все дополнительные вводные укажите отдельно. Например, так:

4. Одна задача – один ответственный 

Плохой пример, это тот, где у одной задачи сразу три ответственных.

Потому что если ответственных много, то их нет. Каждый может понадеяться на другого, а с кого в итоге спрашивать непонятно.

Хороший пример, это когда задача декомпозирована настолько, что можно назначить единственного ответственного. 

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

5. Указывайте связи

Например, чтобы провести обучение, нужно подготовить к нему материалы.

Плохой пример в этом случае тот, в котором задачи “проведи обучение” и “подготовь материалы” не учитывают длительность и сроки друг друга, а также то, что вовремя не подготовленные материалы блокируют задачу по проведению обучения.

Хороший пример тот, в котором учитываются взаимосвязи и блокировки задач. Связь такая может указываться как в тексте, например: “подготовить материалы для обучения, которое будет проведено 05.12.2021”, так и в инструменте по работе с задачами, как здесь:

6. Делите сроки на критичные и некритичные

Критичные сроки обусловлены взаимосвязями задач, то есть если обучение нужно провести 5-го декабря, то материалы нужно подготовить не позднее 3-го декабря. Срок связанной задачи подстраивается под главную.

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

7. Классифицируйте задачи

Практически любой инструмент для работы с задачами, если, конечно, речь не о бумажном блокноте, позволяет классифицировать задачи по какому-то признаку: по исполнителям, по приоритетам, по срокам и тд.

Такой подход позволяет сортировать и фильтровать задачи, ускоряет их поиск и рассмотрение. Вот несколько примеров классификации:

Задачи в Trello классифицированы по продуктам, статусам (бэклог, в работе, выполнено), модулям.

Также в этом инструменте есть возможность фильтрации по датам и исполнителям.

Задачи в таск-трекере coda.io можно классифицировать по продуктам, статусам, срокам, ответственным, сложности и любому другому признаку, который вы зададите. Это очень удобно, а как настроить такой таск-трекер под себя, читайте в нашей статье “Как настроить таск-трекер за 4 дня без кода (кейс coda.io)”

Делитесь вашим опытом работы с задачами в комментариях и подписывайтесь на наш телеграмм-канал Уж&Ёж. А если вы начинающий или опытный специалист в сфере project management и хотите рассказать о своем опыте, пишите в телеграмм @Malakhov_Andrey, создадим полезное вместе :)

Автор: Дарья Зайцева