顯示具有 專案管理 標籤的文章。 顯示所有文章
顯示具有 專案管理 標籤的文章。 顯示所有文章

11/12/2016

Scrum - 專案壓力來自於無法掌握的命運



一個壓力實驗:

有兩個籠子(A,B),都連結同一個電極器,各有一隻老鼠。A籠子中,有一個燈號和按鈕,當燈號亮起時,如果在數秒內,A老鼠沒有按下按鈕,則就會產生高壓電極,讓A,B兩籠的老鼠都被電的很不舒服。不過,如果燈光亮了,在時間內A老鼠按下按鈕,則A,B兩籠就都沒事。B籠的老鼠則是全然被動的,只要A老鼠能做好他的工作,B老鼠就沒事。當然,經過幾次電極之後,A老鼠很快就學會了一旦看到燈亮,就應該儘速去按按鈕。

過一段時間之後,哪一隻老鼠的壓力大?

經過健康檢查,A老鼠幾乎看不到壓力大的特徵。而B老鼠,則出現各種癥狀:高血壓,胃潰瘍,成長障礙等等不一而足。

(以上內容取自:數位痴呆症:作者Manfred Spitzer)


軟體專案的壓力和該實驗有異曲同工之妙。真正的壓力來源不在於事情有多難,而是在於自己「全然」隨著命運擺佈,無法控制。以A老鼠的情況來說,他仍然是被關著,而還得三不五時瞄一下燈是不是有亮,一旦亮了就得趕快反應。

然而,「至少有一件事情」A老鼠可以控制:他可以決定自己要不要被電極。B老鼠則是沒有一件事情是自己可以決定。因而壓力無從擺脫。

Scrum(實況)是根據事實,固定的時間,以及有效團隊分工來達到敏捷開發的精神。而在此基本精神內,每一個角色都有「至少可以全然控制」的事情,不但可以正確減低無法掌握命運的壓力,更能組合出正確的團隊合作方式。


Product Owner(產品擁有者或產品經理)


在傳統的「瀑布開發模式」,或者,系統整合商SI的「隨意無止盡需求模式」中,產品經理會就所有應該要做的事情列一個驚人的功能清單,交由專案經理負責領導開發。接下來的18個月,產品經理就在B老鼠的壓力下度過,即便有檢查,也不知道產品真正的進度。而18個月後發現意外的機率...已經不是機率而是必然。

而過於認真擔憂的產品經理,更有可能在每一段時間,修改需求,讓開發團隊變成B老鼠,不確定哪個需求改變的命運降臨。

在Scrum中的產品擁有者(Product Owner)擁有非常簡單而清晰的責任,這個責任用非常簡單而清晰的方式減低他的壓力:「撰寫並排序需要完成的使用者情境」。

專案開始時,產品經理會撰寫數個使用者情境(user story)並且排定優先順序,而每個sprint開始時,團隊會告知這個sprint(4周)會完成到第幾個story。產品經理等候4周之後,檢查這些當初答應的story是否有如預期完成,並且在下個sprint開始時,或確定,或重新排列,或增加,或減少接下來要完成story的優先順序。

產品經理仍然不會去「做東西」。然而他確實全然掌握階段性完成,並且確定每sprint開頭都能選他最想要的事情先做完。因此,產品經理確實能掌握這個產品每一段時間的「樣貌」,而不是在最後關頭才求神拜佛,或者要求加班。甚至,在sprint的中間階段,若有必要,產品經理可以要求sprint停止,重新開始新sprint,用來調整後來才發現不正確的優先順序(priority)


Scrum Master (開發領導者)


過去一個團隊的技術領導者,帶領團隊解決技術困難並協調各類工作。他常常會是夾在產品經理(或客戶)以及開發成員中的角色。

在傳統模式下,他若非變成一個技術獨裁者,用以壓迫成員前進並反抗大幅需求改變,就是變成試圖面面俱到的好好先生,用以彌平不同角色的紛爭。「能良好溝通」這個字眼會常出現這個角色的工作描述(job description),但事實上,困難的專案,不會因為一個很能講話的專案經理,就變得簡單。最後最常出現的結果是:專案經理總是能有效呈現「自己的貢獻和功能」,但無法反應在專案成功。換言之,常常看到自己從來不失敗的專案經理,曾經領導了很多壓根不成功的專案。

Scrum Master並非傳統的專案經理,其責任和角色也有很大的不同。而他能有效掌握的事情,也能讓他減少原本專案經理的壓力。

Scrum Master 掌握「會議」。他可以確保每日會議只「說明三件事」:完成了哪些事情,接下來要做什麼,有遇到什麼困難。確保每個sprint開始的會議,領導團隊能完成哪些使用者情境(user story),並且確定這幾個要完成的事情,產品經理都有完整而合理的描述。他雖然沒有掌握全部18個月會完成的事情,但是透過掌握每一個sprint,腳踏實地的一個一個完成優先要完成的事項。

Scrum Master 掌握「真實進度」。透過領導決議「和未完成」以及以事實展現的燃盡圖,Scrum Master掌握過去真實進度。因而可以有效推測未來進度,並有足夠的證據顯示給產品擁有者。因此,才能有足夠的「動作權力」成為A老鼠:仍然在籠中,但掌握部分真實權力,以減少壓力。


Member (團隊成員)


傳統模式下,團隊成員經常是壓力末端。所有的壓力最後承受的出口。所有過勞死最可能發生的地方。傳統上最常出現的是:「某功能我們在要X月X日之前出來!」「現在馬上改做XX不然沒辦法驗收」。

而傳統的產品經理和專案經理 - 無論是軟性還是強硬 - 通常不得已的把壓力直接轉嫁給團隊成員。

但是,在Scrum中團隊成員,決定使用者情境:「真正完成的所需要的時間」。而這個權力,僅代表一個事實:由做事情的人傳達做事情的時間與結果。成員不再在決定什麼事情先做後做,只要決定現在在做的事情,什麼時候可以完成,以及「真的去做他」。換言之,Scrum團隊真正的A老鼠,其實只有團隊成員,只有他才會真正的按下按鈕。然而,如果Scrum團隊不能掌握分工負責的精神,團隊成員很快就變成B老鼠:不是被無謂的壓力掌握自己的命運,就是試圖跳脫牢籠。






10/20/2016

Scrum - 務實的彈性,千萬不要削足適履




夫所以養而害所養,譬猶削足而適履,殺頭而便冠 ......除小害而致大賊,欲小快而害大利

--- 淮南子說林訓


雖然說Scrum的方式與工具十分簡單,能務實並且彈性運用比照著字面嚴守方式來的重要。不過「務實彈性」和「削足適履」有時候只有一線之隔。


形式主義的削足適履


某些形式主義分子在執行Scrum上,會嚴守大部份framework的要求:每日站立會議,燃盡圖更新,user story和PM確認...等等。達成基本要素,似乎就是必要的事。

但是實際檢視其內容,偶爾會有怪異之處,而這些怪異之處,總是自然生出個理由:「因為我們team比較不一樣,所以有不同作法」。但其實以軟體開發來說,每個team統統都不一樣,而是否能有不同的做法,乃是看有沒有掌握agile的精神而定,而非把不一樣當作理由。

常見的怪異之處有:

* 每日會議除了堅持站著開之外,其他完全不堅持,會議中仍然會試著討論專案問題與技術解答。

* 在幾個sprint之後,仍然無法得知專案團隊的速度,因此仍然常有在sprint快結束時強迫加班的情況

* Scrum Master或者team leader會指定工作項目的完成時間

* 出現一些時間長達3天以上的工作項目,但卻又無法更細分階段或者細項。

* 在sprint結束的檢討會議(Retrospective Meeting)似乎都是在檢討別的單位的合作問題。


這些怪異的狀況都是削足適履的表徵。Scrum的精神在於實況並務實,因為「要Scrum」而做出怪異的行為,還不如乾脆不要使用Scrum作為開發方法論。



務實彈性的例子:以功能為sprint


sprint的基本精神在於每個sprint之後,都會產生可「交付」的結果。一般情況而言,專案的每個sprint時間長度是固定的,以符合Scrum的time-boxed精神。

但如果一個軟體產品已經是5.0版,功能趨於穩定,未來的挑戰,其實在於更快速正確的回應市場變化,則其實可以將time-boxed改為feature-boxed。




上圖取自:http://comsysto.files.wordpress.com/2010/06/scrum_cycle.png

簡單的說,每個sprint的開始,由產品擁有者(PO或PM)選定一個「最最最高優先」的user story。只能有一個,不多也不少。接下來的流程,和一般的Scrum相同,break down開發細項之後,由專案成員評估時間。

略有不同的地方在於,評估確切完成時間之後,就是這個sprint需要的時間。因此,可能是2週,也可能是4週8週。完成的定義當然是變成「可以交付的產品」。因此可能是5.0.1版。

假設sprint plan會議完成,決定是5週,之後就和一般Scrum一樣,在5週之後準時交付產品給產品擁有者。而產品擁有者應該會「立刻」將產品放到市場,看看這個「最最最高優先」項目有沒有達到預期的市場反應。下一個Sprint當然也是選擇一個「最最最高優先項目」,可能會花2週,也可能會耗時8週。

對於已經成熟軟體產品,這樣調整的最大好處是,快速取得市場反應,而非等9-12個月之後產生一個6.0的大改版。

產品擁有者(或者PM)自然會對自已的判斷有完整的責任歸屬,畢竟,如果幾個sprint都交付了產品經理認定的最最最高優先項目,而是市場反應卻不怎麼好,那麼產品擁有者當然要負起責任,花更多的精神來瞭解市場,並且將市場需求轉化為適當的user story。


每一種務實的調整,都有其優點和缺點。

「以功能為sprint」的例子中,最大的缺點在於,稍微控制不當,就會變成傳統瀑布開發模型。而時間估算稍有不當,就會容易延長專案難以收拾。因此每一次務實的彈性調整,都應該在sprint之後的檢討會議上,確實檢討改善。


參考:Scrum的缺點




10/10/2016

軟體專案的現實:解決人的問題




無論是否採用agile的開發方式,所有軟體專案,最大問題的來源都是人。

人的問題,通常會極現實的影響專案的進行。然而,妥善運用agile的精神和Scrum的方法,有機會讓人的問題降到某個程度。

某個朋友,姑且稱為K,在專案扮演專案經理的角色,遇到以下狀況:

我最近有遇到一個問題,不知道怎麼辦,下面的人一直做不到我的要求,或者動作很慢,即便壓日期給他,他還是沒辦法達到,但實際上它任務並不多,只是開test case,我不太知道怎樣push他,我又不想來硬...他只有這個任務 平常又常常看他在上facebook, line....覺得要當一個讓人喜歡的lead真的蠻難的....


這個問題非常典型。

以敏捷開發(agile)來說,解決方式似乎也很簡單。首先專注於優先項目,接下來根據事實檢視工作,最後才考慮能力問題。


一:專注於優先項目


每個人在Sprint之中一定有正在執行的項目。確保每個人都是「專注」於目前最優先的項目是Scrum master最基本的任務。

即便不是採用Scrum也一樣。團隊成員必然在某個時間點有一個特定任務。專案經理或領導者(leader)當然必須確保,在這個時間點他只會專注在這個工作任務上。

對於剛剛成立的團隊來說,要確保團隊成員專注於目前任務上的方式很簡單:就是腳踏實地的「問」。在該成員一來辦公室的時候,就坐到他座位旁,親切的詢問他昨天早上在做哪些事情,昨天下午在做哪些,並實際上「看」到做的結果。就可以確定他是否專注,而能確定是否做到真正的效果。

整個詢問的重點都是在了解事實,而不是監督細節。因此每天頂多也只針對「需要幫忙的成員」,一起坐著看實際上的狀況。


二:工作檢視

以Scrum而言,每天的會議(無論是不是站著)就是為了統一工作情況檢視。完成就是完成,沒有完成即便是已經達到99%也一樣是沒有完成。當然,前提是在Scrum開始時有定義「什麼叫做完成」 - Definition of Done。

如果不是採用Scrum,則應該盡可能在團隊開始時,就先定義何謂「完成」。

以開test case為例,完成是指把要做的功能的test case詳述在某個測試文件管理系統上?還是只要先用excel或者wiki列出來即可?test case完成後是否要先讓團隊成員審閱,看看有沒有問題?要不要先估計每個test case執行會花的時間?test case的前置作業 - 例如建立測試資料等等,是不是也要涵蓋在其中?

當有完整的工作完成定義之後,要讓負責進行工作的人「決定時間」,而非「被決定時間」。

以軟體專案而言,任何超過2天的工作項目(task),都應該分階段完成。畢竟,就事實而言,一個人不可能「連續工作2天」,每天一定會停住工作,下班回家。而這些階段應該要有階段產出。以test case而言,假設有10個新的user story需要建立test case,則今天完成了4個,表示還有60%尚未完成。


三:能力分配

如果團隊成員的確很專注於工作,而且也對時間/產出有正確的體認。最後的問題就是「能力問題」

團隊成員的能力組成其實非常複雜而且麻煩,牽涉範圍廣。以軟體專案而言,能力並非只是撰寫程式,測試程式,理解規格等等。能否和其他人合作,也是能力的一環。

一個規模中等的軟體開發團隊(4-7人),如果有一個人的能力「極端」的差,確實會造成專案很大的問題。

在Scrum的情況下,這樣的問題在前兩三個Sprint應該就可以被控制。因為雖然他的產出差很多,但未來的sprint的進度,是以團隊能力來考量,因此Scrum master仍然可以有效掌握專案產出和進度。

在不是Scrum的情況下,可以先找到該成員的相對優勢。排定一些學習項目,來提昇該成員在這個專案中的相對優勢,並且在未來安排相對優勢的工作。值得一提的是,根據經濟學的「比較利益法則」,每個人一定會有所謂相對優勢:請參考這裡,和這裡

關於軟體開發團隊的個別能力,還需要注意以下幾點:


1. 每個人都會成長,但是....


每個人都會成長學習新知識和能力。但是!在中短期專案裡,必須先考慮個別能力與優勢。

換言之,團隊領導要像下象棋一樣,找到每個人的「專長」,能妥善組合專案,就是個好的領導者。

而差強人意的領導者,則是常常試圖規避個別成員的「缺點」,這樣比較不會出大問題,但也容易產生差強人意的結果。而最糟糕的領導者,則會把人當做圍棋,看到人非黑即白,見到專案漏洞時,看到有空閒的人就直接填塞。這在某些有數百個人的硬體專案或許可行(因為數量在此可以產生品質),但在軟體開發專案鐵定行不通。


2. 能力是綜合考量...


能力必須綜合考量「全方面」:例如是否好溝通,是否能處理複雜的設計問題,能否開放心胸的就事論事等等。不能僅僅考慮寫程式的能力。

另外,如果覺得整個開發團隊能力都很差。作為一個能自我思考的領導者,應該先思考自己是不是「問題的來源」,甚至要思考自己是不是根本不適合作為團隊領導。


3. 讓不適任的成員離開...


讓不適任的成員離開,某些時候是個可行的解決方案。特別是某些企業管理派別認為,投入時間在不適任的人身上,他有可能變得適任,也有可能不會改變,然而投入時間太多,會造成專案延誤。

以Scrum的角度來說,這個情況不太會發生,因為2-3個sprint之後團隊速度已經確立,無論適不適任,專案產出速度不太會再改變。因此剩下的問題僅在於「換個人會不會更好」。而以中短期(3-6個月)的軟體專案而言,讓破壞性的不適任者離開,當然是解決方式,但不見得要「找另一個人進來」。






相關文章:人才管理心智圖為自己工作...



8/14/2016

Scrum (實況) - 瞭解事實才能領導專案






近年來在符合Agile精神的各種專案方法論中,Scrum應該是最簡單,也是最熱門的。

雖然簡單,但要掌握其精神,必須對抗長久的習慣,而這並不容易。

目前市面上也衍生各式各樣Scrum架構的作法和細節,從一開始的User Story到sprint最後的檢討會議(retrospective)都有琳琅滿目的作法與工具。假如只能選一個最重要的精神,則「實況:瞭解事實」是最最最根本的Scrum精神。(註1)

Scrum架構中,理解事實有很多層面。在此以「角色」「衡量效率」「固定時間」作為範例。



1. 角色


實況(Scrum)只會有三種角色

1. 產品擁有人(Product Owner)
2. 團隊領導 (Scrum Master)
3. 團隊成員 (Scrum Team)

而最根本的Scrum務實精神,在角色所扮演的任務中展露無疑。

也就是:

(A) 只有產品擁有者,才能排定產品功能的開發順序(product backlog)!

(B) 只有團隊成員,才會決定每一段時間,哪些功能會完成!

換言之,什麼事情先做後做,交由最接近市場的人 - 也就是產品擁有人 - 來決定。但是那些事情要花多少時間,是由做事情的人 - 也就是團隊成員 - 來決定!這個作法完全奠基於事實,並且適用於絕大部分的情況。

這和傳統專案有很大的不同。許多專案的時間預估,都不是做這件事情的人來預估。自然就一定不可能預估的準確。

不過,在許多「精采的成功個案」中似乎常常會有一個超強的產品經理,能主導市場,產品進度,甚至使得專案團隊有突破性的創新結果:典型的個案就是第一代iphone直接由賈伯斯(Jobs)作為產品經理帶領開發。似乎就是產品擁有者,主導進度的鐵證?

然而,事實上絕大部分的產品經理都不是賈伯斯。可是,大部分的企業,卻可以雇用到接近賈伯斯擁有的研發團隊品質!!因此,絕大部分的情況下,將產品研發功能相關執行與時間預估,交由團隊成員,才比較可能產出和市場預期的結果。除非該產品經理很確信自己跟賈伯斯差不多,並且也能提出「具體證明」。(就如同大部分的資深程式設計師,都能提出具體的證明 - 程式碼,佐證他的經歷一樣)



2. 以結果來衡量團隊效率


在實況(Scrum)中,一個項目完成的定義就是「完成」。而團隊的速度,取決於每個sprint可以完成多少項目。當然團隊一開始的完成事項的速度,大概很難和自己預估的一樣。

然而,過了兩三個Sprint之後,團隊速度應該已經「固定」,而這個完成工作的速度,就變成「事實」。

要看研發團隊速度在這時候很簡單,打開燃盡圖(burndown chart),算一下每段時間 - 例如每週或月 - 可以完成多少單位,自此之後,要估計時間,只要能有效估計每個功能(user story)規模大概多少單位即可。

這個事實,原則上不會改變。然而,產品擁有者確有權限可以在必要的時候改變事實。他有兩種選擇:(a) 更換產品功能。(b) 改變團隊。

更換產品功能可能是縮小功能規模。例如原本app支援facebook, linkedin, google+的帳號登入,考慮市場都在台灣,因此就先做facebook登入即可。

當然產品擁有者也可以改變團隊,重新組織團隊,更換成員。但一旦改變團隊,就必須重新啟動新的sprint,而也會重新產生新的速度。



3. 以取得事實來固定會議時間


Scrum(實況)的會議,必然鎖定會議「目的」以及「時間」。在事實的基礎下,兩者有很大的關聯。

以每日會議為例-- 不管是不是站著開會,一定是一天工作的開始,最多只花15分鐘。成員輪流以1-2分鐘「說明」三件事:

(a) 從上次開會到現在完成了什麼,沒有完成就說沒有 
(b) 今天打算做什麼,而且有什麼會完成 
(c) 遇到什麼困難需要ScrumMaster協助。

這三件事情,只是說明,若有問題,也是對說明的問題,絕不應該討論。要討論是開會之後,相關人等,聚集在適當的地方,最好是某個人的電腦前面,開始幫忙解決。

通常最容易花時間就是遇到困難的時候,大家紛紛都想提議見幫忙,但這並不是「這個會議的目的」。每天5-7人聚在一起,是為了將大家對狀況的認知統一,僅此而已。因為一旦開始討論困難,很有可能變成A和B熱烈的討論起來,其他5個人在滑手機發呆。Scrum Master要根據決定好的目的和時間,具體果斷的打斷討論,讓會議前進。

或許有些人會認為,這樣會破壞創造性思考和創意思維。然而,事實上無止盡的會議才是破壞創造性思考和創意的元兇。在每日會議之後,Scrum Master可以根據遇到困難的情況,重新找適當的人,並且到適當的地點 -- 也就是電腦前面,手腦並用的解決問題,而非在會議室空談。

其他在實況(Scrum)框架中的會議,像是Sprint啟動會議,Sprint結束會議,Sprint檢討回顧會議等等也都是一樣。必然是在特定的目的,特定的時間完成。


將能專注控制的事情完成,才能把時間與思維,留給創意。





註1. 因此,敏捷開發中的Scrum方法,中文翻譯應該叫做「實況」,至少也比google翻譯為「爭球」來的好。

註2. Scrum的學習可以參考這裡-> 學習Scrum,或者->Scrum認證

8/06/2016

Scrum 認證!? 不要再浪費你的錢了!


管理類型的證照無用論,早在軟體工程界提倡Agile Movement的時候就逐漸存在。

以目前看起來取得成本最高的PMP在資訊科技的評價為例:比較客氣的說法像是這篇:雇用有PMP的專案經理需要更進一步了解其能力。而比較不客氣的說法會像是幾篇:PMP毀了專案管理,或者PMP證照無用。(註1)

而這幾年Scrum的方法論,因確切執行之後確實對軟體產品開發有顯著效益。隨之就有各類型推廣,教育,甚至認證產生。

然而,花大錢考Scrum真的有意義嗎?


(1) 認證市場


技術專業認證,絕對有其必要性,例如:醫生執照,律師執照,CCNA,SCJP,TOEIC,甚至,職業大貨車駕照,乙級中廚檢定...等等。擁有此技術執照,表示你至少「會」做某些事。

然而,非技術執照,只證實「考過」某些考試,一旦考試內容和實際會到的問題有差距,該執照就沒有太大意義。只能代表你對某些考試的努力成果。專案管理,企業經營方面的執照就屬於這類。這類型執照如果成本不是太高,倒也無妨。高收費的認證?等於是浪費錢。

一旦有高收費的認證,自然就會有認證教育訓練市場。教育訓練本身是好事情,可以讓人學習成長,但是,教育訓練本身如果是應付考試,意義就降的很低。


(2) Scrum高收費認證為何沒用?


迄今,Scrum認證有很多種類,單就Scrum Master而言,網路上隨便找,都可以找到以下七種,請參見下表。


證照名稱考取成本 (以台幣計算)組織
Certified Scrum Master$30,000 (含16小時訓練課程)Scrum Alliance 
 Professional Scrum Master I 
 Professional Scrum Master II
$4,500

$7,500 
Scrum.Org
Expert Scrum Master$3,000EuropeanScrum
Certified Scrum Master$3,800 (不含訓練課程)
$4,500 (含8小時訓練課程)
GAQM
Scrum Master Certification$13,500ScrumStudy
Agile Scrum Master$5,880EXIN
Scrum Master Accredited Certification$900Scrum-Institute


筆者考過並取得最貴的認證以及最便宜的認證。其價格差距很大(三萬台幣 vs 九百台幣)。單就「考試內容」而言,最便宜的考試內容甚至還稍微難一點點。而最貴的CSM (ScrumAlliance)其實也就是台灣各教育機構最努力推廣的認證。

就考取認證作為職場價值這點來說:

1. 如果是沒有任何軟體專案經驗者,透過高收費教育訓練考取最貴的收費認證,基本上,和只自學而通過最便宜的認證,在Scrum基礎知識上根本沒差別。而在Scrum實務運作上,也沒差別:都屬於完全沒經驗。


2. 如果是有數年軟體專案經驗者,「有無證照」對於專案管理來說,只是履歷表上的一撇,一旦遇到真正的艱難問題:在Scrum上採取正確作法的經驗和收獲,遠比考證照的收穫大得多。因此,昂貴證照和便宜證照也無任何差異。

3. 沒有駕照,就不能合法開車。但沒有Scrum證照,在務實的企業中,只要你有足夠實務經驗,足夠證明支持你的能力,根本沒有問題。反之,如果有Scrum證照,但無法足以匹配的經驗,能力,而再加上創意不足,那麼甚至是有害無用。



(3) 建議作法


如果有想考Scrum相關證照,有三個強烈的建議:1.「自我學習Scrum」2.「確切運用Scrum」3.「考最便宜的」

1. 自我學習Scrum:

學無止盡,無論是Scrum還是其他未來可以出現的方法論,都值得一學。但更重要的是,如何自己學習。任何教育訓練都很有用,但也不可能完全取代自我學習。

自我學習的方式可參考這裡:如何學習Scrum 。以及這裡:如何成為Scrum專家,或者:scrum的缺點,或者 :Scrum三件必要的事

2. 確切運用Scrum觀念與作法在軟體專案中:

任何專案管理上的知識技能,如果不能有效運用在專案管理上,當然就沒有意義。以Scrum的每日會議(無論是不是站著開會)來說,其基本觀念在於:

「限時」 - 15分鐘
「事實」 - 只描述做完的項目,和下次打算做完的項目。(註2)
「困難」 - 只說明困難,不是要在每日會議上解決困難。

也許現實會讓Scrum Master或專案經理有所調整,但如果調整的方式不能切中Scrum觀念,則取得昂貴Scrum證照也沒有任何意義。(例如每日會議花超過40分鐘,肯定不符合任何一種Agile專案方式)

3. 以實力考最便宜的證照:

不可否認,還是有不少人認為一旦履歷表上有幾個証照,似乎會多一點點面試機會。另外,也有些有專案管理經驗者,自我學習Scrum想要有個目標來證實自己。

以這樣的立場,其實考取最便宜的證照即可。而最好是在沒有任何準備的情況下,抱著隨便考的心態。如果這樣考過了,表示Scrum的基本知識已經深入腦海中,考不過其投入成本也不高。

剛出社會的新鮮人,如果覺得萬一在面試時,有人對便宜的證照有疑慮?你可以客氣的敦請他去考考看,了解一下其考試的品質。





註1: 我們不是反對PMP。事實上,在其他工程領域PMP有其必要性。例如:cern的LHC是一個橫跨數十個國家,涵蓋土木,電機,資訊的龐大工程,PMP條列的九大項目,五十多種可能的文件在此就有點必要性。本文反對的是,以PMP(或其他管理證照)來判斷一個專案經理有沒有能力執行資訊軟體相關專案

註2: 何謂做完?(definition of done)也是Scrum team需要在專案開始前定義好的。

註3: coursera.org 提供各種課程修業完成認證,目前沒有ScrumMaster,但是有類似Agile Management的課程,上課是免費,不過,取得認證約為3000~5000台幣之間。

7/28/2016

心智圖 - 進入職場第一個必備技能



在畢業之後,投入職場的那一瞬間,假如你突然失去記憶,喪失所有技術能力,你最希望先恢復什麼能力呢?

相信一定是「學習各種技能的能力」「連結不同技能的能力」「延伸整合技能的能力」這類型的選項。概念上類似神燈可以實現一個心願,稍微有智慧的人,第一個願望,一定是希望有無限多的心願。

「心智圖」mindmap是最簡單,最容易學習的能力,可以用來連結學習延伸其他的技能的基礎。它應該是踏入職場第一個必備的技能。

心智圖極端簡單(請參見心智圖wiki),不過就是把心中想的主題畫在一張紙的中間,把跟這個主題相關的重要「事情」「項目」「動作」...等等,用線連在一起,而後還可以再延伸這些「事情」「項目」「動作」到其他細節,或者其他主題。

雖然心智圖很簡單,有不少人宣稱在高中就已經會用,但實際上熟練地使用者卻很少。

下面這張圖就是在撰寫這篇blog的後所畫的第一張心智圖:

這篇文章所用的第一個心智圖

心智圖的繪製,沒有任何特殊技巧可言,它只是想法的延伸。換言之,心智圖本身無法代替思考。但他可以讓抽象思考具體化,讓你更容易有全面的視野來觀察任何主題。這和哈利波特裡面的儲思盆有異曲同工之妙。只是你不需要去念霍格華茲,也可以學會使用心智圖。

經常利用心智圖,對職涯發展有莫大助益。然而,在台灣職場上,卻並不常看到有人使用心智圖,更常遇到某些特殊事情發生之後,才想到「當時如果用心智圖做紀錄會不會好一點」的情況。

其中一個主要因素是:缺乏練習,以至於當下沒「聯想」到有此工具。


有三個工作項目,是最好練習心智圖的機會:


1.  即時會議記錄:


即便有超強的打字能力,有意義,並能快速呈現重點的會議記錄,遠比把所有人講的的話一字不漏的記下來來得重要。臨時的會議,有結論的會議更是如此。

一邊開會,一邊將主題相關的人事物,用心智圖快速連結起來,可以在開會的過程中,掌握要點,避免會議「歪掉」,減少會議常見的三大毒瘤:「會而不議,議而不決,決而不做」


會議還沒開始,先畫出主題以及會議之後的行動
做法很簡單。首先:如果你是主持會議的人,會議還沒開始前,先在白板中間畫個圓圈,中間寫會議的目的。接下來先把「Actions」先畫出來。在會議一開始,就確保會議結束前,一定會討論出作法。如果你不是會議主持人,可以畫在筆記本上,這樣確保會議結束前,萬一Actions的圖形之下,沒有任何行動,也沒有人提及要有會後行動,你也會「主動提出」。

接下來,在與會人士慢慢來到之前,先把會議的背景,要討論的事情大綱,畫在主題的周遭,並稍加分類。以簡單的圖像表示與會人士。


會議即將開始前,先將背景以及可能討問的事項在白板列出來。以簡單的圖像代表與會者的討論。

隨著會議的進行,白板會越趨複雜,當然可以簡單的照相紀錄過。

會議的目的,當然是為了「議」- 也就是為了討論。而討論最佳的方式,莫過於把彼此的思維,投射到可以視覺化的地方。心智圖是最簡單,成本最低的好方式。





2.  分析與設計:


有複雜問題的時,可用以分析。例如:專案資源不足,遇到瓶頸,解釋複雜的人際關係等等。

有需要進行的事情時,可用以分析。撰寫技術類型的文章,就很適合先使用心智圖。

以這篇文章為例,在撰寫之前先以心智圖繪製草稿大綱,然後經過一些考量修正,先修改心智圖大綱到自己滿意的程度,在開始撰寫內文。
這篇文章的最終心智圖草稿,和第一張圖有些不同

各類流程,事物的互動,也是很適合使用心智圖分析。以旅遊為例,如果你沒有精美的行程設計,使用簡單的線上心智圖工具來繪製旅遊計畫,是方便又好用的方式。
以線上工具繪製的東京旅遊計畫




3.  任何超過3分鐘的技術問題討論:


程式設計師,專業白領階級員工常常會有「技術討論」。而技術討論光用嘴巴講效果很差。一圖勝千言,簡單的流程圖,循序圖,物件圖,永遠勝過長篇大論。

UML需要比較長的學習與練習,而心智圖卻很簡單。特別是用於觀念討論,大方向的設計(註1),



app使用者登入討論大綱
以mobile APP為例,在討論技術上,也許有程式設計師,在討論之前,先花上幾天搞個極為細緻的流程圖(例如這個),但很多時候只需要只需要三分鐘,在白板畫個圖就搞定。以右圖而言,顯示這個APP在使用這登入的討論大綱


簡單的東西,通常可以運作得更優雅良久。心智圖並非萬能,它僅只是簡單。掌握心智圖的簡潔,快速,利用它來簡化,分析,記錄事務絕對可以讓職涯事倍功半。





註1: 資訊科技比較完整的分析圖形工具還是以UML比較適合

7/18/2016

解決軟體專案困境的最爛方式 - 加班





「加班」是解決軟體開發專案困難的常見方式,但也是最爛的方式。(好方法?請參考:解決專案困境的三個方式)

負責控管專案進度的主管或專案經理,如果只會用「加班」這招來解決問題,那就不適合做軟體專案經理。

長期,非自願的(註1)加班沒辦法真正解決問題的各種經驗實證,早在許多談論軟體專案的書籍中存在。例如:人月神話Peopleware約耳談軟體與熊共舞等等。從來沒有看過有任何「專案管理理論或實務認為加班有用」。

最根本的原因在於:知識工作者(軟體工程師),其產出和付出的「超額」時間根本沒有關係,也因此,加班從來都不會解決真正的問題。

既然如此,為什麼加班文化仍然存在?

常見原因有:

1.  短期效應


特定目的的短期加班:例如參加週末創業活動,或者,產品銷售大會之前的熬夜修正demo問題等等。這些特定的目的,固定時間的活動,確實會讓人拼了命「加班」完成目的。但是,短期效應絕對不能當作一般專案管理的方式,大部份的專案都不是百米賽跑!


2.  專案經理本職學能不足,利用要求加班來展示苦勞。


專案經理沒有其他辦法,只會加總人時。因此,即便人月神話從初版印刷上市(1975)到今天已經超過40年!仍然有不少軟體專案經理即便看過人月神話這本書,仍然不可自免得繼續要求加班。因為,如果有加班,即便專案失敗,以往也被認為「沒有功勞也有苦勞」。

但是,以現在環境變化迅速,一個軟體企業中,如果「一直都只有苦勞」,被淘汰的速度遠比過去還要快得多。



3.  模糊的合約。


在某些糟糕的情況下,銷售可能會簽下模糊的合約,當專案經理看到合約內容時,其解讀方式和客戶「截然不同」。在各種專案經理訓練課程,以及各類商管叢書裡,都會說「要良好溝通」,但實務上,當專案經理手上已經拿到不合理,而且驗收條件極為模糊的合約時,幾乎不可能以「溝通」來解決。如果專案經理,誤接燙手山竽,而又沒有足夠的創新能力和技術能力來解決時,通常會誤以為軟硬兼施的「加班」,或許可解決這個問題。

但是,如果這次不能非加班的方式解決,下次就不可能有更好的方式。其後就落入惡性循環。可以google一下「台灣  接案公司」看看目前的現實情況。


4. 心靈激勵。

無論是「要有創業家的精神!」,或者是「我們在做全世界最偉大的軟體」,甚至是「世界的和平,人類的未來就靠我們了」。而又有太多人誤以為,只要有正確的心靈激勵,軟體工程師就可以像電影劇情,日夜匪懈的工作,還能有創造性的思考解決問題。


5. ...很多其他的理由。


如果你是專案管理人員,之前要求成員加班的理由到底是什麼?如果你是軟體開發人員?曾經被哪些理由要求加班? 




既然如此,到底什麼是解決軟體專案困難的好方式?
除了可以參考這裡之外,還有三個原則:


1. 永遠都有選擇 - 「Say No」也是一個選項!


認為不正確的事情就應該說「不」。在正確的時間點不說,只會拖延,就不是個好的專案領導者。


以組織層面的角度:

就專案經理本職學能而言,一旦發現自己不是個好的專案領導者,應該要對自己說不,迅速辭職,改當一個好的程式設計師,或許是對專案最好的幫助。

就專案目標而言,倘若使用這的需求不確定,就應該選擇不做,或者選擇先做mockup,讓使用者確定需求,才不會浪費時間。

資源 - 特別是人力而言 - 在企業組織中,永遠都是有限。而良好的管理是透徹於在有限的資源中做有效的分配。加班不會讓分配變得有效,只會讓無效的分配繼續無效。

以技術層面的角度:

技術永遠有選項。一個複雜的功能,可能有起碼5種不同的實作方式,到底是選擇複雜但是有趣,還是選擇簡單,但是堅固耐用?就要視情況而定。

無論什麼事情,一定有選擇,絕對不會有「我們只能加班」這個選項。



2. 專案擁有人,必須參與專案!


近年來流行的Scrum,有一個必要的要點:專案擁有者(product owner)在每一個sprint之後要檢視產出。這個要點非常的重要,遠比正確做好燃盡圖,每天站著開會來得重要100倍。

專案擁有人,需要參與專案的每一階段進展,確實了解專案的人把時間用在哪裡,並且確實了解,每一個sprint產出都是專案擁有人最想要的產出。如此才能確保「做出對的事情」。

如何讓專案擁有者參與專案,就變成專案管理者「一定要做」的事情。

會把PMP的教材背的滾瓜爛熟 -- 溝通管理計畫書是要建立蒐集擷取散布各處的資訊,以及最終處置專案資訊的流程 -- 但實際讓連每一小階段讓專案擁有者「確定產出是他要的」都無法實際做到,簡直沒有任何意義。

在每個階段發個制式的email,裡面塞了很多複雜的圖表資訊,只會讓專案管理者「誤以為」一切都很順利。把確認每階段產出是他要的這件事情越往後延,風險就越大!


3. 磨利斧頭!


技術上的學習,會讓事情事半功倍。太陽底下沒有新鮮事,你所遇到的困難,可能已經有另外17個人遇過同樣的困難,而其中也許有9個人已經解決,解決的人之中有5個把相關資訊放在網路上。只要有正確的英文閱讀和google查詢能力,並能固定的自我學習,充實自己(參考如何充實自己),通常都能以更好更快更有效率的方式,解決軟體上的問題。

但是,千萬不要把「沒有時間學習」當作理由。當你的斧頭已經鈍到無法砍樹,還試圖用鈍斧頭砍樹來表現自己的努力,這是完全沒有意義。學習的目的就是磨利自己,將知識與技能銳化,才不會以無意義的舉動,做無意義的事情,加無意義的班。






註1: 凡事皆有例外,遇到天災人禍等不可抗力情況而加班其實算合理,不過即便如此,也應是極短的時間。例如,颱風天放假,隔天需要額外的工作時間。自願性質也絕對不會是長期,例如自己去參加創業週末,某種程度是自己為了自己額外工作,但頂多是一個週末,也不可能連續10個週末都在進行這樣的活動。

相關文章:
-->  換工作的面試-軟體工程師如何展現價值
-->  靠感覺做專案管理 - 鐵定失敗
-->  如何提高工作效率:三個務實的快速步驟
-->  心智圖:職場的第一個技能
-->  你確定知道專案進度嗎?
-->  80/20法則之軟體專案的三個運用重點


7/02/2016

如何學習Scrum


如何學習Scrum?

端看學習Scrum的真正目的,有三種方式可供參考:(1) 網路資源 (2) 收費課程 (3) 實際經驗


(1) 網路資源


很簡單,費用幾乎為零。

下載這兩個pdf,接下來,先不要上網查專有名詞,也暫先不要查字典,好好的先花時間看完。

* Scrum-institute 的 training pdf
* m-plaza 的 Scrum Guide pdf

然後,隨意上網找一些相關資料閱讀佐證即可。也可以自己做個類似這樣的簡單學習計畫

不確定自己有沒有學會?可以考慮花29美金考一下證照看看,請參考Scrum證照這篇

假如是剛畢業的大學碩士學生,英文閱讀沒有太大障礙的話,大概8-16小時應該可以完成。


(2) 收費課程 <- 不推薦


也很簡單,但是要花錢,大概7,000~20,000不等。


在google搜尋[scrum 認證課程],出現起碼5個不同的教育機構,其價格從7,000到20,000台幣不等,時間通常大約是2整天左右。衡量自己的時間和財務狀況,挑選離家近的參加即可。

這類型的收費課程通常會協助考取證照。在此並不推薦這個方式考取非技術專業之證照。

(3) 實際經驗


非常難!要花的成本看起來很高,不過他通常伴隨工作經驗的成長。

(a)基本作法:


首先必須要先參與開發團隊一陣子,在此期間必須要先用方法(1) 網路資源。用以了解Scrum的基本精神。

然後,只要運氣不要太差,加上自己的努力,有朝一日會變成專案經理,或者是團隊領導者的角色。接下來,由於自己已經擔任領導者角色,就在自己領導的團隊中,以務實的方式執行Scrum。其中一定會遇到阻礙,每當你碾平一個障礙,就更多一層對務實的認識。

基本作法其實也是最佳作法,如果是一個已經有足夠技術背景的人,而有意識的朝這個方向前進,在台灣大概3-5年就可以有很好的成果。


(b) 突破性作法:

和所有專案管理技能一樣,當不能付諸現實的時候,技能的本身就沒有意義。就像籃球教練沒有籃球隊可以教,沒有籃球比賽可以參與的時候,籃球教練等於沒有付諸實踐的意義。

要有突破性作法的原因在於:

* 企業組織長久以來沒有真正agile的精神
* 在創新小公司任職,架構混亂,以完成事情為優先
* 自己並不是團隊領導,但希望能改變團隊
* 剛畢業,沒有領導管理經驗
* ...


然而,在這些外在因素不利的情況下,如何有Scrum實際經驗?(突破性方式的概念可參考這篇。)

簡要的說,自己起頭一個專案,無論是跨界虛擬專案,還是開源(open source)專案,還是到便宜的外包市場找南亞工程師加入的專案。當自己開啟專案時,自然就可以確定,如果要採行Scrum,不可能會有其他外界因素,所有成功與否的因素都在於自己。當然也是靠自己來碾平困難。

一旦個人的能力提昇,自然就越能貢獻現在的團隊,現在的組織,更容易體會團隊合作的可貴。






6/12/2016

靠感覺做專案管理 - 鐵定失敗



真實故事:


有近70個工程師參與的軟體專案的組長會議中,除了專案經理之外,另有8個負責領導開發不同模組的組長一同與會。

例行的報告進度後,專案經理看了一下大家,帶著遲疑的臉說:「在兩三個禮拜大家的模組就都完成了,如果沒有問題的話,應該整個系統同時也都弄好了吧?」

負責UI以及整合模組的組長,看著大家漠然不語,也只能硬著頭皮的說:「現在最大的風險在於:如果所有模組都在最後實現完成,那根本不會有人知道組合起來會發生什麼事,所以我只好老實的建議,要不就額外增加整合測試的時間,要不就要減少某些模組的功能讓他可以早點進入整合」。

但其實大家心裡有數,這麼多人在短時間開發出來的系統,不可能在短期間整合完畢。

未料,專案經理似乎沒有體會事實,他說:「接下來大家就要在努力一點,就快要搞定了」。

可能是心情不好,在加上長時間加班的火氣:某組長就說:「我們到目前為止的問題是在於我們不夠努力嗎?」。

專案經理當然說:「不是,我知道大家都很努力...」話未說完,該組長就說:「既然問題不在於我們不夠努力,為什麼叫我們更努力,就可以解決問題?」。

專案經理:「...」





許多失敗的專案管理者,在遇到困境時,只會用幾個永遠不會有好結果的方式,來試圖解決問題。常見的方式像是:無意義的加班,默許降低品質,虛報進度,哭訴人力不足要求增加人力。在緊要關頭,這些作法都不會有好效果。只會這幾種方式的專案經理,儘快離開管理位階,才會是組織最大的貢獻。

最有天賦以及領導力的管理者,通常擁有不可言喻的直覺,並能透過直覺透徹專案。很遺憾的是絕大部分的人不會有這樣的天賦,特別是作為軟體專案經理者。很難具備以敏銳直覺,完成複雜系統開發。

然而,專案管理其實不需要天賦,所有人都可以透過自我學習,了解專案管理的精隨,透過自身的努力作個稱職的專案經理。和所有重要的事情一樣,首先是要了解事實。在略具規模的專案,應該透過事實的呈現,來了解專案目前進度,可能的風險,遭遇的困難,以及解決方式。

而且,只有盡可能了解事實,面對事實,才能引發可行的創意行動。


事實的取得有三個面相:

恰當的衡量:


恰當衡量,是判斷專案經理的好與壞的關鍵之一。恰當:簡而言之,必須是可行,正確,有效,有意義,精簡的衡量。

近年來Scrum蔚為風潮,其中一個重要因素是對於進度的恰當衡量。通常專案進行了一段時間之後,burndown chart可以清楚的顯示,現在專案的進展,和是否可能在預定期限內完成。也因為burndown chart展示的是不可否認的事實,讓Scrum的團隊在取得洽當的衡量之後,做正確的因應。

不恰當的衡量,出現在幾乎所有失敗的專案場景裡。

有些專案經理會依賴WBS的圖表,來看進度是否得當,但WBS是固定的無法調整,即便調整,也很難追溯過去調整的細節。WBS在軟體專案中,很難達到可行,正確,精簡。

有些專案經理,會依賴團隊成員報口述「完成」來斷定進度,在沒有看到「實品」(例如程式碼,每天自動編譯測試的build等等),口述完成不是「有效」衡量。

最慘的專案經理,會透過大型,繁複,耗時的會議,逐一確定已經完成的項目,花在「了解事實」上的時間,遠超過「做事情」的時間。這種本末倒置的既不可行,也不精簡。它唯一的好處只是在於讓原本不懂的人 - 也就是專案經理,花上不可置信的時間了解事情而已。一個不超過10人的團隊,要是每個禮拜耗費總時超過4小時在這類型的會議上,就表示專案經理沒有對技術有透悉能力,儘快換掉專案經理會是對團隊最有利的作法。



承認不確定性:


沒有人可以預知未來,必須承認不確定性,並且把可能的不確定性當做事實加以處理。當打算推測不可知的未來時,用過去之已知事實,並加上不確定性。

例如:未來3個月團隊的總人時?假設團隊成員共10人,每個月22個工作天。則總人時推測為220人日時,等於表示沒有推測。這220人日,根本沒有把「過去已知事實」考慮進去。比較好的推測應該是,220人日,減到(1) 過去3個月,這10人的總休假生病天數。再減掉(2)可能的季節性假日,例如颱風。再減掉(3) 組織已知的活動,例如員工旅遊,大型會議等等。當然,這些以過去的數字推測未來不一定準確。但是,以過去的事實推測未來的不確定性,總比當做沒看到的好得多。

一般專案管理中,不確定性會用風險管理來衡量並且控制。正是「真正」的風險,就是坦然面對事實。

失敗的專案經理在每週的報告中,會把「人力不足」當做風險,試圖避免未來失敗的責任歸屬 - 畢竟已經先在每週報告中說了,目前人力不足是風險,但是就是沒給足夠的人力。這其實單純是專案經理試圖逃避未來責任的作法。

人力不足壓根就不是真正的風險!如果人力不足是真的,那麼專案時程規劃不正確,對技術掌握不足,專案經理沒有創意來解決問題...這些才是真正的風險!假如真有人力不足,它必定不是突然出現的可能機率,它是「已經存在的必然」,風險必須是某種可能會出現的事件,萬一出現,會對專案造成及大的影響。例如,在建築專案中,大地震就是風險,必須要規範出現的機率,但它很有可能不會出現。

把不正確的風險當風險,以及不把真正的風險當風險,都是不願意面對事實的畏縮專案管理者會做的事情。



理解認知偏誤:


在專案管理中,人類認知偏誤(Human Bias) 不可能全部去除,但可以盡量避免。根據事實原則,專案經理應該承認:認知偏誤的存在,盡可能減少影響,但也要理解,不可能全然去除認知偏誤,畢竟人非聖賢,也非機器。自認為已經去除所有認知偏誤,等於是一種認知偏誤。

去除是不可能,理解並且降低偏誤,是取得真正事實的最重要的方向。

例如:在code view的精簡會議中,常出現偏誤在於,極為資深的員工的程式碼,通常比較不會被挑出問題。但根據研究,只要運用程式語言超過2年以上,資深與資淺員工,在程式碼撰寫品質並沒有太大的不同(參見約耳談軟體一書)。要去除這類型偏誤,最簡單的方式是透過系統送出匿名程式碼(在尚未commit之前),要求成員利用email寫出自己的意見,而意見也可以是匿名。

高階主管為另一個例子:高層主管對團隊的了解,大部分來自第一線主管或二級主管。高級主管必須要認知,取的團隊資訊,必然經過過濾和扭曲。這幾乎是不可避免的事情,畢竟第一線主管或二級主管也是「人」。例如,如果發現有某團隊老是有問題,進度不佳,人力似乎永遠不足,高級主管如果找第一線主管了解原因,不會有第一線主管直接了當的說「是我的問題」。但是,一個團隊有問題,75%的原因是出現在領導者身上。去除認知偏誤的方式,除了越級訪談之外,高級主管不應該詢問一級主管的「看法」,而是直接詢問可以獲得的事實。例如:目前的問題,一級主管採用哪些「有價值的作法」來解決。

偶爾進行的團隊訓練活動,也可以將人類偏誤以討論的方式作為主題。讓團隊成員知道有偏誤的存在,自然就有可能減少偏誤的發生。



只要能根據「事實」,降低並去除認知偏誤,比較有機會在困難的專案狀況下,發揮團隊潛能,並且找到有創意的解決方案!畢竟,根據「事實」,一個營利組織必然希望團隊能帶給組織真正的價值,而非僅只是達成表面目的。





5/26/2016

問對問題,如履平地。問錯問題,萬劫不復!




在不到十歲的年紀,有一次流感重症去看醫生。那時候還沒有健保,醫生通常還是會跟家長講一下治療方式可能的價格。當然,如果打一針可以好的比較快的話,多花個幾百塊可能也是值得的。但是!小時候的我很害怕打針。也許恐懼的神情被醫生發現了,他就好意地問『有比較大筒的針跟比較小筒的針,看你要打哪一種?』小時候的我,毫不猶豫的當然回答『小的針。』。結果,最後護士是拿出「兩隻」小的針筒,左右兩邊各打一針。

這個慘痛的經驗,後來讓我學習到,要完整考慮「問題」,至少要從三個方向思考:


1.問題可能不能代表真正的問題


無論是一般工作進行,還是特定專案,通常都有各式各樣的「問題」產生。有些可能是單純的疑問,例如「這個功能什麼時候可以完成?」。有些看起來比較複雜,例如「帳號如果被管理者停用,則正在登入使用中的session是否要立刻中斷?」

單純的問題,可能要考慮的更多。以「這個功能什麼時候可以完成?」為例。可以循用5 Whys 五個為什麼,來了解看似單純問題的真正本質,

例如:

「這功能完成的時間已經在系統有紀錄,為什麼要額外詢問?」--- 原詢問者回答:「只是想要知道有沒有意外」

「為什麼會想要知道有沒有意外?」 --- 原詢問者回答:「之前某高層詢問專案進度,我覺得這個功能因為比較複雜,不知道會不會有風險」

「為什麼高層會詢問專案進度?」 --- 原詢問者回答:「因為高層覺得專案預計完成時間太晚,想要用一些方式提早」

「為什麼會覺得預計完成時間太晚?想要哪種方式提早?」---原詢問者回答:「我也不知道,不要再問了!!」



2. 真正的問題很難找到


事實與真相就像船頭和船尾,首先會看到船頭,然後根據整個情況有多大多複雜,才會在最後看到船尾。

要找到真正的答案,必須要先找到真正的問題。

在許多軟體專案中,經常會有專案管理者以「人力不足」作為問題並試圖解決。但是,這個問題在絕大部份的軟體專案中,根本不真正的問題。

真正的問題也許是:

(a) 許多專案成員另有其他任務,導致投入專案的時間太少

(b) 專案需求不明朗,時常增刪變更,導致時間浪費

(c) 「人才」不足,而非「人力」不足,像是:
       (C-1) 專案管理者沒有看透技術關鍵的能力
       (C-2) 專案成員訓練不夠
       (C-3) ...其他...

而每一個問題, 背後又隱藏其他的問題。絕大部份的專案中,問題看似很多,但最重要的可能只有幾個。

專案經理的重要任務在於:決定真正重要的問題(忽略不重要的問題),並且優先解決最重要的問題。


3. 真正的問題才能找到真正的答案


要找到真正的答案,必須要先找到真正的問題。

一旦找到真正的問題,等於已經產生一半的答案。不過,另一半的答案可能也不見得很簡單。

假設認為真正的問題是「專案需求不明朗,時常增刪變更」,答案的選擇可能有:

(a) 採取Scrum開發模式,確保每個Sprint的需求不會再改變,讓真正的專案擁有者能參與每階段的決定

(b) 暫停所有開發活動,在沒有完成細部設計與需求規格書之前,先不開始開發

(c) 再花時間去找到為什麼專案需求不明朗的背後原因,






最終,每一個成員,需要為自己找到最適切的真正答案。
隨波逐流,最終只能忍受左右兩邊各一針的結果。





5/06/2016

80/20法則之軟體專案的三個運用重點




軟體專案的Scrum的一次sprint之後,照例的檢討會議(retrospective)中,張經理收集了成員的意見,經過投票整理與排序,發現"不夠專注在重點上"是成員們最希望改善的地方。於是,張經理發表他的見解:「看起來大家可能是覺得瑣碎的事情太多,沒辦法專注於工作,這次新的sprint開始,大家試著把心思專注在重要的事情上」,接下來,張經理開始順道交代其他事情:「呃,上次要給法務部門的3rd party版權清單,老馮你準備一下;明天我們要定個下午茶,小陳你有空的時候幫個忙...」。....於是乎,最希望改善的地方就從未改善過。


Pareto Principle,又稱為80/20法則,指的是80%的結果來自20%的原因。這個法則是取名字義大利的經濟學家帕雷托。他觀察到1906年義大利的80%總資產屬於20%的人口。而此一情況被學者們,在其他領域也觀察到重複類似情形,因此被簡約成此法則。

80/20法則中的數字,有時候,會和實際領域不同而有所改變。例如,絕大部份的軟體,其90%的執行期間,執行的是其中10%的程式碼(參見這裡)。


在軟體專案管理中,能掌握80/20法則,等於是掌握80%的成功。

以程式撰寫為例:最重要的10%程式碼,關係到軟體運作的90%時間,掌握最重要的10%的效率與品質,就掌握系統的本身。當然,80%的bug來自於20%的程式碼。(參考這裡

以測試為例:1000個測試案例(test case)如果能有效掌握哪20%的測試案例可以測出80%的潛在問題(bug),就可以有效縮小測試。

以人員管理為例:在有一定人數的情況下,30%的程式設計師完成70%的主要功能。而有追蹤問題(bug)的來源時,80%的問題來自20%的模組撰寫者。


因此,掌握並改善20%重點,是任何專案的成功關鍵因素。

不過,這件事情知易行難。以反面來看,作為專案管理人,如果整個專案過程的每天都忙得焦頭爛額,隨時都有不同的人來進行不同的會議,螢幕旁邊有數十張待辦的便利貼。這很明顯的表示你一定沒有掌握到20%的重點,而你雖然很努力的想要完成任務,但並沒有朝向正確的努力方向。更慘的是,假如你認為這種忙碌可以顯示自己在組織的價值與貢獻,這種想法做為專案的領導者只會害死大家。


每個專案都是獨一無二,因此每個專案的重點20%都有所不同。然而,掌握關鍵的「20%」倒是有三個共同切入點。


1. 目的 - 真正目的


軟體專案的真正目的各有不同:有些是新產品開發,有些是既有產品增加新功能,有些是客製化專案。大部份的情況下,其目的通常不是「技術目標」,而是「達成效果」。

例如,網路商店需要開發mobile app,其目的鐵定不是為了要有一個Android APP或是iOS APP,而可能是要讓客戶在智慧型手機上也能購物。但也有有可能目的是要讓客戶在智慧型手機上容易查詢訂單。當然也有可能兩者兼具。但無論如何,技術目標:也就是有Android/iOS APP,與達成效果通常有相關,但專案管理者必須清楚兩者的不同:

達成效果是勢在必行不可或缺,但技術目標永遠都有其他選項

網路商店不見得需要有APP才能讓使用者在智慧型手機上購物,可以使用符合智慧型手機規格的網站(所謂的響應式設計),讓使用者利用手機瀏覽器進行購物,也可以透過簡訊或者撥打電話的方式購物,開發APP只是其中一個選項而已。

掌握真正目標之後,列出這個目標中的所有使用情境(user story)中最重要的20~40%的功能,而軟體開發的重點就放在這20~40%重要功能。集中力量完成最重要的20%,才不會「先」耗費力氣在無謂的事情上,「最後」才做真正重要的事情。



2. 時間 - 不倒退的沈默成本


時間是不會倒退的(參考這裡)。軟體專案裡的時間成本一旦投入,都屬於不會退還的沈默成本。也因為時間無法退回,一旦投入就是投入。因此,必須要確定「先」運用時間在重要的事情上。

80/20法則的重點在於:計劃運用「未來的時間」,在有效果的事情上以達到80%的產出。

舉例來說,一個程式設計師,在早上抵達辦公室,打開電腦的第一件事情,應該試圖確認「今天什麼事情對我最重要」,而一個開發團隊,每天第一件事情應該是「今天團隊完成什麼事情最重要」。因此,典型的scrum都會在一早展開standup meeting(快速會議),以15分鐘的簡單開場讓專案團隊確保先投入在最需要進行的事情。

這也是一個聽起來簡單,執行起來並不容易的概念。有很多情況,團隊成員並未「徹底」實踐快速會議時的精神。

例如:某甲陳述:今天會開始開發模組A,預計今天會完成,而這也是他今天最重要的事情。然而某甲可能無意識地忽略掉昨天他的功能B的程式碼尚未簽入版本控制系統,因此實際上會議結束,其實他花了一早上在簽入程式碼,並且執行合併/建構系統。某甲並非不應該完成昨天尚未完成的事情,而是他對於「未來即將使用的時間」沒有腳踏實地的認知。

80/20法則運用在專案的時間管理上,最重要的精神在於「腳踏實地」,並且「確實展現事實」-- 缺乏這兩者,會讓80/20法則淪為壓榨程式設計師的幫兇。



3. 激勵因素與保健因素


激勵保健理論(參考這裡),將影響人工作時心裡的滿意度因素分為兩類:激勵因素與保健因素。簡單的說,保健因素是「沒有會死,但是有也不會很高興的因素」,激勵因素是指「沒有的話不會怎樣,但有的話會很高興」。

激勵與保健理論,乃是在軟體專案管理中,80/20法則運用的最容易忽略的一環。特別是在兩個面向上:(a)軟體團隊經營
(b) 技術決策


(a)軟體團隊經營:

保健因素(薪水,電腦設備,工作環境):無論加碼到什麼程度,對程式設計師的績效成長極端有限,然而一旦失去基本下限 - 例如減薪,則其他的激勵方式會突然失效。軟體專案負責人,應該在一開始,就先確保:保健因素是成員可以接受的。爾後專案執行過程,不要特別關注它即可。

激勵因素(個人成長,價值觀,成就感):激勵因素才是大部份軟體開發專案成員「願意保持工作熱誠」的真正原因。負責人或者領導者,應該將團隊經營的80%重點時間放在保持激勵因素。然而每個人的激勵因素皆有不同,因此了解團隊成員個別的「真正需求」,才是需要花時間的地方。

舉例來說,有些團隊成員可能會抱怨沒有雙螢幕,雙螢幕對於撰寫程式的確很重要,專案經理想辦法弄給他雙螢幕之後,千萬不要以為這樣就會讓他心甘情願賣命。雙螢幕只是保健因素,是必要取得,但不是重點。專案領導者在團隊經營上,應該花20%的時間快速搞定保健因素,而後,花80%的時間確保激勵因素的存在。

缺乏激勵因素的團隊成員,並不代表一定會離職,也不一定代表任務不能完成。一個能力很強的人,可能因為暫時沒有其他選項而在現在的位子上滿足最低限度貢獻。這樣成員,反而成為一個潛在的問題,他隨時有可能因為任何短暫膚淺的因素而離開,更糟的是不離開而成為團隊困擾。而這種情況並非是該團隊成員的問題,而是團隊領導者,沒有辦法找到並維持適合的激勵因素。



(b)技術決策:


既然是軟體開發專案,必然會歷經各種技術決策。80/20法則一定是技術決策的主要運用重點。

以功能而言,如果有A功能與B功能在短時間之內,只能選擇完成一個。則技術決策應該從幾個方向考量:

方向一:中大型軟體專案一定有20%的重要功能,會滿足80%的使用者需求。哪一個功能屬於這類。

方向二:如果A與B都滿足方向一,則考慮哪一個功能會直接滿足「專案目的」。

方向三:如果A與B都滿足方向一與二,則考慮兩者哪一個對於此專案是屬於保健功能(沒有會死的功能),哪一個屬於激勵功能(有的話會很高興的功能)。並且考慮專案目的,是屬於維護且保守的專案,還是開創性的新專案。開創性的專案自然優先考慮激勵功能;而維護型或保守的專案,當然要先考慮保健功能。



80/20法則的有效運用是判斷一個優秀的專案領導人的條件。以反面例子而言:有很多15年以上專案管理經驗的所謂專案經理,他所有的經驗可能都在於無謂的忙碌與焦頭爛額中度過,這樣的15年和1年沒有什麼不同。如果你是這樣的專案經理,為了團隊好,或許應該考慮轉換適合的工作跑道。












4/27/2016

軟體專案品質控制的三要點


老馮是軟體專案經理,在專案進行的某一天,被高層找去開會。高層:「最近雲端計算很火紅,你的專案既然是跟Cloud有關,看能不能早點完成」。老馮就問:「那可不可以auto-scaling的功能不做?」。高層:「沒有auto-scaling哪能算雲端計算平台,當然要做啦」。老馮就又不死心地說:「怎麼可能功能不減少又要早點完成?我們都已經是早9晚9在加班」而老馮心裡沒說的是,加班也絕對不是解決的方法。高層:「那就看你們的能力啦,不然我在多加3個人給你好了?」。老馮:「...」


專案管理過程中,品質是最容易忽略的項目。在狀況複雜的專案,品質常常是自動被犧牲的事情。在沒有良好控制的專案,品質是最容易被省略的事情。

品質Quality的定義其實有點複雜(參考這裡)。基本上,在軟體上,一個可接受的品質通常是指:功能如預期的正常運作,並且沒有不預期發生的壞事。

例如,一個手機購物程式,在你執行登入,往下捲動查看最近的商品目錄,點選商品,下單,這幾件事情都如預期的運作,就表示功能沒問題。從看到商品到購買,整個過程沒有讓你覺得很慢,那就算是沒有不預期發生的壞事。

又例如:當你點選商品之後,看到商品大的照片,接下來你就橫向擺放手機,照片因而旋轉之後,再轉回原來的正向,結果手機程式就當機直接跳出,這就表示功能有問題。當你點選商品到購買,整個過程讓你等得很心煩易燥,每個動作都要5秒鐘的等候,那就算是不預期發生的壞事。



軟體專業經理人,應該都知道一條鐵律:品質,範圍,成本,三者不可能兼具。

軟體專案的成本指的是:時間,人力,金錢或其他投入的資源。

軟體專案的範圍指的是:軟體的功能,規模,支援的硬體範圍等等,範圍修改自然就是功能增多或減少。


三者不可兼具,指的是要顧全某一項或者某兩項要素,就一定會犧牲另一項。例如:某APP可以支援google+ 以及facebook 帳號登入,後來因為時間(減少成本)考量,最後決定僅支援facebook登入。又例如,某APP原本可支援google+ 以及facebook帳號登入,後來又希望可以額外支援維博登入,這時候就決定花錢(增加成本)找外包廠商實作此功能。

軟體專案中,另一條鐵律是:試圖三者兼具者,會自動犧牲品質。例如:某APP可以支援google+以及facebook帳號登入,而後又想要支援維博帳號登入。專案經理想要在不增加成本,又不減少其他功能的情況下,又不增加實作時間。硬是要額外增加此功能的結果,必定是品質會自動犧牲。

不知道品質會自動犧牲的專案經理,必定不適合做軟體的專案管理者。

軟體專案品質控制有三個要點:

要點一:來源


品質的來源是整個開發過程,從一開始的計畫以及團隊組成,就已經決定了品質的一半。

一個簡單合理有效的計畫,可以控制改變,掌握進度事實。開發方法是不是採用Scrum並非最關鍵。重要的是,計劃中的開發方法是否簡單並合理的被團隊認知。

舉例來說,傳統SI常會有RFC,也就是需求變更的管理計畫。在開發過程中,如果有需求變更,基本應該是1.先填一份表格,2.在專案會議中與客戶討論,3.互相同意修改之後進行變更。換言之,有需求變更(RFC)管理的情況下,必定是前期的架構,設計細節,規格等等都先完成了,才會開始進行開發,因此,就不可能使用Scrum的開發方式。


假如團隊的組成是可以選擇的,那這件事情也是掌握品質的關鍵因素。



要點二:架構


在實作上,架構是另一個品質的主要關鍵因素。一個優良而且簡單的架構,比較有可能在多人而且複雜的開發情況下,獲取最容易達到的品質。

精煉的軟體架構設計表面上容易,實際上困難。架構的設計要素,眾所皆知:內聚力高,耦合力低,不同模組之間首重介面溝通。

然而,任何有3至5年工作經驗的程式設計師,都可以規劃出極為複雜的架構,普通並且沒有實務經驗專案經理,會容易「讚嘆」這種複雜的架構。這會在不久的未來讓品質很快降低。

實務上,只要沒特別的控制以及重構,正在運行的軟體的熵(entropy)值通常會隨著時間越來越高。同時也讓軟體品質越來越低,或要花很大的成本達到高品質。



要點三:創意


在品質控管中,創意是最被人所忽略。特別是在傳統的開發環境裡,負責品質的相關專業人員通常傾向於「找到問題」,事實上,這的確是QT或者QC的主要責任,但軟體專案中,作為QA(Quality Assurance)扮演的任務就不僅如此,而是在整個開發過程中確保品質符合規格(註一)。

而有創意的QA是第三個重要的品質來源。

普通的QA會執行QT/QC的任務,在開發過程中參與設計討論,並且撰寫測試案例(test case)。在功能完成之後,會認真執行測試案例,或者撰寫測試程式碼以便自動化測試,而在過程中找到並且記錄問題,並督促程式設計師修正錯誤。以上這些都很好,而且也沒什麼不對。

但是!當時系統複雜,時間壓力大,程式設計師能力參差不齊等等困難情況發生時,普通的QA流程並不會對「範圍」以及「成本」有所幫助,因此很容易被壓縮或者犧牲。

有創意的QA會根據專案的情況,找出最好的解決之道。而非死命地抱著舊有的測試流程,在確定有問題的情況下還不進行改善。

創意的可能行動有很多,但總之就是要有「行動」。空想的創意是沒有意義的。有創意的QA行動,可分為技術類型和非技術類型:


技術類型


例如:透過pair-programming主動參與開發;除了自動化測試之外,撰寫當介面改變時的監視程式;對於程式設計師的commit做自動化分析...這些都是透過QA的技術能力,提早發現可能的問題並提早解決。


非技術類型


例如:著重架構的精煉與簡化;改善測試流程;利用其他資源(例如業務人員)進行測試;改善code review的方式;簡化bug記錄以及追蹤方式...等等,這些都是透過QA的協調作業能力,縮短或減小品質差距。


簡而言之,絕大部份的軟體專案品質控制,其實是需要有創意的QA,才能突破既有限制,創造更多價值。而QA要有創意也並不困難,只要願意嘗試,通常都有很好的效果。


參考:沒有QA?如何確保軟體開發品質

註一:ISO對於QA的定義:"part of quality management focused on providing confidence that quality requirements will be fulfilled"






4/12/2016

你真的知道專案進度嗎?



只要是從事程設式設計相關工作的人,必然曾經參與某專案(Project)。專案的大小不一而足,有些只有幾天或幾週,有些橫跨數年。

如果有幸負責專案管理,則無論規模大小,掌握進度是除了管理利害關係人期望之外的第二重要的事情!!而實際上,要管理利害關係人期望的最好方式就是能有效掌握真實進度。

「掌握進度」之後,才能調整應變可能發生的意外,降低風險。


只要看軟體專案進度的「掌握方式」,就大致可以判斷一個專案經理的「本職學能」到什麼程度。

一個好的專案經理,可以單靠自己,就能足以掌握專案進度。

一個普通的專案經理,可以利用流程,規範,加上開發成員的協助在一個合理的時間範圍內,掌握專案進度。

一個很爛的專案經理,會利用各種會議,各種形式文件的填寫(WBS之類),直接或者間接的資訊,花很多時間,仍然不能掌握專案真實的進度。


很遺憾的是,好的專案經理很少,好的軟體專案經理,更是極端的少。因為他同時需要具備技術能力,透悉問題的能力,以及有效的專案管理能力。



要點一:以時間為單位


非軟體專案管理上,掌握進度的單位有很多種,例如「以執行預算」或者「實獲值」來掌握進度。(請參見PMP相關網站)

以軟體專案而言,「時間」才是真正掌握進度的單位。

當詢問負責的程式設計師:「A功能進度如何?」,而他回答「只剩下UI整合,加上DB欄位定義調整,就快好了」。這樣的回答,對於掌握進度幾乎完全沒有意義。因為,該程式設計師可能在A功能花了1天,然而UI整合與DB欄位定義調整,可能還需要另外花上3天,換言之「就快好了」根本不是真的,基本上只完成了25%。但該程式設計師並不是故意要說謊,因為或許最難的就是那25%。


程式設計師若以困難度為考量,進度就像下圖,功能完成之後,就「快要好了」。





但如果以實際時間進度為考量,則如下圖,功能完成之後,只完成了25%。離「快要好了」有很大的距離。




大部份的軟體工程師,著重於困難度。這並非不正確,只是專案管理在掌握進度時,實質進度必然是以時間為考量單位。即便「這件事情很簡單」,也必須要考慮「簡單的事情還是要有人去做」。



要點二:產出的事實


直覺上,大部份的產出當然是程式碼。實務上,非程式碼的產出許多時候會超過想像中的多 -  特別對於比較沒有專案管理經驗的人而言。


基本情況


最基本情境是,根據規格要完成功能A。一開始,程式設計師寫好了程式碼,並且自己編譯(compile)並簡單測試之後,簽入(commit)到版本控制系統中,並且和其他相關程式碼合併(merge)之後,整合成新的版本,並且新的版本經過QA測試後也沒問題。這個功能A就算完成。

在這個情境中,寫程式(coding)可能佔了70%的時間,另外merge以及測試可能佔了另外30%的時間。

專案經理要掌握的「事實點」在於:整合成新版本並經過QA測試後也沒問題,至此,功能A才算完成。


進階情況


在一個稍微複雜的專案裡面,根據規格要完成的某任務,實務上可分為「功能A」與「功能B」。一開始,幾個程式設計師分頭完成自己負責的功能,並分別自己compile並簡單測試之後,功能A與功能B就commit到版本控制系統的不同版本線(code line)。此時,QA分別進行測試,沒問題之後,協調某人「分別」合併功能A與功能B到主線(main line)並且整合成新版本。在整合過程,或多或少有需要修改的程式碼,也許在合併工能A的時候沒問題,但是在合併功能B的時候有出現問題,並也修正完畢。最後新的版本經過測試也沒問題。至此該任務才算完成。

專案經理要掌握的「事實點」在於,最後新版本經過測試也沒問題。至此,某任務才算完成。

但是,這和基本情況不同的是,整個過程很長,從數天到數週都有可能。coding本身可能僅佔50%。而合併,測試,在合併,修改等等可能佔了另外50%的時間。

與前述要點一相同,專案管理者要能掌握實際上的進展,跟「未來還需要花的時間」。在複雜的情況中要掌握,除了最後的產出事實之外,中間的進度掌握,需要靠專案管理人員對專案本身實務的了解。

專案進度的掌控,大部份是由專案經理個人獨立可以完成。其中,技術上的要素就是能否「判斷產出的事實」

而以軟體專案為例,專案管理者如要能判斷產出的事實,必須要能做「自己獨立」做下列幾件簡單的事:

1. 在版本控制系統中(git, p4, cvs等),找出過去一段時間的所有commit過的程式碼變更,誰去變更,為什麼變更。

2. 在最近的新版本測試中,看到哪些新功能確實增加

3. 自行檢查目前bug的清單,並且找出幾個關鍵的bug



假如你是專案管理人員,而你不認為上述事情是自己應該獨立進行,或者你認為上述事情會花太多時間,


請參見下節:除去迷霧。


要點三:除去迷霧


許多「非技術背景」的專案管理人員,常常用各式各樣的大大小小的會議,來獲取專案進度的掌握:每天早上例行會議,每隔兩天來執行bug review,每個禮拜來討論整合進度...開會的本身並不會「加速」專案進行,過多的會議,肯定會「拖累」專案進度。

如果你是一位主管或專案經理,而你迫使專案成員每天花超過10%的時間(也就是40分鐘左右)在正式的會議上,並且只是為了呈報「目前進度」。那麼,你實在是個很糟糕的主管,要麻,你就盡快辭職,要麻,盡快提升自己的專案管理能力,否則你的存在只是浪費大家時間

了解目前專案的進度,等於是除去迷霧,看清事實。除去迷霧的方式,必須要是「貼近事實」與「清晰的技術檢視」。


貼近事實


事實有時候很容易了解。例如:app要可利用facebook帳號登入。此功能容易判斷有完成,或者沒完成。

但有些時候事實很複雜。例如:某程式設計師宣稱,app要可以利用facebook帳號登入,他需要花12個工作天完成。12個工作天到底是長還是短?如果覺得太長,是因為寫程式的人能力不足?還是既有的app過於複雜,所以要加任何新功能都很難?


按部就班的貼近事實是讓該程式設計師先行「分解」這12個工作天。讓專案管理人員了解,他打算如何利用這12個工作天。

如果該程式設計師說「我這個是大概估計,12天就拿來做這一個功能阿,你還要我花時間去分哪天做什麼喔!我哪來這個時間」。這表示事實是,12天根本只是沒有基礎的猜測,他可能22天才完成,也可能2天完成。

絕大部分軟體專案,程式設計師的某行動完成都應該至少可以以「天」為最小單位,(也可是以「小時」為單位,不過太細的單位也會造成不必要的麻煩)。

超過2天估計,就應該可以分成「兩個以上的事情」,超過12天的估計,應該是建立在至少6個以上的某行動完成。


不能分解行動,表示沒有計畫,也對此任務沒有任何基本了解。

假設該程式設計師將app如何利用facebook帳號登入分解為以下工作:

(1) 修改UI: 3天
(2) 登入的程式碼: 7天

(3) 測試: 2天


專案經理應該要能看出,這樣的WBS其實完全是在應付專案經理,對貼近事實沒有幫助。他等同是一樣沒有了解任務。

如果無法將此任務交給別人,專案經理應該參與「計畫」與「分解」的過程。和程式設計師一起坐在某台電腦前面,將android studio打開,了解登入在哪邊加icon,如何到facebook取得App ID,facebook sdk如何使用。

對於有技術領導背景的專案經理,頂多花上一小時,就應該至少可以分解此任務如下:

(1) 到facebook developer網站了解sdk:1天
(2) 申請App ID以及了解相關規定:0.5 天
(3) 登入Icon要和美工討論實作方式:0.5天
(4) 執行登入,取得session:1天
(5) facebook帳號與其他帳號在db處理的不同:2天
(6) 與QA討論測試方式:1天
(7) QA測試:1.5天
(8) 其餘模糊規格的討論,例如是否可登出:0.5天

加總起來可能僅需要8天。但重點不再於天數減少,重點在於此計畫已經破除進度迷霧。當這個計畫開始執行,到了第三天,如果該程式設計師已經開始撰寫登入程式,那麼表示進度和預測相同,但如果他還在申請App ID,表示進度落後,專案經理需要調整進度,或找人幫忙。但無論如何,絕對在計畫開始執行的前期就已經知道如何處理問題,而不是到12天之後,突然發現根本無法完成。


(Android如何利用facebook帳號登入,請參考這裡)


清晰的技術檢視



前述的app利用facebook登入,專案經理之所以能和程式設計師一起坐下來定好比較清晰的時間,其首要條件在於具備清晰的技術檢視能力。

簡要的說,能區分技術難度,區分使用該技術對於專案的影響,以及,使用技術可能產生的風險。清晰的技術檢視能力,會有效提高對整個產品或者專案的洞察力。雖然,洞察力可以經過訓練磨練取得相關經驗,但實質培養卻需要有意識地進行。

技術檢視需要對技術的深度與廣度,每個專案經理所需要的技術能力各有不同,以下有個簡單的軟體專案經理自我問題清單,回答「是」就得1分。

低於5分表示是沒有技術檢視能力的專案經理。
高於8表示是罕見的擁有技術檢視能力的專案經理。

* [Yes/No] 你可以自己從版本控制系統中了解專案目前大致規模:(行數, 檔案數, 平均每工作日增加的程式碼數量),無須依靠其他專案成員嗎?

* [Yes/No] 你可以自己找出哪些程式設計師的程式碼常常會出現bug,無須依靠其他專案成員嗎?

* [Yes/No] 你每一週會隨意抽出幾個程式碼簽入(check-in)看看有沒有明顯的問題,無須依靠其他專案成員嗎?

* [Yes/No] 你會手動編譯專案,無須依靠其他專案成員嗎?

* [Yes/No] 你隨時知道目前技術文件(程式碼註解, api 手冊, 使用手冊)撰寫的實際情況?

* [Yes/No] 你知道專案成員實際花在專案的時間

* [Yes/No] 當某個進度完成時,你可以自己檢查該進度是否真的完成,無須依靠其他專案成員。

* [Yes/No] 你會用專案開發的主要程式語言撰寫工具用程式(例如查閱系統log之類),無須依靠其他專案成員?

* [Yes/No] 你能自己估計團隊能力和團隊完成某模組的大概時程,無須依靠其他專案成員?

* [Yes/No] 你能單靠記憶,繪出目前專案個模組之間大概關係,無須依靠其他專案成員?