(五)
上回講到， User Requirement Change 同 New Request的多寡，決定了項目能否準時完工收錢，是一個項目最關鍵同難搞的地方。作為項目經理，最重要的能力，就是控制User的期望值，儘量減低用戶的新需求。
然而，User文明的一面，常常是放工後才表現出來，我們無福消受。 User 的本質善變，部門的本質是溝通不足，互相推委，Requirement 天天改，Project 日日 delay。一年完成的project, 可以做3年，錢冇得加，反而遲交仲要罰錢。 S.I 果是天下最難撈的行業。
遇著捉細節的 User, 更慘。
講番Project B吧。
Project A 的項目經理雖然能幹，可是，公司要打響頭炮，不能得罪第一個客，於是選擇做Yes Man，注定將大船使入地獄！
客戶的代表用家(即係負責測試的同事，而不是最終用家)，非常挑剔，應該說，他們當中有一位同事A君，非常挑剔，非常Outspoken，佢上司也傾向接受他的提議。
A君是一位典型的完美主義者，做事快手有幹勁，非常為東家著想，於是，他找出了很多比原先設計更好的方案，包括流程(page flow)、介面等。
(六) 以快打快，累極而亡
在測試期間，我最高峰期一天接他30多個bug report, 當中一半, 是介面上的問題，約1/5，是功能改動的建議，其他是Bugs。
通常，一批Bugs 來了，我條Team修改，Turnaround大慨是 2-4天，最初，為了爭取表現，我一直想將Turnaround 的時間縮短，希望客戶了解我們做事的效率，到後來，試過即日Fix好再比A君 試。
我最記得有一次，我拉捺不住，將我們改好的Bug List，輕輕向A君桌面擲去。結果他不但不怒，反而是即日下午試完，再將File 輕輕向我桌面擲去！
Shit，完來佢要同我鬥快！我改得愈快，他挑的問題就愈多愈快。我乃野了！對付這種人，其實應該不要太快，因為他是客戶佔上風，你寫Program需要大量時間，同佢鬥快，肯定佔下風。當時年少氣盛，沒讀懂莊子，不知道生有涯的大道理。
今天回望，總結八個字，就是：以快打快，累極而亡！
乃野的，還有另一樣。
當時由於客戶濫發Bug List，驚動了上頭，我老頂於是同客戶傾掂數，給幾天時間，客戶試，但不入Bug List, 而我們答應以更快的速度修改，結果…Bug List 一樣雪花般飄來，我們只是做得更累。
其實，在客戶的立場，跟本無需要比面你…佢對你愈刻薄，其實可能愈容易升職！
如果對家的同事，是合約制或項目制員工，更大鑊，因為項目拖愈久，他們的飯碗就愈穩，這樣的客戶一般表現為油條，喜歡打太極，要對付呢挺人，一定要越級同佢大佬講數。
但我當時未去到呢個級數呢，所以結果只能每天930-930地工作了。
結果，Project A 的 第一期，比原定時間遲了足足 6個月才完成。
如果公司要靠 Milestone Payment 開飯，早就執笠了！