导读:由于G端项目的特点，产品经理不能不了解项目管理，项目经理也不能不了解业务和产品。所以在做G端项目的时候，产品经理往往也会承担起项目管理的责任。笔者以一个服务于公安行业的综合业务系统项目为例，梳理出ToG项目产品经理需要具备的五大项目管理技能。
一、总体协调-项目边界管理
1.1明确项目目标
对于有明确合同约束的实施项目，最重要的是定义项目目标。在我们在职场上看重的“结果导向”特质中，这个结果是根据目标来定义的。
作为乙方，本项目最重要的目标是保质保量按期交付。
对于甲方来说，本项目最重要的目标是顺利验收各个功能模块，保证各个模块能够正常投入使用，提高本单位的工作效率。
1.2清晰的交付边界
对于这类强甲方主导的项目，有两个特点:高度定制化和传播需求。
所以项目进入实施阶段后，首先要做的就是仔细阅读合同和需求书，明确交付边界。
梳理项目整体结构，定义从基础设施层到网络层、应用层、表示层的交付边界。
基础设施层:
包括数据采集设备的类型和来源，存储资源、计算资源等基础资源的来源类型，是甲方提供的资源还是合同范围内的自行采集形式？是云资源还是物理资源？
网络传输层:
什么是网络环境？是专网还是互联网环境？是否涉及跨网传输业务？如果需要跨网络传输，是双向的还是单向的？传输渠道资源建设谁来提供？
业务应用层:
解决了以上两个基础资源的问题后，我们再来看用户可以直观感知的业务应用层。在这个层面上，首先要明确这个项目服务的用户范围，涉及哪些业务部门？有哪些业务模块可用？各功能模块的数据来源是什么？如果涉及对接第三方数据，数据准备和对接方式是什么？
以上“人生五问”基本明确后，就要开始进行有针对性的详细需求调研和梳理，明确各个业务模块的业务目标、用户群和业务逻辑。对于一个功能模块的交付目标，除了梳理以上三项，更重要的是对用户期望的管理。众所周知，在科技发展的征程中，系统建设也在经历几个里程碑式的迭代:信息化——数字化——智能化。当然，随着数字化转型的快速发展，目前大部分系统都在从信息化向数字化转型。那么应该明确目前的业务模块更适合信息化还是数字化？不管结果如何，在这一步，我们需要做的是和客户统一认知，明确预期。并在纸上描述预期的交付结果。
表示层:
然后我们来到了表示层。当业务模块和客户明确后，就需要根据使用场景来选择展现媒体。比如一体化指挥态势监控模块，使用场景是指挥中心对事件处置进行指挥调度，用户是指挥中心的用户和领导。需求是能够一览无余，快速调配所有的人力物力。那么呈现媒介是屏幕的较大屏幕端。另一个例子是在办公室处理业务的推销员的角色。他们的需求更多的是坐在电脑前处理业务操作，完成流程节点。所以大部分业务模块的主要功能都是在PC端完成的。再比如，公安有很多警察在外巡逻。他们需要在外面巡逻，不能长时间呆在办公室前面。所以他们对系统的体验媒介主要是移动的，比如巡逻签到、信息上报、接收指令、提交申请等。
在梳理了几种典型的呈现方式后，我们需要做的就是根据各业务模块的用户类型和需求，梳理出需要使用的呈现方式，并画出在不同的呈现媒介中需要完成的主要动作，以保证流程的完整性。
三。沟通——确定项目的外部利益相关者。
G项目中的利益相关者有很多种。按所属公司可分为内部利益相关者、项目组成员、甲方利益相关者和第三方利益相关者。
其中，甲方的利益相关者可以按照不同的职级、不同的工种、业务职责进行区分。
典型可分为三层:决策领导层、处理层和执行层。
决策，往往是部门负责人，是最终决定是否为这个项目买单的人。他们更注重价值和利益，而不是具体的细节。所以在设计功能方案时，大屏和各种数据的统计结果显示往往被视为领导关注的模块。他们最后想要的是“好看”两个字。当然，这里的“好看”不仅仅局限于UI设计的酷炫，还有项目效益的高价值感。例如，业务模块提高了业务部门的响应处理效率，项目产生了大量的社会效益，为单位的实际成就增光添彩。这些都是“好看”的。
管理层往往是这个项目中甲方实际的“项目执行经理”，我们在项目实施过程中接触最多的人。他们有的精通业务，有的熟悉技术，有的善于管理，注重结果。根据不同类型的管理者，有不同的沟通方式和侧重点。不管他们经历了什么，在这个角色中，他们最关心的一定是进度和交付质量。在与管理者沟通的过程中，核心是达成一致的目标，形成定期的汇报机制。
执行层作为系统的真正用户，可能来自不同的业务部门，有不同的业务需求。研究的主要对象是这个群体。功能上线后，培训和反馈研究的主要用户也是这个群体。他们关心的是功能是否好用，是否会给他们造成额外的负担。
第三方利益相关方:
是指通常与我们项目有对接的第三方单位或公司，比如数据对接、业务流程交互等。在这个场景中，我们需要对第三方涉众进行分类。有两种典型的类别:
甲方的兄弟单位，同样属于业务方，可能与我们甲方有业务交互，需要梳理业务边界，明确交互流程。第三方服务企业和我们一样，属于“乙方公司”。他们通常负责其他系统的开发，与我们的系统有系统的数据交互。我们需要做的是划分技术边界，明确对接的技术方式。
四。执行-项目进度管理
当项目需求边界梳理完毕，就意味着真正的项目实施和交付环节开始了。g端项目通常具有周期长、业务复杂的特点。为了避免项目的交付与客户的期望无关的纯瀑布式开发流程的弊端，我们需要根据合同要求，确定阶段性目标，锁定关键节点，倒排工期。
比如项目中包含采购服务，明确节点什么时候需要采购什么设备或者产品，做好相关的验收手续和材料。
对于系统开发的工作，需要找到关键部门的核心需求，根据前期研究的需要，进行优先排序，逐个击破。当然，这一步重要的是与甲方达成一致，并积极汇报实施过程中的进展和问题。
在管理项目进度时，需要提前对各个环节进行预估和沟通，以保证尽可能合理的分配和安排。避免把前期设计的时间安排一个月，只留三天开发。
动词 （verb的缩写）判断-项目风险管理
作为项目经理，除了对项目进度进行总体控制外，另一项重要职责是风险识别和控制，这在很大程度上决定了项目进度是否顺利。
在一般G端项目的实施过程中，通常存在以下三类风险:
1)项目延期风险
项目经理在进行进度安排时，通常会对设备采购、研究、设计、开发、测试各个环节进行分解和工期安排。有风险点的环节之一是设计环节。为了减少交付后的返工，面对强势的甲方，我们通常会选择在投入开发之前，先与甲方确认设计稿。这种方式相当于稀释了风险，把倾覆返工的风险放在了设计环节的前面，降低了返工成本。然而，它也是一把双刃剑。由于客户的多层次特点，设计稿确认的决策链条过长，管理者往往需要与一把手再次确认，因此这一环节的时间消耗无法准确估算。所以这一步，一定要做好“三轴”:前期充分调研，过程中反复确认，后期积极跟进。
2)需求变化的风险
在项目实施过程中，由于项目交付周期长，甲方领导的想法经常在变化。因此，需求变化的风险也经常存在。
要提前识别和规避这样的风险，最好的办法就是多问多报多记录。
多问:做需求调研和功能设计时，发掘根本需求，做充分的需求分析。多汇报:在梳理和设计的过程中，向需求方汇报和沟通，进行二次确认，保证你对需求理解的正确性。多记录:每一次沟通和确认都要进行书面记录，形成会议纪要。最好和需求方签字确认，减少甲方“贵人忘事”的可能性。3)进度调整的风险
除了需求范围和内容的变化，另一个常见的是甲方对原计划进度的临时调整。在以下三种情况下会发生这种情况:
一些突发的大型事件，涉及到甲方的业务职责，需要及时做出反应，配合工作。比如疫情或突发恶性事件，这类事件的特点是不可预测、不可避免，只能积极及时应对。响应的核心重点是“快”和“准”。第一时间与甲方相关人员或部门沟通，找出核心需求，以最小的时间成本实现需求，然后在后期进行调整和改进。对于大型节日活动来说，这类事件的特点是周期性和可预测性。如果你经验足够丰富，对甲方业务足够了解，可以在活动到来之前提前做好准备。即使在制定排班计划时，我们也可以将其考虑在内，提前规避排班变化的风险。关键利益相关者的变化，这种情况出现的频率较低，但也很难预测。关键利益相关者的变化主要体现在甲方单位负责人或管理者角色的变化。在上面关于确定利益相关者的部分，我们介绍了不同类型的人员有不同的关注点和管理理念。比如有的领导热衷创新，喜欢求新求异，有的一心求稳，只想先做好核心业务，不求有功，但求无过。在这种情况下，合同的最终交付结果不会改变，但交付过程中会对核心打磨模块和优先级进行较大调整。
不及物动词决策权-项目变更管理
作为乙方的项目经理，我们还需要明白一个“潜规则”就是几乎每个项目都不可避免的会有需求的变更和传播。我们可以做到以下几点:
了解需求变化的背景。是对交付的功能不满意，所以提出新的需求，还是因为业务或政策调整需要改变？
如果是前者，严格来说不是需求的延伸，而是对现有功能的优化。通过培训指导用户正确使用或优化交互体验，可以提高用户对功能的接受度。如果是后者，就要从业务调整这个核心点来突破。是否只需要调整原有功能模块的局部流程，就可以避免大的开发变更，节省开发成本？当然，这种情况属于需求变化。请提醒所有项目经理做好需求变更的记录，并遵循变更流程。新的需求完全超出了原来的交付范围。此时可以和甲方调查分析需求产生的背景和达到的目标，讨论是否可以延长二期建设，对新增需求进行记录，将新需求纳入二期建设范围，在收费前交付。
七。摘要
G端项目不同于常规的B端项目。除了标准化业务流程的共性之外，还具有更高的定制化、更多层的领导结构和对政策影响更敏感。所以在G端项目的实施过程中，我们需要以服务的心态去做更多的项目，针对不同的客户层次，提供不同的服务体验。同时，为了保证公司的成本和项目服务质量，必须做好风险识别和控制，从而更好地交付ToG项目。
本文最初由@发布上上上上上上上上上上上上上上上上上上上上上上上1未经许可，禁止复制。
题目来自Unsplash，基于CC0协议。
