惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

IT之家
IT之家
Recent Announcements
Recent Announcements
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
The GitHub Blog
The GitHub Blog
MyScale Blog
MyScale Blog
爱范儿
爱范儿
GbyAI
GbyAI
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
美团技术团队
Y
Y Combinator Blog
博客园 - 叶小钗
Apple Machine Learning Research
Apple Machine Learning Research
Martin Fowler
Martin Fowler
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
罗磊的独立博客
M
MIT News - Artificial intelligence
博客园 - Franky
V
Visual Studio Blog
I
InfoQ
V
V2EX
Hugging Face - Blog
Hugging Face - Blog
腾讯CDC
博客园 - 司徒正美
L
LangChain Blog

博客园 - 小猴子

一年项目开发经验谈 网络应用性能分析 用好工具,助力开发 蚀“日”行动:一个硅谷传奇的《甲申三百年祭》读后感 软件开发质量控制-CMMI读后疑问 今天很高兴 社会知识 转载-3年职业失败经历的感悟 系统分析员 查尔斯—西蒙尼 过年回来了 2009-中间件 科技与人才的完美结合 指鹿为马-真实版本 准备买个正版的WINDOWS BUG维护经验总结 百折不挠,贵在坚持 回莞第二天,关于多线程程序运行问题 北京第一天
JIT资料学习后记—改善工作总结
小猴子 · 2008-10-31 · via 博客园 - 小猴子

最近有个客户和我们签定了合作协议,将我们新开发的硬件用到JIT的生产管理中,对生产管理起到一个配合和促进的作用,因此

临时找了JIT的资料来学习下其管理模式与流程。在一篇论文中看到了一段关于质量改善的经验总结,觉得非常的不错,特备注于此:

曾经出任丰田公司负责生产和质量管理专务董事的根本正夫先生,总结了他30多年从事现场改善工作的经验,归纳了支持“改善,再改善”的六个要领: 

①领导者本身也要从事改善。

不要认为“改善的工作是部下的事,上司不必去做这些”。事实上,不论是领导者还是管理者,如果有心要搞好本部门工作,那么他首先自己要能够致力于改善才行。如果他自己没有办法首先身体力行,那么其部下也就无法跟着前进。 

作为领导者,每天都要督促自己力行改善,同时也要常常要求下属人员“改善,再改善”,从而激发和提高下扈人员改善工作的意愿和情绪。 

当然,领导者所进行的改善与生产现场一线作业人员所进行的改善的主题是不相同的。现场作业人员的改善是以作业程序和操作方法为主,而领导者则以组织、制度、管理体制等软件方面的改善工作为主。 

尽管两者各自的具体改善对象和内容不相同但是上级人员如能为人表帅、以身作则,并不断督促部下要“改善,再改善”的话,那么下属人员就会增强改善意识,自觉贯彻上级的改善意图。 

总之,无论是领导者还是下属人员,都应该在工作的不断改善之中,实现个人自身的不断完善。 

②领导者要关心下属人员的改善活动。

有人误认为领导者的工作就是给部下分派任务,规定目标。事实上,作为领导者,要求部下改善工作、制订改善计划、规定改善目标,而自己只等统计数字,这种做法是极不妥当的。相反,不论下属人员准备进行什么改善、做了哪些改善、改善中有哪些问题、改善的结果如何等等,领导者都要对之给予关心,这是非常重要的。 

例如,当下属人员为了进行某种改善活动,将自己的改善设想和方案向上司提出来时,如果上司对部下的改善设想及方案表示冷淡,或者说:“这算不上什么改善!”,这就如同给部下的改善的积极性泼了冷水,必然会使“改善,再改善”活动停滞不前。相反,如果上司对部下提出的改善方案热情关注,并表示“你发现了好方法,一定照你的想法试一下!”部下就会更加主动和更加积极地设想出一连串的好主意和改善方案来。 

又例如,在质量管理小组成果发表报告会上,到会的领导者是否能够一一仔细聆听部下的每一个改善成果报告,也会对下属人员改善的积极性产生不同的影响。如果上司以漠不关心、满不在意的样子听取发言的话,那么发言者自然会觉得不起劲,提不起精神。相反,如果领导者认真听取每一个发言,并不时提出一些带有挑战性的问题,那么向改善挑战的热情就会被激发出来。 

③不要轻视微不足道的改善活动。

在生产现场,总会存在一些看来很不起眼的不合理现象或工作方法。然而,一些大事故往往出自于这些平时被人们忽视的环节上。 

所以,领导者要重视那些看来微不足道的改善活动,而不要轻视“小改善”。要让大家没有任何顾忌地不断提出改善设想和改善方案,这才是上策。 

④要容忍改善活动的失败。

领导者要容忍下属人员改善活动的失败,要认真听取改善活动失败的经过和教训。 

实际上,事事成功是不可能的。而失败本身就意味着需要改善。每一个失败的事例都能为我们提供改善机会和防止再度发生的构想。想不出改善方案的人应该经常自问是不是没有失败、没有差错,这样就会产生改善的点子和设想。 

领导者要懂得,人非圣贤,谁都会有失败的时候。失败并不重要,而重要的是不要使同样的过失再度发生。 

假如,领导者一听到部下改善失败的报告就发脾气,那么后者就会暗暗下决心:“把过失隐瞒起来,不说为佳!”这实际上就扼杀了改善,为酿成大祸留下隐患。相反如果上司能够认真听取部下改善失败的报告,并共同分析失败的原因,寻找出更好的改善方法,那么就会提高改善的水平。 

一般来说,出现了失败,当事者常常难于向上司启齿。既然部下有勇气将其失败讲出来,领导者就应对此给予赞许,并鼓励他们继续改善下去。 

因此,创造一种敢于说真话,敢于报告失败的气氛和环境,对于“改善,再改善”来说是极为重要的。 

⑤越忙,越是改善的好机会。

用“急中生智”来解释“越忙,越是改善的好机会”这句话,也许是再恰当不过的了。 

经验表明,在那些工作比较轻闲的车间里往往不会产生出更多的改善方案,并且也不会产生出水平较高的改善方案。相反,在那些工作较忙的车间里,改善方案却往往是层出不穷,而且还会出现高水平的改善方案。因为“忙不过来,人手不够”,人们才会去开动脑筋,想出解决办法,激发出改善设想和改善方案。当然,也会有“太忙了,顾不上改善了”的牢骚。这只能说明,这些人的改善意识和改善欲望不够强烈。因此,他们也无法或者难以摆脱“忙不过来”的

状况。而不断改善却会使人们的工作变得轻松愉快,更加有效。 

⑤改善无止境。

对待改善工作,就要像拧出一块毛巾中的水一样,而且拧干之后还要不断地拧,因为一块毛巾不会总是干的,遇到天阴下雨,毛巾就会变潮湿。改善工作也是如此。生产现场的情况并不是一成不变的,改善工作也不是一蹴而就和一劳永逸的事。上周的改善成果,在本周看来,也许又会发现一些不完善的部分,也许又可以发现更好的改善方法。 

人的能力在不断地提高,新知识扣新技术在不断地涌现。因此,人们不会也不应该满足或停留在已有的改善成果上。企业的环境在不断地变化,顾客的需求也在不断地丰富。因此,生产现场也不能只保持原有的状况。总而言之改善是不会到顶的,而是无限的。改善,再改善。 

上述内容揭示了丰田准时化生产方式背后的基本理论,这就是,企业的不断发展只有通过公司内部全体人员对自己的作业活动不断地加以改善而实现。 

事实上,质量和改善的根本问题是人的质量问题。只有全公司的所有工作人员都热爱自己的公司,都热爱自己的工作,都热爱自己公司的产品,都遵循自己公司的方针,都像一家人一样来开展工作,公司的事业才能长盛不衰。正因为如此,丰田公司强调人的质量,注重对人性的尊重,重视对人的教育和培养。 

改善活动本身就包括对人的质量的不断提高和完善,这不但有助于人的发展和公司事业的发展,而且为准时化生产方式的实现提供了最强有力的支撑。

读了这段话后,我感触颇深,虽然他说的生产管理中的改善,但我们做软件开发其实也是一种生产,我们面临着非常严重的质量问题。回顾这几年的开发,小规模的软件开发,经历了不少,失败的产品不少,见过的失败产品就更多了,真正成功的软件开发往往是特殊单。原因是什么?特殊单的要求虽然特殊,但广泛性不强,其需求容易确定,自然容易成功,但标准版本就不一样啦,需要考虑的东西太多,往往顾此失彼,做开发的忙得焦头烂额,还是不能满足市场的要求。这里有点偏题了,我写东西总有这样的情况。

我们公司开发了一套通用的产品软件,兼容了公司自成立以来的所有硬件,到今天,和同行相比,算是不错的啦。但还是会出现一些意外的BUG,比如一个关键参数输入值范围,常态下是1-10的范围,但经常用的基本上都是5-10,4位以下很少很少,结果有客户自己设置了个4,造成了硬件和软件匹配不当的问题。其实象这样的问题,在这个软件中是有很多的,但为什么没有至今没有改善了?因为能下代码改善的我们往往不屑这些细小的问题,解决这样的问题一点成就感都没有,难度也非常的小,因此经历了几任开发后,还是没有改,当然问题的严重性也是相对比较低的,我们上千家客户中,也只有这家自己选了4,其它的都是合法的。这样在程序员的眼中,这已经不算BUG啦,自然是不改了。

可实际的情况要比这糟糕,原因在哪里?因为象这样的BUG很多,我前段时间出差到了北京,和那边的同事一起共事了一个月,才明白公司的软件居然有那么多的小漏洞或者不尽人意的地方,可怜我们做程序的还天真的以为这套软件推出了4年多,应该是很完善了。

回头看看我们今天的这个关于质量改善的文章,觉得要想做一个通用的、长久、好的、令客户满意的软件,是需要广泛动员,每个人都积极参与到改善这个环节才能真正的做好,

无论这个人是开发、还是销售、还是客户。

我以前也带领过团队开发,对以上六点有部分做到了,有部分没有做到。

③不要轻视微不足道的改善活动。

   在开发的时候,比较忙,很容易忽略,往往把精力投入到了关键问题上,这点是不错的,错在当时没有激励其他的同事改善。
④要容忍改善活动的失败.

  改善失败的情况,是没有处理好的。如果大型的比较费时的改善失败后,我一般比较生气,小一点则就算了。现在想想是不对的,激励比谴责更适合处理这样的失败情况!
⑤越忙,越是改善的好机会。

  我忙的时候,连代码都可能控制不好,因此我一般每天最多写6个小时的代码,其他时间包括下班,都在思考如何写。对于改善的事情,实在是没有放在第一位。

  也许只能等开发主体完成后,才能处理好这个问题。
⑤改善无止境。

  这种情况就是典型的自满啦,觉得软件写的不错啦,运行没有BUG啦,即使用户操作起来不习惯,那也不是软件的事情,是客户的事情。

最后总结下,写一个好的软件是不容易的,特别是团队合作方式下。这篇文章将会影响我以后的开发策略,虽然我不是领导者,但以后就是啦。

希望自己将来成为一个合格的软件开发领导者。