當我們在評估一位程式設計者的能力時,多半會從下列這些層面來切入。我們會評估他所能使用的程式語言類型及數量、他對程式語言的熟悉程度,也會關心他是否能夠適當的運用特定的應用程式框架或程式庫,以滿足開發團隊的需求。當然,具有良好的設計觀念及技巧更是我們心目中優秀的程式設計者的必備條件。能夠善用各種工具來輔助開發、提高生產力、減少錯誤,對一名程式設計者而言更是加分。

其實在軟體開發的過程中,還有一些較為「軟性」的能力,其實也深深影響軟體開發的過程甚至結果。這些所謂「軟性」的能力中,可能包括軟體工程、開發流程的觀念等等。而在這之外,像「溝通」也是軟體開發中十分重要的「軟性」能力。

變動未及時與其他成員協調的嚴重後果
溝通有多重要呢?讓我來舉一個例子吧。曾經參與過一個軟體開發專案,在專案開始之後,每個成員都分配到特定一個子系統,而每個成員對於所負責的子系統的介面及功能,也都完成了設計,之後,各成員各自實作自己所屬的子系統,並且規畫了完成以及整合的時程。到了要整合的時候,突然有一位成員出聲了:「因為我在實作的過程中覺得當初的設計有問題,因此,我自己改變了原有的介面設計,現在,新的介面設計及實作是這樣子的……,這樣子修改之後,就變得更好了」。接著,他開始說明做了什麼變動,以及為什麼要做這些變動。

其他的團隊成員聽到之後無不傻眼。這些變動或許言之成理,但是「大哥啊,這些話為什麼不早點說呢?」因為其他成員都已經依據了原先的設計,來假設他所開發的子系統所會具備的介面,現在因為介面已經做了變動,而且幅度還不小,所以,其他成員的程式碼也就遭受到極大的波及,必須跟著做對應的調整及修改。這簡直有如一場災難,大家都必須重新回過頭去改寫程式碼,並且重新測試,最後,才能夠重新回到整合的階段。

這個問題之所以會發生,當然跟許多環節都有關係。例如,透過對開發流程的改善,就有機會可以規避這類的問題。但是,最根本的原因,是出在程式設計者本身在「溝通」上的問題。如果這一位成員,願意在他察覺到必須對介面設計做出修改時,立即找其他成員一同討論,提出他的考量及打算執行的方式,並且在大家一致同意後施行,就不致於發生這種到了最後一刻,才發現有成員不照原先所安排的劇本走的悲慘故事。

將自己的想法早點提出來,可以降低後續影響的程度
諸如此類的故事,我或許還能舉出更多。像是原本預計的時程到了,才告訴大家「我覺得當初所規畫的時程完全不可行,所以,我一直打算照我自己的步調來走,目前我認為,大概還需要一個月的時間,我才能夠完成這個工作。」

專案中所規畫的時程,並不是單方面由專案經理所設定,而是需要專案經理及負責工作的成員,雙方一同協同評估規畫的。

而且,更重要的是,這是雙方同時做的承諾。當負責的成員在一開始或執行過程中,發現預計的時程和實際可能發生的時程有所落差時,就應該及時反映,而不是等拖到槍響前最後一刻,才舉手說「做不到」或是「來不及」。

相信不少人都有和上述例子類似的經驗。這類型的情況,都是只要即時反映自己的想法,讓其他成員或是專案經理明白,進而採取應對的措施,多半都可以獲得更好的結果。但是,因為「疏於告知」,而對專案開發產生了極大的危害。其實,只要多做一些並不是很起眼的小動作,像是發封電子郵件,簡單說明自己的想法,讓其他可能會因此受到影響的成員能夠被告知,就能夠啟動相對應的應對措施,對專案造成的損害也就可以降到最大。

但,正如你可能也經驗過的,只需要很簡單的「溝通」,但是,就是沒有做到。有不少專案就是在溝通上累積了一個個的誤差,導致最後成果不如預期,甚至是失敗。這說明了「溝通」對軟體開發來說,究竟有多重要。軟體開發是「人」的產業,在許多情況下,擅長溝通的程式設計人員,會比程式設計的超級高手來的有用──如果超級高手無法做好溝通工作。

將自己所面臨的處境,表達給其他人知道
溝通是門極為高深的學問,但是只要能做到基礎的溝通動作,對事情就會有很大的幫助。在軟體開發過程中,有幾個簡單的溝通觀念,我想藉由此文分享一下。

首先,最重要的是,要不吝於將資訊提供出來。讓所有的資訊盡可能的在開發團隊中流動是很有用的。這些資訊可能像是自己的進度、自己的實作的想法、自己所遭遇到的困難、自己是否對之前的共識打算做些改變等等。

不吝於將資訊提供出來是一種態度。要先有了這種態度,才有辦法談之後溝通的方式及技巧。有很多溝通所導致的問題,就是源自於根本不打算溝通,非得到不得不說了才說出來。事實上,愈早說出來,溝通的成效就會愈好,造成的問題也就愈小。

我看過有些開發團隊,雖然是遠距在合作開發,但是他們會透過像IRC之類的網路聊天室來交換資訊,而且十分頻繁的交換,這些資訊包括像是自己正在做些什麼、打算做些什麼、有什麼想法。他們雖然也有定期的會議,但是,透過這種機制,隨時都在做溝通。有愈多的資訊在團隊中流動,其他成員就有愈多的資訊,可以輔助他們做所有事的決策,使得決策的品質更好。

千萬不要覺得有些事情只是微不足道的小事,所以就把它給捨棄而不讓其他人知道。有時候你所認為的小事,卻是影響其他人的關鍵。要記住,溝通是再怎麼樣都不嫌多的。「寧可多說,也不要少說」。

有時候我們並不是「吝於將資訊提供出來」,而是「懼於將資訊提供出來」。但千萬要「不懼於將資訊提供出來」。為什麼會害怕將資訊提供出來呢?像是,專案時程中自己所負責的工作項目,可以預見即將發生延遲的情況。有不少人會因為壓力而不敢告訴專案經理自己即將發生延遲,而期待自己可以努力趕上進度或是等待延遲確實發生。

此外,當自己的工作遭遇到難以排除的障礙時,也有不少人會不敢提出,不論是基於愛面子或是怕被視為能力不好。但是,事實上,無論是在時程上或技術上有任何的困難,最好都能盡早讓其他人知道,因為只要盡早尋求援助,可以在專案的計畫或是資源上先做因應的調整,一樣可以將損害降到最低。反之,若是拖到最後一刻,傷害就可能十分慘重。與其如此,不如及早說出。

確認掌握的資訊是否與其他人理解的一樣
除了「不吝於將資訊提供出來」這個原則之外,也不要忘了「不吝於確認自己所理解的資訊」。當我們接收到來自於其他成員所提供的資訊時,要養成習慣向其他成員確認自己所理解的內容是否有所誤差。有些程式設計者在接收到規格或設計時,並沒有確認的習慣,於是就依照自己的理解進行設計及實作。確認同樣也是個簡單的小動作,但是,降低任何可能的誤解,就能造成重大的影響。每個小小的誤解,都可能影響專案的進展,累積起來就更可怕了。

以上只是幾個小小的觀念,但是,只要能實際落實在開發工作中,就能減少不少的問題,讓專案的進展更順利。

 

作者簡介


Advertisement

更多 iThome相關內容