上班一年多了,最近一次的大型專案開發在 6/1 上線,來利用這篇文章反省加檢討我參與過的專案管理與開發時程問題。

先講很失敗的第一次,因為對當時的實力掌握太差,所以最後大受打擊無疾而終。

處理的專案是廣告系統的後台,需要改寫並新增功能,但我想完 model ,寫完 CRUD 之後就停滯了。

  • 原因1:當時的我,對於基本網站架構還不夠熟悉,在規劃 CMS 上也不夠清楚,因此上稿的部份寫完,與前台接軌就卡住了。
  • 原因2:寫完那些 CRUD 之後,因為我同時還要顧及美妝的專案,每個月固定都要寫 event ,雙管齊下當時的我無法吃下來。
  • 原因3:時間管理太差,我當時沒有把整個負責部分切開成一張張小票的能力,整個混在一起沒頭沒腦地做,難以掌控進度,也無法知道什麼時候要完成哪些區塊。

最後因為開始寫美妝的 event ,負責的部份就也撥給同事處理,那時候也沒有再拆票過來請我幫忙,從此這個專案就成了我心中的痛,處理的一團糟。

回頭檢視,我真是太傻太天真,做一塊還不夠熟悉的東西(web),也不曉得章法(製作流程),重點是也不知道怎麼開口請教別人給予一些基本指導。

 

再來講最近的一次美妝改版,情況比剛剛說的廣告後台專案好,但有很多值得檢討記錄的地方,這也是寫本篇的目的。

改版的方式走瀑布式開發,雖然我一直很想嘗試敏捷開發,但是我對網站的經驗還是太少,無法充分的決斷與規劃。

在初期,我先挑了一個最麻煩的新品快遞服務來處理,開始將 database 先 porting 成新版的結構,同時做出對應呈現的前台。這次我學乖了,開始試著把這個服務切成一張張小票處理,但是我沒有處理好時程,對於處理事項的權重也有問題。票開好了應該要先排序、找核心票避免解票時發生卡票、相依性太高的票要盡量切小/切開,這些問題我都踩到了,因此開發時雖然一直在做事,但卻像多頭馬車什麼都有做卻什麼都沒有完成,所以在時程上顯示一直 delay。

同時,雖然這段時間美妝的 event 改用其他方式製作,不會花到我的時間,但我決定趁這次機會,將陳舊的 Rails 2.3.4 直接改用 Rails 3.0 改寫,導致初期花了不少時間,將原本的程式搬過來後調整成新版的寫法。另外,由於有做 SSO ,原本的使用者認證 gem 就變得太過肥大,當時我決定將原本的 user authentication library 改寫一份給專案使用的精簡版本,這種種繁雜的問題,使得初期進度極為緩慢。

初期的問題在於,我對 Rails 3 還不熟,所以在估算改寫的時間時,必須要將解決 Rails 3 的寫法這塊也考慮進去。雖然我習慣性地的預留一些開發時間,但是留的太少了。再來,當已經拆出小票之後,優先權最高的應該是 dependency 最高的票,因為這種票不做完會 block 到其他票的進度;其次是要把只有自己特別熟悉的票先做完,因為這種票如果要請其他 RD 協助,是快不起來的。這幾點之中,我只有最後一項處理的比較好,前兩項準則沒抓到,所以做起票來東卡卡西卡卡,成效不彰。

 

中期的時候,雖然花了不少時間,但我有把初期新品快遞的服務功能寫完 90% ,因此當美術把版都切完送過來時,我開始處理第二塊 porting 流行日誌,這時也正式進入五週的技術開發時程。由於先前寫 Rails 3 把部分的地雷都排除過,因此技術上卡住的情形降低很多,不過我在這個階段做錯兩件事,迫使我時程大 delay 。

第一,新品快遞的服務功能完成 90% ,這個數字事實上有 pending 一個在後台接軌痞客邦相簿的功能,決定 pending 的原因很簡單,因為已完成的功能是可以正常上稿,也可以使用痞客邦相簿,只是會多幾道手續,但是如果要完成接軌的功能我得再花 2~3 天實作,以時程來說最高優先毫無疑問是上線,因此我應該先去完成其他的服務,最後有時間再來解這張功能票,但我陷在裡面好幾天,後來主管提醒之下才醒悟。

第二,優先權錯誤,在初期和中期開發上,我都把 database migration 放在最高優先,因此花了很大的力氣去做對應的 convert ,這個決定錯在我應該先生頁面,讓頁面功能正常,再來做 database migration 把舊資料轉移過來才對,畢竟上線會先看的是功能正常,其次才是看資料內容。

由於這兩個原因,讓我做了兩週之後,雖然大部分資料庫已轉好,但頁面依舊有許多是未套版或功能未完成。第一週結束時我還很天真的認為,進度雖然有延誤,但是週末加班趕工可以追上進度,第二週結束後才發現我錯了,檢視之下發現,原因是我切出的票具有太高的 dependency ,可是我花在做 database migration 的時間卻不少,因此頁面功能的進度 delay ,導致時程被越拉越遠...

在第一週發現時程延誤時,我有先告知主管希望把我不擅長的票拆出去,請其他 RD 幫忙,但只有一小部分;而到第二週結束時,我不得不再次告知主管,我很抱歉拖到時程只剩三週才講,可是必須要再請一位 RD 一起寫,否則真的會來不及。幸運地是,雖然我當初花了太多的力氣去做 database migration ,但這部份也是我較為熟悉的部份,因此一起合作 coding 的 RD 在跳進來後沒有被這塊 block 。

 

後期開發上,首要決斷是我完全放棄管理專案,改請主管接手,我不再開會而是專心寫程式,而且很明顯我的排票、時程估算和決策等等都還有待磨練。主管接手之後,他很迅速地根據時程決定 pending 一些有替代方案、以及影響較小的功能,讓所有目標都專注在完成整個網站並上線,同時 RD 的壓力也跟著降低;此外,主管根據我已經切出的票再延伸,讓團隊開發上能夠更加地容易。以往我開票的方法不夠有條理,也沒有切到很乾淨,在做票時也不曉得要設定狀態讓其他 RD 知道,這次讓我都學到了。另一位 RD 加入之後,由於 api 接軌和 javascript 的部分他很熟,功能做起來也相當迅速,而我就可以專心做我熟悉的部份,進度因此明顯提昇,最後得以在 6/1 順利上線。

總結來說,

  • 我對於時程估算非常有待加強,主要是得看出實作上會花時間的地方,有時候魔鬼藏在細節裡,沒做過真的不會知道小地方其實需要花很多時間實作。基本 CRUD 最少要半小時,如果有特殊功能繼續往上加; database migration 非常花時間,一定要儘早處理;遇到有加密的部份,因為涉及到 system library ,最少要撥三天處理(像是 SSO );自己不擅長的技術,要估算兩倍或三倍的時間;有替代方案的功能,可以往後壓晚點做。
  • 我的切票技巧有比以前好,但是切的還不夠乾淨,最終目標應該是切出的票要有正交性。
  • 做票的優先權, CRUD 很枯燥,但是要乖乖地做;所有的 link 都應該先做,不然會缺東少西;拆不開,具有高 dependency 的核心功能要先做,不然會 block 後面的票;只有自己能做的票要先做,以免影響到其他 RD 。
  • 排定時程時,從容易的功能開始,排在時程末端,接著依序將越難的功能排到越前面的時程。訂好的時程,要每天或是每兩天檢查,延誤一週就要趕快求救。

以上這些,是我親身的專案經驗檢討,雖然兩次專案都沒有處理好,但記錄下失敗的經驗,避免以後重蹈覆轍。這次趁著記憶猶新,將這兩個月的苦日子回想了一遍,盡量客觀地把自己的問題找出來。沒有人喜歡失敗,我也不例外。

笨笨小蟹 發表在 痞客邦 PIXNET 留言(0) 人氣()