软件开发项目管理心得(一)

今天,再把项目管理中的一些体会整理出来,力争能形成一份较为系统的心得文档。

   一、需求调研阶段

   需求调研阶段工作的完成质量,直接影响着后续项目的所有进程以及项目成败。但是软件项目往往也是因为本阶段出了问题,想完全杜绝需求上的争议是不可能的,本阶段能做的,就是尽量把需求描述清楚,少出问题罢了。下面是我工作中的一些体会:

   1、对客户的需求要有所过滤

   调研时,面对客户中各级的人员,有高层管理人员,有中层管理人员,也有基层的操作人员。各人的立场不同,对软件的要求也不一致。有时候,他们提出的需求是本身管理制度的问题,软件本身就没办法实现,他们提出来本身就是一种诉苦,本来也不奢望软件能帮他们解决,这就需要对他们提出的需求进行过滤、筛选。譬如有时候库存人员要求软件能实现负库存,但财务人员却要求不能有负库存。针对这种情况,可以让财务跟库存人员直接对话,得出他们共同的需求。如果双方争执不下,则需要让领导出面决定,我们只接受领导的要求。

   经常在客户那进行调研时,被客户的很多要求搞晕了,以致到后面就是客户说什么我记什么,回来后才发现不合理,再打电话跟客户沟通时就不方便了,这就需要调研人员在工作时,要时刻保持清醒,至少要注意避免笼统接受客户要求的情况。

   2、客户的需求要汇总到同一个人身上再反馈

   有条件的话,这个人最好是客户公司的领导,对他们公司本身较熟悉,也有一定的权威。让客户把所以的需求都汇总到他身上,他对这些需求进行整理、分析后,再反馈给我,这样的需求较为可行,含金量也比较高。后续如果客户人员直接把问题反馈给我时,我也要先向他汇报,再由他判断是否需要进行。

   如果没条件有这么一个人的话,至少也要让客户指定一个项目负责人,此人与项目经理直接对口进行交流,避免了需求反馈到不同人身上而发生缺漏的情况。

   3、尽量不要做客户未最终确认的业务流程

   有时候,客户本身对自身的流程也未拍板决定,或者本来该流程就不知道能不能行得通。因为时间的关系,他们往往要求先这样做一下,后面看情况再调整。在需求调研时经常碰到这种情况,这种情况危害很大,后面实施时流程可能就不实用了,以致软件实施不上,或者该功能用不上,这就影响了软件的验收。

   对于这种情况,事先最好让客户先认真分析后再决定。也可以直接找公司的领导,由他们拍板决定。如果现在真的无法确定的,也要事先跟客户说明后续流程调整的就要属于变更,责任应该由客户自己承担。这样才能避免承担不必要的风险和责任,保护了自己。

你可能感兴趣的:(杂谈)