X公司的流程改造之路 (一) [课程报告]

起点

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就说:”连需求的规格都没做完都要让项目延期”。我对这当然是要抱怨的。总之，市场单位和研发单位的配合不起来。研发团队为了在开发周期内完成100多项的功能，我必须承认，我们后面基本失去了协调能力，没有了节奏，只能是将任务分到每个人头上，然后再由个人对照列表逐项完成。中间发生问题了再报出来。所以我不再是Manager,而是救火队长！你知道吗？我们一开始准备的WBS和Schedule到了项目一半时，基本上已经完全被改版了。手上的事情本来就做不完了，而需求的功能还一直在增加，当然也有些是做到一半不要的。这种情况非常打击团队的积极性。代码质量就成了一个很突出的问题。

 

第三，公司现有制度对团队成员的支持也不够。所有开发人员的绩效考核都是以半年度考评展开的，其中项目的绩效评定以项目周期达成状况决定的。在实际开发中，项目管理团队为了降低风险，在项目规划时故意预留了一段缓冲时间，从而压缩了项目团队的开发时间。面对这个不可能按时完成的项目，其绩效结果基本上定了的。所以团队的动力不足。

 

这些Beck在报告里都提到了。针对这些问题他们提出了解决方案，坦白说，我并没有多少把握。主要是改动太大，怎么才能顺畅的推行下去？这不简单啊。相信这也是你来这的理由。

 

说完，Sutherland冲着Watts点点了头。 Watts认真地听着Sutherland的说明，虽然Beck对这些问题都提到了。但今天听到Sutherland的再次说明，Watts对Beck提出的解决方案也更加有了信心。Watts来之前，Pressman让他和Beck仔细地讨论过一次，但以Watts的观察，Beck虽然将新SCRUM+XP说得像是就为了解决现在的问题而生的，但Beck并没有深厚的项目经验，所以Watts对新方案的态度也很谨慎。

 

Watts准备鼓励Sutherland说下去：你说得很好，让我有了更清晰的认识。那么关于Beck的解决方案呢？真得可以完全解决现在的问题吗?

 

Sutherland随后表达了自己对Beck所提方案的支持，但重点还是对如何执行，心里没有底。Watts清楚下面需要请Beck亲自出场了。

在Beck来之前，Watts必须花些时间了解一下团队。先是请Sutherland介绍了每一位组员，然后Watts下午约每位工程师做了半小时的面谈。在交谈中，Watts已经能够深深感受到团队中充斥着不安的气氛。

 

“看来只有Beck将方案说透，团队才能回到正常的状态了！”Watts想到了Tuckman关于团队发展的四个阶段，还真是需要一段时间。

 

下一篇:  X公司的流程改造之路 (二)

 转载请注明出处:http://blog.csdn.net/horkychen

参考:

  为你的职涯做个清楚的定义

  [FT Chinese]职场的“中国特色”

  程序员谈如何掌握计算机专业英语

    工作是有计划的学习

    职场上个人价值的三个驱动力

    软件工程师两年的职场训练