Постановка задач подчиненным: все ли я делаю правильно?06.03.2018 12:18

Поставка задач в digital-среде давно перестала быть прерогативой исключительно руководителей. Задачи ставят и владельцы агентств, и руководители департаментов, и начальники отделов, и менеджеры, и дизайнеры, и программисты, и пиарщики, и маркетологи, и проектировщики и много кто еще. Да те же клиенты, например!

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

Три основных сценария

Итак, ошибки. Откуда растут ноги, и куда эти ноги могу привести? Пожалуй, здесь можно особо выделить три основных сценария:

1

Задача изначально непонятна исполнителю

• Как проявляется: исполнитель до и в процессе работы закидывает постановщика кучей вопросов. Или не делает ничего.

• Чем чревато: потерей времени постановщика и исполнителя за счет дополнительных коммуникаций.

2

У исполнителя нет необходимых ресурсов для выполнения задачи

• Как проявляется: исполнитель может отчаянно фрустрировать, ожидая новых вводных или ответов на свой запросы.

• Чем чревато: потерей времени исполнителя за счет дополнительных коммуникаций и ожидания предоставления нужных материалов/инструментов.

3

Исполнитель подумал, что понял задачу, но на самом деле это не так

Пожалуй, худший сценарий. Особенно, если задача масштабная.

• Как проявляется: В условленный срок вместо желаемого постановщик получает НЕЧТО.

• Чем чревато: потерей времени, срывом дедлайнов, негативной атмосферой в отделе.

Как же избежать появления подобных сценариев? Мы попросили представителей digital-рынка поделиться базовыми рецептами.

Регламент как основа основ

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

Комментарий: Василий Вишняков, генеральный директор интернет-агентства Bquadro

На все основные блоки работ мы разрабатываем регламенты. Есть свой регламент и на постановку задач. Мы смотрим на постановку задач шире: задачи могут ставится не только подчинённому, но и подчинённый может поставить задачу руководителю. От этого не меняется важность правильной её постановки. То есть не важно, кому задачи ставятся; они должны быть правильно оформлены и понятны исполнителю. Мы работаем через систему постановки задач, она здорово выручает. Понятно, что чёткость выполнения задачи зависит от того, насколько детально она описана. Мы работаем с сайтами и цифровыми продуктами, поэтому в регламенте у нас прописано, что является обязательным. Например, предоставление ссылок на страницы, даже если и так понятно, о чём идёт речь. Это же касается и скриншотов. В задаче обязательно должен быть указан дедлайн, отмечено время, которое отводится на её выполнение. Также для нас важна формализация названия каждой задачи, корректное указание срочности. В задаче должны содержаться все документы, которые имеют отношение к её реализации (техническое задание, макеты, медиафайлы и пр.), чтобы не тратить время исполнителя на их поиски.

1000 и 1 вопрос

Второй рецепт отлично подходит для ситуаций, когда по каким-то причинам невозможно напрямую повлиять на постановщика задач. Чаще всего в этой роли выступает представитель заказчика.

Комментарий: Артем Соколов, директор по маркетингу InSales

Самая распространенная ошибка при постановке задач — это лень. Некоторые менеджеры проектов ленятся писать огромные ТЗ дизайнеру или верстальщику, обходятся объяснениями голосом. Это плохая практика: как гласит одна знаменитая поговорка, «Нет ТЗ — результат ХЗ». Поэтому наши менеджеры проектов принимают от заказчиков работу в любом виде (с подробным ТЗ, без него), задают много наводящих вопросов, составляют ТЗ и только после этого отправляют проект в работу. Таким образом повышается не только качество работ, но и дисциплина сотрудников и общее отношение к проектам.

SCRUM, я люблю тебя

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

Комментарий: Виктор Пермяков, генеральный директор студии Vikiweb

Наша компания использует в работе SCRUM — все процессы распределяем на спринты. Разбив одну большую задачу на несколько, мы тем самым ускоряем сроки реализации, приемки и сдачи работ. Исполнитель приступает к задаче, только после полного понимания для чего это задача поставлена и какую цель она за собой несет. Тем самым мы экономим время, минимизируем издержки, и на выходе получаем качественный продукт и довольного клиента.

Все придумано до нас

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

Комментарий: Агентство CreativePeople, коллективное мнение

У нас все просто — молодым менеджерам на стол кладется распечатка из «Энциклопедии профессора Фортрана». Это не значит, что мы относимся к дизайнерам, как к роботам. Мы просто ценим их время. Задача должна отвечать принципу «исчерпывающей информации» — в идеальном случае исполнитель не должен задать ни одного уточняющего вопроса. Ошибка: прямая трансляция слов клиента исполнителю. Все нужно переварить и понять, почему клиент сказал так, а не иначе. Комментарий «листья недостаточно зеленые» не всегда означает, что их нужно сделать просто зеленее. Проблема может быть совсем в другом. Менеджер должен защищать творца от неполной/избыточной, невнятной, эмоциональной формулировки.

Постановка задач: разбор по молекулам

Что же из себя должен представлять целостный подход к постановке задач? Наверное, все знают про SMART (задача должна четко сформулирована, результат должен быть измеряем, задача должна быть достижима и актуальной). Следующий спикер настаивает, что этого мало, важно, чтобы это понимание было на уровне ДНК, на уровне мышления того, кто ставит задачу. Мы попросили его подробнее рассказать о принципах постановки задач, практикуемых в агентстве ДАЛЕЕ.

Комментарий: Константин Нефедов, управляющий партнер digital-агентства «ДАЛЕЕ»

Начнем с терминологии. Если речь идет о постановке нетехнических задач, то важно уметь отделять задачи и проекты, поручения и проблемы. Проект — это набор задач, а поручение — это атомарная единица, в которой должно быть понятно, что делать одному исполнителю и он должен быть обеспечен всем необходимым для ее выполнения. Проблема — это вид задач, в которых на текущий момент не ясны ни конечные результаты, ни способы решения. В задачах же известен результат или цель выполнения, но нужно найти способ решения. Давайте сразу определим роли — Клиент, Менеджер проекта, Исполнитель (программист, верстальщик, дизайнер). В практике деятельности агентства ДАЛЕЕ мы давно пришли к следующим правилам: Исполнитель не общается с клиентом. Задачу исполнителю ставит менеджер. Конечно, исполнители могут общаться с клиентом в начале проекта или, когда нужно более подробно при встрече или голосом что-то обсудить, но тем не менее фактическую задачу ставит менеджер. Задача ставится только в трекере (мы используем Jira). Клиент может общаться с менеджером в любом удобном формате, но по итогам менеджер должен сформулировать результаты своего общения в виде задачи и поставить ее в трекер. Важно придерживаться правила: одна задача — один исполнитель. Не ставьте одну задачу на нескольких исполнителей, разбивайте задачи как минимум на количество исполнителей. Теперь набор задач мы должны разбить на проекты и задачи и дальше распределить их в соответствии с квалификацией исполнителей. Дальше мы должны обеспечить исполнителя всем необходимым для выполнения. Правило номер 0 — в задаче не должно быть ничего лишнего. Из задачи нужно убрать все, что не имеет отношения к ее выполнению конкретным исполнителем. Чтобы понять, что нужно ответьте на вопрос — что/где/когда. То есть, нужно указать где находится, то с чем мы работаем. В виде аттачей мы должны приложить все материалы, которые необходимы для выполнения. Также нужно описать какой результат мы хотим получить. Легко запомнить, как в школе чертили доску для решения задач: Дано, Решение, Ответ. За Решение отвечает исполнитель, а менеджер за Дано и Ответ. Теперь нам нужно получить подтверждение того, что исполнитель обладаем всем необходимым для выполнения задачи и получить оценку сроков разработки. Если речь идет о проектах, то нам нужно быть очень внимательными в тех задачах, результаты которых становятся входными данными для других задач. Постановка задач — это краеугольный камень всего процесса разработки. Мы должны понять, что задача менеджера — это обеспечение бесперебойного выполнения задачами исполнителя в его профессиональной сфере. Любая неточность или некорректность приведет к тому, что разработчик потратит больше времени на ее выполнение. В то же время, если задачи не проставлены на будущее, то разработчик будет не занят, если он выполнит задачу или у него возникнут вопросы по ее исполнению.

Чек-лист по постановке задач

Итак, вот обещанный чек-лист. Он представляет из себя краткий список вопросов, на которые необходимо ответить, чтобы убедится, что вы поставили задачу должным образом.

1Что именно нужно сделать?

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

2В какие сроки?

Исполнитель должен четко понимать, когда он обязан сдать работу. Одна из наиболее распространенных ошибок здесь — отсутствие временного люфта (постановщик не закладывает день-два на то, чтобы при необходимости можно было успеть внести изменения в результат работы исполнителя).

3Из каких этапов состоит данная работа?

Достаточно ли понятно вы их описали? Понятны ли исполнителю контрольные точки?

4Приложили ли вы сразу необходимые исходники, скриншоты, дали ли все нужные ссылки и контакты?

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

5В чем должен выражаться конечный результат?

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

6Объяснили ли вы исполнителю какого эффекта нужно достичь? Какие цели преследует эта задача?

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

7Нет ли в описании задач лишних вводных?

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

8 Прочитали ли вы описание задачи перед тем, как нажать кнопку «Поставить/Отправить»?

Нельзя забывать, что что-то кристально очевидное и понятное для вас, может быть не быть таковым для исполнителя. К тому же, крайне важно не допускать двусмысленных формулировок. Помните, что один из законов Мерфи гласит: Все, что может быть неправильно понятно, скорее всего будет понятно неправильно.

Полный текст статьи читайте на CMS Magazine