Риск разработать то, что хочется заказчику. Но не то, что ему нужно
Тема агрегации требований, их анализа и ценности этих результатов при разработке, всегда будет актуальной. Эта заметка появилась во время обсуждения нескольких зарубежных статей из мира бизнес-аналитики и является их адаптированным переводом.
В — взаимодействие
Представьте, что есть состояние, находясь в котором, профит
от разработки получает и исполнитель, и заказчик. Назовем его состоянием генерации пользы.
В обычном редизайне сайта или создании имиджевого мобильного приложения, в принципе, нет ничего плохого. Без сомнения, такие решения в определенной ситуации приносят ценность бизнесу.
Ключевое замечание — в определенной ситуации…
«Ошибки в требованиях стоят от 70 до 85% стоимости переделки» Leffingwell 2007
Всем известно, как важно извлечь ключевые требования заинтересованных сторон на ранних стадиях проекта, когда закладываются архитектурные особенности приложения. Но сама проблема глубже – если мы не знаем причин, которые движут заинтересованным лицом, мы никогда не поймем, является ли наше решение наиболее подходящим из всех возможных. Мы рискуем разработать для заказчика в точности то, о чем он нас просил, но со временем, выяснив, что это не то, в чем он нуждался.
Мир уступает дорогу тому, кто знает, куда идет
Мы очень хотим помогать тем, кто принимает решения. Совместно
и конструктивно двигаться к старту реализации решения, которое будет бить точно в цель.
Без взаимопонимания и доверия между исполнителем и заказчиком здесь не обойтись.
На рынке много клиентов с уже сформированным видением решения, но часто, после погружения в задачу, становится ясно, что они не уделили должного внимания проработке исходной бизнес-цели, инсайтов аудитории или исследованию других возможных решений.
Скорее всего, вам знакомо что-то подобное:
«Я знаю, чего хочу! Через 2–3 месяца нам нужна система XYZ и никаких дополнительных исследований тут не нужно. Можете начать работу над системой на этой неделе?»
В подобных случаях, после первичного интервьюирования, мы попросим о повторной встрече, чтобы детализировать пройденный заказчиком путь, установить ожидания от ключевых результатов. Если это увеличение объема продаж, хорошо, тогда как будущий проект позволит достичь этого результата?
Важно совместно с заказчиком проследить путь, которым он пришел
к своему решению. Что является наиболее важным для него в этом решении? Рассматривались ли другие варианты? Если мы реализуем его, решит ли это все проблемы или останутся пробелы?
Иногда, благодаря подобному диалогу, мы можем предложить более эффективную альтернативу. Либо разработать что-то совершенно новое, абстрагировавшись от предметной отрасли заказчика и бросив вызов своим силам.
Если диалога с заказчиком не получается, вы буксуете и увязаете
в конкретных фичах или составляющих графического дизайна, применяйте техники из бизнес-анализа. Например, хорошо работает перемещение между уровнями требований, с уровня деталей реализации на уровень потребностей и возможностей.
«Если мы правильно вас поняли, пользователи должны иметь возможность масштабирования изображений при просмотре списка продукции, чтобы можно было рассмотреть отсутствие недостатков и потенциальные преимущества продукта. Верно?»
Осознание проблемы — первый шаг к ее решению
Исполнитель обязан понимать, почему требуются изменения,
что представляет наибольшую ценность для заказчика и как разрабатываемый продукт будет вписываться в его бизнес-процессы.
Агрегация требований и их анализ, формирование стратегии разработки являются критически важными процессами и,
к сожалению, часто упускаются заказчиками.
Мы призываем представителей рынка разработки использовать свой опыт и компетенции в убеждении заинтересованных лиц в ценности указанных работ. Формируйте успех проектов совместно со своими заказчиками :-)
Использованные источники:
Эта заметка является частью цикла по разработке проектов с высокой долей неопределенности в Molinos Studio.
