«Новы сайт ср-ки сжат»: основные принципы постановки задач

Менеджер проектов 9pm.agency Александра Руденко рассказала, как неправильно сформулированное поручение влияет на процесс работы.

«Новы сайт ср-ки сжат»: основные принципы постановки задач

Нашей команде приходится решать параллельно несколько маркетинговых задач для клиентов: помочь с выпуском нового продукта, сделать упаковку или промо-материалы, перезапустить сайт и подготовить контент.

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

За три года мы выработали свои принципы управления долгими проектами, совместив agile (гибкую методологию разработки) и здравый смысл. В этой статье я расскажу о том, как формулировать задачу так, чтобы команда вас поняла, выполнила задание вовремя, при этом с вами не ссорясь.

Как сформулировать и делегировать задачу

1. Начните с глагола

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

<i>Задачи без глагола выглядят как беглые заметки — они создают хаос и редко выполняются</i>
Задачи без глагола выглядят как беглые заметки — они создают хаос и редко выполняются

Что произойдёт, если к этим же самым заметкам добавить действие:

<i>Вы ещё не знаете, что внутри задачи, но уже понимаете, о чем она</i>
Вы ещё не знаете, что внутри задачи, но уже понимаете, о чем она

2. Поймите сами, что вы хотите получить в результате

Ответственность за выполнение задачи наполовину лежит на постановщике. Он формирует видение результата и помогает прояснить его исполнителю. Если же этого видения в вашей голове ещё нет — создайте заметку для себя и дайте задаче вызреть. Без чёткого обозначения результата вы потратите кучу времени на обсуждение задачи и, возможно, даже поссоритесь с исполнителем, если итог вам не понравится.

Из этого примера понятно, что постановщику требует коммерческое предложение, но непонятно, каким он его видит, для каких именно продуктов его писать, в каком формате, и почему всё так срочно.

<i>

















«Поди туда — не знаю куда, принеси то — не знаю что»



</i>
«Поди туда — не знаю куда, принеси то — не знаю что»

3. Превратите видение в текст

Если вы видите результат — вам очень просто выразить словами то, что вы хотите получить. Опишите задачу подробно, но без занудства. Важно, чтобы человек вас просто понял и выполнил задание.

Если вы поделите мысли на абзацы и выделите ключевые моменты — понять вас будет ещё проще:

<i>Уже значительно понятнее, но это не всё</i>
Уже значительно понятнее, но это не всё

4. Определите, когда задача считается выполненной

В каком случае задача по разработке коммерческого предложения будет считаться завершённой, а исполнитель сможет поставить рядом с ней галочку?

Вариантов множество:

  • ​Коммерческое предложение утвердит директор компании.
  • Коммерческое предложение поможет продать эквайринг тысяче клиентов.
  • Колл-центр утрвердит коммерческое предложение.
  • Коммерческое предложение будет размещено на корпоративном портале.
  • О появлении коммерческого предложения узнает весь колл-центр и так далее.

Каждый из нас по-разному видит конечный результат. Если вы хотите получить нужный — опишите конкретный критерий завершения:

<i>Так стало понятнее, когда задачу можно закрывать</i>
Так стало понятнее, когда задачу можно закрывать

5. Прикрепите дополнительные материалы

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

6. Обозначьте дедлайн

Задачи без крайнего срока очень долго болтаются в незавершённых и попадают в сектор «что-то важное» в голове исполнителя, только если они очень интересные. Хотите получить результат к конкретной дате  —  чётко задайте дедлайн с учётом всех форс-мажоров.

7. Назначьте ответственного и соисполнителей

У любой задачи должен быть один ответственный. Коллективная ответственность вроде бы существует, но на практике в любой сложной ситуации исполнитель скинет ответственность или поделит её с коллегой. Решите, кто лучше всего справится с задачей и сможет довести её до конца.

Если задача объемная и явно делится на подзадачи — делите и назначайте ответственного за каждую. Но у основной цели остается один ответственный, который контролирует соисполнителей.

Теперь задача выглядит вот так:

<i>Такую задачу можно обсуждать и брать в работу</i>
Такую задачу можно обсуждать и брать в работу

8. Проясните видение результата с исполнителем

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

Можно обратиться к инструкции Люды Сарычевой, о том, как понимать задачу. Её картинки хорошо иллюстрируют слово «видение».

Восемь признаков задачи, которая будет сделана хорошо

  1. Задача начинается с глагола.
  2. Постановщик чётко видит результат и понятно описывает задачу.
  3. Задача имеет критерий завершения​.
  4. К задаче прикреплены дополнительные материалы, которые помогают прояснить видение результата и экономят время.
  5. Должен быть обозначен дедлайн.
  6. Задача разбита на подзадачи, если она объёмная, и для их решения нужно несколько человек.
  7. Должны быть назначены ответственный и соисполнители.
  8. Исполнитель и постановщик одинаково видят результат.

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

Сравните, что было с задачей в самом начале:

<i>Ничего не понятно, вряд ли кто-то сделает её хорошо и вовремя</i>
Ничего не понятно, вряд ли кто-то сделает её хорошо и вовремя

И что стало:

<i>Так больше шансов получить нужный результат вовремя и без судорожной проверки каждого шага</i>
Так больше шансов получить нужный результат вовремя и без судорожной проверки каждого шага

Многие думают, зачем же так подробно расписывать задачу и тратить на это кучу времени: «Вот ещё, расписывать задачи и заниматься прикреплением ссылок. Я всё объяснил. Мы же в одном офисе, все друг друга видят и понимают, если надо — спроси».

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

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

1111
5 комментариев

Отлично! Большое спасибо, Саша!

1
Ответить

Спасибо, Рената! Рада, что статья оказалась полезной.

Ответить

"За три года мы выработали свои принципы управления долгими проектами, совместив agile (гибкую методологию разработки) и здравый смысл."

В agile нет здравого смысла "из коробки"? Кто являлся эталоном "здравого смысла"? С каждой итерацией "здравый смысл" улучшается (свят-свят)? Как замеряли обратную связь?

"В этой статье я расскажу о том, как формулировать задачу так, чтобы команда вас поняла, выполнила задание вовремя, при этом с вами не ссорясь."

Я так понимаю пересказали SMART, без отсылки к первоисточнику (ну или как минимум указать в списке использованной литературы, стоило).

Ответить

Владимир, согласна, не очень корректно выразилась об agile и здравом смысле. Принципы agile – это база, которую каждый адаптирует под себя. В нашем случае получилось именно так.

Во внутренней базе знаний у нас написано так: "Задачи нужно ставить по принципам SMART...", но я не стала указывать это в статье, потому что SMART это всего лишь принцип, а не первоисточник. В своей же статье я поделилась конкретным чек-листом для постановки задачи.

Ответить