软件，落后制造业二十年

其实，我很清楚，这个文章的标题太夸张了。正确的，应该说，我的思想，落后制造业20年。但，我想，我大概也能代表51%的IT人的水平了吧。就让这100%的IT人被代表了吧。

自从离开上家公司（央企一流技术团队），一直在思考研发团队的组织形式。传统IT企业，把研发团队划分为：业务分析-功能设计-代码开发-测试-运维，按工作流程条块切割。各组只管自己那一段的工作，不对产出负责。一直感觉效率低，每个人成就感都不足，出了问题，谁都不负责。最后形成大家只是来上班，“积极怠工”的气氛。而且在解决问题的时候，更是费劲。明明几行代码调整就能解决的事情，但代码人员无权调整，说要找设计，设计说找业务，业务说要考虑考虑其它部门意见。最后，就是一点小事，都很难推动。体制僵化，几次改进下来，积极的人也消极了。

在新的团队中，上次黑猫问我，是不是招一个专职测试。我直接就回绝了。我说，咱们这里，没有不懂业务只懂代码的技术，也没有只管开发不管测试、运维的技术。每个技术人员就是上帝，就是造物主，有权决定他做的东西要实现什么。同样，这是他的东西，他嗬的锭就要自己打扫。东西做的好，荣誉是他的，背后的辛苦也是他的。

我希望，通过这种方式，给技术人员荣誉感，让他们知道，自己不是民工，不是别人说让做什么就做什么的工具。让技术人员知道，要为自己做的东西负责。自己的差错要自己承担后果。我允许代码出BUG，但我不允许没有责任心的BUG。

后面我们几个人在分工的时候，也是尽量按功能模块分工。这个功能归他做了，那所有的事情就都是他的。我希望按这种小微框架的工作方式，而不是工作流程切块的工作方式，激发人的责任心，减少协调工作量，让大家的精力，更多的集中在有效生产力上，让工作尽可能自动化，尽可能的避免堆人来解决问题。这样可能就单体来看，战斗力低了一些（他不仅要做自己擅长的、喜欢做的，还要做枯燥的、不喜欢做的工作），但是整体、长远来看，我觉的应该是大大优于几个人按流程协同工作的效果的。

讲这么多，其实是这个想法这些年一直在脑海中酝酿，总算有机会完全按我的想法组建团队，而且实施中初步感觉效果还不错，有点小小自得。然后无意中看到百度词条：丰田的精益制造的解释。突然发现，原来在制造领域，人家在八十年代就已经这样做了。。。汗。

引一段让大家看看：

精益制造的起源

丰田公司在探索新的生产模式的过程中发现，小批量生产比大批量生产成本更低，而造成这种现象的原因有两个：第一，小批量生产不需要大批量生产那样大量的库存、设备和人员；第二，在装配前，只有少量的零件被生产，发现错误可以立即更正。根据后一个原因，丰田得出结论，应该将产品的库存时间控制在两小时以内，这就是准时生产（jit）和零库存的雏形。事实上后来jit生产还推广到与合作伙伴之间的合作，确定了这种模式下制造企业与合作伙伴之间亲密的依赖关系。
为了实现随时发现并纠正错误，必须有由高度熟练和具有高度责任感的工人组成的工作小组。在流水线生产模式中，组装线上的工人只是重复一些简单的动作，而不对产品的质量负责，产品质量由专门的检验部门在产品整体装配完毕后进行检查。但事实上组装线上的工人最了解第一线的情况，如果在组装线上就将生产中出现的错误进行纠正，那就不会出现因错误积累而导致大量拆卸返修的现象。

所以丰田公司按生产将工人分组，每个小组随时纠正本组生产过程中出现的错误，并且定期集体讨论，提出改进工艺流程的建议，这就是成组技术和质量控制的早期形式。当然在刚刚实施随时纠正错误的做法时，组装线老是停下来，但当所有的工作小组掌握了经常出现的差错，并对发现差错原因有了一定经验之后，差错的数量大为减少。

因为每个工作小组的工人对他们的生产负责，所以他们有权决定如何提高生产力水平，并自己实施改进措施，也就是说工人有进行决策的权力。而在授权给生产小组方面，除了给予他们改进生产的权利，还赋予工作组长强大的行政权力，组长可以根据小组成员的表现晋升工作出色的成员。这种管理方式改变了企业的生产文化，为日后精益制造模式的发展打下了基础。

以前只知道一堆名词，精益制造，JIT，零库存，而自己也正是搞ERP的，以为自己很明白。现在才突然发现，当时自己屁都没明白。结合最近看的另一本讲管理的书：【目标-简单而有效的常识管理】--Tolerate / Jeff COX（同时强烈推荐给大家，其实这本书，通篇都在讲一句话，但值得你去读他怎么反复讲的）。突然感觉自己这次似乎是真的明白了。

呵呵，希望自己是真明白了吧。不过，估计自己一年、三年、五年、十年，再回首的时候，发现自己还是不明白。

不过，在软件开发领域，践行精益制造，也不是那么容易的，还需要不少的技术工具、技术框架层面的实践支持。比如尽可能选择哪些独立工作的小微框架，松耦合方式协作的控件，尽可能让每个模块有明确的责任，能够独立完成完整的业务功能。比如django的app模式、angular/react/vue的组件模式，相关的代码都组织在一个模块内部，集中责任而不是分散责任。反例，就是spring/structs/hibernate这种分层设计的框架，这种框架是按工作流切的工作面，不利于按照精益制造的精神组织生产。

感觉近几年的IT的发展，确实是在向小微框架方面演进，逐渐摒弃了JAVA时代的分层框架设计思路。这跟开发语言层面语法的简化，动态语言/弱类型语言的发展（尤其是js/nodejs/php/python的强有力发展）、硬件计算能力与云化能力（不再强调单机的垂直扩展，而是强调小机集群的水平扩展）的进步密不可分。

这也是我，为什么喜欢python / js / php这种动态/弱类型语言（嗯，python谈不上弱类型），为什么选择的技术路线是

• 泛前端团队：weui+light7+vue+php或nodejs
• 小后端团队：python-django

不过这里要说明下，我很清楚没有一种放之四海而皆准的方法与组织形式。因此这个方式，我觉的是最适合初创至中型公司的结构。也就是研发团队规模在3人至28人的规模。对我来讲，一个公司研发团队，做到28人就足以足以了。再大，另做一个公司吧。同时，超过28人的团队，也已经不是我的菜了，我享受不到乐趣，我觉的再大的团队，精力就要放在内部斗争、内耗上了，我不享受，不喜欢。真要到那个时候，就让我退休，另做一块我喜欢的事情吧。这才符合小微团队的精神--专注、敏捷。为什么是28人呢，1-（3-3-3）-（3-3-3）-（3-3-3）=28人。3个人的团队是最有战斗力的，3个3人团队是一个中型小组，3个中型小组组成一个大团队。大团队一个专职的LEADER。这就OK了。从3到28人，也要遵循这个步骤壮大团队。重视每一个人，培养每一个人。不合适就换掉，不能凑活。这样的团队结构，在我现在空中楼阁、雾里看花的视角看，是最能够发挥出每个人的荣誉感、积极性的团队结构。

自己也不专业，随笔而已，而且思维跳跃，中间两句话你看着不顺的，其实我中间还有几个推理步骤，没落在纸面表达。虎虎外行。内行见笑了。不对之处，也欢迎多多指点。

很开心，因此码字以铭志。痛，并快乐着~~~