在上一篇文章《敏捷方法的成功密技（六）：Scrum Master 並非你想像的那般卑賤！》中，我們談到了 Scrum Master 這個角色，其實最好是由一位開發和管理經驗豐富的人來擔任，工作經歷不足的菜鳥，是很難勝任得好，更很難以服眾的。
接下來我們就來看一下，為什麼 Scrum 又要特別定義出「開發團隊（Development Team）」這個角色呢？所有的專案，不都得有個「團隊」去完成相關的專案工作嗎？這不是在「脫褲子放屁」嗎？還是老外在「為賦新詞強說愁」呢？
新領域、新團隊，最有機會嚐試新作法
過去，我曾經在一家知名的國際品牌軟體公司，擔任一個新設研發部門的主管。這家公司原本的主要業務，是消費性影像編輯軟體的開發和販售，銷售的對象主要是針對一般的消費大眾，以及少數的專業影像工作者。
因為這類的消費性軟體產品的逐漸飽和，公司的業績成長趨緩，於是就想要把公司的影像處理核心技術，往企業級應用軟體的方向來發展。又因公司內部缺乏企業級應用軟體產品的開發經驗（需要極高的長期運作可靠度和穩定度），於是才從外部徵才，讓我有機會進入這家台灣之光的軟體公司服務，並給了我相當大的產品開發，以及人事的自主權。
當時，部門內的軟體研發工程師只有兩位，因此，我必須在產品的開發過程當中，同步對外徵才，以打帶跑的方式，來管理、建置這個全新的軟體研發部門。這個部門的團隊建立過程，就好像是在運作 Scrum 一樣。接下來，我就詳細說明一下，為什麼我會這樣講。
首先，我一上任就知道，部門團隊必須「盡快」完成一個「企業級應用軟體產品」，但是，不論是公司高層主管或者是我自己，其實都沒有人真的知道客戶在哪裡，更沒有人知道（也不可能問得到）客戶想要哪些功能！所有的功能需求，其實都是我們團隊自己在猜測罷了。
其實，一個全新的、革命性的產品，其誕生的過程，往往都會是這樣的路徑和場景，你不知道用戶是誰、也不知道用戶在哪裡。但是，你也是個地球人，不是生活在火星上，也應該具備一些基本的人類同理心，也應該有能力可以換位思考一下，以用戶的角度先猜想個大概的需求應該長怎樣。
開發團隊夠紮實，產品就能打帶跑
然後呢？當然就是必須盡快地，找到客戶來埋單，找到真正的用戶來使用產品，驗證一下當初團隊自己的假設性需求是否正確，有多少是賓果中獎了，哪些又是雞肋該被丟掉。但是，想要做到這一步，還必須先要有團隊，而且團隊要有能力迅速把產品功能實現出來才行！而這個開發團隊的順利建置與否，絕對是這個企業級產品能否成功的關鍵因素之一。
有主管經驗的讀者夥伴們，您一定遇過跟我一樣的這種困境，那就是：好人才難找，尤其是軟體人才！
不消說資深的軟體工程師難找，就算是沒經驗但有興趣來從事軟體開發工作的新手，也不是這麼地容易找得到。況且，請神容易送神難，研發人才的徵選和培育，更該服膺「寧缺勿濫」的準則，切莫「飲鴆止渴」，隨便找人來充人數。不然，我保證您會引火上身，難以善後。因為，鐵定會有人不斷地在到處放火（製造 bugs），讓整個團隊疲於奔命地滅火（相關文章可點擊參閱「好人才，怎麼找」系列文章）。
因此，在這樣的徵才策略原則之下，我聚焦在「維持恰當資深/資淺人員的搭配比例」的大原則，來逐步地招募建置部門的研發團隊。當有新手加入團隊的時候，我們就必須要讓暨有的老手（資深人員），手把手地帶這這些新手們熟悉上手其工作，也就是所謂的 on-job training！
然而，一個新手的加入，大概會消耗掉團隊中一個老手，約略三分之一到一半的工作時間，來「用心」教導這個新手熟悉相關專案工作，同時還能維持新手和自己的工作品質。這個訓練的過程，還將持續三到六個月不等的時間，端視新手的學習能力和老手的教導能力而定！
這也就是說，在新人的訓練期間，１位老手＋１位新手，最多只會達到 1.5-1.67 個人的戰鬥能量（這還是在「新手能夠達到老手同樣的生產力」的假設前提之下）！您也許會問，怎麼會需要消耗掉一個老手這麼大比例的時間，來教導和訓練一個新手呢？
其實，這也是 Scrum 的精神。研發團隊不該只求人多，但更該要求的是，每位人員都很精實！因為，軟體產品的品質，跟創造軟體的人的素質，是非常緊密相關的！
待續...
圖片來源：spin.atomicobject.com
相關文章：