标签：
说起项目需求，之前聊了一个失败的范例，现在便聊一个成功的范例。
项目不大，只是一个技术难度不大的手机APP，而且只包括android版本，项目周期三个月。
好吧，又是三个月。
不过，这次的APP我并没有参与到开发中，纯粹只是参与了需求调研。因有老司机保驾护航的情况下，一路安安稳稳，虽小有波折，总体上来说还是比较顺利。
这个APP需要依赖客户原有的网站开发，但是原网站不是我们开发的，所以一些东西就变得复杂。当然变复杂的不是开发，根据协议我们开发人员直接操作原网站的数据库内容，而不需要原网站的研发人员为我们专门编写接口。真正复杂的是——需求，原网站的开发团队文档严重缺乏，我们只能从网站上采集需求。
首先，我们从网站上采集此次项目涉及的内容，将其中的内容进行整理成第一版需求文档初稿。
其次，与这个APP相关的部门进行沟通，并就采集到的内容进行确认。跟他们进行探讨，并对采集需求进一步进行深挖，扩充，删减。
在我们认为需求结束的时候，客户提供了一份原网站研发团队提供的需求规格说明书。经过几天分析后，我们发现，之前我们还是太嫩了。在这份需求规格说明书中，提供了更加详细的网站内部逻辑，与我们跟客户调研的并不一致。于是，我们只能再次根据这份文档进行分析。经过对比后，只能按照功能点一个个找客户进行确认，敲定其中的细节。值得庆幸的是，客户业务部门相当的配合。
当需求基本敲定时，三周没了。接下来，轮到设计文档。因为，在做需求的时候一直都有考虑代码编写的问题。关于设计上的绝大部分内容，我们都是心里有数的。所以，设计文档成型比需求文档还快。不过，也因为当时时间赶，考虑有些不周。当开发人员拿到我的设计文档时，莫名的看不懂。尤其是，网站某些功能的逻辑问题，最终还是重新进行了讨论，才最终交付。
----------------------------------------------------------------------------------------------------
关于这次需求调研，我谈几点个人感受。
首先，还是专业性。让客户知道公司的专业性，你的专业性。而这些东西，可以从你的言行，从你提交的文档上看出来。而这些都是可以缓慢建立你在客户心中信任基础的东西。
其次，细致。这指的是调研时，对于那些发现的问题一定要追究到底。一旦，有什么不确定的地方，千万不能有“大概这样，我认为......”之类的想法。不明白，不明确，就一定要找客户问清楚。如果当时无法找到客户，那么就记录到问题追踪表中，下次跟客户交流时，再找他们相关人员问清楚。当然，如果遇到客户也无法确定的情况时，就需要你来提供解决方案了。
最后，耐心。这个耐心不但包括跟客户沟通时的耐心，也包括写文档时的耐心。我们会发现，很多问题一说，双方大都能心有灵犀一点通。但若需要通过文字描述的时候，逻辑过程会变得相当繁琐、混沌。然而，程序代码是最讲究逻辑的，非黑即白。无法做到人类那般可意会。好吧，其实如果你的设计方案只能意会，只能说明你的设计方案还存在问题，需要继续修订。
标签：
原文地址：http://www.cnblogs.com/liuyp-ken/p/4861436.html
