对于新产品服务型Web软件需求管理的思考？——我的项目管理心得

对于Web软件而言，由于其通过浏览器访问的优点，有很大一部分不会像传统软件那样一套一套的去买，而是弄成一个服务型的平台，可以通过1对N的方式进行服务。

而且很多Web软件是出于一种创新，市面上没有现成的产品（或者有但是绝对不是完全重合），而软件的设计初衷就是满足某类潜在的需求，按照软件工程的做法，自然是要经历调研、立项、整理需求、设计、开发、发布、使用等步骤。但是在一些中小型公司，可能一个产品甚至一个平台性质的Web软件可能来自于老板或者整个公司高层一些想法就开始决定做了，而且一开始就交给本来为数就不多而且资源并不丰富的开发部。

这种情况为数不少。带来的问题通常软件按照当初高层定下的软件核心价值进行设置，而软件的需求多半要靠项目经理通过各种渠道去搜集、管理并把需求转化为软件的设计，才能进行后面的流程。对于没有经验的项目经理，或者只认为自己负责技术开发的项目经理可能到最后会发现，原来不是那样简单，因为接受的信息可能和实际的需求有很大的差别。

下面来看看笔者的真实情景。公司是做某传统行业软件的，因为业务的需求和网络的发展，需求是构建基于B/S的某应用软件，而之所以做这个决定是由于公司在长期运作中发现了这一潜在的需求，没有解决方案，如果能够解决这些问题就能够为目标客户带来很大的益处，而公司自然也能够从中受益。这自然是一个新产品的产生的最大动因。

难题是具体需求。因为公司高层的思维是不停的强化最初的想法，比如客户需要某个功能，他们会不停的思考应该满足这个需求。最糟糕的是高层难以避免的加入到了对软件需求的干预，提出他的想法，对于业务上来说可能是对的，但是对于软件需求来说却会给产品的开发带来麻烦，因为高层通常从核心价值观到一个小提示都会加入他们的想法，这样需求难以管理，开发也遇到困难。

到高层觉得不完善后，就把权威的希望寄托在业务上，此时业务往往由于忙于原有成熟的销售，思维自然不再新产品上。而对于业务来说，他们对于产品看法和真正的需求整理所需要的信息也是差距很大。

另外还有和客户技术层面接触最多的实施和技术支持部门，这个部门在业务上经验丰富，他们的对客户的认识是非常深刻的。但是对老软件的认识根深蒂固，有时候也会不经意的产生思维定势。

直接的客户的需求反馈，对于项目经理或产品经理来说，这些才是最重要的，但是往往这个最难以获取的。因为高层觉得公司的业务或者实施工程师就是权威，没有必要大规模进行客户调查（当然也是资源和时间的考量）。

笔者采取的做法先通过公司内部整理的初步需求开发出内部测试版，然后内部通过后，进行Beta测试。找到直接客户使用。这个时候高层的意见多数是直接转到测试小组，因为大部分其实是细节。另外通过调查等方式获得直接客户的意见，再把这些意见让公司的实施和技术支持工程师和市场人员进行讨论加工，这个时候得到需求基本就比较准确了。

做好对需求的把握和搜集，不仅是需要教条的规则，还需要要求项目经理因地制宜的把各种关系处理好，以便获得真实的需求，这样为一个新产品，尤其是服务型的产品质量打下了良好的基础。