在之前,我們探討過好幾次關於程式設計者開發生產力的議題,大多數情況我們著墨著程式設計者如何改善個人自身的生產力。程式設計者自身的技巧、設計方法、所使用的工具、等等,都會影響到他個人的生產力。

不過,軟體開發可以說是個團隊的活動,當然,也有少數的軟體是在個人或很少數人的情況下完成,但是,一般情況下,軟體都是由多人一起協同完成的。個人生產力和團隊生產力間不必然畫上等號,團隊中有生產力超高的程式設計者,不代表團隊生產力一定同樣的高。

個人的生產力固然重要,但團隊所呈現整體的生產力,才是最後決定開發效率的因子。在過去,我們也看過不少高手坐鎮的團隊,卻沒有因為高生產力的程式設計者加持,而使團隊生產力大幅提升。高手的生產力的影響效應,在團隊中會被稀釋。

這說明了當我們探討生產力時,也不能忽略討論如何增加團隊整體的生產力。

用管理來促進軟體開發團隊的生產力
當團隊成員個別的生產力,受個人技巧、觀念影響甚鉅時,要怎麼提升團隊整體的生產力呢?當然,有一個重要的方向便是從管理面來著手。

有不少人談到「管理」,往往會先入為主地認為,「管理」就是施加額外的負擔。尤其對程式設計圈子裡的人來說,更是如此。我有看過某個開發團隊的招募文案,其中還強調「無管理」,其用意當然是對準那些不希望工作受到無所謂「管理」手段干擾的程式設計者。據我的觀察,有很高比例的程式設計者對於「管理」,都沒有太好的印象。

事實上,或許的確有些人的「管理」,純粹只是為了營造有「管理」而做的管理,並不能真正達到管理的目的,如此一來,管理的手段,當然會成為施加在程式設計者身上的額外負擔。但增加額外負擔並不是管理的目的,它是管理要付出的成本。對軟體開發團隊的管理,其最終目的當然包括了要提升軟體開發團隊整體的生產力。

管理絕對不是只是為了形式上的滿足,也不是為了建構出有制度的假象。當然,你可以看到不少人是為了這樣的目的來做的。透過建構出「有制度」、「有流程」的假象,會讓一些人放心,因為這樣,讓他們相信自己的團隊好像運行在軌道上,最終可以如他們所預期的路線、速度來達到終點。

這種對管理的想像,就和對開發文件的想像是類似的。正如同有人會不明究理地要求團隊成員,完成許多本質上其實完全不需要的文件內容,只是為了滿足對「形式」的渴望,完全不理會製作這樣的文件,是否能對開發本身帶來助益。如此一來,最終只付出了「代價」,卻沒有獲得該有的好處。

也因為追求形式的人太多,也使得程式設計這個圈子的人,普遍對管理手段存在負面的印象,而這並不是管理本身的目的,還有期待得到的結果。

回歸管理的初衷

我們應該要回到管理本身來思考,為什麼我們需要管理?目的是什麼?我當然不是熟悉管理領域的人,做軟體開發團隊管理工作的時間也不算長,但是,對於軟體開發團隊的管理,倒是有一些想法,想提出來分享。

對軟體開發團隊的管理,其主要目的應該是要輔助每個成員用更有效率的方式、順利完成他們各自的工作,並且使他們得以更容易的方式整合起來。

透過對於這個目的的陳述,我們應該可以了解到,管理本身是一種輔助,是透過一些手段和方法,來輔助團隊中的每個成員來完成他們的工作,並且使每個人的工作成果最終匯整起來,因而得到開發最後的產物。所以,對每個團隊中成員的「輔助」,是我們在思考如何施行管理的手段時,應當要時時刻刻想到的。

舉例來說,開發團隊大多都會使用版本控制系統,來管控多人開發下的原始碼。但是,在缺乏管理的情況下,或許會有成員任意將不能成功編譯的原始碼,送上版本控制系統中,使得團隊中的其他成員,因而取得了有問題的原始碼,同時也影響到其他人的工作。

所以,我們需要管理,需要在團隊中規範使用版本控制系統的準則,讓每個成員得以依循此準則來使用版本控制系統。這些準則中,可能會包括像是:「送上版本控制系統的程式原始碼,都必須是可以成功編譯的」。

這樣的準則看起來是個限制,因為這麼一來,程式設計者就不能隨時想將原始碼送上版本控制系統就送上去。但它背後的意義是要輔助程式設計者,避免在不小心的情況下,影響到其他成員的工作,進而影響到團隊的實質生產力。

你可以想像,若是少了這樣的規範,團隊的其他成員,偶而就要被這種錯誤干擾,也必須耗費時間聯繫、等待造成錯誤的成員修正問題之後,才能繼續原本的工作。這就是生產力的耗損,或許單看個人的生產力能力是好的,但只要團隊中有成員會造成此類的錯誤,再高生產力的程式設計者,也會因此而受到影響。從整體來看,生產力就變低了。

所以說,管理就是做為一種輔助,正因為我們知道倘若少了這樣的管理規範,少數成員偶發性的錯誤,就會造成整體的影響,所以,我們才會進行一些管理的手段,來輔助程式設計者不致於犯下這種錯誤。有了這樣的規範,起碼在文字上明確提醒程式設計者,必須留意此事。而你也可以想像,若想在文字之外提供更進一步的保障,可以在工具或流程上再加強,更可防止程式設計者的無意之過。這就是管理的作用。

當然,你或許也會想到,少了這樣的規範,只要我的成員觀念都正確,也都能夠自律,他們自然就會自己做到這件事,並不需要管理。

的確,但管理的手段本來就是因時、因地、因人而制宜,軟體開發是個以人為中心的工作,倘若能確保你的成員都一定能自律,那麼,這樣的規範當然也就形同虛設。但是另一方面,在這個例子裡,這樣的「自律」是一種文化、價值觀、習慣或工作模式的契合,所產生出來的結果。

單看版本控制系統的使用,就有可能有多種不同的文化,例如,有人喜歡單一版本線,但有人喜歡廣泛地運用分支機制,除非你能確保團隊中的每個成員,都有相同的看法和習慣,否則,仍舊還是會需要管理的手段進來介入,以維持眾人使用相同的方式,來協同合作。

從管理做為一種輔助的觀點來看,你可以想到很多管理可以有所發揮的事情,像是,透過管理的手段了解每個成員是否遇上了困難或障礙,以便調度其他的資源來進行協助。

像從這個例子裡頭,你就能明白開會的意義。

開會當然可以用很形式的方式來開,但開會也是可以具有實質的管理目的,像是讓每個人了解其他人的工作進展,是否遇上了困難、是否有其他人能夠提供建議或伸出援手,來加快問題解決的速度等等。當你了解會議的作用後,就知道如何因時、因地、因人制宜,在管理上安排會議。

集合很多很強的人在一個團隊裡,不一定得到一個很強的團隊。這中間當然有很多因素會影響到這個結果,但是,是否提供了良好的管理輔助,肯定是關鍵的因素之一。很強的程式設計者不太會犯下本文中舉的這種低層次的錯誤,但是他們需要其他形式的輔助。良好的管理輔助,的確是可以讓每個人清楚知道自己,在每個時間點上該做什麼,該如何和別人互動、合作,而這對帶來更佳的團隊生產力,是有幫助的。

 

專欄作者

熱門新聞

Advertisement