【寫在前面】
來源包括親身見聞、與口耳相傳。因為實在太經典了，不得不闢一專欄來記載。
首先， Id-Triggered 是什麼意思？
凡是需要該部門協助的事項，僅僅透過電話、email、或者是禮數最周到、人親自跑到他們面前要求，對方都不動於泰山，一定要有 BugID 才可能「納入考量」。注意！只是把這個 ID 排到他們滿滿的 schedule 當中，不代表何時完成。
說穿了，他們是很有原則、超有原則的單位。比公家機關、甚至軍隊都來得有嚴謹的紀律，不論你是皇親國策，一概都要 follow 他們的規定行事。
這些規定怎麼來的呢？簡單，當然就是該部門的主管囉。有她在，天蹋下來都有人頂！真是夠硬頸的主管！
他們的處事優先順序為何？很多人霧煞煞，其實很明白。
- S 優先。謂 S？主管的話最大嘛！
- 還是 S 優先。不過這個 S 是 showstopper ID。
意思是緊急到必須打斷目前的工作，先行協助處理的事項。 - 才是一般 ID
- 那來自電話、email、當面講的 request 呢？
那是什麼？沒有這一條！誰規定 email 一定要回？！
【經典一】
只要跟對方開會，粗估有二至三成的時間，大家都要必恭必敬，全心傾聽她訴說自己的辛苦，每天忙到三更半夜，幾乎等於以公司為家了... 要不然就跟老闆說不幹了！
於是乎，如果大家遇到不爽，就可說：「我不幹了！」然後不用真的付諸行動。
【經典二】
「user 的 request 不是我想做的！」
【經典三】
該部門用心研發一項產品，demo 給 PG 單位看時，聽說現場的主管都傻眼！PG 主管挑明地說：「你們做好我們也不會用，因為根本不是我們要的」對方面有難色地回答：「這樣我沒辦法回去向主管交待」PG 主管當場暴跳如雷。聽說，這是他第一次在公司如此發飆。
是什麼樣的東西讓人血脈賁張呢？用 Excel 做 cronjob 要在 unix 上使用。
【經典四】
某經理反應問題，email、電話中已清楚明白地跟對方部門溝通應該如何做。沒想到幾個禮拜之後，事情依然懸著未解！使用者單位主管抓狂了！這回走「正規要求」管理，發了 ID，質問對方都已知該如何處理，卻因何未行動？對方回：「某大主管，我們很忙，你能不能處理？」
對對對！大主管都是閒閒美代子。
【經典五】
有個 ID 晾在那，一年多了，R&D 問進度如何？對方經理答：「這個 schedule 要再安排」到底是多大的需求呢？要改很多東西嗎？答案是，只需改一行。
【經典六】
另外又有個 ID，擺數個月了，這位經理可能在做清倉大掃除，急著想把 ID 清掉。問 request 的主管：「這個問題不在我這裡，是另外什麼的問題。我能不能 close 這個 ID？」（其實另外什麼的問題，也是他們部門理應解決）隔天對方迅速回應：「不行！對我來說，東西都還不能用，怎能 close？！你把問題轉給能夠處理的人」稍候，這位經理又回：「跟 S 經理談過，需要誰的幫忙。那個誰，你看一下」
真是「有效率的自動化」流程啊！該部門實在非常尊敬他們主管，凡事必定過問再行事！軍隊的紀律與要求，也不過如此爾爾！
由於過於「磬竹難書」，必然有遺珠之憾！咱們以後隨時補充。
Orignal From: Id-Triggered Department 精采語錄
