软件开发项目管理心得（一）

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

   一、需求调研阶段

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

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

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

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

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

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

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

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

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

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