设计模式_23
这个问题太有感触了，不熟悉业务当然做不好系统，但业务理解的深度与技术能力并没有直接的对应关系。
我们先讨论一下另外一个问题：
技术人员创造的价值是什么呢？我们的技术最终体现某一个商业的业务上，解决用户的问题，从而创造价值。我们去面试，去找新的工作机会，目的是更好地实现自己的价值，目的并不只是换个涨点工资的工作。比如王争老师，现在也是在教育的这个具体的业务上闪闪发光。

这里引用一下吴军老师的“五级工程师模型”

> 第五级：能独立解决问题，完成工程工作；
> 第四级：能指导和带领其他人一同完成更有影响力的工作；
> 第三级：能独立设计和实现产品，并且在市场上获得成功；
> 第二级：能设计和实现别人不能做出的产品，也就是说他的作用很难取代；
> 第一级：开创一个产业

可以看到，在更高级别的工程师中，对于产品和商业的理解变成了一种要求，因为他是技术与现实生活的桥梁。

课堂讨论Answer：

钻研业务与发展技术的取舍（或精力分配）取决于其风险与收益。

如果公司基本面良好，业务蒸蒸日上，我个人受到领导的认可，同事的尊敬，则倾向于将更多的精力钻研业务，提升个人在公司的不可替代性。

如果公司基本面恶化或前途未卜（比如大多创业型公司），领导本领低微或不重视我的意见，和同事相处一般，则应将大量精力分配在技术精研上，提升个人在就业市场上的竞争力。

最后，钻研业务和提升技术并不是一枚硬币的两面，如果一些事情上同时满足两种需求，就再好不过。

课后讨论
1.业务是专业资源（复用受限），技术是通用资源（复用不受限），所以业务知识的沉淀对于个人是一个风险比较高的投资，所以大部分人本能的就会讨厌这种受制的局势，进而就不喜欢在业务上投入太多的精力。

2.其实我觉得很遗憾，大部分程序员会规划自己的技术栈却不关心干什么活（做什么业务）。当然，业务知识不好考核，技术知识好考核，所以技术知识在面试吃香也是必然。不过可以遇见的情景是：招了个技术牛逼的人，但短时间他产生不了什么价值（需要了解业务），等到他吃透业务（半年甚至一年），他的技术水平已经又上了一个台阶，面临新一轮人员调动的开始。结果就是，一个技术很牛逼的人，在我这个项目组干活期间，不显山不露水，资深的水平干着高级的事，我还知道这合情合理，等他开始发挥资深水平价值时，人走了。

3.产品技术其实是一体两面，如果有产品思维，那么业务领域的选择和技术栈的选择其实是绑在一起的。走在自己想干的业务领域，自己的技术栈也跟着这个领域的需求去发展，如此以来每份工作的业务积累都能为下份公司带来大量点子和突破口。但这样就会出现，高级的水平干架构师的事，但一般没公司为你带来的“架构师级价值”买单。目前的情况是欢喜的接受你带来的改变，但并不会为你加薪（因为你的技术水平在市场只值这么多，公司给你的钱会尽量平衡在市场线，而非你真正的价值）。这种病态得不到改善，程序员不重视业务就得不到变革。所幸当下，跑马圈地已过，抢人已经不再疯狂，招聘方的招聘目标也在慢慢从技术牛逼到实际价值转变。