Process

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

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

※作者注：这世上应该不会还有那个从事软体开发的人没看过骇客任务(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都是笨蛋，还是做不出什么有用的东西。有了完善的开发制度，却一直只是做软体代工，而不发挥想像力，想想我们可以做出什么不一样的东西，我个人觉得这是舍本逐末。有大钱可以赚，干嘛整天汲汲营营，锱铢必较于蝇头小利上？

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

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