成員離開團隊時,生產力下降是最為直接的影響,對軟體開發工作來說,交接除了靠文件,也可透過知識分享、一起搭檔工作的方式,將集體知識儲存在團隊成員上

任誰都不喜歡團隊中的成員有所異動,我曾在之前的文章中,提到有新成員時加入團隊時可能會引發的種種問題。新成員加入團隊可以為團隊提供更多的生產力,但加入初期仍不免因為諸般因素,而造成整體生產力的降低。而當成員加入的情境變成了成員離開團隊時,情況往往只會更惡劣,因為所造成的生產力下降是最為直接的。一來少了一個人手,二來還得倚靠現有成員進行工作交接,折損了他原有該有的生產力。

不過,現實世界就是如此,即使你再怎麼不喜歡團隊中有成員離開,這件事終究還是有可能會發生,一旦發生了,就是得坦然面對。

還好,通常公司中的員工在離職時,會有一定的預告期,在這段預告期間,你還有機會及能力去安排應變的相關措施。

通常會透過文件的搭配來交接工作
成員離開團隊的原因有各種可能,在本文中就不予以探討了。一旦有成員要離開,就勢必要辦理交接的工作。當然,那些行政上的交接程序,像是保管財產的交接之類的事宜,也不在我們此次關心的範圍之內,我們最關心的當然還是開發工作的交接,以及盡可能降低對之後開發工作的衝擊。交接這件事當然不是形式,而是希望具體達到減緩衝擊的目的。

想到了開發工作的交接,你可能會先想到「文件」。理想的情況下所要交接的內容已經有了完備的文件說明,所以要把工作交接出來的人,只要辦理幾次正式或非正式的交接說明會議,解釋文件的內容,欲交接者大概可以有一個脈絡可依循。

只不過,完備的文件通常也很少存在,因此,在遇到交接事件時,就很有可能要撰寫需要、但卻不存在的文件,以利交接工作的進行。

交接的文件及說明,應該包括那些項目呢?首先是業務規則(business logic)的部份。

業務規則的文件說明了系統運作的邏輯規則。通常應該是在需求規格文件中,會載明業務規則。

如果不知道業務規則,就不知道系統究竟是如何運作的。

例如一個報表的計算,如果不知道其計算的規則,自然無交接可言。再來是系統的架構及設計,使用圖或文的方式說明了系統的大小組成,以及每個組成所對應的具體作用,還有各個大小組成之間互動的方式。此外,還有資料儲存的格式,例如資料庫的schema 設計,以及資料的操作規則。大多時候,這些都是設計文件中所會包括的。

在實作層面上,對於對應之設計的原始碼位置,以及對應關係也應予以載明。所使用的開發工具及環境、建構原始碼的方式、部署系統的方法、系統所動用到各個伺服器位置、伺服器的帳號及密碼自然也都必須辦理交接。

看到了這邊會不會覺得有一點很有趣,也就是這些資訊,事實上是原本就應該存在,在團隊中被適當流通的,但是為什麼卻時常等到了有人要離開了、需要做交接了,才開始準備這些文件,或才開始流通?

從沒有文件的角度來看,這有可能是因為文件記錄、書寫的額外負擔,使得許多開發團隊不打算付出這個成本,來換取開發上的更輕量化。對於一些「重量足夠」的流程來說,在有人打算離開時,或許這些文件都是現成的、毋需再另行準備。「魚與熊掌難以得兼」,得到了簡化文件書寫的好處,就會在像是交接這種時刻來付出代價。

從交接所得到的資訊,離真正落實還有一段距離

但即使是有了文件,有做過交接工作的人也都知道,從這些文化中所獲得的資訊,要落實到真正的開發工作上,通常還需要一段轉化的時間,因為你多半不熟悉其中所記載的事項,在實務的工作中,多半是邊查閱文件邊運用,甚至還得重新思考文件中所載事項和實務上需求的關係。即使交接過程中說明的如何詳細,之後還是可能有所疑問,這都是因為,交接時無法考慮到真正會有的實務問題所導致的。

交接工作考驗的是,當有人要離開團隊時,團隊因應這個變化的能力。

倘若原先團隊在開發過程中的文件,即按一定流程及規範產出,那麼當不幸必須做交接時,應變的能力就會比較好。相反的,若是團隊在開發過程中,缺乏對這些資訊做記錄的措施,那麼就必須臨時在交接期間,盡可能補足這些資訊。

交接工作其實就是一種團隊共有知識的流通。原先在開發過程中,整個團隊集體累積了一定的知識,得以開發出現有的系統。當有人離開團隊時,整個團隊便有可能失去一部份的知識,致使必須透過交接程序來彌補。

開發過程中應該知道的知識,可透過所有團隊的成員來流通
文件記錄是一種封存集體知識的方式,不論文件中的資訊有沒有被流通,最起碼,資訊被記錄下來了,有朝一日需要的時候,這些資訊可以被重新「召喚」出來。少了文件記錄、或是文件有一定程度的簡化,那麼勢必要將這些集體知識儲存在團隊的成員中。

所以你可以看到一些「敏捷」的開發方法,試圖降低文件書寫所造成的額外負擔,它們不寫文件或是只寫簡單的文件,而選擇把集體知識儲存在團隊成員中。

所以,這些開發方法會重視集體知識的共享,讓開發中所涉及的知識,盡可能地在團隊成員間擴散。就像搭檔設計(Pair Programming)的目的之一,便是透過結對的伙伴一起撰寫程式,讓開發中的集體知識得以流通。

所以,沒有任何程式碼是只有特定人士才能夠編寫、修改,也不會只有特定人士才了解某個業務流程或業務規則。因為這些知識都透過一定的機制,不斷在團隊中流動。知識可以記在文件上,也可以記在團隊成員的腦中,重點是當某個成員離開時,團隊有沒有辦法很快的修補、回復所缺的那一塊拼圖。倘若離開成員所知悉之事,也都為其他成員所知,那麼該成員的離開所造成的傷害,自然就會小很多。

所以說,文件記錄並不是問題的核心或本質,這背後最重要的意義在於,開發相關的資訊在團隊流動、擴散的程度和速度。

如果,每一段程式碼,都可以被團隊中的多個、甚至是每個成員編寫、修改、擴充,那麼就代表開發知識已經大範圍的擴散、流動,整個團隊承受成員離開的能力就會很好,交接工作的進行也就會順利許多。相反的,若是開發知識過度封閉或是沒有適當的流通,等到有成員要離開時,交接所造成的影響就會大多了。

交接表面上看起來是有成員要離開團隊時才發生的事件,但是,影響交接是否會順利、有效的關鍵之一,卻是在團隊平時在運作時,是否已經做好了足夠的準備。

如果團隊平時在知識流通、擴散上,有妥善的機制設計,那麼,即使不倚賴大量的文件記錄,也能讓交接工作事半功倍。相反的,若是平時知識不夠流通,特定的知識也僅有特定的人員明白,那麼即使有詳盡的文件,也不見得能保證交接工作進行得一帆風順。

總之,一個知識流通順暢的開發團隊,因應成員離開的能力會很好。

作者簡介


Advertisement

更多 iThome相關內容