IDEA #317：食懵你成功法則(二)

網上看一篇關於將八十二十法則用於工作的文章。論點很"大路"，都是說只要用百分之二十的時間，便能夠完成百分之八十的工作，之後的百分之八十時間便可以用於改善質素方面。

一直以來，我對八十二十法則都有所保留。問題在於：

1. 此法則不能同時應用於一個組織中的所有範圍
2. 它沒有考慮問題的關聯性

一個具體例子。我們公司的系統開發，都是基於八十二十法則，先盡速完成主要功能，然後(打算)進行改善。不過，現實是銷售推廣做得很早，客戶急得要命，百分之八十的時間是要將那完成度只有百分之二十的產品硬推出市場。結果可想而知，就是客戶服務部在高層會議上不停被"插"不能解答客戶疑難。

對客戶服務部來說，那完成度只有百分之二十的產品，也就是那"失去的百分之八十"，"造就"了百分之八十的投訴和不滿，佔用了同事百分之八十的時間，即使這些客戶只占百分之二十。銷售部門賺錢，然後客戶服務部"燒錢"，組織的整理營運並無法得到改善。

此外，個人認為八十二十法則不適用於系統開發。軟件是個複雜系統(Complex System)，組成部份之間聯繫緊密，早期設計的適切性非常影響後期工作。只用百分之二十的時間設計和生產，也就無法透徹考慮設計的影響；資料庫架構訂立了以後，也很難修改。

一個簡單的例子。你要設計一個用於管理員工出席情況的系統，在八十二十的要求下，沒有時間詳細分析需求，為求儘快出貨，你決定以半天為單位去管理員工職務編排。然後，所有系統功能和報告，都基於這個精度進行設計和編程。

結果，大部份的客戶都對系統感到滿意，怎料最近有客戶詢問有同事不適早退兩小時，不知如何處理。由於系統的基礎是以半天為單位進行資料處理和運算，兩小時不是系統可以處理的精度。客戶服務部只能用一個婉轉的方法說"不支援"。

因此，八十二十法則似乎只有在工作幾乎可以從任何地方開始做，和在一個組織嚴密性低的處境(如個人)下，才能適用。像系統開發那樣，後工序取決於前工序，客訴多少取決於功能是否完善的環境中，八十二十只是一個"食懵你"的法則。


=======
後記：
最近在開發in-house的內容管理系統，情況亦一樣。雖然在現階段，無需以單字或句子為單位，管理文字內容(其實同一個詞語各地用語不同，已經是一個很典型的使用例子)，但我還是以可以做到此，作為設計目標。雖然有點用電鋸切菜的感覺，但基於"系統精度一旦定了，便不能提高"此一法則，一開始便要用最高的精度去設計。

不明白的，會說是吹毛求疵，浪費時間；明白的，會知道這是爲了可持續發展著想。下一次，會以iPhone和iPod Touch的宣傳資料為例，說明為什麽要以單字和句子單位管理內容。