最近我收到了潜在客户对非常复杂的Web应用程序的请求.
他们希望我在“真实”作品开始之前写一个规范.
规范,因为他们看到它应该只是描述应用程序和数据库的单词.
我发现最好的方法是“绘制”或“构建”应用程序将拥有的屏幕原型(html比写书更容易,特别是如果你只是为了这个阶段使用WYSIWYG ……标准并不重要这点).
他们希望我在“真实”作品开始之前写一个规范.
规范,因为他们看到它应该只是描述应用程序和数据库的单词.
我发现最好的方法是“绘制”或“构建”应用程序将拥有的屏幕原型(html比写书更容易,特别是如果你只是为了这个阶段使用WYSIWYG ……标准并不重要这点).
当你的眼睛前面有一个屏幕时,它会立即清楚显示应该是什么元素(日历/照片画廊/主要链接,搜索框等)
那么,我的做法是错的吗？
或者客户是否了解正确的做事方式？
解决方法
虽然我同意您需要就构建系统的范围和成本达成一些广泛的一致意见,但我认为,在认识到您可以在将系统置于客户手中之前完全规范系统时,我们正在抓住这些问题.正如您所发现的那样,客户在实际看到之前往往不知道自己想要什么.解决这个问题的一种方法是模拟,就像你习惯做的那样.我在设计和规划时也使用它们.
然而,大多数情况下,您需要将实际产品送到客户手中,以获得关于哪些有效和哪些无效的不可避免的反馈.你最好早点而不是后来这样做,因为在开发后期发生的变化要困难得多,而且价格昂贵,至少在传统方法中如此.使用敏捷方法尽早并经常提供工作软件,与足够的计划和文档相结合,获得更好的客户反馈,而不是迭代客户可能发现他们不想要的产品的规格(或者至少需要它们他们说的方式).
我建议您需要一些文档,概括地说明项目的范围.足以让你就系统的一部分和非系统的一部分达成一致.例如,如果您正在构建库存管理应用程序,则不应期望获得客户关系管理系统.然后,应用敏捷开发方法的技术,以轻量级的方式跟踪所需的功能,并尽早将一些工作代码交到他们手中,并在此后定期获取.这需要所有各方的信任,因此您可能希望从小项目和时间表开始,并建立信任.
