新手筆記-持續改進實踐：開發計劃的改進 (轉)

新手筆記-持續改進實踐：開發計劃的改進 (轉)[@more@]

標題：網站開發新手筆記-持續改進實踐：開發計劃的改進

關鍵詞：網站開發、開發計劃，過程改進，過程實踐

  7月12號：越來越懶了，夏天的太陽就是讓人懶懶的不想動……

:namespace prefix = o ns = "urn:schemas--com::office" />

真相總是雜亂無章，支離破碎，漫無目的，乏味的……，真相永遠不會有趣，因此我們需要藝術。（引自高盛公司《關於中國與世界的五大神話》）

過程改進，CMM，諸如此類的名詞在無數地方被人談論著。有個朋友告訴我，在他每一次面試專案經理的時候，無論是大公司，還是小公司，都要問他是否瞭解CMM，是否瞭解ISO？可見這些名詞的熱度有多高。與此情況類似的是，幾年前XML開始熱起來的時候，很多人言必稱XML。可是真正XML這玩意對專案，對組織來說有什麼意義？我想並不是所有人都回答的出來！

在我的理解中，其實這些東東並沒有什麼特別的地方。書本上也早就告訴過我們，CMM的核心之核心就是改進，什麼組織改進呀，什麼過程改進呀，其它的可以放到一邊（除非你們的公司要去想辦法透過這類的評估或）。XML更是什麼都不是。所有理論與標準對你的技術與管理方面的實踐都只具有指導作用，最終有用的還是要開發人員在組織內部，專案過程中切合實際的方法，策略，才能真正實現。

下面的筆記主要是比較了兩份不同時期我為網站開發制定的工作計劃。而制定工作計劃的方案都是具體根據對網站開發工作的理解，對工作任務的切分，對人員能力的計算。並且最重要的是，可以體現過程改進在工作中的具體應用。

簡要介紹需要定製工作計劃的任務。兩個月前，我接手的網站之後的第一個正式的任務是要完成頻道A。制定頻道A工作計劃並完成之後，透過總結，得出了可以進行改進的方面。緊接著的第二個正式的任務是完成頻道B。下面就以技術部門為頻道A與頻道B定義的開發計劃為例，簡要的說明網站的技術部進行的過程改進實踐。

頻道A開發之前總結的問題

開發頻道A之前網站進行了一次規模很大的改版。改版過程花費的時間幾乎是開發計劃中定義的開發時間的三倍，進行改版的同時，網站開發部門還要處理網站的日常維護工作。由於工作量大，並且工作的組織比較混亂，幾乎每一次交給網站部門的工作總是一拖再拖。這種情況下網站開發部門給其它部門的印象就是開發計劃的制定與沒制定沒咋子區別！技術部門從各個方面瞭解情況之後，總結出問題可能在以下幾個方面：

a)  任務劃分的尺度不正確

改版是一個非常大的工作任務，而當時配備進行網頁的開發人員只有與兩人。在這種情況下，定義的開發計劃時並沒有將大的任務切分成小的任務，進行分步的提交確認。所以最後出現的情況是，在拖了一個月之後完成的所有頁面開發之後，統一的內容測試與確認後又一次性的提出了超多的修改意見，再花了兩個月的時間改，再提交，再改。計劃的拖延可想而知。同樣問題其實在開發的工作中也遇見過。對應的解決方案無非是根據可以參與開發的人數，正確的定義任務的細度。找出一個合適的切割任務的方案。

b)  需求文件不完善

網站內容生產部開發的需求文件是“創意十足”，可是開發文件形式的創意對開發部門來說就是一場災難。沒有統一的文件，沒有統一的說明方法。並且絕大部分情況下內容生產部的同仁也並不清楚是否將需要表達的東東說清楚了。於是開發的過程中，反覆在開發過程中找技術部門進行確認，浪費了雙方大把的時間。

c)  開發過程不透明

開發人員按照自己的想法進行開發，與內容生成部門同仁進行溝通，但是領導們並沒有一個渠道去隨時瞭解各個過程的開發到什麼程度？而是透過開會過程中的相互扯皮來了解工作進度。導致所有人對開發進度的信心不足。

d)  需求經常根據時間在進行變化

網站資訊釋出是一個非常靈活的事情，當你開發出頁面進度無法得到保證時，需求的經常進行變化就可想而知了。在前一期的開發中，經常出現的現在就是完成一個階段任務過程中，開發人員要不斷的與內容生產部門的人員確認需求，確認完成之後，又出現需求變化，又要改，無法上線，過了一段時間改完之後，上一期的需求已經過時，又出現新的需求……，開發與網站內容兩邊都叫苦不迭。

頻道A開發計劃

總結上面提到的問題之後，技術部門針對上面各點分別做出了一些對策。比如制定需求文件模組；培訓內容生產部的使用需求文件模板；過程互動強制採用的形式，並抄送給各個相關部門以統一工作進度；將任務合理的分成幾個較小任務，等等。在這種普遍改進的背景下，頻道A的開發計劃出爐了。雖然沒有解決所有的問題，不過應該說已經運用過程改進的方法改進了工作互動，改進了工作的流程。

²  頻道A的開發計劃

頻道A的開發任務被分成四個小的任務：欄目A、欄目B、欄目C、欄目D。技術部門分別為這四個任務定製了開發計劃（以其中一個開發計劃為例）

“欄目A”工作計劃：

  i.  需求+設計；（涉及部門：內容生產部+技術開發部） A天 （需求討論，形成設計文件。）

  ii.  美工頁面開發；（涉及部門：技術開發部美工組） B天 （根據設計形成美工開發的頁面）

  iii.  資料準備；（涉及部門：技術開發部資料組） C天  （準備提取資料的語句，或過程，並採用加速生成靜態的資訊資料。II步與III步是技術兩個不同的組同步進行開發的。開發計劃中安排的時間也是重疊的。）

  iv.  頁面整合；（涉及部門：技術開發部頁網開發組） D天 （將靜態的資訊資料檔案與美工頁面進行整合，形成最終頁面）

  v.  測試；（涉及部門：內容生產部+技術開發部） E天 （兩個部門共同協商，完成測試與修改工作。）

上面定義的開發時間都是在以前的開發上定義的（由於我以前制定的都是軟體工作計劃，網站的開發計劃還是第一次制定。所以上面的開發計劃有純軟體開發的影子。）

²  完成頻道A後遇見的問題

第一期結束時，我們完成的任務的情況大概是這樣：

²  欄目A：定義時間是三個星期，最後是晚了二到三天完成；

²  欄目B：定義時間是三個星期，最後是晚了二到三天完成；

²  欄目C：定義時間是三個星期，由於前面的欄目開發時間過長，最後是晚了五個工作日完成；

²  欄目D：定義時間是一個星期，由於前面的欄目開發時間過長，最後晚了七個工作日完成。

雖然晚了很多時間完成，但是相對以前的開發過程已經有了一定的改進。由於初步體現出了過程改進帶來的好處，所以我們並不沮喪。並且我們在開發過程中又總結了很多的經驗與教訓，可以將這些經驗帶入下一期的開發過程中，以實現持續的過程改進。

總結出的經驗教訓主要有：

Ø  沒有抓住網站開發特點，將確認與修改過程制度化

透過幾個小任務的開發過程，技術部門已經總結出一個規律。雖然內容生產部門各個同仁的適應技術部門定製文件，流程的能力並不相同，但是平均下來，每一個小的任務都需要二到三次的確認，修改過程才可以達到上線的程度。總結出這個規律之後，可以在開發計劃中加入確認的流程，以定義出更符合本公司網站開發實際的制度化的開發流程。

Ø  內容生產部門同仁的責任不明確

頻道A的開發計劃中，只在I，IV中涉及了內容生成部門。實際情況是內容生產部門的同仁在每一個步驟中都要發揮主導作用。但是就算是在這兩步工作計劃中，定義的完成任務的責任人都還是技術部門的同仁，更別說其它的工作的步驟。這種情況的後果就是開發時責任不明確技術部門非常的被動。很多的東東等內容生產部門的同仁的拍板，但是內容生產部門的同仁由於沒有明確的責任，對技術部門的問題並不能保證及時響應。總體來說這個問題涉及到管理上的問題，需要技術部門與內容生產部門進行管理上協商。工作計劃的過程由於有一部分的參與者的責任不明確，最後完成時發生延誤的現象也就不奇怪了。

Ø  任務完成的時間沒有明確與上線時間結合

測試這個詞在不同的地方有不同的含義。並且網站上線的時間點是所有的人最為關心的時間點。上面已經提到過網站欄目有很強的時效性，也就意味著很多情況下，根據時間的進行微小的調整不可避免。所以網站的測試與軟體的測試不同，需要進行微小的調整的流程分離出，移到網站日常維護的流程中，安排其它的人進行處理。測試完成的時間應該是晚於上線時間，所以對應需要進行開發計劃的修改。

經過總結與討論，技術部門進行了第二次過程改進，修改了開發計劃。並完善了很多的過程中需要加入的文件。進入了頻道B的開發過程。

頻道B的開發計劃

1.  頻道B的開發計劃

頻道B的開發任務被分成五個小的任務：欄目I、欄目II、欄目III、欄目IV、欄目V。技術部門分別為這五個任務定製了開發計劃（同樣以其中一個開發計劃為例）

開發“欄目IV”：

  i.  需求+設計；（涉及部門：內容生產部+技術開發部） A天

  ii.  資料準備；（涉及部門：技術開發部資料組） B天

  iii.  美工頁面開發；（涉及部門：技術開發部美工組） C天

  iv.  美工頁面確認；（涉及部門：內容生產部）D天

  v.  頁面整合；（涉及部門：技術開發部頁網開發組） E天

  vi.  第一次綜合確認；（涉及部門：內容生產部） F天

  vii.  修改問題；（涉及部門：技術開發部頁網開發組） G天

  viii.  第二次綜合確認；（涉及部門：內容生產部） H天

  ix.  修改問題，上線；（涉及部門：技術開發部頁網開發組） I天

可以看出，頻道B開發計劃是帶上很強烈的網站開發過程烙印開的開發計劃。主要加強的部分是對應頻道A開發中總結的問題進行處理的。

Ø  對應內容生產部門三次明確的確認過程，並寫清所承擔的責任。

以上的步驟IV，VI，VIII步都是為內容生產部門定義的明確的計劃任務。並且技術部門為其定義了確認文件的格式，以統一流程。

Ø  寫明上線的時間點，並且規定上線時間是欄目開發的最後時間點，其它的修改將轉移到日常維護的流程中

將開發與日常維護分離，使得開發的成果在合理的時間上線，滿足各個部門的需要。

相對頻道A的開發計劃，此份開發計劃執行起來比較明確，可操作性比較強。

並沒有結束的改進過程

改進過程永遠不會結束。也許在頻道B的開發過程結束之後，技術部門與業務部門的磨合程式更高了之後，我們在可以找出更好的開發計劃的制定方法。

差點忘了寫我為什麼用最上面的一段話作為這篇筆記的開頭了。一開始其實我只想將“真相總是雜亂無章，支離破碎，漫無目的，乏味的……，真相永遠不會有趣，”引進來，是因為我覺得只有理解這些才能理解持續改進的想法。事情總也做不好，不是誰的錯，不是誰笨，而是過程不合適，而是真相本身就是雜亂無章，支離破碎，漫無目的，乏味的……，所以我們需要的只是改進一點，再改進一點，最後找到最合適自己的方式。就從現在開始吧JJJJ