設計的通則？
- 關於留後路這件事，事實上只是當時提出的眾多考量「其中之一」而已，他當時也有從「可延展性」以及其他諸多方面去思考而給出那樣的意見。
- 另外「只把資料庫單純當作資料倉儲」這樣的想法則是來自另一位不同的同事，並非出自同一人。
- 為了讓文章聚焦，避免模糊焦點，我將來自不同人物的意見合併在一個代表人物上，並且因為當時對於「預留退路」這件事情特別有感觸，所以在撰文時將其他無關該主題的意見通通割捨掉，實際上是「斷章取義、以偏概全，與事實不符」。
簡而言之，這個網誌是為了記錄針對 IT 領域，個人對一些議題當下所激發的想法，並非為了留為呈堂證供，留作法庭審判用途，所以對引論中心思想無關的情境事實和前因後果，會過於簡略帶過或變造，以便撰文時可以流暢表達最重要的想法。
前天跟同事喝咖啡，針對我上一篇文章，又聊到有關『設計與開發的通則』這個話題（真的很感謝有這麼優秀的同事們，不斷激發我回顧和重新審視一些觀念和想法，讓我一直在不斷的碰撞中找到成長的方向）。我們的工作之一，除了上一篇提到的內容外，還有提出「Development Guideline」。
曾經，問過主管，我們提出的這份 Guideline 只是一個可以被 override 的 suggestion，還是必須強制遵守的 Commend？我得到的答案是後者，這讓我對於給『通則』這件事情起了相當的顧慮。Guideline 的存在幾乎都是來自於管理面（Management）的需求，管理面的理由一開始都可以講得冠冕堂皇，說是為了加速效率、減少溝通成本、維持一定的品質。但是我們再看深入一點，這是讓管理者省麻煩而已，不見得真的對組織有益。
因為這個制度把原本最清楚狀況的第一線人員，該去思考「怎麼作才是最好的」責任移轉到 Guideline 的製作者身上。他們既然不用負這個責任，自然就不會想多花腦筋處理手上的問題：多想多做容易多錯。
為何 Guideline 可以提升效率維持（但不是提升）品質？因為它要求其他人只要照著做，不要思考與質疑，任何議題的溝通，只要你提出的意見違反了 Guideline ，就不用多說了，趕快摸摸鼻子離開會議室把 Guideline 再讀一遍，照著做吧。
「這 Guideline 不是有寫嗎？」與會者如果有人講出這句話，代表他不想再花時間討論，直接亮出王牌了。
製造出這把尚方寶劍的組織其實才是罪魁禍首。
而隨著組織年紀越大，內部堆積的 Guideline 只會越來越多，底下的人越來越沒得發揮，這也就是資源雄厚的大公司為何老是被小又沒錢的新創公司所超越？因為新創公司的 Guideline 還不夠多。ＸＤ
就像我上一篇所說：沒有任何決策是放諸四海皆準。如果沒有依據問題背後的成因作思考（記得幾年前有本著名的商業書籍 QBQ - Question Behind Question，好像就是在討論這麼回事），往往只會得到很平庸的結論。
幾乎每次我面對來面試的人，我都會問同樣的問題：
「如果將大量資料透過網路傳輸，從Ａ點（伺服器）到Ｂ點（使用者），無論你先壓縮資料或是直接傳送所花的時間都完全一樣的情況下（壓縮所多消耗的 CPU 時間恰好等於省下的傳輸時間），使用者當下感受也完全一樣時，你會選擇先壓縮再傳送？還是直接傳送？」
這個問題沒有統一的答案，完全由應徵者根據過去的經驗，是做專案還是做產品？風險或是責任歸屬？去假設事件背景來回答，我很容易從答案看出他思考的傾向。
例如上回討論到對資料庫使用的意見，同事問我說公司是否有對「運算應盡量在資料庫上進行亦或是盡量在應用程式內進行」這個方向制定一個 Guideline ？
所幸還沒有。
同事之前做商業產品時，把運算都拉進應用程式內進行，使得他們的產品可以針對不同預算的客戶提出不同價格搭配的套餐，將產品線範圍迅速推廣到大中小企業皆可。
然而對這次非產品的內部專案而言，比較好的方式又不一樣了，事實證明果然不可一概而論吧！
如果沒有尚方寶劍的存在...?
當組織成長，要避開「Over Management、Over Controlling」，讓 manager 放手部分他們原有的權力，並且隨時準備好歡迎底下的人來 challenge ，的確是一個非常考驗人性的關卡。
但如果 Guideline 只是一個 external reference，隨時可以被 override ，是不是一個比較好的做法？BUT....（套句九把刀的口頭禪，人生最雞巴的就是這個 BUT），提供 override 權力的同時，無論要採用或推翻 Guideline ，當事人皆需負擔做決定的全部責任，並且在每次 override 時提出完整的理由說明， 這樣 Guideline 有了每次 override 的 feedback ，或許可以不斷進化成更有意義的資源呢！
留言
張貼留言