听说，年终总结写不好，绩效要被打 C
Posted dbLenis
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了听说，年终总结写不好，绩效要被打 C相关的知识，希望对你有一定的参考价值。
点击蓝色“有关SQL”关注我哟
加个“星标”，天天与10000人一起快乐成长
我曾问过身边的年轻朋友们，你们平时写日记吗？
猜猜这些工作2，3年的程序员们，怎么回答。答案自然是五花八门，其中最令我咋舌的是，“正常人谁写那玩意儿啊”。几近戏谑的话，对我来说却十分深刻。
“是的，正常人谁写那玩意儿呢”
我坐在星巴克大落地窗下，望着窗外朦胧的烟雨，不禁沉思，在写字儿这事上面，有多少人是认真的呢。
乱花迷人眼的新奇感，让我们越来越舍不得放下手中的游戏机，爆米花，还有星巴克。是的，我们都不能逃离。于是，时间越来越碎，精力越来越涣散，拯救严肃思考的，似乎就只有写字。
回到现实中，工作上的总结，可能并不是一板一眼的邮件，一个PPT。可以是老板的一次面谈，也可以是一份开放式问卷。
细想，你老板面对几十张要吃饭的嘴，能做到面面俱到，对你的工作内容十分清楚？他除了每天上千行的代码，真的还有心思，来琢磨该怎么培养你？
所以，无论如何，我们都不能相信，你的直属老板一定会把你当亲儿子，亲闺女一样来疼爱，对不对？
你的喜怒哀乐，在老板面前就是个屁。与项目进度，风险和收益相比，老板一定不在乎，你今天是吃了KFC，还是麦当劳，甚至因为无良商家的螺蛳粉，闹了半天肚子，情绪已经炸天。
所以总结报告的王者打法，一定是只讲老板想听的。
与老板同频
这个时候你一定要和老板的屁股，坐在同一处。他的业绩就是你的饭碗，他的米袋子撑满了，你的米袋子才有机会。
这个时候，你就要使劲去回忆，老板在年初动员大会上讲的所有目标细节。当然这里如果你有保存一份会议纪要，对你的回忆绝对十分有利。
通过回忆，你终于记起来全部的技术目标：完成市场部和财务部的 ERP 自动化报表系统，达到交付率99%，数据一致性质量为100%；提高客服服务质量，降低系统异常投诉率，控制在3%以下；完成数据流自动化测试平台搭建，全年测试覆盖率达到85%以上。
围绕这些目标，处于初级，中级和高级职位的你，应该做出不同的工作阐述。
举个我们组的例子。年初动员大会，讲目标的时候，老板说要完成80%的自主搜索功能，结果有个同学说，他要继续ios的学习。学项目之外的技术，当然很好，没人拦你，作为私人目标就好。
总结时，发现有些指标没有完成得很好，怎么办？老板当然知道有些不足，只要不影响大局，无伤大雅。
但有些直男，就会坦白地说 “今年目标执行失败，没有达到KPI”。你以为工作中谦虚是美德，得做得实诚，而放在老板眼里，就会觉得你缺乏自信和不识大局，拎不清主次。这些没完成的指标，优先层次比较低，做成自然好，做不成也没关系。
比较委婉的做法，可以和去年做比较。只要比去年好一点，今年的目标就不算执行太差。报喜不报忧，这不仅是给家里长辈汇报的艺术，也可以用到工作上来。
反过来，指标完成得特别好，直接说KPI都完成了，行不行？其实还不够，你还得抠细节。老板恐怕早已忘记KPI的具体细节是什么，这个时候，你就可以大胆自信的嘚瑟，完成了销售额1500万，比起KPI的1200万，超额完成 25%, 比去年同期的1000万增长了50%；生产系统故障率0.01%, 客户投诉率 0.05%, 完成指定的KPI，环比下降 10个百分点。
总结，与老板强相关的，多扣细节，多举证。和老板无关的，比如自己的成长，自己的私人计划，不说。
简洁不失重点
工作1-3年的朋友，平日里能做的工作，大部分是按照工头下发的任务来完成的。那汇报的时候，当然也只能按照详细的工作内容来阐述。你说要把这些工作讲出花来，是不现实的，也不要对自己太苛刻，搞得压力很大。
比如，你作为一个入门级的数据库开发，你在写报告时，写清楚今年做的2个项目，分别是做的什么业务；工作的完成度有多少，有没有延迟交付，为什么延迟交付；解决了多少Bug，遇到问题是怎么解决的，就行。
参考范例：
今年总共参与了两个项目，财务部 ERP 和市场部 CRM. ERP主要负责收集工厂产能数据，核算每生产单元的成本，完成委外生产成本控制。CRM 是公司对外收集客户反馈资料的信息系统，有大量的电话，邮件接入，通过对这些信息文本的存储，分析投诉率和完善客服质量。
两个系统总共完成 200 个存储过程的开发，准时交付率达到99%。由于2个需求在交付日前一个星期重改，与用户确认后，延迟一周交付。
参与系统bug的调试，累计完成98个，完成率98%. 另有2个比较严重的系统故障，在资深某工的指导下调试成功。
工作5年以上的朋友，那么肯定有很多东西可以讲了。比如接触到的生产环境现实问题多了，项目中使用不同架构的机会多了，这个时候，你就不能只介绍自己的一亩三分地，毫无分寸感的来阐述自己的工作内容。
比如，作为ETL设计师，你需要谈下为什么要迁移到流计算引擎，完成了什么样的业务功能，比原先的批处理提高了多少吞吐和计算；在Spark, Flink两者的选择上，究竟有哪些考量最终支持了你的决定，等等。
参考范例：
今年参与了数据仓库平台（SuperBI)的设计与开发。
SuperBI以全公司8个子系统的MES, ERP和CRM应用为上游数据，以Kimball理论为搭建基础，采用了流批一体化设计策略，为全公司各部门提供了自动化报表服务。替换公司原有的Excel服务，节省了800多万的微软服务费用，将原先报表计算时间从T+1缩短到了T+0,加快了1天的报表交付时间。
在整个建设平台期间，一期采用了mysql 为存储的方案，快捷，高资源和低成本是我们考虑MySQL的因素。后期加入了 Flink 计算框架 和 ElasticSearch 引擎，前者完成生产设备数据及时入库的需求，将设备管理和风险控制窗口时间提高了1小时，而后者满足了市场部对投诉反馈进行自助式检索的需求，将客服响应时间提高了5分钟。
同时，我们还对比了行业内通用的Kylin, clickhouse框架，通过测试数据发现，两者在分析时有较好的性能提高，平均提高分析时间4小时。如果明年数据量再成倍增加，就可以尝试投入资源来做。
以上仅供参考，列具体项目的时候，综合重要性，时效性做分层阐述。
缺点和人事的避讳
人无完人，谁还不能有些缺点。但如果你把缺点放到工作总结里，那就容易出事。
比如作为财务，你说你工作马虎，数字粘贴错误，好几次通过复查改过来了，那么作为听众的老板，会不会觉得，天哪，这种重要的财务数据，你都能搞错，还有多少是没有找出来的？你是不是其他事都那么马虎，以后还能放心把事情交给你么.
再比如，你说你是个直男，暴脾气，看不惯这，看不惯那，老爱发牢骚，给团队增加了很多负能量，那么老板还能相信你能把团队带好吗.
所以这些都不要谈。
人最难控制的是自己的情绪。在工作中，由于压力和困难，会遇到各种与同事合作的不愉快。那么这些不愉快要不要在年终总结的时候，说出来呢。我认为毫无必要，最好还要回避，即使老板问起，你也不要说，顶多说沟通还需要加强，千万别说对方懒散，工作态度极强恶劣等等。
为什么平日里工作受了对方那么的侮辱，无视，甚至是对方工作拖沓的工作方式带来的项目延期，我们也不要说呢？
还是前面的第一点，老板请你过来做事，是帮他完成事情，而不是听你来抱怨的，如果他知道了这些事情，他主动帮你去找同事沟通，在他眼里，你就是属于把问题上交的那种，工作能力不强。
真遇到平时工作不努力的同事，你可以当面找他沟通，争取达到双赢的地步，也不要在最后年终的时候，在老板面前叨逼叨比，意图阻止对方升职加薪。说不定老板还拿他当主力心腹培养呢，你不恰当的表述，可能引起老板反感。
跟老板谈话，先深吸两口气，平复下情绪，保持心如止水，把自己的眼光和格局放大，别盯着同事的一面不放，转换下角度，去观察他/她的好。
真的要跟老板抱怨同事，我给你个不会挨打的建议。每说一件负面的事情，多给他/她补上一件好事，这样老板会认为你看人比较全面和客观。最重要的是，老板会认为你在和其他同事，死党吐槽他/她的时候，也会客观。
总结，自己的缺点，同事的缺点，都不要出现在年终总结里。
下一步计划
我想在老板谈话或者年终总结的最后，都要说说你自己的下一步计划。如果是面对面的交流，老板肯定还是要问你，你还有什么要说的吗，这个时候就给你足够的空间。
首先，还是第一点的基础上谈。不能与团队，与老板的方向，相差太远。老板要你明年准备大数据战略方向，你不能说你要去学安卓和iOS开发，这肯定没戏。
那么你一定是要围绕着团队的方向谈自己的看法，预测和技术加强。
你可以坦言今年哪个方向还有提高的空间，看下老板是不是有资源和意向给你足够的时间与资源去继续投入。这样才能争取到明年的项目，主导自己的工作内容。当然这些都是基于你平时的观察，实战和思考。
在年终的1,2天，你要突击做完合格和完美，是不可能的。写文案设计到太多的技巧和要素，功夫还需花在平时。所以我建议大家平时都写写日记，记录下对工作和生活的领悟，培养自己的写作素养。
--完--
往期精彩：
以上是关于听说，年终总结写不好，绩效要被打 C的主要内容，如果未能解决你的问题，请参考以下文章