需求阶段

在接到任务后,先与业务员(商务)进行需求沟通,多提出业务员当时未向客户提出的关键问题,详细了解需求并试图想到解决需求的方法,与业务员沟通解决方法是否可行,以及成本预算是否在合理范围内。

在了解需求清楚以后,进行需求的评估。出具需求详细列表,向业务员展示需求的内容,并由业务员进行确认,业务员确认不了的向客户进行确认。如果是数据接口方面,在不了解需求业务流程,则尽量和业务员进行多次的沟通,确定业务流程以及业务流程中数据获取的方法,客户系统的菜单流程等。

客户有可能急需一个评估价格和评估时间。在评估时间的范围内要加上20%到30%的时间。此时实际上只是一个需求列表,并没有一个进行原型设计,如果时间允许的话,最好是出具原型图,这样方便业务员和客户进行沟通及展示。

本次沟通要出具文档:《需求说明书》,并由业务认可。说明书在实际中即使确认了也有可能变更,则要出相应的新文档,并由业务员确认。在开发过程中是按需求分配任务和开发,没说到的更加细节的地方则需要有相应的《需求变更书》。如登录在需求中要说明是否进行录入框的验证,以及验证的要求,不能因此让业务员说这是常识要求而不是需求变更。在需求沟通时在要提出来并记录在需求文档中,同时提醒业务员是按需求文档进行开发,没说的就可能会造成延时或者后期再开发,一定要有需求变更书。

很多时候业务员并不了解实际完整的需求,则根据业务员的描述进行尽量的需求想像的描述,最好不要评估时间,否则业务员会以此时间向客户报价和时间,即使预增加了时间,在完全明确需求后会发现需求比当时要多很多,但时间不会增加。

此时可能业务员就将任务完全甩开,而由开发人员去进行现场沟通、客户确认直至开发结束、上线、实施,甚至收尾款。如果涉及集成产品,业务员也可能不会去处理,只是开发人员在不能获得实际结果(如当初业务员与集成商签订合约时,上面所说的一些功能没有实现,或者新的要求需要实现的话集成商提出费用问题)时才会去与集成商沟通协调。因为没有产品经理、项目经理的说法,所以全部由开发人员协调。即使有产品经理一职,也可能只是表面的业务员转化,产品或项目的一些具体工作是不会去做的。在这种情况下,一定要确认好需求,不能贸然答应相关任务,一定要回复说考虑一下并发邮件确认,并且出具需求变更书。

在日常的需求编写中进行知识积累,这样每当客户提出相关要求时候就可以重复使用。

这个阶段对于开发公司来说,实际上是需要一个产品经理来进行的,需求的了解,以及规划、设计产品应该是什么样子的,但在实际的公司运作当中,基本上没有或者是只是老板自己,或者让业务员来做产品的需求,或者让开发人员进行现场调研,做产品需求,做产品经理需要做的事情。而且在产品不是产品的情况下,叫做项目时(实际上是可以当作产品)进行产品的设计以及将来之后的项目分解,才可以更好地进行梳理。

无论是否将这个职责,或者说将这个责任指定给你,一旦接手进行需求分析,与客户沟通,实际上已经在作为一个产品经理了,并且在做产品经理该做的事情的大部分时,那么,既然做了,那你就该担当起相应的责任。如果不去担当起相应的责任,那么在开发当中,就会形成艰难的一个过程,而且在收益上你将达不到相应的收益,你只是一个开发人员的身份,拿到开发人员的收益而已。