项目复盘：产品小白及其肩负项目管理的艰难之路

张伯伦 2023-07-27 07:55:32

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

公司的一套较为完善的人工智能产品，个人在做相关产品规划工作，通过在整个系统流程上引入某系统产品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%了”；这个一方面需要产品与开发在沟通需求时反复确认，尽可能让开发自己表述一遍，然后指明理解不一致的地方；另一方面产品需要在开发过程中随时沟通查验，尽可能减少沟通与理解导致的信息缺失问题，避免产生大的风险。