半年述职已结束，伙伴们是否有如下“感受”：
述职材料难读懂！
给他人的反馈不给力！
逻辑基本功和你一起探讨述职背后的逻辑
01 述职模版（员工版）
述职模板本身就是一个经过实践沉淀总结出的“逻辑框架”，在述职模板指引下，我们更容易围绕“工作价值”和“个人成长”展开工作回顾与总结。你是否还记得这个“述职神器”呢？
我们一起回顾下：
1总结过去
目标与结果：结果很重要，这是我们的产出，从组织目标到个人目标，个人目标要能够支撑组织目标；
总结与分析：需要对过程进行总结和分析，复盘过程、总结经验、分析问题，是体现我们思考的重要部分，而人都是在思考中进步的；
个人成长：事情重要，人同样重要，一个人的眼界和能力决定了事情能否成功，我们的能力决定了公司的明天，也决定了我们自己的明天：）。
2展望未来
下阶段工作目标、策略和思路：工作目标是未来工作的方向，而策略和思路是目标实现的路径，路线的选择影响通往目标的速度，甚至是否能通向目的地；
个人成长目标：完成工作目标同时，个人成长目标是不是能够同步达成也很重要，我们希望人和事互相促进，借人成事、借事修人，实现个人和公司的共赢；
针对未来的目标，是否需要相关的资源支持和帮助：我们是一个集体，是一个组织，为了未来目标更好达成，个人需要组织给与哪些支持和帮助，组织也希望能帮到我们。
你，get到了吗
02述职逻辑三原则
有了模板，要避免在模板中流水账般地填充内容，更要注意各部分之间的逻辑关系和内容间的逻辑。
原则一：“前后一致”
保证内容的前后一致，是有逻辑叙述的基本要求。在述职材料中，以及日常沟通中，我们经常会见到前言不搭后语的情况，看得人一头雾水，想要搞清楚前后的关系还要问许多问题，这是一种典型的表述逻辑不清晰的现象。
举一个“栗子”
任务目标：进行xxx系统稳定性建设工作，3分钟发现问题，分钟级解决问题；
......
做完之后的总结：
稳定性建设是一个长期且持续要做的工作，目前只是初步建设完成，后续还需要做线上性能压测；
点评
总结中的内容与目标不一致，“线上性能压测”是提前发现问题的手段，但并不是“3分钟发现问题，分钟级解决问题”的手段。
原则二：“不重不漏”
重复和遗漏是逻辑的大敌。如何保证不重不漏呢？来了解下MECE原则。
MECE（Mutually Exclusive Collectively Exhaustive）意思是“相互独立，完全穷尽”，是一个分类思考工具，可以确保分类结果不遗漏、不重叠。
当我们要对复杂问题或资料进行分门别类的时候，就会用到MECE原则。如果分类没有涵盖问题的所有方面，那么最终推演出来的方案就有可能以偏概全；
如果分类有很多是重叠的，那么我们就无法梳理清楚真正的原因。
MECE常用的分类方法有很多，如矩阵法、过程法、要素法等，大家平时见到比较多的“事情按照重要紧急程度划分四象限”就是运用了矩阵法。
在述职材料里，又有哪些不符合MECE原则的情况呢？
进行xxx系统稳定性建设工作
目标：3分钟发现问题，分钟级解决问题；
工作计划 ：
负责核心链路梳理；
负责监控报警能力建设；
负责报警策略调优；
负责非核心下游熔断降级能力建设。
取得的关健成果：
完成核心接口关键指标监控报警配置及日志优化工作，基本达到1分钟发现问题，分钟级解决问题；
点评
工作计划中“报警策略调优”与“监控报警能力建设”重复，不符合MECE原则；
目标对应的工作计划有遗漏，也不符合MECE原则，建议从“3分钟发现问题，分钟级解决问题”两个目标分别进行拆解策略和行动；
由于拆解不符合MECE原则，“取得的关键结果”不能得到有效证明。
原则三：“严谨推理”
“推理”逻辑学指思维的基本形式之一，是由一个或几个已知的判断（前提）推出新判断（结论）的过程。推理在日常工作中经常会用到，严谨却是关键。
举个网络流行段子来看看：
一切权利都属于人民->我是人民->因此一切权利都属于我。
大前提“一切权利都属于人民”没问题，小前提“我是人民”看起来也没问题，但是很显然结论“一切权利都属于我”不对，为什么？大家可以想一想哦~~~
推理的前提可以是已知的公理、常识，比如说上面的例子，也可以是现实情况说明、数据等。
特别说明：数据，是我们在述职材料中经常用来反映问题或者说明成果的方式，在使用数字时，如果逻辑推理不严谨，会产生反面效果，让读者不相信作者的结论或者成果，更严重可能会因此怀疑整篇内容的可信度。
我们来看下面这个“栗子”
重点工作以及成果
进行xxx项目测试，保证系统高质量按时上线；线下过程质量进行了提升；质量结果如下：
线上bug：2019Q3有2个，2019Q4有3个。
线下bug总数：2019Q3有30个，2019Q4有8个；千行代码bug率从0.056‰下降到0.039‰ 。
由上述数据可知，Q4季度的过程质量有所提升，千行bug率减低，线上过程质量有所降低，线上bug都有所提高。
点评
"千行代码bug率下降"结合“线上bug减少”才能推出“过程质量有所提升”，而材料中第二个前提并不成立。
按照以上三个原则去审查自己和别人的材料，能够帮助大家更好地加强逻辑性，从而提升述职效果。
03讲了这么多，我们一起看看“扫地神僧”的述职材料
目标：
原有支付收银台系统不能满足业务高速发展及稳定性保障要求，组内启动了PHP转Java技术重构项目，我的目标如下：
按期完成交易服务的PHP转JAVA项目（7.31日完成上线）。
代码千行BUG率低于0.2‰，迁移过程无S4以上故障。
职责：
负责主R交易系统重构，按时保质完成上线。
问题：
交易服务重构与其他服务并行进行，人力支持不充足（项目启动晚，RD及QA人力不足）。
对系统及业务理解不深入，重构过程及线上质量压力大。
关键策略：
针对项目过程人力不足问题：
合理排期分工：排期前通过翻阅PHP代码大致预估编码及自测工作量，留足自测时间，每个子任务预留一定buffer；对项目按照功能进行分工，任务之间尽可能独立，互不影响，各接口自测及提测时间点更灵活自主。
风险预判与解决：制定计划前提前预判项目实施过程中的风险，在开发过程中汇总每日整体进度识别风险，提前发现并消化风险；与QA及时同步提测进度，更新计划，确保接口提测相互衔接。
针对业务理解不深入、质量压力大的问题：
编码前结合梳理文档及代码，理解业务流程；编码时疑问处todo标记，编码后走查代码，todo逐项核实处理。
分析前期bug较多原因并总结经验，落地编码checklist文档；结合收银台历史的测试用例，编写自测用例300+例；总结前期放量问题，聚焦放量过程关注点，确保线上问题影响不扩大。
关键成果：
进度方面：9.23日完成交易服务所有接口上线，开发过程无延期，上线相比原计划延期较多（开发投入晚且人员借调、QA人员不足）
质量方面：千行BUG率0.14%，同等复杂度项目过程质量高（QA评价），线上无S9及以上故障。
系统建设方面：重构下单、支付流程代码，提升了下单、支付流程的扩展性，提升了代码的可读性和可维护性。
经验沉淀：1）总结编码及放量过程易出问题的点，总结经验落地wiki/checklist，帮助提升重构质量。 2）总结开发及测试过程外部工具，收集至wiki落地，提升后续工作效率。 3）总结放量及流量迁移SOP及checklist，保障剩余接口迁移质量。
总结：
在重构过程中比较大的不足点是工期紧张，导致排期时按照完成代码迁移工作量来进行评估，留给代码重构的时间很少，从而造成项目中编码规范遵循不够、冗余代码较多、代码结构设计感欠缺以及服务稳定性方面考虑欠缺等问题。
经过三个季度的PHP转JAVA项目攻坚，完成了收银台技术栈、整体架构的拆分及重构工作。但是由于整体时间紧，开发人员对业务理解不深入等原因，造成一些系统内部结构及代码大部分还是继承了PHP系统的一些问题，如业务流程设计、接口设计、代码风格、异常处理等。因此各系统可以针对这些问题，结合业务流程及业务诉求，对系统细节流程进行设计重构，规范代码风格、异常处理等，提升系统扩展性及代码可读性，并持续进行提升改善。
点评
这段表述内容完整清晰、逻辑合理，体现出对整个事情思考完整、进展可控。
其中做的比较好的地方：
前后一致 ：成果比较好的体现了目标的达成情况，总结中针对实施中出现的问题进行了分析和反思，整体一致性较好；
不重不漏：如在关键策略中，针对“人力不足问题”分别从正向“合理排期分工”和逆向“风险预判解决”两个角度给出策略和解决方案，符合MECE原则；
严谨推理：在关键成果中，分别从线下质量“千行代码Bug率”角度和线上质量“线上无S9及以上故障”两个前提说明质量比较好。
你Get了吗？希望这篇文章能够在述职材料编写上助大家一臂之力。