每天都面临着不同的工作任务，都会收到很多邮件，有新的需求，有问题的反馈，有紧急问题的报障等……
对于这些我们都习以为常，而且对于有些邮件也已经变的麻木，身在职场，终究还是要一件件的进行处理，反观一些特别牛X的同学每天的工作却游刃有余，这是值得我们学习和反思的。
下面主要谈谈个人对日报、周报、月报、年报（晋升总结）的一点想法。
- 日报：即个人每天的工作计划与任务安排，有些管理者也会要求团队成员写日报来统计工作量。
- 日报目的：记录个人当天的工作内容，进度及相关的问题，用于个人的回顾与总结。
一、日报如何写？
1.无论是个人行为还是团队要求，日报中的工作内容都应该按四象限来进行分类。
这个在时间管理方面也有过很多的介绍，但是实际工作中我们更多处理的是紧急不重要与重要紧急的，从而使得重要不紧急的演变为重要紧急了。
原因大部分是由于有的任务是老板安排的，同事直接电话邮件找你的，顺手做的事。
2.每天早上进行计划，把当天需要做的事情用便签纸或记录在日历中，有临时的任务直接按重要紧急程度进行安排。
我在一次与产品经理需求评审时看到他在讨论过程中将一些工作的安排在讨论间隙间记录在日历表中，而且还设置了任务提醒，特别佩服他的这种工作方式。此外利用Excel或印像笔记等都是不错的选择，只要用着顺手都可以
3.每天下班前进行回顾，将工作进度、问题、改进等汇总。这些最好能保持相同的格式，方便进行汇总回顾，如果团队要求那么可以利用wiki等内部工具，按统一格式填写。
二、我的观点
1.日报是个人日常工作的一份计划，每天的工作日志，它不应该作为团队管理者统计工作量和衡量能力与工作饱和度的工作。
2.有的公司要求研发、产品等同学每天登录工时，但纵观一下这些不可量化的记录只是增加了个人的工作量，浪费了时间而已，会有多少参考价值呢？每个人录入的内容经得起推敲吗？
3.有的团队管理者要求每个人每天都写日报，而且没有格式，最可笑的是通过微信群。这种的要求在我看来就是闲的蛋疼，无非是为了监督团队成员工作而已。根本发现不了问题，也没有留存何来的回顾呢？
三、建 议
1.每个人都应该养成写日报的习惯，可以根据个人的喜好来记录，便于个人的回顾与总结。
2.要保证相同的格式，每天都要遵循早上计划，晚上回顾的过程，每天在此花费的时间应该是早晚10分钟即可。
3.作为管理者应该思考是如何帮助大家发现问题、解决问题，而不要想着通过日报监视下属，大忌。
周报：每周工作的总结汇总，要体现出本周的成果产出、本周的问题以及解决问题的方法。
周报是来源于日报的汇总及总结，在带团队的时候曾经要求团队成员每周都要写周报，但目的仍然不是为了监督大家的工作，而且为了从中了解每个人在忙什么？每个组在做什么？
四、周报如何写？
1. 根据日志工作日志进行信息的提炼，进行一次小的总结。
2. 把重要的、重大的项目任务罗列出来，主要列出来问题和解决问题的方法。
3. 要经得住别人的询问，要有改进的建议等，不能将日报按天堆列。
五、目的？
1. 想通过周报这些来提炼出可以创新的项目、发现团队有潜力的人员。
2. 发现当前系统中潜在的问题，总结教训，推广好的经验。
每个人都有自己的想法，一个能正确对待这项任务的人，而且能够做的好的，我相信未来他(她)也会有好的发展。
我的观点：周报应该要写，在每周例会上可以以组为单位进行讨论，共同改善，提高。
月报：有了周报个人就不需要月报了，但是作为团队管理者应该有月报。
月报应该以PPT或标准文档的方式进行，是一个团队的阶段性总结。
要列出重点项目、本月的问题、下个月的团队规划；团队贡献等，如果有资金应该设置一些小的奖励。
我个人觉得好的团队需要经常性的沟通，公司也应该提供一些必要的场所，譬如大点的会议室，项目奖金等。
公司管理团队有季度总结会、团建会等，对于基层的团队更应该有这些的机会，战略和执行都不可缺少。
曾尝试坚持过几次这些的月度会议，但随着人员的流失与个人的变动，现在这些实践也付之东流，但经过很长一段时间的思考，感觉这样的月报还是有必要的。
通过月报可以安排有潜力的人进行主持，给以锻炼的机会，发现人才。
通过月报的总结，可以让团队知道前一阶段的工作成果，了解未来的工作重心，知道现在的问题。
……
年报：年度工作总结或晋升、述职报告
年年岁岁花相似、岁岁年年事不同；每个人每当年底都会感慨，这一年又白过了，年初的誓言也随着年终而未能实现。
但对于职场上的你我他，都会涉及晋升、述职的过程；不想通过升职而加薪的人是极少的；随着年来年龄的增长越来越觉得职级才是高薪的基础，没有职级你想达到高薪难，因为你不在那个职级中，你都不清楚那个层级的人有多少隐性福利。
六、如何写好年报？
1. 要做一份漂亮的PPT，这个要求版本、字体、色彩搭配上要简洁、大方。
2. 重要的工作成绩回顾时要从树干到树枝，再到树叶的原则，即先主后次，循序渐进。
3. 在描述重大项目时要遵循STAR原则。
即：场景Situation、任务Task、行动Action、结果Result。
- Situation:当时的项目背景是什么？
- Task:你要达成的任务有哪些？
- Action:你的行动是什么？有什么样的里程碑等
- Result:最终结果是什么？
4. 如果是晋升等，会有提问，所以列出的内容要能够经受住提问。
5. 要有数字，以图表方式展示，不要全文字描述，看着就一片，看的都累。
6. 适当的动画，可能会增加你的专业度。
7. 实事求是，不虚夸，有理有据，要自曝不足，有缺点不代表不完美，但是要有改进的思考。
参加过多次不同公司的述职、部门、公司总结会，见识了不同人的汇报，也参加过很多公共会议，听过专家的演讲，使我认识到，牛逼的人做什么都很专业的。
通过一个汇报的PPT，一个演讲，你可以学习了解到这个人准备的是否充分，思路是否清晰，平时是不是吹牛X类型的人。
KANO 模型：最后再介绍一个在日常工作中可以用到的模型。
个人觉得在日常接到需求、进行产品设计、详细设计时可以考虑前三个即基本、期望和兴奋。
- 基本（必备）型需求
——Must-beQuality/ Basic Quality
- 期望（意愿）型需求
——One-dimensional Quality/ PerformanceQuality
- 兴奋（魅力）型需求
—Attractive Quality/ Excitement Quality
- 无差异型需求——Indifferent Quality/NeutralQuality
- 反向（逆向）型需求——Reverse Quality，亦可以将 ‘Quality’ 翻译成“质量”或“品质”。
一般的需求我们如果能够实现前两个，就挺不错的了，但是基本需求是必须要达到的，期望性可以通过快速迭代的方式来实现，对于兴奋型需求在项目管理中则属于“渡金”，可以最后去补充。
KANO模型一般是用于运营和市场运营的，但我们在技术产品中也可以采用，研究了解我们的用户也是一种运营和提高。
总结一下
最近只能偶尔抽时间来写点东西，所以写的内容可能是想到哪就写到哪，有看到的，有听到的也有自己经历过的，年底即将来到，2020年从准备一份年终总结开始：），感谢您的阅读！
