编辑导语：作为一名产品经理，在日常工作中需要面对多方的问题，需要有把控全局的能力、准确的判断能力等等，也要有足够的经验；本文是作者分享的关于新人产品经理在做项目管理时遇到的问题，我们一起来看一下。

产品经理是一个讲究综合素质的岗位，产品经理会被领导、开发、运营人员不断地挑战，期间充斥着被怀疑与自我怀疑；新手产品经理需要积极培养个人的逆商，并不断学习总结复盘，减少重复性犯错的可能，总结优秀经验，才能逐步成长，成为一名优秀的产品经理。

公司的一套较为完善的人工智能产品，个人在做相关产品规划工作，通过在整个系统流程上引入某系统产品A，进而实现整个流程的智能化；我作为整个方案的设计方及需求方，同时也是其中某个系统的产品经理，身份比较复杂，但整体上我是承担需求方、方案设计产品经理、项目推动项目经理，三个角色。

因为个人做产品经理时间不是很长，所以经验明显不足，在整个项目过程中主要暴露了作为产品经理的方案设计问题以及作为项目经理的项目管理问题，作为记录也作为经验共享，分享给新人。

一、项目背景

项目涉及系统：前端H5、前端SDK、两个中间系统、系统A、系统B。

项目涉及人员：6个系统各一位产品，各系统对应开发及测试12人（每个系统至少1位开发一位测试人员），业务需求方（2位），整个项目涉及至少20人。

项目整体趋势：两个中间系统准备重新划分职责，整个流程推进智能化，整体趋势向好。

二、项目过程

项目起初利于提升某运营指标实现降本增效，经过一段时间的调研与产品设计，计划在该流程中引入现有策略产品，从而实现整个流程的智能化；个人在此项工作中承担产品经理的角色。

需求实现自始至终出现了以下问题，严格意义上，这是个人第一次承担比较大的产品规划管理工作。

1. 需求方案讨论阶段

在需求方案讨论阶段，未充分了解各系统间调用流程，导致在方案制定时，一方面导致被其他部门人员引导进行，产生不利于原产品定位的问题；另一方面在方案最终敲定上摇摆不定，期间多次反复讨论，差点上升至领导决策层面，（最终互相让步了）导致整体项目历时延长。

个人经验：新手们在进行方案探讨前一定记得把需求涉及的系统能力、系统调用逻辑调研了解清楚，这样对后续方案的讨论和敲定都会起到积极有效的作用；如果是严格意义上的需求方尽可能把业务流程梳理清楚，如果是产品经理的话需要把产品逻辑梳理清楚。

2. 方案评审阶段

在初步方案评审阶段，出现相关方未到位的情况，出现这个事情的原因是个人不清楚本次系统改造还涉及这样一个系统，因而很顺利地导致第一次需求评审流产。

个人经验：这个说起来真的很痛心，但是新人们一定要注意避免，不要因为不清楚就想当然的认为拉齐了相关方，可私下向其他系统同事请教了解一下，真的很有必要，尤其是在新接手某个涵盖不太了解的系统任务。

需求评审拉起相关方！需求评审拉起相关方！！需求评审拉起相关方！！！重要的事情说三遍。

3. 需求提交阶段

在需求沟通阶段未邮件留痕，方案评审完成后未尽快提交正式需求，导致在中间出现变动时无法有效找到证据进行项目推动；因此导致整体项目历时有所延长，约3-4个工作日。

个人经验：在以下几个阶段，建议通过邮件的方式进行留痕：

• 方案讨论阶段达成的方案共识，以会议纪要形式同步各方，一方面证据留痕，另一方面周知各方，避免遗忘或信息不同步。
• 需求提交留痕，可以通过工单系统或者邮件留痕，有其一即可。

4. 需求实现阶段

1）特殊场景未穷尽——设计方案时只考虑主流形式

针对80%用户会采用的形式进行的方案规划设计，但针对特殊的20%的场景未进行方案设计，如没有用户ID的场景、没有手机号码的用户、接口超时问题、缓存时长未定义等；在前期对业务未充分了解，对场景未充分穷举的情况下，赶时间出方案特别容易出现该问题；虽不是大问题，可以通过后期补救的方式，但总是这样会影响开发等对产品的评价。

2）动态配置内容做在系统流程上（大忌）

针对某一渠道，用户进线不携带ID，初次拉着相关产品和开发讨论时，竟决定做在系统流程上；后期得亏缓过神来，马上拉着开发探讨，后续将该场景做在了动态策略上，方便后续灵活变动。

在此自我反思，后期需要变动的内容尽可能不要做在系统流程上，让做动态的系统专门做动态；如果让主流程去判断个性化且后期大概率变动的内容，在后期变动时开发难度大，且容易引起不稳定的情况。

3）你认为不是他认为的

此项目中，在跟开发沟通需求时，通过文字+口头表述的方式传达需求，开发当场表示明白了，没问题。

到了实现阶段各种需求对不齐，很多情况下出现这种问题，也就是“产品想的是100%，产品说出来的可能是80%，开发理解完大概率只剩60%了”；这个一方面需要产品与开发在沟通需求时反复确认，尽可能让开发自己表述一遍，然后指明理解不一致的地方；另一方面产品需要在开发过程中随时沟通查验，尽可能减少沟通与理解导致的信息缺失问题，避免产生大的风险。

5. 指标定义阶段

前期认为指标一可作为评估指标，也是一开始的提升目标，但指标一为宏观指标，同时还受其他因素影响；指标一虽能部分程度表示策略结果，但不能清晰表示具体上线内容的效果，故在功能实现后又重新定义了指标二，惭愧惭愧。

指标应该是一开始就定义好的东西，不管产品还是开发，或者其他系统的同事，其实大家都比较关心这次开发实现了什么，提升了什么指标，自己述职写周报时也好写；指标定义应该是前提，指标都没定义好，特别容易出现忘记一开始为什么做这个需求的情况，以此为戒。

当然也不全是问题，LZ也在其中也有处理好的方面。

1）及时发现问题重新定义方案

面对某一渠道不能同步改造，无法传递ID时，一开始拉着一众产品和开发竟然要把策略做在系统流程上；还好后面悬崖勒马，及时发现问题，把动态化的东西做成可调配的策略，最终避免了悲剧的发生，也获得了两个对接系统的相关开发人员认可。

2）项目管理之延期风险

H5前端因迟迟未进行开发排期，短期内未进行有效推动。通过以下方法有效降低风险：

• 协同各系统进行信息同步并明确前端不能同步上线的可行性及风险。
• 讨论前端二次上线，第一次保证流程改造同步上线，保证系统能力；第二次上线实现具体功能细节等上线，通过此避免了大面积风险的产生。

3）项目管理之担当

面对某系统（非个人负责系统）数据表获取困难时，及时出面协调解决；项目经理在此应该有所担当，帮助处理部分协调问题。

三、后续进展说明

有了本文所述项目的进行，LZ一方面理清了系统流程；也开启了和其他系统的对接模式，缓和了关系（原各部门间关系比较紧张）；同时也学习到了各种在产品设计、项目管理中出现的问题和解决的方法。

LZ在2.0版本的设计与方案讨论中做的比1.0版本游刃有余地多。

四、总结分析

1）产品经理在做产品规划时，首先是调研清楚项目的业务价值以及其具体的衡量指标；第二步要学着把自己的故事讲好，让开发、相关系统认为接下来要做的是一件有价值的事情（但是杜绝忽悠，忽悠得了一时，忽悠不了二时）；第三步跟进开发进度，随时解决可能出现的延期风险。

2）产品经理需要补充一下此类能力：项目管理能力、沟通协作能力、对细节的极致追求。

初次记录总结，请多指教。