标签： 复盘 总结
好久没来简书写东西了，一是感觉自己状态出了问题，在调整；二是确实忙了一些，随笔写了一些，不太想发，所以摘了一篇复盘的方法论写写，希望能给大家带来一些启发，也给自己之后做事做一个参照。
这是第一次带一个完整的项目，不知道自己这么做对不对，大家可以指点、批评，我再优化改进。
全文以5大产品层次作为基础，时间为轴，对在各个阶段做什么事，如何将需求落地，做了一个简短的说明，希望对你有用~
1.讨论战略层
这个层面是要告诉我们，做什么，为谁而做。
- 首先拿到一个方向，我们要进行调研+收集需求，确定自己大致的一个路径。
- 其次，进行需求分析，结合产品定位（产品定义+用户需求）筛选需求，这个时候可能几个主要负责人会在一起进行第一次会议。
（PS：因为整个项目的提出到现在的实现我都全程参与，所以几次方向的改变也都经历，真的有一种豁然开朗的感觉，从一开始的不解，到无奈，再到趋势认同，确实说也明了，一个想法需要经过不断的思考、迭代、讨论等等，才能真正的转化成一个产品，适用的产品。方向不可怕，可怕的是不思考。）
2.落实范围层
这个层面是要告诉我们，需要做什么。
- 结合项目资源、KPI、公司战略，将用户需求转化为产品需求。产品需求包括 战略方向+产品所需功能。
- 确定要完成1，需要哪些功能，并确定优先级。该阶段产出feature lists。
- 第一次评审会议召开。之后进行修改改进，进入下一个阶段。
（PS：几次熬夜想需求，想功能，产品经理真的是一个烧脑的职业，重要的不是会执行、会画图，重要的是你的脑袋，是不是会思考，是不是思考全面，是不是逻辑清晰。）
3.转化结构层
这个层面是告诉我们，怎么做，即在该层面确定拥有哪些模块，如何跳转，每个模块的信息包含哪些字段等。
- 优先级、功能都确定了，开始要动手确定产品结构、信息结构、产品流程图了。
- 首先确定模块层次，将已准备好的功能填入；
- 确定产品结构，产出产品结构图，例如微信有微信、通讯录、发信、我，每一个模块都有哪些功能点。
- 确定产品信息结构，即脱离产品模块、页面和结构，将数据抽象出来，产出产品信息结构图，例如用户信息包含哪些字段，产品列表包含哪些字段等；
- 确定个模块页面的跳转，产出流程图。
- 开始第二次评审会议，增加、删减、修改功能模块。厘清逻辑。
（PS：我就在这个地方吃了大错误，要做管理后台，我直接跳过这个考量，着手原型，边话边想，效率极低，最终导致思路混乱、逻辑不清晰的局面；同时，也会让评审无法进行，因为他人根本不能理解逻辑，当被老大询问要产品结构、信息脑图的时候，整个人就懵逼了，因为只是在草稿上随意画了下。所以一定要厘清自己想做的，评审时才有依据，才能更好修改、改进，才能思路清晰，程序员哥哥们才不会鄙视。）
4.形成框架层
这个层面告诉我们，做成什么样子？即在该层面确定每个模块，每个功能该如何摆放，哪个内容需要突出等。
- 根据产品结构图、产品信息结构图、流程图确定基本产品框架。
- 细化框架，增添血肉。
- 形成原型图。
- 开始第三次评审会议，讨论、提议、修改不合理的地方，进行完善，之后产品内部进行小规模讨论，确定原型，形成PRD。
（PS：PRD一定要写好，一定要写好，一定要写好；开会一定要记录，一定要记录，一定要记录；标注清晰、流程清楚、容器等等，你都得做好，要不然，呵呵了。）
5.完美表现层
这个层面告诉我们，做成了什么样子。
- 同时进行，让UI产出设计稿，让后端开始开发。
- 设计稿尽快出，然后全体查看，后台继续开发，前端开始跟进。
- 给开发哥哥们买东西吃。
- 跟进开发人员进度，及时确定完成状况，了解项目进度。
- 等待完成，测试、上线、优化、迭代。
（PS：这个阶段，正式成为产品狗的阶段。记住，要随和、随和、随和，不要生气！！好好“跪着”沟通，好好求求设计、好好承担责任。多给开发们买点吃的！正经的说，提升自己的实力，让他人信任你，信服你，才是沟通没有障碍的真正途径。）
6.补充说明
以上看似C端的开发流程，其实管理后台一样适用。管理后台的所有流程步骤都应该按照这个流程走通，同时需要注意的是，应当和C端相呼应，在做C的时候，就应该想到，C端上这些展现的字段、内容从哪来？后台如何设置？后台的操作流程如何？etc。
7.想法
项目进行了几个月了，也跟了几个月，中间出现了几次方向的变化，磕磕盼盼，也算快要有产出了，挺兴奋，所以想要复盘一下这段时间对于项目、产品的一些事，做一些总结。具体的就不说了，都在上面的PS中，想想自己的方法论，查缺补漏，不足加以改进。
