Blog

Blog

PHODAL

程序员成长:如何写一份给自己看的年终总结?

你差的可能不是能力,而是一把复盘。

每年到了这个时候,为了生活仪式感或者 KPI,便都开始筹备自己的年终总结。三言两语之下,总结这一年里:

  • 做了些什么事情?
  • 取得了怎样的成功?
  • 收获了什么东西?
  • 未来会做什么?

或是出于成长的需要,总结自己辛辛苦苦一年的~~柴米油盐~~酸甜苦辣。或是出于公司对于 KPI 的需求,写一份总结。其差异也源于目的的不同,或是面向的是涨工资的需求,或是面向的是 “领导” / KPI 团队,或是为了嘉奖自己。目的地不同,写的东西也不同,收获也不同。面向工作写出来的东西,往往对于自己的帮助不是那么多——它们永远关注于工作。它们的方式,大抵是以年为单位的结果导向——充满了不可持续性。它们比不上以五年十年为的个人目标为核心的计划。

我们关心什么?

无论卑贱与崇高,无论美丽与丑陋,无论年轻与衰老,无论健康与疾病,我总会给自己写一份年终总结。再加上一定地装饰、美化,将它公开出来。或是用来获取被监督感,或是提醒自己前方的道理是否正确,一方面大抵是为了获得认同。而这种总结,依自己的角度来看,往往拥有这么一些套路,或者说模式,或者说模板。也不需要一一去区分三者之间有什么区别,它们拥有一个核心的内容便是:我们关心什么?。如从技能来说,我关心的几个技能方向:

  • 编程。
  • 写作。
  • 设计。

对应的要审视自己的有:在技术上,有什么提高,造了什么轮子,哪些地方可以做得更好?在书写方面,学习了什么东西,看了什么书籍,写出的文章怎样,下一步如何提升?在艺术方面,是否有投入足够的时间,某些方面是否与工作相结合?

正是一个个要素,能探索出每年关注于我们想要的东西,不断纠正自己的路线。

1. 写下 “流水账”

作为总结的第一步,我习惯将做过的事情,罗列到每年的时间线上。这种方式看上去,便是将年终总结变成了流水账,看上去一点意义也没有。但是它的目的是,一来可以防止漏掉某些重要的内容,以便方便后期做总结;二来,往往多个细小的内容,可能组成一个有效的结果

倘若我们是一个机器人,不耗费多少力气,便可以统计出每天的时间花费,自己一年的主要时间花费在哪里。可惜,我们并不是,我们只是普普通通的肉身,哪怕是一丁点的身体不舒服,都会影响我们的行为,思考速度。可以说,每天几乎都是完全不一样的。可在我们看来并不是这样的,我们的工作日看上去是一样的:

起床 -> 吃饭 -> 上班 -> 午饭 -> 午休 -> 上班 -> 下班 -> 吃饭 -> 业余活动 -> 睡觉

在这些平淡中,我们需要罗列一下,这一年里做了哪些重要的事?按照不同的公司的模式,罗列的方式也有所不同:

  • 如在工作上,笔者是需要以项目为单位,来统计在不同的项目上做了什么事。
  • 如在业余学习上,则是以 GitHub 的项目为单位来统计

从总体上来说,以每月为单位,来罗列一下自己做了哪些事情,会更为细致一些:

  • 1 月,blabla
  • 2 月,blabla
  • ……

将我们关心的维度,结合到 “账单” 上,便拥有了一个初级版本的年终报告。

记录下这些东西,方便进行总结。

2. 寻找关键结果

无论是在公司内部提供一份年终报告,还是写给自己看的年终总结,都得提炼出其中最重要的部分。如同,我们在编写简历一样,好的简历能突出某一部分,给 HR 留下好的印象;而差的简历,则看上去很平淡——因为写简历的人,可能把每一项都视为重要的部分。

这部分的内容,就好像在考察 KPI 一样。做得好的地方,便是能收获的地方。若是哪个地方没有做好,导致没有产生结果,那么也就无能为力了。这也就是为什么需要一份自我总结的原因——以 KPI 为出发点,便会忽视自我的成长。KPI 并不一定认可,你这一年的学习成果。因为对于你的学习来说,它在当前没有体现出任何的价值。

从我们的流水账中,找出那些闪亮的点、成就,它们值得我们去炫耀、证明自己的价值,鼓舞我们前进;或写入到简历中,又下一份工作寻找契机。如:

在这一年里,我写了一本微前端相关的电子书,编写了一个微前端框架,都受到了一定程度的关注。前者在 GitHub 上有 550+ 的 star,后者在 GitHub 上则有 250+ 的 star。数字 + 结果,无一不让人觉得欣喜。

若是因为做的事情过于平凡,不要过于羞愧,更应当去找寻关键的结果。一旦我们找不到自己做的重要的事情,又或者自己起的关键作用,在未来一年里,便更应当注意——是学习不到新的东西,还是位置不合适导致发挥不了才能。若是学不到新的东西,怕在将来会有危机,也因此会自己让自己更加地焦虑,而后起而行动

记录下这些东西,作为里程碑。

3. 总结收获

年终总结的目的,并不单纯只是为了晒到朋友圈,其主要目的在于:让自己审视(Review、复盘)自己的表现,以决定下一步要怎么做。

总结,是事后对某一阶段的工作或某项工作的完成情况,包括取得的成绩、存在的问题及得到的经验和教训加以回顾和分析,为今后的工作提供帮助和借鉴的一种书面材料。

在笔者的习惯里,我习惯将成功的结果和不那么 “成功” 的事情,分开来讨论。我总感觉某一部分有结果,似乎是理所当然的。但是,对于成功的项目、结果来说,我不会认为它没有学习的地方。

在有些事情里,反而是成功的部分更加坎坷,便能学到东西。因为在过程中,你或者别人挺身而出,解决了一个问题,推进了整个事件的正常化。那么,人人称道的地方,便也容易观察得出。

而有些失败,则是一开始就注定的,如饼太大,消化不了。不过,大部分的的失败,并不是这样的情况,它们值得我们去关注。对于目前的我们而言,有些事情的结果,并不是我们力所能及的,有些超出了我们的能力范围。比如说,我们花了极大的精力,去编写了一个开源项目,它一点儿也没有用户。不论是应用中存在 bug,或者是运营能力所有不足,都会在一定程度上体现出来。

所以,无论如何,我们都得从中去寻找原因,以便于自己学习。先总结下自己的所思,下次遇到的时候,便可以尝试解决。

记录下这些思考,方便未来进行对比。

4. 改进方案及目的

随后,从过去的点点滴滴里,我们会不断地获取知识:

  • 既然知道为什么成功,那么就知道学习如何成功,总结出经验和模式
  • 既然总结为什么失败,那么就要分析出改进的方案

而后,我们所做的事情,无非便是制定一个目的,然后创建一个计划;又或者是创建一个目标,而后制作改进计划。

但是,并非所有的目标,都需要实现的。按照不同的划分方式,有不同的目标划分级别(典型的如 MoSCoW 优先级排序法),又或者是笔者习惯的:

  • Must to have(一定要做)
  • Nice to have (做了更好,但是可以不做)。

这辈子有些事情,一年要明年做;有些事情,明年更了更好。分清它们的轻重缓急,然后计划之即可。

记录下这些目标,方便我们变更计划。

5. 计划

不论是学习和实现计划,都是这么几点:

  • 心态。
  • 技能。
  • 工具。

视目标的不同,方式便各有差异。

就笔者而言,笔者的佛系计划,都是顺其自然的。

关于我

Github: @phodal     微博:@phodal     知乎:@phodal    

微信公众号(Phodal)

围观我的Github Idea墙, 也许,你会遇到心仪的项目

QQ技术交流群: 321689806

新书《前端架构:从入门到微前端》

《前端架构:从入门到微前端》是一本围绕前端架构的实施手册,从基础的架构规范,到如何设计前端架构,再到采用微前端架构拆分复杂的前端应用。本书通过系统地介绍前端架构世界的方方面面,来帮助前端工程师更好地进行系统设计。

前端架构包含以下五部分内容:

  • 设计:讲述了架构设计的模式,以及设计和制定前端工作流。
  • 基础:通过深入构建系统、单页面应用原理、前端知识体系等,来构建出完整的前端应用架构体系。
  • 实施:通过与代码结构的方式,介绍如何在企业级应用中实施组件化架构、设计系统和前后端分离架构。
  • 微前端:引入6种微前端的概念,以及如何划分、设计微前端应用,并展示了如何实现这6种微前端架构。
  • 演进:提出更新、迁移、重构、重写、重新架构等架构演进方式,来帮助开发人员更好地设计演进式架构。
comment

Feeds

RSS / Atom

最近文章

关于作者

Phodal Huang

Developer, Consultant, Writer, Designer

ThoughtWorks 高级咨询师

工程师 / 咨询师 / 作家 / 设计学徒

开源深度爱好者

出版有《前端架构:从入门到微前端》、《自己动手设计物联网》、《全栈应用开发:精益实践》

联系我: h@phodal.com

微信公众号: 与我沟通

标签