Народ. Принесли вам суперштуку, которая сначала сделает немного больно, а потом — очень хорошо. Её давно используют в узких кругах, пора сделать её популярной.
Называется «понимание задачи».
Если кратко: когда к вам пришли с какой-то новой задачей, сначала вы всё внимательно выслушиваете и задаёте вопросы. А потом вы сами пишете некий документ или сообщение, в котором описываете, как вы поняли свою задачу и что именно будете делать. И даёте на согласование тому, кто вам это поручил. И пока вам не подтвердят, что вы всё правильно поняли, вы не начинаете работу.
Зачем это: чтобы не переделывать. Чтобы те, кто вам что-то поручил, отвечали за свои решения. Чтобы вас не эксплуатировали.
Теперь погружаемся.
Ситуация со стороны специалиста
Вы специалист, например аналитик. В компании есть сайт. К вам приходит менеджер: «Вась, есть новая задача. Нам нужна статистика по всем страницам сайта — сколько там пришло людей и сколько из них купили. Сделаешь до пятницы?»
Вам всё понятно: нужно выгрузить эксельку, в которой будет список адресов страниц, число посещений и число кликов по кнопке «Купить». Сначала будут посещаемые, в конце — нет. Три столбца. Вы уточняете, за какой период нужна статистика — вам говорят, что за месяц.
До вечера пятницы вы сделаете что-то такое:
Ситуация со стороны менеджера
Вы менеджер в этой же компании. Вам прилетело, что сайт не продаёт, и нужно срочно определить, какие направления на сайте нужно развивать. Вы поручаете аналитику сделать вам отчёт, какие страницы нужно развивать.
В пятницу вечером вы ожидаете от исполнителя что-то такое:
Вы получаете что-то совсем другое, и в субботу-воскресенье все будут на ушах: аналитик будет переделывать данные, дизайнер — рисовать, вы — рулить процессом.
Как можно было бы предотвратить проблему
Менеджер: «Вась, есть новая задача, такая-то. Принимаешь? Напиши, как понял»
Вася:
Это и есть понимание задачи.
Обратите внимание: тут написано, что именно будет делать исполнитель, в каком объёме, какой будет результат. Не просто «сделать аналитику», а в деталях, что именно будет происходить. Что-то вроде технического задания для самого себя.
Менеджер смотрит на это и такой: «Не, погодь!». Оказывается, аналитик Вася плохо понял задачу: нужно не Эксель, а презентацию. И не с 1 января, а более живую осеннюю статистику (потому что в январе люди отдыхают). И не просто кликов, а именно тех кликов, которые привели к фактической продаже — это разные вещи. И хорошо бы не впритык к пятнице, а пораньше.
Аналитик Вася смотрит на эти комментарии и такой: «В смысле?!» В частности:
- Он начнёт делать работу только в четверг, до этого времени занят.
- Он не знает, какие клики по кнопке дали продажу — таких данных нет в принципе, потому что работает отдел продаж.
- Он не успеет сделать презентацию в PowerPoint.
Вася и Костян посидят над этими противоречиями пять минут и придумают так:
Это тоже понимание задачи — только теперь уточнённое. В итоге задача изменилась, но теперь все участники процесса сделают ровно то, что нужно именно в этой ситуации.
Почему это проблема
Во-первых, у каждого человека своё представление о работе и результате. Примеры:
Думает Костя | Думает Вася |
Сделать презентацию | Выгрузить эксельку |
К началу пятницы | К концу пятницы |
Сделать готовый продукт | Дать данные для чужого продукта |
Предусмотреть все нюансы | Сделать ровно то, что попросили |
Предупредить о проблемах заранее | Успеть в срок как получится |
Во-вторых, при обсуждении задачи могут вскрыться детали, о которых кто-то не знал. Например, когда менеджер говорит «выгрузи данные за месяц», он может не вспомнить, что в январе данные плохие, а в декабре — хорошие. Он думает, что аналитик сам про это вспомнит.
Или, например, менеджер хотел нагрузить человека большой работой, а тот и так перегружен. Это всплыло только в процессе обсуждения, поэтому они перестроили задачу.
И последнее: иногда ситуация быстро меняется. Я сегодня ставлю задачу, и мне нужно что-то одно. А завтра, когда исполнитель начинает эту задачу делать, нужно уже что-то другое. Хорошо бы обсудить это.
Почему обычно не составляют понимание задачи
Составлять понимание задачи — это ещё одно дополнительное действие. В кратком виде оно может занимать пять минут, а для сложных проектов — целый час. Обычно хочется кивнуть головой и просто пойти делать — типа сэкономил время.
Но если вдруг ты не понял свою задачу, ты рискуешь потом переделать её всю целиком. То есть ты на старте сэкономил 5 минут, а потом потратил дополнительные 5 часов.
Сами менеджеры часто не настаивают на составлении понимания задачи. Мол, «я же всё сказал, задача передана, работаем». Это признак неопытности: любой бывалый менеджер знает, что переданная задача — не значит понятая.
Всегда ли это нужно?
Понимание задачи нужно писать на все новые задачи. Когда пришёл новый человек, новый тип задачи, новые условия и обстоятельства.
На типовые задачи и которые уже много раз делали — уже нет необходимости.
Дополнительные бонусы
Защита исполнителя. Если исполнитель согласовал понимание задачи, заказчик больше не может соскочить со словами «я не этого просил». Нет, дружок, ты мне согласовал именно эту работу. Изволь платить или принимать работу. Согласование понимания задачи — это обоюдная ответственность. Исполнитель внимательно его составляет, а заказчик — внимательно принимает.
Защита заказчика. Если исполнитель сделает ерунду, можно будет вернуться к его пониманию задачи и свериться. Если это действительно ерунда, исполнитель сам это увидит и исправит. А если это вы приняли неточное понимание задачи — в следующий раз согласуете его внимательнее.
Лучшее решение задачи. В хорошем ПЗ уже прописано решение. Это решение можно заранее улучшить. Например, что лучше: нагружать аналитика или дать доступ менеджеру? Возможно, в этой ситуации второй вариант лучше. Без написанного понимания задачи оно бы не пришло.
Альтернативный взгляд на задачу. Заказчик может не знать каких-то нюансов, которые влияют на результат. В нашем случае — что невозможно связать клик на сайте с фактической продажей. Или что менеджер может сам извлечь нужные данные, если аналитик проведёт инструктаж. Узнать это можно, только смотря на документ.
Немного затягивает процесс. Это крамольная мысль, но это правда: примерно половина приходящих к вам задач на самом деле не являются задачами и их можно не делать. Проверить это легко: если менеджер не готов обсуждать эту задачу после того, как он её на вас скинул, — это неважная задача. Пишете понимание задачи, возвращаете мяч на его сторону, менеджер пропадает, а вы идёте на обед.
Короче:
Лучше сейчас за 5 минут описать понимание задачи, чем потом 5 часов всё переделывать 🗡
Источник
Термин «понимание задачи» придумал Артем Горбунов где-то между 2007 и 2008 годом. Бюро Горбунова популяризует этот термин с тех пор.
Пониманием задачи в бюро называют две вещи:
- Процесс, когда исполнитель идет к клиенту и выясняет, что клиенту нужно.
- Документ, который готовит исполнитель перед стартом проекта.
Понимание задачи — обязательная часть работы: сначала бюро встречается с клиентом, готовит документ, и если документ согласован — составляется договор.
Читайте об этом статью 2013 года: bureau.ru
Для тех, кто хочет управлять
Менеджеры — это связующее звено в любой ИТ-компании. Без них в компании хаос, переработки и сорванные сроки. Хороший менеджер — на вес золота. Платят соответствующе.
Лучше всего в этой роли раскрываются эмпатичные, организованные и внимательные люди. Если это про вас, начните с бесплатной части курса «Практикума» про управление проектами. Если зайдёт — можно стать востребованным специалистом и работать в диджитале.