想法随写：推动与拉动 and 百思得解 and 学会扭转被动局面 and 大胆假设小心求证

§ 推动与拉动

上周和一位以前的领导打电话。他现在就职于bat之一。提到以前的工作倾向于推动，而来到bat，工作重心变动了拉动。大平台提供了很多施展才华的机会，不过，首先你得是个人才，要去深入市场，挖掘用户需求，推敲打磨。当你的想法得到上层管理层的认可后，公司就会给你足够的产研资源。

细品一下，推动与拉动，一字之差，含义却大不同。就像一驾人力车，你推着它，它就向前走。但是方向，你也许控制不住。而引领方向，就得靠拉动。

拿一个企业来说，公司的决策者，就是制定战略目标指引发展方向的。然后，中高层管理者，要根据战略方向，确定中短期阶段性的项目。而基层管理者的任务，更重要的是带领团队，推动一个一个的项目落地。

回归老本行，对于我们的技术组织，成员技术水平不一，初、中、高通常以类似于5：3：2的比例来配置。那么，对于组织的负责人来说，就要依据各成员的技术能力和态度，来区别对待。能力强态度好的人，自然是多多益善。不过，这样的人，常常是可遇不可求。尽管如此，还是要进行分析归类。那些能力强态度好的成员，你可以放心安排任务，定期关注一下进度，稍加推动可能就ok了。对于那些能力偏差的成员，就要采用拉动的策略了。给其分配的任务要足够明确，就是尤其要遵从SMART原则，同时，不断跟进任务的执行过程，多指导，多纠偏。且不可让其做一些技术调研、方案设计这样的工作。

 

 

 

 

§ 百思得解

百思不得其解？这世上哪有那么多百思不得其解的事情呀！

不是找不到答案，而可能是自己缺乏思考，甚至没有百思。

如何做到优秀？KSA三点，技术/knowledge+技巧/skills+态度/attribute。技术需要通过努力学习。完成一个任务之后，如果还能不断思考更好的处理方式和解决办法，不断改进，就会形成自己的技巧。

btw，早上上班路上，忽然想，百思得解是个多好的词语呀。现在是移动互联网时代了，如果前几年的互联网1.0和2.0时代，注册一个bestjack域名（音译：百思得解）也许还可以小挣一笔人民币呢。。

 

§  学会做事：扭转被动局面

商户做资金下发时，银行返回付款失败，付款单改成失败后，风控系统在释放占用额度时却失败了。一步步排查原因，发现原来是风控系统里的交易表中，商户订单号字段的长度不够导致了这个bug。看似简单的问题，排查的过程却是漫长的。整个过程中商户还在不断的催促问运营要反馈。

当然，如果直接把我们系统的这个bug反馈给商户，显得我们太不专业太不靠谱了。于是，修改反馈的话术：我司风控系统对接收的数据的长度限制比较严格，那笔交易的订单长度是31位，超出风控系统可接受的长度，导致额度控制出现问题。对此，我们已经紧急处理，经过风控运营同事评估之后，将商户订单号长度进行适当扩容，提高对客体验。

之所以能够这么做，还是要感谢以前的老领导李总。他在职时，每当系统出现问题，不管是对公司内的其他部门高管，还是面对外部的企业客户，他总能扭转被动的局面，甚至变被动为主动，变不利为有利。记得有一次，客户在我司差旅SAAS平台预定了飞机票，而在出行当天客户赶到机场后，却收到了我们系统发送的航班延误若干小时的短信通知，致使客户空等很长时间才得以登机。通常，这种航班延误的通知，应该至少在出行前一天通知到客户。客户是一个普通职员还好，而如果是一个企业高管，抑或是多个客户，可就不那么容易搞定了。李总和运营给出的说法是：上游航司系统故障，不过我司会承担所有后果，包括经济赔付。最后，因为处理的比较巧妙，公司并未因此事惹上麻烦。

我后来回想，这可能就是人情练达即文章。

 

 

§  大胆假设，小心求证

系统在运行过程中，总是会出现这样那样的问题，无论是小bug或大故障。

而且，往往很多问题并不那么容易找到原因。尤其是当我们掌握的资料有限的情况下，比如生产的数据我们没有查询权限，redis存储的数据难以确认，消息中间件的运行情况我们无法查看，依赖的上下游系统对于我们是个黑盒，等等。

不仅如此，当一个系统的业务链条比较复杂的时候，单从系统内部来排查问题，也是会存在很多可能性因素的。

所以，好的选手，不仅在于可以写出好的代码，还能善于排查问题修复问题，即，拥有超强的解决问题的能力。

大胆假设+小心求证，给我们提供了解决问题的方法论。具体来讲，就是要打破思维，同时，能够自我否认，不局限于某一个点，而是放眼整体，来从各个环节进行怀疑。就是先对结论进行设想，罗列出可能出现问题的环节。然后呢，有了存疑，就要小心求证，通过认真、谨慎地分析日志或数据，客观证明这些环节是否有问题。

反例的情况，

如果只拘泥于某个点，可能排查来排查去，都找不到原因。实际上，原因可能隐藏在别处。

如果只是大胆假设，然后就主观的拍脑袋下定论，不去一探究竟。可能都没找到真正的原因。那么，同样的问题还会再来光顾的。

 

§  “收到”的重要性

我们拿即时聊天工具比如微信来说，对方告知我们某些信息，我们至少应该礼貌性的回复一个“收到”（现在流行的是call 1）。“收到”就代表一种信息反馈。当然，信息的反馈远不止于“收到”这么简单。

不管如何，信息总是不对称的。一个项目，我把我这块做完了，需要你继续做，我告知你，你没有反馈。若干时间后，才发现，我告知你时，你并没留意，还在傻傻的等我。。

这就是信息断档，这样的场景在我们的工作中是不是屡屡出现？如果事情的影响范围小，那还有弥补的机会。而一旦事情影响严重了，那岂不是因小失大呀。我们对重要事故的复盘，十之八九得到的结论是源于团队对细节的疏忽。细节决定成败，绝非空谈！

因此，工作中，养成及时反馈的习惯吧，你好，他也好！

 

§  如何打破信息不对称

众所周知，信息不对称是不可避免的。

一个开发组里，有的同学知道开发分支，有的同学知道dubbo管理端，有的同学知道配置中心，有的同学知道vue建在哪个项目，有的同学知道需求文档地址，有的同学电脑里保存了设计文档。

需求开发完要提测了，测试同学才知道要介入测试。还有时间编写测试用例吗？被动呀！

尽管有微信、qq、钉钉，大家可以很方便的沟通。不过，正是如此，信息似乎却被打乱了。

你有没有发现，你创建完代码的开发分支后，开始的3天里，你在群里发了好几遍？因为你在发消息的时候，只是问的人在关注。其他成员并没留意。当其他成员忙完手头的任务需要来coding了，他们又来@你问开发分支。

我们谈论孩子的幸福，会用衣来张口饭来伸手来形容。其实，之于每个人，骨子里的惰性皆是如此，有其他人可以问的话，谁都愿意直接去问。

总说效率，我们的效率就是在每天的这种低效抑或无效的沟通中，一步步降低了。

那么，怎么解决这种乱糟糟的情况呢？

俩字————共享。————打破信息孤岛，实现实现共享。————借助于工具。比如公司局域网内部的wiki、confluence。如果没有，那就求助于互联网上公开的共享空间，禅道、worktile、云笔记。办公协作软件很多，只要不用再一遍遍的重复传递，都可以借助用。

§  KASH-The Secret Of Excellence

K-knowledge（知识）、A-attribute（态度）、S-skill（技能）、H-habit（习惯）

 

§  预留buffer

buffer的意思是缓冲、余量。就是指我们说话或做事，不要太绝[duì]，尽力留点余量。

在开发中，例如通过http协议调用外部Rest接口，connect timeout在绝对意义上是不可避免的，这种情况下，超时时间且不可设置得过小，例如100ms。必须要考虑非正常网络通讯的情况，结合实际业务场景，设置得稍大一些，例如2s。当然，如果你不假思索地设置成1min或2min或更大，除非极特殊或极个别情况，基本可以认定是不负责任的表现，要么就是你专业技术知识层面存在欠缺。

在工作中我们会遇到这样的情况。客户反馈问题，解决这个问题的同学，在刚一得到相关的信息后，就会武断的扬言，绝对是XXX代码 / XXX逻辑 / XXX配置导致的。结果呢，在查明原因后，发现出现了误判，打脸不？大胆假设可不是拍脑袋。

在工作中我们会遇到这样的情况。有同学暴露给下游服务的一个接口，完全信任下游提供的数据，而不做任何校验。你如果建议他加上必要的校验，他会说，下游那边都做了校验了，我还校验没有意义呀。果真没有意义吗？当下游服务在某种情况下没有控制好，导致所提供的接口出现故障时，这样的同学通常不会反思自己存在的问题，可能还会去抱怨下游对接的同学。

在工作中我们会遇到这样的情况。领导让产品经理找结算、财务、风控、技术的相关伙伴确认一件事情，产品经理立即拉群，请大家到某会议室当面沟通。我想说的是，每个人每天都有自己的工作，你要找别人协助时，至少要提前半小时预约一下吧，冷不丁地就召唤大家集合，有没有考虑到别人的感受呢？这就涉及到一个人的共情能力了。懂得换位思考的人，不会这么草率的。

同样，日常系统开发过程中，当我们需要他人支持时，比如需要他们提供一个API接口，需要事先沟通，给对方留出足够的开发时间。

 

§  万一呢？

我们做事预估风险是一个比较好的素养。程序设计阶段除了实现正向的需求逻辑，还要考虑各种逆向情况可能带来的风险或问题，罗列穷举各种风险场景，并提供方案，编码阶段，同样会补充更详细的风险场景，并加以实现。
把这些可能出现的case一一考虑到并规避掉，这是能力！

怕的是，未经过客观分析和深入思考，而是各种怀疑，动不动就“万一”呢。

例如，程序里封装的一个内部方法的参数是Map，为了提高程序可能性，废掉Map参数类型，改为参数列表的方式，相应的调用这个方法的地方也做更改。那么，对于诸如此类程序调整，只要你比较严谨，再配合互备伙伴的codereview，是不会出问题的。自信点，不会存在万一的情况。如果担心，就穷举出来这些“万一”的case，然后对代码做进一步完善。

再例如，我们在针对一些需求讨论实现方案，或对业务代码业务流程做改进展开讨论时，我们尽量穷举出来各种case，当然，如果业务复杂，或者我们对系统或业务了解不足，担心也是难免的，不过，我们的担心，一定要聚焦在当前范围内，围绕当前事情，别发散。一旦发散，那相关的case就非常多了，可是细想一下，这又有什么意义呢？这些case并不在我们聚焦的事情上呀，再者，如果不加控制会议现场，话题就会发生变化，我们的会议为什么低效，这一定是一部分原因。

 

▄︻┻┳═一想法随写：推动与拉动 and 百思得解 and 学会扭转被动局面 and 大胆假设小心求证

▄︻┻┳═一没有绝对，没有百分百