统一开放平台是个啥？
搭建公司专属的统一开放平台，提供对应平台服务中各类API接口，供给第三方厂商或用户去做接入，微信支付、支付宝支持，高的地图等，大部分产品都是调用他们开放的接口，此种情况下第三方不需要再进行页面和后台开发，只需要根据平台方要求传入相应的参数即可。
项目名称：统一开放平台
项目复盘周期：2022-10-01 —— 至今
项目目标：2022-09-30 ，统一开放平台V1.0.0版本上线
目标内容：根据需求完成对应功能设计，在对应里程碑节点下完成最小可行性产品，并进行后期产品迭代规划，具体内容为：API管理、授权管理、数据展台、文档管理、服务管理、数据开放接口、能力开放接口、门户相关功能设计及研发，组件SDK模块移动到后期版本迭代中进行
项目现状：完成招标文件上对应所需的必要性功能，并配合研发进入到产品开发测试阶段
一、项目目标复盘：1、项目进度复盘
是否按原计划时间交付？
目标：按照招标文件上的需求进行产品规划及研发
现状：已完成招标上关键路径对应的功能设计，但产品细节在一定程度上需要进行优化
原因：产品在设计过程中由于时间较为紧张，部分功能在交互或用户体验上有待优化。
二、需求阶段复盘：1、现状：招标文件上的需求并不是较为详细的，导致很多问题更多的方向判断是产品经理的经验
2、经验：后期产品在拿到不清楚且之前未了解过的需求时，需要先去了解对应竞品，具体看看竞品的功能逻辑，因为大部分是类似的，在一定程度上可以帮助经验少的产品经理去快速理解需求功能点；如果是需求不清楚但有经验，则可以按照自己的经验去思考整个产品结构，同时也可以参考一下竞品，在竞品的学习过程中，大家可以做到取其精华，去其糟泊，当然更多的时候大家是站在业务的层面去做产品设计。
三、设计阶段复盘：1、UI设计复盘：在做产品设计以及UI设计时，需要考虑用户主要是谁？面向的业务是什么，因为不同的业务形式有不同的潜在规则，比如政府项目的话，更多的产品UI风格多政务化，如果是电商的话，则更多是具有商业化，不用行业在设计上有不同的风格，即便是同一个行业面对不同的具体业务项，也是有不一样的展示形式，如武警和消防，具体的主题色都会呈现不一样的，作为一个产品，可以考虑一下产品整体的业务方向，然后根据方向去实际去做整体产品的规划。
2、针对UI风格上，UI设计师虽然是主导，但是如果碰到那种没有啥经验的UI设计师，那作为产品经理是需要提前和UI设计说一下具体的业务方向，如果可以的话，尽可能和设计师沟通详细一些，避免后期一直改整体的风格设计，说实话，具体要和设计师详细到那种程度，还真不好说，哈哈哈哈哈哈，只能说最好是多次确认，保证产品一致。
四、开发阶段复盘：当前是作为产品经理角色在整个产品开发过程中的复盘：
1、在需求评审前需要做的准备工作：作为产品经理，在需求评审前，我个人建议需要做几件事，第一作为产品经理，在开需求评审前，你需要梳理一下本次需求评审的功能内容的逻辑框架图；第二在需求评审前，需要将对应的原型图、逻辑图等资料提前一天或者半天发到对应的研发人员手中；第三，理解什么是需求评审，很多新人觉得需求评审就是产品和研发撕逼的环节，其实并不是这样的，好的需求评审会是做一个产品的需求及功能实现方案的确认，并不是让产品和研发进行对撕，我目前会在需求前去和对应技术总监去沟通一下（这点很重要！！！！），目前整体产品实现上可能存在的技术难点，如果存在一定技术壁垒，那可以在产品上进行调优，事下沟通，可以一定程度上节约开会时间且能和技术较高领导人达成一致，避免会上其他开发人员忽悠说开发实现不了，有技术总监发话，一切就会好办很多，这个方法大家可以试试；第四，需求评审前需要预约对应的时间（具体到时分）、参与人员、地点、明确会议主题等会议事项需要提前通知到具体人员
2、需求评审过程中，首先可以整体向大家介绍一下整个产品功能的背景、让大家事先了解这个功能是干啥的，不要一上来就直接进入到功能研发讲解中，需要把开发人员带入到你的讲解环境中，这样他们才能比较快的去接受你的看法，其次，说完功能背景、业务背景后，作为产品还需要和大家在整体逻辑上保持一致，所以我建议是大家在需求评审时，需要先说一下整体的逻辑是怎样的，最后在根据具体的功能进行讲解，在具体的功能讲解中，如果你觉得有研发会有忽视或者容易模糊的细节，也可以随便提一嘴。
3、在需求评审时，如果遇到和研发意见不合的情况，可以及时在原型图上做备注，我个人不建议在会议上和研发去争论，说实话毫无意义，还浪费时间，如果是那种和研发没有长时间（极限是十分钟）没有达成一致的，作为产品经理，需求评审会你自己主导的，所以你可以直接说，这个问题你目前的一些看法，如果和研发存在较大差异，可以会议后私下再找对应功能开发的人沟通一下，避免浪费其他人的时间，后期讨论的结果也要及时通知到其他人，让大家整体的逻辑达成一致，避免大家前后信息存在差别（这个很重要！！！！）
4、最后，需求评审会议结束后，如果原型有需要调整的，我个人建议是及时调整，避免遗忘细节，调整后及时将最新的原型通知到具体相关人员。
五、一些好用的方法这是我个人目前较为喜欢的一些做事方法，可以和大家一起交流一下：
需求分析阶段
1、我建议大家拿到需求时，不要一开始就去做具体的功能设计，而是需要先把产品的整体框架用思维导图整理出来，大家可以按照模块出发，思维发散的去想如果你是用户，你可能会用到哪些功能模块
2、整理出你觉得必要的功能模块后，你可以用鱼骨图，对功能模块进行拆解，拆解出具体这个功能需要完成的事项
3、当确认完成事项后，咋们就可以做一件很重要的事情，采用用例图，按照角色去做划分，将不同角色下的操作进行分解，这个很重要，这样做的话，你可以很清楚的知道具体角色功能权限、数据权限，后期在绘制角色管理、用户管理、权限管理的时候，你将会十分的便捷
4、通过以上这几个图的绘制，我相信你可能已经对自己的产品有很多较为详细的认知，接下来的时间，就是按照功能去做原型绘制啦
最后：可参考我针对复盘查询的相关资料
1、如何设计及管理开放平台？ | 人人都是产品经理 (woshipm.com)
2、产品项目复盘【方法论+案例】 - 简书 (jianshu.com)
3、了解什么是用例图：浅谈UML中常用的几种图——用例图 - Vathe - 博客园 (cnblogs.com)
你是否还在寻找稳定的海外服务器提供商？创新互联www.cdcxhl.cn海外机房具备T级流量清洗系统配攻击溯源，准确流量调度确保服务器高可用性，企业级服务器适合批量采购，新人活动首月15元起，快前往官网查看详情吧