编辑导语：业务项目经理需要在项目进行时挖掘需求、规划业务流程设计，并跟踪项目落地效果，做好管理分析。那么在这些工作职责中，项目经理应当从何处着手进行操作？本篇文章里，作者结合其工作经验给出了自己的方法论总结，一起来看一下。

　　笔者目前就职于一家电商公司，岗位Title是“项目经理（流程分析）”。职能是接收或提出系统需求、规划业务流程设计、业务培训和运营效果跟踪。

　　这个岗位在互联网电商公司比较少见，一般的电商公司由产品经理负责接收需求和出方案。这个岗位类似传统IT的需求分析师，但因为电商行业比较年轻，目前我工作内容还不像传统需求分析师那么规范，于是更多是自行在摸索岗位流程和深挖岗位技能。所以这篇文章除了分享自己所识所解，也是对自己几年工作的方法论沉淀。欢迎交流。

　　笔者目前归属业务部门而非产研团队，所属业务部门负责公司的产品开发，公司的主营行业是服装饰品。

　　这篇文章主要是介绍大的工作流程和框架思路，往后再有其它文章展开具体案例。文章内容适合产品经理、业务分析师、需求分析师等岗位对于需求的调研和挖掘，也适用于产品经理、项目经理对项目的安排，以及产品运营岗位的用户运营。

　　六个流程参考了 芭芭拉·A·卡克诺德的《7步掌握业务分析》、《PMP项目管理》，以及了解市场类似岗位工作流程，结合自己的工作，总结而出，仅作为参考。另外这个闭环比较适用于单个项目或需求，当有多个流程共同进行时，会同时穿插不同阶段的项目，以后再讲。

　　这一环节主要目的是判断当前阶段重点，结果是识别需求。通常很多岗位会定义为这一阶段为“接收需求”，但对于一位注重业务流程的分析师，这一阶段更重要的是自己挖掘需求。

　　此环节的主要目的是确认具体需求的背景、目标（最好可衡量），和业务共同梳理流程和细节，确保达到业务预期目的。通常业务人员首次提出的都是一个具体的功能，往往要深入探讨后得出可实现可落地的具体方案。和第一阶段的区别主要是具体功能的深入探讨。此阶段的难点是建立信任度和专业度。

　　这环节的目的是和产品输出最终落地方案，主要是探讨最终实现方式。此过程最重要的是对当前产研部门工作重心的了解，将业务的预期涵盖和嵌入开发计划中，可能面临业务目标的阶段性分拆。

　　此环节主要由产品先和开发人员评估技术实现方案和排期，需求分析人员主要的工作是确保时间符合业务预期，更多是作为一个项目经理的角色进行资源协调。

　　环节五接近流程尾部，主要确保上线操作符合业务期望，验收完成后进行培训和推广。此环节可能会发现很多开发前的漏洞，如遇到，需要考虑功能是否仍可上线。如上线需要和业务讨论可接受度，并安排进下一次迭代。如果可能的话，最好组织业务间的经验分享。

　　最后一个环节，其实也是下一大阶段的起点。这一阶段主要是复盘业务使用效果，评估和初始目标的偏差。

　　此阶段很容易被忽视（尤其当需求未正式立项时），但又是一个很重要的事。因为这一阶段才能真正积累对业务流程的认知，如果效果不进行复盘，很容易沦为一个实现需求的机器，无法在今后过程中真正引导业务和把控需求的主动权。

　　这一部分是对六个环节的细致解说，主要介绍每一环节的细致步骤、具体技术和方法。参考同样来自《7步掌握业务分析》、《PMP项目管理》，以及自己的实践。涉及的技能技术以后的文章再详细展开案例。

　　1）理解业务和部门现在和未来阶段的目标

　　目的：保证自己对公司大方向战略规划的理解正确。操作：了解公司公式的OKR、内部战略分享文件、外部对公司的报道、公司财报，以及竞争对手的动作。技术技能：公司共有文件发布渠道的了解、对信息的敏锐、开放的信息吸收、不断地学习。2）理解自己所在部门对于机构的价值

　　目的：确保自己的价值和优势地位（尤其是当刚到新公司新岗位时）。操作：公司组织架构和管理层级了解、部门当前工作在汇报中的重要程度。技术技能：对隐形信息的判断。3）了解干系人

　　目的：岗位的影响者及被影响者。流程分析这一岗位，涉及的有项目发起人、项目经理、用户、用户上级、QA、专家、开发人员、数据库人员、供应商等等。操作：了解组织架构，了解工作流程涉及的人。浅层的了解只是知道人名、岗位、工作内容。而深层的了解则是了解影响力、性格、能力、喜好、人员关系链等内容。技术技能：干系人评估（内容过大，以后的文章中会具体展开）。4）接收需求，记录需求池

　　目的：好记性不如烂笔头。另外对需求进行归类和优先级排序。操作：EXCEL表或在线文档都可。5）根据目标和现状差异梳理疑问

　　初级阶段操作：从自己角度输出对公司业务的理解，和对现状的疑问，从宏观角度输出现状思考。此环节不一定会和外部交流，当然有会更好。深入阶段操作：当入职2-3个月后，已经初步了解公司问题，可以从中间层和微观层梳理业务问题，列出清单，进一步准备落地的优化改善方案。

　　1）了解业务目标、达成情况

　　目的：重点是业务管理层对于现状的理解和未来预期，当然操作层也会有指标，但更重点要关注宏观要求。操作：单纯地了解情况不难，难点更在于如何与管理层建立良性关系和信任感，因为要了解的是业务的核心指标。一般可以通过从上（更上层管理者）到下的引荐，或者从下（对操作层的支持）而上的渗透沟通来慢慢建立深层关系。技术技能：干系人评估、沟通管理。2）理解业务部门操作流程、运营方法

　　目的：重点是了解执行层的操作方式和运营步骤。操作流程指系统或线下的一个个步骤。而运营方式更多是他们操作背后的管理方法和思路，可能是隐性不可直接获知的。操作：访谈、轮岗、梳理流程图（注意观察业务实际操作可能和描述的不一致）。技术技能：业务流程记录模板、需求核心组件记录（数据、过程、规则、主题）、根本原因分析（5WHY)、问正确的问题、有效地记录。3）明确需求目的，尽量量化出可衡量指标

　　目的：确认业务需要解决的问题，因为实现方式很可能会偏离目标。操作：单个流程中多个需求优先级排序，多个流程的优先级排序。技术技能：KANO模型。4）流程梳理

　　目的：明确方案的主流程和分支，尤其分支非常容易遗漏。操作：每个分支点都要做横向扩充，需要考虑有无需要反向流程的场景；主流程为主，副支需要考虑频率概率。技术技能：矩阵分析、决策树、概率树。5）考虑整条流程上的所有干系人操作

　　目的：为了可能提升全流程效率，除了内部用户，也尽可能考虑外部用户使用流程。

　　6）明确干系人中有效的决策者

　　目的：确认当前方案的所有影响相关方，尤其是企业内组织结构复杂时。操作：每个最小颗粒度组织单位中，都需要确认四类用户RACI，即决定者、执行者、（辅助）监督者、知情者。有时候这些人员的职能并不明确也不明显，还需要流程人员确认相似职能者，或推动业务负责人确认相关人员。技术技能：干系人评估。

　　1）和业务讨论初步解决方案

　　目的：尽可能梳理出多个方案和业务碰，以便和产研讨论时可做选择。技术技能：头脑风暴、HMW分析、元素拆分法。2）梳理系统流程，和产研输出实现方式

　　目的：此步骤主要由产研团队输出可执行方案，需要1-3周左右，最重要是确认实现方案符合业务目的（不一定能符合预期）。

　　3）风险预估

　　目的：评估流程风险和设置应对方案。

　　4）和重要干系人（对接职能人员、资深用户）确认

　　目的：和重要干系人确认最终方案和交互效果。技术技能：词汇库、用例、原型。5）确认效益指标需要的数据埋点

　　目的：尽可能确保需求上线后需要的效果可观测。操作：跟产研确认数据埋点是否可统计（简单覆盖量统计）、是否落数仓（较多且复杂的明细数据，不适合直接从操作系统导出）。

　　1）评估WBS、排序、历时估算、沟通机制、风险

　　目的：保证项目、需求，按时、按质、按量交付。技术技能：参考《PMP项目管理》。2）组织定期的需求反馈方式、协调优先级、安排资源

　　目的：和业务、产研双方分别开展定期的需求讨论会，重新明确当前问题点和需求优先级。技术技能：80/20规则、时间盒。3）需求和项目的具体排期

　　目的：需要产研侧输出具体的开发、测试、上线时间，并知悉业务。

　　1）验收：产研验收、流程人员验收、重点业务人员验收

　　目的：确保产品功能性无异常、大流程符合业务操作。注意点：确保产研验收通过后，再进行业务验收。和重点业务提前1-2天预约。2）正式上线推广培训

　　目的：面向所有用户教授其使用方法，B端产品功能性比较复杂，都需要专门的培训。操作：面授培训或者线上培训。面授试用于复杂功能、运营要求比较深的功能、创新性高不确定使用效果的小范围测试。线上培训适用于人数众多的小功能培训，最好不要超过半个钟。注意点：当流程改动比较大或过于复杂时，最好找部分业务人员先试行，再全面推广，因为可能会出现意料不到的问题。3）组织业务间的深度分享

　　目的：开展分享会，鼓励资深用户分享自己的操作和运营方法。一方面真实用户的分享信服度更大，有利于推广产品的使用。另一方面大带小，真正地推动提升用户的运营能力。

　　1）效益评估，和目标差距的复盘

　　目的：确认效果是否和预期相符，如果不相符需要总结经验教训，落到下一个迭代的计划中。操作：一般是统计相关指标，在前面第二步“需求理解——明确可衡量效益”已确定的。复盘周期根据项目实际情况安排，可以日、周、月不同的维度进行统计。2）定期汇报

　　目的：让项目相关方了解项目进展和目前问题。操作：根据项目需要，一般以周或双周频率展开项目会议，重要性特别高的项目还需要以周维护展开。当项目进入平稳运行阶段后，可以月维度进行。注意点：出色地呈现、接受批评性建议、认识你的弱点并克服它们。3）项目交付

　　目的：明确项目可完结，资源可投入其它项目中。操作：当项目按时按质按量完成后，即可与发起人确认是否结项。如可结项，需要召开正式的结项会议，和各相关方正式公布项目结束。如尚无法达到交付条件，则需要讨论项目是否需要延期，以及需要哪些人员支持。

　　以上是个人五年工作的一些总结和输出，和市面上常见的方法论、岗位职能并不一定匹配。目前的困境也是在于未来的岗位定位和规划，但有趣也在于可以不断去探讨新的认知。如果我梳理的内容和你有所共鸣，欢迎一起探讨^_^

　　本文由 @我叫更更 原创发布于人人都是产品经理，未经许可，禁止转载。

　　题图来自 Unsplash，基于 CC0 协议