Заказчик требует дичь или как работать с плохими требованиями

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

Мы в компании называем такие требования “требование-дичь”. У нас, кстати, даже проходит ежегодный конкурс, в котором мы выбираем самое “дикое” требование года, и конкуренция здесь достаточно серьезная, поверьте.

Но одно дело посмеяться над требованием соседа-аналитика раз в год, другое - столкнуться с ним и его автором лицом к лицу.

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

Самое простое и одновременно худшее, что может делать аналитик на проектах - это сразу брать все поступающие от заказчиков требования в работу. Такая практика довольно часто встречается, ведь всегда можно свалить всю ответственность на заказчика: “он заказчик, он так захотел”. Говорить авторам требований “нет” бывает далеко не просто, а иногда просто не хватает опыта, чтобы оценить все масштабы совершаемой ошибки. А масштабы в зависимости от типа требования могут быть значительными.

Любые модификации системы накладывают риски на проект, увеличивая трудоемкость и сроки, а потому каждое изменение системы должно быть оправдано.
Мы верим и проповедуем то, что основная задача аналитика - не просто собирать и реализовывать “хотелки” заказчиков, а помогать заказчику принимать правильные проектные решения, даже если об этом явно не просят.

Для обработки таких требований мы предлагаем очень простую и работающую схему:

Рассмотрим по шагам.

1. Идентифицировать требование-дичь. Операция, которую необходимо выполнять при получении каждого требования, это проверка его на “дичь”.

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

· Если это требование не реализовать, основные бизнес-потребности будут удовлетворены?

· Потребность можно закрыть имеющейся функциональностью или реализовать требование проще?

· Реализация этого требования влечет какие-то риски?

Если хотя бы на один из вопросов вы ответили “Да”, есть вероятность, что перед вами требование-дичь, а значит переходим к этапу 2.

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

-- заказчик просто не знает, как сделать по другому, но хочет убедиться, что его потребность будет удовлетворена;

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

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

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

· какую задачу он пытается решить? в чем заключается потребность?

· к чему приведет, если это не сделать?

· есть ли какие-то ограничения, которые не позволяют нам рассматривать альтернативные варианты реализации? Кстати, если такие причины есть, то иногда рационально сразу перейти к пункту 4.

3. Предложить альтернативы. Как донести до заказчика, что его идея плохая? Этот вопрос вызывает трудности у многих специалистов, работающих с людьми.Для ответа на него мы руководствуемся принципом наилучшего выбора Милтона Эриксона:

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

Эти варианты можно по разному представить, например, в виде небольшой сравнительной таблицы. В качестве характеристик можно использовать “Удовлетворение потребности”, “Стоимость/Трудозатраты” и “Риски и ограничения”.

Для отбора альтернативных вариантов предлагаем следующую схему:

· Вариант 1. Что предлагает Заказчик? Одним из первых предложений к рассмотрению описываем вариант реализации, о котором просит заказчик. При описании его ограничений важно избегать субъективных оценок “вам будет неудобно”, “это некрасиво”, “это сложно”. Опишите с какими трудностями ОНИ столкнутся, если реализовать требование: какие возможности станут недоступны, как это повлияет на работу пользователей или сроки/стоимость проекта.

· Вариант 2. Что есть в “коробке”? Проанализируйте, какая функциональность уже есть во внедряемом вами продукте. Возможно, она полностью или частично закроет потребность заказчика. Как правило этот вариант всегда самый дешевый и безопасный, поэтому предложить его имеет смысл всегда, даже если потребность удовлетворяется частично. Если варианта “в коробке” нет или нет “коробки”, то переформулировать вопрос можно как “Какой вариант был бы самым простым и дешевым?”.

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

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

4. Зафиксировать ограничения и риски. К этому шагу мы переходим из пункта 3, если убедить заказчика не удалось, и он настоял на своем предложении, или после шага 2, если имеются ограничения, которые не позволяют рассматривать альтернативы. Даже если реализации плохого требования не избежать, перед тем, как брать его в работу, важно явно согласовать с Заказчиком все ограничения и риски, которые вы выявили в пункте 3. Пропишите способы устранения последствий при негативном исходе и ответственных за выполнение работ. Таким образом вы делите ответственность с Заказчиком и минимизируете последствия рисков, которые может вызвать реализуемый вариант.

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

В нашем блоге для аналитиков Kung Fu Аналитика мы публикуем реальную практику и рабочие кейсы со всей их поднаготной. Подписывайтесь и претендуйте на соавторство в блоге. Начните с комментариев. Например, с какими требованиями-дичь вы сталкивались? Как действуете при их получении?

Романова Ксения, руководитель отдела аналитики.