今天完成的事情：（一定要写非常细致的内容，比如说学会了盒子模型，了解了Margin）

项目管理的部分

1.组织立项会议时，邀请相关利益方加入，特别是技术团队的老大和产品团队的老大，以及双方的老大大，让其明确授权，包括调配资源、管理团队、进度汇报收集的权利。如果老大无暇参加此会议，则需要书面声明或者邮件周知相关人员，由谁负责或担任此类工作。不要看似简单，其实在很多流程不够规范的公司内，职权是界定不清的，导致相关人员不同程度的甩锅与拖延无责的心态继续摸鱼，另外，群聊记录的口头声明是不可靠的。

2.项目汇报的管控，时间为一周一次或一周两次为宜，记录的内容需包含现阶段人员的一周按日程格子记录的开发进度，以及状态是否正常、延期、完成率的百分比。如有备注要声明人员的具体情况，比如请假、临时任务、其他事项等等，补救措施是调休加班、往后期延或是提前完成不需调补等说明，确保跟上开发计划。进度每周抄送一次项目组成员，利用大众的监督施加适当的压力与责任，而不是产品经理一人对一个技术团队。

3.明确制度，赏罚分明，一旦计划确认完毕，执行者在执行过程中除特殊情况，否则不可随意修改，有明确的赏罚制度，也有一定的奖励制度，但是奖励需要公司层面才能决策的，所以不一定都有，所以部门内看能否通过其他途径给项目成员奖励。奖金的激励一定程度上会促进成员的积极性，赏罚能够规制约束项目成员，否则立不立项、能不能如期完成对成员来说无关痛痒，急的说不定就是产品经理自己。

4.营造参与感与成就感，不管是谁，当做出了一款产品并得到他人的夸赞时，内心的成就感是不言而喻的，是对自己付出的犒劳和自我追求的认同感。所以项目过程中，要确保项目成员能够从中获得自己想要的一些东西，经验也好、金钱也好，赞许或评选鼓励也好，都是可以促进成员的积极性。很不好的是如果都是产品经理一个人在孤军作战，那么项目是真的很难推动，把相关的权益和责任让不同的人员负责，才是对资源的最好分配。

5.项目计划分配，不同的项目计划模板各有不同，细到什么程度因不同公司决定，但是工作任务一定要拆解开来，WBS（工作分解结构）是最常用的一种方式，大化小，小成无。将整体项目划分为不同的工作包，由长期解构为短期，这倒是挺贴合产品经理日常思考模式的，整体——拆解——分析——执行——完成，WBS能直观快速的表现出对每个阶段的任务点及目标，协助清晰的按照计划进行，也便于快速查找问题。

6.风险控制，风险一般包括定性风险和定量风险，此部分比较偏知识论，经验有限的人员常常对风险不能做好全面的预判，高级产品也是因为在项目中不断的总结，避开了遇到过的坑坑洼洼。所以，在项目结束做好总结中或吸取以往项目的经验的维度，是风险控制的初级识别的一个重要方式。其次，可通过头脑风暴，组织项目成员在负责的模块所会碰到的潜在问题，以及产品经理和其他部门对接时的可能性事件，如流程变更、人员离职、需求变更等等，列出表格，预留解决的时间。定量的话是指风险不确定但可被量化，书本的定义是对每一风险发生的概率及其项目目标产生的影响，以及项目整体风险的范围进行数值分析。这类分析通过发生概率的大小而有针对性的采取不同的措施进行规避。

明天计划的事情：（一定要写非常细致的内容）
遇到的问题：（遇到什么困难，怎么解决的）
收获：（通过今天的学习，学到了什么知识）