一、 项目过程：
1. 需求调研
需求来源：行业需求；企业需求；市场需求；场景需求
目前项目的需求来源于科研部，后续跟着市场节奏不断增加新的需求
总结经验：
方案探讨前一定记得把需求涉及的系统能力、系统调用逻辑调研了解清楚，这样对后续方案的讨论和敲定都会起到积极有效的作用；
● 严格意义上的需求方尽可能把业务流程梳理清楚，产品端逻辑梳理清楚；
● 尽量减少减少因为需求不明确，导致返工情况；
● 需求提前两个周提出，方便后续产品规划，和研发开发；
2. 方案开发
a. 方案设计
经过前期的调研和需求分析，方案设计阶段要求我们聚焦产品主线和价值内核，寻找能解决问题快速看到效果的最小可行化产品（MVP），即聚焦核心用户的最小最基本的功能组合。
总结经验：
● 优先关注内在的而非外在的，关注实际的而非未知的；MVP阶段优先解决的逻辑性问题，后续迭代关注细节的性能和体验；
● 在初步方案评审阶段，拉齐相关方（需求方，发起人，参与者），多次有效沟通交流，逐渐明细方案设计的具体方案；
b. 需求评审
形成初步方案后，需要拉着开发、设计、运营等相关人员以及项目负责人对方案进行评估。从初步方案到成熟方案经历好几次打磨，所以参与评估时一定要保持良好心态，并在项目周期中预留出足够的方案调整时间。
评估可分为产品侧和技术侧两方面，主要评估当前解决方案能否满足需求，能否创造价值，操作逻辑以及方案落地的技术可行性。
总结经验：
● 需求评审，产品事先了解相关技术，评估会之前与技术同学沟通，了解技术背景进行简单的技术评估；
● 借助图形和少量文字聚焦逻辑主线，不要过多关注细枝末节或者价值输出少的功能点。要讲清楚需求背景和方案价值，与与会人员建立起共识；
● 在项目周期中预留出足够的方案调整时间，需求评审早于开发版本一个迭代周期，出现问题可及时调整，不影响下期开发进度；
● 产品做好排期之后，开发同学根据实际情况，做个预估，在可控的时间范围内，做好自己的排期，（后续出现问题及时沟通交流）；
3. 项目管理
a. 任务管理
1) 需求排期
● 排期前首先要评估需求优先级，在评估会之前最好先自行评估一下，对需求进行排序。然后再拉着团队成员在此基础上调整，这样能够有效提升评估排期的效率；
● 善于利用排期表进行任务分配，需要确认每个需求任务的负责人，保证其真的清楚任务要求和交付节点，每个人的表达和理解能力是不同的，其实很多任务延期都是因为前期没沟通清楚导致的；
2) 文件管理
● 需要熟悉项目开发中产生的各类文件，确定统一的传输和保存路径。
● 文件名可以加上创建时间方便后续查找，即使是更改过的文件，对于较大改动也应当保存更改记录，这样有助于我们更清晰地了解项目演进过程。
3) 进度跟踪
● 每日例会或是周会，开发过程中可以根据项目情况多组织小会及时同步进度；
● 对于多条并行的任务要合理安排时间及时推进，切不可只顾一头，真实的实践场景很复杂，提升多任务并行解决的能力很重要；
● 关注交付节点和风险点，当感知到问题在节点不能解决时可以积极需求其他开发人员帮助，遇到问题及时沟通交流，不要陷入苦思冥想而超过交付节点。
4) 解决突发问题
● 面对突发的bug，快速试错和复现判断问题成因，提高解决问题的效率；
● 举棋不定的时候不要搁置争议和问题，一定要搞清楚原因，再三确认能否解决，解决不了的话也把原因记录清楚再找其他解决方案或者咨询他人
b. 向上管理
作为项目负责人，除了具体的方案开发工作外，沟通是非常重要的一部分，主要包含向上管理和团队沟通。
向上管理指与上级相关的沟通管理工作，向上管理是否有效良好甚至决定着项目的走向。
总结经验：
1) 方案讲解
● 方案讲解时主次分明，指出主要问题阐释和相应解决方案以及该方案的优势和价值；
● 注重讲解的脉络和逻辑；
● 在方案首页和末页整理出一个议程或信息总览，让与会人员对讨论的议题更有概念，方便围绕议题进行讨论并敲定方案。
2) 应对质疑
● 积极反馈项目进展和工作内容；
● 对于上级的合理质疑，不要急于给出结论，要多思考实践从多个角度去论证，得出结果后及时反馈给上级
3) 进程汇报
● 除常规的项目汇报外，对于风险点要及时尽早提出，千万不能抱有侥幸心理，要学会借助上级的力量协调资源处理问题规避延期风险；
● 对于市场的发现的新动态也可以多整理多汇报，这样之后形成需求落地就会容易很多。
c. 团队沟通
总结经验：
- 沟通方法
● 说对方能听得懂的话，除了上级产品经理面对的角色主要有开发、测试、设计同学，还有可能接触市场、销售、美术等其他部门同学，不同角色往往有着自己的话语体系，产品经理需要对此有所了解并有针对性地调整沟通方式；
● 沟通方式要灵活，对于难以解释的事情或者紧急的事情，要积极地去进行面对面沟通；
● 带着目的去沟通，沟通时要有明确目的不可含糊不清，注重提高沟通效。 - 任务落实
● 队内沟通中非常重要的一部分是任务分配和执行，任务实施前要把任务细则、目标和时间节点都明确出来确保成员意见一致，并让每个人都清楚负责的内容，有可能出现的风险和预案最好提前说明，让大家都做好应对准备；
● 任务执行的过程中，非必要时产品经理不能擅自修改需求，不然开发会崩溃，测试同学会流泪，不利于团结；
● 跟进任务时要有节奏，可以为执行阶段设几个跟进节点，了解任务进展及时规避风险。
d. 测试实践 - 产品自查
● 在方案设计阶段，自己准备一个常用自查表进行产品自查，比如页面、控件、交互是否完整流畅，文案和提示是否适当完备，是否考虑全异常情况等等。
● 前期把事情都考虑清楚能够极大减轻之后的开发和测试压力；随着开发深入和产品成熟，自查表需要及时更新，可以去掉项目不涉及的检查条目，让自查表和项目更加匹配，为后期迭代提供依据（目前可能存在更新不及时情况，这个之后会注意）。 - 测试准备（目前缺失部分）
产品测试是产品生命周期中及其重要的环节，一款产品没有经过测试就推向市场的话。尤其是B端硬件产品，整个系统较为复杂，存在系统性风险的程度非常高。推出的产品在用户使用过程，出现重大异常，会损失产品口碑，甚至结束合作关系；
● 当项目开发进入尾声，就可以开始准备测试内容了，要提前和测试同学沟通好测试需求和测试样例，并让测试同学尽可能熟悉项目内容；
● 产品测试过程涵盖产品生命周期几乎所有环节，产品测试保证了产品制造输出产品与最早定义的产品一致，同时能够发现评估产品存在的风险，为打造稳定、可靠、可制造的产品提供闭环检测手段。
3) 测试反馈
找一个固定位置或者软件同步测试结果，保证项目相关人员都可以看到，并做好记录保存，方便之后查看校验；对于测试结果，需先对测试结果分类处理，再对要修改的问题进行优先级排序最后与开发沟通排期，解决相关问题
4) 项目验收，运营上线
二、 总结分析
- 问题描述：以叙述的方式描述项目过程中，遇到的问题或收获，可以从项目各阶段里程碑划分，例如，上线部署时，测试验证时间比较长而且覆盖面不够全。
- 预期结果：基于问题或收获，抛开实际结果，理想化的分析目标期望达到的最完美结果。
- 实际结果：实事求是，记录基于问题描述，实际达到的结果。
- 原因分析：通过对比实际结果和预期结果的不足或超额完成点，分析导致两者差距的原因。
- 经验总结：从原因出发，剔除项目因素，分析优点，不足之处，总结可适用于后续项目的经验规律。