如何能正确理解需求

本文是我编写技术管理经验的第一篇文章。希望它能作为一个管理类篇章的好起点，同时也希望这些文章能为各位开发人员或者管理者带来一些帮助。此类所有文章以事件引出，以解决方案结尾，请大家接受这种写法。

【事件】

我所在项目组开发的产品是运行在移动设备上的CAD应用。由于CAD是辅助设计软件，与图形处理密切相关，所以我们招底层开发人员必须有相关开发经验才行。但就目前的市场形式，我们又不得不招一些上层（移动端）开发人员，辅助我们去完成产品的开发工作。

这些上层人员的介入，使得我们沟通有了不少阻碍。因为他们不了解CAD，对其中的实体、命令、图层、布局一窍不通。这样的话，我们只能让底层开发人员，尽量将底层库封装好。上层人员只需调少了的接口，就能实现功能就好。但是问题还是会出现的。

当新的需求（包含CAD专业性的）产生后，底层开发人员很快就能理解需求，马上做出响应（做完设计开始编码）。可上层人员还在想需求到底是什么？此时他可能会做出两种反应：1）找产品经理，让他解释每个专业名词的意义。一时理解了就开始着手设计。2）猜想出是某种功能，然后开始设计。

第一种行为可能造成的后果是，耽误了很长时间，做出的功能一半正确一半错误。保留那正确的部分，可能与解决错误后的模块兼容不上。不保留的话，又感觉之前的设计白做了，浪费时间很可惜。

第二种行为造成的后果是，兴致勃勃作完的功能交给产品经理验收。一盆冷水浇了过来，他可能会告诉你，需求本来就不是这个意思。你的设计偏差很大，全部丢弃，重新设计。

【解决方案】

我们说理解需求最好的方法就是去沟通。所以上面事件中，第一种行为肯定比第二种更好些。但对于一个非专业的人士来讲，沟通也需要技巧。盲目的询问只能是鸭子听雷，完全没有理解。

我们经过讨论后，决定“如何能正确理解需求，需要产品经理和开发人员相互讲解此需求”。

就是说，当一个项目需求制定出来后。产品经理先根据自己的需求给大家讲解一遍。这时，大家可以根据自己处于的角色对此需求做评定。测试人员也可以参加，他们可以代表用户，指出哪里设计不符合常理等等。开发人员可以根据需求里面的专业知识点，深入咨询。产品经理在解答问题时，其他专业人员可以对答案做审核，给予补充等等。这样使得提问者能够更清楚地理解需求。

经过产品经理讲解后，大家回去可以细细研究一遍，对不懂的地方可总结到一起，必要时可做第二次讲解会议。如果已经没有异议，那么开始做概要设计。设计好后，开发人员召集大家，讲解一下自己的设计。让产品经理看看开发人员设计的是否合理，需求是否已经理解透彻。针对细节处，大家可以深度讨论。

通过这样的互相讲解需求的方式，就能保证需求设计的质量，以及开发人员理解需求的正确性。

如果您在开发中，遇到过事件中同样的问题。并且您所在的公司解决方法与我们不一样，也请您有时间给予指点，谢谢！