软件开发和公司管理

    大道同源,今天参加敏捷大会的最大收获就是认识到公司管理和软件开发的本质一致性.敏捷软件开发思想本来就来自于丰田的精益思想或TPS.本质在于消除浪 费,增加应变能力,获得最大的投入产出比,同样的拥有很大的复杂性和不可预测性.对付这个复杂性我们有一些有限的经验,比如一些公认的原则,比如人性(管 理的) 和设计原则(软件开发的,其实是软件的性).但是只有这些是不够的,况且没有人能准确的100%的掌握和用好这些.那怎么办?精益思想告诉我们:

1. 要持续改进.我们需要"发现问题->尝试解决->纠正->总结->发现问题->尝试解 决......."不停的循环下去.我不谈软件设计,就谈管理.比如我们觉着弹性工作制能增加公司人员的满意度,并间接提高工作效率.OK,那好我们尝试 从8:30到9:00弹性工作,然后来收集效果,如果效果好,我们可能要考虑8:30到9:30的弹性,效果不好,可能要退回去.这是精益的做法,每次前 进一小步.如果非精益的做法是,前期做大量的研究论证,然后把时间一次定为8:30到9:30,而且还会把打卡制度直接一起取消了.精益的消除浪费,就体现在小步尝试,及时反馈,及时改进.及时发现错了能及时纠正,使损失最小化.
2. 精益的理想还体现在提倡关注细节,人人参与.传统认为管理是管理人员的问题,普通员工只是受众.精益却不然,丰田要求 每个员工都关注工作和流程的改进.是每个人都参与的持续改进,而不是只有管理人员参与的改进.比如公司成立了流程办,难道要让流程办来改进整个公司的流程 吗?显然不是的,流程办是处理公司级别的跨部门的流程的(我认为也应该是协助实际参与人员),部门内部的小流程谁来改进?要靠参与人员自己去识别浪费,改 进流程.比如每次笔没水了就要只新的,也许就是浪费.管理人员可能注意不到这种细节,只有参与人员才能发现并改进.
3. 还有及时叫停,丰田流水线的某一个环节一旦发现问题,整个流水线都会叫停,直到修复问题.因为继续运转只会产生更多的问题产品,造成更大的浪费.我们是否做到了呢?我们是否在进度压力下放弃质量,最终导致更大的浪费呢?在OA选型没有一家合格的情况下,还坚持八月一日上 线,是否会造成更大的浪费呢?值得思考.
4. 拉 式模型.需求是从客户向前的.比如客户需要一辆汽车.这个需求到了组装工人这里,组装工人就需要车的一个外壳和一个发动机,2个前门,2个后门等部分,然 后需求就到了这些部分工人哪里,最后一直传递下去,然后到采购人员那里就是精确的既可螺丝钉,多少钢铁.不会比实际需求多一点点.如果放到软件开发里面, 客户向产品经理要一个软件,有哪些哪些功能,产品经理就像测试要一个测试稳定的有XX功能的软件,测试就向开发人员要代码,他好测试,开发人员会向需求要 需求说明书.好像没什么区别?有!产品经理不需要详细的测试文档,而是需要自动化的测试用例,项目经理就可以亲眼看到这些功能都通过.测试不需要详细的设 计文档,不需要复杂而"漂亮"的架构设计,只需要稳定的产品.开发人员不需要详细道了字段长度的需求文档.只需要了解主要功能和非功能要求.有人说没有需 求文档和设计文档,以后怎么维护?需求文档和设计文档当然有,都在代码里面.况且项目内的需求文档和设计文档往往因过时而变成错误的,只能起到误导作用.

    软件开发也好,公司管理也好,重点在于持续改进,持续改进的步伐越小风险越小,浪费越少;频率越高,前进的越快;参与人员越广泛,成果丰硕.据说现在在日本很流行的TQM,其实也是精益思想的一种.
    精益思想的发明者丰田,2004年"的净利润仍达到1.6万亿日元(102.8亿美元)，成为第一个利润过万亿日元的日本公司。利润总额几乎是其三大竞争对手———通用、福特、戴姆勒-克莱斯勒总和的两倍。"
    别人从公司管理或者产品开发中的精益思想发明了敏捷软件开发思想.我却是从敏捷软件开发的思想去学习精益的管理思想.班门弄斧了,有不对的地方还请多指教.