X公司的流程改造之路 (一) [课程报告]
转载请注明出处:http://blog.csdn.net/horkychen
起点
X公司是一家中规中矩的公司,从事软件开发二十多年,一直使用传统瀑布开发模型,开发流程和相关的制度都已经完善。最近两年因为市场的变化,考虑到公司长远的产品线的竞争力,决策层决定推动新产品领域开发。但是传统的瀑布模型无法满足高层快速进行产品试水的需要,市场部的需求一改再改,并极力打造大而全的产品,虽然他们并不承认。两个项目(A, B)下来开发团队和公司高层都非常不满,团队士气低落,离职频繁。公司高层对项目成果不满,甚至提前中止了第二个项目B的开发,要求公司EPG对两个项目运转进行分析总结,并拿出改进方案,务必使下一个项目成功。经过若干大会小会检讨、分析,EPG指出了公司现有流程无法适应当前开发需求,建议在准备执行下一项目的团队中试行SCRUM+XP。于是我们的故事就从项目经理Watts的上任开始了……
组织结构及主要人物:
Drucker --公司总经理 (原型是现代管理学之父Peter.Drucker)
Knuth – 公司技术总监兼研发副总 (原型是Donald Ervin Knuth, <<计算程序设计艺术>>的作者)
Beck --- EPG单位经理 (原型是Kent Beck)
Sutherland –- 研发团队经理 (原型是SCRUM最初提出者)
Pressman – 项目管理团队经理 (原型是<<软件工程-实践者的研究方法>>的作者)
Andersen – 市场部经理 (原型是<<长尾理论>>的作者)
Myers – 测试部门经理 (原型是<<软件测试艺术>>的作者)
Fowler, Robert – 开发工程师 (原型就不用说了)
Eric –系统架构师 (原型是<<领域驱动设计>>的作者)
Watts -- 项目经理 (原型是<<软件管理沉思录>>的作者)
新生计划
大纲: Watts是一位从事严谨、处事果断的项目经理,在公司内部颇受尊重,常常受命处理极为棘手的项目。这次也不例外。
Watts一上任后,马上展开团队面谈,全面了解项目团队目前的状况。同时也和他的老板Pressman以及市场部的Chris了解高层对项目的期望。当然他的最主要挑战是EPG要在他的项目中导入SCRUM,一时还很难预知其中的风险。所以他需要和Beck, Sutherland一起谈谈,SCRUM到底能为团队带来什么?并要求EPG对新的项目团队进行培训。
……
周一一大早,Robert和Eric在公司餐厅边吃早餐边谈论着后面的工作。
Robert:伙计,你要失业了!
Eric: 胡扯什么!这周新项目就要开工了,我应该会忙一阵呢!而你们还可以先休息一会,不过,后面可够你们受的。
Robert:得了吧,兄弟!你不知道Beck那个家伙搞了什么吗?他现在可是准备把设计阶段从项目开发过程抹掉。当然还不止这些。
Eric:怎么可能?不做设计就直接开发?你忘记上个项目怎么失败的吗?Marketing的那个叫Andersen的家伙,三天两头的变更需求,搞得我根本没办法做好系统设计。没有稳定的系统设计就是B项目被Drucker那个老头砍掉的根本原因!
Robert:不要太激动!要生气的应该是我们。设计变来变去,你知道为了配合你那不着调的设计,我们加了多少天的班?真想买本<<人件>>给Sutherland看看!真不知道那家伙看过没有。你说没有充分的设计是前两个项目失败的原因,这个我不同意。Sutherland在项目总结会说过,真正的原因是目前的产品没有清楚的定义,所以需求变来变去。根本原因在这里!
Eric平静下来了,自己刚刚只算是宣泄下情绪。 Robert说得有道理。毕竟他们这些程序员的压力并不比他小。他轻轻地朝Robert点头表示同意。
Robert:我有确切的消息。Watts今天就会来我们的办公区上班了,他是咱们下一个项目的PM。而Beck在我们呆了一个月后,上周给Durcker老头提交了一份关于A、B项目的分析报告,说我们前面运行的流程全错了,要推翻掉改为SCRUM开发模型。这个模型,我查过,确实是针对Andersen那个善变的家伙的,至少我这么认为。整个开发流程和以前不一样了,这可是一个不小的变化。
Eric开始注视着Robert,听他继续讲下去。
Robert: 其中有一项和你老兄就有关系,因为我没看到专门的设计阶段。而且Beck那家伙还一直在EPG内部的评审会议中反复强调说”不要做事先大量设计”,可你不就是干这个的吗?这可是内幕消息,我也是花了不少心思的。哦!你看看Myers?
Myers正低着头从旁边走过,像是在思考什么。
Robert:他肯定也得到消息了。他们测试单位也要面临很大的挑战。
Eric沉思了一会,问道:如果真是这样,影响也太大了。不可能说改就改吧!
Eric显然已经从自身转移到对整件事情的关注。
Robert:当然。所以Watts来了。他可是以执行力出名的。
Eric:God!
Eric开始担心起来。
上班时间一到,Watts就出现在Sutherland的办公室。两人一见面,相互道了个早安,就直接切入正题。这是Watts的风格,Sutherland也很配合。
Watts:上周在Beck报告会上,R&D这边,主要是Knuth发表了些意见。倒是没听到你讲什么?你是团队的直接主管,我是很想听听你对Beck的报告中关于流程改造有什么看法。
显然, Watts早就看出来Knuth过于偏爱在纯粹的技术领域探讨问题,那是他的专长。特别那三本神一般的著作,公司给每个高管都发了一本。Watts以前就常常拿着它们练练二头肌。现在年龄大了,书也不知道塞哪去了。总之,Watts根本就没兴趣去看那些书,他更关心的是流程。
Sutherland稍稍调整了一下姿势,十指交叉的支住下巴,沉思了一会。
Sutherland:坦白说。Knuth关于技术上的意见是非常正确的。我们的确在一些技术上准备的不充分。而且在开发过程中有一些设计实践和建构方法也不太恰当。特别一些新加入的工程师,在解决问题的能力上常常走弯路,而且得不到有效的支持。所以导致后面Bug一直无法收敛……
Watts打断了Sutherland:老兄,这种的说辞我听得太多了。我们之前已经合作过很多次了,不需要这样避重就轻。我能理解前面两个项目对你造成的压力,而我就是来帮助你解决问题的。所以我们之间需要简洁、高效的沟通。
Sutherland有些尴尬的干笑了一下。曾几何时,自己也是老板指哪就打哪,奋勇向前。但经历越多项目,反而使自己越来越谨慎起来,甚至有些胆小。面对着Watts的洒脱和执着,Sutherland决定找回从前的自己。
Watts继续说:这些问题都只是执行层面中方法论的问题,并不是真正的核心问题。我想听听你对 Beck提出的流程改进计划的看法。
Sutherland:我先说一下先前两个项目的问题。首先,Beck关于前两个项目的分析结论,是正确的。 Beck亲自在这里调研时,我们就已经达成共识了。正如 Beck报告里的那张图,研发团队面临的是两个完全相反的力量。市场端总是责怪我们做得根本无法同其它厂商的产品竞争,同时开发效率低下,开发周期一直拖延。他们根本不理解为什么一处UI上修改会需要不止一天,甚至还引入了一些新的Bug。而另外一边,现有的开发流程要求我们文档一个都不能缺,中间各项制度也不能打破,以免产生破窗效应。
这是研发团队面临的最大的问题。研发团队一般都是指责市场部没搞清楚市场需求,瞎定义,但其中大部分的状况都是针对市场的正常反应,反而是研发团队要学习如何适应。其余的部分就是第二点。
第二,市场部门追求大而全。这里面主要暴露的是产品规格审核的问题,你会发现并没有一个审核机制来约束市场部门对产品的新要求。Knuth没有参与这些细节上的事,所以Andersen总是顶着Drucker的虎皮向研发单位提出新需求。我虽然自行做了一些选择,但却要被指责效率低下。Andersen就说:”连需求的规格都没做完都要让项目延期”,完全无视客观情况。总之,市场单位和研发单位的配合缺少一个有效的方式。
第三,公司现有制度对团队成员的支持也不够。所有开发人员的绩效考核都是以半年度考评展开的,其中项目的绩效评定以项目周期达成状况决定的。在实际开发中,项目管理团队为了降低风险,在项目规划时故意预留了一段缓冲时间,从而压缩了项目团队的开发时间。面对这个不可能按时完成的项目,其绩效结果基本上定了的。所以团队的动力不足。
这些Beck在报告里都提到了。针对这些问题他们提出了解决方案,坦白说,我并没有多少把握。主要是改动太大,怎么才能顺畅的推行下去?这不简单啊。相信这也是你来这的理由。
说完,Southerland冲着Watts点点了头。 Watts认真地听着,虽然Beck对这些问题都提到了。但今天听到Southerland的再次说明,Watts对Beck提出的解决方案也更加有了信心。Watts来之前,Pressman让他和Beck仔细地讨论过一次,但以Watts的观察,Beck虽然将SCRUM+XP说得像是就为了解决现在的问题而生的,但Beck并没有深厚的项目经验,他所谓的成功案例也一直饱受争议。所以Watts对新方案的态度也很谨慎。
Watts现在准备鼓励Southerland说下去:你说得很好,让我有了更清晰的认识。那么关于Beck的解决方案呢?真得可以完全解决现在的问题吗?
(待续......)