稻盛和夫的《干法》结合工作读后感

 从如下几个方面和大家分享一下 IT 从业人员的心声：

• 思维方式
• 学习与提升
• 职业发展路线
• 跳槽和卧槽
• 总结

思维方式

记得在稻盛和夫的《干法》一书中，对于人生和工作给出这样一个公式：

人生(工作)的结果=思维方式热情能力。
公式中的“热情”可以理解为“努力”，分数从 0 到 100 分。“能力”可以理解为智商，情商，组织能力，表达能力，健康等等，分数从 0 到 100 分。

“思维方式”与其他两个不同，它的分数是从 -100 到 100。这也就意味着“思维方式”有可能为负数，如果它为负数的时候，付出的努力越大，拥有的能力越强，就越有可能得到相反的结果。

我常常在反思，在平时的工作和学习中，是否运用了正确的思维方式：

• 程序出现 Bug，是找到原因并且进行总结，还是埋怨项目进度太紧，系统混乱。
• 遇到需求不清楚的时候，是努力整理问题列表，还是抱怨产品经理不专业。
• 当受到老板/客户的非议时，是积极倾听采取改进措施，还是怨天尤人。
  有人说程序员只要专业知识过硬就够了，其他的不用过多考虑。这种说法“正确”，也“不正确”。

专业能力是进入 IT 行业的门槛，在进入之后还需要在各个方面不断的打磨和提升自己。

平时的工作就是在不断发现和解决问题，能否在这个过程中受益，思考就显得尤为重要。

职业生涯开始的几年，我是在摸索中度过的，对工作的意义也不太清晰，感觉写代码就是一个赚钱的营生。每天想的是，快点把手上的任务完成，下班以后打打游戏，刷刷剧。

测试同事给我报 Bug，能推就推，说：“这是操作问题，不是程序的问题”。对于经理报上来的需求尽量，都会说：“难度太大，需要更多的时间”，各种理由搪塞。

久而久之，发现自己在原地踏步。于是，通过观察身边优秀的人和通过阅读书籍来找答案。

《终生成长》一书中提到了，人有两种思维模式，一种是固定型思维，另一种是成长型思维。

拥有固定型思维的人认为自己不需要改变，保持原有处理问题的方式，需要改变的是外界。

而拥有成长型思维的人认为，需要不断调整做事的方式，来满足不断变化的世界。
特别是当今是一个复杂，多变，不确定的时代。程序员更应该拥抱变化，迭代自己，专注思考。

学习与提升

学习提升的道路有很多条，基本上分为自我学习和向他人学习。

自我学习

很多时候为了学习专业的知识，我上网翻看 Blog，关注微信公众号的推文。遇到工作上的问题，打开搜索引擎用最快的方式找到答案。

习惯了享受快餐知识带来的愉悦感。甚至不清楚复制粘贴代码所表达的意思，看过大神文章也不得要领，只有不明觉厉的感觉。

古人讲究“观，为，得”。大多数情况下，我们做了“观”的事情，知道有这个知识，大致知道如何使用工具，但没有形成自己的知识体系。

要在“观”的基础上，自己把知识的前后关系梳理一遍，在知道 What 和 How 的同时知道 Why。

将每个知识点做好笔记，保存下来，下次遇到有关联的知识时，对照起来参考。这才做到了“为”。

最后，把每个知识点串联起来，形成线，再将线变成面，讲给别人听，或者将其形成文章分享给大家，这样才能做到“得”。

如果把每次遇到的问题都如此总结，周而复始技术/理解能力会有明显的提高。

特别是有几年工作经验以后，需要针对基础的计算机知识进行系统的学习。因为基本的编程技巧和工具都离不开这些基本原理的支持。

例如：数据结构，组成原理，数据库设计，设计模式，算法。在这个过程中可以对知识进行重新梳理，分类，站在更高的位置审视所学知识。

向他人学习

记得在《易经》中有一卦叫做“比”卦，意思是要“亲比”他人。在任何一个组织中都有领袖，也是需要大家辅佐的对象，比如：项目经理，技术组长，架构师等等。

“亲比”的意思是围绕在有能力的人周围，辅助他们，同时从他们身上学习知识，技能和经验。

你注意观察你身边的人，包括家庭，公司和学校都有你“亲比”的对象。在他们身上有很多闪光点，是值得我们学习的，甚至我们会希望成为像他们一样的人。

把他们作为自己的目标，结合自己发展的方向(Java 架构师，项目管理)，列出学习条目(架构设计，项目管理)。

以半年为期限，定时去查看目标是否实现，还有哪些需要弥补的。时刻提醒自己目标，能否成为你理想中的那个人。

之前项目组有一个程序员的 Bug 很少，于是我就学习并且模仿他的编码风格，半年以后发现我的代码质量有了明显的改善。

除了学习人以外，GitHub 上面一些开源项目也是学习的对象，看看别人如何构架系统，如何使用设计模式，对自己的工作也是启发。

模仿是最好的老师，久而久之结合自身的特点就形成了自己的风格。

如何检验学到的知识

检验知识的方法有很多，例如：今天学到了编程方面的知识，应用到工作中就可以检验是否成功。

这些检验的方式是有特殊场景的，从问题到解决方案，是被动的验证方式。

如果说在日常工作中没有那么多的问题需要解决，而又需要检验学习的知识，那应该如何操作?

这里分享一种主动验证方式，从学习知识到教授知识。在开始学习的时候，就要确定学习目的是：要教会别人也学会这个知识。

也就是，学习完成之后，你就是关于这个知识的专家了，有责任教会其他人搞懂这个知识。

如此这般，才能在学习过程中对知识精益求精。具体过程可以这样：学完某种知识以后，用自己的话，对着镜子复述一遍。刚开始的时候会结结巴巴找不到要领。

不过不要紧，针对不清楚的部分，回去查资料，再进行演讲。直到演讲的过程顺畅为止。

此时，已经有点信心了，可以找三五个好友，对着他们演讲，此时会有点紧张毕竟有了观众，可以准备简单的 PPT 帮助梳理和回忆。

接下来，再找机会在公司内或者小组内做一次分享。逐步扩大分享的范围，在每次分享完毕以后，做个总结，针对演讲中不熟悉的地方，再进行补充。

这是一个不断自我完善的过程，期间可以形成自己学习的体系和方法，锻炼组织，演讲能力。

同时，在不断扩大范围的过程中，会得到不少反馈，使你对知识的认知的程度不断提高。

最后，在时机成熟的时候可以发表一篇文章，对其做一个总结。整个过程不但验证了知识，还会成为某个垂直领域的专家，提高专业知名度。

职业发展路线

职业发展路线是经常被提到的话题，针对不同阶段，职业规划是不同的。刚刚进入 IT 业的同学，可以考虑掌握一门“安身立命”的技术。能够养活自己，并且有成长的空间。

开始时候可以涉猎多一点技术，在其中选择一个觉得“舒服”的技术坚持下去。前几年读过一本书叫做《逝去的武林》，讲述的是一位老者 40 年学武的经历。

其中有一段讲到，他刚开始学武时，他的师傅教了他好几招。然后问他：“哪一招，练起来最舒服。”他回答师傅以后，师傅就要他只练“觉得舒服”的那几招。

一年以后，才教他其他招式。他问师傅为什么。师傅说：“招式虽然变化多端，但底层原理是不变的。如果有几招已经精熟了，那么学习其他招数也就易如反掌了。

反观，学习 IT 技术不也是这样吗?学习那么多的编程语言，他们之间的底层原理都是相通的。分布式架构，通讯方式，设计模式，在思考方式上也有互通互联的地方。

所以，初进入职场的 3-5 年可以在一个垂直的技术领域深耕。精通以后，再选择后面的路如何走。

除了技术能力，综合能力也是必不可少的。例如：演讲，写作，沟通，管理。不管今后是往技术方向还是管理方向发展，这些技能都能够帮到你。

所以，在适当的时候需要锻炼自己的综合能力，比如：

定期可以进行技术演讲，把技术干货分享给同事。
将平时工作中遇到的问题，写成文章分享到网络。
读几本心理学书籍，学会如何和人沟通。
定期在网上学习管理视频。
在学习专业知识的同时，也要获取其他领域的知识，丰富自己的知识体系。

有了好的开始，那么具体的发展有哪些路可以走呢?下面列举三条路线供各位参考。

技术路线

程序员→中级程序员→高级程序员→技术经理

这是一条技术发展路线。随着开发经验以及对架构的理解，可以先往中级工程师、高级工程师岗位方向发展。

刚开始的时候关心如何编写出代码，减少 Bug，实现功能，通过模块测试;而中、高级程序员需要从整个项目出发，考虑如何编写模块，算法。

之后，可向技术经理的方向发展。在担任工程师阶段，积累了大中型项目的经验，也熟悉了技术标准、技术规范，学会编写、审核各种技术方案和文档。

同时具备编写软件核心代码、处理软件故障和领导团队的能力，基本达到了技术经理的岗位要求。

技术经理之后，可以往技术总监、CTO 等岗位发展，这些岗位的要求会更高，因此在编程过程中要注重其他方面的积累，如算法思维、测试方法、技术文档、技术团队管理等。

管理路线

程序员→中级工程师→系统架构师→项目经理

系统架构师是一个要求兼具沟通能力，设计能力和技术能力的岗位。技术是基于业务的，因此要对业务有深入的了解，需要与客户、产品经理、技术人员、项目经理等都保持良好的沟通。

针对业务场景，设计规划系统架构和应用场景、解决开发过程中遇到的疑难问题;还要提高开发质量，推进开发进度;也要协助管理技术团队，做好技术文档、说明文件等工作。

项目经理是软件项目的组织者和领导者。对内要组织管理技术团队，制定开发计划、测试计划、培训计划、量化任务等;解决开发过程中出现的问题，保证软件按照进度推进;做好技术文档、说明文件的存档工作等。

对外要与客户沟通，了解、完善、修改需求;要与公司沟通，及时汇报项目进度、工作情况和资源需求;要做好市场调研，及时调整技术方案等。

程序员如果具备很强的沟通、设计和团队管理能力，可以考虑往管理路线发展。不具备这些方面能力的程序员，可以多考虑技术管理方向发展。

系统架构师和技术经理在工作内容上有一些区别。架构师对内负责技术架构，对外需要和业务沟通;技术经理多会专注于内部的技术规范，技术标准的制定和执行。

产品路线

程序员→产品助理→产品设计师→产品经理

在日常工作中，你会发现有些程序员，对产品设计、产品管理有很好的想法。

那么他们已经具备了产品设计的基础能力：对产品理解、功能逻辑有思路、有判断。

程序员往产品方向发展，有自己的优势和劣势：

优势是：程序员知道程序开发的过程，熟悉功能实现的方式。站在产品的角度能够和开发人员有良好的沟通，对产品的开发周期、实现方式、故障判断等都可以很好的把控，使产品在技术层面出现的问题尽快得到沟通解决。
劣势是：程序员在客户需求分析、市场调研、产品设计、产品管理、运营分析、用户培训等各方面要从零开始学习，这是需要一定时间的。
如果要往产品方向发展，大部分需要从产品助理开始，不仅要保持住自己优势的地方，还要一步一个脚印学习、积累，逐渐消除自己的劣势，往产品设计师、产品经理，甚至是 CIO(首席信息官)方向努力。

跳槽和卧槽

程序员由于职业特点决定了是一个跳槽比较频繁的职业。特别是这几年社会对 IT 技术的需求量逐渐增大，对程序员的需求也在增大，这也导致整体行业跳槽比率偏高。那么什么时候该跳什么时候不该跳呢?

我在网上找了很多文章，发现有好多原因可以被考虑，例如：自身发展，公司发展，行业发展，老板魅力。

其实，归根到底说的都是，你现在的工作和你想要的工作之间的差异。新的工作是否给你带来更多，包括薪水，发展，平台，人脉等等。

这里介绍工作特征模型，通过这个模型可以针对不同职业阶段进行打分，最后再做出判断。

如果分数呈现上升或者平稳趋势，建议“卧槽“获取更多能量。如果分数有下降的局势，建议根据职业发展方向，找新的工作。

工作特征模型，需要定义几个特征变量，每个变量定义 0-10 分，分数越高说明和特征越符合，将每项打分完毕以后带入到一个公式中，得到最终的分数。

①技能多样性(Skill Variety)。工作中使用的技能是否多样，是否需要多种技能才能完成工作。

很多情况下，我们说的“搬砖”，是一种技能单一的表现，利用现成的技术并且不断重复类似“增删改查”的操作，让人感觉每天都在重复自己。

相反，如果工作中涉及到技术面比较广，类似全栈工程师;又或者需要做横向/纵向沟通以及管理协调的工作，就会让人充满了新鲜感，保持职场的活力。

②任务一致性(Task Identity)。需要完成的任务和实际完成的任务是否一致。

例如：领导给你布置系统架构的任务，在实施时你才发现做的都是一些“救火”的事，对系统的修修补补。

只有保持任务的一致性，才能让你的目标和结果保持一致，增强获得感，不断提高工作能力。

③任务重要性(Task Significance)。这个不言而喻，如果你现在的工作非常重要，是公司盈利的核心或者是公司未来发展的方向。

那是非常好的事情，和公司的发展保持一致，会获得更多的资源，更容易把事情做好，成长也是最快的 。

④自主性(Autonomy)。工作内容，工作形式是否能够自己控制。例如：每天上班是否打卡，完成的工作都是别人指派给你的，还是你自己主动承担工作的。

越是有自主性的工作，越能提高员工的工作动力，大家都盯着一个目标前进，会想尽办法把事情做好。

⑤反馈性(Feedback)。你做的工作是否得到了正向的反馈，这种反馈可以来自同事，客户，领导。

只有不断的得到反馈，才能修正自己提高自身的能力。同时只有自己的工作成果得到反馈才能激发下次完成任务的动力，驱动自己不断前进。

最后将上面的特征变量带入下面的公式，就知道最终的得分了：

这个分数的计算是一个长期的过程，每隔一段时间(1-2 月)，可以给自己进行一次评价，这样一段时间下来会形成一个曲线，通过曲线的上升和下降就知道在当前的公司是否有利于自己的职业发展了，从而确定是跳槽还是卧槽。

总结

程序员的自身发展，需要有正确的思维方式。成长型的思维模式能够帮助自身不断迭代。在学习过程中需要注重自我学习和向他人学习。

自我学习，讲究“观，为，得”，知识不是知道就完了，还要去实践，思考，最后才能够掌握。

向他人学习，要找好你的学习目标，设置时间限制，用先“学习模仿“，后“自成一派“的方式推进。

职业发展，先找到突破口切入，深入以后再触类旁通。可以根据自身条件，选择技术，管理和产品的方向。

跳槽与否，不要凭感觉，用科学的方法论来指导。多样性，一致性，重要性，自主性，反馈性是需要考虑的关键点。

来源：https://blog.csdn.net/yhc166188/article/details/104081827