Основная причина вашего недовольства ситуацией, вероятно, связана с восприятием и вводящими в заблуждение / неправильными терминами, используемыми клиентом. Заказчик обычно не приходит к вам со списком требований , но список пожеланий каждой вещи, о которой он может подумать, может быть полезен для них. Это не все требования, потому что клиент еще не потратил время на то, чтобы по-настоящему подумать, действительно ли каждая функция необходима .
Это не всегда проблема
Если у вашего клиента есть деньги на все эти функции и он готов с ним расстаться, и вам не очень важно решать реальные, реальные проблемы, которые возникают у клиента, тогда это может быть очень прибыльным проектом. Это случается, очень, очень редко, и для большинства разработчиков это убивает душу, потому что вы можете заранее почувствовать, что проект не будет успешным для клиента в конечном итоге (даже если он будет финансово успешным для вас как разработчика). Это также высокий риск, потому что вы, вероятно, в конечном итоге получите проект с фиксированной стоимостью с большой неопределенностью, и действительно важно неправильно оценить риск в крупных проектах.
Что делать, если это проблема?
Допустим, вы не в такой редкой ситуации. В этом случае вы захотите устранить два основных недостатка списка желаний, как указано ниже:
- Маловероятно, что клиент имеет правильное представление о затратах на разработку такого большого списка требований, поэтому вы вряд ли получите контракт на ту сумму денег, которая вам фактически необходима для этого.
- Вряд ли этот список пожеланий точно и кратко описывает реальную проблему, которую клиент хочет решить.
По моему опыту вам нужно обратиться к 2, чтобы исправить 1. Развертывание до актуальной проблемы означает, что вы, разработчик, теперь имеете необходимый вклад, чтобы сделать творческий скачок в решении проблемы способами, о которых сам клиент даже не задумывался. Эти решения, вероятно, будут намного дешевле и быстрее, чем реализация полного списка пожеланий.
Как вы это исправите?
Как говорит Мэтью Флинн в своем ответе - начните с того, чтобы клиент расставил приоритеты в соответствии с требованиями. Это не всегда легко, но заставляет их это делать. При необходимости используйте фразу «Если кто-то приставил пистолет к вашей голове, какое единственное требование вы бы выполнили?». Во время этого процесса вы часто обнаруживаете, что клиент на самом деле не имеет четкого представления о том, что означают индивидуальные требования. В этом случае сделайте то, что предлагает Питер Роуэлл, и заставьте клиента работать с пользовательскими историями. Вы и клиент начнете гораздо лучше понимать проблему и требования, а затем вы сможете вернуться к расстановке приоритетов. Повторите эти шаги так часто, как вам нужно, пока вы не почувствуете себя комфортно, что вы знаете достаточно, чтобы решить проблему клиента .
Как это отвечает на вопрос о разработке решения?
Как только у вас есть приоритетный список требований, у вас есть вход, который вам нужен, чтобы предложить вашему клиенту процесс постепенной разработки. Вам не нужно называть это Agile, но вы можете предложить разбить контракт на более мелкие части для каждого требования (или неделимого набора требований) и поставить их один за другим с подтверждением заказчиком. Или вы можете сделать все возможное и использовать множество ресурсов, доступных онлайн и офлайн, чтобы убедить клиента, что в его интересах сотрудничать в одном из стилей разработки Agile. В любом случае вы можете предоставить свое предложение по контракту / проекту в форме, которая четко предлагает эти строительные блоки требований в приоритетном порядке, каждый со своей стоимостью и заключением. Держи эту морковку перед клиентом,