产品给力需要每一个角色

      国外的开发不太清楚，工作五年了时间不算长。小作坊干过，大点的公司也干过。感觉在大部分公司在开发上的区别还没有到天壤之别的地步，特别是面向政府行业应用的。作为一个研发经常能听到产品实施人员对产品的抱怨，诸如产品问题太多，实施复杂，用户体验性不高等。他们认为研发是问题的底端，这也不错！到了产品实施的阶段研发的确是问题解决的最后保障。无论是研发，还是测试和实施人员他们都是想产品给力。可谁能才是让产品给力的关键呢？这个问题要说起来估计要写上几百部专著也是有可能的。就目前大部分公司以项目推动产品开发的模式，很多软件工程书本上说的东西就变得很难实行了。就拿前期需求的获取来说，所见大都是获取者不知问什么，如何问；提供者更不知提什么；要么搞回来一些天马行空不切实际的需求，要么是些笼统的不再笼统的说明。即便如此项目时间却也花去了大半，研发收到的这些只能以经验来揣测用户的意图，经过概要设计详细设计等一系统分析，不说精细即便粗略的做一下这些工作项目基本就快要到交付的时间了。经历中遇到研发中的问题也很多，比如在需求不明确的情况下大谈设计与模式（这也没有办法需求不明确没法谈），致力于设计万能扩展的框架（笔者不才也见识肤浅还没有真正见过这样的框架）。扩展性，复用性是建立在既定需求范围内的，以对需求的充分了解为前提的。很多时候计划，规范这些执行也有问题。计划，规范倒大都会提而且用一种非常重视的态度提出来。不过很少能执行的。因为缺少过程控制（原因可能没有时间），拿编码规范来讲对于些产品的开发公共的组件是必不可少的抽出这些来按照编码规范搞出来作为项目组成员开发库，这样可以有编码规范的参考依据。计划一般是有的但通常被打断，要不就是不合理。一般接口的定义要充分了解需求前面提到了这已经不太可能了，但至少也要评审一下一般很少评审，评审也流于形式。往往开发过后发现对不上，为了对上做一些转接很影响稳定性。就这样吧，产品在研发加班加点的情况开发完了，测试吧！测试其实不太好做，主要是测试本根不知道测试，因为研发得到的需求都不明确何况到测试呢？凭经验测吧！所见的大都几台测试机几个测试（当然是达不到软件工程上测试与研发的比例的），一、人员配比失调，二、测试环境简单，三、功能需求模糊（基本上研发去解释什么是正常什么是不正常）出现问题无法定位。这种很情况下测试也是很大程度上依赖于经验。最后总算是测试过了（看似问题也都解决了），实施吧！现场实施才发现，其实只是问题没有曝露罢了。而且问题及其诡异，总结原因一、产品确实有问题，二、前方人员的描述不清楚其中很多感性的分析和描述。在这种情况下对实施人员的要求是很高的，他必须能定位分析出问题出现的直接条件或根本原因，因为只有这样研发才能找到问题去修改。从实际情况看这种要求只有研发人员能胜任。不过这还不是最坏的，什么情况下最糟糕呢？项目开发，项目实施，项目支持这些并行时（大家懂得的，呵呵）真是噩梦啊！但做为开发常常有这样的噩梦，呵呵。。。

这样的现实下，要求研发要很强的行业经验了解用户的绝大多数需求和编程经验及能力，测试也要有很强的行业经验其实熟悉用户的环境。实施人员最好有研发能力。在笔者看来这是很难达到的，其中有很多原因公司管理，制度，社会压力等等，还是那句相信大家懂得的。其实在些环节上的每一个人都希望自己的产品给力的，但给力的产品需要每个环节都搞好才有可能。要搞好每个环节一定要从源头解决根本的问题。就现实而论产品的质量在很多行业里面并不是第一位。开发的现状就这样维持着。希望在现实改变前，我们做好了准备。产品给力，需要每一个角色！