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

16 апреля 2015, 08:29

5 принципов постановки задач

Тратите слишком много времени на уточнение задач от клиентов, коллег ли начальства? А потом еще и делаете не то, что от вас хотели? Давайте поговорим об этом.

Александр Пихтовников, Stdio.Digital

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

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

МегаФон ПроБизнес

Получите Кешбэк 100% за запуск рекламы с МегаФон Таргетом!

Узнать больше >>

Реклама. ПАО «МегаФон». ИНН 7812014560. ОГРН 1027809169585

Пример: клиент попросил добавить простую галерею фото на одной из страничек. Как это видит клиент: галерея представляет собой картинку, справа и слева от нее находятся стрелки. Под основной картинкой располагаются картинки поменьше (на них идет переключение при нажатии стрелки вправо), примерно 4-5 штук. Смену можно делать не только стрелкой, но и свайпом на мобильный устройствах, равно как и свайпом мышки. При нажатии на основную картинку открывается попап с ее увеличенным и вписанным по высоте или ширине экрана размером. Смена в попапе происходит по тому же принципу. И все это дело еще нужно зациклить в карусели.

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

Как это видит менеджер: "Окей, галерея фото. Ага, мы делали классную галерею на проекте для ресторана "Твой хавчик", возьмем оттуда. В нее входит даже больше возможностей, чем описал мистер Василий"

Каков итог? Разработчик прикрутит эту супер-галерею, а заказчик останется недоволен. По сути, постановка задачи - это крайне важный момент, касающейся ответственности. Кто виноват в ошибке с галереей? Клиент, потому что неправильно поставил задачу? Или менеджер проекта, потому что не уточнил ее?

Вот тут-то и появляется дилемма. Я написал 5 основных принципов постановки задач, которые планирую показывать всем нашим клиентам. Хотелось бы получить порцию критики или одобрения. С чем вы согласны? Что и где можно изменить, чтобы устранить пропасть в коммуникациях? Также буду рад ссылкам на другие источники с обсуждением/решением этой проблемы. Описанные ниже принципы постановки задач я рассматривал чисто в контексте нашей деятельности, но их можно без особого напряжения мозгов проецировать на любую область деятельности.

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

Основополагающий принцип при постановке задач. Я думаю, тут споров ни у кого не возникнет.

Мы не умеем читать мысли

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

У этого правила есть минус - менеджер проекта может докапываться до любой мелочи и тянуть деньги с клиента .

Но клиент быстро заметит это и просто уйдет от нас. Терять заказ на 100 000 р из-за правок на 2 000 р очень глупо. Поэтому мы такой фигней не занимаемся.

Перед постановкой задачи нужно хорошо подумать: как и насколько это поможет проекту.

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

Исполнитель должен видеть первоначальную задачу заказчика.

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

Давайте жить дружно

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