«Хотели как лучше, а получилось как обычно»: почему заказчик получает не то, что хотел?

Рассмотрим основные причины, а также способы разрешения проблемных ситуаций.

Ожидания не всегда оправдываются. Например, поступили в ВУЗ в надежде получить профессиональные навыки, но там учат более общим дисциплинам. Или дали добро на оффер в компанию, где обещали премию и отсутствие переработок, а на деле Вы не получили ни того, ни другого.

Возникают и обратные ситуации, где уже Вам нужно оправдать ожидания Другого — работодателя или бизнес-заказчика. Сделать это порой тяжелее, чем кажется. Задача усложняется не только по причине непостоянства, но и неполноты постановки. И даже если работник выполнит работу "точь-в-точь как просили", итоговый результат может не удовлетворить принимающую сторону. Такое явление называют разрывом ожиданий или Expectation Gap.

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

С какими проблемами, приводящими к разрыву ожиданий, сталкивается аналитик? Какие подходы помогают с ними справиться?

Проблема №1. "Оптимистичное" планирование

Многиеруководители намеренно называют нереалистичные сроки, опасаясь вала критики со стороны заказчика. Но чаще стейкхолдеры и сами не прочь ускорить процессы «любой ценой, но бесплатно». Такой подход невольно провоцирует увеличение числа ошибок, что приведёт к неудовлетворительным результатам и/или срыву сроков. Но главное последствие сокращения сроков — экономия времени на выявлении истинных ожиданий (далее — требований) заказчика. И даже если все работы чудесным образом будут выполнены в срок, риск того, что результат не оправдает ожиданий, довольно велик.

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

Проблема №2. Заказчик долго (не)отвечает

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

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

1. Регулярное напоминание. Напоминайте заказчику в мессенджере о своём существовании раз или два в день. Рано или поздно у него дойдут руки и до Вас.

2. Ставьте встречи в календаре. Иногда лучше лишний раз не тревожить заказчика и не писать ему по несколько писем в день. Сформируйте список вопросов, накопившихся за несколько дней, поставьте встречу в общем календаре, на которой обсудите все проблемы разом.

3. Автосогласование. Если сроки начинают сильно давить на команду, а ответ так и не приходит, предложите свой вариант действий, дописав фразу: «В случае отсутствия обратной связи в течении X дней, данная часть работ является согласованной».

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

Проблема №3. Постоянные изменения требований

Изменение требований — процесс неизбежный. Однако непрерывный поток правок способен умножить на ноль все старания команды: аналитикам надо будет срочно править и согласовывать документацию; разработчикам придется по новой отлаживать код; тестировщикам — продумывать тест‑кейсы. Аналитик оказывается перед тяжелым выбором: требования, не отраженные в проекте, только увеличивают разрыв ожиданий; однако спешно внесённые предложения прорабатываются недостаточно тщательно и их реализация может всё равно не устроить заказчика.

Решение: есть ряд профилактических мер, помогающих предупредить такую «болячку».

1. Прототипирование. В любом случае, лучше демонстрировать промежуточные результаты, чем не делать этого. Прототипы подходят для этого идеально. Подготовить прототип проще, чем реализовать полностью. Таким образом Вы сможете получить корректировки быстрее, не затрачивая огромного количества ресурсов.

2. Ищите компромисс. Схоже с решением проблемы № 1. Посмотрите отстранённым взглядом на все предложения заказчика. Оцените их трудоёмкость. Поставьте встречу, выделите «самые важные» из них, отразите изменения в техническом задании.

3. Сообщать о последствиях изменений. Если предупредить заказчика, что любая объемная правка будет приводить к увеличению трудозатрат и отклонению от первоначальных сроков (а это реально так), может быть, он поймет, что стоит отложить свои хотелки до следующих релизов. Но это не точно.

Проблема №4. Заказчик не знает, чего хочет

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

Решение: используй свою насмотренность во благо проекта. Ниже советы, как её развивать.

1. Анализ похожих систем. Скорее всего, аналогичные системы уже существуют и пользуются спросом. Как сотрудники компании или другие клиенты им пользуются? Какие функции кажутся Вам полезными? Насколько быстро и надёжно работает ПО? Зафиксируйте ответы на эти вопросы и обсудите их с заказчиком.

2. Исследуй Бизнес‑Правила. В компании заказчика могут написаны нормативно‑правовые акты, ограничивающие некоторые стороны бизнес‑процессов. Помните, что они также могут быть источниками требований.

3. Прорабатывайте архетипы пользователей. Архетип пользователя — собирательный образ пользователя продукта. Представьте себя на месте пользователя. Как бы пользовались продуктом? А теперь опросите человека, схожего с потенциальным пользователем. Сравните результаты. Синтезируйте с помощью такого подхода идеи и предложения по продукту.

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

А какие приёмы используете Вы для решения проблем, связанных с ожиданиями заказчика? Пишите в комментариях.

Да пребудет с Вами Сила!