求救及伸出援手

有時候，你會發現在開發中的大部份工作看起來都很順利，但只有少部份的工作，甚至只有一兩項工作的進展不如預期、甚至是大大落後，但因為這些工作落在專案的關鍵路徑上，使得它們變成了專案進行的瓶頸。

對專案的瓶頸的關心與努力加以解除，是專案進行時最重要的事情之一。因為，即使絕大多數的工作都能準時完成，只要專案的瓶頸上發生了延遲，整個專案就會跟著延遲。所以專案中的工作，對時程而言，並不是完全等價的。

也就是說，有些工作發生了延遲，並不那麼要緊──只要它不會因為發生延遲，而成為專案進行的新瓶頸。相反的，有些工作只要一延遲，專案立即會跟著延遲，所以，它們必須被格外注視、付出更多的關心、以及盡最大努力規避它們可能會遭遇到的風險。

當程式開發工作過程遇到阻礙
在我們過去的討論中，對於程式設計者完成工作的方式，多半集中在他自己在接到工作分派之後，自力把工作完成。當然，有一些撰寫程式的方式，像是「搭檔編程（pair programming）」，是由兩位程式設計者，分別以不同的角色一起合作，來把程式完成。不過，我們很少討論到，如果程式設計者覺得自己對於完成工作遇到了很大的障礙，不僅可能無法如期完成，甚至根本無法完成時，他應該要如何處置？

很多時候，他是需要「求救」了。不過，「求救」在程式設計者的圈子裡似乎不是一個普遍的風氣，在網路的論壇上，你會時常看到有人求救，不論是學生在求救作業，或是有些開發者尋求解答自己的問題。可是，在我的經驗裡，很少遇到辦公室裡的同事，會在他的工作遇到問題時，向其他的同事尋求協助。

大多數的人，即使遇到了難解的困難，也多半是兩種模式：第一種是依舊默默地自己在這個問題上奮鬥，希望自己終究能夠把問題排除；而另一種，則是因為受困已久，乾脆放棄，當起了把頭埋在沙裡的駝鳥來了。

在第一種情況下，程式設計者可能最終可以解決問題，但是會花去很多的時間。他也可能始終無法解決問題，使得工作的完成遲遲遙遙無期。而第二種情況更糟了，他根本放棄解決問題的努力，甚至可能造成逃避，因而不想面對工作的負面心理狀態，進而對工作產生了倦怠感。

無論是那一種情況，都不是我們所樂見的，因為它們對開發來說，都會造成影響，尤其當工作正好是專案的瓶頸時。

而即使這樣的情況，不是發生在專案的瓶頸，也有可能因此而使得它們成為了專案的新瓶頸。一旦它們成為了瓶頸，那麼，正如本文一開始所提到的，對專案的影響就不言可喻了。

為什麼不找人幫忙？

追探大多數我們在同一個開發團隊的成員，之所以不「求救」的原因，或許有一部份是因為「羞於啟齒」。

的確，似乎有一種既定的想法，是認為，如果你不能完成你被交付的工作，那麼，很有可能就意謂著你的能力有問題。大家都不願意被同儕覺得自己能力不足，所以大家都不願意開口。

此外，還有一種情況，便是不希望自己的工作拖累到其他人，所以寧可自己多花時間，也不希望造成別人的負擔。

還有一種想法也很常見，程式設計者覺得自己很有機會可以完成工作，只要再努力一些，所以一直沒有鬆口向他人求助，希望整個工作是百分之百在自己的手中完成。

但是，倘若，遇到了的確會構成障礙的問題，甚至使得工作成為專案中的瓶頸，那麼對專案就會產生整體性的影響，反而更為不利。即使向他人求救，會使得其他人必須分出心力出來協助你，暫時影響到他原本就在進行的工作，但是，從專案整體來看，如果你的工作本身就是瓶頸，或是即將成為瓶頸，那麼，你的工作能否早點完成，對專案來說，就比其他人的工作能否完成更為重要。對整個專案而言，寧可撥出其他工作的人力，也要讓你手上的工作盡快完成。

此外，在工作上努力不懈、永不放棄是美德沒錯，但是，還是要著眼於整個團隊的利益，過度堅持自己不假手他人，卻影響整個團隊的努力成果，並不是一件值得高興的事情。

而求救也不是一件可恥的事情，發出訊號，希望團隊中的成員伸出援手，是一種互相協同合作的精神。每個人在做事上都有盲點，也有可能被交付了不適合的任務，當實際執行發生困難時，還是需要別人的協助。

求救是為了團隊，如果你受限在上述的三種心理狀態而不願意求救，如此反而是失去了團隊合作的精神。

求救的文化需要建立
在過去經驗裡，真的遇過不少其實在工作上遇到障礙，遲遲無法完成，但是又不願意向他人求助的情況。

而這類的情況，時常導致檢查進度的時間點到時，大家才發現他的工作沒有完成，而且即使錯過了時間，他也很有可能隱瞞自己其實還沒有把握可以解決掉目前所遭遇到的問題，只是重新估計了一下時間，像是「大概再三天就能夠完成」之類的。

正因為隱瞞了自己的困境，反而使得情勢的演變更為惡劣，最後愈加嚴重，直到紙不包住火為止。但到了這種時候才知道，要挽救，往往已經不是那麼容易了。

因此，讓團隊建立「求救」的文化其實是很不錯的一件事，首要第一步，便是讓成員勇於在需要求救的時候，向他人發出求救的請求。接著，什麼時候需要求救呢？

當然也不是一遇到困難就求救，我認為，有幾種情況是值得請求其他人協助的：（1）對於完成工作目標完全沒有頭緒──也就是卡關了，不知道接下來如何著手。（2）因為技巧或熟悉程度的問題，進度與預估的時間有很大的差距。(3)程式中有臭蟲，但是遍尋不得，需要有人突破自己思考的盲點，來協助除錯的工作。

除了遇到障礙的開發者本身遇到問題可以尋求他人的協助之外，其他的成員也可以透過各種途徑來了解自己的同事是否遇到了什麼困難，像是平常中午一同外出用餐的閒聊機會等等。而專案管理活動中的進度審查，也是協助專案管理者了解、評估開發者是否遇到了需要援助的情況。

進度審查的目的，除了了解實際進展和預期的差異之外，還有一個重要的作用，就是評估開發者是否遇到了難解的困難或障礙、需要提撥額外的人力來予以介入協助。

總的來說，我們所在的社群缺乏同儕之間求救的風氣及文化，因此必須鼓勵大家這麼做。但是，求救並不意謂著你持續依賴他人，只要遇到了問題，不管問題的大或小，都希望別人替人協助。

畢竟這是一個團隊，大家是在互相合作的基礎上前進，沒有人會喜歡一個處處依賴人的伙伴。即使你在一個工作上尋求了他人的協助，在求救之前，你也必須自己也盡力了，而且在他人協助你的過程中，也有所得、有所成長。這麼一來，才不會造成團隊中強者恆強、弱者恆弱的情況，成員的實力才有機會愈來愈接近。