都是需求惹的祸

上上周我们计费组的同事（华为+中软+中创）一起开了个会，着重讨论了一下以后在质量保证方面所要做的工作。这其中又对开发人员，测试人员提出了详细的要求。其实不管是对开发人员的要求，还是测试人员的要求，都是围绕着需求这个核心问题而制定的。从那些要求里面可以看出，很多很多的质量问题，最根本的原因都是需求不清晰所造成的。因为需求不弄清楚的话，开发人员开发出的模块，就很有可能偏离正确的需求方向，从而导致“做出来的东西不是我们想要的”这样的结果。而如果测试人员对需求不清晰，则这些兄弟姐妹们编写出的测试用例，就非常可能把好的模块给测成不合格的次品，从而“错杀好人”。

其实这个问题也非常的好解决，就是从源头上抓起，在项目启动的时候，开一个需求讨论会议，项目组内的所有人，不管是开发、测试还是PL、PM和SE等，都尽量到会。所有人在会议上都将需求搞的清清楚楚明明白白，自然而然就知道接下来的工作该怎么做了。然后测试人员根据需求编写测试用例，并让相关的开发人员、SE等人来评审，确认无误后再进行下一步的工作。这也是敏捷开发模式中所提倡的测试先行的做法，当然这是在保证项目质量的基础上。

不过说实话，单就这一点来说，我们做的其实并不敏捷，依然还是沿袭着老的套路：需求平台上提出需求，将需求指派给相关的开发人员进行开发，开发人员完成开发后，在指派测试人员进行测试……。在这个过程中，一旦因为需求不清晰而出现了问题，轻则很有可能造成返工，严重的话，问题出现在客户现场，就会造成网上事故。但是我们不要因此而感到悲观，因为针对这种传统的流程，还是有很多的预防措施的，关键还是要防止因需求不清晰而出现问题。

还是从源头上开始做起，在提交需求的时候，一定要在需求的comments中对需求进行详尽的说明，而且最好是用白话文。因为这个需求如果被指派给一位刚入行不久的兄弟或者姐妹的话，白话文对于他们理解需求是很有帮助的，花费时间少，效果还非常的好。这一点在后期书写SRS文档和RTM文档的时候同样如此，也都尽量用白话文，通俗易懂。这方面，我们古代的先人就做的非常的好。记得有位诗人，他每次写完一首诗歌，都会让隔壁的洗衣大妈来看看。洗衣大妈说“好”，那才是真的好.因为我们这些俗人能够欣赏到那首诗歌的美，从而提高了那首诗歌的受众面。而反过来，如果他写出来的诗歌，我们这些俗人都看不懂，只有他自己知道是怎么回事，那么他这就叫孤芳自赏。在解释需求的问题上，这种孤芳自赏的事情我们千万不要去做，害人害己（稍微扯远了一点哈:P）。回到正题，在开发人员完成开发后，测试人员在测试中发现问题，不要去找开发人员确认，而是应该去找SE确认。因为SE是对需求理解最准确的人，这样可以对测试中出现的问题进行更准确的定位。如果问题定位到开发的话，则再去找开发人员进行反馈沟通，从而避免因开发人员对需求的误解，而导致开发引导测试的错误做法。同样地，如果开发人员对需求有疑问，也应该尽早地找SE进行沟通，将那些由需求而可能引发的问题消灭在萌芽之中，避免让那些“坏蛋”来祸害项目组，祸害团队。另外，不管是SE、PL、PM还是开发人员和测试人员等，当有人向你来沟通、确认需求的时候，不管你再忙，也一定要将手头的工作放一放，先给人家进行说明。不能说什么：“我这里有很多事情还没忙完呢，你先回去等等”这样的话来搪塞人家。至于为什么，大家都是成年人了，相信都应该明白。但是我不得不说，有些人在这方面做的那可是相当的差劲啊。希望以后在这方面，我们的团队能够有所改善吧。

一点拙见，让各位看官见笑了。如果大家有什么更好的想法，欢迎拍砖。:P