看清制約條件

RUN!PC 月刊　文／彭靖灝（K2.net大中華區技術總監）

兩個星期前到香港支援一個案子，找了一位同事陪同。原本並沒有計劃讓這位同事前去的，只是成行的前一個晚上，臨時想要透過和同事一起拜訪的過程中，看看這位同事會怎麼表現，同時也借助他熟嫻的技能，減少準備的時間。我們花了一個多小時的時間，決定展示的內容，然後準備好展示環境，同時把展示錄成影片。簡單的影片展示一方面時間很好控制，不想看的可以直接跳過，也比較不容易發散要討論的主題(把討論的重心放在影片本身，而不讓客戶預期可以要看什麼有什麼)。

整個討論的過程堪稱順暢，結束之後，我們找了個地方坐下討論下一步行動。在要開始討論之前，我先就我的筆記做一個整理，條列出我認為後續延伸的展示應做的準備，以及展示的情境。在說明我的要求前，我讓同事先陳述他設計的情境，他很用心(但臉帶愁容)的說明應該展示的內容，包括如何做到自動更新、版本控制…。這個時候我中斷了他的說明，提出一個問題：「按照你設想的情境，你全心投入準備，要多久時間？」他回答：「十天」。我笑一笑：「所以接下來你有十個整天可以做這件事嗎？」他搖搖頭。「所以我們下一步要展示給客戶看，那會是一個月後的事了，因為我們要在零碎的時間上去湊出十天完成。」

我開始說明我的情境，並且強調這個情境中要展示的幾個重點。相較他的想法，情境的內容簡單了很多，重點也很清楚，就只有三點。之後我接著問：「按照這樣的情境，你可以在接下來的一週找到空餘的時間完成嗎？」他的答案是肯定的。「所以投入的時間不會是五個整天？」答案也是肯定的。「所以若是以這樣的情境去準備展示的內容，下週四之前可以完成錄影檔給客戶參考嗎？」答案還是肯定的。

在這個過程中，呈現出我和這位同事思考順序上很大的不同。他在一開始聽客戶的述說時，就已經按照客戶舖陳的順序，去編排他認為要建立的「完整」情境，而未花時間去篩選這當中的重要性。做為一個技術人，他很在乎「如果做不到，客戶可能就不會認為我是個專家了」。於是為了能在「客戶期望的時間點」提交「我們編排出的完整劇情」，我們開始不眠不休，日夜趕工。事實是，這當中可能很多細節都是客戶有提到(甚至沒提到)，但其實不是重點，做了客戶不會特別讚揚的事情。

我和這位同事思考方式上不同的地方是我認定整件事最重要的制約條件是時間，於是我從時間內完成工作的角度去思考工作的內容。這讓我在完整性上必須做出取捨，並且更精準的抓到重點。就是這樣一個順序上的差別，一個看似不可能達成的演示(因為時間的限制)，成為可行。最後的結果是，一週後展示的影片出來了，這位同事同時也完成了其他原本要完成的事情。對他而言，這是一個難得的經驗，也是一個很有成就感的經驗。

技術人，很容易鑽進胡同，有些時候，跳出來，調整一下，整個結果會完全不一樣。看清楚制約條件，然後回頭去做正確的安排。