三谈修车师傅

这个可怜的修车师傅,肯定不知道我们这样在背后说他。:P

abp上的完美废人有一个令人印象深刻的签名:

C++ 只不过是一个我学过的语言!我以前浪费过一年学它,现在只不过心里面有点内疚而已。我越来越讨厌它了!我明天就要换 Java 了,你想怎么样嘛!

让我想到阿三们和某些拥护他们的某些别有用心的人们,现在心里大概也有这么一句话:

“……”只不过是一个我说过的一个谎话!我以前这么说不过是想让你们来跟我们学“软件蓝领”,主要是想骗你们的钱,现在只不过心里面有点内疚而已。我靠它已经越来越赚不到钱了!我明天就要提个新概念了,你想怎么样嘛!

关于这个“……”,有一个经典的问题:“你是否能接受一个技术不如你的人的管理?”,而这个“……”的内容就是:“优秀的项目管理者,可以不了解技术。”

应该承认这是一句非常成功的广告策划的作品。

但可笑的是,在软件蓝领笑话早就穿帮的两年后,还有人把这句话奉为圭臬实在是让人哭笑不得。

继续拿修车师傅说事:

假设有这么一天,这个修车铺被某修车集团收购,为了能控制这个修车铺,集团把那位师傅调走,安排了一位仁兄(大家心照不宣哈)来管理,他虽然对修车一窍不通,但他毕业的学校和专业号称与哈佛的MBA(当然不是哈尔滨佛学院的Monk Behavior Analysis^_^)相当,所以就由他来带那两个徒弟干活。

对于修车铺来说,每一个客户来修一次车自然就是一个项目了。而在这位仁兄来说,这点小项目的管理当然不在话下。这时正好来了两个客户,一个要把后轮的辐条全换掉,另一个要补个胎。这位仁兄一想,这个简单,马上列出项目计划:

徒弟A去换辐条,估计换一根辐条也就不到一分钟的事情,应该半个小时可以换完,于是给他半个小时的最后期限(按照管理学上的帕金森定理,给一个项目多少时间它都能用完,为提高效率,就要用最短的时间,免得徒弟们偷懒)。

徒弟B去补胎,这个事更简单,给他十分钟。

OK,事情开始有条不紊地进行,这位仁兄不时地巡视一下,徒弟们也都很卖力。很快两个项目都按期完成,哈佛的MBA果然不同凡响啊。客户人满意地付钱走人。

等等,不一会儿客户就来投诉了:

客户A的车骑起来东倒西歪—-更换辐条是很简单,但需要较长的时间耐心细致地校正,但徒弟A为了赶进度,只能将就了。

客户B的车骑没多远就又漏气了—-因为补胎用的苯橡胶溶液需要在干透后再用压力粘合,如果未干透,在行驶中很容易因为挤压而分离。

不过人家怎么说也是项目管理专家,他只要向集团公司打个报告,说这两个徒弟学艺不精,导致项目失败即可,反正上面的人比他更不懂。

然而问题是不可能这样长久下去,于是集团把原来的师傅和这位仁兄找来开了一个会:

师傅说:按照我们修车铺的惯例,都是由一个修车师傅来带徒弟的,师傅不但要管铺子,也要干活。那位仁兄不了解这些,肯定管不好。

仁兄说:不是了解不了解的问题,关于你们修车的东西我压根就不知道多少!但是管理和修车是两回事,否则一个诺大的铺子的修车和管理都集中于一人身上岂不危险系数太高了!

做项目管理尤其是修车项目管理没有对进度的把握是不可能实施的,但这种把握完全可以靠同修车人员的沟通协调来获取,而不是将修车成分生硬的加到管理实践中。

社会分工是趋势,但就修车过程,管理和修车孰重孰轻各有各的看法,但太强调哪个都不是一种健康的观点。项目管理远超过修车管理的范畴,好的项目管理者完全可以没有任何修车技能。

BTW:这位仁兄大概心里还在想:我在大学里学了四年的项目管理,在这个集团里也管理过N多项目了,你这个只会修几辆破车的农民有什么资格跟我谈项目管理。

俺也就是个修破车的农民,项目管理咱不谈,还是来谈谈修车……哦,软件开发。

社会分工并非是指一刀切,只是各有侧重。就拿进度管理来说,“(对进度的把握)完全可以靠同开发人员的沟通协调来获取”,可是对于一个对技术一窍不通的人,你如何知道开发人员提供的进度安排是不是在偷懒呢?

比如前面那个修车的例子来说,徒弟B跟你说他要等胶干了才行,我估计所有不懂修车的人都会认为这是偷懒的借口而跳起来:胶都干了还补什么!但问题是橡胶水的正确使用方法就是这样的。

就算是开发人员都很诚实善良,不会骗你,照样有两个问题:第一、开发人员给出的进度安排你能不能接受?第二、如果开发人员有这样的管理能力,那还要你这个项目管理做什么?

我同样可以说:

开发管理远超过项目管理的范畴,好的开发者完全可以不需要项目管理。^_^

而且还可以很容易地举出一堆例子来证明:比如LINUX,Linus本人除了是Linux的核心开发者外,还管理着Linux这个项目(就是令狐所说的Agile中的管理者)。呵呵,要用事实说话嘛。

最后,再举一个实际的案例:我认识一个牛人,近四十岁,在钢铁和机械行业有十余年的项目管理经验,不但是有很高的管理学历,还曾经到日本、美国学习考察过,对TQM和ISO9000也非常熟悉。后来决定进军软件业,曾在某软件公司做到COO的位置,并带领该公司取得ISO9000的认证。然而很不幸,他用那一套机械化的管理方式在软件业根本行不通,数月后不得不黯然离开。

17 Replies to “三谈修车师傅”

  1. 我個人認為, 越小的項目 ,越小的團隊, 就對管理者對相關實施的項目的相關技術的實現要越了解!象上面例子, 失敗的原因就是項目太小, 只是一個分工過程, 不存在分析, 設計過程! 上面的, 充其量是估計, 并不是分析!一進入系統分析, 很多可量化的東西就出來的!

  2. 我现在不想回答任何问题。我想说,FS不要来,FS不要来,FS不要来……

  3. 如果一个程序员接受不了一个技术不如他的人做他所参与项目的管理者,可能有两个原因:一是那个被推上管理位置的人的确没多少能耐,而他站到那个位置上靠的不是自己的实力,或许是其他因素;二是这个程序员自我倾向太严重。前者我想哪个做开发的人都不会服气,这种拒绝是合情理的!但如果是后者,只能说明一个问题,谁碰到这样的程序员都会很头疼。但受排斥的优秀管理者有能力解决这样的问题,其解决的方式就体现着这个管理者的能力…..管理分很多层面。项目管理不但但是代码之内的事情。代码之外的事情或许不需要技术背景,但代码之内的事情我想多少是应该对技术有所把握才可以做好的,当然可以有辅助力去协助管理…..管理说白了也是技术,就看我们发出视线的角度了…..管理面对的是各种技术和非技术资源…..现在信口谈管理的人很多,但真正让自己管理的时候,我看没多少人可以做的好,这是一种现象。

  4. To 本人回复楼上的 本人对你无话可说。有些人愿意理会你是他们有那涵养,本人可没那么高的涵养对待一个永远进入不了角色但却永远自命清高的白痴! 好了,不想在猛禽的站点和一个别人给点阳光就灿烂的人争吵。

  5. 昨天我的头儿就做了一件上面猛禽兄说的那个管理者作的事情。我和我的室友根本不明白为什么要做这个定个日子,做那个也定个日子,给我们已给最后期限就够了。与猛禽兄说的不同的是,我们两个不是那种烂徒弟,我们还是会各自的特长而且技术较娴熟。我们保证按时完成,但是那么多技术未知性存在,不是其他项目基础部分是经过长时间测试已经有经验了,前期讨论仅仅确认了个大致的方向确认了罢了。他拿管理其他项目的方法,来管理我们两个人聊天软件的进度,本身就不合理。加上头儿对其他项目了如指掌,但是对网络通讯这块他一点都不懂。其实这个是最凄惨的。我们说了许多,除了我们两个,昨天参与讨论的三个人一头雾水……现在我在掌握我们两个人的进度,其实技术问题已经几乎全部解决了。说快一个星期,说慢也就10天就能搞定并且测试了。催来催去,给我压力是我不能容忍的,而且在压力下,我可能做不好。现在就是他们那边我敷衍过去,我们两个懒人该怎么搞自己的就怎么搞自己的。也就是我们两个人不会混乱,要是人多了,不堪想象会有什么结果……

  6. 非常同意>但受排斥的优秀管理者有能力解决这样的问题,其解决的方式就体现着这个管理者的能力…..所以就不要再问程序员是否愿意受一个技术不如自己的人管理,而要问问这个管理人员有没有能力管理好一帮程序员!>管理面对的是各种技术和非技术资源而对于软件来说,人才和技术中其中最重要的资源,这和传统行业有相当大的不同,这也决定了软件的项目管理必须是与传统项目管理不同!

  7. 我的头儿学历不如我,技术不如我,可以说什么都不如我。但是我心底里最佩服他,最尊重他。公司里所有的人没有说瞧不起他的。关键还是做人厚道。嘿嘿,我也要厚道。

  8. 前一段时间不是很流行什么余世雄的管理讲座吗?偶多少看过一点,诚然此人思想有点偏激,但其中道出了很多管理者应该必备的素质和头脑。当然这里的管理似乎和软件项目管理有点不太一致。看你的第一个修车师傅的文章提高令狐虫提到管理的层次性,的确,管理是一个系统工程,必然是分层次的,这样有助于管理的事实,更有助于管理的管理。一个软件项目,从需求分析到最后成品产出,中间会涉及很多环节,每个环节又会面对很多技术和非技术资源。技术固然重要,但技术也仅仅是软件开发这个系统工程最后得以成功的一个必要条件。当然,一味强调技术和一味强调管理都不是什么好事情,度很重要!其实个人感觉项目管理过程中真正有难度的是非技术资源的整合利用。毕竟非技术资源的存在取向较技术资源会有更多的选择和不稳定性。

  9. 可怜的RL。ARI的说法也没错,FS的说法也没错比如一个公司的CEO/COO要关心的应收账款,资产负债表之类,肯定没必要关心你的SOCKET是用线程阻塞还是完成端口,他们管的是高层次的事。不过说句实在话,国内有所谓的大软件公司吗?即便像传说中的TOP,东软,其实不过是一些小软件公司的集合罢了。说句不好听的,都是修车铺集团而已。大多数的软件项目管理人员仍然是接近技术层面的,而且就是算是大公司,不同层次的管理也不能完全脱离技术,只是关心的技术层面不同而已。软件开发中固然有可量化的东西,但不可量化的东西更多(其实准确的说法是量化方式不同,如果完全不可量化,只能说明你不够了解)。–这部分内容是有感于最近看的《与熊共舞》所以其实国内最需要的软件项目管理人员,就是类似于修车铺老板似的人物。

  10. 说句老实话,管理方面的书我没看过多少,要说看,也就是看过一些OO技术已经软件工程方面的书,都是拘泥于代码圈的!

  11. 我不可怜。我们两个只是有些烦。室友可能会更烦,因为做完了他可能休息不了,而且可能去常熟出差。最近他比较烦。

  12. TO:FS给你一个忠告,不管你想往哪个方面发展,抓住一个方面就对了,别哪都沾一点,结果就像那个下山的猴子一样,捡一样丢一样,结果一事无成。

Leave a Reply

Your email address will not be published. Required fields are marked *