问题解决者

做了leader之后，撸的代码少了，心中的焦虑感却上升了。本想等业务稳定了，就可以沉下心来写点代码，优化下代码结构。现实却是业务升级，花在沟通和方案上的时间就更多了。从结果来看，事情的完成没有偏的。那问题出在哪呢？我的焦虑还是要解决的嘛。肯定是自我定位上出问题了。我定义的程序员就是写代码的。不写代码或者代码写的少了，我就不合格。

闪念

那我应该如何定位呢？那我反问自己这个问题的时候，我第一反应是，“解决方案者”。因为互联网有很多解决方案公司，作为互联网公司的基因，我们应该就是“解决方案者”。但是感觉挺拗口的。我就重新命名为“问题解决者”，花名“问题推土机”。想到这个名词后，瞬间有种豁然开朗的感觉。

问题一：“深度”或“广度”

我在一个学习群里收到过这样的言论:“我感觉我们公司一点技术含量都没有，天天做业务，感觉一点成长也没有，我想去搞架构，技术驱动的公司”。我就反问他，你不懂业务做架构为谁服务？公司不做业务，用啥来养活你？你做业务没有成长，是因为你觉得你不需要成长，而不是业务无法让你成长。

很多同学在技术深度、广度上有疑惑。其实我一直以来也有。开发者的思想，一般都比较认可应该往深处走。这样才是正道。每样技术浅尝辄止，显得很不专业。但是又发现，自己年复一年的再想如何深入，却没有时间和业务场景去深入。人的时间和精力是非常有限的，撇开工作驱动来谈技术深度，基本不可能，那些所谓深度都是纸上谈兵。那这个问题，如何解答。

从定位上解答。 初级工程师 ：不要想深度和广度的事情，如何高效有质量的完成编码工作，是核心生产力。 高级工程师 ：高质量高效完成编码工作是你的基本功，需要额外加大精力钻研技术深度，来提升自己的专业度。 资深工程师 ：如果执着于深度，应该采用轮岗到其他部门去应用底层或其他技术。如果不执着，则可以多扩展新技术，来多方位促进业务发展。 问题解决者 ：不需要考虑深度、广度的问题，而是结果导向，如何服务业务。通过所在业务需要，反推应该采用的技术。通过扩展技术广度，看能否应用到业务。为何没有纯技术方向的？因为我觉得那是研究院的事情，公司没到一定阶段，投出产出比不够高。

问题二：团队工作积极性问题

最近讨论过一个问题，为何业务团队的工作积极性和主人翁意识高一点。有一个观点是，业务团队的目标会更加清晰。目标感抢才导致的队员奋力拼搏。

我仔细想了一下，好像并不是，大部分业务指标我已经忘了。且我们的目标真的足够刺激我们的队员吗？并不见得，因为目标的相关性还是有缺陷的。如果是完成目标，奖1W。嘿，那效果肯定是好的。

那是什么导致的业务团队的积极性强呢。我觉得是我们的定位。因为我们的业务开发把自己定位为“问题解决者”、“问题推土机”。在解决无论是需求不明确，临时紧急调整、还是需求过饱和等问题，我们都是采用“先解决问题”，再反向推进流程优化和技术优化。这有什么好处吗？我的最大的好处就是，传统的项目方式容易产生，技术瓶颈了，业务就比较难推动了。在业务强行要推动的时候，就出现很多类似“因为这样实现不优雅，这样实现比较恶心”等理由。久而久之，有一些不是不优雅，不是恶心的需求，也被列入到了这个理由中。这对业务来说就不优雅了。业务团队自我认可的点，不存在类似“虽然业务发展的不好，但是我们的技术还是很强的”或者“虽然业务发展的不好，但是不是我们导致的”这类理由。只有把业务搞好了，才是自我证明的最好理由。

总结

我是个武侠迷，我也一直觉得，程序员就是江湖里的侠客。要成为一个武功很高（技术很牛）的人。心法（深度）很重要，招式（广度）也很重要。下山历练，闯荡江湖（实践）对自我的提升最为明显。而最终发展到哪里，还是得看自己的定位。如何定位，“问题解决者”可以帮助你。解决意外被杀的问题--陆小凤。解决国家问题--郭靖。解决世界问题--复仇者联盟。让自己成为一个移动的强大的解决方案库，应该能解决我的焦虑。定位清楚了，那一口一口吃饭就可以了。

题外

拿着“问题解决者”去网上搜了一下，发现有很多对这个名词的解答。最能激励我的，就是《李嘉诚勉励年轻人:要做未来想象者和问题解决者》。我相信我的方向对了。