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

Проблема

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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