编辑导语:业务项目经理需要挖掘需求，规划业务流程设计，跟踪项目落地效果，做好管理分析。那么，在这些工作职责中，项目经理应该从哪里着手呢？在这篇文章中，作者根据自己的工作经验总结了自己的方法。让我们看一看。
目前作者在一家电子商务公司工作，职位名称为“项目经理(流程分析)”。职能是接收或提出系统需求，规划业务流程设计，业务培训，运营结果跟进。
这个职位在互联网电商公司并不多见。一般的电商公司，产品经理负责接收需求，制定计划。这个岗位类似于传统的IT需求分析师，但是因为电商行业比较年轻，目前我的工作内容还没有传统需求分析师那么标准，所以更多的是自己参与探索工作流程，挖掘工作技能。所以这篇文章不仅分享了我所知道和理解的，也沉淀了我几年工作的方法论。欢迎交流。
目前作者属于业务部门而非产研团队。业务部负责公司的产品开发，公司的主业是服装辅料。
本文主要介绍大的工作流程和框架思路，以后会有其他文章推出具体案例。本文内容适用于产品经理、业务分析师、需求分析师等岗位需求的研究和挖掘，也适用于产品经理、项目经理对项目的安排，以及产品运营岗位的用户运营。
一、基本工作流程(一个闭环)六个流程参考了Barbara A. Ka Knode的7步业务分析和PMP项目管理，以及市场上类似岗位的工作流程，结合自己的工作总结出来的，仅供参考。此外，这种闭环比较适用于单个项目或需求。当多个流程一起进行时，不同阶段的项目会同时穿插进行，后面会讲到。
1.环节一:发现和接收需求这个环节的主要目的是判断当前阶段的重点，结果是识别需求。通常很多岗位在这个阶段定义为“接收需求”，但对于一个关注业务流程的分析师来说，在这个阶段自己挖掘需求更重要。
2.链接2:需求理解和指导。这一环节的主要目的是确认具体需求的背景和目标(最好是可衡量的)，并与业务梳理流程和细节，确保实现业务的预期目的。通常业务人员第一次提出一个具体的功能，往往要深入其中才能得到一个可以实现和落地的具体方案。第一阶段和第一阶段的区别主要是对具体功能的深入探讨。这个阶段的难点是建立信任和专业精神。
3.链接3:解决方案设计和评估。这个环节的目的是和产品一起导出最终的落地方案，主要是讨论最终的实现方式。在这个过程中最重要的是了解当前生产和研究部门的重点，并将业务预期覆盖和嵌入到发展计划中，这可能会面临业务目标的阶段性分离。
4.链接4:日程安排和项目管理。在这一环节中，首先由产品和开发人员评估技术实施计划和进度安排。需求分析师的主要工作是确保时间满足业务预期，更重要的是作为项目经理协调资源。
5.环节五:上线验收推广环节五接近流程结束，主要是保证上线运营达到业务预期，验收完成后会进行培训推广。在这个链接中可能会发现很多开发前的漏洞。如果遇到，就要考虑功能还能不能在线。如果需要上线，和业务讨论可接受性，安排下一次迭代。如果可能的话，最好组织商家之间的经验分享。
6.环节六:目标复盘整改的最后一个环节，其实是下一个大阶段的起点。这一阶段主要是复供业务的使用效果、评价和初始目标的偏差。
这个阶段很容易被忽略(尤其是在需求没有正式建立的时候)，但却是一件非常重要的事情。因为这个阶段确实可以积累对业务流程的认知，如果不重新评估效果，很容易成为实现需求的机器，无法真正指导业务，在未来主动控制需求。
第二，每个环节的具体流程。这一部分是对六个环节的详细说明，主要介绍每个环节的详细步骤、具体技巧和方法。参考资料还来源于《掌握商业分析的7个步骤》、《PMP项目管理》以及本人的实践。所涉及的技能和技术将在以后的文章中详细讨论。
1.发现并接受需求1)了解业务和部门目前和未来的目标。
目的：保证自己对公司大方向战略规划的理解正确。操作：了解公司公式的OKR、内部战略分享文件、外部对公司的报道、公司财报，以及竞争对手的动作。技术技能：公司共有文件发布渠道的了解、对信息的敏锐、开放的信息吸收、不断地学习。
2)了解你的部门对组织的价值
目的：确保自己的价值和优势地位（尤其是当刚到新公司新岗位时）。操作：公司组织架构和管理层级了解、部门当前工作在汇报中的重要程度。技术技能：对隐形信息的判断。
3)了解利益相关者
目的：岗位的影响者及被影响者。流程分析这一岗位，涉及的有项目发起人、项目经理、用户、用户上级、QA、专家、开发人员、数据库人员、供应商等等。操作：了解组织架构，了解工作流程涉及的人。浅层的了解只是知道人名、岗位、工作内容。而深层的了解则是了解影响力、性格、能力、喜好、人员关系链等内容。技术技能：干系人评估（内容过大，以后的文章中会具体展开）。
4)接收需求并记录需求池
目的：好记性不如烂笔头。另外对需求进行归类和优先级排序。操作：EXCEL表或在线文档都可。
5)根据目标和现状的差异整理问题。
初级阶段操作：从自己角度输出对公司业务的理解，和对现状的疑问，从宏观角度输出现状思考。此环节不一定会和外部交流，当然有会更好。深入阶段操作：当入职2-3个月后，已经初步了解公司问题，可以从中间层和微观层梳理业务问题，列出清单，进一步准备落地的优化改善方案。
2.需求理解和指导1)理解业务目标和成就。
目的：重点是业务管理层对于现状的理解和未来预期，当然操作层也会有指标，但更重点要关注宏观要求。操作：单纯地了解情况不难，难点更在于如何与管理层建立良性关系和信任感，因为要了解的是业务的核心指标。一般可以通过从上（更上层管理者）到下的引荐，或者从下（对操作层的支持）而上的渗透沟通来慢慢建立深层关系。技术技能：干系人评估、沟通管理。
2)了解业务部门的操作流程和方法。
目的：重点是了解执行层的操作方式和运营步骤。操作流程指系统或线下的一个个步骤。而运营方式更多是他们操作背后的管理方法和思路，可能是隐性不可直接获知的。操作：访谈、轮岗、梳理流程图（注意观察业务实际操作可能和描述的不一致）。技术技能：业务流程记录模板、需求核心组件记录（数据、过程、规则、主题）、根本原因分析（5WHY)、问正确的问题、有效地记录。
3)明确需求的目的，尝试量化可测量的指标。
目的：确认业务需要解决的问题，因为实现方式很可能会偏离目标。操作：单个流程中多个需求优先级排序，多个流程的优先级排序。技术技能：KANO模型。
4)流程梳理
目的：明确方案的主流程和分支，尤其分支非常容易遗漏。操作：每个分支点都要做横向扩充，需要考虑有无需要反向流程的场景；主流程为主，副支需要考虑频率概率。技术技能：矩阵分析、决策树、概率树。
5)考虑全过程所有利益相关者的操作。
目的:为了提高整个流程的效率，除了内部用户外，还应尽可能考虑外部用户。
6)在利益相关者中确定有效的决策者。
目的：确认当前方案的所有影响相关方，尤其是企业内组织结构复杂时。操作：每个最小颗粒度组织单位中，都需要确认四类用户RACI，即决定者、执行者、（辅助）监督者、知情者。有时候这些人员的职能并不明确也不明显，还需要流程人员确认相似职能者，或推动业务负责人确认相关人员。技术技能：干系人评估。
3.解决方案的设计和评估1)与业务部门讨论初步解决方案。
目的：尽可能梳理出多个方案和业务碰，以便和产研讨论时可做选择。技术技能：头脑风暴、HMW分析、元素拆分法。
2)梳理系统流程和产学研用的实现方式。
目的:这一步主要是生产和研究团队输出可执行的计划，大约需要1-3周。最重要的是确认实施计划符合业务目的(不一定是期望)。
3)风险评估
目的:评估过程风险并制定应对计划。
4)与重要利益相关方确认(对接职能人员和高级用户)
目的：和重要干系人确认最终方案和交互效果。技术技能：词汇库、用例、原型。
5)确认效益指标要求的数据埋点。
目的：尽可能确保需求上线后需要的效果可观测。操作：跟产研确认数据埋点是否可统计（简单覆盖量统计）、是否落数仓（较多且复杂的明细数据，不适合直接从操作系统导出）。
4.进度安排和项目管理1)评估WBS、排序、持续时间估计、沟通机制和风险。
目的：保证项目、需求，按时、按质、按量交付。技术技能：参考《PMP项目管理》。
2)定期组织需求反馈，协调优先级，安排资源。
目的：和业务、产研双方分别开展定期的需求讨论会，重新明确当前问题点和需求优先级。技术技能：80/20规则、时间盒。
3)项目的需求和具体进度
目的:产研端需要输出具体开发、测试、上线时间，了解业务。
5.上线验收推广1)验收:生产、科研验收，工艺人员验收，关键业务人员验收。
目的：确保产品功能性无异常、大流程符合业务操作。注意点：确保产研验收通过后，再进行业务验收。和重点业务提前1-2天预约。
2)正规的在线推广培训
目的：面向所有用户教授其使用方法，B端产品功能性比较复杂，都需要专门的培训。操作：面授培训或者线上培训。面授试用于复杂功能、运营要求比较深的功能、创新性高不确定使用效果的小范围测试。线上培训适用于人数众多的小功能培训，最好不要超过半个钟。注意点：当流程改动比较大或过于复杂时，最好找部分业务人员先试行，再全面推广，因为可能会出现意料不到的问题。
3)组织商家间的深度分享。
目的:举办分享会，鼓励资深用户分享自己的操作和操作方法。一方面，真实用户更相信分享，有利于促进产品的使用。另一方面是以大促小，真正促进了用户运营能力的提升。
6.目标恢复和整改1)效益评估和目标差距恢复。
目的：确认效果是否和预期相符，如果不相符需要总结经验教训，落到下一个迭代的计划中。操作：一般是统计相关指标，在前面第二步“需求理解——明确可衡量效益”已确定的。复盘周期根据项目实际情况安排，可以日、周、月不同的维度进行统计。
2)定期汇报。
目的：让项目相关方了解项目进展和目前问题。操作：根据项目需要，一般以周或双周频率展开项目会议，重要性特别高的项目还需要以周维护展开。当项目进入平稳运行阶段后，可以月维度进行。注意点：出色地呈现、接受批评性建议、认识你的弱点并克服它们。
3)项目交付
目的：明确项目可完结，资源可投入其它项目中。操作：当项目按时按质按量完成后，即可与发起人确认是否结项。如可结项，需要召开正式的结项会议，和各相关方正式公布项目结束。如尚无法达到交付条件，则需要讨论项目是否需要延期，以及需要哪些人员支持。
三。总结以上是自己五年工作的一些总结和产出，不一定和市场上常见的方法论和岗位职能相匹配。目前的困境也在于未来的工作定位和规划，但有趣的是我们可以不断探索新的认知。如果我梳理的和你有共鸣，欢迎一起讨论_
本文由@我的名字更原创发布。每个人都是产品经理。未经许可，禁止复制。
来自Unsplash的图像，基于CC0协议。
TAGS：
