发表于：2022/7/21 15:27:26
#0楼
0721 【万泉河】论工控行业中的教会徒弟饿死师傅
教会徒弟饿死师傅，这是中国传统的警世名言。 所有人都懂。
在咱们同行之中， 也有很多人秉承了这样的理念。即， 自己做徒弟的时候，各种讨好，伪装，千方百计从师傅那里挖掘到尽可能多的技能，以尽可能早的脱离师傅的掌控，自己可以独立行走江湖。 而当自己摇身一变做了师傅， 也收徒弟的时候，则小心翼翼保全自己的核心技能。 只把简单的技能教给徒弟，让徒弟帮自己跑腿递烟递茶，通过各种角度审查徒弟的忠诚度，视对其信任的程度， 逐渐放出更多的料喂哺徒弟，让他一直有求于己，而不敢轻易叛变师门。
这种师傅/徒弟的传承关系，源自于古代商业社会的工匠族群。 通常师傅就是一个社团的绝对权威和老大，师傅同时掌握了专业技术以及整个组织的经济大权，也掌握了对每一个成员的生杀大权， 只要不犯罪，至少可以随意把任何一位不够绝对服从的成员驱逐。
而到了现代社会， 这种工匠行业师徒传承关系就被大大削弱了。 通常来说，大家都是学校毕业之后，应聘到一家公司，成为同事。 然后同事之间，就有先来的，后到的。年长的，年轻的，经验丰富的老手，没有经验的新员工。
通常， 师傅与徒弟之间并没有什么紧密的关系。 会有一些工厂，班组有新加入的成员时， 领导会指派某位老手作为师傅带一阵子。 一方面技术上给予一些辅导，而更主要的还是对企业文化，管理流程，以及对机器设备行业工艺等方面的入门指导。
这种情况下，师傅对徒弟并没有经济的一票否决权， 也更没有权力驱逐或者自己另选徒弟，所以师徒之间的关系只剩下了纯粹的技术辅导。 然而如果局限于工厂范围内的工作， 一项工作，如果徒弟学会了， 师傅可以安排徒弟做，自己只在边上监督审核把关。 而如果徒弟学不会， 那么师傅就要自己动手干。关系反而倒过来了，成了教不会徒弟， 累死师傅。 没有完成公司安排的带徒弟的任务，某种程度上师傅反而要被考核，批评。
除此之外，很多工厂内部， 同一个班组的同事之间，私下里也会有一些拜师结对的传统。新来的员工出于对自己技术水平快速提高，以达到快速融入公司的目标，私下找一些比较优秀的老员工请教，并逐渐正式或非正式地成为师徒关系。这种情况下， 师徒之间的利益关系也很小，顶多会在过年过节期间，徒弟给师傅送点礼，平常徒弟多请师傅吃点饭喝喝酒，之类。
然而这种情况，并不通用于所有人。因为有能拜到师傅的新员工， 也自然有没拜到的。同时如果是新厂，或者厂内人数少，同专业就自己一个人，即便想拜师也根本无师可拜。
那么， 这些人就只能利用自己在学校学习的知识，结合工作的实际需要， 自己主动学习技能。尤其现在互联网时代， 知识的流通非常便捷，未必需要师傅传授， 有疑问的地方， 通过学习各种技术资料，视频或者请教他人等，都可以获得。
尤其是从事设计工作的工程师，工作本身带有极大的创新性工作，如果公司和行业内有可以借鉴的资料，可以直接从中吸取营养，或许可以有老工程师给予一些建议指导，而如果没有可以依赖的老工程师，那就只好硬着头皮自己从头摸索着做。过程中会经历比有师傅的宝更多的辛苦，然而只要成功完成任务，收获反而比对方要大，进步要快得多。
所以，同行之中至少有两类人， 一种是入行有师傅， 一种是入行并没有师傅。 当然还有一种人会是自己入行没有师傅，却后来有收徒弟。
有同行跟我咨询烟台方法的学习的时候，提出了疑问和顾虑：假设将来我学习了烟台方法做出标准化的更好的程序设计， 那么应该如何对待公司同事？是对他们保密还是把方法技能传授给他们？如果教给他们， 会不会回到教会徒弟饿死师傅的诅咒？
我的回答：
学习烟台方法，最后实现的当然是公司内部的设计标准化。这一点理解非常正确，我已经重复强调了几十回了。 有同行理解成我要推行大一统的通杀整个工控行业的标准程序，最后让所有同行一方面都失业无事可做，另一方面不再需要自己动手编程。 这既想的太美了， 又太坏了。 没这样好事，也没有这样的坏事。
然而来跟我学习的每个工程师， 如果能掌握先进的高效的设计编程方法， 设计出来的设备程序，结构稳定，效率高，出差时间少，出错少， 那么带给公司收益的同时，对自己来说就是业绩。 有业绩，就拥有了升职，涨薪，再升职，转型管理， 合伙股东， 公司业绩成长，自己成功靠岸，财务自由达到人生巅峰的无穷的想象力。
所以，好的工程师编写好的程序的终极目标是最终自己不动手编程序。最终干具体项目具体设计的活让别人去做， 然而架构是你自己搭建的， 你就永远是第一贡献者，只要设计的设备系统源源不断卖给客户，哪怕自己不介入任何一个具体的项目，甚至连具体合同订单都不晓得 但所有功绩都是你的，别人谁也抢不去。
所以， 你需要的是，展示学习到的新技能新方法的优点， 尽量多的吸引同事来跟随使用，而且要的是心甘情愿，心悦诚服。而不是像一些传统行业传统公司，靠权力和职位压制同事必须服从和接受自己的那套模板，而自己手里的规范又根本不能服众。那样的话，非但业绩提升成为泡影，自己总撒不开手，即便自己一旦撒手不管这一方面的具体业务， 模式就会立马被人推翻。
所以， 烟台方法最终实现的一定是效率提升公司盈利提升的看得见的业绩，而同时烟台方法，相比于传统的PLC编程方法，架构足够复杂，学习难度相当大，一方面学习者没有那么容易学会。 而学会开发架构后开发的设计成果， 交给普通同事简单使用会非常简单，效率提升，而那些封装完成的模块， 除了开发者自己，要交给其他同事能有能力维护和升级， 反而不是那么容易。
所以， 比如你在一个公司内因为有设计成果得到领导赏识，得以从主任工程师提升到部门经理， 那么就必须从现有同事中培养挑选合格的接班人接手你原来的设计工作，然后自己才可以放心去从事更大范围的管理工作。或许有一些公司规模不够大， 部门经理还可以具体做一些技术工作。然而如果你再被提拔，成为公司技术负责人，甚至总经理，合伙人，要运筹融资上市等复杂工作的时候， 还需要天天回来关注设备程序，哪怕这个程序已经足够稳定， 即便一年半载会有一两次的配合设备功能升级或采购变更带来的设计维护，还需要自己亲自去干，就非常不可思议了。投资人如果了解到这种情况，会因此而拒绝投资。
所以，烟台方法的适用者，和带徒弟的老师傅，不在一个层面，完全不同的价值观。
就是，如果你是打算亲历亲为干一辈子技术工作， 一辈子做师傅， 怕被徒弟给饿死的师傅的话， 那么你掌握的那些技能与烟台方法不兼容。不需要来考虑学习烟台方法这一块的技术技能知识。
《谁动了我的奶酪？》 里面的两只小老鼠， 最终发现，并不存在永恒的固定不变的奶酪，要想获得更多更新鲜的奶酪， 只有不断调整自己，主动变化，才能去追寻更多的奶酪。
教会徒弟饿死师傅，这是中国传统的警世名言。 所有人都懂。
在咱们同行之中， 也有很多人秉承了这样的理念。即， 自己做徒弟的时候，各种讨好，伪装，千方百计从师傅那里挖掘到尽可能多的技能，以尽可能早的脱离师傅的掌控，自己可以独立行走江湖。 而当自己摇身一变做了师傅， 也收徒弟的时候，则小心翼翼保全自己的核心技能。 只把简单的技能教给徒弟，让徒弟帮自己跑腿递烟递茶，通过各种角度审查徒弟的忠诚度，视对其信任的程度， 逐渐放出更多的料喂哺徒弟，让他一直有求于己，而不敢轻易叛变师门。
这种师傅/徒弟的传承关系，源自于古代商业社会的工匠族群。 通常师傅就是一个社团的绝对权威和老大，师傅同时掌握了专业技术以及整个组织的经济大权，也掌握了对每一个成员的生杀大权， 只要不犯罪，至少可以随意把任何一位不够绝对服从的成员驱逐。
而到了现代社会， 这种工匠行业师徒传承关系就被大大削弱了。 通常来说，大家都是学校毕业之后，应聘到一家公司，成为同事。 然后同事之间，就有先来的，后到的。年长的，年轻的，经验丰富的老手，没有经验的新员工。
通常， 师傅与徒弟之间并没有什么紧密的关系。 会有一些工厂，班组有新加入的成员时， 领导会指派某位老手作为师傅带一阵子。 一方面技术上给予一些辅导，而更主要的还是对企业文化，管理流程，以及对机器设备行业工艺等方面的入门指导。
这种情况下，师傅对徒弟并没有经济的一票否决权， 也更没有权力驱逐或者自己另选徒弟，所以师徒之间的关系只剩下了纯粹的技术辅导。 然而如果局限于工厂范围内的工作， 一项工作，如果徒弟学会了， 师傅可以安排徒弟做，自己只在边上监督审核把关。 而如果徒弟学不会， 那么师傅就要自己动手干。关系反而倒过来了，成了教不会徒弟， 累死师傅。 没有完成公司安排的带徒弟的任务，某种程度上师傅反而要被考核，批评。
除此之外，很多工厂内部， 同一个班组的同事之间，私下里也会有一些拜师结对的传统。新来的员工出于对自己技术水平快速提高，以达到快速融入公司的目标，私下找一些比较优秀的老员工请教，并逐渐正式或非正式地成为师徒关系。这种情况下， 师徒之间的利益关系也很小，顶多会在过年过节期间，徒弟给师傅送点礼，平常徒弟多请师傅吃点饭喝喝酒，之类。
然而这种情况，并不通用于所有人。因为有能拜到师傅的新员工， 也自然有没拜到的。同时如果是新厂，或者厂内人数少，同专业就自己一个人，即便想拜师也根本无师可拜。
那么， 这些人就只能利用自己在学校学习的知识，结合工作的实际需要， 自己主动学习技能。尤其现在互联网时代， 知识的流通非常便捷，未必需要师傅传授， 有疑问的地方， 通过学习各种技术资料，视频或者请教他人等，都可以获得。
尤其是从事设计工作的工程师，工作本身带有极大的创新性工作，如果公司和行业内有可以借鉴的资料，可以直接从中吸取营养，或许可以有老工程师给予一些建议指导，而如果没有可以依赖的老工程师，那就只好硬着头皮自己从头摸索着做。过程中会经历比有师傅的宝更多的辛苦，然而只要成功完成任务，收获反而比对方要大，进步要快得多。
所以，同行之中至少有两类人， 一种是入行有师傅， 一种是入行并没有师傅。 当然还有一种人会是自己入行没有师傅，却后来有收徒弟。
有同行跟我咨询烟台方法的学习的时候，提出了疑问和顾虑：假设将来我学习了烟台方法做出标准化的更好的程序设计， 那么应该如何对待公司同事？是对他们保密还是把方法技能传授给他们？如果教给他们， 会不会回到教会徒弟饿死师傅的诅咒？
我的回答：
学习烟台方法，最后实现的当然是公司内部的设计标准化。这一点理解非常正确，我已经重复强调了几十回了。 有同行理解成我要推行大一统的通杀整个工控行业的标准程序，最后让所有同行一方面都失业无事可做，另一方面不再需要自己动手编程。 这既想的太美了， 又太坏了。 没这样好事，也没有这样的坏事。
然而来跟我学习的每个工程师， 如果能掌握先进的高效的设计编程方法， 设计出来的设备程序，结构稳定，效率高，出差时间少，出错少， 那么带给公司收益的同时，对自己来说就是业绩。 有业绩，就拥有了升职，涨薪，再升职，转型管理， 合伙股东， 公司业绩成长，自己成功靠岸，财务自由达到人生巅峰的无穷的想象力。
所以，好的工程师编写好的程序的终极目标是最终自己不动手编程序。最终干具体项目具体设计的活让别人去做， 然而架构是你自己搭建的， 你就永远是第一贡献者，只要设计的设备系统源源不断卖给客户，哪怕自己不介入任何一个具体的项目，甚至连具体合同订单都不晓得 但所有功绩都是你的，别人谁也抢不去。
所以， 你需要的是，展示学习到的新技能新方法的优点， 尽量多的吸引同事来跟随使用，而且要的是心甘情愿，心悦诚服。而不是像一些传统行业传统公司，靠权力和职位压制同事必须服从和接受自己的那套模板，而自己手里的规范又根本不能服众。那样的话，非但业绩提升成为泡影，自己总撒不开手，即便自己一旦撒手不管这一方面的具体业务， 模式就会立马被人推翻。
所以， 烟台方法最终实现的一定是效率提升公司盈利提升的看得见的业绩，而同时烟台方法，相比于传统的PLC编程方法，架构足够复杂，学习难度相当大，一方面学习者没有那么容易学会。 而学会开发架构后开发的设计成果， 交给普通同事简单使用会非常简单，效率提升，而那些封装完成的模块， 除了开发者自己，要交给其他同事能有能力维护和升级， 反而不是那么容易。
所以， 比如你在一个公司内因为有设计成果得到领导赏识，得以从主任工程师提升到部门经理， 那么就必须从现有同事中培养挑选合格的接班人接手你原来的设计工作，然后自己才可以放心去从事更大范围的管理工作。或许有一些公司规模不够大， 部门经理还可以具体做一些技术工作。然而如果你再被提拔，成为公司技术负责人，甚至总经理，合伙人，要运筹融资上市等复杂工作的时候， 还需要天天回来关注设备程序，哪怕这个程序已经足够稳定， 即便一年半载会有一两次的配合设备功能升级或采购变更带来的设计维护，还需要自己亲自去干，就非常不可思议了。投资人如果了解到这种情况，会因此而拒绝投资。
所以，烟台方法的适用者，和带徒弟的老师傅，不在一个层面，完全不同的价值观。
就是，如果你是打算亲历亲为干一辈子技术工作， 一辈子做师傅， 怕被徒弟给饿死的师傅的话， 那么你掌握的那些技能与烟台方法不兼容。不需要来考虑学习烟台方法这一块的技术技能知识。
《谁动了我的奶酪？》 里面的两只小老鼠， 最终发现，并不存在永恒的固定不变的奶酪，要想获得更多更新鲜的奶酪， 只有不断调整自己，主动变化，才能去追寻更多的奶酪。
PLC标准化编程
