"劉潤":http://blog.run2me.com/runliu/archive/2006/01/17/13351.aspx
微軟在上海以前是有食堂的，外包給外面的餐廳，負責給員工供應午飯、晚飯。問題有兩個：1）眾口難調，400個人的飲食很難大家都說好，需要多樣化；2）很難控制飯菜的成本、質量，供應商很有可能以很低成本賺取過高利潤。微軟行政部的幾個小女孩就商量出一套供應商管理方法，讓我刮目相看。這套方法其實非常簡單：
1）增加到兩家供應商，一家提供午飯，一家提供晚飯；
2）每三個月對員工作一個調查，瞭解員工更傾向於哪家供應商；
3）讓員工喜歡的供應商提供午飯，另一家提供晚飯。
吃午飯的人數大大超過晚飯，所以兩家供應商都非常希望供應午飯。供應商清楚地知道還有另一家競爭對手，而做出判斷的是吃飯的員工。為了更大的利潤，供應商必須在合理的利潤空間中提供最能讓員工更加滿意的飯菜。我於是看到了供應商請人為員工打湯，做隨機調查，逢年過節提供特別食物等等~~~
行政部只是設立了一套規則，卻有非常好的收效。就是這種神奇的力量。
我很喜歡閱讀這種發生在實際生活上、職場上的小故事。有些問題根本不需要很複雜的處理方式，就能夠輕鬆解決。最主要的癥結點在於 "Focus on Problems vs. Focus on Solutions":https://produsir.synology.me/wordpress/2005/06/10/723 。
隨時都有「路上的石頭」和「學習的黑盒子」，你可以選擇用力去搬掉它或努力搞懂黑盒子，也可以選擇繞道而行，日後再來解決它，或許屆時問題已經迎刃而解。
如何選擇？端看你覺得當下什麼才是最重要。
■ 延伸閱讀：
"管理上的時空錯亂":http://home.wangjianshuo.com/cn/20050801_ccaecceae.htm (推！)
在微軟的時候，有一件事讓我印象深刻，啟發我在動手建立複雜的IT系統之前，先想一想「自己要完成的目標是什麼」，而不是「自己要建立的系統是什麼」。這件事就是「英文潤色」服務的流程。
可靠的英文潤色服務
事情是這樣的。微軟在上海的全球技術中心同時服務微軟美洲和歐洲的客戶。為了保證所有工程師寫出的英文的郵件不會有太多的語法和使用習慣錯誤，技術中心建立了「英文潤色」團隊，全是由英文是母語的人員組成，來幫助工程師修改發出的每一封電子郵件。任何人如果對一份英文的郵件不是很有信心的時候，發信到一個email地址（Distribution List），就可以保證在30分鐘以內，得到修改的結果和避免此類錯誤的建議。每次回復的可能不是同一個人。
這是個不錯的服務，我就經常用，對提高英文寫作大有幫助。團隊保證的30分鐘回復的「服務質量」幾年來沒有有過差錯。那個團隊對於用戶就是一個黑匣子，當一封郵件過去，必然會有一個人（且只有一個人）在指定的時間裡回復。
支撐的IT系統？
我一直以為，他們應該有一個IT系統，把所有發到那個email地址裡的信件放在一個隊列裡面，所有的老外到那裡去「接」郵件，並把這個郵件的「所有人」的狀態改成自己，之後完成審閱，回信，並把狀態改成「完成」。。。「一定是這樣子的」，我拍著胸脯說「要不然，將近十個人看同一個郵箱的信，豈不亂死了？更不要說保證每一封信都30分鐘回復了」。
大家想想，如果你來設計這個系統，會怎麼做呢？
神奇的規則
真實的情況出乎我的意料。其實，根本沒有任何的IT系統，所有人用的是同一個email賬戶加上一個規則。規則是這樣的：所有的人同時收到所有要閱讀的信，從上班開始每5分鐘為一個時間段，分配不同的人來值班。比如，9點到9點05是Tom，9點05到9點10分是Jack，依此類推。。。每個人只處理自己郵箱裡落入這個5分鐘的時間段的信件，其他的都忽略。接到以後，後面的25分鐘裡面回復前5分鐘的信。25分鐘之後，進入下一個自己收信的5分鐘。理論上，6個人一班，每半個小時一個輪迴。而5分鐘裡面的信件，每個人自己安排，保證在下一個5分鐘到來前的25分鐘內回復完畢就好了。
就這樣一個簡單的規則，省去了IT系統的成本，省去了溝通需求，以及維護的成本。一個簡單的規則，運行到現在5年了，它就那樣簡單而可靠的運行著。
這種不用IT系統的方式，在參與的人員少於20個人員變動不大的情況下，是非常合適的。隨著郵件量的增多和人員的增加，大不了把時間間隔由5分鐘便成4分鐘，或者3分鐘就好了。在可以預料的將來，這種方式對於這一種特定的需求還是可行的。
這是聰明的做法。
專業的解決方案不見得是最佳方案
這樣我想到之前聽過的幾個故事，同樣講了專業的解決方案不見得是最佳方案的道理。
一個城市建了一個容納幾萬人的體育場，而周邊的道路還是以前的小路，散場的時候潮水般的人流，導致周圍交通癱瘓，不能迅速疏導。專業的市政規劃的人員，會給出大規模拆遷，投入巨資拓寬道路的建議，而後來採取的方案居然是在每次比賽結束後，都接上一個小時的文藝表演，這樣人流就會分散，緩慢的離開，道路不變，卻不會堵塞。而城市裡的藝術家就有了一個新的展示自己的機會，雙贏，多贏。。。
同樣聰明的做法是寶鋼解決千年蟲問題。專業作法是更換所有設備，保證它們都是兩千年兼容，而實際的做法是，把所有系統的時間統一向前調了50年，然後改變一下和顯示以及打印相關的系統就好了。
註：真不想提這個嚇唬人的千年蟲問題了，現在想起來，很多事情非常可笑。當時微軟最戲劇性的一幕是，我的師傅等一行來自各種產品組的20多人在1999年12月30日，坐火車到了北京，以保證萬萬萬分之一的機會，上海因為千年蟲問題通信中斷，停電，停水，在北京還有幫助亞洲其他國家應付服務器災難的人員，而我們則守在美羅大廈裡，等著太陽從愛爾蘭開始一個時區一個時區的向上海掃過來。。。時刻等著那可能的「災難「。那真是一場瘋狂的全球party。
「專業」的解決問題，往往會花費比實際要高，因為專業人士的視角不夠廣闊，會忘記了自己所在的時間和空間，忘記了「借力」和「過猶不及」。
上億的服務事件？
我經歷過一個反面例子。2003年在建立微軟全國的服務渠道的時候，我們建了個系統，記錄所有客戶提交的問題。這個系統的第一版建的非常的正規，所有的表都用大學課本裡教的第一範式，第二範式，直到Boyce-Codd範式規劃。內鍵外鍵齊全。但改動起來非常困難。我問道「這個地方為什麼不能這樣做？」答曰：「為了性能考慮，我做了限制。你想想，如果這張表裡的記錄數超過百萬，千萬，甚至上億的時候。。。。」我驚訝的說：「從業務的角度考慮，這可能嗎？如果真得到你說的量，說不定要付的錢都超過上海的國民生產總值了。。。」後來證明在當時的環境下，還是一個對性能沒有要求，但是簡單明瞭，隨時可以更改的系統用起來順手。軟件系統應該是有生命週期的，用牛刀殺雞，常常是把雞假想成牛了。
管理上的時空錯亂
最近管理的書很多，大多都是美國大公司的寶典。我看，可以參考，但不要全搬。美國的大企業是駱駝，個頭大，掉頭慢，耐俄，七天不吃不喝也熬得過去。中國的小公司，尤其是創業性公司是兔子，靈活，調頭快，但一天不吃估計就沒有機會活到吃下頓的那天了。所以書店裡講戰略，講「專業精神」，講「系統思維」等等的書，是為駱駝在它所在的環境準備的，不見得會對兔子有指導作用。CMM好，但不見的在中國軟件企業裡有用，就是這個道理。以前走訪的每個軟件園，講到微軟的開發流程的時候，大家都會問一個問題：能講講微軟還是小公司的時候是怎麼做的嗎？現在想來，問這些問題的企業老總都是頭腦清楚的，知到什麼東西可用，什麼東西只能借鑒。
把管理成熟公司的做法拿來管理創業公司，這就是時間的錯亂；把管理美國企業的方式拿來管理中國的企業，這就是空間的錯亂。
註：晚上接待來自《互聯網週刊》的記者陳瓊，地點還是濱江星巴克，陳瓊走到了正大廣場下面新開的那一家。估計從地鐵裡出來以後，大家八成會以為那裡就是濱江店，以後要講清楚才好。
注二：週末開車在杭州度了週末。杭州是個讓人心靜下來，腳步慢下來的城市。我驚訝的發現杭州的創業家精神在某些程度勝過上海。這是個值得經常來的城市。。。
