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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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