03 дек 2021

7 правил понятной постановки задач

Для кого
  • Руководители
  • Сотрудники
  • Все, кто хочет научиться ставить задачи
Знания и навыки
  • Постановка задач
  • Делегирование
  • Коммуникации
Время на чтение
  • 7 минут

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

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

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

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

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

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

Хороший пример: «согласовать договор оказания услуг».
Действие, которое нужно выполнить, понятно и постановщику и исполнителю и всем, кто прочитал формулировку.

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

Плохой пример: «проанализируй варианты ИТ-решений»
Что должно стать результатом анализа. Текст? Таблица? Презентация? Непонятно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Также в этом инструменте есть возможность фильтрации по датам и исполнителям.
Задачи в таск-трекере coda.io можно классифицировать по продуктам, статусам, срокам, ответственным, сложности
и любому другому признаку, который вы зададите.

А как настроить такой таск-трекер под себя, читайте в нашей статье “Как настроить таск-трекер за 4 дня без кода (кейс coda.io)”

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

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

Авторы статьи:
Дарья Зайцева
Смотрите также:
15 Авг 2023
Как собрать свой гибридный метод управления проектами за полтора месяца и восемь шагов?
В этой статье я расскажу, что представляют собой гибридные методы управления проектами, объясню, в чем их специфика, а также дам пошаговую инструкцию, как создать идеальный кастомный  (гибридный) метод, адаптированный для вашей компании.
07 Дек 2022
Как оценить проектную деятельность?
Основой для подготовки такой информации может стать система метрик, описывающая все области проектной деятельности и состоящая из трех групп: метрики результатов, метрики зрелости проектной деятельности и иные метрики функционирования системы проектной деятельности. В этой статье мы поговорим обо всех перечисленных группах.
23 Ноя 2022
Разработали новую методологию проектного управления. Что делать дальше?
Итак, руководством принято решение о необходимости изменений в проектной методологии. Собрана рабочая группа, изменения спроектированы и согласованы на высшем уровне. И это только начало пути, хотя уже проделана большая работа.
Подписаться на рассылку
Высылаем анонсы статей и полезные материалы
Прокомментировать статью
Текст сообщения
Имя, Отчество, Фамилия
Email

Комментарий успешно отправлен

Произошла ошибка при отправке. Попробуйте еще раз

Наверх
Здравствуйте! Если возникли вопросы, мы на связи.
Скопировано в буфер обмена