【原创】客户方领导与业务人员对项目影响分析

【原创】客户方领导与业务人员对项目影响分析
 作者：沈哲磊 2005－04－15
 项目开发的过程，就是人与人之间交流和沟通的过程，项目开发的复杂性
也体现在了人员类型的广泛和沟通的困难。记得巴比塔的故事，上帝为了不让人们
建成巴比塔，就扰乱了人类的语言，使人们沟通困难，所以巴比塔就成了一个失败
的项目。

 从项目的整个建设周期，我们会碰到大量知识体系、观念见解、立场都各
不相同的人员，如何理清人员间的关系，使这些人良好的沟通互动，从而对项目产
生良好的推动作用而不是阻碍或者拖延项目的进展，是项目经理不得不面对的问题。

 若按照一般的思路，项目中涉及的人员可以简单分为技术人员和业务人员，
技术人员向业务人员了解需求和业务流程，并按要求开发出相应的系统指导业务人
员使用。但在实际工作中按照这样简单的思维方式是远远不够的，我们必须将项目
各种人员都详细识别出来，标记他们对项目的影响范围和影响程度，从而有计划和
策略的引导这些人员为项目的成功服务。
 
 为了描述方便，沈哲磊制定了如下的人员分类表
   项目关联人员分类表：
　　　　　－－－－－－－－－－－－－－－－－－－－－－－－－－
　　　　　|　　　客户方　  　|　　开发方　 　　|　其它关联单位
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
高层领导　|　　客户单位领导　|　开发单位领导　|　分包开发商领导
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
项目管理　|　　客户开发领导　|　开发项目经理　|　分包商项目经理
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
项目开发　|　　业务描述人员　|　开发技术人员　|　业务关联被调研单位
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
项目实施　|　　业务操作人员　|　安装调试人员　|　设备采购部门
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
项目维护　|　　系统管理小组　|　技术支持小组　|　关联系统维护组
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

 通过上表，我们可以看到，这是一个由三类单位构成的有层次的体系，
15种不同层次的人员在不同的阶段按顺序进行着横向与纵向交流与互动。
 
 其中不同的人员在项目的过程中发挥着不同的作用，在以往的开发管理思
想中，大家往往重视的是项目开发方的管理和开发流程的控制，着重于如何在有限
的时间和成本限制下高效的完成任务。但客户满意才是成功的评判标准，如何管理
客户，调动客户的资源
为项目的成功服务？

 在本文中，沈哲磊仅探讨客户方五类人员对项目的影响：
（客户单位领导、客户开发领导、业务描述人员、业务操作人员、系统管理小组）

客户单位领导：
 领导重视原则是项目成功的首要原则。
  在项目启动前期，客户方单位领导往往
    1）作为开发需求的初始提出者启动一个项目的初始规划和可行性分析
    2）同时作为客户方最高领导与开发单位高层领导协调项目的初始资金预算和
         初始进度计划。
    3）组织或指定本单位某些相关领导，参与项目管理或开发指导、协调。
  在项目启动后、开发过程中，客户方单位领导往往
    1）作为客户方资源的最终调配者，保障项目在许可范围内资源的追加
    2）作为问题或争端的客户方协调者，争端在需要业务流程、制度变更时是常
         常发生的。
    3）作为业务关联单位的联系人，协助开发方到关联单位调研分析业务的接洽
  在项目实施后，客户方单位领导往往还作为最终的验收者，负责验收项目质量，
 并最终接受项目成果。

    通过客户单位领导在各个阶段的工作，我们可以看到，客户单位领导是项目开
发是否成功的最终评判者，是对项目整体宏观需求有完整把握的直接需求提供者，
更是客户方资源和客户方关系的调配者。无论如何，项目经理也要尽力把握客户方
单位领导的宏观需求，协调和发挥客户方单位领导的主观能动性，从而促使项目在
各方面能够将人为因素和资源阻碍降到最低，最终引导项目走向成功。

   
客户开发领导：
    客户开发领导是由客户单位领导指定的项目委员会成员。往往具有一定的
实际领导权限，并熟悉客户各种业务流程，甚至同时也熟悉项目的技术开发。
    客户开发领导由于具有客户单位领导的授权，和开发单位领导的许可，可以
参与项目的具体管理过程中，及时的了解项目的进展情况，并努力对项目过程中非
开发技术因素产生的阻碍协调解决。
    有一部分开发单位认为不应将客户方领导引入开发团队，认为这样将会被逼着
在短时间内完成不可能完成的任务，或者客户开发领导在需求调研结束后，提出对
系统更多的功能要求，最终可能导致项目失败。
    这种认识是错误的。这种情况往往发生在开发企业本身开发过程不规范，对于
项目范围管理、合同管理、以及需求变更管理不完善所导致的。对于一个管理规范
的开发企业，经过评审的文档和合同对于项目范围、时间约束都是十分清晰的，即
使由于认识深入发生需求变更，也可以采用良性的方式，采用双方接受的变更管理
或者预先合同约定的附加子合同形式进行再次范围约束和调整。当然，附加子合同
往往同时涉及新的追加费用、调整开发时间问题，对于开发单位可以从经济和时间
上得到补偿，也避免了对于客户单位不会由于不了解进度和开发情况，在最后验收
时否定项目，导致项目失败的风险。客户方也能够得到全部期望的功能。同时保障
了开发单位和客户单位双方的利益。
    当然，作为开发单位团队要经常的定期的向客户开发领导汇报项目进度和阻碍
情况。使情况得到客户方的理解和支持，得到缓解。
    客户开发领导往往也作为需求的描述者每周定期或全天接受系统分析师和技术
团队的咨询和调研。并协助团队进行跨部门、跨单位的业务调研和实施工作。

业务描述人员：
    业务描述人员不仅包括了客户开发领导，和业务部门经理，更广泛的包含了业
务的具体操作人员、关联单位业务人员。
    系统分析员往往难以深入了解企业的业务流程，调研业务流程和设计系统架构
依赖于他所接触的人员和相关流程文档。如何在尽可能短的时间内，将业务流程分
析清晰、透彻是一件非常具有挑战的工作。
    通常系统分析员做的工作是收集文档，倾听各类各流程业务相关描述人员的描
述，然后分析文档，从中提炼出能够涵盖描述业务流程和相关数据信息。但这样是
不够的，由于业务描述人员的多样性，和业务人员自身对业务掌握情况和程度的不
同，同一个流程往往有多个似是而非的表达方式。而且，由于系统建设必将影响业
务流程和工作习惯的建设特殊性，总是存在对业务人员本身工作的正面或负面影响，
不同人站在不同的位置，对项目建设也会采取支持、回避甚至阻碍的态度，这也导
致业务描述人员描述的偏差。所以，系统分析员应尽力从宏观的角度分析业务流程，
大胆假设，小心求证，必要时候甚至考虑调整优化现有的业务流程，再由全部领导
评审通过，保障业务流程描述的正确性。

业务操作人员：
    业务操作人员在需求调研阶段承担业务描述工作，他们是系统的最终使用者，
是系统内各种数据和资料的提供者，只有他们顺利的使用系统，并且乐于使用系统
来提高日常工作效率，系统才能够说是真正的建设成功。
    所以项目经理要主动有效的调动业务人员的积极性，消除业务人员对使用和推
广系统的顾虑，无论这种顾虑是由于对系统的不熟悉、对计算机的不熟悉或者对系
统实施带来的业务流程调整、工作方式改变等原因，项目经理都要想办法解决。
    可以采用使用培训、数据初始化等方式降低系统的使用难度。但更应该在一开
始系统调研时就抱着如何为业务操作人员考虑的心态，与业务操作人员探讨应该如
何方便其工作，降低其工作的重复性和减轻工作负担。这将调动业务人员的积极性，
从而使调研工作顺利进行，以及开发实施的配合支持。
    并且业务人员接受系统程度越高，整个项目长期成功的可能性就越高。

系统管理小组：
    系统管理小组是系统实施后经过系统管理培训的客户方维护小组。客户方系统
管理小组承担了系统日常的用户、权限、数据信息、临时使用帮助的管理工作。
    系统管理小组的工作成效，将直接影响系统使用的效果。组建和培训一个具有
一定技术能力的客户方系统管理小组，将大大减轻开发单位的技术支持工作量和工
作强度。并且，能够提高解决问题的响应速度，提高用户满意度。
    为了加强系统管理小组的工作能力，应在系统基本开发完毕，进入beta测试阶
段时，就开始编写相关维护说明书和相关文档，组建和培训客户系统管理小组。
让客户系统管理小组同步参与系统实施过程，并在实施后，开发单位应保持一个技
术支持小组跟踪和在技术上辅助客户系统管理小组的日常工作。

总结
    通过对客户方各类相关人员的分析，大家可以看到，一个项目的成功，缺少了
客户方人员在工作上的大力支持，基本上是不可能的。
    而合理和有效的引导客户方各类人员为项目的提供支持帮助和指导，将取得项
目的成功，并最终获得客户单位与开发单位双赢的良好效果。

作者：沈哲磊 2005－04－15   http://blog.powrise.com