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