Scrum,敏捷,專案管理,PMP,領導統御,甘特圖,排程軟體

    敏捷方法的成功密技(七之一):Scrum 的夢幻開發團隊該怎麼來建置?

    在上一篇文章《敏捷方法的成功密技(六):Scrum Master  並非你想像的那般卑賤!》中,我們談到了 Scrum Master 這個角色,其實最好是由一位開發和管理經驗豐富的人來擔任,工作經歷不足的菜鳥,是很難勝任得好,更很難以服眾的。

    接下來我們就來看一下,為什麼 Scrum 又要特別定義出「開發團隊Development Team)」這個角色呢?所有的專案,不都得有個「團隊」去完成相關的專案工作嗎?這不是在「脫褲子放屁」嗎?還是老外在「為賦新詞強說愁」呢?

    新領域、新團隊,最有機會嚐試新作法

    過去,我曾經在一家知名的國際品牌軟體公司,擔任一個新設研發部門的主管。這家公司原本的主要業務,是消費性影像編輯軟體的開發和販售,銷售的對象主要是針對一般的消費大眾,以及少數的專業影像工作者。

    因為這類的消費性軟體產品的逐漸飽和,公司的業績成長趨緩,於是就想要把公司的影像處理核心技術,往企業級應用軟體的方向來發展。又因公司內部缺乏企業級應用軟體產品的開發經驗(需要極高的長期運作可靠度和穩定度),於是才從外部徵才,讓我有機會進入這家台灣之光的軟體公司服務,並給了我相當大的產品開發,以及人事的自主權。

    當時,部門內的軟體研發工程師只有兩位,因此,我必須在產品的開發過程當中,同步對外徵才,以打帶跑的方式,來管理、建置這個全新的軟體研發部門。這個部門的團隊建立過程,就好像是在運作 Scrum 一樣。接下來,我就詳細說明一下,為什麼我會這樣講。

    首先,我一上任就知道,部門團隊必須「盡快」完成一個「企業級應用軟體產品」,但是,不論是公司高層主管或者是我自己,其實都沒有人真的知道客戶在哪裡,更沒有人知道(也不可能問得到)客戶想要哪些功能!所有的功能需求,其實都是我們團隊自己在猜測罷了。

    其實,一個全新的、革命性的產品,其誕生的過程,往往都會是這樣的路徑和場景,你不知道用戶是誰、也不知道用戶在哪裡。但是,你也是個地球人,不是生活在火星上,也應該具備一些基本的人類同理心,也應該有能力可以換位思考一下,以用戶的角度先猜想個大概的需求應該長怎樣。

    開發團隊夠紮實,產品就能打帶跑

    然後呢?當然就是必須盡快地,找到客戶來埋單,找到真正的用戶來使用產品,驗證一下當初團隊自己的假設性需求是否正確,有多少是賓果中獎了,哪些又是雞肋該被丟掉。但是,想要做到這一步,還必須先要有團隊,而且團隊要有能力迅速把產品功能實現出來才行!而這個開發團隊的順利建置與否,絕對是這個企業級產品能否成功的關鍵因素之一。

    有主管經驗的讀者夥伴們,您一定遇過跟我一樣的這種困境,那就是:好人才難找,尤其是軟體人才!

    不消說資深的軟體工程師難找,就算是沒經驗但有興趣來從事軟體開發工作的新手,也不是這麼地容易找得到。況且,請神容易送神難,研發人才的徵選和培育,更該服膺「寧缺勿濫」的準則,切莫「飲鴆止渴」,隨便找人來充人數。不然,我保證您會引火上身,難以善後。因為,鐵定會有人不斷地在到處放火(製造 bugs),讓整個團隊疲於奔命地滅火(相關文章可點擊參閱「好人才,怎麼找」系列文章)。

    因此,在這樣的徵才策略原則之下,我聚焦在「維持恰當資深/資淺人員的搭配比例」的大原則,來逐步地招募建置部門的研發團隊。當有新手加入團隊的時候,我們就必須要讓暨有的老手(資深人員),手把手地帶這這些新手們熟悉上手其工作,也就是所謂的 on-job training

    然而,一個新手的加入,大概會消耗掉團隊中一個老手,約略三分之一到一半的工作時間,來「用心」教導這個新手熟悉相關專案工作,同時還能維持新手和自己的工作品質。這個訓練的過程,還將持續三到六個月不等的時間,端視新手的學習能力和老手的教導能力而定!

    這也就是說,在新人的訓練期間,1位老手+1位新手,最多只會達到 1.5-1.67 個人的戰鬥能量(這還是在「新手能夠達到老手同樣的生產力」的假設前提之下)!您也許會問,怎麼會需要消耗掉一個老手這麼大比例的時間,來教導和訓練一個新手呢?

    其實,這也是 Scrum 的精神。研發團隊不該只求人多,但更該要求的是,每位人員都很精實!因為,軟體產品的品質,跟創造軟體的人的素質,是非常緊密相關的!

    待續...

    圖片來源:spin.atomicobject.com

    相關文章: