軟體工程與專案管理的方法論以及參考書籍非常多，無論是最傳統的PMP，到近幾年強調的Agile, Extreme programming，以及創新公司最常用的Scrum，這些方法都不外乎希望能盡可能圓滿達成專案目標。
而越後面產生的方法論，似乎都盡量想要化繁為簡，貼近事實，以便彈性的因應改變。例如Scrum就是將需求變更控制在sprint開始或結束，並且讓每個短暫的sprint(3-5週)可以專心於現在的計劃，改變於是乎就受到控制。
專案經理的角色和技術領導相輔相成，只是目的截然不同。專案經理最終的目的其實是”管理利害關係人的期望” (Manage stakeholder expectations)。實務上，這個目的甚至比專案在時間成本內達成來的重要。
技術領導雖然不是專案經理，但實務上，技術領導的小團隊是專案執行的最適切單位，因而技術團隊領導者也是反映真實狀況的適切人選。
技術領導當然不見得一定需要知道專案管理的細節，然而在軟體專案的執行中，技術領導者瞭解得越多，越能讓專案有機會成功。瞭解得越少，越容易受困於專案管理的本身。
(參考案例一）
專案經理(PM)在專案一開始就召集所有分析師(兼為小組長)進行傳統的WBS製作，完成了一份洋洋灑灑專案管理文件。在缺乏專案管理的知識下，三個月後在專案中期，某小組長發現有很多事情其實未列在WBS中，他就很掙扎要照常繼續回報列出來的項目？還是要重新修改WBS？
(1) 萬事起頭難：起初，專案計劃
作計劃這件事很重要，相關的名言也很多：
- 廟算者勝，得算多也；未戰而廟算不勝者，得算少也；多算勝，少算不勝，而況於無算乎。
- A goal without a plan is just a wish
- Fail to plan, plan to fail
- Plans are of little importance, but planning is essential.
- You can't predict the future, but you can plan for it
- The general who loses a battle makes but few calculations beforehand
- Planning is everything. Plans are nothing!
任何專案管理方法論都會涵蓋”做計畫”(planning)這件事情，原因也很簡單因為這實在太重要。可是也太容易被忽略誤解或輕視。
無論任務範圍大小，多寡，範圍，一個適切的”文字化計劃”對於軟體專案絕對重要！特別是有任務是整個團隊曾經執行過類似的，”原則上”只要根據以前的經驗”照著作”就可以達成，這種特別容易被資深員工忽略的任務特別容易出錯，更何況”照著作”等於是打算重覆過去的經驗，而不是打一開始就意圖要精進。
無論任務範圍大小，多寡，範圍，一個適切的”文字化計劃”對於軟體專案絕對重要！特別是有任務是整個團隊曾經執行過類似的，”原則上”只要根據以前的經驗”照著作”就可以達成，這種特別容易被資深員工忽略的任務特別容易出錯，更何況”照著作”等於是打算重覆過去的經驗，而不是打一開始就意圖要精進。
忽略："現在時間很急迫，不趕快做來不急，就不先搞計劃了"
越是急迫的事情越不能出錯，減少出錯的最基本方式就是先行計劃。更重要的是簡單的思考整件事情，並且寫下來，適事情大小，不但不花太多時間，而且最能降低的風險以及未來避免浪費時間來修正錯誤。
誤解："作計劃要花很多時間"
一個複雜的任務絕對需要花時間計劃。但是一個簡單的任務，可能只需要花15分鐘把心裡想做的事情簡單地寫下來。這個過程就可能會讓團隊避免發生前述案例中無聊的錯誤和不必要的問題。
輕視："作計劃是給老闆看的，反正事情都不是照計劃進行，計劃對我們沒有用"
這種想法跟不打算作計劃完全一樣。等同於靠運氣跟個人當時心情來決定最後任務的好壞。
做計畫並非僵化，計劃的本身形式也不拘，一個簡單的心智圖(mindmap)就可以整理思緒 揭露許多未來的可能性。
下圖是本文撰寫的第一個計畫，可以和最後的結果比較看看，雖然粗糙，而且之後順序以及結構也有很大的改變，但是計劃的本身卻是很簡單可以引領思考。
(參考案例二）：
有個售前支援團隊，與各國業務長久一起合作習慣了，常常四處進行軟體產品展示任務。有一天得到通知要去東南亞某國家進行安裝測試，大家都以為當地業務會大致把前置作業搞定，因此就迅速訂機票出發。到現場才發現，客戶負責的技術人員當天根本就沒來上班！整個作業只好延宕一天。
任務分配
團隊合作必然涵蓋工作分配。在資訊科技領域中，分配的方式也有很多種。而對於一個團隊的技術領導者而言。當已經對自己以及團隊的能力有基礎認知之後，有效的工作分配是一開始就要先計劃的事情之一。
技術領導者必然是已經瞭解自己也大致瞭解團隊能力，同時也瞭解任務內容之後，才能進行計畫任務分配。任務分配可以是團隊所有人一起討論，也可以技術領導者自行決定，但無論如何一定要先考慮團隊成員能力彼此之間的比較利益。
比較利益法則最早出現在經濟學鼻祖大作國富論的第一章(亞當斯密,1776)。衍生的，基本概念很簡單，只要有效分配，任何情況下都可以達到1+1>2的效果，即便專案成員某些人明顯地比其他人能力還差。
(2) 專案專案執行中面臨的問題
專案執行面臨的問題 - 人的偏誤
人類判斷事情會先採用快速直覺，這乃是上百萬年來的演化，無論是視覺上還是意識上皆是如此。以下簡單列出常見的人類認知偏誤：
歸因謬誤（Attribution Biases):
解釋別人的事情時，會傾向別人的內在因素，解釋自己的事情時，會傾向外在因素。例如：會議有別人遲到，心裡會想這是這個人紀律問題，沒志力起床。自己遲到，會解釋是因為交通問題，昨天事情太多太晚睡。錨定效應(Anchoring)：
有參考點或第一次接受的訊息時，會過度偏重參考點。例如某地區最近賣出的房價是一坪100萬，則臨近的房子無論好壞，預售價格為一坪50萬時就會被認為"很便宜"，即便一坪50萬對絕大部分的受薪階級來說還是貴得要命。沈沒成本(Sunk Cost)：
過去已經付出去的，不管未來的選項如何，其成本都不會變。也就是說不同的選項無關過去的成本，只關係未來。例如當已經花錢買了張電影票，但是臨時聽說同一時間有某明星簽名活動。這時候有兩個選項，一個是繼續看電影，另一個是去參加喜歡的明星的簽名活動。無論是哪個選項，其該電影院票價成本都是存在，因為錢已經花下去。換言之，要考慮的只是，現在看這個電影是不是比得到喜歡明星的簽名重要，而不是考慮如果去參加簽名活動會損失電影票的錢。
過度自信(Over confidence)：
人類對於評估自己的能力時都會過度自信。例如，在一個50個人班級裡面，所有人自我評估考試成績的"名次平均"在技術上說應該是25，但是通常自評估的平均值都會遠小於25。也就是大部分的人都會高估自己的能力。羊群效應(Herding Effect)：
在團體中，個別成員會不自覺跟著團體中心行動。例如，股票市場中，市場最常發生一直買或者一直賣的情況。而如果是在競爭市場，有特別突出的公司時，其他公司會學習特別突出的公司的行動。專案執行面臨的問題 - 進度(時間進程 vs 距離進程)
在專案或者任務執行之中，技術領導者多少需要有效評估跟瞭解現況。而目前進度是最重要的"現況"。在比較嚴謹的專案管理領域裡面，有許多評量進展的指標，例如已投入成本和預計完成所需的成本比例(一般PMP常用方式)然而，在資訊科技領域中，比較適當的衡量應該還是以時間進度能準確反應事實。
所謂時間進度指的是，還有多少時間可以達到目的。舉例來說假設某人要去日本玩，從家裡到機場需要一小時，而飛行時間為兩小時，抵達機場之後到旅館需要一小時。因此當我們詢問他的進度時，當他的飛機抵達日本的當下，他會回報進度完成75%，尚有25%未完成。
然而，如果是距離進程，也就是以還有多少距離可抵達就有很大的不同。舉例來說，家裡到機場僅有50km，飛機實際飛行距離為1000km，機場到旅館假設有50km，所以當他的飛機抵達日本的當下，他會回報進度完成96%！只有2%未完成。
單以事實來看，這兩者都是事實，可是呈現於資訊科技控制進度與瞭解現況來說，恐怕是以時間進度比較能夠掌握。畢竟，當一個團隊成員說有件事情只剩5%完成，而且你知道他在這事情上做了3小時的時候，在沒特別問清楚的情況下，你大概直覺上認為只需要幾分鐘完成，而非剩下的5%距離，需要在1小時完成。
不過專案進程的事實搜集，有太多太多慘痛的例子是在混用時間進程和距離進程的估計。事實上，由於人類天生的偏誤，在距離很短的時候，會不自覺採用距離進程來回報狀態。這時候技術領導有意識的取得"時間事實"才最重要。
專案執行面臨的問題 - 技術問題
不過就軟體專案而言，有個兩個看似有些衝突的基本概念一定要知道：
(1) 每個人的技術能力與技術方面的產出差距可以達到10倍以上。而每個組織的能力與技術產出，也有近十倍以上的差距
(2) Scrum的方法論裡面，假定短時間每個人的績效不會成長，也不會改變
我們以後會再來討論這兩點。不過建議先對agile, scrum有初步研究。
(3) 專案的結束：好的結尾比好的開始更難
第三個重點，專案的結束。很多大公司，無疾而終的專案很多，軟體專案通常無論如何都還是會結束，只是結束的方式好不好而已。
礙於篇幅，我們在日後的文章再來討論專案的結束
礙於篇幅，我們在日後的文章再來討論專案的結束
沒有留言:
張貼留言