7 правил понятной постановки задач
Страшный, но часто сбывающийся сон руководителя проектов: ставишь коллеге задачу, а результат получаешь не тот, что нужно.
Возьмем например систему по защите персональных данных, к которой может подключиться любой желающий: от ИП Иванова, до налогового органа, как в этот раз. Руководитель проекта хочет понять, как подключить к системе такую крупную организацию и ставит коллеге задачу: “опиши варианты подключения пользователей к системе”.
При такой постановке равны шансы получить ответ как в электронном письме, так и в таблице. Ещё может случиться лонгрид на три страницы печатного текста. Также есть шанс не узнать нужной информации об особенностях подключения налоговой к системе, так как в задаче об этом ни слова. Итог: если результат оказался не тот, то задачу уточнят, ответственный всё переделает, теряя время и желание работать, а руководитель останется недоволен и засомневается в компетенциях коллеги.
За время работы наша команда накопила много похожих примеров, рассматривая которые и родились семь простых, но важных правил постановки задач.
1. Задача начинается с глагола
Плохой пример: «договор оказания услуг».
Сразу хочется бежать и уточнять, что надо сделать. Подготовить? Согласовать? Найти?
Хороший пример: «согласовать договор оказания услуг».
Действие, которое нужно выполнить, понятно и постановщику и исполнителю и всем, кто прочитал формулировку.
2. Из формулировки понятно, какой результат ожидается
Плохой пример: «проанализируй варианты ИТ-решений»
Что должно стать результатом анализа. Текст? Таблица? Презентация? Непонятно.
Хороший пример: “подготовь таблицу с вариантами ИТ-решений и их преимуществами”
При одном прочтении задачи вырисовывается образ того, что получится в итоге.
3. В формулировке НЕ описана технология
Плохой пример: “Подготовь таблицу с вариантами ИТ-решений, которая будет содержать следующие столбцы: ИТ-решение, преимущество, минусы, затраты в рублях, комментарий. Таблицу также нужно сравнить с той, что делали в прошлом году и учесть расхождения”
Лучшее, враг хорошего. Не увлекайтесь с передачей образа результата в задаче и переписыванием технологии, алгоритма, описания результата. Через множество дополнительной информации трудно пробраться к сути задачи и понять, что сделать.
Хороший пример: “Подготовь таблицу с вариантами ИТ-решений и их преимуществами”
А все дополнительные вводные укажите отдельно. Например, так:
4. Одна задача – один ответственный
Плохой пример, это тот, где у одной задачи сразу три ответственных.
Потому что если ответственных много, то их нет. Каждый может понадеяться на другого, а с кого в итоге спрашивать непонятно.
Хороший пример, это когда задача декомпозирована настолько, что можно назначить единственного ответственного.
А если помощники всё равно нужны или сотрудника нужно официально привлечь к выполнению задачи, назначайте их соответственными. Кто ответственный, а кто соответственный должно быть ясно из того инструмента, в котором вы фиксируйте задачи. Например:
5. Указывайте связи
Например, чтобы провести обучение, нужно подготовить к нему материалы.
Плохой пример в этом случае тот, в котором задачи “проведи обучение” и “подготовь материалы” не учитывают длительность и сроки друг друга, а также то, что вовремя не подготовленные материалы блокируют задачу по проведению обучения.
Хороший пример тот, в котором учитываются взаимосвязи и блокировки задач. Связь такая может указываться как в тексте, например: “подготовить материалы для обучения, которое будет проведено 05.12.2021”, так и в инструменте по работе с задачами, как здесь:
6. Делите сроки на критичные и некритичные
Критичные сроки обусловлены взаимосвязями задач, то есть если обучение нужно провести 5-го декабря, то материалы нужно подготовить не позднее 3-го декабря. Срок связанной задачи подстраивается под главную.
Сроки не связанных друг с другом задач не критичны в том смысле, что можно установить любой срок в зависимости от длительности выполнения, загрузки и тд., не подстраиваясь дополнительно под взаимосвязи.
7. Классифицируйте задачи
Практически любой инструмент для работы с задачами, если, конечно, речь не о бумажном блокноте, позволяет классифицировать задачи по какому-то признаку: по исполнителям, по приоритетам, по срокам и тд.
Такой подход позволяет сортировать и фильтровать задачи, ускоряет их поиск и рассмотрение. Вот несколько примеров классификации:
Задачи в Trello классифицированы по продуктам, статусам (бэклог, в работе, выполнено), модулям.
Также в этом инструменте есть возможность фильтрации по датам и исполнителям.
Задачи в таск-трекере coda.io можно классифицировать по продуктам, статусам, срокам, ответственным, сложности и любому другому признаку, который вы зададите. Это очень удобно, а как настроить такой таск-трекер под себя, читайте в нашей статье “Как настроить таск-трекер за 4 дня без кода (кейс coda.io)”
Делитесь вашим опытом работы с задачами в комментариях и подписывайтесь на наш телеграмм-канал Уж&Ёж. А если вы начинающий или опытный специалист в сфере project management и хотите рассказать о своем опыте, пишите в телеграмм @Malakhov_Andrey, создадим полезное вместе :)
Автор: Дарья Зайцева