設計的通則?


        自從上一篇『為失敗所作的設計』貼出後,我收到一些同事的 feedback,首先要先對覺得被影射到的同事致歉並且解釋清楚:

  1. 關於留後路這件事,事實上只是當時提出的眾多考量「其中之一」而已他當時也有從「可延展性」以及其他諸多方面去思考而給出那樣的意見
  2. 另外「只把資料庫單純當作資料倉儲」這樣的想法則是來自另一位不同的同事,並非出自同一人。
  3. 為了讓文章聚焦,避免模糊焦點,我將來自不同人物的意見合併在一個代表人物上,並且因為當時對於「預留退路」這件事情特別有感觸,所以在撰文時將其他無關該主題的意見通通割捨掉,實際上是「斷章取義、以偏概全,與事實不符」。
        簡而言之,這個網誌是為了記錄針對 IT 領域,個人對一些議題當下所激發的想法並非為了留為呈堂證供,留作法庭審判用途,所以對引論中心思想無關的情境事實和前因後果,會過於簡略帶過或變造,以便撰文時可以流暢表達最重要的想法。

        前天跟同事喝咖啡,針對我上一篇文章,又聊到有關『設計與開發的通則』這個話題(真的很感謝有這麼優秀的同事們,不斷激發我回顧和重新審視一些觀念和想法,讓我一直在不斷的碰撞中找到成長的方向)。我們的工作之一,除了上一篇提到的內容外,還有提出「Development Guideline」。

        曾經,問過主管,我們提出的這份 Guideline 只是一個可以被 override 的 suggestion,還是必須強制遵守的 Commend?我得到的答案是後者,這讓我對於給『通則』這件事情起了相當的顧慮。Guideline 的存在幾乎都是來自於管理面(Management)的需求,管理面的理由一開始都可以講得冠冕堂皇,說是為了加速效率、減少溝通成本、維持一定的品質。但是我們再看深入一點,這是讓管理者省麻煩而已,不見得真的對組織有益。

        因為這個制度把原本最清楚狀況的第一線人員,該去思考「怎麼作才是最好的」責任移轉到 Guideline 的製作者身上。他們既然不用負這個責任,自然就不會想多花腦筋處理手上的問題:多想多做容易多錯

        為何 Guideline 可以提升效率維持(不是提升)品質?因為它要求其他人只要照著做,不要思考與質疑,任何議題的溝通,只要你提出的意見違反了 Guideline ,就不用多說了,趕快摸摸鼻子離開會議室把 Guideline 再讀一遍,照著做吧。

        「這 Guideline 不是有寫嗎?」與會者如果有人講出這句話,代表他不想再花時間討論,直接亮出王牌了。

        製造出這把尚方寶劍的組織其實才是罪魁禍首。

        而隨著組織年紀越大,內部堆積的 Guideline 只會越來越多,底下的人越來越沒得發揮,這也就是資源雄厚的大公司為何老是被小又沒錢的新創公司所超越因為新創公司的 Guideline 還不夠多。XD

        就像我上一篇所說:沒有任何決策是放諸四海皆準。如果沒有依據問題背後的成因作思考(記得幾年前有本著名的商業書籍 QBQ - Question Behind Question,好像就是在討論這麼回事),往往只會得到很平庸的結論。

        幾乎每次我面對來面試的人,我都會問同樣的問題:

        「如果將大量資料透過網路傳輸,從A點(伺服器)到B點(使用者),無論你先壓縮資料或是直接傳送所花的時間都完全一樣的情況下(壓縮所多消耗的 CPU 時間恰好等於省下的傳輸時間),使用者當下感受也完全一樣時,你會選擇先壓縮再傳送?還是直接傳送?

        這個問題沒有統一的答案,完全由應徵者根據過去的經驗,是做專案還是做產品?風險或是責任歸屬?去假設事件背景來回答,我很容易從答案看出他思考的傾向。

        例如上回討論到對資料庫使用的意見,同事問我說公司是否有對「運算應盡量在資料庫上進行亦或是盡量在應用程式內進行」這個方向制定一個 Guideline ?

        所幸還沒有。

        同事之前做商業產品時,把運算都拉進應用程式內進行,使得他們的產品可以針對不同預算的客戶提出不同價格搭配的套餐,將產品線範圍迅速推廣到大中小企業皆可。

        然而對這次非產品的內部專案而言,比較好的方式又不一樣了,事實證明果然不可一概而論吧!

        如果沒有尚方寶劍的存在...?

        當組織成長,要避開「Over Management、Over Controlling」,讓 manager 放手部分他們原有的權力,並且隨時準備好歡迎底下的人來 challenge ,的確是一個非常考驗人性的關卡。

         但如果 Guideline 只是一個 external reference,隨時可以被 override ,是不是一個比較好的做法?BUT....(套句九把刀的口頭禪,人生最雞巴的就是這個 BUT),提供 override 權力的同時,無論要採用或推翻 Guideline ,當事人皆需負擔做決定的全部責任,並且在每次 override 時提出完整的理由說明, 這樣 Guideline 有了每次 override 的 feedback ,或許可以不斷進化成更有意義的資源呢!

熱門文章