小荷才露尖尖角（68）——软件工程师个人发展中要面对的不确定性

不同于以往的任何一篇文章，这次我决定丢掉开篇先点明主题的习惯，而是先讲几个我自己在工作中的故事。

工作以来，刚开始那两年是我成长最快的时候。一个个没有见过的需求、没有理解过的概念、没有处理过的问题、没有写过的代码摆在那里，无非就是查资料、读文档、看源码、请教别人，干就对了。

一个需求交到我手里时，我说一天就一天，我说一周就一周，如果时间不够，我就自己晚上、周末加班去搞定。甚至有时为了显示自己比别人更厉害，还主动提出缩短工期。在那股冲劲之下，我很快赢得了“靠谱”的名声。

由于我进入移动开发领域比较早，三年之后也算个公司里面的移动开发专家了，就会经常被主管派去处理一些难题，比如，早期Android不支持gif，而我要把gif的动态效果显示出来；解决 络引擎中的断 重试问题和图片加载过程中的OOM问题；还有长连通道怎么保持等等。在解决这些问题时，基本的技术原理我都是知道的，但很多时候受限于设备能力，无法彻底解决。通常都是别人希望我能彻底解决，而我埋头苦干了两周，只是把问题减弱了一部分，比如，OOM，甚至有些没法解决，比如长连通道所在的进程在内存紧张时被系统杀掉。

最初开始处理这些充满不确定的问题，对我来说最难的不是技术问题，而是自己的心态：我不想丢掉自己的“靠谱”，但很多问题却又是人力所不及。周围人倒是看得开，问题存在这么长时间了一直没好，我能改善一部分，大家就觉得很不错了。于是，慢慢地我也开始淡定起来，甚至转变心态，开始从问题解决者，变成布道者，把自己的攻关过程拿出来分享，既是技术交流，也让大家看到、明白这些问题为什么会存在，以及为什么无法彻底清除。

一次偶然的机会，公司为了跟竞对之间PK，启动了一个新项目，我被调去做开发团队的TL。那时我对自己的技术充满了信心，简单问题难不住我，复杂问题我也能尽量做到比较好，更能跟上下游沟通清楚，心想，让我干个TL还不是手到擒来。

等干了半年TL之后再往回看，那段时间不但没有发挥我技术上的优势，甚至连写代码的时间都大幅减少。以前只需要专心做好需求，或者搞搞技术攻关，而做个开发TL却更像个打杂的，写Job Model、定HC数量、面试、主持需求PK、安排项目资源、解决核心项目中的风险等等。

开始时，我不管做什么事都绷着一根弦：写Job Model怕描述不清楚影响猎头的判断；定HC时，多了怕养不活，少了怕不够用；面试时，标准卡严了没法及时补进来人，放松了又怕进来之后掉队；需求PK时，把每个需求的背景、业务价值理了再理，就怕资源投进去之后没有产出，给大家都不好交待；团队中并行着好几个项目，核心项目我每天看日 ，就怕PM没经验，关键风险如果没有 出来及时灭掉，留到后面就是个大雷，砸了我的牌子。

好在，有公司核心业务的流量支持，新产品发展得不错，慢慢地，用户量上了规模，也积累了一些数据。再后面做就稍微轻松一些了，有历史数据可以参考，就算脚踏实地了，不管是资源问题还是需求价值，只要拿到数据，我就立于不败之地。这是大家普遍认可的方式，也是我一直以来的理想工作方式：No Data No BB。

当然，一年之后我很快明白，任何一句话真理都是给人挖坑的。因为，在一切以数据为指导的思想之下，我们更倾向于解决那些看得见、听得到的问题，而数据只能反映过去，不会告诉我们未来。

举个例子，我们看到很多用户在吐槽，就根据吐槽用户量的排序去优化产品功能，哪个地方用户骂得多就去优化它，最后变得越来越平庸。用户想骂你时再也找不到一个坚挺的理由了，但它就是不喜欢你。就好像你花了很大精力去追一个妹子，她给你发了一张“好人卡”，然后离你而去。

商业是残酷的，这个故事最后没有像大家期望的那样，团队知耻而后勇，然后做出一款让人痛恨让人爱的产品。因为竞对而启动的项目，最后也因为竞对而裁撤掉了，用部门大老板的话说：我们的战略目标已经达到了。

再往后，陆陆续续支撑过好多的业务，我仍然会看数据，但那只是参考，我不再被数据牵着鼻子走，更关心业务的定位、核心价值是否正确，以及我们做的事是不是在预设的方向上。

任何业务，在发展初期总会有各种各样的问题，也会有很多的用户、客户因为我们的问题而骂我们，甚至离我们而去，但是不要紧，只要我们走在正确的方向上就好了，如果他是我们的菜，总有一天他会回来的。很多时候，我们得意识到“用户是S*B”这句话特别有道理，因为他们除了给你抛很多的问题之外，啥也不懂。哎，不疯不魔不成佛啊。

写文章不带中心思想，就跟光谈恋爱不结婚一样都是耍流氓，写到这里我总结一下想表达的一些看法：

1、工作中，做确定性的事更容易感受到快速的成长，但这样的机会大部分软件工程师都只有一次，就是刚毕业入行的时候。

2、随着我们在工作中的段位越来越高，做事情过程中遇到的不确定性就会越来越大，而真正决定业务生死的往往是一些充满着不确定性的事件。拿软件产品来说，开发团队中每个人都在那里辛苦地编码，但实际上对项目最终成败的影响微乎其微，远比不上架构师对核心模型中一个关键字段放在哪里的前思后想、项目PM及时识别并处理掉一个隐藏的风险从而让项目按时上线、产品经理灵光一现的小功能、运营的一个活动玩法、老板在酒桌跟人交流之后做下的一个决策等等。

3、要把一件充满不确定性的事情处理好，不是简简单单靠数据、靠优化别人提出的问题就可以的，那些都代表着过去，对建设未来只有参考意义。我们需要有自己的方向和预判，然后根据预设去执行、观察、反思、调整，哪怕按照自己的思路而做错了，也比迎合别人而做对了，要好上一万倍。

4、在公司里面打工，没人能彻底掌控业务，每个人在一个更大的局中都是一只小蚂蚁，换句话说，只要公司给咱发工资，让干啥就干啥呗。当然，我们需要一直关注自己的个人发展路径，可以曲折、波动、螺旋上升，但不能一成不变、停滞不前。