Chinaunix首页 | 论坛 | 博客

分类: 信息化

2016-10-21 13:56:37

我记得在我还是个学生的时候,很多电影里面所谓的电脑高手,大概都是披头散发,外表打扮不修边幅,打字打得飞快的人。除此之外,这些人还可以长时间面对萤幕喃喃自语,蓦然地灵光一现之后,就可以从不断飞逝乱七八糟的乱码中,找出头绪来。段数比较高的怪才,还可以入侵所有人的电脑,当然,主要都是入侵美国五角大厦的电脑,藉著威胁对全世界发射核武,从此成为宇宙的主宰。

当然,到了现在的电影,这种刻版印象已经被打破了。电脑功力超强的主角已经从得了自闭症的怪人,变身成为戴着墨镜,穿着黑衣的俊男美女,不仅如此,还会在天空飞翔或是徒手躲避子弹。这种人,已经不需要透过威胁要发射核子飞弹,光凭他与众不同的帅劲,就可以变成救世主。

※作者注:这世上应该不会还有那个从事软体开发的人没看过骇客任务(Matrix)吧?

到了职场后,这才发现这个世界好像不是这么一回事。我遇到的工程师,确实有不少人因为醉心工作,所以打扮比较邋遢,打字不见得打的飞快。不过大多数的人看到乱码其实并没有解读的能力,看到电脑中了病毒,大概也不会一眼就知道解药是什么,接着到野外拔几根药草,就可以徒手调配出解药来。大多数的软体工程师,就是很稀松平常的一般人。每天兢兢业业的超时工作,想要赚到一笔可以糊口的薪水。

当然,还是有几个可以被称为超人的人,确实是不怎么注重外表。需要debug时,手指头指着萤幕,不断地卷动滑鼠,切换萤幕,口中喃喃自语,瞬间就可以洞悉别人的bug在那里。

不过,在这行里的高手,并不是个个都可以坐拥难以想像富可敌国的高薪。这跟电影里面的帅劲模样,其实相去不可以道里计。根据我优秀的经纪人所进行的行销调查报告显示,可以被称为绝顶高手的人,占总人口的比率太低,所以属于可以被忽略的市场区隔,关于他们的行为,我们就略过不谈。

在很多软体公司里,大多数人做的事好像是在古庙里面,跟着老和尚诵经抄写经书一样地无趣。每次有一种新版佛经发表了,信众们就赶快拿着教主宝训,照三餐研读这些智慧的言语,外人看来是无趣到极点的事情,可是工程师们却甘之如饴。还有人会努力地比较,不同教派之间的宝典到底孰优孰劣。

当然,在外人看来,这种比较实在也蛮无趣的。不管你是拿着Microsoft的.net圣经,还是拿着Sun的J2EE金刚经,只要你会驱鬼辟邪,算出乐透彩的明牌,除了不同流派的高手之外,其实一般人并不会太在乎你到底是用什么方式把一个系统做出来。

有了法力高强的高僧灌顶,专案就会高枕无忧吗?根据睽违了许久的灵犬莱西市场调查显示,高僧的加持,并不会为专案的成功带来决定性的因素。大多数的专案,并不会因为有能够以光速撰写程式码的超人在这里串场,就会结束的比较快。

咦,有超人助阵,透过光速飞行,应该会飞得比较快呀?为什么专案还是一样delay呢?很多人尝试着为这个现象找出一个合理的原因,一个常见的答案就是process。

有了超人助阵,专案没有开发的比较顺利,其实不一定跟process有关。不过因为process几乎是无所不包,所以你把process拿来review,问问大家:『为什么,我们有了超人,专案还是会delay?我想一定是process出了问题,你认为呢?』这大概也不会有人认为这有什么不对。况且做不好的案子,鲜少process没有问题。

不过凡事会把焦点放在process上,我觉得也是个企业文化的问题。在不少公司里,特别是组织庞大分工很细的公司,如果遇到大家看法不同,彼此之间起了争执,常常都会有人说:『我们应该要就事论事,对事不对人。不要做人身攻击。这样才有办法获取别人的合作,真正解决问题。』例如以下的这个场景。

布鲁斯:我跟所有的team member讨论过了,照现在这个状况,我觉得啦,这个案子应该还要一年才有办法做完。

吉娜:你怎么现在才这样讲?我们已经promise人家一定要在今年年底上线!

布鲁斯:那有可能?每次都是sales部门在乱给promise!这次又是谁答应人家的?

吉娜:是乔安娜跟欧尼尔去客户那里开会的时候答应人家的。

布鲁斯激动地说:Shit!又是他们两个!他们根本就不懂怎么开发软体系统!乔安娜每次去客户那里,都会唱高调,什么客户的需求永远是我们最重视的,我们一定会誓死达成任务。每次都讲那一套!根本不考虑做得到做不到。欧尼尔这个死胖子,每次根本就只想到他今年的quota。

吉娜:布鲁斯,我们应该要对事不对人。我们应该把重点放在怎么改善这个现象。

布鲁斯想,唉,又来对事不对人这套了,这些大烂人:我想我们应该要改变这部份的process,sales在promise任何事情之前,应该要知会PM。

吉娜:这样也只有解决欧尼尔这边,乔安娜我们就拿她没辙。

布鲁斯想,高阶主管不知道自爱,实在大家都没皮条:我想只能请你尽量陪她一起去,帮忙踩踩煞车。

吉娜:看来也只能这样了。对了,有关内部process的修正,就在下次的cross function process review board中提出来吧。

为什么会一直强调,要对事不对人,这或许跟很多软体公司都强调要尊重个人有关。很多软体公司因为流动率高以及长时间处于缺人状态,所以变成你要花时间和每个人好好讨论,看看怎么样让他发挥他小小的才能,而不是要他走路。在这种状况下,你就不得不把事情婉转一点讲,期待透过迂回间接的暗示,加上天生的羞耻心,可以发挥作用。当一个人羞愧至死,又浴火重生之后,愿意把他份内的事情做好。

所以,我们在发言之前,常常都得要顾虑到不要伤害别人脆弱而幼小的心灵。当你遇到程式设计师写了一支烂程式,你就必须婉转地跟他讲:『这个程式这样子写,可能会有问题喔。你要不要再把spec study一下呀,要不然,可能会遇到……这些状况。』而不是『你这个大猪头!你到底有没有认真地看spec啊!』

这种只能对事不能对人的现象在大公司尤其明显,因为很多时候,你对你不满意的人,根本就没有管辖权。这个时候,你就只能眼睁睁地看着别人做傻事,帮你制造出一大堆无止尽的麻烦。

当我们只能够对事不对人时,有很多其实应该是属于人的问题,就很难加以解决。例如我有个朋友,最近刚好有个白痴当上他们部门的主管,整天发出莫名其妙异想天开的指令,所有下面的人莫不叫苦连天。每次当这位主管发言时,每个人都要屏息以待,深怕他又有什么灵机一动的想法。

可是等到事情出包时,大头们要来检讨啦,这个时候又不能直言主管的不对,而这位主管呢,通常又把问题的核心指向下面的人慧根不够,悟性太差,不能够了解他意在言外的微言大义,遇到问题又不能够主动积极地进行沟通。所以呢,都是部属无能的错。于是乎这些无能的部属,只好被罚写检讨报告。写报告的人又不想按照主管的指示,写出一份下诏罪己的报告。谁想跟分红或是奖金过不去呀,可是既然有人闯祸,就得要写份检讨报告。这该如何是好呢?解决之道,就只能把矛头指向process。

在进一步讨论之前,应该要先做一下名词解释。所谓的process,中文通常翻译成流程。指的就是一件事情该怎么做,要完成这件工作的话,应该要采取那些步骤?每个步骤又应该遵循什么规范?彼此之间又有何因果关连?分派出来的每个工作,又该由谁来负责?简单来说,process就是经过实践验证后所整理出来,我们在做事情时,应该要遵守的游戏规则。

因为process这个术语涵盖的非常广,所以天地之间万事万物出了毛病,都可以推托跟process有关。例如:

我们公司没有明确的目标:这是因为设定目标的process出了问题。
我们开发产品没有明确的requirement,也没有清楚的市场定位:这是因为开发产品的process出了问题。
我们公司开发软体时,大家都各做各的,搞得一团乱:这是因为development process出了问题。
客户都不愿意准时付款:这是因为收款作业的process出了问题。
我都一直交不到女朋友:这是因为结交异性的process出了问题。
我肚子好痛:这是因为消化食物的process出了问题。
总统选输了:这是因为选举的process出了问题,这是一个不公正的选举。我要重新验票,找寻枪手,还有寻找启动国安机制的真相。

当然有很多事都跟process不能扯上等号。一件事就是单纯没做好,回头检讨流程,其实没啥大意义。不过如果你出了一个大纰漏,这时务必要大家把焦点集中到process身上,如此一来,做错事的人,就可以逃避所有应负的责任。

当然,透过process的修改,常常可以在不知不觉之间,达成我们想要的某些效应。运用巧妙就存乎一心了。例如下面这个建议。


<提案> 我建议把总统选举改为七战四胜制。
**************************************************
有鉴于2004年总统大选产生极大的纷争,我建议总统大选应比照NBA主客场设计,采取七战四胜的制度。投票最多就是七回。

美国是世界上以民主著称的国家,NBA也是七战四胜,美国职棒大联盟也是七战四胜。这么民主的国家,用这样公平的制度来产生冠军。为什么我们不拿它来选我们的总统呢?不要跟我说美式足球的超级杯也是一战定生死,这种运动在台湾不流行。

每次投票时,候选人应轮流在对方主场的竞选总部等待开票。例如这次连战与阿扁双方这次总部都设在台北,这是一种明显的不公。下次重选,两人就应该回到阿扁的故乡来设立总部,以方便地主队如果选输之后,可以聚集群众进行抗议。

竞选期间,双方可以使用神奇子弹、神奇炸药、神奇火箭炮、神奇刀剑十字弓攻击各所属阵营候选人,以维护选举公平。医院应配合进行现场手术直播,全程监录以及配合测谎。以免夸大受伤状况,造成选举不公平。各组候选人应推派专属御用鉴识小组,进行勘验工作。

为了彻底达到公平公正公开,双方阵营都可以推派黑金被告控诉人,针对对方进行抹黑,这样才能维持立足点的平等。为了避免有公投绑桩的疑虑,主场候选人可以制订公投题目。此外,各阵营可以与配合媒体发布各项不实民调,以及开票时灌票,以协助选前造势,选后聚众抗议。

为了彻底终结作票所带来的不公平,双方阵营应该轮流派自家人马负责选务工作,以方便主场时可以进行作票。大家轮流作票,各显神通,这样最公平。

选举时间,为了避免因为非法集会游行造成首都市长困扰,所以各阵营应该轮流依主客场次预约总统府前广场。每次以一周为限。

原则上呢,就是从 320开始,每周六选举一次。司法机关应该配合24小时加班,以处理选举无效、当选无效、重新验票、重新计票之诉。美国与中共应该要负责派员监督观察,以彻底维护台湾选举的公平公正公开。

想也知道,提出这样建议的人呢,无非就是选输了之后,想要多几次翻盘的机会;或是在总统大选的赌盘上输了一屁股,想要找个翻本的机会。可是只要挂着公平公正公开跟言论自由的大帽子,就算是他是来乱的,你也还是要保障他发言的权利。

在软体开发的世界里, process就跟总统选举时的选罢法差不多。在这一章里,我想先谈谈在台湾见到的几个跟process有关的现象,以及我对于 software development process的一些看法。

在台湾,软体工程跟专案管理其实一直到这几年才开始被媒体炒的比较热,在以往这门学问一向不是门显学。所以有些不是很了解的人,就会把软体开发跟写程式直接划上等号;当然这个业界还有许多饱读诗书,经验丰富不敢信口开河的人。不过大多数人想到开发系统,就是一堆天才,经过脑袋乱转之后,在电脑前打字打得飞快,时钟转个几圈,日历纸撕掉几张,系统就写好了。

所以单单就software development process这点来说,你去观察整个业界的现象,其实大家遇到的问题是蛮分岐的。不同的公司因为不同的现象陷入苦恼之中。我个人观察到的现象大概是这个样子:

有些公司在开发软体时,完全没有任何formal process。
主管开始寻找特效药。
生产了太多的文件。
下面的人开始期待救世主的来临。
信仰不同开发方法论的人,总是认为他们所相信的,才是唯一的真理。
真正执行的人,没有订定process的权利,可是订定process的人,又没有真正照着process去开发过软体。
很多人会把process窄化成只是一些格式固定的文件而已。
有蛮多人相信,遵循formal process的专案就会成功。
认为依时间顺序先后发生的事情,就是有因果关系。可是实际上所谓的因与果之间,可能根本就风马牛不相及。


有些公司在开发软体时,完全没有任何formal process。
**************************************************
这种情况在小公司最多。当你就只有一个人在写程式时,那有什么大家写的code要integration的问题?遇到这种状况,也没有太多版本控制上的问题。文件则是高兴就多写些,反正人数也不多,所以很多东西在沟通时就全靠口述。

对于规模不大的公司来说,如果他们想要做的软体规模不是很大的话,没有formal的process其实影响并不大。因为team size很小,所以彼此之间的沟通可以很顺畅的话,就不会有大问题。更何况很多公司,在规模小的时候,做的都是类型相近的专案,里面的成员在同一个domain合作久了,自然而然会产生工作上的默契。这时候就不是非常需要一套formal的development process。

对这些公司来说,开发系统主要就是写程式。程式写好了,系统就算做出来了。测试?这就请end user测一测就好了。

如果这些公司就打算这样子一直下去的话,其实也不会有什么大问题。而且这样做起来的效率不见得不好。反倒有可能因为沟通顺畅,大家都清楚彼此要做的东西,然后表现出超高的生产力。对这些公司来说,蛮多人都觉得:『我为什么要走那么多流程?简直是人力、时间跟精神上的一种浪费。』

不过小公司都想长大,所以早晚都会认为,应该要建立一套完整的开发流程。特别是当公司规模如果真的长大的时候,单打独斗式的单兵作战,就会很难应付层出不穷的问题。

遇到这种时候,高阶主管很典型的想法就是:『那我就派人去上上课,学学别人是怎么做的嘛。这些人学会后,再回来教其他人。』或是『我们就找这种大厂的人出来辅导我们嘛,我们引进他们的process嘛。啊,政府最近在推一个叫做CMMI的东西,干脆找人来导入就好了嘛。』

这个时候呢,就会产生另一种现象:『主管开始寻求特效药。』


主管开始寻求特效药
**************************************************
如果主管们忽然想到公司内部的process不够完善,这时候,他们通常会跟随着当季的流行,去寻找当时最热门的管理方法,或是开发模式。就像现在有很多人都想试试extreme programming一样。很多主管,一听到这种新思维,新概念,马上就会忍不住想要找个机会来做个实验。

感觉起来,这些主管在看完电影『美国派』之后,就会想要买个苹果派来给team member尝鲜吧。当他拿着派,看着部属们错愕的表情,嘴里面可能还会若无其事地讲:『快点快点,这是现在最流行的喔?怎么样呀?是不是很棒呀?奇怪,这怎么不work,应该会有用呀?你们怎么一副不怎么高兴的样子?电影里的主角可是快美难言喔。一定是你们哪边有问题,这样吧,我派你们去上上课好了。』

※作者注:美国派是一部经典的青春性喜剧,剧中笑点很多都是限制级的荤。里面很经典的一幕是男主角拿着一个刚烤好的派,想要试试用这种东西来打手枪,有什么特殊的快乐。结果他爸爸就出现了。这时就见他手拿着派,表情一脸惊恐与错愕,堪称同类型电影中的经典画面。不是卫道人士,又想看看无厘头的青春性喜剧时,可以看看这部电影。

很多时候,我觉得很多主管只要看到现在的流行是什么,瘾头一上来了,就会想要来个大跃进式的改革。台湾有句闽南俗语说的好:『没有那款屁股,就不要吃那款泻药。』对于开发软体来说,每件事情为什么得要这样做,当你端出一个答案时,其实背后都躲着一个想要解决的问题。你如果不了解前因后果,没有依据专案的规模,开发系统的特性,人员的技术能力种种因素加以考量,就贸然采取了大刀阔斧的改革,一定会遇到很多困难。

※作者注:这句闽南俗话好像是指如果你的屁屁不能收放自如的话,最好就不要吃强力泻药。

不过,对于很多人来说,一方面主管喜欢尝鲜,可是另一方面又有专案的压力,所以常常会不得不在认识不清楚的时候,就赶鸭子上架,硬着头皮在专案里面大幅采用新的process。由于当事人常不甚了然,所以就只能拿香跟着拜,依样画葫芦。这个时候唯一的方向,就是大师们的言论了。久而久之,就会言必称标准,行必遵大师嘉言录,凡是大师所言,必定极力膜拜。


<性向测验> 你是高阶主管,某天当你奉行着走动式管理的建议,到处在办公室闲逛时,忽然警觉到办公室里面,大家好像没什么共识。感觉起来,似乎有各式各样的信徒在膜拜着自己心目中的大师。然而,不同派系之间,壁垒分明。此时,比较激进的信徒又在撰写又臭又长的email炸弹,准备开始进行自杀性邮件炸弹攻击。遇到这种状况,高阶主管又该怎么办呢?
**************************************************

A. 听听各方的观点,并且独自做出正确而睿智的决定。然后要大家照着实行。

B. 隔山观虎斗,弄一个讨论大会,没有结果,不准休息。反正物竞天择,经过充分的讨论,有意见的人讲话也讲累了,当大家膀胱忍不住,纷纷解衣曳甲,双腿夹紧之时,就是结论产生之日。这还可以获得一个经过民主程序认可的美名。

C. 找个顾问,让他来收集各式各样的数据进行分析后,提出完整的研究报告。接着召集各部门的主管,让顾问来虐待他们的膀胱,逼迫他们做出结论。你只要引领方向,也就是说在把顾问找来时,要先做个开场,等到他们结论做出来时,开一个会感谢大家的辛劳,接着成立一个跨部门的process推动小组以及process auditing board。

这个性向测验主要是测量你有多适合在官僚体制下工作。A这种答案呢,原则上就适合在小公司里面称王,到其他类型的公司会被人质疑你不够民主,不懂得什么叫做互助合作。B这种答案大概就是在中型企业工作,公司的资源不够,就不会有钱去找顾问。如果你选C的话,其实就蛮适合在大企业里面生存,如果流程改造计划失败了,还有顾问可以诿过。如果流程改造计划成功了,当然就会理所当然地升官发财了。

提到顾问就会让我想小小离题一下。资讯产业的进展非常地神速,各式新型技术、标准,不断地推陈出新。所以这个行业的人,无可避免的得要去研究很多各式各样的新科技。市场上的人力供给一直跟不上需求,所以资讯类型的教育训练顾问业,一直都是相当蓬勃地发展。

这些年我还真看过不少顾问。如果是学者出身的,所提出来的建议呢,大多体系完整,看来头头是道。不过学者的实战经验太少,所以有很多建议其实是全凭想像与推论,所以他们所提出来的建言,有时就会立论高远,却与实际工作有一定差距。

产业界出来的就会比较好吗?这也不一定。真正厉害的高手,大多会陷在实际的专案里面,再加上会做事的人不见得很会讲课,七折八扣之下,会出来当教师或是顾问的就比较少。如果讲解的是新玩意儿,通常顾问的年纪就蛮轻的。这时感觉起来做案子的经验,就不会很丰富。年轻人的特点就是理想性十足,所以这个时候,常常会提出很多实务上不可行,可是看来很美好的建议出来。

这就好像很多少男在对性事懵懵懂懂的时候,常常会在朋友之间,交换很多似是而非的观念与经验。最会说嘴,讲得最头头是道的人,常常都不是实际战果最好的人。我看到没什么经验,只好硬着头皮装懂的顾问,内心里面总是会想起在『美国派』电影里面,那个吹牛自己性经验丰富,可是被拆穿后,吓到尿裤子的配角Sherman。

※作者注:又找到一个该去看美国派的理由了。


< 随堂性向测验> 你是个顾问,当你发表了你精心分析的高妙言论时,终于到了Q&A阶段。头一个发言的人,劈头就给你难看:『你讲的书上都有,你可不可以提出比较具体的做法?或者提出你自己的经验心得?不然我们花那么多钱请你来做什么?』这时你会怎么回应?
**************************************************

A.『你的态度很恶劣喔?警卫,把他赶出去,关门!放狗!什么?没有狗?那我走。他妈的,老子不干了,有几个臭钱了不起呀?』然后就气冲冲地走了。很多顾问在受到客户的鸟气之后,常常会幻想这个场景。有阿Q式的排解心情的效果。

B.『景气不好,赚钱不容易,我也是出来混口饭吃嘛。兄台何必如此苦苦相逼呢?』接着开始摇尾乞怜。大谈他家中尚有高龄老母,一家妻小嗷嗷待哺的窘境。

C.『我想我在这里只是协助大家快速地了解这个新的理念,我个人是用这样的观念去做过一些pilot project,我也觉得这些pilot project大体上也证明了这个方法的优越性。我个人是认为,既然美国这么先进的国家,都在使用这种开发方式,一定有它可取之处。我个人深信,这一定会变成世界的趋势,整个宇宙的潮流。』请记得需要面带傻笑,表情呆滞,脸上必须显露出完全欠缺逻辑思考能力的表情。

D.『这个建议很好。我想是事前我们在沟通时,忽略了这一个面向的问题。我回去之后,会仔细全面地通盘思考你们所提出来的需求,重新调整后,再向诸位进行更严谨的报告。』收完钱之后,就找一堆理由永不再来。基本上这种顾问如果长的玉树临风,要是没饭吃了,就可以考虑从政选市长。基本上只要把身体锻炼好,穿着性感小背心慢跑,讲讲场面话就可以了。

E.『就产业界的经验来说,各位都是经验非常丰富的前辈。』先戴一下高帽。『我在这里所提出来的建议,无非是基于一般的通则,加上我个人,以及公司同事之间经验交流,相互讨论所提出来最佳的建议。各位的指教我会虚心检讨。以后将会参考诸位宝贵的意见,继续本着我的专业,尽我的全力,提供给各位最好的服务。』嗯,好像不管什么意见都可以用这段话来回应。

上面这个题目的标准答案请参考本人尚未开始写的新书─如果你找得到的话,请通知我一声。我一直不知道它在哪里。

好的顾问其实不容易找到。很多人看的只是显赫的经历,名校毕业,任职于大公司…这类型的条件。然而,我个人觉得最重要的是他的经验跟你的需求是否相吻合。一个很有经验的人,他的经验不一定对你们适用。公司的规模,team size大小,开发系统的特性…很多因素都会影响software development process的拟订。所以你找来的顾问是否可以跟你们在开发的系统相配合,就是一个重点啦。

此外就是在他面对问题的时候,会不会实事求是地追求真正的解答,还是就拿着大师的嘉言在搪塞,这就是另一个观盘的重点。有很多顾问,其实就是会讲好听的场面话,可以讲得一口好理论的人,提供的建议不尽然就是个好点子。

即使你找到了一个好的顾问,他也点出了正确的方向,这也不一定有用。很多事情落实到执行面来,还是常常会有差距。拥有一套好的process,并不是成功的保证。

找了顾问之后,引进了一些新的想法跟作法,接着就会造成新的问题。每次实验了新的作法,产生了新的问题,这时候其实主管们常常都会装死,互相推诿责任。此刻,最常见的企管佳句就是:『我只负责领导,点出一个正确的方向。』例如在以下的这次status review meeting。

大头:这个project怎么又delay了?上次不是说UAT这个月底要结束吗?怎么你们现在又要调整时间。

吉娜:这个问题,我想要由布鲁斯来回答。他比较清楚实际的状况。

布鲁斯:没办法,客户在这一个round的测试提出太多有争议的bug。我们认为是new requirement,他们说是bug。

大头:这种事情不是发生过很多次了吗?你们先前不是告诉我说,这个project你们会采用新的开发方式,可以大幅降低requirement change的机率吗?怎么一延就要延一个礼拜?

布鲁斯:我们确实是很快就把prototype做出来了。User看到这个prototype之后,确实也比较清楚问题在那里了。可是后来公司又要推OOAD,所以我们写了不少use case跟sequence diagram要user confirm。而在confirm的过程里,我们的prototype跟这些东西兜不起来。所以requirement的收集与整理变得很纷乱。

大头:那这个问题也应该早就浮出来了呀,怎么这么明显的risk你们都没发现?还有,这个OOAD干嘛在这个案子插一脚?

吉娜小声地说:老板,就你上次去参加研讨会后,下的指示呀。

大头:我只是负责领导,点出一个正确的方向。实际执行跟后续的follow-up,这当然要你们去做。要不公司花钱请你们做什么?事情做一做,发现了窒碍难行的地方,当然要赶快反应呀。这个案子这么急,当然不要再实验这些我们还不熟悉的新作法嘛。

吉娜跟布鲁斯心想,你上次才不是这么说的呢,没办法,官大学问大:是的老板。

改善公司的process,在我所待过的软体公司里,几乎是每家公司每年必列的目标之一。高阶主管每年都信誓旦旦地说要做什么大刀阔斧的改革,可是实际上,绝大多数的主管,都只有口惠。或是只有提供『方针』与『领导』。而缺乏实质的参与和推动。

我后来看到这种只长着一张嘴的主管,夸言要改善process。都觉得很像是一家已经爆满的酒店里,妈妈桑对着等不到小姐来坐台的客户说:『让你们等这么久不好意思啦。这样吧,待会儿小姐来了,你们就尽量蹂躏我们家的小姐吧。我一定会叫她们拋开所有的束缚,全力配合到底。』很多主管找顾问来对project team施行震撼性电疗时,讲的话也差不多就是这样:『王顾问,如果我们的员工没有好好学习,尽管跟我讲。他们有什么缺失,还是不配合,你都直接讲不要客气。不能够配合公司政策的人,没有资格继续留在公司里面。』理论上来说,妈妈桑只要提供了方向,小姐们就会奋勇向钱,勇往值钱。好的妈妈桑不会做这种傻事,不过不好的主管倒是常常让工程师遭受折磨。

回归主题,执行面最常遇到的问题是什么呢?我个人觉得是:『生产了太多的文件。』


生产了太多的文件。
**************************************************
官僚制度最大的问题,就是会让原本单纯的事情,搞得很复杂,透过官僚的运作,就可以让员工人人有饭吃,个个有事做。如果你在一个庞大的官僚体系下,想要讨论出一套process时,很多人的焦点会放在,谁才有权利去接触到这样的资讯,或是谁才有这个做决定的权利。你把流程弄单纯了,很多盖章的人就会没有饭吃,做出这种建议的人,绝对会被同事鸣鼓攻之。

所以这时候process最大的重点,就在于防弊了。很多事情,就需要经过层层签核,才可以决定,多盖一个章,就可以都养一个同事。反正有饭大家吃,有钱大家赚,这绝对是最高指导原则。凡是违背这种原则的人,要质疑他也很简单:『你怎么可以让一个官小位卑的人来决定这么重大的政策呢?』

有些人生性比较驽钝,不能参透话中机锋,听到这种话,就会想:『嫌官不够大,那我们就直接找大头来开会吧?』这当然不成,大头们日理万机,我们做部属的怎么可以没有经过充份的讨论,没有提供任何可行方案,就叫他们在状况不明的情况下贸然进行决策呢?

解决之道,那就把一干人等一网打尽,发一堆meeting notice给他们,大家来开个会吧。经过充份的讨论跟沟通之后,就可以拟出几个建议方案,再让大头们来做决策。开会加上盖章就是繁衍官僚体系最好的肥料。

其实开这种会,通常主题就是:『这件事应该来会我。』『这件事应该要让我知道。』『这件事应该让我来做最后的决定。』这种『这件事一定要先知会我』的会议,其实开来格外无趣。每个人都想透过参与决策,来分一杯羹。不管是功劳,还是影响力,都是一样。我可以多盖一个章,如果它做的起来,论功行赏时少不了我一份;如果它看起来会帮我找麻烦,我就可以拖他一下。赶快找补救的方法,或是逃到别的部门去。

因为这类会议的主题就是在界定每个人的政治影响力。被排除在权力核心内的人,如果不是满腹牢骚,抱怨没有被事先知会的话,会对企业造成多大的危害;就是一再地说明,如果我事先被知会了,会为企业带来多大的好处。

开会虽然被许多人视为畏途,不过许多人为了想要在企业内部出人头地,掌握可以藉着冗长开会,欺负众人膀胱的权利,就会要求要参加任何一个可以参加的会议。连不关他的事的会议,他都想参一脚。

当你的会议参加的够多,老板就会觉得,咦,你很热心参与,工作主动积极,特别是每次都主动去参加老板不想去参加的会,还可以发言踊跃,真是足为员工表率。当你参加任何会议,都可以滔滔不绝如同滚滚黄河一番的话,每个人为了怕你乱讲话,导致人人憋尿憋到内伤,虽不情愿还是会想办法在email功劳簿上记上你一笔。『感谢某某先生的大力帮忙。』

如果每次开会这种搅局的人都很多,到最后就一定会演变成冗长又无趣的马拉松会议。这世上比起讨论标准作业流程还无趣的会议应该也不太多了。除了那种想升官发财的人之外,有许多工程师或是专案经理,对于这类型的主题则是有莫名的喜爱。

制订一套制度,让大家都照着我卓然出众的思想来做事,这对工程师来说,真是莫大的诱惑。这种事情带来的快感,大概就只有开发出一套绝妙的系统时的感觉差相彷彿。

不过因为工程师在做这种事情的时候,都会确信自己的想法纯然出于理性,自己就是真理的化身,如果有人喜欢采用OOAD,另一派喜欢画DFD,整天听这两派论述大对决,把会议里的对话写下来,就可以制造出一剂失眠最佳良药。

基本上呢,这种争论就像是宗教信仰上的差异,不同的人有不同的信仰。所以就好像听到基督徒跟回教徒在吵架,讨论谁是真主一样。到最后大家的耐心都被磨光了,膀胱也快要爆裂了,这时就会听到一贯道的来插花,说是万教本同宗,我们应该要中学为体,西学为用,兼容并蓄,博采两者之长。

等会议到了这种地步时,通常结论也蛮简单的,因为你的膀胱再也受不了了。所以结论就是什么死人骨头文件都要写。你也不用管写这些文件原本想要解决的问题是什么,你也不用管写这些文件写了到底有什么用。反正就是要遵循规定去写文件。

所以我们会因为需要做文件而做文件。因为这是大师的说法,所以我们需要写这些文件;因为我们要推行软体工程,把process tune得比较好一些,所以我们需要写这些文件;虽然我不知道为什么要这样做,不过应该要这样子做才会符合标准,所以我们需要写这些文件;因为写了文件之后,可以促进世界和平宇宙大同,所以我们需要写这些文件。反正只要你高兴,总会找到一堆理由去生产一堆文件。

对很多人来说,文件不是在你在工作时的副产品,而是一种要特别去写它的东西。写程式时不写注解,而是到写完后再把注解加进来,这样就可以把时间摆在写真正有意义的程式码上。开发时不写该写的design spec,而是到系统上线后,再改一版来交差。

为了写文件而写文件的事情变得越多,浪费的时间与资源也就越多。可是很多主管就是克制不了这种产生文件的冲动。可能大多数的主管前辈子都是伐木工人,见不得有森林存活在地表,一定要砍下来,做成报表纸,要求属下们把文件印成一本一本厚厚的纸枕头,以便中午午睡时可以垫着睡比较舒服。

在开发过程里,需要撰写哪些文件,这类型的标准一旦开始采用,要进行修改就会面临各式各样的挑战与质疑。所以文件只会越来越多,做事情时会越来越繁复,等到开发系统的流程已经繁复到人类无法承受的时候,这时候就会再来一个process reengineering。我们会生产新的文件,来律定那些类型的文件是开发系统时不可欠缺的文件。所以有些大公司会成立流程改造委员会,来改善系统开发标准委员会所订定的标准开发作业流程。

很多人经历过凡此种种改善process的诸般劫难之后,就会开始期待救世主的来临。


下面的人开始期待救世主的来临。
**************************************************
我以往少不更事的时候,每次只要有新的主管空降,就会期待他有一番作为,那时总以为,只要他规定好应该要怎么做,我们大家就照着去做就好了,接下来所有的人就会过着幸福快乐的日子。开发系统也就可以一日千里,以超光速迈向结案。

不过年纪越大就越不好骗了。根据我的经验,上天赐你一个圣君贤相,天生就是个治世能臣,可以帮助你们大刀阔斧厉行改革,然后获得前所未有的成功,这种事情发生的机率,大概跟你走在路上被雷打到差不多。

你可能会从书报杂志上读到,这个世界上还是有像是IBM前执行长Gerstner这种能让大象跳舞的人,所以你应该有机会遇得到一个可以济世的好老板。这世上会有这么多人愿意花钱买乐透,不是没有原因的。我只能说,我在八卦杂志上也看过很多性感名模,AV女星,被踢爆深夜陪着男性盖棉被纯聊天(这是当事人的说法啦)。可是我并不会期待,她们会在晚上为了想要与我促膝长谈,跑来陪我不穿衣服盖棉被睡觉,或是为了配合要帮我欺骗跟踪我很久的狗仔队,愿意配合我深夜开车到荒郊野外演出车震事件。

※作者注:没有八卦杂志会来理我的原因,主要是因为我没有那么有名。小人物的绯闻报导太无聊了啦,写这种新闻会卖不出去。根本没有名气的作家独孤木,深夜演出车震事件?没有名的人大概只有靠在街上裸奔,才有办法吸引镁光灯。不过如果你本身就是个名人的话,你遇到超强CEO的机率应该会提高。所以如果贵公司的名号跟IBM差了十万八千里,你们的老板刚好是不世出的奇才的机会应该很低。

大多数的主管其实也不过就是个年长你一些的普通人,他们不会通灵,也没有三头六臂,更有可能的是,他们跟实际作业脱节很久了,又一直被马屁精们吹捧的自以为高瞻远嘱。所以他们能够做的变革,其实也不用期待太高。

对制度不健全的公司来说,很多process的问题,都是导因于无知。每个人根本就不知道什么才是对的,所以大家各行其是。结果很多该做的事没做到。

比较有规模的公司呢,process的问题,则多半导源于企业文化的特性。所以如果真的要改善,却没有从企业文化进行根本的改变的话,所做的努力根本就是徒劳无功。

如果你遇到的是企业文化的问题,这就不是一个救世主一句:『信我者得永生。』就可以解决的。你得要想办法让共识可以形成,所以你的沟通协调方面的政治能力会远比你的专业能力来得重要。这个时候常常会面临的问题是:『信仰不同开发方法论的人,总是认为他们所相信的,才是唯一的真理。』


信仰不同开发方法论的人,总是认为他们所相信的,才是唯一的真理。
**************************************************
每个人在讨论软体应该要怎么开发时,脑袋里面都有他们自己的一套想法。很多人就会认为只要每个人都能够充份表达他的意见,经过理性的思辩之后,就可以产生出最棒的process。即使中间还有什么不足的地方,最少也是经过一个民主程序,所以应该可以达成一定的共识。

原则上有机会让大家讨论process,这会是一件好事。在做project的过程里,每个人都会累积不少负面的能量,透过策划美好的未来,可以宣洩一下这些情绪。达到心理治疗的效果。如果负面的能量没有获得适当的释放,整个team就会跟人便秘很久,却拉不出来一样的痛苦。

不过这类的讨论呢,却有一个很大的潜在危机。很多人在讨论process时,其实还是抱持着文人相轻的想法。凡是非我族类,其心必异。遇到跟你论点不同的一方时,第一个想到的不是他讲的有没有道理,而是他反驳了我的讲法,要不要给他一点颜色瞧瞧?

特别是如果有两派人马各自拥有不同的经验与认知时,那种方法论的战争就非常惨烈了。有些人会辩论,到底应该采用Object Oriented Analysis & Design (OOAD),还是要走传统的Structure Analysis?到底要画UML diagram,还是要画DFD?到底要follow Rational Unified Process(RUP),采用iterative的方式去开发,还是要用传统的System Development Life Cycle(SDLC, also known as waterfall),或是采用最新的extreme programming?Team的build up ,要不要做一个GUI prototype,要怎么估计专案的大小…各式各样的问题,都有永无止尽的争辩。

有些时候呢,争辩其实是导源于开发团队内部的分工所造成的。像是开发MIS 系统时,有些公司就会把team分成两组,一个是component team,另一个是application team。Component team负责开发底层的component,而application team则是负责要了解使用者的需求,然后透过使用 component team所提供的component来架构出使用者所想要的系统来。

这个观念就理论上来说是不错的。一个人专门做积木,另一个人专门用这些积木来盖房子。如果盖房子的人需要特别的积木,他也不要自己动手做,只要告诉他的同伴就好了。做好的积木,因为接受过各式各样的考验,所以如果下一次要盖房子,就可以拿来继续使用。这基本上是所有OO教科书的标准官方说法。

每个做component的人,总是希望他做出来的component可以用在任何一个project之中。所以他不太愿意为了单一project来修改他的component。然而component的spec是什么呢?却又很少人可以在一开始的时候就定义出来。所以呢,如果你在一个component team,通常会采取iterative的开发方式,进行分析设计时也会采用OOAD。也就是说你会随时都有因应变化的准备。

可是application team呢,则通常有个明确的需求,最少end user觉得很明确啦。所以他们的重点呢,则在于怎么样透过跟end user之间的互助合作,可以把需求以及spec定下来。所以通常是用传统的waterfall加上传统的结构化系统分析。因为他们要解决的,是现在手头上的单一问题,所以这个component是否能够适用在各种不同场合,是否够generic,其实他们并不care。

就实务来说,如果这两个team可以相互配合的很紧密,那当然很好。不过常常看到的状况是,这两个team会因为遭受到project的压力,而互相踢皮球。

例如下面这个场景。

AP team的PM布鲁斯:team member跟我反应,他们需要component team提供一个function,让他们可以透过文件的相关编号,来寻找一份文件。

Component team的PM韦恩:我们的team member觉得这个要求并不合理。这应该是属于AP要自己handle的部份。

布鲁斯:可是你们把相关的object都封装起来了,应该要提供我们相对应的method去处理呀。

韦恩:我觉得我们的component不应该为这种单一事件进行修正。AP team需要的information,应该要自己处理。你们现在所谓的文件编号,这个资讯我们目前implement时,是放在xml里面。如果要提供查询的机制,整个效率太差了。

布鲁斯:Oh my god!这么重要的资讯,你们居然没有放在database里!?

韦恩:我就跟你说过,我们要考虑更generic的需求。如果放在database里面,就有可能会被它限制住,变成一定要绑某些特别的database。

布鲁斯:不会吧,最少运用JDBC去连可以连得到就好了吧?把所有的东西都放在xml里面,就为了要跨database,这代价未免也太大了吧?你们的需求到底是怎么来的?怎么会这么夸张?连这种透过相关编号查询,这几乎是商用系统最基本的需求都没有办法满足,这是什么component?

韦恩:component的spec,上次有跟你们的team member confirm过呀。真的那么重要,那要不就放到下个iteration。

布鲁斯气冲冲地说:下个iteration?我们的project下个月就要结案了,你跟我说下个iteration?

韦恩也很不爽的说:要不你想怎么样?我的team member难道就整天没事做?

吉娜:两位,两位,先冷静下来。我们先就事论事,看看有没有什么其他的 solution?

布鲁斯:我的team member已经连续加班加了一个月,礼拜六日通通都来加班。现在实在是很需要一些component team的support。

吉娜:韦恩,这个有那么难吗?我知道你们的team member个个都很聪明啦,一定没问题的。

韦恩:那个,老板,真要做的话,怎么会有问题呢?可是这样就是hardcode写死,为了布鲁斯他们这个team来做修改了喔。我们的component本来就是想要避免hardcode呀。以后要改到别人可以用,还要再花一次工喔。

吉娜:哎呀,project的deadline要到了嘛,大家就变通一下,相忍为国吧。

韦恩:既然老板这样说,我们当然遵照办理呀。不过这里可能需要架一个search engine喔。要不performance一定会有大问题。

吉娜:这些太先进的技术我不懂啦,这就要靠你大力帮忙了。你们这么强,一定没问题啦。

这种争论其实也蛮无聊的。拿积木盖房子的人说,你做积木的流程有问题,所以你做不出我要的积木,应该只要给我一个积木,他的长相就跟我要盖的房子一模一样就好了。制造积木的人则是说,我要做的东西是可以符合各式各样专案的需求,所以可以给你一个长的像是乐高的东西,你就该谢天谢地了。要盖摩天大楼,用乐高就可以了呀,一定是你们太笨,盖房子的process有问题,用乐高慢慢堆,总有一天可以堆出摩天大楼来。

很多人都喜欢悍卫他所信仰的一切,可是却没有想到各种不同的理论,应该套用在不同的情境之下。吵了老半天,大多数人没结论,彼此相持不下,事情就会跑到大老板那里去。通常这种争论呢,双方的立论都有可以说得通的地方,而大老板通常也不是什么专案管理之神,所以能做的决定多半就是看看两边的政治势力分布之后,接着去做一些政治上正确的决定。结果常常是顺了姑情,就逆了嫂意。

在职场上,理性辩论的空间其实蛮小的。通常就是一些鸡毛蒜皮的小事,大家都没什么兴趣讨论的时候,会存在理性辩论的空间。比如变数的命名规则啦,版本的命名规则啦,这种越无聊的事情,就会存在理性辩论的空间。否则,任何process上的改变,都牵涉到有人要跟着修改他习以为常的做事方法,也可能会牵涉到他要做的工作量。所以在推动任何reengineering时,组织本身抗拒的力量通常是最大的阻碍。

为了避免推动process修正时,组织内部会产生抗拒的力量,我们就把实际执行者找来订定process,不就结了?不过,很抱歉,在台湾,另一个常见的现象是:『真正执行的人,没有订定process的权利,可是订定process的人,又没有真正照着process去开发过软体。』


真正执行的人,没有订定process的权利,可是订定process的人,又没有真正照着process去开发过软体。
**************************************************
一个人开车需要遵守交通规则,可是订定交通规则却不需要这个人会开车。我是没听过立法院修改交通法规时,得要先检查立委的驾照这种事。建筑师要会画房子的蓝图,可是画蓝图的人不用自己去砌砖块抹水泥。

或许是基于类似的推论,真正执行专案的人,常常都没有订定process的权利,可是订定process的人,又没有真正照着process去开发过软体。这种事发生在建筑业可能还蛮合理的。你不会叫一个什么东西都不懂的人去画建筑蓝图,然而在软体业,很多公司却找来什么东西都不懂的人去当软体专案经理。要当个软体专案管理人员,好像并不用什么特殊的技能。就很多人的认知来说,专案经理只要能把客户搞定就成了。

在这种情况下,专案经理所订出来的process,就跟瞎子摸象一样。摸到了象的肚子,就说大象像是一堵墙,摸到了象尾巴,就说大象像是一根绳子,摸到象腿,就说大象像跟柱子。分开来看似乎都有道理,可是整个合起来,就像是一大团象屎。每个真正在做事的人,到后来就会像是那只一直被骚扰的大象一样,很想一脚就把这些一直在乱摸的瞎子们给踹开。

其实主要的问题多半不在于参加的人里面,缺乏经验丰富的老手。这些人的确被叫来开会了,也发表了他们的意见,可是他们的意见没有获得应有的尊重。这样讲也不是很精确,应该说他们的意见,经过加油添醋之后,被加了很多不必要的细节进来。

在某一次process review board上。这次刚好是review布鲁斯所写的专案建议书(proposal)制作标准作业流程。在场官位最大的就刚好是布鲁斯的直属老板吉娜。

布鲁斯:我们现在收到sales的RFP(Request for Proposal)之后,就会先进行开发金额跟时程人月的估计。在真正开始要写proposal之前,我们会先进行risk analysis。

吉娜:对呀,这个risk control很重要。我记得以前有很多案子都没有把risk好好分析。你们现在都怎么进行risk analysis?

布鲁斯:我们会依据先前订下来的专案风险评核表,依据专案的复杂度,时程压力,技术难度,人员技能以及我们目前是否有足够的资源,各个方面进行评估。

吉娜:我不是说你分析那些项目,我是说你们都怎么样进行risk assessment,有那些人参加?

布鲁斯:目前这部份主要是专案经理自己视需求进行,技术上的问题会去询问architect,scope有问题会询问去做presales support的工程师,或者去问做过这个领域的系统分析师。

吉娜:所以主要就是专案经理来主导?

布鲁斯:是的。

吉娜:你觉得这样足够吗?

布鲁斯:我们目前这样运作还没有遇到什么问题?

吉娜:没遇到什么问题?我跟你说,你们就是太低估这个risk assessment的动作。我以前遇过的案子,就都是没有进行risk assessment,所以才会到后来问题一大堆。你要把risk list印出来,贴在墙壁上,让每个工程师都知道:『啊,这些就是risk。』你们不要笑。我们就是要让每个人都知道我们的专案有这样的risk,才可以让每个人都有所警惕,就可以防患未然。回到主题来。你们的risk assessment有没有工程部门主管参加?

布鲁斯:目前没有。

吉娜:那你们的人力资源估计根本就不切实际嘛。PM怎么会知道每个部门会有多少人可以用?我觉得以后要把部门主管都找进来,请他们提供意见。以后应该要召开一个risk assessment会议,把sales,architect,SA,部门主管,会计通通都找进来沟通协调。这样子就算出事了,我们才不用背这些责任。

布鲁斯想,啊这样是要多久才可以把这些人都凑齐?他说:老板,可是我们收到RFP之后,都有时间上的压力也。我们得要尽快完成proposal。现在这样会影响整个proposal的作业时间。

吉娜:那接了一个不该接的project,是你要负责吗?做案子赔钱,你要负责吗?事情做不完,就叫大家留下来加班呀?

布鲁斯想,部门主管跟你平起平坐的,干嘛理我?想撇清责任也不是这样?所以他说:我想这牵涉到部门主管的时间,可能还是要请副总进一步裁示。

吉娜:反正你先写进去process里面。副总有意见,我再跟他沟通嘛。好吧,这边我没问题了,大家有什么建议吗?没有我们就继续下去。看看下一个流程。

对于老手来说,这种process上的讨论常常会在有意无意之间,对他们习惯的工作加上很多限制。出发点不见得不好,每个人都想提供他良心的建议。比如下面这一个中医师的建议。

『我建议你跟你老婆做爱的时候,要恪遵九浅一深的频率。因为根据中国宫廷秘方素女经记载,这样可以延年益寿,治疗百病。』这听起来可能跟任何你不是很懂的事情一样,可能背后真有几分道理,可是真的完全照着去做,可能实行没几次,就会收到老婆严正的抗议。

官大的人不见得学问大,不过声音的可见度绝对比较高。大多数时候,他们会把事情看得太单纯,可是很多实际发生非常繁琐的工作,没有亲身参与的人,其实很难体会个中奥妙。很多原本立意良善的措施,其实会带来你根本没有预期到的结果。这种事情在专案执行时,常常是层出不穷。这里面的学问很大,可是很多人,常常在认识不清的状况下,就把所谓的process,窄化成只是一些格式固定的文件而已。


很多人会把process窄化成只是一些格式固定的文件而已。
**************************************************
Process不是只有文件而已,它的重点在于每项工作背后的精神,在于为什么要写这份文件,为什么要做这样的动作,而这些事情,又有谁要参加,每个人又要扮演什么角色。文件只是当你照着去做的时候,所产生出来的副产品。

要让development process真正可以有用,其实就是要让每一个参与的人,都有机会透过教育训练,或是实际工作的印证,可以了解每一个activity详细的步骤,接着就是要给他一份可以参考的文件范本,并且期望让他能够了解流程背后所蕴含的意义,也就是想要解决的问题。

当每个人都有这样的认知之后,就得要改善你的公司制度与文化,让这套process有自我演化跟改善的能力。文件,只是对于没有参与专案的局外人来说,一个判断你是否有照着process进行的表象。

我记得我开始在做案子的时候,那时候客户根本看不懂我们费尽心血所做出来的文件。其实真正的重点不过几张纸而已,不过为了唬人,就把CASE (Computer Aided Software Engineering) tool所产生的一拖拉库文件通通印出来,弄成一本跟枕头一样厚的小书,用漂漂亮亮的卷宗夹装订起来,再印个美美的封面,客户看到就肃然起敬,哇,一边做专案,一边还可以写出这么厚的一本文件,感觉起来这些人就很专业,一定是没日没夜的在努力赶工。

可是那些文件有什么实质上的意义吗?需要交一份文件给客户时,常常都是事后写写回忆录,或是编编故事唬唬人。真正在开发的过程里面,很多人因为没时间,都是虚应故事。文件可能也随便写一写,大家看得懂就好了。

在开发系统的过程中,文件并不是真正重要的关键,只是对局外人来说,这是唯一判断开发团队有没有follow既有流程的一个佐证资料。我个人认为,开发文件存在的价值,在于大家的观念,是否可以透过文件的媒介,进行更有效的沟通,而这个观念,有没有办法也藉着文件,适当的流传给日后要维护系统的人。

除此之外,还有一些文件,则是一些跟专案管理相关的资讯,可以让你从文件,或是一些客观量度的记录中,来了解并掌握整个专案的现况。接着可以让你依据现状,来修正你的策略。以及对于日后的专案,可以有一个预估的基准。

我个人觉得,良好的process并不是万灵丹,不过有蛮多人相信,遵循formal process的专案就会成功。


有蛮多人相信,遵循formal process的专案就会成功。
**************************************************
很多人在检讨失败的专案时,都会把没有遵循严谨的process当做是原因之一。反正大多数失败的案子,到后来一定会荒腔走板,指责他们没有遵照process,通常不会有什么错。

不过我个人觉得,大多数的专案,失败的主因都不是因为没有严格地遵照process去执行。否则这很难解释同样没有遵照严格的process时,为什么还是会有一些成功的例子。即使一切依据标准作业程序来进行,又为什么还是有些案子就是会经历千辛万苦,到最后以失败告终。

改善Development process会让你整个软体开发的过程里,有一个可以遵循的标准。很多人都把重点放在流程的订定上,却不知改善流程并不一定会产生什么实质上的改变,也不一定会带来生产效率的提升。它唯一代表的是,又有了一份新的标准,如此而已。即使公司已经通过各式各样的process认证,如果企业发展的方向不对,或是产品的方向不对,还是有可能会关门大吉。遵守交通规则来开车,并不会保证让你到达终点,如果你的方向不对,怎么开都开不到目的地。

企业面临的问题,大多数并不是因为缺乏一套完美的standard process所引起的。很多时候,就只是单纯的该做的事情没人做,或是该做好的事情搞砸了。这跟process之间,一点关系也没有。遵循良好的流程所规划出来的产品,并不一定会大卖;依据良好的流程,并不能保证执行面一定没有问题。事实上,培养良好的执行能力远比订定process来得重要。

良好的process最大的功用都是在生产与制造方面。遵照process的话,可以让生产出来的产品,有一定的品质,让时间与成本的掌握,变得容易一点。对于软体产业也是如此。订定出良好的process,可以让每个人工作时,弄清楚自己的权责,以及每个阶段应该要产生的output。大家要一起co-work时,也能够运作地比较有效率。

相对地,对于业务行销类的工作来说,其实标准的process就不必然会有什么宏大的效果。大家都遵照标准流程来进行产品的规划,跟产品是否会有良好的市场占有率其实并没有直接的关系。毕竟process著重在于防弊,而非兴利。完全依照标准流程来做事,并不表示客户就会把案子给你,也不表示你所规划的产品,可以在市场上打遍天下无敌手。通常表示的就只是,我确实在产品上市前有做过市场调查。不过仅此而已。

打个比方来说,很多情窦初开的少男少女,为了要成功获取另一半的芳心,摆脱童贞,就会花很多时间研读探讨两性关系的书籍,接着通常就会仔细推敲,到底要怎么样才可以唤起另一半的情欲。按图索骥的结果,通常要来个浪漫的烛光晚餐,悦耳的轻音乐,鲜花,美酒,绵绵情话…。好吧,你花了大钱跟很多前置作业时间,来策划一个完美的夜晚,不过这并不表示只要你遵照这个成功方程式,you can have sex。所有的这些规划,只能保证你有美食,有美酒,有优雅的音乐,有舒适的环境,and nothing more。再好的流程规划,可能都比不上突发的意外,例如:『亲爱的,我也很想要给你…可是今晚不行,我的好朋友提早一个礼拜来了。』

这也难怪,其实不光是在制订标准流程,我们在分析事物的时候,常常会因为自己对于事物的认知。就会倾向于认为依时间顺序先后发生的事情,就是有因果关系。可是实际上所谓的因与果之间,可能根本就风马牛不相及。

在专案结案时,我常常会开一个专案检讨会议。试着去看看到底我们从这个专案里面学到了什么教训,获得了什么收获。当我们尝试要探索因果关系的时候,常常会有人,把两件风马牛不相及的事情,用因果关系来解释。在这边摘录一些以往开会时的会议记录来解释这种现象好了。

●这次的专案会在UAT还出这么多问题,这通通都是我们没有足够的测试人员,执行的测试个案根本就不够多,才会造成这个结果。

事实上在检讨的这个案子在UAT时所面临最大的问题,其实是因为requirement analysis根本就没有做好,导致整个架构根本就不对所造成的。没有足够的测试人员确实是一个问题,不过它并不是主要的原因。

●这个security上的问题,是因为厂商的程式是由外包商开发的,品质太差才会这样。

事实上这个案子在security上会发生问题,其实是因为有某些资讯被cache在proxy server上,才会造成这样的security hole。问题主要是在于proxy server的设定,不在于程式本身。然而在测试时,基于成本以及资源的考量,就没有架构一套一模一样模拟production的测试环境,这个问题,才没有在测试期间找出来。问题的根源,其实跟外包商的品质一点关系也没有。

●我们schedule的delay都是因为没有足够的resource造成的。

Schedule会delay,其实大半的原因在于schedule根本就乱估。Resource确实不足,不过错误的估计才是失望最大的主因。

很多人看到2004年,台湾总统大选的电视台灌票,结局忽然在转瞬之间翻盘,就认为一定是执政党作票。当你看到一路领先的选票,忽然在开出了500多万票后,票数忽然静止,接着则是完全地翻盘,内心要是没有任何疑虑,可能也不尽合理。所以很多人就会直觉地推论,在开票静止的瞬间,一定是执政党在做票。

虽然此刻法律诉讼依然还在进行,不过我个人觉得,很有可能,又是因为我们对于两件完全不相干的事情,用因果关系来解释。开票票数翻转,跟执政党做票,其实并没有办法划上等号,用因果关系来解释。根据目前的了解,这跟媒体卯起来依据民调去灌票比较有关。

当你做了错误的推论后,最后可能就会定出一些根本就不合逻辑的流程跟制度出来。很多事情,我们看到的都只是表象,当他们依据时间发生时,很难不用因果关系去推论。要下这样的结论之前,需要三思。要真正推敲出彼此的因果关系,需要智慧,足够的事证加上冷静的思考,以及经验所累积出来的直觉。


我个人对于process的心得
**************************************************
●专案开发没有一种特效药,是可以跨各式各样的专案一体适用的。你需要了解有那些是该做的事情,为什么要做这些事情,这些问题的前提假设是什么,而目前有什么已知的解法。

●当你确定了你的案子特性之后,就要适当地挑选一个合适的开发流程。案子的规模,技术上的难度,系统的本质,人员的能力…都是应该要考虑的因素。在可以解决问题的前提下,尽量减化你的开发流程。

●当你确定了开发流程之后,挑选一组恰当的开发工具。接着应该把开发工具尽量地整合在一起。

理论上来说,工具应该是我们在决定了要采取什么样的development process之后,经过仔细思考,深思熟虑后,才会挑选出来在专案中使用。不过根据灵犬莱西在『2004狗眼看人低资讯技术研讨会』上所发表的论文指出,百分之八十以上的软体开发团队,当他们要决定在专案里面,应该要采取什么样的development process时,会从他们所习惯使用的开发工具这个角度去思考。百分之十五的人,则从来都没有思考过development process相关问题。剩下的百分之五,则是拥有严重的物种歧视,他们拒绝回答任何非人类所提出来的问题。

现在我们在开发工具上头所面临的问题,多半是在各个不同的领域之间的开发工具,彼此还没有紧密的结合在一起。当你要开发的系统都属于类似的类型时,挑选一组适合的工具,并且思考怎么把这些工具整合在一起,就会是一件让你竞争力上升的事情。


很多人都一直在思考怎么样可以把软体包到比较便宜的国家去开发,以便节省开发的成本。我个人却认为,如果你对于同一类型的专案,已经把适当的工具都整合在一起的话,你根本就不需要把案子外包到国外去。

●选定风险评估项目,并且定期评估。

●监控你的流程执行结果。光是订好流程是不够的,要去看看它执行的结果,并且参照风险评估的结果来调整流程。

●收集各种测量统计数据(measurement),并且要依据measurement的结果来调整你对于专案的估计(estimation)。

●每个案子结束时,都开一个实事求是的专案检讨会议(Post Mortem)。把学到的教训写下来,提供给将来类似的案子做参考。

●对于类似的案子,不要贸然尝试太剧烈的变革。不要把流程限得太死,应该保留弹性让它有自己进化的机会。


很多人在听了一场大师的演讲,参加了一场精彩的研讨会之后,都会期待有个大刀阔斧的改革。好像是拿着一把装满银子弹的枪去打狼人一样,碰碰碰,然后每件事就会迎刃而解了。

改革应该要缓慢渐进,让团队也好,让文化也好,能够有调整跟演化的机会。太过激进的改革,常常会让组织适应不良,最后终究会失败。

●不要为了写文件而写文件。

●如果你没有任何既定的流程,在你规模小的时候可能不会有大问题,可是当人数一多时,没有一套process的team,就像是航行在海上的船只没有罗盘一样。随时都有撞上礁石因而灭顶的可能。

●正确的陈述你所遇到的问题,你就已经找到一半的解答了。

●推动任何process,都需要花钱,花时间,花人力。不过一套良好的process并不能保证任何事情,一个愚蠢的团队依然会做出愚蠢的系统。


结语
**************************************************
开发系统不是只有写程式而已,还有很多杂七杂八的事情要做。很多该做的事情,其实背后都隐含着一个需要被解决的问题。大多数的人,其实并不是很清楚为什么需要解决这些问题,有很多人甚至于不知道有这些问题存在,所以常常会对于繁复的process提出疑问。

流程永远都有改善的空间,即使你拿到了CMMI level 5,那也不表示你的专案就会帮你赚大钱。我个人是觉得,在开发系统的过程里,为什么要做这件事情,要比这件事情该怎么做重要多了。如果你开发的系统类型都很类似,其实一套适合的开发工具就会很有帮助。不过用了开发工具,很容易就会被工具给绑住。这是另一个比较头痛的问题。

我还记得我以往用过一套到现在还是怀念不已的开发工具,Sybase所出的Power Designer 6.0。那是一套进行结构化系统分析时,很棒的开发工具。不过很可惜,后来Sybase往UML靠拢,新的版本怎么样就是觉得不顺手。而我的工作也渐渐往project management调整,所以就跟这个很好用的tool的这个版本,从此分道扬镳了。

每次要进行开发工具的转换,对当事人来说,都是一件蛮痛苦的事情,就像你要告别一段感情一样,习惯的工具总会有让你依依不舍的地方。不过资讯科技不断地发展,各种不同的应用,各种不同的理论,不断地推陈出新,工具汰旧换新的速度太快,也由不得我们原地踏步。

这阵子CMMI变得比较红,很多软体公司也都把改善开发流程,拿到CMMI level 5,当做是一个远大而值得努力的目标。我个人觉得,软体公司应该要想的,其实不是怎么样能够当一个软体代工厂,代工厂可以赚的就是工钱,而软体公司的价值应该在于生产出可以复制,靠卖copy跟license就可以赚钱的软体。

如何开发真正可以创造出价值的软体,并且把它销售给你的客户,让他们心甘情愿掏钞票出来购买,这远比具有严谨的开发流程,来得重要多了。遵守严谨的开发流程,如果整个team都是笨蛋,还是做不出什么有用的东西。有了完善的开发制度,却一直只是做软体代工,而不发挥想像力,想想我们可以做出什么不一样的东西,我个人觉得这是舍本逐末。有大钱可以赚,干嘛整天汲汲营营,锱铢必较于蝇头小利上?

当你有个确定的方向,也找到了优秀的人才,订一套适合你要开发系统的流程,选择良好的开发工具,并且持续地改进工具与工具间的整合,一定可以让整个开发工作如虎添翼。不过如果你已经有了对的方向,也找了对的人才,其实用什么流程开发,这就已经是枝微末节了。

在这一章里,我所做的其实只是浮面的提供一些自己的看法,至于为什么软体开发得要撰写这些有的没有的文件,为什么需要采用一些莫名其妙的工具,这就不是这样子短短的一个篇幅,可以介绍清楚的。那可能需要一整本厚厚的书才讲的完。或许有空时,我会再写一些这方面的主题,跟大家分享这方面的经验。


阅读(224) | 评论(0) | 转发(0) |
0

上一篇:Delayed Project

下一篇:漫谈UML OOAD and RUP

给主人留下些什么吧!~~
评论热议
请登录后评论。

登录 注册