又到了半年一度的述职季，你是不是也在为不知道如何写述职报告而焦虑，是不是还在问“度娘”要答案，是不是感觉明明干了很多活，但就是表达不出来，写一份文档出来，感觉得少了1111根头发，那今天，遇见我，你真幸运，来给大家支几招~
如果观点冲突，那一定是你对，轻喷~
关于自我介绍
述职时候的自我介绍，主要是跟HR或跟你不怎么熟悉的Leader介绍自己，所以这时候要把自己的岗位职责业务范围表达清楚，最好能让他们记住你，所以这1分钟的自我介绍很重要，得让评委知道你是谁，在哪里“拧螺丝”~
所以我的切入点一般是：来自哪个团队，职位是什么，主要用的是什么技术，主要负责的业务有哪些，个人有什么优点，想往什么样的方向发展，具体举例就是：我叫某某某，来自某某业务团队，主要用的技术是xx、xx、xx，主要负责的业务有xxx、xxx、xxx（最好是有影响力的业务），做过的XX业务超额完成目标50%，个人的定位是做一个开发速度最快且最了解业务的前端/后端开发...
此模块除了把自己的工作内容讲清楚，很加分的一点就是尽可能的给自己贴一个醒目的标签，让评委知道你是有目标的，我这里也给大家推荐几个吧，比如：开发速度最快、具有产品思维的开发、技术深度最广、最了解业务、bug最少质量最高...，任何你益于常人的优点就可以当做标签，但也要符合现实数据情况，比如你线上发现问题十几个，非要说自己的定位是bug最少，是不是也不太合适。如果觉得这些可能官方，稍微滑稽一点也可以，比如：唯一的女性开发、一个灵活的胖子、时间管理大师、穿越过沙漠的男人、BUG克星....
关于过往工作经历
有的人关于这块一般不知道怎么说，作者之前也参加过别的同事的述职，他有那么几家工作单位，然后每一个都详细的说了一下，大概介绍了2-3分钟，但从作者个人视角来看，觉得这块不用过多的关注，述职又不是面试，这块无论说多说少都对述职没啥大的帮助，如果你说在别的公司很优秀，那又怎么会到现在的公司来，如果你吐槽前面的公司不好，好像又说明自己的格局低，所以如果你的公司述职有关于过往工作经历这一项，我建议你就一句话解决：这些就是我的工作经历,具体的就不多介绍了。这不就ok了（作者每年述职都是这一句，感觉挺好用的，也避免提问的尴尬😁)
关于个人成长
个人成长我觉得应该是所有模块里最好写的一个，首先分好大类，可以有：技术能力、写文档能力、处理问题能力、技术深度&广度能力、合作能力、动手能力、定位问题能力、把控业务能力，分享能力，组织能力...，然后再根据自己分好的大类具体描述，比如：技术能力提高了，具体就是学习到了xx、xx、xx、xx等技术，对xx、xxx技术的原理有所了解，技术能力罗列的就是你在这半年期间遇到的之前没有遇到的技术，达到的之前没有过的高度，业务能力的提高，可以说高效完成了xx、xx业务的迭代、提前上线、在评审时也发表了自己好的想法，这块就是介绍下自己为业务付了多少能量，处理问题能力提高，可以介绍下一眼定位并解决问题能力，响应速度等等等吧，只要是你半年内的进步都可以在这里体现出来，甚至还可以借力打力，比如沟通能力提高了，可以说某某某反馈跟我合作起来很顺畅，帮他们解决了很多问题，你想到的，听到的，甚至数据层面的，都能表示你成长了。除了要介绍自己的好的成长之外，可能也需要有1-2个小类说一下自己的不足，强调一下自己还有进步的空间，不足的话建议挑几个小问题略说一下就可以，比如有点粗心大意、技术深度还有提升空间、忘记写代码注释等等等的小问题吧
关于重点项目
重点项目应该是整个述职报告中最重要且最难写的部分，要想写好这个模块，你得从一堆的工作中挑选出来几个比较亮眼的项目，而且重点是挑选的项目中得有显著提升的数据指标，只有这些数据让评委认可了，他才有可能会拿着这些数据去给你谋福利，或者说你对某个绩效结果不认可，这些数据也是你去申诉的底气，所以说重点项目一定得好好写，这也是你辛辛苦苦工作半年，唯一的展示成果的机会，刚工作前2年，最烦的就是写这些，感觉无从下手，但随着工作年限的增加，工作经验的积累，还有从身边优秀同事中吸取到很多经验，也有了一点小小的心得，可以给大家详细介绍一下~
- 首先-日常工作中要做好记录
有的公司可能会有周报或者日报，有的公司也可能没有，不管是哪种，你自己都要有一个表格，表格里面要随手记录自己完成的工作，用到的技术，遇到的问题，工作数据结果以及项目背景等等数据，为什么要记录这些？因为述职都是半年或一年后，等你那时候再写的话，脑容量有限可能会忘记当时的工作情况，所以说一定要提前记录，述职的时候只需要修饰一下拿来用就好。为啥要记录项目背景？项目背景说白了就是项目成果，比如“有一个项目背景是由于某某项目总使用第三方工具每年会花费几百万，然后操作流程复杂且审核流程长，所以需要公司自己实现一套工具”，那当你写成果的时候是不是就可以写：完成了xx工具的开发，帮公司节省了几十万成本，同时解决了之前工具的流程复杂问题且此工具是咱们公司内部开发的，方便迭代。为什么要记录开发中遇到的问题？因为开发中遇到的问题就是收获，你在项目中解决的所有问题，对应的就是你的收获那一项，比如问题是“遇到了做的一些动画在android设备上会有点卡”，那你就可以写成，解决了android动画卡顿的问题，扩展了自己的知识面，从技术底层解决了卡顿的问题，提高了自己的技术深度~是不是感觉很多东西可以写，记录的内容话可以看如下图片
- 其次-一般都有哪些数据，找谁要数据
从前端视角看数据的话，我觉得有那么几个数据可以记录：性能数据、工具节省成本数据、质量数据、营收数据、BI埋点数据、成本数据、解决的问题数据...，像营收数据的话产品一般都会有，因为他们是有营收目标的，有没有达成目标或达成目标了百分之多少，可以找他们要一下，交互数据的可以找BI要一下，比如完成率，进入率，用户量比，线上质量的话可以找测试要一下，因为处理工单一般都是测试在跟，他们会有这方面的数据，最好是能有一些截图，比如性能数据的话，你可以有优化前或优化后的一个指标数据截图，营收的话可以截产品的prd文档里面的记录，因为截图更能证明数据来源是可靠的，但也要切记一点，数据不要弄虚作假，而且最好是可评估的，为什么要是可评估的？因为述职现场一般会有评委，他们可能会提问，如果你写了一个不可评估的指标，比如某某活动节省了50%的成本，如果现场被问你这个50%是怎么算的，总不能说是凭感觉拍的吧，是不是当场就会歇菜，而且如果你的一个数据指标有问题，那对你其他的数据指标也会有影响，当然了，更不能弄虚作假，因为你的直级leader一般都会在现场，或者你的述职报告会被交上去，又或者你可能和你的同事写了相同的工作内容，指标却完全不一样，所以不要妄想用假的数据指标蒙混过关，有些你觉得不好的数据可以不写，但不要作假~
关于去年工作的完成情况
如果你的述职报告中有这一项，那你今年的重心一定是要根据自己规划的目标去做安排，最好是当你述职的时候都能100%完成，90%的完成率也可以，但最好不要低于80%的，因为定了目标没有完成，就显得你这个人很没有诚信，可能也会让评委对你的能力重新评估，那这块一般要怎么避免呢~
- 关于规划的制定
工作规划中要规划一些可行的，有思路的，有想法的工作安排，不要写一些天马行空的规划，比如：弄懂V8编译原理、读完vue3源码框架、重构XX项目...，V8是一个团队很多技术大牛用多年时间才完成的设计，你半年就能弄懂，有点夸大其词了吧，还有vue3源码人家也是一个团队的很多技术大牛在经过无数次推翻迭代才有的成果，半年学完是不是也有点夸张，重构XX项目，XX项目都迭代5年了，里面有未知的零乱的需求背景，半年就能重构完成？，万一重构出了一堆问题呢，是不是没有考虑过后果，所以定目标一定要切合实际，给自己留点退路，绝对不能把自己整疯~ 我觉得规划最好能以最小单位进行拆分，既要表明要解决的问题，又要有指标可以衡量，比如重构XX项目，可以改成 1.梳理XX项目的历史需求，删除一些已下线的活动，减少项目构建体积。2. 先迁移1-2个活动到新项目中，历史原因，XX项目技术太旧，需要逐步迁移。比如读完vue3源码，可以改成弄懂vue3的响应式原理并实现一个小demo，computed计算属性在工作中用的比较多，想弄懂它背后的原理。制定这样的规划是不是更容易完成，拆分的越细，才能完成的越好，另外一点，也可以定一些可评估的规划，比如分享3次、将某个页面的性能提升10%、学习一个git的高级用法等等
- 目标是可以改的
定了工作目标，难道就不可以改了吗，比如你定了一个重构xx项目的目标，但是因为总是有业务需求或其他工作排进来，导致你没有时间完成这项工作，然后随着时间的推移你发现这个项目的业务几乎都下线了，业务方向也发生了改变，日后迭代率极低，这时候你就要随机应变，改变工作目标，述职的时候你可以说，由于业务改动，对此项目进行修复收益甚小且成本很高，所以替换成了xxx项目，然后对你xxx的规范做一个详细描述
- 目标不要写那么满
定目标的时候要在自己实际能力的基础上高于20-30%的能力去规划即可，这个对比最好是跟去年的自己，不要超出太多，明明知道完不成、抗压能力又小，非要定一个高目标，就想表现一把，作者觉得完全没有必要，目标是定给自己的，说大话完不成其实就是搬起石头砸自己的脚，所以要量力而行。另外一点就是，可以把一些想挑战的点放在实际的行动中，而不必在规划中表现出来，比如你把3次的分享计划，改成2次，但是你可以照着3次的分享目标去准备，那等你述职的时候实际完成是不是比你预期的还要高~
关于对公司的建议或疑问
发现有些人会针对这个模块会选择沉默，可能是觉得说多了对自己不好，也可能是没有什么好的切入点，也可能是问题有一堆，但是不知道表达哪个或怎么表达，所以最后的选择就是“没问题，都挺好的”，作者认为这是唯一一项赋予你的权利，在这个时候你一定要把工作中遇到的最想解决的问题在这个抛出来，这是来解决自己的问题的，这个问题如果解决了，可能对你后面的工作帮助很大，而且好的建议也可能让评委更深一层认识你，也能反映出你这人很有想法、观察力很强、有态度
那一般都写什么呢？因人而异吧，作者在这里也可以给大家推荐一些：
- 文档比较乱,历史需求要么没有，有也找不到，找到了又很精简
- 几乎没有技术分享
- 项目中使用第三方库也没有严格的调研，问题多
- 交接文档简单，会导致前同事离开，并不能快速上手项目
- 上线流程或顺序有问题
- 代码提交规范
- review流程
- 。。。
关于最后十分钟评委自由提问
只要你做好了上面的几点，数据真实，工作内容描述的井井有条，评委的问题一般也会围绕你的述职报告来问，到时候随机应变即可，没有什么可怕的，一般不会像面试一样问技术难度的问题，评委的问题一般是针对你述职报告中 他想听的你没有提到的问一下，还有一些有歧义的可能会问一下，甚至还有可能会给你一些小建议，所以这个环节就保持平常心就好~
这个环节给大家的一些建议是，逻辑清晰，谈吐大方，这里比较考验人的其实是表达+语言组织能力，评委问个东，你哼哼唧唧说一堆西，最后也不知道你说的啥，甚至当述职结束，你会懊恼不已，那个问题我要是这么回答就好了，我当时说的是啥呀，或者你的述职文档明明很好，但却因为紧张忘记了自己事先准备的步骤，少了一些灵魂的东西，如果你怯场，不敢在公共场合发言，害怕人多的地方，可以教大家一个方法，在家对着镜子练，你对着镜子说，拿个手机在后面录着，甚至在整个过程中你可以模仿评委会随机问你的问题，你要怎么回答，录完了之后看自己的表现，你可能就会发现自己的问题。作者以前真的是非常害怕在公众场合发言，而且小时候还口吃，就总是对着镜子练，一次不行两次，两次不行三次，回看视频的时候会发现自己会有一些口头语，话术不连贯等问题，会在以后的交流中刻意的提醒自己，慢慢的也就克服了紧张的问题，毕竟大家都是人，有什么可怕的，哼哼😏~
最后，希望这篇文章能对即将述职的你有所帮助，祝大家所有的辛苦都被看见
