走出软件泥潭 第一回 雪上加霜

 

2012年的第一场雪，漫天飞舞，飘扬在整座城市。北风狂吼着，呼啸声中夹杂着漫天的飞雪。狂风暴雪仍然阻止不了上班人的热情。这座城市的软件园永远都是那么热闹，才刚到8：30。路上的雪已经化干净了，远处山上已经被雪盖得全白了。马路上的汽车来来往往，卷起雪泥，催促着人们赶紧跑到办公室。

 

吴俊芳今天起得特别早，一大早就来到的办公室，她今天要召开一个特别重要的会议。这个会议她已经准备了很久了。作为北方ITO公司的总经理，她已经困扰了很久了，最近更是焦头烂额。早上人一到齐她就把各个部门的部长（部门经理）召集到会议室，又叫上质量推进部的严俊经理。这个她准备了很久的会议开始了。

“大家好，可能众位也有所耳闻。最近日本经济不景气，发注量(订单)大为减少，并且汇率也在下调，再加上最近劳动力成本上涨，同行压价。种种外部压力促使业界各个企业都在变革。但是现在的情形，大家都在拼价格，拼资本，看谁能挺到最后。这无异于自杀。我们也面临这种情况，我们到了不得不变革的时刻了。前阵子我们打算跟客户谈涨价，但是客户说这是我们的经营管理问题，很显然这条路已经行不通了。现在公司也在寻找一些用人民币结算的客户，以减少汇率的影响，但是这只是缓解的策略。所以，我们要从更为本质的角度去改变公司的经营状况，在所有的竞争对手中获取竞争优势，这样才能够在竞争中胜出。在过去的一段时间，我请质量推进部的严经理将我们的情况进行了一些总结，根据这些数据整理出了一些结论，我把各位请来一是看看这些数据和结论，二来也想听听各位针对如何变革有什么样的见解。下面请严经理。”

严俊打开他的笔记本电脑，展示了一份幻灯片。这份幻灯片是他最近这一段时间来精心整理又经过总经理反复若干次确认才形成的。今天这个会议关系到公司今后的成败。因为他也难免有些紧张。

“大家好。这份幻灯片的数据是根据过去3年来我们各个部门提供的数据整理总结的。基本上是从质量成本交货期这三个角度总结的。首先是质量数据，我们过去的三年中，千行代码缺陷率为单元测试阶段8.4个，集成测试阶段4.6个。这个数据在同行中算是中等水平。而在代码复查阶段，每千行能够发现8.35个缺陷。详细设计阶段，我们的缺陷率为每页发现4.32个问题。另外，在所有的Bug中，bug的引入阶段，35%来自设计阶段，40%来自编码阶段，25%属于需求理解错误和其他沟通类问题。这在行业中也算中等水平。”

说到这里，严俊来了个停顿。吴俊芳接过话头。

“虽然过去的数据显示我们处在行业平均水平，但是我们的客户显然对这个数字已经不能够满意了。我们需要提升我们的项目管理水平，首先就得从质量着手。要知道每个质量问题到了客户那里就是一个问题，而每个问题会引起我们的返工，而返工就是成本。所以提升质量是我们的首要任务。下面请大家各抒己见。”

“我觉得提升质量的从上流（上游）工程入手，得从设计阶段就提升质量。”发言的是测试部的部长孔令有。

“那么，具体如何做呢？”开发一部的刘星部长觉得这是一句有敌意的发言，立即就反击。很显然，光做测试的人在这里是无法提出如何具体提升设计质量的——因为他从来没做过设计。见孔令有没有回答，刘星继续说，“我倒是觉得问题并不是出在设计阶段，而是需求的问题，客户总是在项目末期进行需求变更，而我们最初的时间规划上并没有这样的规划，这是导致我们成本增加的原因。所以我们应该提出让客户在详细设计阶段开始之后就固定需求。”很显然，把错误推到客户身上，就会把自己的责任推的干干净净。

可是，吴俊芳也是老江湖，这诡计并不能在她那里奏效。“客户固然有客户的原因，找客户的原因并不能让我们改变什么，我们就会回到旧的轨迹上去。这样，对改变并无任何帮助，我希望大家能够想出更多更有效的方法来。”

“我觉得，”刘星觉得这话说的有些和平时不一样了，也不禁感到了气氛有些压抑了，只好硬着头皮接着说，“其实，我们的问题出现在复查上，如果我们的复查能够更仔细，后期问题也就不会发生那么多。所以，我建议增加复查的力度。”

“虽然复查可以一定程度提升产品质量，但是复查花费时间太多，我们可能得不偿失。”开发二部的韩京有不同的看法。“我倒是觉得，测试组应该增加测试力度。”

眼看着照这样下去，会议是开不出结果的。还好，吴俊芳早就对此有预料。她觉得该抛出自己的答案了。

“我觉得，大家提出各种不同的建议都很好。但是，每个人提出的解决方案都是从一个点入手。我们需要从整个流程上入手来解决质量问题才可以。”

严俊知道该轮到自己发言了。“其实我们的质量状况处在行业平均水平。关于这一点我去考察了一些行业中比较领先的公司，他们的做法有值得我们借鉴的地方。比如说：刚才提到的固定需求，减少变化，这一点可以在合同里写上，如果需求变更达到5%以内免费，而超过5%则开始收费，这样可以减少风险。另外，从项目早期阶段入手提升质量有助于后期的质量提升。所以即使在项目的上流工程投入更多的时间复查，在后期节省的时间会更多，这是值得的。另外，也要提升一下各个工程阶段的指标。”说着他打开了另外一张幻灯片。这是一张V模型图，上面标注了软件开发的各个阶段，每个阶段旁边都标注了一个小框，小框中写着一些标注。

“详细设计阶段，我们以前的指标是每页复查的问题为4~6个，现在我们可以提升这个数字为6~8个。代码复查阶段的缺陷密度为每千行7~10个，现在我们可以提升为10~14个。单元测试阶段为8~10个，可以提升为10~14个。集成测试为4~6个，也可以提升为6~8个。执行更严格的质量标准，可以减少后期因为需求变更和客户验收而带来的成本。”

“大家还有什么补充吗？”吴俊芳不失时机的提问道。

看来这是一出早就排练好了的双簧，连幻灯片都准备的那么完整。还说什么呢，大家自然就是以静听为主了。

严俊接着说，“下面就是成本方面，在成本方面，我们的平均工资也处在行业的平均水平。这里不方便提供完整的数字。但是，我们可以想想其他的办法来降低成本。刚才提到的提升质量就是一种降低成本的好办法。大家有什么其他建议，还请多多发言。”

有了刚才的情况，大家有些面面相觑，不知道该如何是好。

“我们过去支付的加班费太多了，可以考虑减少些加班费，比如：每天晚上减少两个小时的用餐时间，不必支付加班费。”刘星第一个发言，看来这个事情他已经憋了很久了。“长期以来，有些员工在外边吃晚饭的时间太长了，只有这样才能够避免他们蹭加班费。”

“其实公司的旅游也没有必要搞得那么夸张，就在郊区找个地方，大家热闹热闹就可以了，这也可以省不少钱。”韩京补充道。

“我觉得返工是最大的成本”，孔令有的发言似乎总是有针对性。“我们每次测试都至少要5轮才能够交付客户。要减少轮次才能够有效降低成本。”

           刘星似乎一直不喜欢他的发言，“可是导致返工的主要原因不是代码质量不好，而是测试组没有把测试用例提前交给开发组，如果开发组提前知道测试用例就能够更好的提高质量。”

“测试组是为了能够站在客户的角度上来验证软件质量，如果提前把测试用例告诉开发组，开发组就不会提高代码质量了。”孔令有不甘示弱。

“我看并不是这样的。测试组是担心测试用例提前知道了会失业对吧？”流行的发言似乎针对性很强。

“我也觉得测试组的用例不能够提前交给开发组，如果开发组知道了测试用例，有针对性的编写代码就无法保证代码质量了。”孔俊芳补充道。

既然总经理已经定方案了，大家就不好再说什么了。

经过了一会儿的沉默，严俊接着说，“下面我们要说的是交货期方面，我们在交货期方面有些不好，因为我们总是比计划晚交付3~4周。这个和成本也是挂钩的。”

“可是，你要知道，我们提升了质量，就要进一步延长交货期，如果不延长交货期，那就要增加人数，提升成本。要是控制了成本，就得质量下降。总之呢，QCD(质量成本交货期)三者之中最多能够同时兼顾二者。这是一个经济学难题。”刘星看问题就是很尖锐。

“对。”韩京附和道。

“是”“对”，其他的部长也都有相同的想法。就连一直和刘星作对的孔令有也符合了这个说法。看来吴俊芳要在这三者中选两个了。而这个确是她一开始没有意料到的问题。

“这个问题我们先放一放，大家说的是有道理的。”做总经理这么久了，处理这种紧急情况他还是很有经验的。“不过针对这三方面的改进我们还有一整套的方案。除了刚才的流程图之外。还有一系列的政策。”

“过去我们的加班量不是很多，而且加班时间很多员工都在外边吃饭吃了很长时间。我们要增加加班量。”这话是严俊说的。“另外，我们的人员等级中，高级工程师数量偏多，应该按照合适的比例去控制，多采用些初级员工，降低成本。还有，会议时间过长，应该控制会议时间。”每讲一个改进点，他都会翻一页幻灯片，而且，都有一些数据在支撑。显然，这一切都是有备而来的。

“下一个项目我已经谈妥了。就由开发一部开始试点，成功以后全公司推广。其他部门也要支持他。这是关系到公司今后发展的重要项目。”吴俊芳在最后总结道。

“好的，下面刘星留一下，其他人可以散会了。”

吴俊芳留下刘星，跟他讲述了一下这次变革对于公司的重大意义，并且对他过去的表现大加赞赏，表示，只有他才是实行这个改革的最佳人选。因为他头脑够聪明，灵活。刘星自然欢欢喜喜的接下了这个重任。

 

窗外，雪花飞舞的更欢快了。不远处一座大钟当当当的，正好敲响了十下。

吴俊芳，望着窗外的远山，似乎，一切都很明朗。