【发布时间】:2010-10-03 17:52:05
【问题描述】:
我问这个,因为明天是我与客户的第一次会面,她告诉我,她现在(手动)在做什么,它是什么,新的 Web 应用程序最终应该做什么。
我想知道,在她向我展示了整个过程的步骤期间,我做了什么。我是否能够识别用例并直接对其建模?我是否在 prosa 中描述了这个过程?我如何将现实世界的过程描述/转录为模型,然后作为代码的基础?
对您来说,开始新开发的最佳实践是什么?有什么建议吗?
【问题讨论】:
我问这个,因为明天是我与客户的第一次会面,她告诉我,她现在(手动)在做什么,它是什么,新的 Web 应用程序最终应该做什么。
我想知道,在她向我展示了整个过程的步骤期间,我做了什么。我是否能够识别用例并直接对其建模?我是否在 prosa 中描述了这个过程?我如何将现实世界的过程描述/转录为模型,然后作为代码的基础?
对您来说,开始新开发的最佳实践是什么?有什么建议吗?
【问题讨论】:
这都是关于流程和管理预期,与技术无关。大多数客户(尤其是小型咨询公司)犯的错误(恕我直言)是他们选择了固定价格合同(可能需要支付 T&M 支持:时间和材料)。他们这样做是为了进行风险管理,所以这是可以理解的。
问题在于他们以三种方式为这种较低的风险付出了代价:
所有这些都会使最终结果对客户来说更加昂贵,让开发人员失去动力(谁想写 300 页的 Word 文档?说真的!)并且延迟了客户实际获得任何东西(从而增加了范围的风险蠕变,与项目的长度成正比)。
如果采用 T&M 方法并结合某种形式的快速原型制作方法,并在不超过 4-6 周的时间内定期向客户交付或演示,双方通常会得到更好的服务。这有助于管理预期。如果客户可以看到正在发生的事情,它会让他们放心,让您继续工作(而不是在会议中等待时间通过 GANTT 图表)。
因此,您应该尝试说服您的客户采用渐进式方法(小步骤),让他们可以看到他们正在获得什么、它是如何发展的并参与到这个过程中。它可以更快地获得结果并且最终更便宜(双方分担风险负担)。
许多开发人员似乎也忘记了一件事情,那就是他们就像 15 世纪法国的皇室臣民。他们可能拥有特权,甚至财富和许多特权,但他们为国王(或王后)服务,国王可以随心所欲地斩首他们。我的意思是客户最终掌握了权力,而您作为开发人员的存在是为了让他们的生活更轻松,而不是相反。
如果客户想要在老板 iPhone 上的虚拟 Vax/VMS 服务器上运行在 Cobol on Rails 上开发的粉红色和绿色网站,这就是他们得到的。现在,您可以利用您的专业知识和经验来尝试说服他们这不是一个好主意,但最终如果这是他们想要的,您有两个选择:给他们或步行。
太多的开发人员陷入了为人们提供他们认为应该拥有的东西而不是他们要求的东西的陷阱。大错。这个过程的一部分是保持与客户的沟通渠道畅通,这样当他们期待完全不同的东西时,你就不会误以为他们想要什么(或决定他们应该拥有什么)。
即使是一个小型的软件开发项目也很容易跑到 6 位数。对于为此付费的人来说,这通常是一笔巨大的投资。他们有权不紧张,你有责任让他们开心。
【讨论】:
大多数开发人员不会花时间这样做,而是直接跳入建模类图和系统架构,但我想说的最重要的是写下她提到的每一个特性。不要担心分组,或者它们如何组合在一起。当时,您只需要从她那里获得所有可能的功能。当您离开并开始考虑应用程序时,您将开始绘制功能块之间的相关性,最终将其分组为具有属性和方法的对象。
【讨论】:
我可以衷心推荐 Eric Evans 的“Domain Driven Design”。它解释了如何对问题域进行建模,并在此过程中建立一种通用语言,您和客户可以通过该语言就应用程序的功能进行清晰的沟通。
另外,看看你能不能找到适合你目标平台的快速开发工具,这样你就可以快速的把东西拿到你的客户面前,获得早期的反馈。例如,如果您使用的是 Java EE,请查看支持往返的 Spring Roo。
【讨论】:
我认为您的客户不想与您谈论这些事情......我敢打赌,她会向您展示一些关于页面应该如何组织以及她期望事情如何运作的图纸。
您应该按照她的演示文稿提问(始终从用户的角度出发),这样您就可以按照她的期望完成您的工作。把技术的东西留给自己;)
【讨论】:
用户对它的工作方式不感兴趣。对他们来说,这一切都与界面的组织和执行操作的必要步骤有关。我同意上面的建议,写下功能和接口要求,他们看看如何以及是否可以建模。
分析后再次与她讨论您可以做什么和不能做什么,并提出解决方案或改进。
【讨论】:
客户很可能会在您与他们交谈的前 5 分钟内告诉您他们想要什么。之后的任何事情都只是枕边话。
【讨论】: