年底了，又到了写年终总结的时候。有意思的是，我还是头一次遇到，需要自己给自己定义工作绩效考核标准的情况。虽然逻辑感人，一时间给整不会了，但是要做的事情还是要尽力做好。
完成之后除了“交差”之外，还有一些意外的收获：
更加明确工作目标——毕竟是自己梳理的；
主动展现工作价值——你不提，别人万一不知道呢？
总之，小有成果。于是写篇文章分享一下，希望对同行的你，也有启发——毕竟，对于每一位职场人来说，绩效考核都是工作中绕不过的坎儿，很重要，与薪资、职级直接相关。
大家好，我是睿齐，一个技术传播从业者，IT行业技术文档工程师。
思路
在着手自己给自己制定标准之前，先简单整理一下，如何做这件事：
明确需求方的基本要求。以“交差”为目标。
了解绩效考核标准基本知识。毕竟干事儿，我们是业余的，必要的知识要get起来。
听取同行建议，吸取先进经验，查漏补缺。
基本要求
明确的要求是：尽可能采用可量化指标。
潜在的要求是：围绕职责定义进行细化。
具体到我个人而言，职责定义包括：
文档交付：保障文档交付，内容质量可靠。
系统建设：建设文档相关流程、规范、模板、公共知识库等。
由于我司产品涉及芯片、硬件、SDK、编译器、算法、工具等，对专业技术背景要求较高，所以技术文档主要由研发人员输出。文档工程师只我一人，职能更接近于：
产品：标准定义。保障研发输出的文档可以达到产品对外交付的质量要求。
项目：项目管理。组织文档开发协作，推动并保障文档按时交付。
开发：文档开发。由于技术文档主要由研发输出，本人参与的部分主要包括文档内容架构设计、内容/样式优化，以及后续低级错误修订等。当然一些对技术要求不高的工具类产品，视具体情况也可以分担一些开发的工作。
基本概念
想制定绩效考核标准，需要预先了解一些基本知识打底。
我个人参考的是百度百科“绩效考核指标”词条，基本上说明得已经很充分（够用），其中值得被画重点的是，衡量绩效的总的原则应聚焦于：
是否使工作成果最大化；
是否有助于提高组织效率。
考核标准
明确了目标，请开始你的深度反省。基于之前对职能的拆解，进一步细化为考核标准。
产品
定性指标：
标准定义是否充分，包括但不限于流程、规范、模板、公共资源。
标准定义是否适用，满足产品交付质量要求，能够指导开发人员保证文档质量。
标准执行是否良好。
项目
定性指标：
文档开发流程是否清晰，并落地执行。
文档开发责任是否清晰。
文档项目管理是否清晰，能够说明文档状态、开发计划/进度等。
开发
定性指标：
文档更新是否及时。
文档交付是否及时。
文档质量是否可靠。
定量指标：
开发量化。以具体任务为单位，包括但不限于：设计、开发、优化（内容/样式）、审阅、修改、发布。
响应量化。及时响应率。用于说明处理文档反馈意见的速度，例如3日内答复，7日内解决等。
交付量化。包括但不限于：
交付次数：说明文档交付数量。
完成及时率：说明文档开发能否按计划完成。
错误率：说明单位文档内包含错误的数量。衡量标准可设为每千字可接受的错误数，如超出则说明文档质量不满足；同时可设定错误级别，或者简单区分技术错误和低级错误。
影响力
在同行的提醒下，我补充了影响力相关指标。我个人也认同，这才是文档价值的真正体现。
定性指标：
文档是否满足内外部用户使用需求。
文档是否起到积极的产品宣传作用。
文档是否有助于降低技术支持成本。
定量指标：
文档使用量：说明文档实际使用情况。
正/负反馈量/率：说明文档实际使用满意度。
工单率：降低技术支持工单率。
总结
在于同行交流过程中，IBM的Goto给出的指导，非常适合放在这里，作为总结。
基础的：是否及时交付；文档质量。；
进阶一点：看文档的访问量的变化，用户对文档的使用情况的量化，以及这些数据季度和年度变化。
再进阶一些：看对企业营收成长和成本节省的贡献。
我个人感觉非常受益，并尽可能把这些点考虑进去。
不过具体到每个从业者、每个职位，可能具体的情况都不相同，需要具体问题具体分析。以上分享，本意是说明思考过程，仅供参考。
没想到，抛砖引玉看到很多深度的讨论和分享，获益匪浅，在此一并感谢。
最后，本文思维导图走一波：
其他推荐：
实施：GitHub + MarkDown 文档系统的工作环境部署及工作流程说明 | 技术传播
这次他们说好要“讲真的” | 传播
在座都别吵了，你们还有我 | 技术传播
睿齐
技术传播从业者
品牌内容策划
自由摄影师
自由撰稿人
汪力迪
公众号：techcomm / htstory
微信号：bgrichi
邮箱：hash_0813@163.com
386
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
