职场新人述职报告心得
目录
〇、为什么要做述职
- 对外：表达能力也是综合能力的一部分，会做不会说，很吃亏，事倍功半。
- 对内：去不断地获得新的看待自己、看待业务、看待技术的视角。总结旧阶段，确定新阶段前进方向。
一、原则
- 基本：真诚，既是给别人做述职，也是对自己的审视与下一步指引
- 行文逻辑： 逻辑关系明确、层级划分合理、合适的总分关系、合适统一的加粗与变色
- 工作量衡量： 业务产出、技术产出（不要一个个按顺序列需求）
- 画图（表）： 一图胜千言！（产品背景图、架构图、用户交互图、代码类图）
- 重在平时： 平时做完需求养成阶段性总结的好习惯，等到要写年终总结的时候再想，一定会忘
- 排版： 不需要精美，但别丑，该对齐的对齐，错落有致
- 目录： 写完看一下目录，听众能否直接看目录就知道你要讲什么，目录的信息是太多还是太少
二、要素
- 体现产出（职级低堆工作量，职级高要紧密联系业务结果）
- 体现项目难点（技术）
- 体现业务理解（业务）
- 思考与成长：看到自己的成长，明确后续成长路线，让大家看到你的成长
三、模板
1. 个人基本信息
姓名、入职时间、学历学校、毕业年限、工作&实习经历
2. 工作概览
2.1 数据指标
利用公司的各种统计面板，大概贴一下数据，做了多少需求，代码行，bug率等等。
2.2 业务范围与职责
用一张产品架构图（基建类的就用技术架构图）来体现下面两个信息点：
- 项目背景介绍：整个团队在做什么
- 你是做其中的哪一小块（用虚线框起来、或者调整背景色），和整体的关联是什么，为什么重要/价值是什么
3. 工作内容与产出
不要全部列出来，3-4个足够，挑典型的。
何为典型？有以下几个判断标准：
- 看产出结果：结果指标好、公司需要
- 看难度（业务、技术、推进）
- 看喜爱度、参与度、收获、能不能讲清讲透
- 各种类型的都来点就更好
最好几个产出相互呼应，串联成一个整体，而不是分散独立的。（如果能有个图总览一下，点明几个产出的递进关系，就更好了，或者可以融合在 【2.2 业务范围与职责】的图里。
如果需求杂而多的话，尝试去归为几大类，找到几个通用的大背景，一个产出里面叠几个小需求一起讲。
3.1 产出一：xxx
以下内容可以灵活组织（可以删减、合并、改变顺序与层级、改为图表等等）
3.1.1 业务/需求背景
- 言简意赅，最好有图，站在听众的角度去思考，抹去不必要的细节
- 涉及多种用户角色的，把小人都画上，交互流程标上号
- 涉及与其他业务系统交互的，也都标上
3.1.2 目标结果
- 业务：产品让你做什么
- 技术：性能、架构升级
3.1.3 难点（先概述，再详细展开）
- 技术：技术方案设计难、代码实现难、性能要求高（量化分析）、技术债重
- 业务：建模复杂、历史业务逻辑复杂、思考通用与拓展性
- 严重性：系统容易崩、影响业务面、丢数风险
- 环境：测试难
3.1.4 解决方案
- 方案本身
- （画图！总分！抽象出技术难点的共性！能屏蔽细节就屏蔽细节！）
- 为什么这么设计、这么设计的好处、各种选型
- 考虑了哪些拓展点、通用性、面向失败设计、锁、索引等等
- 方案设计与改进的过程
- 还有哪些地方可以继续优化的（但是由于时间关系没做）
3.1.5 产出
- 业务产出：
- 产品使用体验：给图！（例如原来在代码中写死，或者在配置文件中的东西，你把它产品化了）
- 数据！！！！找合作的产品去要！（什么，产品没有数据，那下次需求评审的时候，就否TA的需求，让TA想明白，这个需求做了的意义是什么，以及如何用数据去衡量）
- 技术产出：
- 技术提升：给测试分析报告，贴数据
- 后续遇到类似需求，能够节省多少人力
- 降低系统风险
3.2 产出二：xxx
3.3 产出三：xxx
4. 各类杂项（目录层级自定）
4.1 团队工作
有的公司看重团队贡献，例如技术分享等等
4.2 业务理解
- 谈谈你做业务的理解，哪些做得不好，哪些可以去优化。为什么这个产品形态是这个样子，经历了哪些迭代的路径。反思自己是否知道产品的关键业务指标和技术性能指标？
- 需求
- 平时和产品的交流多吗？砍掉了几个需求？通过与PM交流改进了几个需求的实现方式？主动挖掘了多少需求？
- 注：并不是以砍需求为荣，而是与产品站在同一利益线上，去认真思考需求是否合理，如何更优。并不是砍了不做，而是给出不做的原因，或者达到根本目标的更优方案
- 这里贴一个我的需求反思表格，表头分别是：类型（优化、砍、简化需求）、需求背景描述、为什么不做/要做、我怎么做的、结果
- 业界相似的产品了解多少？
4.3 总结感悟
- 优点：共性的说起来没意思，说点自己不一样的
- 成长：
- 技术：
- 宏观：完成需求->思考选型与设计->以项目负责人视角整体看技术迭代
- 细节：看了什么源码、学会了什么组件、设计模式等等
- 业务：
- 宏观：完成需求->思考需求是否合理->主动提需求
- 杂项：排期能力（时间管理）、多任务并行能力、跨团队沟通能力等等
- 技术：
- 不足：
- 把你有信心且愿意改正的，放在最前面，并且真的去努力改正
- 思考（技术、业务）；
- 向外：整个业务、团队的现状、未来
- 向内：从每个需求中学到了什么（技术细节、开发流程、业务理解、沟通、多任务并行能力等等）
4.4 未来工作规划
大团队节奏 + 结合自身兴趣与想法
四、排版与画图经验分享
1. 双栏排版
超级超级好用！
- 原因：当我们结构化写作的时候，往往每个点不会排满整个横屏。而阅读是竖向的，就会显得很长。
- 操作：去把两个有【关系】的版块，放在一起展示
- 例子：
- 左侧是【难点与挑战】（标红），然后用无序列表1、2、3；右侧是【解决方案】，无序列表1、2、3，难点与解决最好一一对应。
- 左侧是【业务产出】，右侧是【技术产出】
- 左侧是【优化前】，右侧是【优化后】
2. 画图经验分享
2.1 画图的关键要素与流程
- 边想边画： 只知道内容，关系暂时没总结出来，先填充细节再归纳整体，如下：
- 想好再画： 知道层级结构、逻辑关系。上面图的中间三步反过来就行，先确定整体再填充细节，即层级->关系->节点。
2.2 如何提高画图水平
- 多看图：积累各种模板（业务架构、技术架构、用户交互、时序图、泳道图、UML等等）
- 多看经验贴：如 技术文章配图指南
- 多实践、多调整，就像写代码那样，多写，写完不断重构优化
2.3 画图工具推荐
- 强推飞书画板（文档写作也建议用飞书文档） ：使用简单、基本模板够用、分区与排版功能强大
- excalidraw：
- 优点：手稿式画风、支持 Vscode插件（然后就能通过 Git 去管理自己的图）
- 缺点：图一旦复杂起来，体验直线下降，尤其是线条与形状的选中范围逻辑
- draw.io: 用的不多，挺多人在用的