一个失败项目的思考

   最近一个项目,进展非常缓慢,问题始终没有解决,上线时间一拖再拖,而且产品人员测试,总会出现这样或那种的问题.
   总结了一下问题的原因,以及从这个项目中的收获.
   1,没有进行难点预研:因为这个项目是基于语音搜索,需要由客户端上传语音到服务器,而前端的硬件环境和网络环境都比较低端,对于上传和接收较大的文件,前端和后台开发人员并没有这方面的开发经验.而开始没有对这个难点进行预研,导致在后期的开发中,其他功能基本都做好了,但上传文件一直没有很好解决.搞得项目拖了三个月,都没有突破,顺利上线,而到这个时候,无论放弃或者继续研发,都是一种痛苦的折磨.放弃又心不甘,继续又不知道何时能解决.讨论到最好,还是决定继续尝试新的方式.如果有预研,对这个难点先进行研发和测试,如果花上两周甚至一个月都不能突破,这个项目就要暂停,或者找有这方面经验的人来开发.而不至于出现目前这种进退两难,开发人员很累,产品人员很烦,大家都没有什么信心的局面!
   2,前端和后台开发人员沟通不到位:这个项目需要前端和后台开发人员一起很好配合.但是又存在一个很大的问题,就是前端人员不懂后台的开发,后台人员不懂前端的开发.这样,就导致在数据传输过程中,很难确定到底是前端没有成功发送数据,还是服务器没有成功接收数据.基于这种情况,最好的方式,就是前端和后台做到一起,共同来讨论,一起调试,不断的交流,才有可能更好地解决问题.
   3,技术自测不到位:产品人员反映,研发人员给的样机,说没有问题,但一测试,就是有很大的问题.搞得又来让研发人员修改,这样造成了产品人员对开发人员的影响很不好,说明开发人员,不够细心,没有做好基本的测试工作.从中可以看出,研发人员要自己测试好,有时宁可慢点,也要确保质量,减少修改和查错时间.
   4,没有进行版本控制:没有版本控制就会造成,今天解决了一个问题,但又暴露出前几天解决了另一个问题.如果研发人员在不断修改,而没有版本控制,就有可能,你根本不知道哪天解决了哪个问题,很可能解决的问题又被覆盖了.为解决这样的问题,版本控制就必须做好.
   5,没有很好的测试流程和测试文档:由于以前没有专门的测试人员,先是由研发部门测试一下,然后由产品部门测试.从来没有完整的测试流程,也没有什么测试文档.目前正在搭建测试团队,招聘测试人员.正规的流程,应该是研发人员完成后,由测试人员来测试,然后将BUG反馈给研发人员,让研发人员修正.测试人员通过后,再让产品人员来试用,提出一些人性化的修改建议,和一些性能方面的要求.这样的话,到产品人员手中的产品,应该是一个试用版软件,而不是一个充满BUG的程序.所以,完整的测试文档,示范的测试流程,好用的测试工具,有效的测试方法,就显得特别重要了.
  
   通过思考,应该规范软件开发的流程:
   1,产品部提供产品需求文档.
   2,研发部(前端和后台)进行需求分析,并作出需求分析报告.
   3,难点评估和难点预研.
   4,确定产品的开发时间表.
   5,全面正式开发,分工配合.
   6,研发人员自测.
   7,测试人员测试.
   8,修正测试人员提出的BUG.
   8,生成Demo.
   9,产品人员试用,并提供修改意见,包括哪些地方要优化性能,要提高响应速度,哪些地方要进行修改,以更加人性化,增加用户体验.
   10.优化软件,再次测试.
   11,正式上线推广运营.

   虽然这个项目,没有很好开展,但从中的收获,却永远受用!