一个程序员老兵的思考

新闻 前端
工作走的累了,不妨停下来,思考一下这一路走来的艰辛。 算一算,我也是工作时间不短的人了。 但是总是感觉工作中思路、方法或多或少有问题。 前几日和朋友几杯酒下肚,倒是聊出了一些故事,说说自己的感受,也就成了此文。

 工作走的累了,不妨停下来,思考一下这一路走来的艰辛。 算一算,我也是工作时间不短的人了。 但是总是感觉工作中思路、方法或多或少有问题。 前几日和朋友几杯酒下肚,倒是聊出了一些故事,说说自己的感受,也就成了此文。

目标&手段——引子

先来说个场景,关于电商的秒杀。

“大秒活动基本都是在整点进行的,整点活动的详情页流量会非常高,为了保证这么大的流量不冲垮机器,业内大致的做法如下:

从详情页开始就做了多层过滤。首先是垃圾请求,普通的电商商品是可以通过拼http/https下单请求参数直接下单的,然而对大秒来说,如果选择了答题,题目参数用户是无法推断的,detail会做一层简单的过滤,将这部分垃圾请求直接拦截掉;接着,由于人的操作速度限制,一秒几十次的请求会被系统直接关进小黑屋,进行若干时间的屏蔽;如果流量依然很大,采取了栅栏方式进行限流(此限流方式有运气成分,平时不会开启,只有在大促限流时偶尔开启),在系统约定的允许请求通过时间点起,会进行一个随机的时间偏移,每个请求的偏移时间不同,如果请求在偏移时间之内,不好意思,运气不好,需要再重试一次”。

在这个故事中,合适的做法,应该先关注“如何从技术角度保证秒杀可以进行”,而不是“怎么让后端服务器同时顶住巨大的流量”。两者的区别,是目标和手段的区别。如果一开始就考虑怎么顶住流量,很有可能就会因为选择了错误的方案,走进死胡同(比如有可能加数倍的机器以及让开发同学被迫去压榨已经接近极限的性能)。

在工作中也一样,首先需要围绕目标思考“ 要拿到什么结果 ”,再考虑“ 如何拿到这个结果 ”。这个概念极为重要,再怎么重视都不为过。

方向&方案

[[333161]]

方向是确定的目标,方案是自由的手段 。

城市环卫,目标是保持干净的市容市貌,而不是雇佣和管理成千上万的清洁工,后者只是一种实现目标的方案。

日本采取了另一种方案,就是做好垃圾分类,做好卫生教育,结果却比绝大部分国内城市做得好。对于清洁工个体,也一样:可以选择早出晚归勤扫不辍,也可以选择多搞几个垃圾桶,放 在垃圾源边上。

“不管黑猫白猫,能抓老鼠的猫就是好猫”,是关于“方向&方案”的最好辩证。在这里,“抓老鼠”是目标,是好猫的标准,而不是长得萌或其他;在这个标准下,黑猫白猫都可以是好猫。

无论是公司CEO,还是清洁工,在目标确定的情况下,手段的选择是自由的。清楚这个概念,工作思路可以开阔很多。可以问老板要方向,不要问老板要方案。方案是自己弄出来的,能想到leader想不到的方案并做出来,就是我们牛逼,才能体现自己的价值。更进一步,理解目标更能帮你站在leader的角度看问题,才能及时补位,超出预期。

结果&过程

[[333162]]

结果是衡量工作好坏的唯一标准,而过程不能完全拿来衡量工作好坏 。

在业务上,说“用户是上帝”,说“用户永远是对的”,因为“用户感知是检验工作好坏的唯一标准”。一个事情做得好不好,不是由你的出发点、动机和付出多少努力所决定的,而是你的用户的感知所决定的。之前在前一家公司负责过公司内部系统流程的移动审批接入。上线之后接到不少同事的反馈说体验不好, 手机打开审批流程慢。老板找我聊,我也解释了不少,说作为审批网关性能实际上和内外任务中心以及下游业务方数据实时获取都有关,但老板的意思很明确, “对于用户而言,主观即客观”,用户主观觉得这个产品不好,那就是不好,没什么可说的。去想办法改进才是正道。另一个角度来看,只有用户可感知的,才是有意义的。这个话我说的稍微有些极端,但是并非没有依据。我们很多人平时都是很忙。早上PRD, 下午技术方案评审,明天kickoff。但是这些只会产生结论,并没有产生结果。这些“结论”,用户都是没有感知的,并不能让我们的产品和服务让更多人知道,让更多人喜欢。在这些“结论”产生结果之前,所有的开会、讨论、分析,都是无用功。极端一点讲,都是成本,而不是成果。

没有借口,说到做到

[[333163]]

说到做到,是最大的靠谱 

我遇到过很多这样的场景。身边的很多同事,包括我自己。总是喜欢为自己找借口。我们总是会说,项目晚上线, 是因为临时出了bug,是因为临时有新项目插进来了,是因为对方联调的同事请假了,然后会把话题转移到自己有多么多么辛苦。

岔开说个小事。我自己很多时候对于时间很偏执。有朋友说过,“所有关于迟到的理由都是不成立的”。所以我总是很在意时间的规划。比如我去每次去机场都会详细的规划好时间。比如晚上九点半的飞机。那我估计多长时间候机?以往在路上大概多久(比如一路畅通从武林门机场大巴站到萧山机场需要27分钟)? 如果晚高峰预留多少时间合适?我需要多长时间能打到车?等等。

总有人说,哎呀,路上太堵,运气不好连续碰到红灯,所以迟到了——你总是掐点出门,当然会迟到,不是今天迟到就是明天迟到。你怎么不提前半小时出门呢?你不能默认一路通畅啊,你应该默认路上会堵啊——做项目,你应该默认有困难啊,怎么可能预设没意外呢?怎么不预备好解决突发问题的资源呢?

困难及不确定性,是需要我们克服的东西,不是在开始之前,就预设为事后“完不成的理由”。一旦有这种预设,就完了,就从一个“行动者”变成“解释者”了,精气神就没了。的确,是有所谓的不可抗力,但99%被称为不可抗力的东西,都不是不可抗力。之前有句流行的话,“以大多数人努力的程度,根本还没到拼智商的地步”。一样的,大多数人面对的困难和不确定性,还远不到不可抗力的程度——还没“尽人事”呢,就“听天命”了。

在上一节说过, “ 只有用户可感知的,才是有意义的 ” 。所做的努力和投入,如果没有最终实现并传递到用户身上,就是成本。没有完成目标,就是没有完成目标,没什么可多说的。结果导向的意识形态,就是“ 没有借口 ”。

从终点出发

[[333164]]

小孩子刚学写文章,总是想到哪里写到哪里;高手写文章,都是先列提纲再动笔的。 

我们在用手机地图导航的时候,第一步都是先输入目的地。然后地图会给你几条路线的选择,再看是打车还是公交车。这里面隐藏着一个道理,就是“倒着做事情”。所谓“倒着做事情”,就是在设置行动路径的时候,从你想要达到的结果进行倒推,而不是根据眼下的情况决定行动方案。上一节说到,为了避免迟到,就要从上班的时间倒算,来定出门的时间、起床的时间;而不是先看几点钟起床,再看什么时候能到公司。

拿我们程序猿来说,我们经常犯的错误,就是接到一个需求,心里感叹一句卧槽这很简单。一个早上的时间便已经写完调试然后发布了。结果发生需求变更说要加一个信息自己就懵了, 告诉PD说这个改动很难可能要改动整体的架构。或是当生产环境发生了异常我们没有做好足够的容灾结果眼睁睁的看着一个小问题变成了一个故障。这里其实是一个基于问题的假设。分析能力的提升,不是学会多少分析的方法,而是掌握正确的分析思路。

跨团队合作中,结果倒推尤其重要。主导一次合作,不是等对方完成一个项目,再看下一步,而是应该直接约定好项目节点,推进事情。不是“等你做好这个,我们再约个会讨论那个”,而应该是“下周三我们一起开会讨论结果吧”。这里有一个好处,就是利用好“ 来自目的地的张力 ”,以此倒逼自己和团队,提升效率。

以对方为准

[[333165]]

"沟通最大的问题,在于以为沟通已经发生" 。这是我现阶段遇到的一个很大的问题。

常常听到团队关于沟通的抱怨,“我跟A说过这个事情的,但是A太不靠谱了,到现在都没有做好”。出现这种情况,通常不是A不靠谱,而是在跟A的沟通中出现了问题。沟通容易犯的错误,就是从自己(沟通的发起方)的动作出发,而不是从对方(沟通的结果方)的接收以及接受出发。

举个栗子。

有次项目, 我在发布前给项目组发了邮件。邮件中指明了某同学在发布前需要将本次涉及到的sql初始化脚本在准备预发时提供给我。结果当天我去要的时候得到的回复是:“我不知道啊?你跟我讲过了?”,我顿时火了:"你特么不看邮件的?"

类似的还有。打车的时候,司机电话说“我在马路右边”,我就会非常恼火,你说东南西北还可以,我又不知道你的朝向,鬼知道你说的右边是哪边啊?发一个通知,说“这个我已经发过群里讲过了”,这只是“讲过了”,却没有保证对方已经了解情况,万一对方电脑坏了呢?“这个模块的接入我们已经讨论过了,但是没法统一结论”,讨论是讨论了,但是双方数据口径的定义是一致么?

另外需要注意的是,要资源、要指导、同步信息,不同的目的需要不同的沟通方式。对谁讲、讲什么、怎么讲?对方了解背景知识吗?对方有什么样的立场?对方可能会有怎样的质疑?我说的对方听得懂吗?是直接了当讲,还是旁敲侧击讲?是用邮件正式沟通,还是电话沟通?是群会沟通,还是1对1沟通?这些都是沟通之前需要自己问自己的问题,并从对方的角度来获得答案,而不是无差别 的 从自己已经习惯的沟通方式和风格来推进。

沟通最大的美妙之处,在于达成共识;而我们常常获得的,是已经达成共识的幻觉。正确的沟通,是拓展影响力的最佳方法。沟通中,要确保信息对方已经接收了,在达成共识的过程中,要确保对方已经接受了——而不能止步于,“反正我已经说过了啊”。

搁置&反馈黑洞

[[333166]]

最后来说说我认为工作中两件最忌讳的事情。

搁置

遇到问题就搁置,职场第一大忌讳。 某件事情被分配到了你的头上,你就要把它解决,躲是没有用的,想方法!哪怕你再讨厌,再反感。

反馈黑洞

积极沟通是第一要务。

这件事情我有深刻的感知。程序猿相对来说是一个比较沉默孤僻的群体。我们大部分人其实不善于沟通。但是我认为沟通恰恰是工作中的第一要素。不沟通,不主动坦露自己的信息,不管本身实力有多强,在团队中总是会遇到各种问题。说的狠一点,沟通能力就像木桶原理中那块最短的板子,严重制约着我们的发展。

结语

[[333167]]

结果导向思维,其实是“反人性”的。人条件反射的就会从“临近的”、“熟悉的”、“具体的”起点的角度来思考和做事,而不会从“遥远的”、“对立的”、“抽象的”结果来进行规划和执行。

在日常工作中,更好的落实以结果为导向,就必须事前清晰到极致的明确结果定义,将责任落实到一对一,这样在过程中才不会倦怠和推诿,同时也就能更清晰的对目标和责任的实践情况进行准确判定。做出结果,做出事前定义的结果才能不惧质询,才能做出成就、实现价值。

尝试改变,发现不一样的自己。

 

责任编辑:张燕妮 来源: 猪厂学习鸡
相关推荐

2012-11-12 10:46:37

2020-02-22 21:51:43

程序员Microsoft SServerSQL

2012-12-17 10:50:27

程序员

2012-10-22 14:17:42

函数式程序员

2014-01-06 09:33:32

程序员管理

2020-10-05 21:13:37

程序员技能开发者

2011-02-14 13:05:17

PythonWeb

2015-06-08 10:48:39

程序员程序员自白

2015-06-16 10:31:36

程序员

2021-07-01 07:43:41

项目程序员代码

2013-07-25 09:47:40

程序员职业发展

2013-07-09 09:11:50

程序员

2019-11-07 15:30:00

EmacsIDE

2010-10-18 11:39:41

程序员

2015-05-13 14:06:03

程序员糟糕的程序员

2020-01-06 09:53:29

程序员

2015-08-24 10:07:13

程序员bug

2019-04-22 10:25:52

程序员技术职场

2009-02-12 15:07:57

程序员创业经验

2012-04-12 14:49:31

程序员
点赞
收藏

51CTO技术栈公众号