项目三部曲

  前言:从项目的需求分析到项目的验收上线,经历的两个中型项目有几个问题记录一下,以便总结一点经验!!!


需求分析 

      描述:跟进的项目中开发所采用的方式为原型+迭代。顾名思义就是在原有模型的基础上分模板对项目进行结构功能上的改进。采用这一方式的前提是在客户提出的需求确定基本保持不变的情况,用这种方式比较恰当不同的模板得以分批或同时处理,在进度上比较快,能够很好的在规定时间内完成开发任务。然而在本项目中出现的问题就是,客户有的需求在前期没有那么明晰并且开发人员对于结构功能上的改进没有详细与客户沟通,导致的后果就是部分模块已按基本需求开发完毕等到与客户演示时对方无法认同结构上的改进。从而产生双方的不友好对接,继续改进,延期处理!

         想法:

      △待开发的模块提前和客户沟通,将要实现的功能具体到按钮。

      △△开发过程中有与客户需求违背(可以用更好的方式展现该功能)应该及时与客户沟通,使其明白为什么这样处理,这样处理有什么更好的实现效果。

      △△△确定需求确认书(重中之重),得到客户签字!!!


上通下达             

         描述:客户和本公司开发人员不同,客户不能随时跟进项目而开发人员夜以继日的开发,两者本身都不属于对等的关系,这时就需要中间人及时向上客户反映项目进展和向下开发人员说明开发问题了。在本项目中进行到中后期时,客户才给出相应的详细需求。听到这个消息后,内心不免得出现一点波动,顿时犹如波涛汹涌,翻江倒海。为什么开发都快结束才确定真正的需求?实在是心灰意冷,万幸的是经过和客户反复的沟通,在项目部分功能细节上进行了改进。导致的后果就是钱没了,时间开支,人员开支等等都白用了。

    想法:

    不要在逗留,客户那边不是任你开发来说的,还是上面那句话,及时沟通,避免无效的开发,都是钱。客户那边老师说,虽然我们看项目的时间不是很多,但是你们要有一个神出鬼没的本领,那就是拦截,下班的时候拦截,吃饭的时候拦截,不遗余力的跟我们讨论需求,居然还有这波操作!!!


基础创新

           描述:项目开发期间跟我leader聊天,leader说到客户那边的需求基本开发完毕,其中有几处是在需求的基础上进行的再创造,几处创新点,拓展点给客户留一个好的影响,目的就是两家公司可持续发展。但是客户那边好像不太满意,究竟为什么?问题就出现在在原有的基础功能上进行创新,客户只想要原来自己提出的功能,不需要再创造。本来是好心,却不知客户意了。最终的结果还算满意,来了一个折中方案。

    想法:

    客户提出的需求不要想当然,即使创新也得另起功能点或者事先告知客户,本来就是全心全意为客户服务!!



猜你喜欢

转载自blog.csdn.net/qq_39810861/article/details/80283805