浅析996和敏捷以及IPD

freedom1

[color=rgb(51, 51, 51) !important]最近996这个话题很热，但各路势力（资方，劳方）的讨论都陷在事业开创时期要不要奋斗，劳动利润怎么合理分配的这个窠臼下相互扯皮攻击，其中马爸爸，qjf都亲自下场，或高呼“兄弟们的”奋斗精神，或贩卖鸡汤，要新人们把996当福报，呵呵呵呵…….我这里先下个结论，便于大家有个大体的概念，然后再来看我后面的东拉西扯，那就是：

[color=rgb(51, 51, 51) !important]整个国内的互联网行业，包括头部的BATJ这几家巨头，在研发管理，业务管理方法论上，不是针对谁，在座的都是垃圾。

[color=rgb(51, 51, 51) !important]

[color=rgb(51, 51, 51) !important]996怎么会产生的？只是开发人员不够资本家不愿投人导致大家整天加班？错！我们来看一下软件研发的过程，其实一个现在很流行的词就已经说明了一切，那就是“码农”，因为所谓的R&D，几个大厂干的只是D，并非R，R所研究的对象那是在实验室和大学里完成的，大厂拿过来只是进行商用开发实现上线。所以其实软件开发过程可以类比工厂生产线上的生产，那么最近几十年现代化大生产最重要的命题是什么？当然是精益！（后面我另有篇幅讲精益和敏捷之间的关系。）那么现在我们的互联网软件整个产品规划定义和开发实现达到了“精益”的思想了没有？恐怕离理想状态差得很远很远。

[color=rgb(51, 51, 51) !important]那么产生996的根源究竟是什么？互联网软件的开发一直有一个问题很难解决，就是需求和团队软件开发实现产能的矛盾，需求变化太快，经常造成软件产品规划定义处于边开发边定义，由项目开发替代产品版本开发，定制化需求主导产品开发，多线版本并进开发的状态。产品部门瞎指挥，大量的无用功，活活累死开发团队。这种问题恐怕不是多招开发团队就能解决的，因为谁都知道团队越大沟通成本越高，到最后增加人手并不能加大产出，效率越来越低，但是客户需求又放在那里，不响应不行，怎么办？996！大家加班，加到让客户满意为止，于是996就变成互联网业不成文的规矩了，老实说，很多大厂996还算客气的，9117这种也不是没见过。

[color=rgb(51, 51, 51) !important]那么难道就没办法了？谁说的……说这话只能说明互联网业最近几年实在是风生水起，钱太多，活太糙，整天只知道风口以及风口的猪和怎么做一只时髦的猪，不知道对整个软件开发过程精益化….这帮家伙根本就是井底之蛙，不知道其实软件产品规划定义开发测试上线这一流程几十年下来，业界已经发展出一套完善的方法论应对上述棘手的局面。类比一下，现在的互联网业就跟70年代石油危机来临时的美国汽车业一样，不知道可以向生产过程要效益，当一个“丰田”出现时，于是就都投降了…….

[color=rgb(51, 51, 51) !important]有人会说，互联网有敏捷啊，有极限编程啊，有Jerkins，CD/CI，devops啊，对，互联网的确在最近10年逐步引入了敏捷，但这种管理的改进始终只局限于产品的开发架构到测试上线阶段，对于产品规划定义阶段并无触及，这样的结果就是只关注开发测试上线，规划定义阶段跟产品开发脱节，产品团队跟开发团队对立（就好比网上那个出名的段子，产品和开发势同水火，互相视若仇寇），很容易造成多线开发，殊不知拉线容易，收线难，merge branch有多痛苦。你试试在不同的branch上同步相同的feature是何种酸爽的感受……

[color=rgb(51, 51, 51) !important]

[color=rgb(51, 51, 51) !important]上图为项目级敏捷流程图

[color=rgb(51, 51, 51) !important]曾跟A厂的专有云部门中高层坐谈过，他们的痛苦就在于一个产品的开发，可能会涉及到和集团内部大大小小80多个部件平台协同，每个部件内部开发是敏捷了（少则8-10人团队，多则百人的大团队），但相互之间步调永远不一致，需求的同步相当繁复困难。One track开发，多轮PI迭代按时发布永远是个梦，平台级的微服务解耦永远在路上，CD/CI永远只是在部件内部，而无法在全解决方案层面实现。

[color=rgb(51, 51, 51) !important]那么到底哪些公司真正掌握了大型软件的开发方法论并和快速变化的客户需求相匹配呢？要知道在互联网之前，一直有一个行业也是大兵团作战，一个主产品开发动辄全球多个site几百上千人同步，然后还要应付全球客户源源不断变化的需求，那就是IT/电信设备业…..

[color=rgb(51, 51, 51) !important]IBM所开发的传统IPD流程的确从方法论上解决了如何规划定义架构设计开发测试验证上线的完整过程，但这是一个瀑布式产品开发流程，且是一个多部门协同，相互牵制的矩阵模式。很多电信设备商用的大多是这个流程的变体，优点很明显，但是缺点也很明显，那就是慢…..一个产品版本从规划到上市要12-18个月，稳是稳了，但是客户响应太慢。

[color=rgb(51, 51, 51) !important]电信设备商经过最近20年残酷的竞争，从业厂家早已从20多年前全球将近2位数的跨国厂商大幅归并到只剩下三大一小，H/N/E外加一个Z，个中过程的惨烈实在只有业内人士说得明白，外界无法想象。但这个过程也的确逼迫业内厂商积极地改进产品规划定义开发测试上线全流程，向软件生产过程要效益，做到软件生产的“精益化”。诸如H家的IPD流程也已经演进到了OBP模式，N家的SAFe也是从一个全流程视角来协同审视产品规划开发问题，以可数字化的统计结果指导产品定义决策，而不是领导的拍脑袋。说句良心话，那种被T家所标榜吹嘘的微信产品上线开发的“光荣历史”，那种全公司从pony ma半夜三更拍脑然后一路层层下压执行的产品规划定义模式真的很low很low，low爆了好不好，丑没关系，出来丢人现眼就是你的不对了。

[color=rgb(51, 51, 51) !important]

[color=rgb(51, 51, 51) !important]真正的全流程多层级产品级敏捷

[color=rgb(51, 51, 51) !important]这里顺便谈谈敏捷和精益的渊源，其实敏捷的很多概念都出自丰田的精益思想，甚至直接照搬了很多术语，例如kaizen （改善），Kanban （看板），很容易就看出这些日语汉音词的出处，核心的概念很简单，那就是仔细调查研究生产过程中的每个步骤和工位，消除生产过程中的瓶颈和浪费，从需求到生产运输全流程视角规划，生产步骤相互解耦，提高效率，不断发现问题，持续改进。

[color=rgb(51, 51, 51) !important]曾经请教过丰田系的精益顶级专家，我问了一个“傻问题”：那就是为什么丰田会去搞精益这种看似吃力不讨好的事，对方回答，不要忘记丰田再次起家是什么年代，是二战后，朝鲜战争时期，得到了美军的大量军车订单，那时候物资匮乏，每一颗螺丝每一个零部件都是紧缺资源，你必须仔细规划生产的每一个步骤，最大限度地利用各种资源，努力消除瓶颈，最大限度提高资源的利用率，绞干毛巾里的最后一滴水！那是刻在丰田骨子里的东西，永远都抹不掉！

[color=rgb(51, 51, 51) !important]一个996背后所显现出的其实是互联网业快速发展的后遗症颇多，管理不善，从来只有粗暴的“管”没有精细化的“理”，而且以low为荣，以low为美，一时歪论四起，却从不知根子还是在管理方法论和执行到位否。看来互联网也只有经历过电信设备业那种残酷的大逃杀，才会静下心来真正想想自己的问题在哪里。

1 y5 W- M) X0 [- G! u* w- M6 r  \+ [

$ d( b8 I/ @* w5 n7 r4 g2 N8 m

updown

一个996背后所显现出的其实是互联网业快速发展的后遗症颇多，管理不善，从来只有粗暴的“管”没有精细化的“理”，而且以low为荣，以low为美，一时歪论四起，却从不知根子还是在管理方法论和执行到位否。看来互联网也只有经历过电信设备业那种残酷的大逃杀，才会静下心来真正想想自己的问题在哪里。

t123456

学习学习