帥勾美女，我是你的早餐店阿姨 小笠宏樹，今天一樣蘿蔔糕加大杯冰奶嗎？

連假的開始讓我們瘋一下
椰子!!Coconuts - 瘋狂的醫院

今天先來聊聊曾經的流行現在常被唾棄的對象 - 階層式組織（較大型、較完整、較老的專案）
以下就以缺點去討論所謂的階層式組織，並用程式的方式去解釋其可能的原因

缺點

1. 行動和改變緩慢 - 通常對於階層式組織要改變通常需要很長的時間，所以還會有一些特別的形容詞叫「大象跳舞」、「大象轉身」，用來形容大型企業的改變。
   • 這從程式的角度很好理解，畢竟越老越龐大的專案，很容易就牽一髮動全身，所以通常都必須改得小心翼翼，甚至得反覆測試才敢上版本。
2. SOP或規矩很多 - 這個也是必須的，當越多人的組織要成形，難免必須立下很多規矩讓管理者方便地去審視和管理公司，換另一個角度而言，為了方便管理，管理者必須將某些權利從員工個人上奪走，並建立SOP，這樣從SOP的這個角度而言，員工都會是有固定的表現行為的。
   • 從大型專案來理解也會是這樣的，通常為了簡化工程師去了解專案的難度，會創出一大堆的interface（可以參考我寫在Day 8 SOP的好與壞的內容），以便讓大部分的Class都會有類似的表現行為。
3. 穀倉效應 - 用來描述社會上組織或企業間缺乏相互協同的現象（取自MBA智庫百科的解釋），來講個好玩的真實案例，作者本人曾經被派發要研究VR這項新的技術，而當我研究了快2個月後某次報告進度給上層時，才發現原來跟我隔了不到5公尺的另外一個部門做的事情跟我一模一樣ＸＤ，除此之外我們也常常覺得有很多公司甚至會出互相競爭的產品在同時間一起賣就是穀倉效應的「好」案例
   • 在大型專業也會很常見，當好不容易刻完了一個自己覺得超猛爆強的功能或邏輯時，換來的卻是同事冷冷的一句「那個不是在XXX Class已經有一個很類似的了嗎？怎麼不直接用？」
4. 獨裁 - 有很多時候公司高層為了方便管理會將文化塑造成獨裁的體制，這有好事也有壞事，假如定的規矩是好的那整個組織架構就會很順利地跑，但假如定的很歪那反而會導致公司整個走偏，舉幾個例子：「高層很相信品格，因此每個人在打考績自評時，就會要自評德智體群美」、「高層很相信日式管理，所以每天都要跳早操」、「高層覺得業務才是重要的，所以會逼所有的員工都要將公司的產品背下來」、「高層信佛，因此每個員上班前要先拜拜」
   • 這個在專案中也會出現，舉一些比較技術類的例子好了，比如這個工程團隊篤信Rx，因此只要有人不用Rx的方式寫程式就reject這個PR，或是篤信命名規則一定要按照某種特定規範，所以只要命名上有點不順就會想要reject，但這些都不一定是好事，比如命名這件事的目的是大家覺得好讀看得懂就夠了，而不是像是要取小孩用一生的名字一樣謹慎（ＰＳ：就算是真實姓名，人一生也是可以免費改三次喔：））。
5. 指令的傳遞過程中很常會跑掉 - 公司中很常出現上面的指令跟下面做的事情有時候常常相反，這不一定是有人做錯了，而是上層的模糊指令傳道下層時，很多時候下層的人都必須經過轉譯才能得出能實際執行的行為，所以當一次兩次的轉譯都讓原本的指令稍微的偏個幾度後，最後就會得出這個上層的指令跟下層的行為有180度的反轉，而雙方卻又認為自己沒做錯的情況
   • 程式碼中也一樣，Parent Class傳過來的訊息必定不可能會包含細節，因此當傳遞的層數過多時，必然會導致結果跟原本預期的會有偏差，這個也是為什麼在「Day 5 不懂function？那要怎麼在公司溝通？」中強調的“單一功能原則”，假如你今天發現function裡面不只做了一件事，那你繼續傳遞下去很容易就會出現偏差的情況，因此這時最好的方式是找上層討論看看是不是這樣子的指令傳遞是有問題的。

以上就是有關階層式架構缺點的探討
速速寫完我要去烤肉哩
也祝大家中秋多胖兩公斤
明天會來寫當紅炸子雞扁平化組織