各位同學大家好！不管你是要上台成清交（沒錯我就是成大的不然你咬我啊！），還是想考上理想的系所，跟著老師我 小笠宏樹 就對了！來我們來一起複習Pointer！

今晚來點歡樂的來度過連假的開始
教練 Coach【芭蕾女孩】

好的～老師來揭曉答案了～同學們請準備好筆記本！

前情提要

雖然Java公司已經盡力做了改革，但是事情當然沒有那麼簡單，新架構所衍伸的問題導致各個部門都有所抱怨，這些還不打緊，重要的是元老級的兩大事業群「菠蘿」、「吐司」這兩個大頭也跳出來大聲的抗議了，而且「蛋糕」這個產品因為市場競爭激烈，也還無法交出讓大家都決定把頭繼續洗下去的決定，因此這時老闆只好跳出來再次主持大局。

架構篇

登登登！答案其實很簡單，既然此路不通那就用git revert回去原本的情況吧！
好啦～事情當然不可能那麼簡單（老闆也不想要打幾年前自己的臉），以下還是來介紹一下組織這次的架構，首先萬年不變的當然是已經變成三個的事業群「菠蘿」、「吐司」和「蛋糕」，而這次每個事業群中的部門變得更加完整，每個事業群中都擁有自己的外觀設計、調味研發、開實體店、行銷、外包生產、管理通路等等的部門，而這些部門人的來源當然是來自於原本這些部門的人由一分成三個，然後實際共用的部門就只有人資、財務和行政了，另外為了解決之前的部門整合決策的問題，將較通用的部門如外觀設計和行銷另外在事業群外面又在建立了行銷總部、外觀設計總部來進行三個事業群間的配合。

後記

事情也還在發生中所以暫時還看不出最終成果，通常架構的變化都是必須給予個幾年的時間來給公司做消化和部門之間重構的，但首先可以得知的一點是既然架構變回去了，那最一開始的架構缺點也還是會出現，只不過由於架構更往另外一邊傾斜因此會縮小某部分的缺點並且會放大另外一部份，以下提出來幾點來討論

1. 由於將很多部門拆分到各個的事業群中，因此這些部門的上下關係和權責關係通常會變得較為明確。
2. 也由於將很多部門拆分到各個的事業群中，因此部門之間的重複性還有可複用性降低到極致，所以很可能會產生淡旺季人員的調度比較困難。
3. 在三個事業群中的互相配合上雖然有另外設立了部門總部去改善，但在執行到實務上時還是會比較困難，因此會導致產品線各自為政的情況。
   另外再提幾點Refactor公司架構期間會遇到的狀況
4. 由於要將原本的部門一分為三，因此光是要把哪些function放到哪個事業群就一個頭兩個大，尤其是原本的想法就是要將部門效用最大化，因此很多功能都會合在一起做，這也導致了在拆分上的困難。
5. 由於部門的上下關係和權責關係的重新變動，讓原本藉由外包形式的平等關係產生變動，因此需要重新設計溝通流程。
6. 承接第二點，尤其在特殊的部門更麻煩，像是某個事業群的行銷部門，它既要站在事業群的立場去設計流程和做事（因為給薪水的是事業群），但它又要在從屬關係上聽從於行銷總部的規劃去進行整個公司的行銷計畫，這個在很多時候會產生立場混亂。
7. 公司的重構計畫可能是為了長痛不如短痛，因此在動作上非常快速和大刀闊斧，但有時候事情並不是越快越好，就這麼快速反而時常讓下面的中層幹部更無措適從。

好啦～拉哩拉匝的講了一堆，其實上面的這些故事都會是誇飾法，如果有實際做過重構都會知道，並不是每次重構都會完完整整地做完才進行下一種類型的重構的導入，因此上面這三個階段其實的區別並不如所寫的大，反而是大部分的狀態都是模糊不明的部門權利之間的流動，當然這樣的故意區分，我其實想表達的是說不定這些大方向的論點就會是在某個老闆與事業群負責人的會議中出現的討論，可能他們討論的方式不會只在意組織架構所導致的結果，但我們或許能藉此更加靠近老闆的想法一點。

明天會來聊聊企業文化