X公司的流程改造之路 (一) [课程报告]-阿里云开发者社区

开发者社区> 开发与运维> 正文
登录阅读全文

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

简介: 起点 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对新的项目团队进行培训。

……

周一一大早,RobertEric在公司餐厅边吃早餐边谈论着后面的工作。

Robert:伙计,你要失业了!

Eric: 胡扯什么!这周新项目就要开工了,我应该会忙一阵呢!而你们还可以先休息一会,不过,后面可够你们受的。

Robert:得了吧,兄弟!你不知道Beck那个家伙搞了什么吗?他现在可是准备把设计阶段从项目开发过程抹掉。当然还不止这些。

Eric:怎么可能?不做设计就直接开发?你忘记上个项目怎么失败的吗?Marketing的那个叫Andersen的家伙,三天两头的变更需求,搞得我根本没办法做好系统设计。没有稳定的系统设计就是B项目被Drucker那个老头砍掉的根本原因!

Robert:不要太激动!要生气的应该是我们。设计变来变去,你知道为了配合你那不着调的设计,我们加了多少天的班?真想买本<<人件>>Sutherland看看!真不知道那家伙看过没有。你说没有充分的设计是前两个项目失败的原因,这个我不同意。Sutherland在项目总结会说过,真正的原因是目前的产品没有清楚的定义,所以需求变来变去。根本原因在这里!

Eric平静下来了,自己刚刚只算是宣泄下情绪。 Robert说得有道理。毕竟他们这些程序员的压力并不比他小。他轻轻地朝Robert点头表示同意。

Robert:我有确切的消息。Watts今天就会来我们的办公区上班了,他是咱们下一个项目的PM。而Beck在我们呆了一个月后,上周给Durcker老头提交了一份关于AB项目的分析报告,说我们前面运行的流程全错了,要推翻掉改为SCRUM开发模型。这个模型,我查过,确实是针对Andersen那个善变的家伙的,至少我这么认为。整个开发流程和以前不一样了,这可是一个不小的变化。

Eric开始注视着Robert,听他继续讲下去。

Robert: 其中有一项和你老兄就有关系,因为我没看到专门的设计阶段。而且Beck那家伙还一直在EPG内部的评审会议中反复强调说不要做事先大量设计,可你不就是干这个的吗?这可是内幕消息,我也是花了不少心思的。哦!你看看Myers?

Myers正低着头从旁边走过,像是在思考什么。

Robert:他肯定也得到消息了。他们测试单位也要面临很大的挑战。

Eric沉思了一会,问道:如果真是这样,影响也太大了。不可能说改就改吧!

Eric显然已经从自身转移到对整件事情的关注。

Robert:当然。所以Watts来了。他可是以执行力出名的。

EricGod

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]职场的“中国特色”

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

    工作是有计划的学习

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

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


版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
开发与运维
使用钉钉扫一扫加入圈子
+ 订阅

集结各类场景实战经验,助你开发运维畅行无忧

其他文章
最新文章
相关文章