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關于團隊發展的四個階段，還真是需要一段時間。

 轉載請注明出處:http://blog.csdn.net/horkychen

參考: