如何描述自己的工作
如何描述自己的工作¶
统计信息：字数 8054 阅读17分钟
原作者张鑫旭，原文地址：https://www.zhangxinxu.com/life/?p=1384
一、背景¶
本文内容虽然不多，但是对于大家的职业发展，尤其新人却很重要。
无论是晋升汇报还是简历求职，都需要对自己的工作进行描述，然而，根据自己的观察，很多人对自己工作的描述非常糟糕，关键是，这些糟糕之处本人是意识不到的。
所以这里，就希望通过几个例子，给大家讲讲如何更好地描述自己的工作，帮助大家做好临门一脚。
大家可以看下面这张图，是截图自某个简历的描述。
乍一读，似乎没什么问题，然而实际上上面的工作描述问题很大。
二、问题剖析¶
首先，讲一个原则：
“描述自⼰的⼯作千万不要沉浸在自⼰的世界里！”
因为你描述自己工作不是写日记，是要让别人评判的。
Part 1¶
例如这句话：
“逻辑清晰，能够构建负责的应用程序”
这就是一句没有任何意义的废话。
你说你逻辑清晰，那是你自己的感觉，有意义吗？
路上随便抓一个人，你问他，你觉得你逻辑清晰吗？100个人99个人会说自己逻辑清晰的。
所以自我的评价并不能作为你本身能力的认可。
记住这句话，在工作描述中，举证⼈所有感性的自我描述都没有任何价值！
再看后面这句话，也是沉浸在自己世界中导致的糟糕描述：
“开发某某项目期间，负责云服务器资源购买、服务器变更配置、新增配置等页面的开发，自定义购买的选配逻辑是整个项目最复杂的地方，在保质保量完成的情况下，并协助同事修复bug”
糟糕在什么地方呢？
就是说了很多很多，其实并不能说明自己是个很厉害的人。
原因很简单，因为上面的工作内容交给在座的任何⼈都可以完成，买卖服务器，然后配置，这属于脏活累活，但并不是那种高技术门槛的工作。
这里，举证⼈自认为花了⼀番功夫完成了一个具有挑战的东西，但是横向对齐其实并没有优势。
这里也是类似的，做一些运维相关的工作，并不能证明自己多厉害，在这段描述中，真正有价值的，或者说有区分度的表现是“主动性”，这是一个优秀员工的特质之一。
因此，上面这段话，还不如这句话：“⼯作之余主动承担云服务器购买配置等运维相关的边界⼯作”，足够了，无需描述细节和困难，因为那些困难只是苦劳。
Part 2¶
第二段前半句：
“能为业务方和初级工程师答疑解惑，或提供技术方案”
这句话属于没有讲好的亮点。
“能为”，这个词实在是太失败了。
工作描述中有一些词是禁止出现的，包括：能够为、我觉得、较大提升、应该。
例如这里，“能为”指有能力做这样的事情，关键做没做并不知道，明白了问题在哪里了吗？
小明虽然技术一般般，但是帮助新人解决了很多问题；大明虽然技术很厉害，但是并没有技术输出。请问，哪个才是更好的员工？
更重要的是，上面的表述并不能说明自己专业能力很厉害，因为技术一般般的人也是可以为他人答疑解惑的。
其实，我是知道的，举证人是想说自己会帮助他人答疑解惑，技术选型决策者。这个时候，应该通过具体的数量和具体的业务场景加以描述，这个后面会有举例。
再看后半句：
“在维护用户登录项目期间，为业务方提供平台登录的技术方案，特别是正在一级域名不同时的跨域登录信息同步的实现上，通过绘制流程图以协助理解相关逻辑，从而提供技术支持。”
举证人是想表达自⼰专业技术强吗？可强在哪里呢？
又是一个自我感觉良好的解决某个技术细节的案例，这个时候，只要跳出自己的视角，稍微看看，也知道这个描述很糟糕，并不能体现技术厉害，反而让人觉得此人技术不行，这么点技术实现就拿出来沾沾自喜，说明是个半瓶水。
这句话还不如下面这样的描述：
“我写的技术⽂档比别⼈溜，会绘制美美的流程图（放个用户登录项目的流程图示意下）”
虽然不是什么显著的加分项，但至少是个可圈可点的亮点。
Part 3¶
下面这句话的问题更具有代表性：
“对于产品和技术实现⽅案有自⼰的看法，特别是在某些设计上和太合理时，积极表达意见并积极探讨，共同寻求最优解”
请问大家，上面这句工作描述的问题在哪里？
我们不妨对比一下以下两种不同的工作描述：
符合左边描述的员工，说不定是个“喜欢吐槽设计，喜欢主观表达，寻求认同和存在感的前端开发”，是个糟糕的员工。
而符合右侧描述的员工，一定是真正可以对产品带来改进，有推动⼒的前端，是个⼈才，因为有理有据，有故事有场景，多么令人信服。
所以，之所以工作描述要规避感性的描述，是因为弹性和水分实在是太大了，我这么讲大家可能内心没有什么直观的感受，来看一个例子，下面是张三和王二参与紧急改版项目写的工作总结。
两个人的工作总结都没有说谎，请问，你觉得那个员工更优秀些？
如果单看两位的工作描述，会觉得两人应该差不多，可能王二更好一点。
如果你也有类似的感觉，那就对了，说明上面感性的工作总结就是一坨屎，大忌，非常糟糕。
实际上，这个项目的工作情况是这样的：
大家可以仔细对比实际工作情况和对应的工作描述，看看，是不是没有任何说谎？
但是，两人的工作表现其实天差地别，王二就是个混日子的半吊子，结果单看工作描述，好像也很不错！
所以，有经验的面试官或者领导，在面对那种含糊其辞的描述的时候，都会打一个大大的疑问，相关信息并不会被采纳，因为水分太大。
正确的做法是数据说话，例如，张三的工作描述如果是“90%的页面和代码都是自己重构的，95%的文档都是自己写的”，显然就不会被误认为和王二平分秋色了。
这个可以通过 github 上面的提交比例和代码量说明（不同子项目可以拆开叙述）
STAR法则¶
对于工作描述，STAR法则也是适用的，STAR法则具体如下：
Situation: 事情是在什么情况下发⽣
Task: 你是如何明确你的任务的
Action: 针对这样的情况分析，你采⽤了什么⾏动⽅式
Result: 结果怎样，在这样的情况下你学习到了什么
这个在晋升汇报中尤其适用，对于简历描述，由于篇幅有限，可以直接重点放在Result上，数据说话，作品说话，所有描述可佐证，有理有据，千万不要出现我觉得，较大提升，明显优化，可以，能够这样含糊其辞的表述。
而恰恰大多数人忽略了Result，简历中大量篇幅描述自己做了什么，优秀的团队总是希望新员工不仅能干活，而且能够干好活，所以，要想去优秀的团队，简历中一定要突出好的结果，注意横向对比。
三、总结下¶
如何更好地描述自己的工作？
- 跳出⾃⼰的视⻆
- 少感性描述、数据说话
- STAR原则，重视Result
- 重视日常的总结、⽂档以及月度汇报的书写训练