專 案 管 理 輕 鬆 學

(開始前，請先看完原文)

有人說有 bug ：「26 樓會議室的燈亮著，去關掉。」
bug 裡有個提示：「這應該只要花你 5 分鐘，不過就是關個開關而已。」
你來到了 26 樓的會議室，燈開著，但環顧四周，你找不到燈的開關。
因此你打算自己裝個開關，但設計師卻過來告訴你說這會毀了整個房間的美感。會議室牆壁是水泥做的，如果用適當的工具，你可以很快裝好這個開關，但沒人會核准你去購買這些工具；而沒有這些工具，安裝這個開關至少要花上兩天。但他們卻又又要求你馬上解決這個問題，因為他們怕 CEO 心血來潮來 26 樓逛逛，剛好經過會議室時問道為什麼燈是開的。
這時候你開始接到 email，問你為什麼燈還是開的。
所以你現在必須停下工作，寄一封群組 email 解釋你的情況，而開始了一陣恐慌。
你知道光是在電子郵件上討論不能解決這個問題。這個 bug 標記著你的名字，也標記著今天的日期，所以要是今天沒解決，有麻煩的會是你。因此你爬上了會議室外走廊的天花板夾層裡，找到連接到會議室的燈的電線，並一刀剪斷。終於，問題解決了。
為了平息 email 串上的恐慌，你回報你解決問題的方法。
平靜了一陣子之後，大家開始關心接下來沒有辦法再開關會議室裡的燈。要是 CEO 想要在那裡開會怎麼辦？因此，他們要你把電線一路接到地下室，當有人想要開燈或關燈的時候，他們會找你，而那時候你就得跑下去地下室接電線。
你對你的老闆提出抗議，但他只說，「是啊，我了解這個情況並不理想。但這是我們目前唯一的解決方法。」
走到這步田地，你了解到你只有兩個選擇：要嘛聽他的繼續做，要嘛不幹了然後再去找別的工作。但你馬上想到，就算你換了一個新工作，新老闆還是非常有可能叫你做些同樣愚蠢的事情。
所以你硬著頭皮把電線從 26 樓一路接到地下室，當你抵達地下室時，你看到一叢紊亂的電線從牆壁中竄出，你立刻了解到那些是前人的傑作（現在你瞭解到把電線拉到地下室這個想法是哪來的了）。
你拉好電線，一一貼上標籤，並留下一張簡短的便條，向下一個被指派處理這些電線的人道歉。
你回到你的座位上，你發現有人留了通訊息給你。QA 又通報了同一個 bug：「我看到燈亮著。」
你跑回26樓的會議室，燈是關著的。你再一次回到你的座位上，然後把這個 bug 標示成已解決。
QA 又一次通報了這個 bug。「房間是亮的。」他們說。在你再次去查看那關著的燈泡後，你去找你的老闆，他卻叫你去檢查地下室的電線。你抗議你正看著那個燈泡而他確確實實是關著的。老闆告訴你，「我了解，但你這樣就能告訴 QA 你完全檢查了每個地方。」
你回報給 QA 說你檢查了燈泡也檢查了電線，一切都沒有問題，線沒接著，燈是關的。
「我沒說是燈泡的問題啊」QA 如是說，「我說有 bug 是指房間是亮的，那個房間太亮了，你不是應該拉上遮簾嗎？」
你反應遮簾不在你的管轄範圍內，而且 bug 指明叫你把燈關掉。
在跟你不相信你的情況下，QA 寄了一封群組 email，詢問遮簾是否屬於 bug 的範圍。
過了好一陣子之後，一個來自 email 串的人打了通電話給你。
「理論上來說，」他們問，「有人要在26樓的會議室開會時，覺得房間太亮或太暗了，他們能夠自行開啟或關閉遮簾嗎？」
「可以。」你回答。
「我的意思是，如果是一個一般人呢？他們不需要問你就能知道怎麼做嗎？」
「是的，一般人可以，不需要問我。任何人都知道怎麼做。」
「太好了，非常好。那我們就先這樣。我會再安排一個站會跟大家討論遮簾的問題。」
好了，這個 bug 解決了。但在聽到諸多關於26樓的會議室的討論後，現在 CEO 想要在那裡開會。你收到一堆恐慌 email 告訴你他們需要開燈。
你到了地下室，接好了電線，回到你的座位上，然後發現迎接你的是 32 封新郵件。「出錯了！燈關著！」「這裏有問題！燈沒開！」「你到底有沒有看到我們寄的 email？」
第32封郵件：「沒事，燈開了」
當要關燈時，極為類似的過程再次發生。
但好消息是，在那次會議後，每個人都忘記26樓有會議室了，所以你也不用再管這個問題了。

1.bug 裡有個提示：「這應該只要花你 5 分鐘，不過就是關個開關而已。」

這是一句身為工程師最常聽到的話，也是十分忌諱、十分容易惹怒工程師的話。這句話的出現有三種情境，第一是這個bug可能真的很簡單，提問者也很清楚，所以直截了當對工程師提出需求。第二種情況是提問者依自身(或過去)經驗來推斷時程，第三種則是提問者毫無根據，只是希望問題及早解決而已。第二和第三種情況都是缺乏對問題本身的細膩觀察，因此沒有事先釐清當下遇到的問題和以往是否有所關連，貿然就定下預定的時限，這點不論在時程管理，甚至是溝通管理(沒有和工程師協調討論)上都有極大的錯誤，與其如此，還不如單純回報bug就可以了。

當然，在非工程師的觀點中，會擔心對方對bug的修復時間沒有具實以報，所以才會事先給予時限，但溝通是一種雙向的行為，除非對方是慣犯，否則保留一點空間讓工程師能夠評估後提出看法，對未來持續合作才有幫助，否則你可能就會得到"剪斷線路"這種無厘頭的解決方案。

2.如果用適當的工具，你可以很快裝好這個開關，但沒人會核准你去購買這些工具

這是一個非常現實的問題，經常和公司的組織關係及管理文化有關。某些小型企業沒有適當的權責分配，大小事通常都得經過老闆才能決議，但老闆卻不會花心思去聽工程師說明購買工具的理由。而稍具規模的公司，又經常樹立過多的權核機關，導致我們也無法說服層層主管去完成一個臨時性的採購。不過話說回來，就經濟效益而言，若只是解決像26樓會議室的燈這類小雜事，確實也沒有核准採購的必要，除非這個工具對於整座大樓的線路配置有極大影響，但這通常又牽涉到更全面性的架構重整，不花個半年一年是很難達成多數共識的。

3.你看到一叢紊亂的電線從牆壁中竄出，你立刻了解到那些是前人的傑作

我曾經有個這樣的經驗，大老闆是一位頗具遠見的領導者，他對旗下某業務十分有熱忱，經常隔空抓人處理各種臨時的決策，導致底下兵荒馬亂，無奈公司系統龐大缺乏有效管理，長年疊床架屋已經行動遲緩，所以大家通常只求不要出事，並不斷再疊床應付需求。還有個朋友，在一家新創公司上班，老闆仗著創業家衝鋒陷陣的幹勁，不斷開發新產品，在新的時間壓力不斷逼迫下，許多系統只好層層堆疊，直到最後他自己受不了離開那家公司，據說後人也只是維持系統運作，從此不再有新的服務了。

疊床架屋的情況，若發生在特定工程師身上，那麼代表個人技術能力有待提升，需要部門主管嚴加監控，並適時給予矯正。如果發生在單一部門，也許該借助外力或更高層主管介入，但若不幸發生在大部分的環節上，那麼就很難由底層工作者去挽回了。

4.「我沒說是燈泡的問題啊」QA 如是說，「我說有 bug 是指房間是亮的，那個房間太亮了，你不是應該拉上遮簾嗎？」

品質管理是一道重要的關卡，通常也代表著這家公司的精神文化，如果對品質要求甚低，那麼連帶其他環節都有可能出現道德上的瑕疵。品質管理中的品管流程，是針對成品進行抽樣性測試，並回報給相關單位修正處理，但如果回報不確實，就會造成其他單位的困擾。為了減少雙方溝通上的歧異，有時候制訂制式的表單是有其必要性的。

5.你去找你的老闆，他卻叫你去檢查地下室的電線。你抗議你正看著那個燈泡而他確確實實是關著的。老闆告訴你，「我了解，但你這樣就能告訴 QA 你完全檢查了每個地方。」

有時我們為了引出對方的真正需求，常會需要做一些"看似理所當然"的實驗，並將結果回報給對方(通常是客戶或老闆)，藉由這個動作，一來告知對方我已經仔細處理這個問題，表揚自己的工作細膩度，二來是希望他正視對話，提出真正的想法或需求，我過去在處理課訴時，就經常使用這種方式。對工程師而言，如果只接收到檢查地下室電線的指令，當然會做得不情願，但若能理解背後的意義，或許就能釋懷一些了。

6.QA 寄了一封群組 email，詢問遮簾是否屬於 bug 的範圍

一般來說，專案開始前都會先定義各角色的權責(俗稱R&R)，若有爭議則可以藉由權責分配表來釐清，當然，若是遮簾這種顯而易見的問題，理當由團隊成員本身或專案經理就可直接裁決，無須再大費周章告知全體，由此可見26樓會議室的權責分工並不清楚(或者甚至不該有這個專案，純粹為了迎合老闆而來)。

7.「有人要在26樓的會議室開會時，覺得房間太亮或太暗了，他們能夠自行開啟或關閉遮簾嗎？」

很遺憾的，這類白癡的問句總是經常出現，而它的通常有兩種可能，第一是問的人真的很無知，第二是有人刻意要留下證據，為每一件經手的工作做紀錄，以便日後究責。

8.在那次會議後，每個人都忘記26樓有會議室了

這和bug發生時，email成串寄來的情況相呼應，也讓我想起"急迫/重要"象限表，它的說明是這樣的 : 多數人把大部分時間都花費在急迫但不重要的事情（第三類）上，但其實，必須懂得捨棄第三與第四類工作，並對第一類工作盡量節制，保留更多時間在重要但尚不急迫的事情（第二類）上，例如建立人際關係、規畫長程目標或防患未然等，這樣，才能掌握重點，重要事務才能一一完成，避免自己每天匆忙又疲憊。

話說回來，大老闆臨時丟下來的工作，通常是屬於哪一類呢?

圖片來源：經理人雜誌

作者：Victor

Blog：http://victorhsu0202.pixnet.net/blog