做好述职是个多方面能力的组合，比如要有文档编写的能力，演讲的能力，临场发挥的能力，以及平时思考总结的习惯等。
当然最重要的还是事情本身做的好，这就需要你对事情背后的业务价值了解以及你的技术落地能力有一定的要求了。
有人说述职是一道证明题，目的是证明你牛逼，手段是做的事情很牛逼，通过做事过程的思考，落地效果，实现证明你的目的。
比如为了证明你具备了负责人能力，你就需要找个事情作为论据，说你过去把这个系统负责好了，怎么证明你把系统负责好了呢？是这样思考业务需要的，思考问题现状的，思考问题本质的，经过一些取舍，到达了几个合乎逻辑的方案，推动落地，拿到了成果。
这样就闭环了一道证明题。
当然不是说事情本身牛逼，而是你赋予这件事情的牛逼的点。
因为一件事情之所以做得好，可能是环境导致的，或者竞争对手拉胯，不代表你能力好。
述职文档是做好述职的第一步。
述职文档要求结构化，一个好的述职文档的结构，基本上把内容说清楚了。
把述职材料填空进去就可以了。
整个述职文档结构体现的是金字塔原理。
你可以把你做的事情，打破时间线，以金字塔的结构重新组织。
要求MECE，相互独立，完全穷尽。
有了金字塔的结构，有了不同的层次内容，接下来就需要抽象的总结提炼相关语言了。
比如你可以把平时全部文字念下来要十分钟，抽象提炼到1分钟，避免长篇大论。
文字抽象与提炼背后是为了让别人听懂，不然说了好几分钟，也没用个主题思想，很容易让对方懵逼，别人就没心思继续听了。
写业务，首先给个概述，直接写清楚为什么要做这个业务和业务结果就可以了。
但是需要思考这个业务结果和你的工作怎么联系起来。
比如业务的GMV增长了，很难和你一个技术同学的工作产生联系，这里面的逻辑关系就需要你思考怎么衔接过来了。
有些业务增长的数字，不太能直接写个数上去，有可能是业务自然增长带来的，和你的努力没有半毛钱关系，你得有ABtest才能证明做的是好的还是坏的，也更有说服力。
技术同学的工作价值可以从几个点考虑：稳定性、效率、质量、成本、技术先进性、体验角度。
比如效率，以前某个定时任务跑2个小时时间，分析下来，原因是什么，解法是什么，落地了一个什么系统，获得了什么样的收益（收益一定要回到业务收益上去，比如帮助商家提高了工作效率，提升了体验，对搜索增量有帮助等）。
技术先进性，就是用比较好的技术实现方式，解决了现在的问题，这个方式有一定的先进性或创新性，因为是新东西讲明白就很重要。
述职讲业务部分，一定要讲明白why，一件事情一定要把问题定义清楚，定义好问题，问题就解决一半了。
很多人问题都没讲明白、价值都没讲明白，就开始讲方案，整的大家一脸懵。
而且why要找到根因，不要停留在表层上，谁能挖到根因，谁能找到本质，谁对问题解决的也就越好。
讲明白业务的why，如果有个很好的业务pd，他能说清楚，恭喜你。
但大部分情况下，业务pd自己都不知道为什么要做，还需要研发不断push业务和产品去思考你的业务价值是什么，为什么这么做，这么做究竟能不能实现业务效果。
如果需要自己去调研why，方式可以是看业务相关数据，学习相关领域资料，和专业的人去聊。
通过以上调研和了解，对事实了解是有帮助的，讲道理就是讲事实。
把问题列出来，如果问题太多，就抽象成三个问题。
明确定义了问题，接下来就是解题思路了。
这个过程非常重要，因为一件事情的事实，和事情达成的结果，和你的关系性不大，你的思考过程是真正能体现你的独特的。
很多人描述业务时，描述完业务背景就结束了，后面跟了一个技术架构设计，这就很奇怪。
有可能你思考了，但大家确实没有看到，给的太直接了，你需要给出一个思考逻辑和解题路径。
接下来就是方案权衡，我们知道一个问题对应的解法，往往是受限于它拥有的资源。不同阶段、不同资源背景下，你解决问题的效果就是不同的，手段也是不同的，需要结合手里的资源找到ROI合适的解法。
这个权衡的过程，其实就是解题思考，所有的权衡过程贯穿一个解题路径，把这个思考和权衡过程写出来，最终得出一个结论，我们要做一个什么事，那么目标就出来了。
这些权衡思考，其实功夫是下在平时的。
你平时做一些大项目的时候，就一定要把这些思考和权衡放进去。
比如你回过头看一些大项目，在文档中没有写业务背后的思考，就直接给了个目标，然后写产品应该怎么做，就结束了。
为什么要做没有写，怎么思考的也没写，什么原因都没写。如果一个参与执行的同学，对这些都一无所知，自始至终他都不知道怎么思考是对的，那么他怎么能拿出一个最合理的方案呢？怎么能保证最后不会返工呢？这个项目大概率也不会成功的。
目标是服务于业务发展阶段的，任何一个业务不同阶段目标都会有不同。
普遍来看，业务发展都可以抽象为三个阶段：产品化、数据化、智能化。
对应的系统能力的标准化，精细化运营的需求，借助智能手段，技术驱动业务。
不同阶段的业务，业务和系统的目标是不同的。
比如营销平台，在产品化阶段基本上是把产品做出来，同时提供营销计费能力、营销落地页统一管控、权益和传播、核销等基础能力，在配备一个对内的配置平台提升运营效率，产品化阶段的事情基本上就做完了。
数据化阶段，就是打通全链路的数据，做ABtest，通过各个维度数据看板看业务效果，甚至打造一个基于数据驱动的自动化分析能力。
智能化阶段，就是通过历史数据反哺业务迭代了，通过历史数据加业务结构化的规则建设合理的ROI模型，在营销前期做出最佳营销费用投入判断，收益最大化，就是算法模型告诉你营销怎么做效果最好，成本最低。
技术同学不要陷入技术自嗨的境地，做业务系统不要把思维停留在做高性能、高可用、高扩展层面上，要继续想这些做好了，对业务的帮助是什么，把收益落到业务收益上去。
一个技术的落地，往往是因眼前的问题而起，但肯定不是到此为止，而是要着眼于未来，面向未来设计。
一个系统架构图应包含四部分：
- 系统和外部的边界；
- 内部组件的上下左右的关系；
- 系统的非功能性设计；
- 系统面向未来的设计；
面向未来的设计，就要求系统负责人起码看到未来三年（或者一年半）业务可能发展的形态，是抽象总结业务表层问题，看到问题背后的本质，然后把本质和抽象归纳成领域模型概念，通过领域的分析思考，产出一个总的架构设计，也就是说要把未来放进你的架构。
总的架构设计完成之后，要具体落到细节上去，就是我常说的上天入地。
回归到业务阶段性的诉求上去，可以类似于时序图、服务类图、流程图等。这些方式有助于你落地工程，写代码，解释思考就可以了。
有人纠结自己做的系统深度不够，对于一些级别的同学来说，系统的复杂度是有要求的。
但系统复杂度不等于技术深度。
其实深度没有标准答案，往往因人而异。
技术深度可以简单理解成某一领域的专业技术壁垒。就是在你所处或者要解决问题的领域内，你积累的具备解决复杂问题或特殊问题的能力，这种能力最后被归纳成一套解决方案，这些可以被称之为深度。
比如网约车业务，拼车部分，怎么平衡价格敏感的用户和体验敏感的用户的拼车诉求呢？
最后的落地方案可能比较简单，但背后的思考过程，就需要你对这个领域有非常强的认知，就是你的深度。
千万别为了体现深度或者复杂度而过度设计，往往越复杂的事情，用简单的解法才能体现出你的能力。
述职中每个收益点的数字，你都要知道怎么来的，背后要有推演公式。
述职文档最后一部分往往是总结反思，本质上是和解题部分呼应的。是你做的这一件事的再总结，以及你在这个过程中获得的成长，具备的能力。
要有做的好的部分和做的不好的部分，做的好的部分大大方方的写出来，加粗描红。
做的不好的部分也大大方方的写出来，不然体现你思考的不足，如果一件事情回过头来重新做，肯定是可以做的更好的。
有了做的不好的部分，你才能写未来的规划，不然规划从哪里来。
QA环节，很多人PPT写的很好，讲的很好，但QA部分不好。
其实QA往往是一次述职中最重要的部分，比如前面PPT你可以找别人写吧，里面的素材可能是你抄别人的不是你的吧，可能是你老板帮你搞得逐字稿吧。
这些可能在QA环节你就暴露了。
因为再怎么包装，也就是外表的包装或者浅层次的包装，一旦问到一些有深度的问题，系统的思考，本质的东西，如果不是自己做的或者思考的不足，就会被问住。
做好QA，首先是把你这个述职素材里面的所有内容都要做到心里有数，并且平时有复盘整理思考的习惯。
整个述职过程要体现出你的可迁移的能力，比如不负责这个业务了，或者不负责这个系统了，你能带走或者在另一个项目上产生价值的点是什么。
是数据能力，洞察能力，项目管理能力，思考能力，还是抽象解决问题的能力，本质上是你通过这件事情，这段经历，获得了什么样的成长，这些东西不会被带走，会刻在你的脑子里。
可迁移的能力提升大致可以从这几个角度思考：组织协调能力、数据洞察能力、项目管理能力、复杂系统架构能力、团队管理能力、结构化思考能力、沟通能力、演讲能力等。
关于未来规划，很多人只想了一年之后的规划，更深入的话，会被问三年规划。
这个问题回答会比较难，首先你要知道业务的定位是什么，整个组织中这块业务的位置在哪里，需要完成什么样的使命，核心衡量指标是什么，核心领域的本质问题是什么，当前处于什么样的外部环境，核心业务和技术挑战有哪些，这些问题的优先级是什么，问题怎么解决，别人怎么解决的，自己和被人的优劣势分别是什么，当前资源怎么组织可以最大化解决这些问题，落地节奏是什么，需要哪些团队配合，可能的风险是什么等。
如果这些都想过且想明白了，那就是真想明白了。
如果你可以透过现象看本质，并基于未来做设计，并且中间逻辑自洽，有比较好的结构化表达，那么你其实已经超过80%的人了。
ppt形式，文字功底，画图和演讲技巧，能把问题可以清楚的说明白就可以了。
