... of the 20,000 notable players for us to consider, I believe that there is a championship team of twenty-five people that we can afford, because everyone else in baseball undervalues them...(Moneyball 魔球)
軟體開發團隊的建立和運作,不可能有完美的狀況。但是,妥善的計劃,能大幅降低軟體團隊的運作風險,並且讓團隊成員專注於發揮專長和創意,減少不必要的浪費時間。
特別是浪費時間在於解決非技術性問題。
問題有可能來自各方面,例如:
(1) 目標極端困難。例如:要在3個月內完成類似AWS EC2的雲端運算平台。
(2) 目標不確定性極端的高。例如:團隊目的是要完成一個不知道誰簽訂的模糊合約。
(3) 團隊還沒組成,目標也還沒確認,就已經有時間壓力。例如:一個2-3個人合作的新創公司,剛剛獲取資金成立。
(4) 團隊的組成有時間壓力。例如:在大企業中,因為高層要求,一定要在某月某日找齊7個人組成團隊
(5) 團隊已經有部份是問題成員,在此同時還要因組織任務擴張而增加人力。
(6) 因為組織變動(例如企業改變目標,併購等等),讓某個團隊大幅流失人才,而需要重整補齊人力。
(7) 因為文化與跨國合作困難,導致前期人力大幅流失而需要重整團隊。
負責組織團隊的人,最最基本的認知就是:
軟體團隊組成這件事情:本身一定會有困難與挑戰。不具備困難與挑戰的軟體團隊,其實沒有存在的必要。(註1)
以下三個步驟可以供組織團隊負責人參考:
(1) 了解探索事實,盡可能將事實攤在陽光下
許多新團隊一開始就建立在「各種假設」上。例如新創團隊「假設大家對Scrum都有相關經驗」,或者「假設在3個月後可以找到2個優秀的iOS開發人員」,或者「假設大部分的使用者都有fb的帳號」,或者「假設3個月內某個模組可以先行開發完成」。
在許多情況之下,很多事情的確有假設,才能進行下去。
但是,在建立團隊的時候,除了瞭解背景假設之外,先確認事實才重要。
以下事情必須要儘早確立。
(a) 團隊目標願景:
可參考下節「確切定義短期中期目標」。如果是非營利組織,團隊願景就非常重要。因為這可能是召集成立團隊的最大動力。一般企業,營利組織,除了獲利之外,也可能會伴隨其他更遠大的目的。例如:「讓人類可以移民火星」之類的(註2)。
一個有崇高理想的非營利團體,也就不應該將盈餘拿來作為績效獎金。而是以團隊能達到的願景作為激勵人心的最大方式。(例如Kiva)
相對的,如果只是單單純純想賺大錢的公司,例如某東南亞賭場在台灣的軟體部門。也就不需要唬爛一個崇高的偉大目的,就只要讓團隊了解「大家來歡喜寫程式賺錢吧」即可。因為有正確的認知,才能集合正確的團隊。一個誠實的宣稱「大家來寫程式賺錢吧」的團隊,自然不會將社會責任活動當作是團隊成員想要做的事(例如:到沙灘撿垃圾,協助獨居老人),當然「培育企業人才」也不太需要,甚至Scrum裡面的「自己選取task來做」也根本不用,採用由上而下的軍隊式管理,讓工作以最有效率的方式完成,才是這種團隊的最好方式。
(b) 資源現況:
目前的現況是不可否認的事實,但許多人一開始的時候,會將現況和未來的希望混為一談。在此時此刻擁有的資源就是現況。
例如:現在有1個專案經理,以及1個剛剛到職的工程師,未來可以找10個人。...這就是資源現況。
但也有可能是:現在有1個專案經理,以及1個剛剛到職的工程師,未來可以找10個人,但是辦公室座位目前只有4個空位。...這也是資源現況。
更有可能是:現在有1個專案經理,以及1個剛剛到職的工程師,未來可以找10個人,但是辦公室座位目前只有4個空位。而團隊目前總薪資預算為1千萬台幣,其中還得包含筆記型電腦採用費用。扣掉已經到職的兩個人,年預算只剩下600萬台幣,所以可以找10個人,但是平均年薪只能為60萬,或者找6個人,平均年薪為100萬。...這也是資源現況。
作為一個建立並組織團隊的人,資源現況的瞭解和掌握,必須要越清楚越細節越好。實際上,絕大部分的情況下,只要稍微多花個幾個小時,就可以掌握到很多現況細節。
(c) 組成專長:
即使已經是軟體開發的專家,這仍然是一件需要擔心的事情。
如果團隊的短中期目標確定,組合的專長可能大致確認。然而,某些專長不見得是「團隊成員需要有的」,這些專長可能可以用「短期購買」取得。
團隊領導者在取得事實的階段,需要清晰可見的專長分佈圖。
以上圖為例:簡單地列出做一個購物網站可能需要的專長,並且也把目前團隊已經擁有的人才能力列在其上。未來在組合團隊時候就比較容易考慮周詳。
要注意的是,這樣的圖並不是要完全技術上正確,而是要做為未來計畫的參考。因此有可能一再修改,也不見得需要用了不起的繪圖軟體製作。
(d) 關鍵成功因素:
哪件事情做好了,會讓這個團隊成功。成功關鍵因素應該只有1-3個,不應該太多。 這個關鍵成功因素必須要很「實際」,能夠被「衡量」,當然也必須要是能「達成」。至於困難不困難就不一定。以xspace的火箭設計為例,他的關鍵成功因素不只是火箭能發射,還要能「掉回地球後,能自己站立,以便低成本回收」。
軟體開發團隊的「建立組成」的通常是願景能否達成的關鍵成功因素。然而,建立組成的本身也有關鍵成功因素。例如,在2個月內吸引3個具有5年工作經驗,並且容易合作的工程師到職。
....其他需要搜集以及展現的事實還有不少。完整清單請參考(註3)。當然,不可能花幾百天的時間,只是為了收集事實,只要在合理的時間內,盡量收集了解重要的事實。
(2) 確切定義短期中期目標
前段所述的事實如果了解的夠完整。定義短期中期目標就很簡單。
短期目標是1週到4週內「必須」完成的事情。中期目標則必須要能夠「完成一項的關鍵成功因素」。
以建構軟體團隊而言,八九個短期目標完成後,差不多就等於一個中期目標完成。
任何軟體開發計畫,必定會有目標,而讓團隊朝向「同一個方向」前進。所謂團隊,當然是一群人往同一個方向前進,才能叫做團隊。一群在同一個組織架構的人,或者在同一個老闆底下工作的人,不見得是一個團隊,很有可能每個人在軟體開發
(3) 根據目標擬定計劃和備用計畫- Plan B
兵法有云「夫未戰而廟算勝者,得算多也;未戰而廟算不勝者,得算少也。多算勝,少算不勝,而況無算乎!吾以此觀之,勝負見矣。」
計劃本身並不重要,但是做計畫這件事情很重要。
計劃要達到的目的要非常清楚。而且必須「至少」包含兩件事情!
*** 達到短中期目標的做法
*** 實質建立工作環境與實際做法
建立軟體開發團隊的初始計畫至少需要涵蓋以下內容:
(a) 團隊目的,短中期目標
....請參考前兩段...
(b) 團隊組成
需要哪些專長的人在這個團隊。更重要的是,哪些技術背景的人的組成最適合這個團隊。最好的方式是將所需要的「實質技術能力」清楚地列個圖示,根據分佈圖,來劃分團隊組成。
切勿用想像的方式。
以上圖為例:這是一個打算建立電商網站的技術分布圖,和目前團隊成員(四個人)所擁有的技術連結。可以很清楚的看到哪些領域還沒有適當專長的人。也可以清楚地展示,團隊目前組成和未來最需要的地方。
這個草圖並非正確的描繪出細節,而且也把技術不相干的東西納入(例如裡面有個API doc,其實是還沒有去做的事情)。但整件事情的精神在於「視覺化」。透過視覺化,對團隊的變化才有整體性的考量和規劃,而不會落於枝節上。
(c) 團隊運作原則
近年來流行Agile的Scrum方式。可以參考這裡。
(d) 初始化工作項目
當團隊的成員是逐漸到職,最初的工作項目是能夠讓團隊快速形成共勢。這看似枝微末節,但是是隱含的關鍵成功因素。
初始化工作項目,在新成員到職的前幾天,最好是鉅細彌遺。規劃了新成員第一天到第五天,「每天」要做的事情和達成的結果。並規劃前4週,要達到的大項目,以及前3個月的必須要的貢獻程度。
團隊是由一個個單一個人組合起來。將個別成員的適應期縮得越短,對團隊的組成越有利。
規劃前五天的細目,絕對不會讓這個新成員變得沒有創意,也絕對不會扼殺他的潛能。反而是讓他可以在極短的時間之內,先擺脫掉和「智慧創意」無關的邊緣事項。因為這些邊緣事項,如果在前一段時間沒有擺脫,之後會一直出來煩大家。
以下是某個電商開發團隊的前三天初始化工作項目,同時也是檢閱清單:
Day-1
- Mentor介紹工作環境,取得電腦和其他硬體設備
- Mentor協助取得email和其他必要的帳號
- 取得目前程式碼版本控制系統權限,確定可以clone
- 確定clone目前的程式庫
Day-2
- 取得目前的UI/UX設計文件,Mentor協助了解文件內容
- 參加Scrum會議,理解Scrum雞與豬的原則
- 在Mentor協助下,建立自己開發環境
Day-3
- 在Mentor的協助下,在自己的開發環境確定能修改程式/簽入(commit)/建立branch,最後產生自己的build。
- 了解基本的測試項目
以上僅是3天的範例,這些看似細節,但要在三天之內完成也不並容易。
(e) 定期檢討方式
檢討方式可以參考這裡和這裡。
簡而言之,建立團隊的過程也需要被檢討。
例如:
新加入的成員,在當初面試的時候所呈現的能力,和實際上工作的產出,是否吻合。
新的成員對於非技術類型的雜事,是不是很快能找到資訊。例如git的位置,目前各個branch的狀況,自動化建構的方式,建立開發環境的方式等等。
註1:如果這個挑戰對負責組織團隊的人來說太過困難,最好不要接受這樣的任務。一個失職的程式設計師頂多讓專案推遲幾天,或者品質降低一些;但是一個失職的領導者,會讓整件專案崩壞。
註2:例如xspace
註3:建立軟體開發團隊的事實搜集清單
(a) 團隊目標願景
(b) 資源現況
(c) 組成專長
(d) 關鍵成功因素
(e) 關鍵風險 - 一旦發生就可能會失敗
(f) 關鍵技術 - 是否有必須具備的關鍵技術,需不需要招募這樣的人才
(g) 利害關係人 - 哪些人跟這個團隊有實質的相關
(h) 外在環境 - 辦公室設備 是否有遠端甚至跨國合作團隊等等
沒有留言:
張貼留言