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

無論是否採用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個月)的軟體專案而言，讓破壞性的不適任者離開，當然是解決方式，但不見得要「找另一個人進來」。

---

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