干货分享：To G项目管理五力模型
一、统筹力-项目边界管理
1.1 明确项目目标
对一个有明确合同约束的实施项目来说，最重要的莫过于明确项目目标。我们在职场上所看重的“以结果为导向”的特质中，这个结果便是根据目标来定义的。
作为乙方，本项目最重要的目标即是如期、保质顺利交付。
对于甲方来说，本项目最重要的目标莫过于顺利验收每一个功能模块，并保证每个模块能投入正常使用，提升本单位工作效率。
1.2 明确交付边界
对于这类强甲方主导的项目，往往存在着高度定制化和需求漫延两大特性。
因此，在项目进入入场实施阶段后，第一时间要做的事就是熟读合同和需求书，明确交付边界。
梳理项目整体架构，从基础设施层、到网络层、应用层、展现层来做界定交付边界。
基础设施层：
包含数据采集设备的类型和来源，存储资源、计算资源等基础资源的来源类型，是甲方提供的资源还是合同范围内的自采形式？是云资源还是实体资源？
网络传输层：
网络环境如何，是专网建设还是在互联网环境下建设？是否涉及跨网络传输业务？如果需要跨网络传输，那么是双向传输还是单向传输？传输的通道资源又由谁提供建设？
业务应用层：
将以上两项基础资源的问题解决后，即来到用户能直观感知到的业务应用层，在这一层，我们要明确的首先是本项目服务的用户范围，涉及到哪些业务部门？具备哪些业务模块？每个功能模块的数据来源如何？如果涉及到对接的第三方数据，则数据准备情况以及对接方式如何？
以上“人生五问”基本清晰后，便要开始进行针对性的细化需求调研和梳理，对每个业务模块明确业务目标、用户群体、业务逻辑，对于一个功能性模块的交付目标，除了梳理前述三项以外，更重要的是做好用户预期的管理。众所周知，在科技发展的征途中，系统建设也进行着几个里程碑式的迭代：信息化–数字化-智能化。当然，随着数字化转型的高歌猛进，当前的大多数系统正从信息化向数字化转型。那么便要明确，当前业务模块，更适用于信息化呢还是数字化呢？不论结果如何，在这一步，我们要做的是，和客户统一认知，明确预期。并将预计交付的结果，述之纸上。
展现层：
接着我们来到了展现层。当业务模块和客户明确清楚后，随即便需要根据使用场景来选择展现介质。例如综合指挥态势监测模块，使用场景是指挥中心对事件处置进行指挥调度，用户为指挥中心的用户及领导，需求是能对全局态势一览无遗，并快速调配所有人、物资源。那么展现形式介质是屏幕更大的大屏端。又如办公室内处理业务的业务员角色，他们的需求更多是坐在电脑前处理一个个业务作业，完成流程节点，因此，大多业务模块的主功能都在PC端完成。再如，公安中有许多外部巡逻执勤的民警，他们需要在外巡逻，无法长时间待在办公室前，因此他们对系统的体验介质，以移动端为主，例如巡逻签到、信息上报、接收指令、提交申请。
梳理完成几种典型的展现方式后，我们要做的是根据每个业务模块的用户类型和需求，来梳理需要用到的展现方式，并绘制出在不同展现介质中所要完成的主要动作，确保流程完整。
三、沟通力-识别项目外部干系人
G端项目的干系人种类往往有多种。根据所属公司可分为公司内部干系人，及项目组成员，甲方干系人和第三方干系人。
其中甲方干系人可根据不同职级、不同岗位类型和业务职责来做区分。
较典型的可以划为三层：决策领导层，经办层，执行层。
决策领导层，往往是部门的一把手，最终决定是否要为这个项目买单的人。他们关注的更多是价值和效益，而不是具体的细节问题。因此在做功能方案设计的时候，往往会将大屏、各项数据统计结果的展示作为领导们关注的模块。他们要的最终就是“好看”两个字。当然，这里的“好看”不仅局限在UI设计的酷炫，更是项目效益的高价值感，例如业务模块提升了业务部门响应处理的效率，项目产生了大量的社会效益为单位实际的政绩添光增彩，这些都属于“好看”。
经办层，往往是甲方在本项目中实际上的“执行项目经理”，在项目实施过程中，我们接触的最多的人。他们有的精通业务、有的熟知技术、有的善于管理关注结果。根据不同类型的经办人，有不同的沟通方式和侧重点。不论他们曾经经历如何，在这个角色上，他们最关注的就必然是进度和交付质量。与经办人沟通的过程中，核心是要达成一致目标，并形成定期汇报机制。
执行层，作为系统真正的使用人，他们可能来自各个不同的业务部门，带着不同的业务需求。需求调研的主要对象就是这个群体，在功能上线之后，主要的使用培训对象、使用反馈调研对象也是这群人。他们关注的是功能是否好用，是否会给他们造成额外负担。
第三方干系人：
通常指和我们的项目有对接的第三方单位或公司，例如会有数据对接、业务流程交互关系。在这个场景中，我们需要对第三方干系人做好分类，典型的有两类：
- 甲方的兄弟单位，这类也属于业务方，可能和我们的甲方有业务交互，需要我们梳理好业务边界，明确交互流程。
- 第三方服务企业，与我们同样属于“乙方公司”，他们通常是负责其他系统的开发工作，和我们的系统有系统层面的数据交互。我们需要做的是划分技术边界，明确对接的技术方式。
四、执行力-项目进度管理
当完成了项目需求边界梳理后，意味着真正的项目实施交付环节启动。G端项目通常都具有周期长、业务复杂的特性。为避免纯瀑布式的开发流程导致的项目交付后和客户预期风马牛不相及的弊端，我们需要根据合同要求，确定阶段性目标，锁定关键节点，倒排工期。
例如项目内如果包含采购服务，则明确在什么时间节点需要采购什么设备或产品到位，并做好相关的验收流程和材料。
对于系统开发的工作，需要根据前期调研的需求，找到关键部门的核心需求点，排出优先级，逐个攻破。当然，这一步切记要和甲方达成一致意见，并在实施过程中主动积极汇报进度及问题。
在做项目进度管理的时候，要提前对各个环节做好预估和沟通，保证尽量合理的分配和安排。避免前期设计的时间安排一个月，而留给开发的时间只剩3天。
五、判断力-项目风险管理
作为项目经理，除了对项目进度的统筹把控以外，还有一个重要的职责便是风险识别和把控，这一项能力很大程度上决定了项目进展的顺利与否。
一般G端项目在实施过程中，通常存在以下三类风险：
1）项目延期风险
项目经理在做进度排期的时候，通常会将设备采购、调研、设计、开发、测试各个环节工期拆解排期。其中有一个存在风险点的环节，就是设计环节。为了减少交付后返工的情况，面对强势甲方我们通常会选择将设计稿和甲方进行确认后再投入开发，这样的方式相当于风险前移稀释，将推翻返工的风险前置到设计环节，减少返工成本。但是也是一把双刃剑，由于客户构成的多层级特性，设计稿确认的决策链条过长，且经办人往往需要和一把手再做确认，这个环节的耗时无法准确估计，所以在这一步，务必做好“三板斧”：前期调研充分，过程多次确认，后期积极跟进。
2）需求变更风险
在项目实施过程中，由于项目交付周期较长，甲方领导的想法也常常在变。因此需求变更的风险也高频存在。
要提前识别和规避这类风险，做好的办法就是多问多汇报多记录。
- 多问：在做需求调研和功能设计的时候，刨根追底探究出根本需求，做充分的需求分析。
- 多汇报：在梳理和设计过程中，多向需求方汇报沟通，做好二次确认，保证自己对需求理解的正确性。
- 多记录：每一次的沟通和确认都做好书面记录，形成会议纪要，最好和需求方做好签字确认，减少甲方“贵人多忘事”的可能性。
3）进度调整风险
除了需求范围和内容的变更，另一种很常见的是甲方对于原先排好的排期做的临时性调整。这种情况多发生于以下三种场景：
- 某些突发的大型事件，涉及到甲方的业务职责，需要作出及时响应，配合工作。例如疫情或突发恶性事件，这类事件的特性是无法预测且无法回避，只能积极响应及时应对。响应的核心重点在于“快”和“准”。在第一时间，和甲方相关人员或部门进行需求沟通，找到核心需求，以最小时间成本实现需求，后续再做调整完善。
- 大型节假日活动，这类事件的特性是周期性的可以预期的，如果经验足够丰富、对甲方业务足够了解，可以在活动到来之前，提前做好准备。甚至可以在做排期计划的时候，就考虑在内，提前做好排期变更的风险规避。
- 关键干系人的变更，这类情况发生的频率较低，但是也很难预测。关键干系人的变更，主要体现在甲方单位一把手或是经办人角色的人员变动。如上识别干系人一节中，我们介绍到不同类型的人员所关注的重点和管理理念不同，例如有的领导热衷创新，喜欢求新求异，而有的领导一心求稳，只想先做好最核心的业务，不求有功，但求无过。这种情况下，往往合同最终的交付结果不会改变，但是交付过程中的核心打磨模块和优先级会发生较大调整。
六、决策力-项目变更管理
作为乙方项目经理，我们还要明白的一条“潜规则”是，需求的变更和漫延几乎在每个项目里面都是不可避免的，我们能做的有以下几点：
了解需求变更的背景，是对已交付的功能不满所以提出新的需求，还是因为业务或政策调整带来的需求变更？
- 如果是前者，则严格来说不算是需求漫延，而是对现有功能的调优。可通过培训指导用户正确用法，或者优化交互体验的手段来提升用户对功能的接受度。
- 如果是后者，则需要从业务调整的核心点着手突破，是否只需要对原有功能模块的局部流程做出调整，尽量避免大的开发变更，节约开发成本。当然，这种情况属于需求变更，友情提醒各位项目经理，做好需求变更记录，走变更流程哦。
纯属于在原有交付范围外的新增需求，此时可以和甲方一起调研分析需求产生的背景和实现的目标，探讨是否有延伸二期建设的可能性，做好新增需求记录，将新增需求纳入二期建设范围中，先交付再收费。
七、总结
G端项目不同于常规的B端项目，除了需要标准化业务流的共性，还具备更高的定制化、更多层的领导架构、更敏感的受政策影响度。因此，在做G端项目的实施过程中，我们需要更多的怀着做服务的心态做项目，针对不同的客户级别提供不同的服务体验，同时为了保障公司成本和项目服务质量，我们一定要做好风险识别及把控这一步，才能够更好地做好ToG项目交付。
本文作者 @慢吞吞 。
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
