◎ 本文轉載自 Blog.XDite.net。
我在網站程式上線前需要準備的事(四)提到了為了順利進行專案,一個好的專案管理系統絕對是必備的。
專案管理系統背後運作的邏輯何在,就是這篇文章主要的重點。
Issue Tracking system,顧名思義就是紀錄、追蹤問題的系統。BugZilla、Trac、Redmine、JIRA、lighthoustapp、Basecamp…等等這幾套軟體,都是知名的 Issue Tracking system。
一套合格的 Issue Tracking system 的 Issue 至少要可以紀錄這些內容:
其中 Redmine、JIRA、Basecamp 並不僅止是 Issue Tracking System,更精確的來說,它們應該被稱為「專案管理工具」。
它們多半能夠提供以下作用:
網站程式上線前需要準備的事(四)這篇文章刊出後,得到不少的迴響。其中我看到的絕大多數的回應多是多半抱怨 PM 根本不稱職不盡責,只顧著畫規格,然後只按照自己寫出來的無法執行的天才(?)規格的催進度。所謂的 M 不是 Management,而是 Magic。即使成員賣了命的加班,專案還是得不到好的結果:超時,品質粗糙,成本過高,scope 過大無法完成。
在我進行開發軟體專案時,也發現所謂的其實絕對多數的 PM,其實職稱與進行的事務完全不合。它們的工作內容往往只有 Project Planning,應該被稱作是 Planner,而不是 Project Manager。
一個軟體開發專案,最重要的變數有四:成本、品質、時間和規模。真正的 Project Management,是能夠準確 Manage 這四項變因,在可以接受的與變動差異下,完成整個專案,產出預期的成果。
我認為 Project management tool 可以協助做到專案中以下幾項的管理:
專案會無限膨脹,主要多半是因為規模的掌控不佳。而規模掌控不佳,時間和成本就會隨之膨脹。
規模之所以膨脹,有幾個原因:
所以,專案需要一個工具能提供以下功能:
一個專案中,最寶貴的資源是「時間」。什麼東西都可以用「錢」買到,唯獨時間不能。在專案中時間最容易被浪費的地方在:
所以,專案需要一個工具能提供以下功能:
同時,專案最好能夠搭配舉行每日的 Standup Meeting,確保每個人正在進行的方向是正確的,以及確保專案資源沒有被浪費的跡象。
一個專案,成員至少會有兩人以上。兩個人以上,就會有溝通與工作協調安排的問題。專案的工作項目往往是有 related 的,少有獨支。 比如說 Planner 沒有把規格寫完,RD 和 Art 就不太容易先動工。沒有把 Database schema 規劃好,後續就很難繼續開發程式。
這也是專案當中最傷資源的狀況:優先權等級為:「block」票。因為 A 方沒有交付,導致 B 方不能交付,連帶導致 C 不能開始。
而專案當中也有很多工作項目分別是「對最終專案目標很重要,但當下不重要」、「對當下 milestone 很重要,對最終目標沒那麼重要」,「只對合作同事很重要」…etc
如果工作項目不能夠按照當下狀況調整正確的優先等級分派給團隊成員。就很容易會造成所有的人雖然很努力,整體工作效益卻非常低的情形。
當然,不只是 Project Manager 需要知道全部的人今天要做什麼。而被分派到項目的成員,也需要能夠知道自己當天所需要執行的項目依序是哪些,按照優先狀況完成。如果優先狀況有錯誤,可以及早告知資源協調者 (Manager)。
所以,專案需要一個工具能提供以下功能:
Project Management,並不是在專案的一開始設下「完成時間」,切出所有「工作項目」,列出「完成目標」這麼簡單。隨著專案的進行,開始會有很多變因出現,造成資源不足,需求改變,規模追加,人力減少…等等的挑戰障礙出現。
都在考驗著專案經理對於資源調配的管理能力。能不能在預定的時間、預定的預算、預定的人力資源內,如期完成當初設立的目標以及交付達到品質要求的產品。
如果條件不允許,當下必須作出取捨、做出決定,而非死板的捍衛規則與命令。
所以,專案需要一個工具能提供以下功能:
若讀者對於專案管理有興趣的話,研究過一些「敏捷開發」的 method,不管是 XP、Scrum、Kanban…,你會發現到這些工作方法都在傳達幾件類似的事:
而一個好的 Project Management Tool 能夠輔助專案具備以上的特徵。
還是老話一句:真正的 Project Management,是要能夠準確管理,成本、品質、時間和規模這四項變因,在可以接受的與變動差異下,完成整個專案,產出預期的成果。
「Project Manager」必須要做到的事,也就是要在動態的環境下,利用種種手段盡力讓這件事發生。
所謂的「Project Management」其實可以用很科學的手段達成,因為事實上這本身就是一門科學。
一般所謂的 PM 很常誤以為 Project Management 就是用 mail+excel、口頭分配任務,得到專案成員的口頭回覆,接著只要坐著回去發呆或無時無刻的跑到座位上催專案成員作事,整件事情就會發生。如果你真的一直這樣想,我想可能最後程式設計師可能做的事:就是直接用 shell script 換掉你。
no kidding。
▲ 圖1:Thinkgeek : Go away or I will replace you with a very small shell script (https://www.thinkgeek.com/tshirts-apparel/unisex/frustrations/374d/)
▲ 圖2:廣告:Essential Rails Pattern 開始 update 了
Essntial Rails Pattern 這本書已經進入排版階段。 詳情請看這篇文章。