老翟书摘:从《大野耐一的现场管理》看软件工程管理

输入图片说明

前年,接触到了《丰田生产方式》,就对大野耐一这我的十分感兴趣,就专门找他的书来看。服务器

同时,我一直都有一种“感受”:咱们软件工程的管理方式都是从传统工业借鉴的。好比被吹上天的“精益”概念及“看板”概念。然而,这些概念里,少有人说明这样地借鉴的理由及借鉴了哪些,放弃了哪些。想回答这个问题就必须分别弄清楚传统工业和软件工程的本质。架构

我尝试在这本书了解一些关于传统工业的管理概念。如下是书摘:ssh

####“精益”的概念的产生工具

1990年,美国麻省理工学院的詹姆斯 沃麦克等多位教授,在《改变世界的机器》一书中,首次以“精益生产”(learn production)为核心介绍丰田生产方式,自此,欧美的一些企业才开始把丰田生产方式做为全球化以及提升生产率的标准和尺度。单元测试

####领导说服力:坦诚即表明强劲的说服力开发工具

要想说服别人或是获得理解,若没有什么根据或道理是行不通的。测试

不要老是认为本身的言行没有错误,意识到错以后就应该爽快地说出来。若是有了这种胸怀,指挥现场以及下属不就变得垂手可得了吗?.net

犯了错误以后,应该不吝于向他人甚至的下属道歉,怀着这样坦诚的态度,怎么会没有说服力呢?code

为了造成强劲的说服力,重要条件之一就是管理者自身应该怀着谦虚的胸襟。blog

现实生活中,人们彷佛随着知识愈来愈丰富,产生错觉的可能性反而越大。

传统工业也会遇到咱们软件工程同样的问题:面对一样一份工做,存在不一样的意见。传统工业时里的体现多是组装配件有两种方式,哪一个效率更高;软件工程里的体现是实现某个功能,怎么实现更快(不要忘了,咱们还要考虑可维护性,可读性)。当存在不一样的意见时,双方容易在无用的争论上浪费时间,大野耐一是这么处理的:

在产生两种意见的状况下,各给双方一个工做日的时间,让他们按照本身的意见试着作一作,最后比较结果,直到让你们完全理解、赞同为止。

其实,这样处理的最大好处是将**“实践出真理”**的文化慢慢带入企业。

####要提升生产效率,“意识革命”是首要问题

从上层管理者到中层管理者甚至工做在生产一线的做业员们,因为你们都是普通人,因此都有可能被禁锢在错觉之中,认为现行的作法是最科学的;或者说即便不认为是最好的,也以为别无选择,这就是被常识化了。

咱们软件行业更是如此,特别是一毕业就只在一家公司待好久的人。很容易被“常识化”,认为软件开发就只有一种方式:手工将jar包下载回来,导入到IDE中,而后写代码;部署软件也就是ssh上服务器,而后stop,start。

大野耐一说:

如果不改变从管理顶层到一线做业员以及工会的意识、观念和想法,那么怎么可能探索出作好工做的新方法呢?组织上的改革或许相对容易,可是“意识革命”应该会更加困难一些吧。

再好比不少人认为写单元测试会致使进度被拖慢。其实,关于单元测试是否加快进度,须要更多的数据支撑。因此,须要软件项目管理工具为咱们提供更全面的统计工具,来收集这些数据。这也说明了软件行业和传统工业的一个很大的不一样。传统工业中不少工做是重复的(产品一般是批量生产),能够快速实验,快速看效果。而软件行业中,根本没有批量生产某一软件的说法。

####无效率的动做不是工做

身为生产现场的管理者和主管,必须具备分辨“动”和“働”的慧眼,也就是说,必须可以分辨清楚哪些动做是无效率的,哪些动做与工做是无关的。

这里,对于这个“无效率”的定义会有争议。我是这样认为的,若是不能帮助我写出可读、可维护、用户可用的软件的动做都是无效率的。好比手动去管理软件依赖、手动部署、需求沟通须要等上一个星期、新加入团队的成员须要花两天的时间搭建开发环境、重复手工测试、单元测试写在main方法里、写代码过程分心看微博,动弹……

做为leader,发现这些无效率动做,而后找到改善办法是一项重中重的工做。

####改善应该按顺序进行

所谓做业改善,就是可以让现有的设备更好地发挥做用。在改善过程当中,首先须要考虑的不是购买设备,而是最佳的工做方法。

我认为首先须要进行的是做业改善,以后才依次为设备改善、工序改善,也就是改善应该有前后顺序。

软件行业中,顺序应该是软件开发流程改善,以后依次是实现技术改善、软件开发工具改善。缘由是软件开发流程的成本收益率比实现技术改善、软件开发工具改善更高。这只是个人片面之词。但愿有数据的同窗能帮我证明。

####产品质量问题

若是某个零件比较容易在前几道工序的时候出现问题,是否是应该考虑将检验工做提早呢?提早发现并剔除不良品,总比让它们一直往下走要好得好多。

品质融于生产过程当中,所以,若是能在必要的地方作好检验工做,那么就没必要等到工程的最后才发现不良品,或者说到工序的最后阶段只须要重点检验某些部分便可。

产品质量融于软件开发过程当中,将风险高的软件模块提早开发。QA在功能开发前就参与需求的讨论,并提出验收条件AC。

####下降成本

若是有人问我,为何要拼命减小库存、下降成本,我会告诉他,是为了让资金周转更加轻松。

然而,只要提到下降成本,你们就会以为这是财务人员的责任,其实否则,财务人员根本没法促使成本下降,这只能经过集体的努力实现。

所以,所谓的下降成本,惟有依靠生产现场来进行,现场的下降成本的意识要作到比鬼还要精才行啊。

减小浪费也能够下降成本。关键是咱们如何看待浪费。在《丰田生产方式》中定义的浪费:

1.过量生产的无效劳动:软件行业中指在不合适的时候开发多余的功能
2.窝工的时间浪费
3.搬运的无效劳动:需求沟通不完整,致使重复沟通
4.加工自己的无效劳动和浪费
5.库存的浪费
6.动做上的无效劳动:花费过多的时候搭建开发环境
7.制造次品的无效劳动和浪费:品质没有融于生产过程当中

从这里就能够看出光靠架构师是不能完全杜绝浪费,更不可能靠财务了。

####小结 这本书给我最大的启发是:高高在上不接地气的技术管理是没法管理好团队的。高高在上意味着他没法或很难及时、准确得知开发现场的状况的。若是你连“施工现场”的状况都不了解,谈何改善?

同时,我也发现软件行业的代码审查、每日站会就很好的体现了大野耐一的现场管理思想。经过这两个实践,咱们的leader才有更多机会靠近“现场”。这才是代码审查、每日站会背后更深层的缘由。

半年后再次重读这本小书,又知新。

==========

老翟书摘说明

==========

书摘内容彻底来自原书,若是原书的做者或出版商以为我侵权了。请经过开源中国 @翟志军 联系我。

老翟书摘旨在经过一种书摘的方式让你们花最少的时间了解一本书,从而决定要不要继续读下去。书摘的每一本书都是本人亲自读过并理解的。

相关文章
相关标签/搜索