一、为什么要述职？

组织需要：首先阿里是个述职文化比较浓厚的公司，基本上是一年两次述职，述职的形式各种各样：一对一的，一对多的，还见过视频直播的；述职过程一般就是述职人讲20分钟，评委问20分钟，述职效果的好坏每个组织应该都有自己的一杆秤，当然大体的评价标准大同小异。

个人成长：述职对于个人来说，官方点的说法就是对自己的阶段总结、总结反思以及阶段规划什么的，不过最实在还是在个人晋升上，晋升对每个人的重要性就不说了哈，述职好坏直接影响了组织对你的评价，如果你有辛被提名了要去答辩的话，述职文档的编写能力、演讲能力、临场发挥能力，这些都非常重要了，直接影响你晋升的结果。

二、述职怎么写？

1、文档结构

所谓的结构化思考能力一定是从一个好的文档结构开始的，优秀的文档结构基本上就已经把内容说清楚了，看内容细节只是想证实下自己的想法是否和作者想的一样而已。

当然个人认为这个结构还有一个好处：以终为始的做事方式；如果下图的每一项都是一个填空题，那是不是一年里做的事按照这个图把它填满就可以了。

2、概述

金字塔原理：如果让你1分钟把你今年做的事给你领导汇报下，你怎么组织语言呢？如果给你10分钟呢？如果给你1个小时呢？问题的答案就在金字塔原理这本书里，其实就是把自己做的事总结抽象成一个金字塔结构，思考原则：相互独立，完全穷尽，想深入了解的建议看原书，当你把你做的事都用一个金字塔展现出来后，你只需要按照你的金字塔层次来组织语言就可以了。给你1分钟，你把第一层的事情说下；给你10分钟，你把第二层的事情再说一遍；给你1小时，把第三层的事情再说下，再举几个例子。

大道至简：这里的概述其实就是当你要开始长篇大论前，请先用一分钟总结下你都干了些什么，让人有个总体的认知，如果你这个都没说清楚，后面估计别人也没心思继续听了。那概述具体写什么呢，如果是业务的话，业务结果写清楚就可以了，但这里个人认为有两个重点：

• 归因：也就是这个结果和你个人的关系，因为这里我们说的是个人述职，既然说业务结果如果能很清晰的说出这个结果跟个人的关系，那自然是很好的，不过有的时候做的技术基建本身就是没办法归因的，譬如做了一个系统提升了小二的工作效率，但业务增长是没办法归因的，但有时候优化了接口性能，是可以带来业务效果增长的。
  
• 增量：个人认为业务价值一定是要有增量部分的，业务增长有时候也是有自然增长的，如果没有合理的AB实验，那这里的增长有可能是自然增长的，而不是你这个项目带来的，所以合理的AB实验产出的数据效果，更有说服力。
  

再来就是技术结果了，技术结果是技术人最起码的追求，也是实现自我价值最直接的东西，业务要关注归因、增量，那技术也要有关注的点，个人以为也有两点：

• 不要造轮子：之前内网也出现过造轮子的热帖，很多大佬都有回帖，说的是慷慨激昂，我个人以为每个人心里都有杆秤，至于是选择做正确的事，还是选择当前的苟且，只有他自己才能权衡；我只能说当天平出现在我面前时，我会偏向做正确的事，但我也没办法保证在任何情况下不苟且。
  
• 带来变化：今天你做了一套新的系统，或者重构了一块代码，到底带来的前后变化点是什么？个人理解变化点大致有三类：作业效率的提升、业务的增量结果以及技术先进性的提升。
  
• 作业效率：这块是大部分技术在做的事，譬如把一个原本线下的流程搬到线上来了，本来需要在excel里各种操作，现在只需要在线上点几下就可以了，变化点线下变成线上了，节省了操作时间；或者把一个搜索系统的性能优化了，结果呈现从2s优化到500ms，买家可快速看到搜索结果，这样不仅提升了买家的体验，同时还能带来增量业务效果；
  
• 业务增量：这个是大部分技术都想做但做不好的一块，通过技术的手段带来业务增量，这样作为技术就可以证明出自己独一无二的价值了，而不是作为资源工具人去实现PD的需求；算法的千人千面是个典型的例子，通过技术的模型预测来推算出买家的喜好商品，完全由技术算法驱动。但我还想说的是，有时候有些系统的开发跟业务效果本身真的完全没有关系，真的不要硬上，真的很没有意思，譬如你做一个活动招商系统，这个就是用来活动招商的，产品的自身定位就是为了提升小二的招商工作效率的，非要硬杠业务效果。
  
• 技术先进性：这个大概就是面向未来的技术吧，上面说的都是苟且，那远方就是这个了。有可能是所在业务技术团队的缘故，看到很多这样那样的系统，技术都差不多没有太大变化，大部分人都在用最小化的方式完成当前的快速结果，但我们是不是不要那么眼前，是不是可以站的稍远一点，自己感觉下未来三年大概是什么样的，然后留下点什么不一样的东西呢！
  

3、工作总结

业务背景

一切从why开始：一件事如果可以把问题定义清楚的话，那这件事已经成功一半了，看到很多新人甚至是来了好几年的同学，开始了一件事情，为啥做真的说不清楚，不知道自己为什么做，或者知道的只是很表层的原因。5W2H模式里面最重要的就是why了，why搞不清楚请不要开始。

怎么搞清楚why：如果你遇到一个很靠谱的pd，她会把为什么做说的很清楚，恭喜你，你遇到了一个超级好的pd，但大部分时候我们遇到的pd，自己都不知道为什么要做，或者说的逻辑完全不通。这时候我觉得你需要自己调研清楚，否则下一步的巨坑将等着你跳。那怎么调研呢，个人理解有几个地方可以切入，第一：数据分析，尽可能多的拿到一些业务数据，分析这里面的逻辑，找数据的关联性，不过这块工作对一个后端同学来说还是挑战不小的。第二：找资料看，ata上、各个搜索引擎、买书，最大化的扩大自己的领域知识，这样起码可以快速了解这个领域内的小白知识，不至于犯低级错误；第三：找专家问，在各个渠道找到领域的专家，谦虚的请教咨询，把自己遇到的问题都准备好问他们，看看这些高手之前遇到的坑是什么，作为自己的思考输入，起码可以站在前人的基础上继续往前走，而不是失败再来一次（不要说你比他聪明，你不会犯那样的错，no！你跟他差不多聪明）。

三个why：通过以上各种输入调研素材，表事实讲道理，把问题都列出来，如果问题太多的话，建议抽象归纳成三个问题，当然三个不是绝对的。

解题思考

不要省略思考过程：同样看到很多人的述职文档，业务背景描述结束了，后面紧跟着就是一个系统架构设计，这就很奇怪，我并不是说大家没有思考，但是的确是没有看到，只是也许你的思考被你省略了，我想说高考作文你不思考就直接下笔吗？起码有个审题和解题路径吧。

资源的权衡过程：我只想说很大一部分问题，只要能定义清楚出问题来，都是能解决的，只是在解决问题之前，需要盘一盘当前的形式以及手上的资源情况，然后给出一个最适合的ROI解决方案；这个权衡的过程其实就是解题思考，需要思考人力资源、机器资源、资金情况以及组织情况等等，这些所有的权衡过程都贯穿成一个解题路径，把这些所有的思考和权衡过程写出来，最终得出一个结论，我们要做一个什么什么样的事情，那么目标就出来了。

最近看到一些大项目在如火如荼的进行中，但官方的文档里并没有这些业务背后的思考，直接一个目标，然后产品应该这样做那样做，然后结束了；也许是思考没有写，或者其他什么原因没有附上，但如果执行的人自始至终都不知道背后的思考是什么，他们怎么会有信心呢，只能自己把自己当工具人了，大概率政治项目都是要失败的。

目标制定

环境决定决策：业务目标有业务增长率的测算来完成，这里重点说下技术目标的设定。一句话：技术目标是围绕着业务在当前的阶段或形态来设定的。对于任何一个系统，它都有发展阶段，按照历史经验，一般的系统都会经历三个阶段：产品化、数据化和智能化，在不同的阶段技术目标一定是不一样的。举个例子：对于一个营销平台，产品化阶段一定是把这个营销平台做出来，对外需要提供营销费用的计算能力、营销氛围的统一管控、权益的传播&核销等等能力，对内需要需要搭建一个后台营销配置平台，让活动小二可以快速配置上线一个营销活动玩法，做成这样产品化阶段应该就差不多了；数据化那就要把全链路打点、AB实验能力、各种维度的数据效果看板做出来，甚至要做出一个自动化的效果数据分析能力了；智能化大多是要通过历史的营销数据做迭代反哺了，通过历史数据加业务结构化的规则建设ROI模型，在营销前期给出最佳营销费用的投入，产出最大的收益，说句简单的，就是算法模型告诉你营销应该怎么玩ROI最大化。

切勿为了情怀：之前听过一个真实案例，一位同学花了两个月的时间，把一个页面接口的性能从500ms提升到100ms，页面出来的速度更快了，本来想在周会上show下自己的成果，结果反而被领导批了，领导说：对于一个网页的浏览者来说500ms打开一个网页和100ms打开一个网页有什么区别；这个故事告诉我们，不要盲目追求高可用、高性能、高扩展，所谓的三高一定是在有被需要的情况下才有意义的。

技术方案

面向未来的架构设计：技术目标说白了就是着眼眼前，根据眼前的情况定一个合适的目标，但在设计系统的时候绝对不是着眼当前，设计系统要面向未来。系统架构图应该怎么画，听到过一个靠谱的回答，包括四个部分：系统和外部的边界、内部组件的上下左右关系、系统的非功能性设计以及面向未来的设计，所谓的面向未来的设计，个人理解起码看到未来三年的发展形态，是抽象总结业务表层问题，看到问题背后的本质，然后把本质抽象归纳成领域模型概念，通过对领域的分析思考，产出一个面向未来的总体架构设计，其实就是多想三步，把未来的可能性都放进去。

落地再次贴近现实：总体的架构设计完成后，到具体的落地环节，还是要回归到阶段目标设计里去，根据当前的资源情况产出一套落地的具体技术方案出来，这时候类似时序图、服务类图、流程图、应用关系图等等就派上用处了。这里对于这些图的详细程度标准，个人理解最好是拿到这些设计就可以直接编码的程度，千万不要等要写代码的时候，还要重新思考一遍，那就太浪费时间了。后续多次的迭代其实就是对最初那个大图的不断完善和扩展了。

谈一谈技术深度：之前有一段时间，有个问题一直困惑了我很久，就是：你这个设计技术深度不够！当听到这个问题，瞬间蒙了，什么叫深度不够，多深才是深呢？10米还是100米？关于这个深度有一个衡量标准吗？当然问这个问题的人，他也没解释清楚什么叫深度，我当时真有点感觉他在pua我，但是我还是带着这个问题日思夜想，终于得到了一个自己觉得稍微有点满意的答案。技术深度其实可以用某一领域的专业技术壁垒来解释，说到深度是在某个精细化的领域下，通过长时间的沉淀积累或者遇到特殊场景下的复杂问题，总结出一些专属在这个领域场景下的技术方案，我觉得这可以称作为技术深度。至于复杂问题我说明下，多复杂叫复杂？这其实也不好量化，说的简单点，当你提出一个领域问题时，对于大部分的普通技术专家来说，他无法在短时间内给出解决方案，那么我认为这就是复杂问题（当然不排除天才级别的瞬间能想出办法来）。当然我再重申一句，千万不要为了技术深度而过度设计，只是当我们遇到了有技术深度特点的事，我们知道怎么去判断并很好的表达出来。

结果说明

这里的结果逻辑思考路径跟概述里是差不多的，但区别是这里的表达可以更细致一些。譬如业务数据可以把具体的计算公式列出来、AB实验对比的时间维度列出来等等；技术结果可以把概述里面沉淀的平台扩展开来，详细说明下里面的核心模块、扩展性，甚至是横向方面的一些内容都可以，譬如性能、稳定性、安全方面等等。

总结反思

总结思考本质上和解题思考是前后呼应的，一件事情在一个阶段结束后，一定是有做的好的和做的不好的地方，做的好的大大方方的写出来，特别优秀的数字和战绩完全可以标红加粗，做的不好的也大大方方的写出来，千万不要说今天只有Highlight没有Lowlight，这个是绝不可能的，任何系统在不同的阶段和环境下总有问题，只是组织在权衡了利弊后，选择是否要去解决它而已。其实Highlight在前面的概述和结果说明里大体都提到了，这里重点还是要说下Lowlight，说句比较实际的话，没有这里的Lowlight，下个阶段的规划怎么写呢？

4、个人成长&团队贡献

灵魂拷问的启蒙：之前有一次分享，整个过程中的我滔滔不绝，一切尽在掌握中的感觉，结束后到了Q&A环节，有个前辈问了我一个问题：“你这个系统挺厉害了，但现在假如由于组织调整，必须要把你这个系统交给别人来做，你怎么看？”，当时第一反应就是：“我做了这么长时间，付出了这么多，马上就要收割了，你让我交给别人，肯定不干啊，强行拿走，我就辞职。”，当然那种场子肯定是场面话应付过去了，譬如尊重组织选择啊、拥抱变化啊什么的，但没等我说话，前辈紧接着又是一个问题：“如果你现在做的这套系统承接的业务没了，业务被砍了，你怎么办？”，说实话当时脑袋瓜嗡嗡的，脸很烫，自己从来没有思考过这种问题，完全不知道怎么回答，后面只能说会后再思考下这个问题。

可迁移的个人能力：其实这个问题背后的逻辑就是个人成长问题，如果你的系统交给了别人，或者你的业务没有了，那就给呗，没有就没有了，互联网产品的变化本来就是这样瞬息万变的，重点是你在做这个系统的过程中，自己在哪些方面得到了成长，是架构设计能力、数据洞察能力还是结构化思考能力，这样的能力提升是伴随着你一生的，是刻在你脑袋里的，没有人可以拿走，这个才是属于你自己真正的财富。前段时间有个同学问我，个人成长都有哪些呢，我大概写几个大家参考下：组织协调能力、数据洞察能力、项目管理能力、复杂系统架构能力、团队管理能力、结构化思考能力、沟通能力、演讲能力等等，大家可以拿这些能力对照下自己，哪些方面比较弱，可以给自己定一个财年目标，今年重点训练哪几个。之前听过一个人，把这种能力定义成叫可迁移的能力，这些能力是不分行业不分工种，每个人在职场都应该不断完善丰富自己的这种底层基础能力，假如哪一天互联网落寞了，换个行业你也可以快速适应下来。

关于团队贡献：我认为其实本质上还是在于个人成长上，只是在你成长的某个阶段你需要把你的成长外化出来，通过各种形式表达出来，通过ATA文章的形式写出来，通过在各个地方（团队内、bu内、bu外、集团外）分享告诉更多的人，也可以针对创造性的技术点写专利、论文，这些都是不同的渠道而已，重点是要输出，成长其实就是输入和输出的过程，费曼学习法也是这样的逻辑，输入后一定要有输出，你把不明白的人说明白了，你才是真正的明白了。当然通过这些外化的形式也可以带来个人品牌影响力的提升，至于个人品牌的重要性就不多说了，大家自行yy。

5、财年规划

看一个人对一块业务的理解程度，只要问他对这块业务的下一年规划是什么就够了，如果需要更深入的话，就问三年规划。要回答这问题其实非常难，首先要知道业务的定位是什么，整个组织给这块业务的位置在哪，需要完成什么样的历史使命，核心的衡量指标是什么，核心的领域问题本质是什么，当前处于一个什么样的外部环境，核心的业务&技术问题有哪些，这些问题的优先级是什么，问题应该怎么解决，别人是怎么解决的，别人&自己的优势&劣势有哪些，当前的资源怎么组织可以最大化的解决这些问题，有没有更好的解决方案，如果有需要哪些资源的配置，落地的节奏是什么，需要哪些团队配合，有哪些风险等等这样的问题，当然如果这些问题都想明白了，那真的是想的很明白了。

其实在上面一些小节中已经说了同样的一些内容了，当前的形式环境下一定是有新的问题，透过问题找本质，面向未来做设计，把其中的逻辑说的足够自洽其实就已经超过80%的人了，后面只需要一些文字功底、画图能力以及演讲技巧，把问题表达清楚其实就可以了。

写在最后

最近一年自己组织了一个新人学习小组，看到了很多新人遇到的一些这样那样的问题，有时候他们是真的不知道，在成长中遇到各种各样的困惑，在这个过程中通过个人的努力也得到一些同学的正反馈，属实有点欣慰，原来帮助别人得到反馈是这么幸福的，所以把自己的一些算经验教训吧通过文字分享给大家，希望能帮助到更多的人，这也许就是稻盛和夫「心」这本书里说到的「利他」的辛福感吧，感恩。