Хотя я согласен с тем, что вам нужно иметь какое-то широкое согласие в отношении объема и стоимости создаваемой системы, я думаю, что это цепляние за соломинку, чтобы думать, что вы можете полностью определить систему до того, как передать ее в руки заказчика. Как вы обнаружили, покупатель очень часто не знает, чего он хочет, пока не увидит это на самом деле. Один из способов решить эту проблему - использовать макеты, как вы привыкли. Я тоже использую их при проектировании и планировании.
Однако чаще всего вам нужно передать реальный продукт в руки покупателя, чтобы получить неизбежную обратную связь о том, что работает, а что нет. Лучше сделать это раньше, чем позже, поскольку изменения, которые происходят на поздних стадиях разработки, намного сложнее и дороже, по крайней мере, в традиционных методах. Использование гибкого метода, который предоставляет работающее программное обеспечение на ранней стадии и часто, в сочетании с достаточным планированием и документацией, дает лучшую обратную связь с клиентами, чем повторение множества спецификаций для продукта, который клиент может найти, что он не хочет (или, по крайней мере, хочет, чтобы он как они сказали).
Я бы посоветовал вам найти некоторые документы, которые в общих чертах описывают масштаб проекта. Достаточно, чтобы вы могли прийти к соглашению о том, что является частью системы, а что нет. Если вы создаете приложение для управления запасами, им не следует ожидать, например, также системы управления отношениями с клиентами. Затем примените приемы из методов гибкой разработки, чтобы легко отслеживать желаемую функциональность и получать рабочий код как можно раньше, а впоследствии на регулярной основе. Это потребует доверия со стороны всех сторон, поэтому вы можете начать с небольших проектов и сроков и укрепить это доверие.
person
tvanfosson
schedule
04.06.2009
