探索需求-设计前的质量之三

　　第三篇探索机会，通过头脑风暴产生想法，通过右脑方法产生可理解的产物，通过冲突找到正确的产物。当然，大多数听起来愚蠢的想法确实会被证实是愚蠢的，而且一些人会因为他们的“愚蠢”的想法被记录下来而感到不安，由于这个原因，没有经过编辑整理的想法的列表是绝对不应当被会议之外的人看到的。会议议程的安排中必须包含头脑风暴结束时用于编辑整理想法的时间。如果参与者理解了并且相信了这样的承诺，他们就会放松下来而产生许多“愚蠢”的想法，就有可能从中找到很棒的想法。

　　想法，是一个非常抽象的东西，对于这个东西来说，一个人的力量总是有限的，所以当两个人以上需要想法的时候，我们就可以进行一次这样的头脑风暴会议，集思广益，才能做出更好的东西，同时，要注意不批评不责备，想法越多越好，注意更改与合成逐步整合与剔除，得到最佳的想法或者说解决方案。

　　而右脑方法这一章，主要讲的就是映射图，他是我们所做的系统的流程，同样的我们也可以用语言来解释请所有的流程，但是通过流程图或者说映射图更加直观形象，他帮助我们理清系统中的信息传递、以及人与系统之间的交互。

　　命名是一件繁琐但有必要的事情，名称左右着我们的思想，一旦被误解或具有含混性就会成为麻烦的起点。提出一个名称；给出不合适的原因三个；提出另一个可以消除这三个问题的名称；重复上述过程，直到找到一个可用的名称就好。

　　冲突有三种：一种是无关紧要的冲突即非本质的冲突对项目没有任何影响的冲突；一种是个性冲突即思想上的碰撞这就是火花从中找到最好的想法是这场冲突的结果；一种是信息的不一致造成的冲突，这就是之前的理解不到位了。在冲突中，一位合格的推动者是至关重要的，但最终的目的是推动工作，让时间得到有效的利用。

　　总的来说，这两篇是整个项目的基础，它为项目需求规格说明书提供了重要的参考资料和想法，而处理问题的方法、获得需求的途径也是很有参考价值的。

　　接下来是余下的两篇，在这两篇中，第四篇讲了明确期望，第五篇则讲了成功标准也就是对于成功的衡量标准。

　　在明确期望的工作中，我们多次运用了头脑风暴的方法，根据项目的内容列出我们所能想到的所有功能、属性、约束条件，并做好与客户之间的沟通了解客户的偏好最终得到客户对于该项目的最终期望（当然这是一个循序渐进的过程）。

　　而在项目的测试阶段，我们应对所有项目内容在一次复习，虽让项目内容的含混性是不可能完全消除的，但是通过协商可以找到一个恰当的平衡点；通过技术复审我们可以找到自己的失误所在，有道是“旁观者清，当局者迷”；然后通过满意度测试了解真正来自与客户的意见，客户满意才是最重要的；而对于公司内部的测试则应更专业一些，比如黑箱测试等等，我们要真正测试出软件的功能可靠性，在最后阶段，我们的软件应该具有对于各种需求完备性、明确性、准确性及简明性；同时我们更要注意学习或者说了解我们的对手的产品以及已经存在的产品，通过对比找到我们的优势、劣势，所谓知己知彼百战百胜；然后我们就要和客户面对面的审核，要注意协议以及签字，作为一个商人，我们要避免不必要的麻烦，让我们所有我们能够想到的相关责任人签字。同时要有结束的勇气，我们总是认为我们可以做得更好，可以增加更多方便的功能，但是那不是我们的任务，没有一个软件是绝对完美的。

　　通过这本书，我看到了许多的工作心得，里面的例子虽然很荒唐，但是更能让我体会到探索技巧的重要性。从第一篇达成共识，再到第二篇的进入主题，紧接着探索机会，然后明确期望，最后提出测试用例，让我看到了一个完整的项目开发过程。项目小组理解要一致，准备工作要做足，会议气氛要和谐，与客户沟通要及时，期望要明确，测试用例要全面多层次，整个项目要有边界，不要做无止境的循环。

 

转载于:https://www.cnblogs.com/zrdm/p/5090205.html