del

极客时间专栏/geek/职场求生攻略/职业素养篇/01丨优先级：工作中那么多事情，我要如何安排优先级？.md

@@ -0,0 +1,103 @@
+<audio id="audio" title="01丨优先级：工作中那么多事情，我要如何安排优先级？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/ca/08/caafad7ff6a256725877210d716a9408.mp3"></audio>
+
+你好，我是臧萌，这篇文章是专栏的第一篇，我们以工作中的优先级这个话题开始。我们在日常工作中，总会这样感慨：事情，是干不完的。
+
+既然干不完，那我们就要分清轻重缓急，哪个重要，哪个不重要，给它们划分一个优先级，这样不至于让自己手忙脚乱。
+
+能给手头的事情排上正确的优先级，是一项很重要的工作能力。
+
+当然，我们在生活和学习中，事情也可能不少。但是和工作中的优先级相比，生活和学习里的事情是我们自己的事情，只要安排得让我们自己满意就可以了。在工作中，事情的优先级的标准，是要让公司受益，让老板满意，让同事认可。
+
+首先呢，我们先谈谈优先级为什么重要。
+
+## 优先级的重要性
+
+我工作中有一段时间，就经常被工作的优先级所困扰，经理也时不时地批评我：“这个事情这么重要，你怎么到现在还没开始弄？”我心里也有点憋屈：“我又没闲着，我做的事情还不都是经理安排的么？”
+
+这里有一个很重要的字眼——重要。
+
+优先级有很多的考量，并不是简单的先来后到的线性时间顺序，我们需要根据事情的要紧程度安排优先级。
+
+还有一个需要考虑的因素就是程序员的工作性质。对于软件工程师来说，一个事情可以用一天的时间做完，也可以用一个星期的时间精心打磨。如何在时间有限的情况下安排自己的时间，让时间用在最值得做的事情上，就是排优先级需要考虑的内容。
+
+给不同的工作安排优先级，不仅会让我们的工作效率更好，也可以让我们和同事之间达成良好的合作关系，为什么这么说呢？且往下看。
+
+## 如何给工作排优先级
+
+首先，我们可以从两个维度去给工作划分类型，一个维度是工作本身的性质，另一个维度从合作角度出发，然后根据这些工作的重要与否安排优先级。
+
+### 基于工作性质安排优先级
+
+基于工作本身的性质，我把工作划分为公司发展计划、安全相关的事情和生产上的事情。
+
+每个公司都有自己的发展计划，并给这些计划划定不同的权重，以指导协调公司内有限的资源。
+
+拿我所在的公司来说，每年公司高层都会制定当年的发展目标，然后以此为依据，制定不同的发展项目，再根据项目，一层层地将项目分解为各个部门的子项目等等。每个部门，以顶级项目的优先级为参考，安排自己的资源，以达到公司的发展目标。
+
+我们程序员作为公司人员组织的基层员工（我习惯称为叶子结点），自然不需要操这么大的心。但是我们需要了解公司的发展方向和重点项目。一般来说，公司的发展目标和与之相关的各个项目的优先级都会对内公开，公司也鼓励所有员工都熟悉这些内容。当和这个项目相关的工作安排到自己手里的时候，一定要给予这种工作足够的优先级。
+
+同时，这种重要的事情，最好多花点时间在上面，力争做到最好。因为这种重要的事情是拖不起的，如果因为没做好拖累整个项目的进度，可能会影响自己甚至整个组的表现（performance）。
+
+我们再来看看安全相关的事情。
+
+“安全无小事”这个口号在所有工程类的工作中都适用。软件开发里的安全问题虽然不会直接影响生命安全，但是它会带来很大的经济损失和商誉损失，现实中各种数据泄漏的例子不胜枚举。
+
+我随便举个Java的例子。在JDK 的早期版本中，有一个执行任意代码漏洞。Java可以启动新的进程，执行任何命令，方式是使用Runtime的exec方法，传递一个命令的String数组。这个漏洞在于，它先检查了String数组里的命令是否允许被执行，然后再遍历数组，依次执行每条命令。而在多线程环境下，完全可能在检查完毕后，数组里的内容又被别的线程恶意更改了，改为不应该通过检查的命令。这样的话，一条本不应该通过检查的命令，就这样被执行了。
+
+作为承担着软件开发和运维工作的现代程序员，我们首先要遵守安全部门的安全规范和检查，这就好像进入工地要戴安全帽，是没得商量的。
+
+安全部门有时候还会发布紧急安全升级等要求。比如升级有安全隐患的jar包/组件等，这时候，我们一定要把这个当作优先级最高的任务，不要有任何的犹豫或轻视。
+
+站在我们程序员的角度想一下，一旦出了安全问题，如果是因为自己执行不到位，这个责任肯定是要自己承担的，即使后期再怎么弥补，也无济于事。
+
+试想一下，如果你没有配合安全部门的任务，导致一个有漏洞的 jar 包被利用，造成了数据泄漏。即使接到任务的时候你没有闲着，甚至为了完成业务开发挑灯夜战，但你觉得业务的人会为你说话，替你挡箭背锅吗？
+
+如果你不确定，那么就换位思考一下吧。如果你是业务方，给开发提好了需求，进度也排好了，结果忽然开发组跟你说，因为做你的项目，导致我们没时间做安全升级，造成了公司损失，你要背锅。你是不是觉得这锅来得匪夷所思？
+
+安全部门的要求就是最高的要求，是一切需求的“挡箭牌”。当一个安全部门给的任务到了你手上，告诉经理你要放下手中的工作，立刻开始执行安全任务吧。这既是为了公司，也是为了自己。
+
+除了安全问题需要注意外，我们还要注意生产上的问题。
+
+如果生产出了问题，那么作为 DevOps 的程序员，要第一时间放下手头的事情，冲上去搞。理清问题之后，马上开始行动。生产上的问题都是火烧眉毛。火烧眉毛的时候，你会等着别人给你送水，还是自己想尽一切办法找水呢？当然是自己找水了。如果需要别人配合，马上联系相关的人或者其经理。
+
+### 基于合作安排优先级
+
+讲完工作本身的性质，我们再来看看那些需要跟别人合作的事情，毕竟有人的地方就有沟通，如果优先级没有排好，那就很容易导致沟通不到位，出了纰漏，就很麻烦了。
+
+在日常工作中，我们有很多任务都是经理下达的。经理往往掌握着更多的信息，也更能判断一件事情的优先级。现在一般都是敏捷开发，经理会给每个story排优先级。在给任务排优先级的事情上，程序员可以提建议，也可以和经理讨论，但是一定要以经理的决定为准。
+
+还有一些经理临时安排的事情，这种事情有时候更急一些，可能也不用耗费很长时间。所以这种事情也要先做。
+
+如果一个事情需要别的部门配合，那么优先做。比如申请资源，和自己的上游讨论需求等等。这样一方面可以让别人尽早开始工作，另一方面也可以尽早交换信息，避免日后翻车。
+
+举个简单的例子，如果有一个需求依赖上游服务。那么在自己这边需求明确的情况下，你要尽早和上游的组通气，看自己的需求能不能做，排期是怎样的。如果自己觉得没问题，先开展自己的工作，结果上游那边无法做或者无法排期，那工作就彻底翻车了。
+
+如果事情没有太明显的轻重缓急，那么换位思考，与人为善，优先做那些阻塞了别人工作的事情。有些事情是来自组内的，有些来自组间合作。良好的合作关系就是这样一点点打磨出来的。
+
+## 做事情本身的优先级
+
+给工作排好优先级之后，我们还要注意工作内部各项事情的优先级。工作需要拆成不同的步骤来实施，这些步骤也有优先级，其实基本道理和我们上面讲的都一样。
+
+我举一个开发新功能的例子。开发新功能可能要申请机器，要找上游谈依赖，要开发代码，要找下游谈需求，要和上下游联调接口等等。
+
+你看，这里有“申请机器”“找上游谈依赖”“找下游谈需求”，那么这个时候，申请机器和找上游就是应该尽早开始的。同时，接口和联调也应该尽早开始，接口具体实现的代码不需要写得那么完善，甚至mock一些过程也是可以的。这样一方面可以和上下游尽早落实集成的细节，另一方面也可以尽早将阶段性的成果展示给需求方，随时review，避免最后来个大“惊喜”。
+
+我们做事情的时候，如果能把其中的每一步都想清楚，理清依赖关系，安排得井井有条，这就已经事半功倍了。
+
+## 总结
+
+我们的工作繁杂而琐碎，今天我也仅仅是给出了一些通用的建议。在不同的工作内容，工作岗位上，可能有不同的维度。但是需要牢记的是，当你觉得自己工作手忙脚乱的时候，不妨停下来，先理理自己手头工作的优先级。怎么整理优先级呢？这里我给出一个简单的方法。首先把所有的事情列出来，然后对每件事情问自己两个问题：不做这个会怎么样？做了这个能怎么样？剩下的事情，就是顺着这个思路走下去了。
+
+其实，给工作排优先级，不仅仅是一个提升工作效率的方法，也是提升自我和磨合团队的重要方式。
+
+程序员的工作不只是低着头写代码，也不只是别人让干什么就干什么。给事情排优先级，是一种能够帮助把事情做对，做成，做好的重要能力。它不仅需要你对事情本身有准确的认识和判断，还需要你有清醒的思维，能够将事情分解，按照最优的顺序执行。给工作安排优先级的过程，也是锻炼自己能力的过程。
+
+进一步说，这种能力更是一名经理的必备能力。经理的很大一部分任务就是理清事情，排列优先级，让自己的手下去做事情。程序员能控制的就是如何安排和使用自己的时间，而经理要对手下所有人的时间负责。所以经理眼前的事情更多，关系更复杂，需要做的判断也更重要，对这个能力的要求也更高出好几个层次。所以如果你有转做管理的计划，不妨在这件事情上多花点心思吧！
+
+<img src="https://static001.geekbang.org/resource/image/2b/ac/2be0c0b0ebcd3b8a9fc0a2051f65ccac.jpg" alt="">
+
+## 思考题
+
+我在开头中提到了我刚参加工作时的窘迫，你有过我当初那种“我明明没闲着，却被经理说做事情不得力”的委屈和困惑吗？你现在走出这种困惑了吗？
+
+欢迎你在评论区和我讨论，也欢迎把这篇文章分享给你的朋友或者同事，一起交流一下。

极客时间专栏/geek/职场求生攻略/职业素养篇/02丨沟通：邮件那么重要，你还在轻视邮件吗？.md

@@ -0,0 +1,113 @@
+<audio id="audio" title="02丨沟通：邮件那么重要，你还在轻视邮件吗？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/0e/83/0e5f16a5e6504ba16ca195c838a73083.mp3"></audio>
+
+我刚毕业开始工作的时候，是比较讨厌邮件的。面对面聊不好吗，异地的话打电话不好吗？但是现在，我和组外的工作伙伴说得最多的一句话就是：“好的，你发封邮件给我吧。”有时候会再加一句，“抄送我老板”。
+
+嗯，成功变成了自己当初讨厌的样子。为什么呢？
+
+其实工作多年的人都隐隐理解邮件背后的含义，但是不会明说。我有一位前辈在某次组内会议的时候，直接捅破了窗户纸：“邮件不是用来沟通的，它是用来撕扯和甩锅的。”
+
+为什么这么说呢？让我们先从邮件的功能开始说起。
+
+## 邮件的特性
+
+在我看来，邮件有三个重要的特性。
+
+1. 异步交流：邮件是一种异步交流的方式，双方有足够的时间准备邮件内容。
+1. 无法修改：邮件内容无法修改，这是邮件可靠的基石。
+1. 方便扩散：邮件有邮件组，可以很方便地把相关人员加进来，并且保留邮件历史记录。
+
+## 邮件是公司内部的合同
+
+下面我们开始聊有意思的。邮件，其实就是一种简易版的合同。在这里呢，我们来模仿电商公司两个组之间的一次合作，以此来看看邮件在整个过程中的作用。
+
+### 情景介绍
+
+业务组负责开发业务，对接和集成上层产品线，配合运营做营销活动等。基础服务组负责提供基础框架和服务，蹭个流行一点的词，就是中台。这次的功能是购物车，需求一层层传递下来，基础服务组需要提供一个“购物车功能”给业务组使用。
+
+#### 场景1：设计确认（邮件的“确认”功能）
+
+购物车的需求设计等等需要一个接一个的会议讨论。当然，需求最后也要用文档的方式确定，并且通过**邮件**的方式通知所有相关人员。邮件这种异步沟通的方式，其实就是给双方足够的时间去细细地看，不催着你立刻给一个确定的回复。邮件可以随意加人，如果有任何疑问，可以随时把相关人员加进邮件线程（email thread）。
+
+我们工程师作为实际干活的人，有问题一定要提出来，或者和组内讨论，或者在邮件讨论。关键的点可以在邮件里确认，比如购物车的数据是保存在服务器端，而非session中。
+
+如果你收到邮件又不说话，那就是默认。
+
+如果没有问题，相关人员（比如经理、技术经理、功能主程、双方对口人之一）应该礼节性地回复一个赞扬的邮件，内容不重要，重要的是这封邮件代表你已经同意邮件内容了。注意，这点很重要：同意。这时候，双方相当于签订了合同，合同内容就是大家对购物车功能的共识。
+
+购物车功能的需求清楚了，开发周期有个差不多的数字了。经过双方估计，基础服务组大概需要10个人做两个月，一台标准服务器可以服务10w活跃用户。
+
+#### 场景2：优先级（邮件的“证据链”功能）
+
+这时候第一个扯点来了：优先级。按照这个预估的工作量，基础服务组之前排好的工作计划就要重新排。但是基础服务组之前已经排好的需求，也大多为了业务组服务的。这个球就踢到了业务组：是把已经排好期的某些功能往后推，还是把购物车功能往后推？亦或者暂且简化购物车的功能，压缩工期到5人一周（比如把购物车保存在session里）？钱多优先级都高的话，可以借人或者招人。双方的经理可以开会，拉上各种相关人员做出决定。业务组内部肯定也会有不同的声音，如果之前的功能排期被挤掉了，肯定会影响业务组一些人的工作。
+
+所以，这时候得出的结论，一定要通过邮件的方式让业务组老大发出来确认。
+
+无论是推迟已经做好的计划，还是简化购物车功能，都可能带来潜在的业务风险。邮件的作用就是允许人在深思熟虑之后，通过邮件的方式宣布决定。这时候，这封邮件就是合同。同样的，基础服务组也要履行自己的承诺，10个人，2个月，做出之前设计的购物车功能。
+
+如果业务组老大的决定是推迟已经安排的功能开发，若是因此被竞争对手抢走了很多用户，那么业务组老大要承担大部分责任。开撕的时候，这封邮件就是依据。同样的，如果2个月没做出购物车功能，这个锅就要算在基础服务组头上。当然，有些时候项目延期，并不会导致明显的损失（软件行业开发延期再正常不过了）。所以这份合同，会不会被用来当做开撕的证据，不好说。但是我们在公司做事，还是要严谨稳妥一点，别在邮件里承诺自己没有把握的事情，力争做到“没事儿Be Nice，有事儿必耐撕”。
+
+#### 场景3：大促（邮件的“沟通协调”功能）
+
+接下来公司搞大促了。沟通从运营一路到业务，到基础服务，到运维，到预算批准，到服务器上线，服务部署等等，每个操作都需要相关的组给出明确的操作细节和时间节点，比如大促的时间、峰值人流、持续频率、活动地区（全国还是某些省市）等方面的数据，都需要相关的组在内部充分沟通之后，以邮件的方式确定。各个组之间通过邮件的方式签合同，用邮件组等方式确定各个组和人员都得到了相同的信息。
+
+每个组各自背负好各自的责任。
+
+#### 场景4：新业务接入（邮件的“防遗忘”功能）
+
+紧接着，公司别的业务也要接入购物车了。对基础部门的你来说，改动可能就是增加一个配置。但如果业务组的人过来找到你，说：“哥们，购物车功能棒棒哒，我们安卓的应用也要用啦，给加个配置呗。”你脑子一热说：“好好好，立刻就加。”
+
+那么这种沟通，就是双输。
+
+为什么呢？
+
+对业务组来说，他们并没有得到一个上线的保证，只是你的一句口头承诺。而你可能一忙，转头就忘了。如果业务组立刻着手进行安卓的购物车集成，结果上线之后发现你这边还没改配置，这就是车祸现场。
+
+对你来说，如果你真的立刻做了这个事情，组里没有人知道，非但无功，而且有过。配置的修改，至少要对流量有个预估吧。而这些数据，包括上线时间，还是需要用邮件的形式做出正式的沟通和确认。还有很重要的一点，一个组要做的事情，需要在组内告知，因为组员都可能会修改这个服务，万一有对安卓不兼容的改动而你不知道，上线之后依旧是车祸现场。当然组内的沟通，可以不通过邮件这种方式。
+
+#### 场景5：技术升级和Bug修复（邮件的“广而告之”功能）
+
+接下来是基础服务组要对服务做改动，可能是一个Bug的修复，也可能是技术升级，比如增加一层Redis缓存。发布的时候，服务的可用性可能会受到影响。作为基础服务组的你，如果只是走到业务组那边，找个相熟的人问：“哥们，今天晚上我们做个升级，购物车大概停服一个小时。”你哥们也很“够意思”，说：“木有问题。”那么你们俩就都掉坑里去了。
+
+你这个哥们可能不知道全组的情况，可能组里有些项目今天晚上正好要用到购物车服务。万一出了事情，俩人就都得歇菜。所以和上面的情况一样，还是要用邮件加邮件组，充分告知足够的人，而且提前足够多的时间（比如三天），让大家都能得知变动的计划详情。
+
+## 邮件的魅力
+
+到这里可能你会觉得心好累，为什么有这么多算计，为什么不能干就完了。其实，**这不是算计，这是负责**。邮件是正式的沟通渠道，一封邮件如同一份合同。我现在为什么张口闭口让别人发邮件给我，因为别人张口就来的需求，可能并没有经过深思熟虑，也可能没有经过他们组内部的讨论。我让对方发邮件的初衷，就是让对方好好思索和沟通好之后，给出一个正式的需求，而不是草草地开始做事。
+
+同时，邮件确认了，做不好就要负责，也就是“背锅”。**我们都是普通人，普通人没有“背锅”的压力，就没有持久的把事情做好的动力**。你品，你细细品，我们是不是这样的人。
+
+## 邮件的小技巧
+
+我在上面说了很多，模拟了一个场景，既想让你了解合同的重要作用，也想让你知道合同的正确使用方式。那么在这里，我再给一些使用合同的小技巧，或者注意事项，希望对你有帮助。
+
+#### 定期查看邮件
+
+既然是要使用邮件，那我们就要定期看邮件。不要觉得这个建议很不起眼，事实上，我刚开始工作那几年，经理经常跟我说这句话。因为那时候的我还时不时地会漏掉公司的一些公告信息，以及别的组请我们帮忙的邮件。这就很尴尬了。所以一定要养成定期查看邮件的习惯。
+
+#### 发送邮件的小技巧
+
+回复或发送一封邮件的时候，看清收件人有哪些，再决定自己该说什么。
+
+首先要学会抄送老板。如果想催促进度，就抄上对方的老板。如果觉得自己搞不定，记得抄上自己的老板。
+
+其次要用好邮件组，该加人的时候加人，比如某个组的邮件列表，某个部门的邮件列表等。做到应通知，尽通知。避免只通知某个组的某个人，以免这个人对邮件中的事情有误解或者漏掉了信息。
+
+如果你的邮件收件人比较多，那就记得**多检查一下邮件内容和标题**。版本公告就是个例子，每次都是复制上一次的模版然后修改一下。我曾经不止一次忘记改标题或者时间，虽然没直接影响，但是会让人觉得你不仔细（本来就不仔细囧）。
+
+#### 写会议纪要
+
+如果是和自己相关的会，开完会之后一定要记得发一封会议纪要，给所有参会人员。会议纪要可以总结这个会上得出的共识，列出下一步可以采取的行动，保证这个会上得出的成果不会被遗忘或者被误解。
+
+## 总结
+
+我今天讲有关邮件的一些内容，比如邮件的功能、使用技巧等。其实你也能看出来，邮件不只是一个沟通的渠道，而是一个正式的，签合同的渠道。现在很多公司也在积极的使用更高效的工具代替邮件的功能，但是本质是一样的。
+
+因此，在正式的工作使用场所中，我们要牢记使用邮件的注意事项，这样一来可以避免工作沟通带来的问题，二来也可以帮助自己梳理工作任务。
+
+发邮件要有仪式感。邮件只是一种形式，如果公司不使用邮件，也会有一种正式的沟通渠道。好好利用它，祝大家工作愉快。
+
+<img src="https://static001.geekbang.org/resource/image/fa/fc/fafa86315896fe947c68eaf1872bdcfc.jpg" alt="">
+
+## 思考题
+
+你在使用邮件的问题上，有过哪些疑问或者故事吗？欢迎在评论区讨论，我会和你一起交流，也欢迎你把这篇文章分享给你的朋友或者同事，一起交流一下。

极客时间专栏/geek/职场求生攻略/职业素养篇/03丨沟通：程序员为什么应该爱上交流？.md

@@ -0,0 +1,130 @@
+<audio id="audio" title="03丨沟通：程序员为什么应该爱上交流？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/28/e1/282fa7402e381c036901223825ee0be1.mp3"></audio>
+
+程序员这个群体最开始被社会认知的时候，标签之一就是不善交流。慢慢地，“喜欢玩电脑，不喜欢和人交流”成了大家对程序员的一个刻板印象。作为程序员，我发现工作的时间越久，承担的责任越大，那么交流是一个越来越重要的能力。
+
+在这一讲里，我们就来聊聊程序员如何进行高质量的交流。当然了，你可能会想，我不喜欢交流照样工作得很顺利，可是，交流带来的好处也就体会不到了。
+
+当然了，在开始前，让我们先想想，为什么我们会不爱交流呢？
+
+## 为什么程序员普遍不喜欢交流？
+
+其实，是不是喜欢和人交流绝大部分是由性格决定的，和职业无关。可能程序员这个行业，相比其他行业，吸引了更多的不喜欢交流的人吧。但是除了性格之外，确实有些客观因素影响了交流的积极性。
+
+### 工作被打断严重影响效率
+
+我觉得这个绝对应该是排在第一条的。和人交流一般需要约好时间，到了时间不得不放下手头的工作。有时候也会有人主动过来，随便聊点东西。无论是哪种形式，其实都会打断程序员当前的工作。
+
+而所有的程序员，都非常讨厌自己的工作被打断。
+
+### 交流不能直接帮程序员完成工作
+
+网上有个段子，说程序员和产品经理在开会，讨论到下班才结束。产品经理一看正好到点了，就欢欢喜喜地闪了，留下程序员拿着需求挑灯加班。
+
+会议结束之后，程序员的工作才算真正开始，从利益的角度来说，也难免我们会抵触这种不能帮自己直接完成工作的交流了。
+
+程序员其实只是交流中的“利益受损者”，我们排斥的不是交流本身，而是厌烦交流中时间的“浪费”。
+
+当然，面对面的交流只是一个例子，其实写文档、回邮件、做演示等等都一样，都让程序员感觉是“浪费时间”。
+
+简单来说，没有无缘无故的讨厌。别管程序员嘴里怎么说，心里其实明白，归根结底，还是因为我们觉得这些事情影响了自己的“利益”。
+
+## 爱上的第一步：正视和人的交流
+
+如果交流有损程序员的利益，那为什么我们还要交流呢？我就写我的代码，写完下班不是挺好的吗？其实这就涉及到一个长期利益和短期利益的问题了。短期来看，少参加一个会，少和人聊两句业务，少被人打断几次，从一个星期的维度看，可能工作确实完成得更快了，加班更少了。
+
+但是从长期发展来看，缺少交流的程序员，很难发展为公司的骨干，升职加薪可能都会被排在后面。我们的工作，真的不止眼前的程序。
+
+在做事情的时候，优秀的交流能力是必须的。如果你能够展示自己在交流能力上的优势，组内外的同事也更愿意和你合作，经理也会优先考虑让你承担更多的责任，对自己的发展有很大的好处。
+
+我认为，交流的好处可以从两个方面来说，一个是输入，一个是输出。
+
+### 输入
+
+我们都说要创新，要整合资源。其实要想做到这一点，在一个公司里实现成长，就要时刻保持自己获取信息。如果能够重视平时的交流，交流的时候多主动思考，慢慢地，自己收获的关于公司和行业的信息也就越来越多，没准还就能够找到新的突破点，抓住新的机会。
+
+机会都是自己争取的，这句话看似鸡汤，但是背后的道理一定要明白。没有哪个创新是空中楼阁，在现代社会闭门造车也很难成功。只有足够的信息可以在脑子里碰撞，创新的火花才更有可能出现。在外人看来的灵光一闪，背后可能有很深的积累。
+
+### 输出
+
+现在已经不是一个酒香不怕巷子深的时代了。自己的想法，自己的工作成果，都应该积极主动地向外界输出。输出不一定是什么长篇大论，可以是简单的交流、发邮件、写文档、做工作成果演示等等。通过输出，我们才能慢慢赢得自己的声誉，树立自己的影响力。
+
+### 养成主动交流的好习惯
+
+当我们意识到交流的重要性之后，就应该慢慢养成主动交流的好习惯。
+
+交流不一定要是非常正视的形式。我们可以闲聊，趁着吃饭或者散步的时间，主动和组内同事，和自己的经理，和自己上下游的关键联系人交流自己的想法以及正在自己做的事情，然后也从对方那里获取相应的信息。
+
+不要让自己做一个小透明，做的事情要让别人知道。同时，也知道别人在做什么，别人遇到了什么问题。别人的问题，就是你潜在的机会。
+
+当然了，我们也可以通过分享会的形式，进行正式演示。这种演示一方面可以展示自己的工作成果，另一方面也可以听取别人的意见，看看自己的工作如何能给更多的人带来价值。
+
+前面说到的交流多偏向于信息交换。其实日常工作中还有很多交流都是为了解决具体的问题。从技巧上而言，这两种类型的交流并没有什么区别。
+
+## 程序员交流的技巧
+
+### 换位思考，注意受众
+
+其实人和人之间交流最重要的一点就是换位思考。站在对方的角度理解自己表述的内容，看看能否被正确地接纳和吸收。程序员是一种专业性很强的工种。很多专业技能相关的内容，可能会让非专业人士摸不着头脑。大到一个公司，一个部门，小到一个组，一个项目，都可能有很多专有名词，专用词汇，需要很强的背景知识。
+
+所以我们在交流的时候，首先要进行快速的角色转换，找到对方和自己认知的“最大公约数”，英文叫做“on the same page”。然后对于交流中需要补充的知识做简单的介绍，比如系统特点，专有名词的介绍等等，避免受众一路带着问号听你说，最后对话变成了“鸡同鸭讲”。
+
+举个例子。如果我们发现上游的订单数据有问题，那么我们可能需要找同组的人帮忙看。这时候，我们可以找组内相关的同事说，帮忙看看订单的数据是不是有问题。组内的同事对系统都是很熟悉的，不需要交代太多上下文。
+
+如果我们发现确实是上游的数据有问题，有些字段缺失了，需要上游系统配合帮忙查找问题。这时候可以发邮件给上游系统。我给出两个邮件标题，你觉得哪个更好呢？
+
+1. 订单数据在OrderProcessor引起异常
+1. 从3月15日起，来自Kafka的订单数据，缺失了OrderingTime，OrderName字段
+
+第一个标题，明显没有分清交流对象。OrderProcessor是自己组内项目的代码，这明显不是两个组的责任交界。数据在进入OrderProcessor之前，还有很多步骤，不能确定是上游发的数据的问题。难道你想让上游的组去看你的代码，帮你找自己代码的问题吗？
+
+第二个标题，很清晰明确。上游数据发到Kafka，这是大家责任的交界处。时间，问题也都交代得很清楚。上游的组完全可以以此为起点，向后查找自己的问题。
+
+简单来说，既要让对方听明白，也要让对方听到自己应该听的。交流不是应付差事，说完拉倒，也不要只顾自己说。
+
+### 交流要带有足够的信息
+
+我们来看一个教科书般的交流失败的例子：
+
+A问：“订单信息数据在HDFS上有吗？”
+
+B说：“有。”
+
+B的回答没错，但是也没啥用。A的问题明显是想知道订单信息在HDFS的具体位置，而非只是有或者没有。B如果知道具体在那里，就应该一并告诉A；B如果不知道，也应该回答“有，但是我不知道在那里。”如果B知道谁可能会知道，那么应该一并告诉A。这样，一次交流，基本就可以结束了。
+
+再以上面订单数据的问题举例。使用了正确的邮件标题，内容也要足够翔实。邮件内容应该包含如下信息：
+
+1. 证明订单信息并非一直缺失这部分数据，并拿出数据，附带数据的详细来源。
+1. 证明现在的订单数据并非所有的消息都缺失这部分数据，并找出缺失数据的消息ID和没有缺失数据的消息ID、时间等追踪信息，以便对方定位问题。
+
+用数据说话，数据出处要清晰；推理条理要清晰，事情的来龙去脉要清晰。有时候写重要的邮件和文档，就像写论文一样。
+
+### 先说重点和结论
+
+这一条规则适用于所有场合。日常中普通的交流也是，如果带着明确的目的，那么就要先说出自己的结论和想法；如果是写邮件和文档，内容翔实的一个副作用是难免冗长。这时候应该注意，先把结论抛出来，再写细节。如果是PPT类的演讲，也是先抛出结论和成果，再去涉及详细的内容。
+
+这样不仅可以让对方马上抓到重点，而且还可以让对方在有疑问的时候，可以带着疑问去阅读后续的细节。
+
+## 总结
+
+程序员的工作就像是产品。好的交流就像是包装，广告，公关和营销。有了好的产品，还要有好的包装，突出产品特点的广告，及时的公关和合适的的营销，才能赢得市场。没有这些，别人可能根本就不知道你有这么个产品，不知道这个产品能干什么，有什么特点等等。
+
+这里再总结一下，从输入这个角度来说，交流的好处可以分为以下几点：
+
+1. 获取更多的信息；
+1. 理解公司的业务；
+1. 加深对行业的理解；
+1. 发现新的机会。
+
+如果在交流中能够输出自己的内容，长期来看，给自己带来如下好处：
+
+1. 赢得自己的声誉；
+1. 树立自己的影响力；
+1. 赢得同事和经理的信任，承担更大的责任。
+
+充分的交流，并不是“就知道动嘴”，而是一个获取信息，加工信息，给出信息的过程。只有交流了，我们才能知道对方的想法，自己认为的好，可能并不是大家认为的好，自己没有想到的好处，别人可能想到了。我们在日常工作中应该多注意自己交流技巧的培养，养成喜欢和人交流的习惯。工作越久，交流在工作中的地位也就越重要。
+
+<img src="https://static001.geekbang.org/resource/image/34/27/34d9e3cbbc2920518d0f37b62d42af27.jpg" alt="">
+
+## 思考题
+
+你是一个喜欢交流的程序员吗？你有因为擅长交流而获得什么惊喜吗？欢迎你在留言区留言，我会和你一起交流，也欢迎把这篇文章分享给你的朋友或者同事，一起讨论一下吧！

极客时间专栏/geek/职场求生攻略/职业素养篇/04丨主观能动性：为什么程序员，需要发挥主观能动性？.md

@@ -0,0 +1,95 @@
+<audio id="audio" title="04丨主观能动性：为什么程序员，需要发挥主观能动性？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/66/36/6637a3d8edbe9bc85ea8473f8903bb36.mp3"></audio>
+
+其实关于这个主题，我也仔细想过，是放在生存发展篇合适，还是放在职业素养篇合适。最终还是觉得，作为程序员，发挥主观能动性应该算是一个基本的职业素养。
+
+很多时候，只要我们勤勤恳恳，认真负责地做好老大交代的任务，就算是一个合格甚至优秀的员工了。但是程序员这份工作，如果只是做到这一点，最多算是合格。由于软件开发的特殊性，一个任务完成的界限是非常模糊的，而且会根据具体的情况而变化。那么这时候，就要求程序员发挥自己的主观能动性，才能把事情做成，能够交付，而不仅仅字面意义上的“完成工作”。
+
+你可能会想，说得这么玄乎，是真的么？我们来看两个例子。
+
+## 数据清理和数据标准化背后的要求
+
+在一个数据处理和分析的项目中，有两个功能是对订单数据进行数据清理（data cleaning）和数据标准化（data normalization）。
+
+我首先简单介绍一下数据清理和数据标准化。我们要知道，来自不同的订单数据源的数据质量是不一样的。有的会缺失重要的信息，比如说购买者的ID、商品详情、订单时间等等。过滤掉这种缺失信息的不合格的数据，这就是数据清理。
+
+数据标准化则是对数据中的数据格式进行标准化转换。比如有的时间用毫秒表示，有的用秒数表示，有的用不同的格式“2020年5月15日 15点30分15秒”“2020-3-15 15:34:45”，有的甚至用不同时区的时间。再比如对于苹果这个品牌，有的数据用“Apple”表示，有的用“苹果”表示，有的用“苹果（Apple）”表示等等。那么数据标准化的任务就是要将这些数据转换成统一的格式。
+
+### 怎样才叫“任务完成了”？
+
+如果按照需求文档里的描述，我们完成了数据清理和数据标准化处理，这样是不是就叫完成了呢？如果你是负责开发的程序员，你还会做些什么呢？
+
+你可能会想到单元测试，代码覆盖率等。不错，这说明你已经是一个“摸着良心”干活的程序员了。那么除此之外呢？还有什么可以做的呢？如果就这么交付出去可以吗？
+
+一个有经验的程序员会想到，这种功能可能会用到不同的计算框架上，比如 Spark、Flink 甚至 是Hive。而之前蹚过的坑会告诉他，不同的计算框架内置的Jar 包的版本都是不一样的，自己的程序要能够尽可能少用兼容性差的 Jar 包。那么也许他就会在开发期间，跑去问相关的用户，这个功能可能会跑在什么框架的什么版本上，然后按照计算框架的版本，确定自己使用的 Jar 包的版本。当然，系统架构设计等也是一个需要用心的地方，我们在后面再细聊。在这里先不涉及。
+
+做了这一步，用户集成的过程就会顺畅很多，虽然你自己确实付出了一些额外的时间，但可以帮助整个项目的进度不被 Jar 包兼容性的问题所阻塞。
+
+当然，从责任上来说，功能是否要适配到不同的计算框架，应该是在需求上写清楚的。但是道理归道理，实际归实际。没有人能把所有的细枝末节都考虑全面，互联网时代，软件开发和迭代速度并没有给我们这么宽裕的时间。
+
+如果因为各种需求没有说清楚，导致最终做出来的功能无法使用，我们程序员虽然可以把锅甩出去，但程序员作为一线工作人员，很多细节可能只有走到那一步的时候，才能想得全面。如果一个程序员做事情永远只知道按照需求中写的做，不多考虑一分，实际上就是自己的失职。从结果上看，就是程序员没能交付自己的工作。长期如此，是很难成长为一名合格的、让人觉得可靠的程序员的。
+
+站在用户的角度试想一下，如果用户的这个项目要在 Spark 上用到两个功能。一个功能出现了各种 Jar 包版本兼容性问题，各种跑不起来，各种修改 Jar 包版本，甚至还需要修改代码，整个集成过程从原计划的三天拖延到了三周。另一个功能一下就用上了，一点毛病没有，原计划三天的集成时间，一天就搞定了。你会给这两个功能打多少分呢？又会倾向和谁合作呢？
+
+当然，这里的例子其实是一个比较明显的例子，确实应该在需求中写清楚平台和版本。但是在程序员的工作中，确实有很多我们需要考虑的细节，有很多考验我们“良心”的地方。发挥自己的主观能动性，多为用户考虑一点，是评判一个程序员是否合格的重要标准。
+
+### 一个合格的Dashboard是怎样的？
+
+聊完了数据清洗和数据标准化，我们接着聊下一个需求。这个需求是设计一个Dashboard，把每天的销量和销售额用一个Dashboard展示出来。
+
+这个需求看似很简单，就是把数据按天展示出来嘛。按照需求，我们先原封不动地作出一张如下图所示的Dashboard。
+
+<img src="https://static001.geekbang.org/resource/image/e7/61/e768fcec1e1f9bfa5e0cb5f6c0c25361.png" alt="">
+
+我相信，大部分用户看到这个图，第一个问题都会是：怎么就一根线？你可能会说，我确实把销量和销售额都展现在图上了啊，按照需求做的没毛病啊。用户有问题那是他们需求有问题，用户只看到一条线那是用户不会看。
+
+这种看似忠于需求的工作态度，其实并不能真正地让用户对工作成果感到满意。当然，程序员将需求做出来了，确实只是如此，没有人能挑出毛病，但也不会有人喜欢跟这种程序员合作。
+
+为什么呢？正如上面的例子所说，在互联网快速迭代的今天，需求可能不会那么细致。我们依然要站在用户的角度看问题。
+
+那么这张图到底有什么毛病？
+
+在上图中，因为销售额比销量大很多，销量被销售额的数字“压”得几乎成了一条底部的直线。那么这样一来，有一个很明显的事实就是，销量这根线，已经不能传递任何信息了。除非用户是列文·虎克，有耐心还喜欢拿着显微镜看报表。
+
+所以用上面两个例子我想说明什么呢？
+
+完成明面上的用户需求，仅仅只是我们工作的合格线而已。一个程序员应该基于需求，把自己的触角延伸到需求之外，交付用户真正想要的东西。比如给报表增加按照对数设置Y轴坐标的功能，让数据相差特别大的两根线，也能在同一个Dashboard里展现自己的“曲线”，如下图所示：
+
+<img src="https://static001.geekbang.org/resource/image/e5/5d/e5b6b055996aa9032ac1633cf65a775d.png" alt="">
+
+我相信，任何一个用户都会更喜欢第二种方案。虽然需求没有明确说要支持这种功能。但是从交付的角度，第二种方案才能对用户产生实际的价值。
+
+那么前面通过两个例子，我描述了一下程序员这个工种对发挥主观能动性的要求。下面我们来谈谈如何发挥主观能动性。
+
+## 如何发挥主观能动性
+
+其实发挥主观能动性的方式会随着程序员具体工作内容的变化而变化，比如说前端工程师、后端软件开发师、架构师等等。但总有一些东西是共性的，那么在这里，我就说说我的几点建议以及需要注意的东西。
+
+我在上面反复强调交付思维，所以我觉得这一条应该列在第一位。
+
+### 交付思维
+
+发挥主观能动性，究其核心，我觉得就是一点：站在用户的角度，交付用户想要的东西。也就是说，不能止步于用户的需求。程序员作为冲在第一线的人，对细节的掌握是最多的。我们需要依靠这些细节，结合用户的需求，理解用户需求背后真正想要的东西，然后努力向这个目标发展。
+
+正如前面的两个例子，其实做得好的标准，就是理解用户没说出来的需求，能够为用户着想，交付用户想要的东西。
+
+### 注意时间
+
+发挥主观能动性的一个代价，就是会用掉更多的时间。这方面一定要注意。比起功能的完美，在规定的时间内实现基本功能，才是优先级更高的事情。
+
+假如你突然对一件事情有了想法，但是时间来不及，或者不确定是不是对用户有价值，那么可以及时和用户交流。如果用户觉得这个细节确实很重要，即使延期也值得做，那么大家可以商量新的时间线。如果用户觉得可有可无，或者可以放在后续迭代来做，那么就专心做好需求里描述好的功能。
+
+程序员在发挥主观能动性的时候，也难免会“夹带私货”。比如说，自己想用个什么新技术，试试不同的做法。这时候也要注意时间。用户可能一时无法理解新东西给自己带来的好处，但是用户肯定知道项目无法按时完工的坏处。所以在“夹带私货”的时候，一定要保证自己对项目的进度有所把控，不要因为自己的私欲让整个项目无法完成。
+
+## 总结
+
+程序员这个职业，已经远远延伸到了写代码之外。对内我们要DevOps，对外我们要交付对用户有价值的东西。而发挥主观能动性，就是帮助我们做对用户有价值的事情。程序员接到需求之后，要进一步理解需求背后的用户意图，理解用户的问题。
+
+正所谓，将在外，军令有所不受。又有言：让听得见炮声的人决策。程序员就是那个拿着作战目标，冲在一线，能够听得到炮声的人。面对系统实现时各种复杂的情况，我们有责任，也有义务发挥自己的主观能动性，达成最终的作战目标。
+
+<img src="https://static001.geekbang.org/resource/image/5b/f6/5b6aaf94e387a5f4767519d6df7c60f6.jpg" alt="">
+
+## 思考题
+
+你在工作中，有发挥自己主观能动性的习惯吗？有发挥自己主观能动性的场景吗？
+
+欢迎你在评论区和我分享你的留言，也欢迎你把这篇文章分享给你的朋友或者同事，一起交流进步一下。

极客时间专栏/geek/职场求生攻略/职业素养篇/05丨责任的边界：程序员的职责范围仅仅只是被安排的任务吗？.md

@@ -0,0 +1,95 @@
+<audio id="audio" title="05丨责任的边界：程序员的职责范围仅仅只是被安排的任务吗？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/20/91/209c3e6afde31fd2951cfee332ee5291.mp3"></audio>
+
+我们要知道，在现代社会，责任一般是和钱挂钩的。
+
+我举一个例子。现在很多ERP软件都提供SaaS的服务。一个公司如果要使用这个SaaS服务，即便免费的额度已经够用，大多也会选择付费。为什么呢？其实花钱就是为了买个对方的责任。不付钱，看似节省，但如果真的出了问题，比如数据丢失、数据泄露等，那么对方是没有责任或者义务帮你修复的，但花钱就不一样了，一旦出现数据安全、数据稳定相关的问题，服务提供商都是要担责的。
+
+那么同理，我们参加工作，和公司签了合同，有了工资。工资的背后，就是“责任”二字。
+
+任何拿了钱的事情，都要负责——这是一个最基本的社会规则。
+
+## 程序员需要对哪些事情负责
+
+看到这里，你可能会有疑问，这还用说吗，我对自己的工作负责不就好了？可是我们的工作边界在哪里？“工作”仅仅指的是在公司内的工作职责吗？
+
+首先，我认为，身为程序员，我们的工作边界及其范围包括3个部分，分别是个人的基本能力、工作内容以及工作时间。
+
+### 对自己的基本能力负责
+
+首先，程序员要对自己的基本能力负责，基本能力主要是技术能力和熟悉公司系统的能力。
+
+**持续精进技术能力**
+
+技术能力就是工作中用到的技术，是我们看家的本事。公司毕竟不是学校，没有教学的义务。既然拿了工资，就要学会相应的技术，完成安排的工作。
+
+我在工作中也遇到过一些人，很多基本技能都不会，自己还没有任何补短板的意识和动作。安排工作的时候，直接甩出一句：我不会。理直气壮，令人惊叹。久而久之，大家对这个人的印象就是——没有工作能力。
+
+当然，很多时候，并不是所有的技术需求都来得那么强烈，也不是所有的技术每个人都熟。我们在实际工作中，也难免会遇到自己不会的问题。这个时候可以向别人请教，但是千万不要觉得请教完就算完了，我们还要意识到自己为什么不会，想办法补齐这块的知识和技能。
+
+如果一个事情不会做，那么基本上就相当于“违约”了。
+
+但如果公司安排确实不合理，工作岗位不能发挥自己的能力优势，这种情况下又该怎么办呢？我的建议是，首先还是考虑发挥自己的优势，再抽时间补短板。态度要积极，不能摆出一副“我不会我有理”的态度。但如果新的工作全是短板，技术不熟悉，业务不熟悉等等，那么不妨和经理和HR聊聊转岗的可能性。
+
+除了补短板之外，我们更可能遇到跟随公司做技术转型，学习新技术。如果是一些重要的公司层面的技术转型，有些公司可能会安排培训，或者给出一定的激励措施。当然，如果公司没有相应的政策，那么自己也是有责任把技术学起来，胜任新的工作的。
+
+其实公司技术升级，也是给自己的技能升级的好机会。我一直强调的一点是，学的东西一定要在实际工作中使用，因为这样最能够激发学习的积极性，也最能验证自己学的成果。公司决定转型采用的技术，也大都会比现在使用的技术更优秀。很多工作久了的同学会抱怨说工作中用不到新技术，如果遇到公司技术转型升级，赶紧抓住机会努力一把，给自己的技术也升级一下。
+
+就我个人的例子来说，我学会Hadoop、HBase、Hive、Spark、Scala和JS等等很多技术，都是抓住公司新的项目要用到新技术的机会，“强迫”自己学下来的。有些项目公司会留一部分学习的时间，大部分情况下全靠自己挤时间学。一边学，一边通过公司项目的实际操作来考验学习成果，过程非常的充实，学得也牢固。
+
+所以公司技术升级，对我们个人来说，其实是一个非常难得的机会，如果你有遇到过，那么请一定要抓牢它。
+
+**熟悉公司的内部系统**
+
+很多公司都有自己的内部系统，熟练掌握和使用这些系统，也是我们程序员的责任。
+
+在有些程序员看来，公司内部的系统不能算技术，因为这些东西不是通用的，就算学了对以后找工作也没什么用处，所以一般对内部系统的学习积极性并不高，甚至有些排斥。
+
+但能够熟练使用内部系统，也是拿工资后要承担的一部分责任。公司内部系统的价值在于，它们一般都是和公司的整个框架集成好的，比如公司内部的SOA框架或者微服务框架，都是和公司内部的监控系统等等集成好的，即使这个框架再“不好”，公司内部的项目还是要使用，这样我们才能够在宏观上建立对公司内部所有服务进行的理解，从而更好地利用自己的技术，不至于“盲人摸象”。
+
+撇开硬性工作要求不谈，事实上，有些公司的内部系统，做得还是很优秀的，甚至于让人离职之后还很怀念。积极学习公司内部相关的系统，也是自己在这个公司的收获之一。以后如果有机会在别的公司从事相关系统的开发设计工作，也可以借鉴学习。
+
+你看，这同样也可以提高我们工作的基本能力。
+
+### 对安排的工作负责
+
+说完我们个人的基本能力之后，接下来，就是我们非常熟悉的内容了，工作责任。无论什么职业，都要对安排的工作负责。
+
+程序员这门职业的特殊性在于，工作本身的具体内容和难度，会随着被安排的工作内容的改变而改变。从对工作负责的角度来说，我们大部分人会付出比当时预想的更多的时间，才让自己能够按时完成工作。
+
+当然，这里并不是鼓励加班，只不过是一个小建议，如果你有额外的付出，那么到时候可以将自己做的计划外的事情说出来，这样一方面让大家认可你做的工作，另一方面，也是能够让大家对这类事情的工作量估计更合理。
+
+当然还有另一种情况是，事情超出了自己的能力范围，比如一件事情的复杂度远超过之前的估计，在规定的时间内，自己确实无法完成。那么这个时候，正确的态度不是硬着头皮上，而是将情况理清楚，早点找经理或者负责人，让他们知道事情的进度和之前没有预想到的难度，把事情重新安排一下。毕竟，谁也不能承担“到了deadline事情还没有做完”的风险。
+
+从管理者的角度来看，一个事情安排得不合理，就应该早发现，早计划，重新安排资源。毕竟大家的目的是把事情做完，而不是冒着事情可能做不完的风险去压榨一个人。
+
+当然，还有一种情况就是，给自己安排的事情实在太多了，自己没有时间完成。这时候，一方面要自己思考事情的优先级，这点我们之前也讲过，另一方面要及时和经理沟通，建议将优先级低的向后推，或者找别人来帮忙。总而言之，不要在最后给经理“惊喜”。
+
+很多新人可能很难把握这样一个度，什么叫“偷懒耍滑”，什么叫努力负责呢？在工作经验不丰富，技术能力也相对薄弱的情况下，怎么才能知道事情有没有“失控”呢？
+
+我的建议是，当遇到自己吃不准的事情，可以多问问组内资格老的同事，如果老同事说问题不大，那么自己也更有底气。如果老同事说这个问题自己也没有遇到过，那就得找经理聊聊下一步的安排了。
+
+### 对工作时间负责
+
+很多软件公司，其实都是弹性工作制。毕竟程序员这个工种要求一直在线，有时候出了问题，随时随地掏出笔记本就得开干。既然没有一个明确的“下班”时间，那么很多公司也就不规定硬性的上下班时间了。
+
+这里说的“对时间负责”，也是因公司而异的。我的建议是，一定要在“实际上班”时间之前到，避免有人找你却找不到的情况。比如说，大部分人都是在九点半之前到公司，那么你也尽量在这个时间左右到公司，不要延迟太久。
+
+还有就是如果有会议，一定要准时参加。如果临时有事无法参加，要及时和大家同步。
+
+对时间负责的背后，其实不止是为了保证工作时间。毕竟我们程序员都知道，坐在座位上并不代表就在工作，没在座位上也不代表没有在工作。这里想强调的一点是，程序员的工作不只是写代码，还有很大一部分是交流沟通，保证基本的工作时间，才能更多的和大家交流。
+
+## 总结
+
+随着级别的升高，程序员的工作也更丰富，从不同的角度来看，也会有不同的责任。比如我现在担任组里的技术主管，除了要做好安排的工作之外，还要协助组里的同事完成工作，同时要思考如何推进系统的技术升级，以更好地满足用户的需求。对于级别更高的同事来说，还有更具有挑战性的责任。付得起责任，才对得起自己那份工资。
+
+俗话说：受人之禄，忠人之事。责任是一点点增加的，负责任的态度和习惯，也是从平时工作中的一件件事情中养成的。当你养成这样一种习惯之后，你会收获一个别人对你的金字评价：这个人，负责，靠谱。
+
+如果你承担的责任更重了，那么距离你加薪升职还会远吗？
+
+<img src="https://static001.geekbang.org/resource/image/63/6e/63d3bcf51ac687a1853a5eb73f01d56e.jpg" alt="">
+
+## 思考题
+
+这里给你留一个思考题吧。你觉得程序员还有那些基本的责任？就文中的内容而言，你觉得你是一个负责任的程序员吗？
+
+欢迎你在评论区与我分享你的思考，也欢迎把这篇文章分享给你的朋友或者同事，一起交流一下。

极客时间专栏/geek/职场求生攻略/职业素养篇/06 | 职业素养篇热点问题答疑.md

@@ -0,0 +1,99 @@
+<audio id="audio" title="06 | 职业素养篇热点问题答疑" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/0e/11/0e8a94726e85adb06e4a9ff3c47fe011.mp3"></audio>
+
+你好，我是臧萌。转眼之间第一个模块就结束了，这个模块讲了我们在日常工作上遇到的问题，也引起了很多同学的共鸣，在评论区纷纷说出了自己的苦恼。我觉得有些话题非常值得展开讨论，
+
+## 有关优先级的那些事儿
+
+优先级这个话题牵涉到很多人，不止有自己的，还有合作方，乃至领导的。有些同学在评论区中说到，会因为优先级的事情和经理有争论。
+
+我的建议是，不要跟经理就事情的优先级有太多争论。
+
+什么意思呢？并非说不能交流，交流是很好的一个过程，也是帮助我们理解经理决定的过程。交流 = 沟通事实，同步信息，表达自己的意见和想法。但是交流之后，就听经理的判断，不需要再跟经理争论。因为决定事情的优先级是经理的一项重要的权利。这个权利就好像将军有军队的指挥权一样顺理成章。
+
+### 交流技巧之逼出对方心里的优先级
+
+@峰 同学说，需求方每次都说事情很急，但是他做完之后，对方就没动作了，这样很打击积极性。
+
+我的建议是，如果你的客户只有这一个需求方，我建议你给出任务的工作量估算，然后让对方给出优先级，这样就能“逼”出对方心里真正的想法，哪个活儿重要，哪个活可以适当延后，你自己干活也更有目标性。当然，有时候对方可能也没有仔细思索优先级，只是惯性地把事情压给你而已。这时候你这么倒逼对方一下，也可以让对方更好地思索一下事情的重要程度。
+
+比如说，可以这样：“taskA，3周；taskB，5周；taskC，2周。现在还有一个月，这边有俩人，也就是8个周的工作量。你自己选吧，哪个可以延期。”
+
+当然，对方可能说“不行你就得加班撒……”你就说：“这个已经算上加班了。”
+
+## 做好自己的事情，负好自己的责任
+
+@jhren 同学问，自己的工作被阻塞了，自己催没用，经理不帮忙催，怎么办？
+
+我站在利益和换位思考的角度说说我的观点。
+
+老板的一大职责就是搞定人，搞定关系，搞定非技术的事儿。如果你老板知道这个情况，还想躲在后面，站在经理的角度，从利益最大化为出发点，他这么做有3种可能性：
+
+1. 他觉得这个事情并不值得他出面，或者说他觉得这件事做成的好处远远小于他“得罪”阻塞你工作的人。
+1. 他本身就不想这个事儿能办成，但是也不能什么都不做，明知不行还把下面的人推上去，让你去催。
+1. 他本身知道这个事儿成不了，他出面也摆不平，他也不想趟这趟浑水。
+
+你作为最下面的执行者，可以发个邮件给到协同的同事：大家好，请大家把事情定下来之后通知我一下，我可以继续下面的工作。非常感激大家的通力合作。
+
+你自己呢，就是做好自己的事情，负好自己的责任。守住一个职业人的底线就可以了。
+
+## 邮件在现在到底还适不适用？
+
+@再来二两杜康酒同学 问，发了邮件没人理怎么办。
+
+也就是说，邮件没效果怎么办呢？我给出一个标准组合拳：
+
+1. 抄经理，抄对方经理，目的就一个字——催；
+1. 开个会，仔细聊，聊不清楚继续聊；
+1. 列出事情的优先级，列出事情不做的影响，给对方施压。
+
+除了这个问题外，还有相当一部分人在说，现在已经不用邮件了。比如@Kǎfκã²⁰²⁰就提到了这个问题。
+
+这里要为这位同学的公司点个赞，就好像文章里说的，邮件并不是一个高效的沟通工具。相信你工作中用的工具更高效。
+
+我写这篇文章的时候专门找字节跳动的同学聊了聊，飞书确实很不错。大家也表示，在字节不扯别的，就是干！不过，确实也是累。交流的效率上去了嘛，自然有更多的时间干活了，可以更快出成果。但是呢，慢也不是一无是处，慢可以让给我们留出更多的时间去全面地思考问题。
+
+总之，“邮件”的逻辑也还是在那里的。同步的沟通更高效，异步的沟通更需要深思熟虑，要为自己给出的话负责任。
+
+## 内向的程序员如何沟通？
+
+@chewbee 同学问，内向的同学如何养成主动交流的习惯呢？
+
+我觉得我和这位同学挺像的。我给出一些我自己的建议吧。
+
+首先还是态度上的转变，我们要把交流沟通当作做事情的第一步，而不是把做具体的事情作为做事的第一步。现在我把“和人交流”放在比“做具体的事情”更高的优先级上。也就是说，不把事情弄清楚，就不开始做具体的事。这样一方面是为了把事情做对，另一方面来说，对于写了那么多年程序的人来说，在知道怎么做的前提下，做事本身没有什么挑战了。而弄清事情的前因后果，弄清要解决的核心问题，才是更有挑战的工作内容。
+
+其次，我在直播里也提到过，对于内向的人来说，可能很难忽然转变，跟谁都能聊得无拘无束。其实这样也没关系，我们可以在经常合作的部门里，找一两个固定的人交流，作为起点。比如自己组里的经理，架构师，或者是比较熟悉组里情况的同事。别的组里，也可以是一些资深的员工或者架构师等职位的人。不要觉得对方和自己交流是耽误对方的时间。我的感觉是，大部分的架构师，经理以及资深的员工，都非常愿意和人交流。当然，如果有那种不愿意和人交流的，那你下次换个人就是了。
+
+最后，别和人张口就是工作，没事儿可以和别人打个照面，打声招呼，随便聊聊别的事情，游戏，生活，电视剧，八卦，军事，音乐，运动什么都可以，只要是双方都感兴趣的。这样非常有利于拉近彼此的距离，减少陌生感。
+
+## 让别人看到自己的工作
+
+@牛牛 同学有个问题，说自己做的事情都是小事情，又很繁杂，那么如何优雅地让自己做的事情让别人看到。
+
+这里，我可以给你出个主意。小事也是跟大事相关的，这些琐碎的、浪费时间的事情，为什么不得不处理呢？就是因为跟这些事情相关的更高层级的事情更重要。把自己做的事情跟这些重要的事情关联起来，就显出自己做的事情的分量了。
+
+我随便举个例子。比如说是给业务增加新的API和数据表。你如果只是单纯地说“增加了一个表，添加了几个API操作表里的数据。”这样谁看着都枯燥，也突出不了自己的贡献。从技术角度看，也就是CURD，没啥好说的。
+
+如果你在做API和数据库表的时候，多跟业务方聊两句，问问这个API是给哪个项目的，是干什么用的等等，那你报备的时候就可以这样说：“为公司重点项目购物车二期新增三个API，一个购物车数据表，提供了购物车二期项目中对Android和iOS应用中购物车操作的支持。”
+
+所以，觉得做的事情没意思的时候，就问问业务方的目的，因为我们做的东西都是业务提供的。正如你说的那样，注意沟通，沟通让你获取更多的信息，see the big picture。
+
+@咸鱼翻身记 同学也提到类似的问题，他解决了很多系统遗留的技术债，做了优化，而且写了文档。
+
+这里必须点一个大大的赞，同时也建议你，记得总结并跟大家分享自己的工作成果，这样一方面可以让大家了解相关的改进，另一方面也让大家了解自己的贡献。
+
+这还牵涉到了另一个问题，@LDxy 问，要不要把自己想做的额外的东西说出来。
+
+说，必须说，而且要先说再做。想做的东西，先跟需求方交流，看自己理解的对不对，对他们来说有没有价值。
+
+这个也和之前说的交流有关系。自己对问题的理解和解决方式有了新的想法时，应该先跟需求方确认自己的想法是否正确，做出来是否有价值。这样，对自己发挥主观能动性，是一个巨大的正反馈。如果只是自己的理解，做出来用户不买账，反而很打击发挥主观能动性。
+
+所以我们不能玩霸道总裁向，不能说“我不要你觉得，我要我觉得”。而是要玩霸道码农向，要说“我不要我觉得，我要你觉得”。快给我觉，我说的这个怎么样，有没有感觉，这个feel对不对。不对我们继续聊。
+
+作为结尾呢，我分享一位同学的评价，他说我“可以把挺多讲出来很容易负能量满满的道理，用一种充满正能量的视角合乎情理地表达出来。”
+
+我觉得说的还挺贴切。这也是我这门课的一个目标。说说职场上的这些事，进而理解这些事背后的道理和职场的逻辑，让大家在职场的路上走的更顺畅一些。俗话说，世界上只有一种真正的英雄主义，那就是在认清生活的真相后依然热爱生活。
+
+把这句话的“世界”换成“职场”，把“生活”换成“工作”，也挺对味儿。大家品品：职场上只有一种真正的英雄主义，那就是在认清工作的真相后依然热爱工作。
+
+以上就是答疑篇的内容，不知道有没有解决你的困惑呢？欢迎你在评论区与我交流你的想法，也欢迎把这篇文章分享给你的朋友或者你的同事，一起来交流一下。