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