Project management 如何表明您了解项目的要求

你如何向你的客户/雇主表明你了解他们的要求

你推荐用什么？用例图？流程图？数据流图？决策树

---

我并不是要一个非常详细的答案。这只是一个简单的方法，可以帮助我与编写需求的人进行沟通，看看你们是否在同一页上。

流程图往往会混淆一些非技术人员（即客户）以及数据流程图。用例是好的和可理解的，还有业务需求和技术需求文档，可能是某种粗略的线框草图

我只是用我自己的语言解释需求，提供我的假设并添加限制

要求可能是“点击按钮时变绿”

我会问“好的，那么当用户点击按钮时，按钮的背景色变为绿色，但文本保持不变？”

---

基本上是提示给出需求的人解释他们对它的设想是如何工作的。

我通常在项目的早期就制作一个PowerPoint幻灯片，提供项目的高级概述，以及一些架构图（越简单越好）和屏幕模型/线框。然后，我将召开一个“启动”会议，审查需求，并讨论业务问题和建议的解决方案。

这取决于您所讨论的需求

• 功能要求？也许UML是最适合的工具。但我更喜欢测试规范
• GUI需求？没有什么能比得上纸和铅笔
• 安全要求？通过描述您的安全限制，您可以避免意外的欺骗
• 可靠性要求？测试机制和软件/硬件备份/恢复计划
• 其他要求：取决于您的客户

---

但无论如何，请记住，并向客户解释，需求将在开发阶段发生变化，这将始终是成本和功能性之间的讨论和折衷。诚实会给你的客户带来更多的信心。

我认为，展示你真正理解客户想法的最好方式是制作原型

顺便说一句，我参加了上一次的需求工程会议和其中一次研讨会（MERE），西门子展示了一个有趣的软件，该软件是基于客户想法的视频制作的（它适用于不限于软件的项目），目的是确保完全理解所有需求

---

不管怎么说，问题是有时候用一种创造性的方式来展示它们会更好。不要局限于标准图。

我的角色有很多需求收集。我发现最好的方法是双管齐下，通过PowerPoint演示文稿进行讨论，使其保持简单和高水平，并展示概念验证或模型。在与客户交谈时，他们会给出许多“如果”的回答，例如“我可以试试颜色吗？”这让每个人都对他们得到的东西有一个大致的了解。如果你能得到一些用户可以触摸和玩的东西，那么这些东西在发现隐藏的假象方面非常有效

然后，用真正详细的低级需求来支持这个高级需求。请拼出带点的“i”和划线的“t”。在POC之外的任何操作完成之前，让用户通读并签名。一般来说，有很多截图的word效果很好

除非用户能给您带来UML和数据流程图，否则不要在客户看到或签署的任何东西中使用它们。如果它是由客户签署的，并且您必须注册后端以满足“如果”的要求，那么您必须完全放弃所有内容

最后一件事是确保客户可以用他们自己的语言与您谈论他们的需求，并详细说明他们得到了什么。这样做的一个方法是坐在中层管理层的位子上，向高层管理层推销产品

不要试图欺骗客户，如果他们想在最后一刻改变一些东西，解释一下时间和金钱上的成本，并询问他们是否完全需要这样做。这样做通常会阻止人们做出琐碎的改变，并迫使他们思考为什么他们想要改变

需求是从客户所说的他们想要的东西中得到客户所需要的东西

编辑- 关于提前显示屏幕截图，有时需要一个好的PM，让客户知道时间尺度和一切都在哪里。如果PM帮助设定了一些合理的时间框架和期望值，客户将不会感到兴奋。POC和屏幕截图的好处是，人们可以得到它可能是什么样子的图像，并且通常可以在他们的脑海中工作

如果你想避免截图，可以使用线框外观，或者使用白板和20分钟的绘图。只要记住在你挥动白板之前把它保存为照片就行了

---

白板（和良好的旧OHP）可以成为需求收集的天赐之物-开发良好清晰的绘图概念风格可以节省研讨会的时间。

我在创建简单词汇方面有很好的经验，包括来自领域的术语及其含义和关系，然后仔细检查，确保每个人都同意每件事

写作和讨论词汇迫使你思考，而不仅仅是认为“我们稍后会解决这个问题”

---

当然，这并不是什么灵丹妙药，应该与功能需求规范和原型等其他手段一起使用。

如果您在早期向客户展示屏幕截图，您是否发现客户认为大部分工作已经完成，并且在构建实际功能时变得不耐烦？