工作累了，不妨停下来想一想一路走来的艰辛。毕竟我也是一个工作量很大的人。但总觉得工作中的思路和方法或多或少存在问题。前几天和朋友喝了几杯酒，聊了一些故事和自己的感受，就成了这篇文章。Goal&Means——简介首先说一个场景，关于电商秒杀。“大秒活动基本是整点进行的，活动详情页的流量会非常高。为了保证这么大的流量不会压垮机器，一般的做法是在行业如下：从详情页做多层过滤首先是垃圾请求，普通电商产品直接拼http/https订单请求参数就可以下单，但是对于大神来说，如果选择接听question，用户无法推断出question参数，detail会做一层简单的过滤，直接拦截这些垃圾请求；然后，由于人为操作的速度限制，系统会直接锁定每秒几十个请求进入一个小黑屋，将他们屏蔽一定时间；如果流量还是很大，采用fence的方式限流（这种限流方式有运气的成分，不是习惯一直开着，只是在大促的时候偶尔开着）。每个请求的时间偏移量不同，如果请求在偏移量时间之内，抱歉，运气不好，需要重试。可以从技术角度进行”，而不是“如何让后端服务器同时承受巨大的流量”。两者的区别在于目标和手段的区别。如果你认为关于如何从一开始就承受流量的问题，你可能会因为选择了错误的解决方案而走入死胡同（比如可以将机器数量成倍增加，迫使开发同学去榨取接近的性能）limit）。在工作中也是如此。首先需要围绕目标思考“得到什么结果”，然后再考虑“如何得到这个结果”，这个概念极其重要，怎么强调都不为过。&ProgramDirection是一个明确的目标，并且pr克是一种自由的手段。在城市环卫中，目标是保持清洁的市容，而不是雇佣和管理成千上万的清洁工，这只是实现目标的一种解决方案。日本采取了另一种解决办法，就是做好垃圾分类和健康教育，但效果好于国内大部分城市。个体清洁工也是如此：你可以选择早点出门，马不停蹄地复工，也可以选择多建几个垃圾桶，放在垃圾源头旁边。“不管黑猫白猫，能抓到老鼠的就是好猫”是对“方向&计划”最好的辩证。在这里，“捉老鼠”是目标，是一只好猫的标准，而不是可爱或其他任何东西；在这个标准下，黑猫或白猫都可以是好猫。无论是公司老总还是保洁员，当目标确定后，手段的选择就自由了。如果你理解了这个概念，你可以在工作方面拓宽你的思路。你可以向你的老板询问方向，而不是计划。这个计划是我们自己制定的。如果我们能想出领导想不到的方案并做出来，我们就牛逼了，更能体现我们自己的价值。更进一步，了解目标可以帮助你站在领导的角度看问题，从而及时补位，超越预期。Result&Process结果是衡量工作质量的唯一标准，但不能用过程来衡量工作质量。在商业上，都说“用户就是上帝”，“用户永远是对的”，因为“用户感知是检验作品好坏的唯一标准”。一件事情做的好不好，不在于你的出发点、动机、付出了多少努力，而在于用户的认知。在之前的公司，负责公司内部系统流程的移动审批接入。上线后收到很多同事的反馈，体验不好，一开机审批就慢。老大来找我说话，我解释了很多，说审批网关的性能其实跟实时获取内外部任务中心和下游业务数据有关，不过老大的意思很明确，“对于用户来说，主观就是客观。”，用户主观上觉得这个产品不好，就是不好，也无话可说。想办法改进才是正道。从另一个角度来看，只有用户能感知到的才是有意义的。我说的有点偏激，但也不是没有根据。我们中的许多人通常都很忙。上午PRD，下午技术方案评审，明天开球。但这些只能得出结论，不能得出结果。这些“结论”没有被用户感知到，也不会让我们的产品和服务被更多人知道和喜欢。在这些“结论”产生结果之前，所有的会议、讨论、分析都是无用的。极端的说，都是成本，而不是结果。没有借口，言出必行，言出必行，才是最大的靠谱。这样的场景我遇到过很多。我周围的很多同事，包括我自己。我总是喜欢为自己找借口。我们总是说项目晚上上线是因为临时bug，因为临时插入了一个新项目，或者是因为对方联调的同事请假了，然后我们就把话题换成howhard我们是。说一件小事吧。我自己很多时候对时间非常偏执。一位朋友说，“所有迟到的理由都站不住脚”。所以我一直很注意时间的规划。比如每次去机场，我都会详细规划时间。比如晚上9:30的飞机。我估计要等多久航班？过去在路上用了多长时间（比如从武林门机场汽车站到萧山机场需要27分钟）？晚高峰多长时间合适？我需要多长时间才能叫到出租车？等等。总有人说，哎呀，路太堵了，连续闯红灯不吉利，所以你迟到了——你总是迟到，当然迟到了，不管你迟到今天或明天。你为什么不提前半小时离开家？你不能假设道路是畅通的，你应该假设道路会被堵塞——你做项目的时候，你应该假设有困难，你怎么能假设没有意外呢？为什么不准备资源来解决意想不到的问题呢？困难和不确定是我们需要克服的事情，而不是在我们开始之前预设为事后的“没有完成的理由”。一旦有了这样的预设，就完了，从“演员”变成“诠释者”，精神就没了。确实有所谓的不可抗力，但是99%的所谓不可抗力的东西都不是不可抗力。之前流行一句话，“以大多数人的努力程度，还没有到拼智商的地步”。同样，大多数人面临的困难和不确定性，也远不是不可抗力的程度——你没有“尽力”，“听天由命”。上一节讲到，“只有用户能感知到的，才是有意义的”。所做的努力和投入，如果没有最终实现并传递给用户，就是成本。不达目的不达目的，无话可说。结果导向的思想是“没有借口”。从终点开始，孩子刚开始学写文章，总是想着往哪里写；大师写文章，总是先提纲后写。我们在使用手机地图导航时，第一步是先输入目的地。然后地图会给你选择几条路线，然后看是打车还是公交车。这其中隐藏着一个道理，那就是“逆向行事”。所谓“倒着做”，就是在设定行动方针的时候，要从想要达到的结果开始倒着做，而不是根据现状来决定行动方案。上一节提到，为了避免迟到，需要从上班时间往回算，确定出门时间和起床时间；而不是先看起床时间，再看什么时候能到公司。以我们程序员为例，我们经常犯的错误就是，当我们收到一个请求时，我们在心里感叹自己很简单。一上午的时间，调试已经写好发布了。结果有需求变更的时候，我一头雾水说要加一条信息，跟PD说这个变更很难，可能要改整体架构。或者当生产环境出现异常时，我们没有做足够的灾难恢复，眼睁睁地看着一个小问题变成了故障。这里其实是基于问题的一个假设。分析能力的提高，不是学习了多少分析方法，而是掌握了正确的分析思维。结果的逆转在跨团队协作中尤为重要。主导合作，不是等对方完成一个项目再看下一步，而是直接约定项目节点，往前推进。与其说“当你完成了这个，让我们再开会讨论那个”，不如说“让我们下周三开会讨论结果”。这里的一个好处是可以利用好“来自目的地的张力”来逼迫自己和团队提高效率。以对方为标准“沟通最大的问题就是认为沟通已经发生了”。这是我现阶段遇到的一个大问题。经常听到团队抱怨沟通，“这件事我跟A说了，但是A太不靠谱了，到现在也没做好”。出现这种情况，通常不是A不靠谱，而是与A的沟通出现了问题。沟通中容易犯的错误是从自己（沟通的发起者）的行为出发，而不是来自另一方（导致通信的一方）的接收和接受。举个栗子。在一个项目中，我在发布前给项目团队发了电子邮件。邮件指出有同学需要在准备预发布的时候提供我本次发布前涉及的sql初始化脚本。结果那天我去问，得到的答复是：“我不知道？你告诉我的？”，我顿时火冒三丈：“你怎么不看邮件？”有类似的事情。我打车的时候，如果司机说“我在马路的右边”，我会很生气。你说可以，但我不知道你的方向。谁知道你指的是右边哪一边？发通知说“这个我已经在群里发过了，谈过”只是“谈过”，但不保证对方已经了解情况。对方电脑坏了怎么办？“我们已经讨论过这个模块的访问，但我们无法就结论达成一致。”讨论讨论了，但双方对数据口径的定义是否一致？另外需要注意的是，需要资源、引导、信息同步，不同的目的需要不同的沟通方式。对谁、对什么以及如何？对方有背景知识吗？对方的立场是什么？对方会有什么疑惑？对方能听懂我说的话吗？是直截了当，还是不真诚？是通过电子邮件还是通过电话进行正式沟通？是小组会议还是一对一交流？这些是你在沟通之前需要问自己的问题，并从对方的角度得到答案，而不是从你习惯的沟通方式和风格上胡乱推进。沟通最大的妙处在于达成共识；而我们常常得到的是达成共识的错觉。适当的沟通是扩大影响力的最佳途径。在沟通中，你要确保对方收到了信息，在达成共识的过程中，你要确保对方接受了——不要停留在“反正我已经说了””Shelving&FeedbackBlackHole最后说一下我工作中最忌讳的两件事。搁置是职场中的第一大忌。如果分配给你的东西，你必须解决它。躲也没有用，还是想办法吧！不管你有多讨厌，不管你有多厌恶。反馈黑洞主动沟通是第一要务。我对这件事有很深的感受。程序员是一个相对沉默寡言的群体。我们大多数人都不擅长沟通。但我认为沟通只是工作中的第一要素。如果不沟通，不主动透露自己的信息，再强的人在团队中也总会遇到各种各样的问题。说白了，沟通技巧就像是木桶原理中的最短板，严重制约着我们的发展。结论结果导向的思维其实是“反人类”的。人们习惯于从“接近”、“熟悉”和“具体”的出发点思考和做事，而不是从“遥远”、“相反”和“抽象”的角度来规划和执行结果。在日常工作中，要更好地贯彻结果导向，需要事先把结果明确到极致，把责任落实到一对一，做到过程中不出现倦怠和搪塞，并在同时，更加清晰准确地确定实践目标和职责。只有做出结果和预定义的结果，才能不怕质疑，才能做出成绩，才能实现价值。努力改变，发现不一样的自己。
