Главное Свежее Вакансии Образование
Выбор редакции:
4 940 11 В избр. Сохранено
Авторизуйтесь
Вход с паролем

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

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

Проблема

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

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

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

b_552dea8c54571.jpg

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

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

b_552deb5a8155f.jpg

Каков итог? Разработчик прикрутит эту супер-галерею, а заказчик останется недоволен.

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

b_552deb826fcea.jpgА как нормально-то сделать?!

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

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

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

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

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

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

b_552deeb0b753b.jpg

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

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

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

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

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

b_552def6d7bcd9.jpg

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

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

b_552deffdbc159.jpg

На этом все, жду интересных предложений :)

+11
В избр. Сохранено
Авторизуйтесь
Вход с паролем
Комментарии
Albert Fazullin
Понятно, что мы не умеем читать мысли, но заказчик как правило не завязан с разработкой сайтов и формулировать правильно их не умеет. Это скорее вопрос к менеджеру. Умеет ли он вытягивать информацию из клиентов?
Ответить
Stdio.Digital
Мы проектируем интерфейсы, готовим контент и делаем сайты.
Александр Пихтовников
Чтобы менеджеру правильно ловить такие вот "скользкие" задачи, ему нужно очень круто разбираться не только в проекте, но и в бизнесе клиента. Такой подход вполне разумен, но увеличит стоимость для того же клиента за счет увеличения траты времени менеджера
Ответить
Ис-Симпл ИнфоВизум
Интерактивные интерфейсы. Цифровые постеры. Для оффлайна.
Григорий Нотченко
Хорош тот клиент, который ставит именно задачу ("галерея"), а не задачу-реализацию ("галерею, чтобы бы там была свистелка, а сбоку ещё и перделка крутилась").
В таких случая уместно спрашивать, какого собственное конечного эффекта клиент хочет добиться. А как это сделать — решает исполнитель.
Ответить
JARC for Reddit
Клиент для Reddit на Android
Александр 803
Ну, клиент и скажет про все свистелки / перделки, нет?
Идеальных клиентов, по-моему, не существует, увы
Ответить
Stdio.Digital
Мы проектируем интерфейсы, готовим контент и делаем сайты.
Александр Пихтовников
Если говорить в контексте рассматриваемого примера, то я согласен.

Но если взять более крупную задачу, которая касается чисто бизнеса клиента, и для него какая-то свистелка де-факто должна быть. А менеджер не задел этот вопрос, так как не подразумевал, что свистелка вообще может понадобиться в этой задаче. И тогда клиент может прийти к вам недовольный с перделкой в руках и начать расстраиваться
Ответить
Stdio.Digital
Мы проектируем интерфейсы, готовим контент и делаем сайты.
Александр Пихтовников
В том то и беда, что клиент не всегда понимает, что ему нужно. А потом появляется негатив: "А почему вы не спросили у меня об этом?" или "Ну это же просто сделать, ну"
Ответить
JARC for Reddit
Клиент для Reddit на Android
Александр 803
Отлично показаны отношения клиент-исполнитель в "99 франков", я считаю. Аксиома "клиент всегда прав" — миф.
Ответить
Neaktor
Автоматизируем бизнес-процессы компаний. Всерьез и надолго.
Николай 13981
Выскажу свое мнение по пунктам 1,2 из статьи. Оно вероятно разойдется с вашим.

1) Клиент априори не умеет ставить задачи, не будет этому учиться и в идеале не должен этого делать. Если у вас есть непонимание с клиентом — то это косяки проектного менеджера. У клиента есть ПРОБЛЕМА и он хочет, чтобы вы ее решили. Так предложите ему варианты решения, а не заставляйте его думать, как это надо сделать.

Визуализируйте. Отличная штука прототипирование и скетчи: занимает 15-20 минут времени, зато клиент будет видеть визуально и скажет нравится ему или нет. Вы сэкономите уйму времени на обсуждение с клиентом, написание задач для разработчиков и уж тем более на переделку чего-то, если вы уже что-то закодили. Существующие инструменты прототипирования позволяются делать “динамические” прототипы, то есть вы можете сделать несколько страниц, залинковать их между собой и показывать клиенту как это работает в динамике. Типа тыкнули сюда — произойдет это. Axure, Justinmind Prototyper, Mockflow, Pencil Project и куча других инструментов вам в помощь.

2) Про постановку задач (тем более клиентом). Работая на одной из крупных аутсорс компаний, я был лидом команды по саппорту UAT (User acceptance testing) для ОЧЕНЬ крупного клиента. Частью нашей работы было отслеживание того как бизнес юзеры при приемочном тестировании заносят тикеты и помогать им оформить баги, улучшения и user stories в адекватный для понимания разработчиками вид. Могу сказать, что из нескольких десятков очень мотивированных бизнес-пользователей в более менее адекватном виде тикеты могло заносить только 2 человека. Оба занимали высокие посты в компании и когда-то вышли из бизнес-анализа (были бизнес-аналитиками).

Вот например при работе с ошибками в QA есть такая штука — CAN PIG RIDE называется. Это небольшой документик, который описывает общие правила занесения багов. Можно посмотреть например здесь: http://canpigride.blogspot.com/ (первая ссылка которую нашел). Если подумать хорошо, то занесение бага во многом схоже с конкретной постановкой задачи разработчику и многие правила сформулированные там актуальны.

Я это к тому, что грамотная постановка задач — это своего рода искусство, которому надо учиться и на это надо время. Вы хотите заставить клиентов учиться этому за их же деньги? Мне кажется у бизнеса и так целая куча проблем.
Ответить
Stdio.Digital
Мы проектируем интерфейсы, готовим контент и делаем сайты.
Александр Пихтовников
Спасибо за хороший комментарий.

Я не хочу заставлять клиента учиться ставить задачи, тем более за его деньги) Я хочу при старте переговоров договариваться с клиентами, чтобы мы приняли эти 5 принципов как основополагающие. Что по моему мнению, поможет снять многие недопонимая и конфликты ближе к завершению проекта. Будет более четко видно кто накосячил: мы или клиент.

На счет прототипов: да, мы прототипируем и они снимают кучу проблем. Тем не менее некоторые из них, к сожалению, вылезают ближе к концу. И большинство из них как раз связаны с "Я подразумевал это, а вы нет!?"
Ответить
Neaktor
Автоматизируем бизнес-процессы компаний. Всерьез и надолго.
Николай 13981
"Я подразумевал это, а вы нет!?" — это извечная проблема любого аутсорса и, вероятно, она неизлечима в принципе :). Именно по этому так много аутсорс-проектов с треском провалилось, проваливается и будет проваливаться или значительно выходить за рамки бюджета.

Но проблему в большинстве случаев все же можно существенно минимизировать. Тут я соглашусь с первым комментарием в ветке.

То есть, если говорить не о конкретных инструментах взаимодействия с заказчиком (например, прототипирование или взаимодействие через системы управления проектами), а говорить о системном решении проблемы, то тут поможет только чутье менеджера и его разносторонний опыт в работе с разными клиентами и проектами. Это уже о том, когда вы чувствуете, что здесь может быть недопонимание и действуете проактивно задавая правильные вопросы. Разбираться в бизнесе клиента все равно придется — за это кстати нам айтишникам собственно хорошие деньги и платят. Растите крутых проджект и продакт менеджеров — именно они делают magic (Где уже взять крутых ребят — это конечно отдельная тема.)

В ответ на ваш комментарий "Такой подход вполне разумен, но увеличит стоимость для того же клиента за счет увеличения траты времени менеджера" — могу только сказать, что разного рода доработки или в некоторых случаях полная переделка будут стоить заказчику в разы больше, да и осадочек останется.
Ответить
Stdio.Digital
Мы проектируем интерфейсы, готовим контент и делаем сайты.
Александр Пихтовников
Благодарю за советы, будем наращивать компетенции проджект менеджеров
Ответить
Выбрать файл
Блог проекта
Расскажите историю о создании или развитии проекта, поиске команды, проблемах и решениях
Написать
Личный блог
Продвигайте свои услуги или личный бренд через интересные кейсы и статьи
Написать

Spark использует cookie-файлы. С их помощью мы улучшаем работу нашего сайта и ваше взаимодействие с ним.