如何提升技术解决能力

如何提升技术解决能力

在学习提升过程中，一定注重培养自己的元认知能力。所谓元认知能力，就是识别和提炼关键知识概念、并在不同环境中将它们加以联系应用的能力。提升元认识能力，从在晨会中训练一分钟之内描述完手上的技术工作开始。下面请看带来的如何提升技术解决能力！

一、基于手中的工作去拓展学习，可以达到最高效率

所有的技术提升都最好基于实际问题出发，否则如同隔靴搔痒，花了功夫还不见效。

开发同学在工作了2到3年，逐渐渡过最初需要人带的阶段后，就应该去训练自己提问题的能力。对于手上负责的技术内容，从横向和纵向去巡检有没有更好的解决方案，然后动手改进。

横向，是指对于系统的每个部件，是否有更好的方案可以替代，同步的换成异步的，语言原生的换成工具组件的，手动的换成自动的，野生的换成监控的，等等。

纵向，是指对比别人家已经走在前面同类系统，哪些地方可以去改进演化，哪些地方可以一步到位去优化，这个就需要平时大量的输入了。

另外还可以基于帕累托原理，周期性地总结造成系统功能、性能瓶颈的前20%的缺陷，这些缺陷可能会带来日常80%的问题，把它们解决掉后，下一个周期再盘点，不断迭代。

平时我也看到一些同学在学习相关拓展书籍，例如JVM原理之类。如何检验自己学的东西有没有用？把现有系统中最严重的一个JVM问题解决掉，就证明你看的那本书有价值了。

二、在学习开始之前，搞清楚学的是气宗还是剑宗

很多技术书籍资料，讲的是花拳绣腿，耍刀弄枪。这一类书，讲的是剑宗，平时不看也罢，需要用的时候，临阵磨枪也不迟。

还有一些书籍资料，讲的是系统原理，哲学文化。这一类书，讲的是气宗，不仅要看，还要多看。

选择学习内容的时候，要倾向于选“根目录”地位的资料，有助于理解延伸出来的所有概念和方法。

举个例子，如果你不习惯接受*nix家族的环境、工具和方法，甚至还在用Windows进行开发，那一定是没有读过《Unix编程艺术》（虽然书名中有编程二字，其实讲的是哲学

越是基础性的东西，越要去反复打磨使用技巧、去在工作中持续沉淀。到时候，你会发现，天下框架一大抄，反反复复抄的就是几个东西，然后你封装一套，我封装一套，各立山头，各自圈地罢了。

三、目标驱动，而不是任务驱动

每周我会阅读大量的周报，发现一个很严重的问题。很多人只是列出了一个checklist，并不是很明确地表述出要达到的goal。

如果一个同学总结工作，说我完成了任务123，却不知道123

都是为了达成一个目标而服务，就是典型的任务驱动，而非目标驱动，只见树木，不见森林。

任务驱动型的同学还有一个潜在问题，就是目标在规定期限达不成的时候，他不会去拼一拼，而是会说：下次/明天/以后再说吧。到了最后，手术成功了，病人死了。

学生做作业，有0到100分。员工打绩效，有SABCD。对于真正目标驱动的人来说，事情评价的标准，只有成与不成。

从初级技术人员，成长到高级水准，一定要跨过这道坎，一定要把任务思维转换为目标思维。

如何训练目标驱动思维？主动走近业务，不要止步于现成的设计方案，搞清楚需求的和应用的价值。目标驱动的思维，会促使你把事情做到极致。

如何引导、加强团队的技术氛围呢，建议讲四点。

一、清晰定义目标，做到师出有名

首先是业务目标。技术人员越往上走，越要关心业务目标。到了高阶段，甚至要和业务目标绑在一起。到了这个时候的思路就是，不是我会什么技术，才去做什么工作。而是完成这个业务目标需要什么样功能，我就去采取合适的技术去实现。

再一个就是技术标准。我们鼓励大家去做技术上的提升，包括采用新技术、新方案、新组件，或者去做一些重构、演进，但是要先确定好一个衡量基准，在整个提升的过程中，大家一起去促进这个度量值的提高，不仅能持续给团队带来增长信心，也能实际证明工作的成效。

而师出有名，讲究的是一种仪式感。我们要做某个方面的一揽子提升计划，就立个名号，拜一拜大将，功成之后，来个庆功大会，复盘总结。技术工作很辛苦，人生也很苦淡，技术改进犹如一场没有尽头的赛跑，需要仪式感的支撑。

二、鼓励新人超越老人，鼓励野心扩张

老人的水准，容易成为新人的瓶颈，特别是工作经验不多的新手，老人的一招一式都会成为新人模仿的对象，无论是留下来的代码，还是平时的工作方式，都会给新兵蛋子带来比较深刻的影响。到了最后，师徒几人，都是一个套路，对的也一样，错的也差不多。

针对这种问题，我的建议是，新人虽然要拜师学艺，但是一定要保持一定的更新频率，隔一段时间，追赶上一个老人后，再去挑选适合自己学习模仿的对象。

一对一式的教学，非常重要，如果老人的水平代表着新人的天花板，那新人如果要取得较快的成长速度，就要不断提高天花板的高度，不断地去向更牛逼的高手学习，甚至超越原己的师傅。

当然，作为人师，每位老人也要保持一定的成长速度才行，实现长江后浪推前浪，前浪后浪一起浪的效果。

三、杜绝保姆式开发，提倡全栈式开发

什么是保姆式开发？保姆管的是婴儿的吃喝拉撒，保姆式开发指的就是别人来承包开发写代码之外的一切事情了。可能有人会问，开发不就是应该写代码吗，产品需求有人提，测试有人做，术业有专攻啊？是，也不是。

技术人员把需求实现到位，只是最基本的要求。优秀的技术人员，会主动和产品去一起理解、梳理业务逻辑，而不是等着喂投需求文档。这样实现得更好更快。当工作实现完毕，自己需要保证交付成果的质量，而不是直接扔给测试人员，测出一堆问题再来改。

越是高阶的开发，越重视自己的名誉，会尽力保证交付成果不为别人所诟病。

遇到更严重的情况，对需求不加理解和研究，对交付成果不问质量，就成了garbagein，garbageout了。

这里所说的全栈，并不是狭义的前后端一起，而是研发从上到下要考虑到产品、技术、运营方面的问题，实现业务的全栈思维，是为广义全栈。

所谓的专业，就是节省他人的时间，让合作伙伴感到舒服和高效。

四、重视解决边界点问题，实现能力能级跃迁

什么叫边界点问题？这是我自己发明的一个词，指的是超出自己能力边界、但是自己跳一跳、努把力就能解决的问题。看图说话：当你解决了边界点问题后，能力能级得到跃迁，也就是：

解决边界点问题很痛苦，也会占用比普通问题大得多的时间，但是去挑战并解决边界点问题，是提升能力的最佳途径。

解决边界点问题，也能提升前面提到的元认知能力，帮助自己在不同领域迅速掌握关键概念并开展工作