不做大項目,很難理解多人合作有多麼艱難。真正參與到項目中,才發現責任分配模糊、懶於溝通、越俎代庖干涉他人決策等,都會讓項目進展陷入僵局。雖然合作中常能感受到別人給自己帶來的麻煩,但我們卻很難發覺自己也在給別人帶去痛苦,越是自信,越難發現自己的失誤。

花了些時間,總結了下自己的經驗教訓,又訪談了不同職位的合作夥伴和好朋友,總結了一些各個職位與其他職位合作時最頭疼的事。興許可以幫大家看一下別人眼中的自己。

產品經理(Product Manager)
面對互動設計師(Interaction Design)的痛苦:

1. 不主動幫忙提供解決方案,而是先 PK 需求。
怎麼辦好呢:互相認清自己和崗位定義,採取積極配合的態度,多提建設性的意見;同時在需求構思階段產品最好能拉上互動設計師一起討論,同時為需求尋求客觀的用戶數據支持。

2. 悶頭畫稿不溝通,畫出一套自己滿意的稿,卻和自己預期相差很大。

怎麼辦好呢:建議互動設計師畫粗糙紙面稿,經頻繁溝通討論,再繪製精細紙面稿。再次確認溝通後,才用軟體繪製精細線框圖,逐漸細化,把矛盾逐批解決,不至於積累到最後爆發。

針對交付銜接:

1. 各個角色在交付文檔後,承接人的理解會走樣。

怎麼辦好呢:各種交付物在交接時要由負責人在交付評審會上逐條講解,以實現充分理解。交付物只是用來備案的,不是用來溝通的。

2. 對上游的交付物和交付時間有疑問,不直接詢問相關責任人,而是先來詢問產品經理,再由產品經理轉告。

怎麼辦好呢:對特定角色的工作有疑問,要直接諮詢此人,同時確保產品被知會到。

互動設計師(Interaction Design)
面對產品經理的痛苦:

1. 功能點照抄競爭對手,以至於界面無需思考,照抄即可。

怎麼辦好呢:請產品經理講清楚每個功能點背後的用戶需求和真實的生活場景,描繪該產品對用戶的生活會帶來怎樣的幫助。

2. 需求思考不清楚,經​​常變更。

怎麼辦好呢:爭取參與前期的需求制定階段,輔助產品經理討論清楚用戶使用場景和功能點,然後再列述下來。各合作方在需求評審會上公開確認需求。

3. 過度干涉控件佈局等細節。

怎麼辦好呢:產品經理應首先專注於挖掘靠譜的用戶需求,並清晰地列述功能點和幫助用戶實現的目標。這些用戶目標就是用來衡量互動方案是否有效的客觀目標。切忌用主觀標準否定設計方案。

面對視覺設計師的痛苦:

1. 以美觀之名更換控件,擾亂任務流,忽視對相關頁面的影響。

怎麼辦好呢:互動設計師應該在設計中期就拉入視覺設計師一起討論,讓視覺設計師知道每個控件的用意,同時坦然接受視覺設計師對互動方式提出的合理建議。

2. 調整控件佈局,擾亂元素的主次關係。

怎麼辦好呢:同上。

視覺設計師(Visual Designer)
面對產品經理的痛苦:

1. 用主觀的「我不喜歡、我覺得不好看」來否定設計稿,無法用客觀的詞彙描述預期效果。

怎麼辦好呢:產品經理應該將對視覺方案的要求書面留檔,並以此為作為評估設計方案的客觀標準。

2. 經常變更需求,並且天真地認為所需要做的調整超級簡單,一秒搞定。

怎麼辦好呢:產品經理不要低估調整視覺方案的工作量,視覺設計師也可以在初稿階段試試產品經理的口味,多傾聽一下彼此的意見。

3. 對自己的審美能力很自信,對設計稿指指點點說「要這樣移、那樣調」。

怎麼辦好呢:視覺風格方面產品經理應充分信任視覺設計師的審美能力,給建議時也要態度誠懇,淡化盛氣凌人的感覺。

面對互動設計師的痛苦:

1. 佈局控件時,不與視覺設計師溝通,直接丟一套線框過來。

怎麼辦好呢:互動設計師邀請視覺設計師參與線框圖的設計階段。

2. 設計的互動稿沒新意,太老套死板,了無趣味。

怎麼辦好呢:互動設計師要多玩、多看、多體驗,豐富自己的設計儲備庫,以便厚積薄發提出讓人眼前一亮的設計。

面對開發工程師的痛苦:

1. 改參數,並堅稱自己做的更美觀。

怎麼辦好呢:視覺設計師對於自己責任範圍內的設計稿參數標註要盡量詳盡,給出完備的視覺設計稿作為客觀的衡量標準。在開發完成後,要及時走查,並跟進問題的解決。

2. 不用切圖素材,用代碼來實現效果。

怎麼辦好呢:視覺設計師首先要確保給出的切圖素材十分完備;開發工程師也要克服惰性,將視覺素材充分利用起來。

3. 對像素、肌理、陰影不敏感,看設計稿不仔細,實現效果與視覺稿差異很大。

怎麼辦好呢:對開發工程師容易忽略的視覺細節,視覺設計師要與面向開發講述;交付的設計稿只是備案,不是高效的溝通方式。開發同志們是沒有視覺設計師那樣的像素眼的。

開發工程師(Developmental Engineer)
面對產品經理的痛苦:

1. 對產品前景沒有充足考慮,每次發新版本代碼都需要推倒重來。

怎麼辦好呢:產品經理要明確產品發展的大方向,並將遠景清晰地闡述給合作夥伴,以便開發工程師在搭建程序時為未來留好空間。

面對互動設計師的痛苦:

1. 設計稿缺少細節,像是每個頁面可響應事件的區域,響應的動作,操作成功和失敗的反饋。

怎麼辦好呢:互動設計師除了描繪頁面之間的跳轉關係,還應該將頁面內部所有的事件響應文檔化,減少開發工程師的誤解。不要怕麻煩。

面對視覺設計師的痛苦:

1. 沒有定量標註設計稿的每一個細節。

怎麼辦好呢:請視覺設計師認識到定量標註細節對於開發工程師無損地實現視覺稿的重要性。開發工程師是沒有精力去猜,或者量一個特定參數的。

2. 切圖不完備,遺漏細節,需要開發自己用代碼補。

怎麼辦好呢:每一個細節的素材都切圖切出來,並系統地使用文件名命名方法,幫助開發理解。

一遍看下來,有沒有覺得背上冒冷汗呢?一切依著自己的性子往前走,真的很難發現自己有哪些地方做的不對,不知不覺就給別人留下了心靈的創傷。

其實合作沒有很難,多積極參與一下上游的決策,知根知底;多耐心向下游講解一下那些只存在於自己腦子中的主觀想法,傾聽一下他們的建議和疑惑。多往彼此那邊靠一靠,心就能挨得近一點。

____________________

「團隊溝通」真的是千古大難題!到底該怎麼樣才能讓我跟技術團隊好好溝通呢?如果你也跟我一樣不想再增加無謂的時間、金錢成本;如果你也跟我一樣不想每天加班,產品卻還沒有進展:

橘子學院邀請 PTT 站長、資深科技人戴志洋(Kaede),八堂課循序漸進帶你理解「網路是什麼」、「怎麼技術 / 設計團隊溝通」、「產品完成後維護」等鞏固你的管理專業。不要猶豫了,快來報名你人生中最重要的電腦課!

最近有位剛做 PM(產品經理)的人跑來跟我控訴,說公司技術部的 RD 們(程式設計師)個個不給力。需求過了千百遍還是理解錯,或者就是簡單回一句「做不了」,表情如死灰。

這位 PM 血氣方剛,張牙舞抓,​​腦子裡總有一千萬個新產品需求的想法沸騰著。他咄咄不停的抱怨 RD 們不配合,能力差,懶惰,沒思考能力,沒品位,順帶連摳腳味兒太大這種事也強烈譴責了。「X,老子明天就去學 Coding!」哎,我發現 PM 們都特喜歡說這句無比勵志的話呢!

面對他,我的心突然惆悵起來。幾年前的自己也差不多是這個模樣,懵懂如白紙,但誰又知道這樣的 PM,在很多 RD 的眼裡就是個傻逼吧。

身為一位女性 PM,我至今為止並肩合作過的 RD 團隊超過 8 組共 200 多人(動盪曲折的職業生涯啊),受過的委屈流過的淚就不在這裡贅述了,打算留著以後寫小說。今天我只想淺談一些自己總結的 PM 與 RD 相處之道,所謂人艱不拆,希望大家看完後能更理解彼此「都不容易」的立場。
PM 眼裡的 RD 分成兩種:能溝通的和不能溝通的,後者佔 90%
如果你跟我一樣,是個沒有技術背景的 PM,估計你會覺得世界上「不能溝通的 RD」佔九成以上。難道不是嗎!

每當你鬥志昂揚講完一個偉大的產品計劃,期待看到 RD 激動的眼神,卻發現他們真的一點兒不興奮。給面子的 RD 會乾巴巴的問:「什麼時候要什麼時候開始設計稿確定了沒產品文檔寫完整了沒。」不給面子的 RD 則會當場質疑你,「這個新功能你到底想清楚了嗎?老闆又風花雪月拍腦子了吧?這麼做有數據依據嗎?做過市場調查嗎?老用戶會因此流失嗎?能保證上線後不再改了嗎?@$%^ ^% %$$@% #$%^ ^% 」真的是沒法兒做朋友啊!

曾經有一個自以為很神但其實能力已經跟不上時代的 RD 總監,在 kickoff 會議上把我所有的需求都推翻了,讓我差點在十幾個老男人面前哭鼻子。

話說人在經歷苦難後,要麼變乖,要麼變壞。這種迫切想要搞定 RD,讓他們聽命於我的心情,實在太強烈,於是我學會了通過非正規途徑收買 RD 的心 -- 比如請他們吃 KFC 啦,陪他們聊黃色笑話啦,穿低胸裝秀黑絲大腿啦。在這些努力之下,我和 RD 的關係改善很多,他們開始敞開心扉,解釋他們對於新需求的負面情緒到底從何而來:有時是因為實在忙不過來,有時是因為實在無法理解這個功能有什麼意義(至少他們自己肯定不會用),有時是因為 PM 不但不調解現有項目的優先級,反而還每天做夢,想些有的沒的,讓他們極為惱火。

而負面情緒最大的根源,則是他們對這個計劃失去了信心,覺得反覆改版卻一直沒有大的突破,老闆和 PM 都應該去吃屎。

正當我沾沾自喜,認為自己靠美胸美腿贏得了這場戰役時,一個 Ruby 開發者幽幽的跟我說「我好喜歡你的門牙。」 ( …… 你們果然是無法溝通的生物…… )

RD 眼裡的 PM 也分成兩種:有腦子的和沒腦子的,後者佔 90%
沒腦子的 PM,RD 們是打心底森森嫌棄你的。嫌棄你的理由可能有以下三點,歡迎對號入座,我們一起舔傷口:

嫌棄理由 1:你沒有自己的想法。

聽清楚哦,我說的是 RD 們「認為」你沒有自己的想法。這個話題實在很辛酸,哪個 PM 會沒有自己的想法呢,就是想法多的溢出了腦門兒才跑來當 PM 的啊混蛋!

但是 PM 的生存環境無比艱辛,很多決定都身不由己(尤其當你有一個心思活絡的老闆時)。於是,有些 PM 選擇推卸責任,兩手一攤「老闆說必須做」 ,急著撇清關係強調只有老闆是傻逼哦我不是哦。此言一出,你在 RD 心裡的形象全毀。

PM 必須是產品的靈魂,無論老闆決定鬧哪樣,你都要把這個決定翻譯成大家能接受的理由,建立你自己的口碑和信任。

在跟 RD 溝通的時候,不要說“ 我和老闆爭論了很久他就是不聽我的”,這樣更凸顯你的無能;也不要撒謊說「其實我覺得老闆的想法挺好的」然後硬掰些白痴的理由,這樣顯得你特別虛偽。比較好的應對方式是開誠佈公,說你自己真實的想法,如果你覺得老闆真是玩過火,也要解釋下老闆為何會有這樣的執念(是被投資人逼的,還是被老婆逼的,還是看到競爭對手做的什麼事情眼紅了想抄襲),然後安慰體恤下 RD 們的辛苦,並表現出和他們同甘共苦的決心。

嫌棄理由 2:你風花雪月沒有邏輯。

都說能做出厲害產品的 PM 要感性和理性兼備,因為厲害的產品能直戳人性,滿足用戶多層次的生理和情感需求,這就要求 PM 對生活細節敏感,情感豐富。

可是情感豐富的 PM 通常思維比較跳躍(藝術家嘛都這樣),情緒波動幅度巨大,鬱悶時會在陽台發呆抽一下午的煙,興奮時連坐在馬桶上都拿著手機寫文檔,這樣的節奏 RD 們真心吃不消。他們覺得你 X 的趕緊吃點兒腦殘片吧!(吐槽:我的上一篇文章發布後,就有人建議我服食腦殘片!)因此,論起 PM 的自我修養,你必須有收放自如的情感,還得有理性的邏輯思維去支撐起每一次的靈感乍現。

你可以問自己三個問題:

一、這個功能是否服務於產品的主線業務,比如一個聽歌的軟件是否要有日間/夜間模式切換?如果只是錦上添花,使用場景不足整體的 10%,那勸你還是等自己學會寫 Code 以後在家做著玩吧。

二、這個功能的技術實現成本有多大,如果用工時或天數來預計工作量不夠直觀,請去 HR 部門問一下 RD 全員每天的工資總額,再乘以所需要的開發時間,哈,這個金額應該足以讓你好好思考「需求性價比」這件事了!(這招在創業公司尤為實用)

三、這個功能的效果是否能被評估,這樣至少你能檢驗自己的判斷是否正確,無論如何都能積累寶貴的經驗。

嫌棄理由 3:不信任 RD 的能力。

說起這個真是百感交集。每一個有血有淚的日子裡都在重複上演這樣的劇集:PM 問 RD 這個功能要做多久,RD 說至少 3 週,PM 於是去問自己做技術的好友「真的需要 3 週嗎?」,朋友拍桌子說「這有什麼難的,換了我 3 天就搞定!」然後兩人忿忿不平的拍案皺眉,開始討論公司裡的 RD 們到底是能力差還是在偷懶。

我曾經也這樣,因為不懂技術害怕被騙,於是勾搭各種民間技術神人讓他們給我做狗頭軍師。軍師們為了維護自己偉岸的形象,通常會拍胸脯各種誇大各種裝厲害。更糟糕的是,軍師們也變相破壞了我和 RD 之間原本就已經很稀薄的信任。(喔多麼痛的領悟 ~~~)

最後,RD 眼裡的 RD,只有一種:比自己厲害的人。

剩下那些能力不如自己的,他們的存在早已消失散盡在霧霾裡了。

讓 RD 覺得產品經理很優秀的方法
1. 眼觀四路耳聽八方,知識淵博,掌握行業內的各種動態,分析市場趨勢,沒事就盯著友盟的數據看,各種國外新推出的厲害產品統統用起來。RD 們會覺得你什麼都知道,那你的判斷八成是可靠的。

2. 混對圈子,收集幾個很強的人脈,難得和大人物有飯局的時候一定拍照發狀態,時不時去知乎回答些問題,去各種活動露臉,撮合各種合作,盡一切可能把公司推到聚光燈下,這樣也更容易招聘到優秀的開發者,產生良性循環。RD 們大多不喜歡拋頭露面,所以他們會覺得你的付出無可取代(不然他們老覺得 PM 每天看看文章聊聊天,簡直是悠閒的廢物)。

3. 無論是口述的需求還是撰寫的文檔,文字和原型圖的呈現都要有邏輯,有條理,最好用寫 Code 的思路來寫產品文檔,功能細節上的邏輯處理無一遺漏。

4. 在老闆責問為什麼還沒上線的時候,衝上前去說,「都是我的錯,前幾天又改了個需求」。

5. 在 RD 們被各種部門的需求同時襲擊的時候,為他們安排最合理的優先級,並承諾擔起一切後果(包括被某部門主管批鬥責罵等)。

6. 招到漂亮的實習生妹子給 RD 們養眼。

7. 給他們加薪,給他們加薪,給他們加薪。

文章的最後,我想對所有還在拼搏的產品經理們說,就算你的行業環境不斷限制你的創新和暢想,就算你身邊的開發者總是打壓你的積極性,攻擊你的決策和判斷,就算你覺得全世界都沒有人肯定你的努力,沒有人理解你的無奈,你都不可以放棄。勿忘理想,勿忘初心。你們是美好未來的希望。

____________________

我相信工程師大大你應該也想好好溝通;我希望證明我不是沒腦!
給所有疑惑該怎麼跟 RD 好好相處的你:

橘子學院邀請 PTT 站長、資深科技人戴志洋(Kaede),八堂課循序漸進帶你理解「網路是什麼」、「怎麼技術 / 設計團隊溝通」、「產品完成後維護」等鞏固你的管理專業。不要猶豫了,快來報名你人生中最重要的電腦課!

本文轉自虎嗅網 《程序員,為什麼千萬不要重寫代碼?》

 

作為100offer 工程師拍賣的行銷,我們常常和用戶交流討論,有一個話題經久不衰:工程師入職新公司後接手已有的程式碼,怎麼處理?

大家都有一顆工程師的心,所以當他們到一片新的場地想做的第一件事就是,將舊的一切打掉重來。是的,他們決不會滿足於簡單的增加勞動量。

或許這種微妙的心理定位可以解釋:為什麼工程師進入新項目組後寧願丟掉舊程式碼重新寫,也不願意修修補補,他們認為舊程式碼簡直一團糟。

但是,事實上真是這樣嗎?你之所以認為舊程式碼一團糟,其實是由編程的一個基本定律決定的,那就是:寫碼容易,讀碼難。

為什麼你覺得舊程式碼異常混亂?因為讀代碼更難

這大概就是程式碼 Reuse 難以實現的原因,也可以解釋為什麼你組裡的每個人都喜歡用不同的功能將分割的字符串轉換成一個數組。比起猜測舊的功能是怎樣實現的,重新寫一個自己的功能要簡單和有趣多了。

作為這個公理的推論,你可以問問身邊的工程師他們正在奮戰的程式碼怎麼樣? “簡直是一塌糊塗!”他們肯定會這樣說。 “我簡直想打掉重來!”

為什麼認為程式碼這麼糟糕呢? “看看這個功能,竟然有兩頁長!完全不知道這些東西為什麼在這裡!完全不知道這些 API 是幹什麼的。”他們會這樣回答你。

 

1154558253.jpg漫畫:讀別人代碼是一種怎樣的體驗?

 

曾經, Borland 的創始人 Philippe Kahn 當初就是向記者們吹噓: Quattro Pro 會比 Microsoft Excel 要好用得多,因為它是從頭開始編寫的,全部都是新的源代碼!

但是,認為新程式碼比舊程式碼好簡直就是荒謬。舊程式碼是已經運行過的,測試過的。無數的 Bug 在被發現前都上線運行過,發現之後工程師們可能在花了好些日子才修復了這些 bug 。這種修復可能是一行程式碼,也可能是幾個字符,無數的時間和精力都花在了這些 bug 修復上。
當你決定拋棄這些舊程式碼從零開始的時候,你也丟掉全部前任努力的結果。

 

新程式碼一定比舊程式碼好? NO,重寫可能會帶來更大的風險

 

對技術領導者來說,重寫項目的程式碼代碼也是一個異常艱​​難的決定。因為從公司層面說,重寫程式碼甚至會威脅產品的市場競爭力。一旦決定重寫程式碼,那麼與競品相比,你可能落後了2~3年——在軟體行業,這時間可夠長的。

 

你理想中的新程式碼會帶來產品功能的提升▼

1156381351

但事實上,即便重寫的新程式碼可以實現舊程式碼的所有功能和需求,但是為產品帶來的市場競爭力只有邊際提升。因為重寫用的新技術、新語言、新框架並沒有給產品帶來質的提昇。

更不用說在重寫的漫長過程中可能會遇到一些意外情況,比如:

1、缺錢:資金鍊的斷裂

1157094204

 

2、缺人:核心工程師離職

1158088674

最終導致效果不佳:達不到原產品應有的所有功能和需求,白白浪費了時間和金錢,也丟掉了市場競爭力。

所以重寫程式碼意味著,你在把自己置身於非常危險的境地,可能幾年後你也寫不出比以前更好的代碼。你只是花了一大筆錢把已經存在的程式碼又寫了一遍。

 

當你覺得眼前的舊程式碼很爛時,該怎麼辦?

 

你覺得舊程式碼寫的很爛,那又怎樣呢?它們已經上線,已經在實際運行中承受住了考驗。所以當你發現前任留下的程式碼亂七八糟的時候,不妨冷靜下來,從以下三個方面入手理解程式碼、改善程式碼:

 

1、程式碼的結構有問題

如果一段網路程式碼突然彈出了自己的對話框,應該是 UI 程式碼需要被處理。這些問題可以被解決掉,你要一次次小心地移動程式碼,重構,改變接口。還需要一位細心的工程師立馬仔細地檢查這些改變是否有問題,從而不打擾到其他人。事實上,甚至比較大的結構變化也可以不扔掉代碼程式碼來完成。

大牛工程師 Joel Spolsky 回憶說,曾經在某個項目中,他和他的團隊花了好幾個月重新架構在一點上:把程式碼動來動去、清理、創建有意義的基類,並創建了模塊之間的完美接口。但是他們始終非常小心翼翼,並沒有產生新的 bug ,也沒有丟掉任何舊程式碼。

 

2、程式碼的效率不高

曾經, Netscape 的渲染程式碼被傳非常緩慢。但事實上,這只會影響該項目的一小部分,這部分是你可以優化甚至重寫的。你完全不必重寫全部程式碼。優化速度的1%工作量,會讓你獲得99%的爆炸性提高。

 

3、程式碼寫得很醜

有些程式碼真的寫的很醜,比如 Joel 曾參與一個項目,開始用下劃線做開始的成員變量約定,但後來改用更標準的“M_”。所以一半的功能用“_”開始,一半用“M”開始,這看起來真的很醜陋。但這個問題5分鐘就能解決,而不用從頭開始寫全部的程式碼。

最後,你要記住,從頭開始再寫一遍並不意味著你會寫出比以前更好的程式碼。因為你沒有參與到上一個版本的創建,所以你其實根本就不算有經驗。一旦你準備打掉重寫,你可能會再犯一遍版本一犯過的錯,甚至會產生更多的新問題。

 

總結

 

面對糟糕的舊代程式碼Keep Calm & Carry On!

在大型商業項目中,打掉重來是非常危險的行為。當然,如果你是在做實驗,想到新算法可以隨時重寫。如果你跳槽、或剛接手一個新項目,面對看上去異常混亂的舊程式碼,請冷靜下來,忍住打掉重寫的衝動,想想上面這些經驗之談。

《TO 導讀》:本文作者是中國新創團隊 Fiberead 創始人江苑薇,她現在在 500Startups 內進行培訓。500 Startups 給他的第一個震撼教育就是「老闆罵人是正確的。」這到底是什麼意思?為什麼一個新創企業也同意以「罵人」來作為管理?以下為第一人稱敘述。

在 500 Startups,我的兩位導師都是連續創業者,他們的性格截然不同。Dominic 話很少,他在說任何要點的時候,都是同一副冷靜嚴肅的表情,偶爾被自己的冷笑話感染,笑一下馬上又恢復原狀;而 Zafer 則熱情很多,他從不吝惜對 Fiberead 的讚美,當我跟他闡釋運營的思路,他覺得精彩時,就把手舉起示意我擊掌。兩位導師都是極其聰明的人,隨著時間推移,我越發從內心裡尊敬他們。

今天,就團隊管理,Zafer 給我上了一課。這一課之所以讓我印象深刻,是因為我從未感受到 Zafer 對一個觀點如此篤定。在過去,他總是抱著開放的心態和我討論,即便表達自己的觀點,也會半開玩笑,甚至沒有底氣地說「Runa,這事很重要」,「Runa,我有個想法,說出來你別介意」。

而今天的議題,似乎觸發了他的警報,他用一種完全沒有商量餘地的口吻跟我說了很多。

我相信很多創業者也會有同樣的境遇,我們都十分清醒地認識到,創業團隊的早期員工很重要,所以我們花了很多時間在招聘上。然而即便如此,實際管理時,也會遇到類似的問題:

在作出開人的決定前,我總是存有疑慮,是否是自己管理能力不足,導致這個員工出現問題,是否我提升自己的管理技巧,就不會出現這樣的問題。

Zafer 問我:「Runa,你對人發火有困難嗎?」

「沒有」。

他又問:「你的團隊現在有多少人?」「加上我和我的合夥人,一共 5 個。」

「那你罵過多少人?」

「5 個。」

「好樣的。非常好。」

然後,Zafer 無比堅定地對我說下面這番話:

「你為什麼會對某個員工發火?是你想這樣嗎?你對他發火,一定是他做了錯事。」

「你要接受一個事實:這個世界上,就是有人比其他人差,他們要嘛不夠聰明,學得更慢,要嘛就是更懶,要嘛就是性格有缺陷,要嘛心思在其他地方。你要的是那些最優秀的人,你不要第二等,第三等的人。」

如果沒有優秀的員工,你永遠沒有辦法成為優秀的領導。不是因為你是優秀的領導,就能把差員工給帶優秀了。一顆不夠好的種子,是永遠種不出參天大樹的。

任何崗位,都不要找二等、三等的人。永遠要用最優秀的員工,你需要人開車,你要找最優秀的司機,你需要人做清潔,你要找最優秀的清潔工。

這個世界上有兩種員工,一種員工是你推著他們往前走,還有一種員工是他們推著你往前走。優秀的員工是會推著你往前走,是他們讓你變成優秀的領導,而不是靠你推著他們往前走。

你不要給自己設限,去假想那些優秀的人不會加入你的公司,而是自己去創業。這個世界上,優秀的人才多了去了。並不是每一個優秀的人,都有創業的天時地利。你認為這些人都會自己去創業,不過是你自己的假想而已。

我以前也想過讓我自己改變,我問過自己很多次,是不是我做得不夠好,是否我改變 ​​了,員工就不會這樣。你放心吧, 一等的員工不需要你來驅動,他們在任何情況下,都不會給你弄出一坨屎來。

如果你開始在想一個員工是不是有問題的時候,那麼他就是有問題。如果這個員工很優秀,你現在不會來跟我說這些,你只會跟我說他有多優秀,而不是在糾結現在這些問題。

一個創業團隊,不能只有創始人在學習,所有人都需要學​​習。你招人,是給你節省時間,不是讓你花時間精力去當他的老師。如果一個員工不知道自我學習,如果他凡事都需要你教,你得把他開掉。你的責任不是當他的老師,你請他,就是讓他幫你解決問題,你不會想要當他的老師。

你要做的,不是一個不錯的公司,不是一個還行的公司,而是一個偉​​大的公司。你覺得,一個偉大的公司,可能是由二等、三等的人組建的嗎?公司是由人組成,一切都依賴於人。找到一等人的加入,當然是不容易的,所以要創建一個偉大的公司,會非常的困難。

很多公司,之所以失敗,或者淪為還行的狀態,就是因為創始人忠誠於和他一起創業的早期員工,而非公司。一個創業公司的前五個員工是最重要的,很幸運的情況下,你們能夠一路走下來,但是更多的情況是,在每一個階段,會有新的人加入,舊的人離開。

創業者的心情,不應該影響到公司,不要把你個人的喜怒哀樂,帶到公司中來。你不要想著在公司裡交朋友,做好人。你的責任是把公司帶向成功,不是討好不適合的員工。

永遠忠於你的公司。

你不要想著,自己怎麼改進,怎麼能讓你的員工變得更好。你要做的,就是接受現實,把他開掉。對於早期員工的招聘和管理上,你絕對不能妥協,絕對不行。永遠只請最優秀的人。

所以,對於一個早期團隊,當作為創始人的你腦海裡有以下想法的時候,罵人就是唯一的解決方案

這個員工態度很好,但是就是學得太慢,我是不是應該再給他更多的時間;(他的態度很好,真的很難得,你還挺喜歡他,所以這會讓你在開掉他的時候感到更難過);

這個員工做的不夠好,但是沒有他事情就沒法推進了;(你寧可讓公司的業務慢下來,也要把他開掉)

是不是我的管理方法出了問題,導致他的工作效率不高;(你的管理方法肯定有改進的空間,你要學習的東西還有很多很多,但是這不是他給你弄出一坨屎的理由)

是不是我給他的壓力太多了,他扛不住了才會這樣,是不是我安排工作時說得不夠清楚,他才會有這樣的問題;(他是優秀的人才,他自己會知道該做哪些事情,他自己分得清優先級,既然他分不清楚,他就不是你要的人)

重新招人的成本很高,並且存在不確定性,我是不是該將就著用他;(重新招人,你的公司還有活下去的機會,將就著用他,你的公司就一定會完蛋)

接著,他又告訴我了幾個管理上需要注意的地方:

永遠告訴你的員工「為什麼」。當你給員工安排工作的時候,不要至專注於告訴他工作的內容是什麼,工作的方法是什麼,你最應該告訴他的,是為什麼要做這個工作。不要只在一開始的時候才說,不要隔幾天才說,你要每一天,每一次都說。

不要突然罵人。要給你的員工發警告信。警告不是責備,而是一種威脅。當他們的表現你不滿意的時候,把你不滿意的地方寫下來,把書面的信息發給他,給他設置一個觀察的期限,明確地告訴他,在觀察期限內如果出現同樣的問題,他的麻煩就大了。不要不給人緩衝的餘地,讓他覺得很突然。

分清「好錯誤」和「壞錯誤」。當你的員工第一次犯一個錯誤的時候,這是「好錯誤」,永遠鼓勵你的員工犯「好錯誤」。但是,相同或者相似的錯誤出現三次以上的時候,這就是「壞錯誤」。當你的員工出現「壞錯誤」的時候,不是他對工作不上心,就是他腦子不好使。你不需要犯「壞錯誤」的員工。

數據是最公平的指標。會有這樣的情況,是管理者忽略了員工的工作量。可能這個人的工作已經很飽和了,但是我們還在不斷地給他加工作。所以,讓你的員工把工作時間寫下來,你就能清楚地知道他到底做了什麼。寫下來的目的,而是為了讓你做出開掉他還是留下他的決定。

或許你會問,這種做法是否會和人性化管理有衝突?不衝突。你要做的是人性化管理優秀的員工。前提是你得有優秀的員工。不夠優秀的員工,只會消耗你的精力,迫使你一次次地指責他,甚至對他咆哮,消磨整個團隊的信心。

需謹記,一等的員工是永遠不能夠和二等、三等的員工並肩作戰的。不要把他們放在一個團隊裡。你要警惕的,不是小白兔,小白兔很容易分辨,從 A、B、C、D、E 到 F(Fail),有很多個等級,你最該警惕的,是從 B 和 C 這類員工,他們算不上太差,但是不夠優秀。你不需要不夠優秀的人在你的團隊。

最後,和大家分享一篇 Zafer 推薦的閱讀材料,有興趣的朋友不妨花時間看一看:

(圖與本文無關)photo credit: hackNY.org

軟體吞噬世界,開發者這個職業炙手可熱的程度前所未有,而且只會愈來愈熱門。許多人意識到這股潮流,加入寫程式的行列。不過別看矽谷工程師坐擁高薪,這可是個強者如雲、充滿挑戰的環境。也因如此,開發者品質的優劣判斷總是在網路上引發熱烈討論。Quora 上就有這麼一道長壽的問題「糟糕的軟體工程師有什麼特徵」,亞馬遜軟體開發工程師 Nachiket Naik 的回答頗為中肯,獲得幾千名網友贊同。邁向頂尖開發者的道路上,你該避免成為下列十種討厭鬼。

1. 只會複製貼上的機器人

程式設計問答網站 Stack Overflow 擁有非常豐碩的資源,很多人寫程式碰壁了就會上去找解答,Stack Overflow 本身並沒有錯,它是工程師的得力助手。但是如果只是複製貼上,改個參數,不去了解前因後果,不去弄懂為何這樣的解法到底是不是真的適用於現在面臨的問題,那當然很難進步。有不少工程師寧可相信他們在網路論壇看到的說法,而不願意費心思考眼前的程式碼或系統。

2. 懶得測試

「我不幹測試這種事,那是測試工程師的責任。」即使在敏捷開發方法如此盛行的時代,這種態度依舊層出不窮。工程師不願測試的惰性還是很普遍。有可能是他們討厭設定測試環境,也有可能是缺乏測試的連貫性知識。當然,也或許是,測試工程師在開發者社群中總存在著不能說的污名。

3. 不寫文件

有些人覺得程式文件(code documentation)應該如詩一般簡潔美麗,他們沒能力做到這樣,就乾脆不做了。可我認為這樣的心態是軟體開發的頭號公敵。傑出的軟體,不需要有幾百萬個酷炫的功能,傑出的軟體,應該是要提供幾個讓人「離不開」不斷使用的功能,而且這幾個功能背後有幾千個人閱讀、更新、修正。輕視技術溝通、文件精確度、忽略細節的開發者,肯定是公司獲得成功最大的絆腳石。

4. 程式寫得很醜

我的程式能跑,但⋯⋯

  • 有些變數被命名為 x、flag、str、arr⋯⋯
  • Most of what I write is in one giant method.
  • 忘了縮排
  • 缺乏連貫的程式慣例或風格
  • 把全域變數噴灑得到處都是

對作者來說,這簡直是最惱人的事。雖然某段程式碼不見得差,甚至有可能是寫得最好的部分。只是,如果出現上述情況,就像一條鑽石項鍊被埋葬在鐵達尼號的殘骸中,沒人找得到它,也沒人想清理它、佩戴它、使用它。

5. 只能衝刺而無法跑千里

他寫程式、他部署、他繼續前進,絲毫沒有想要學著解決問題的意願,只要給這傢伙一段程式碼,他就會沒日沒夜奮戰,隔天就交出成果,你會得到一個修復好、能執行的軟體,除此之外別無所有。有時候,選擇開發者的時候你得有些私心,找個不但會在大限之前完成任務,而且也有旺盛的求知慾的人。

6. 一天到晚怨天尤人

「這不是我幹的」、「這不是我的錯」、「這跟我修復的部分無關,一定是有其他人搞砸了」、「這東西真的很煩!(無限迴圈)」、「我不知道怎麼修復這邊,找個會的人來啦」⋯⋯

那個犯錯的人可能早就修正向前走了,你還在大肆抱怨什麼勁呢?

7. 這個世界唯我獨尊

「不照我的方法做就拉倒」,是這群人的座右銘。在他們心中,這是一場他的「點子」與你的「點子」之間、他的解決方案與你的解決方案之間的競爭,不為整個專案著想。他們會來來回回仔細你植入的程式碼,即使他們運作正常、經過測試、看來完美無缺,仍讓他們覺得芒刺在背。這類傢伙是阻礙生產力的大麻煩,在壓力來襲時,他們也會是最先落荒而逃的人,就算經驗再怎麼豐富、技術再怎麼厲害,也別輕易嘗試找這些人加入團隊。

8. 不願踏出舒適圈

寫 Java 的 A 開發者一聽到他得寫一段 Python script 就愣住了。B 開發者一聽到設定檔裡某個部分必須改正就慌了。C 開發者一聽到他得在資料庫裡輸入東西就畏縮了。這些人傾向趨吉避凶,不願離開舒適圈。他們有很奇異的迷信,不想接觸系統的某些地方。這個現象尤其容易出現在菜鳥開發者身上,出色的開發者或快或慢,都會渴望跳出舒適圈,探索陌生的事物。

9. 粗枝大葉

忘掉留存備份、快照存檔、一堆未歸檔的程式目錄⋯⋯這些都是菜鳥容易出的狀況,隨著你愈來愈朝專業者邁進,這些漫不經心的狀況都應該避免。

10. 偽裝成駭客的麻煩精

這些人能夠耍些小技倆,「騙過」系統使之運作,沾沾自喜。面對複雜的問題,他們彷彿變個魔術就能解決,但就作者的經驗,10 次有 9 次都只是表面功夫,實則漏洞百出,而且遲早都會當掉,導致後來還要花更多成本處理。

最近開始研究DDD(Domain Driven Design),發現它確實是組織大型軟體架構出色又實際的方法。
可惜網路上只找得到一堆理論與說明,實際的範例code很少,我只好自己摸索了。
我會陸續將成果分享出來,希望對需要的人有所幫助。


需求

我公司串接由A公司提供之金流服務(第三方支付),A公司在確認收到顧客付款(信用卡、ATM轉帳)之後,會以HTTP POST通知我公司某設定好之URL。
由於可能有粗心大意之顧客,針對單筆訂單送出多筆交易、重複付款,因此需要在發現重複付款之時通知A公司放棄之前相關授權交易。

原解法

我公司有代表交易之trades資料表與代表訂單之orders資料表。
商業邏輯如下:
* 使用A公司SDK計算與驗證參數
* 從trades找到對應之交易並設為「已授權」
* 從orders找到對應之訂單並設為「已付款」

在MVC架構之下,我將其撰寫於某專責於金流交易之controller:

問題:
* code可讀性不夠高
* 此controller action一次處理多件事情、分工不佳

反省

也許可將這串程序封裝成Trade類別底下的一個動作?

問題:
* 只是將code由controller移進model,所有問題都依舊存在

在MVC架構之下,只追求’thin controller, fat model’會很容易將軟體架構只改善到這個階段。

DDD觀點

一個「交易」實體本身不會「授權」自己,應該由「某個程序」去進行「授權」一個「交易」實體的動作。
也就是說這行code不合理:

它將原本Trade類別的意義由「一筆交易擁有的屬性、行為」擴大去包含了「會對一筆交易施加的行為」。
就算改寫為靜態函式依然擴大了原Trade類別的意義。
Trade類別的意義過廣會導致可讀性降低、不好理解、難維護。

DDD中關於一個service的判斷如下:
* 涉及到domain中的其他object
* stateless
* 涉及一個domain,通常不屬於一個entity或value object

我決定撰寫一個service類別專職處理這段接收通知的金流程序,並在controller中使用這個類別:

幾乎只是將原本的code剪下、貼上而已,卻花了我整個下午。

您覺得可讀性、可維護性有改善嗎?

期待您的寶貴意見,歡迎在下方給我feedback。

dohpaz42

軟體測試是一個超複雜大怪獸。每個人測試的方法都差很多。電腦理論都這樣的。
先簡單回答你的問題:測試所有東西。
完整回答比較複雜。我試著整理出來,請見諒。
測試有分很多種:unit tests,integration test,regression tests,feature tests,等等。根據測試的對象不同,你會使用不同的測試。
舉例來說,當你寫一個model,基本上你會用到unit test。你會替每個method可能走過的每條道路都寫測試。
如果你對這觀念不熟,就這樣想:若你的method會製造X種副作用,那你就得替這X種副作用寫測試。正確執行、失敗執行的情況都算。
unit test的定義就是測試application中的一個特定單位。如果測試碰到其他models或程式碼,你就mock那些物件(利用dependency injection)來忽略它們。若有個database model會寫入資料到database,我需要去管database layer是否產出正確的output嗎?大概不需要。你只需要注意正在測試的部份系統(System Under Test, SUT)會針對database的output正確反應。這代表你應該要對所有會影響系統運作的database output寫測試。只需要pass-through、proxy(或是任何不會造成副作用的方式)這樣的簡單方法,就能有效忽略那些code的可能走法。譬如說:

這個method只是把application中另一層layer的結果丟回去,而那層layer你應該早就測過了。所以你不需要替fooProxy寫測試。

很好,感謝你保持耐心。正式回答前,我想先釐清這些。

controllers通常會與application中的多個部份一起合作。它們透過front controller、routing機制來運作,並用上models、views。很少會有專屬於controller的logic(這不代表controllers不需要測試)。要是有的話,那就測吧。測試在不同狀況下,他們與其他code的互動是否一如預期。這需要integration tests才行。

一個integration test不怎麼在乎系統運作的細節。它只在乎:如果XYZ放進去,那麼結果應該要是ZYX。拿REST API舉例:如果我丟一個GET request到/resource/a,我應該得到一個200 response,也許再加上body content。這樣算通過測試。如果我把幾個變數跟request一起丟出去,結果得到400 response,那就沒通過測試。不在乎系統是否碰到資料庫還是檔案什麼的,只在乎response是不是200。

正式回答你的問題:對,所有東西都應該測試。你會寫很多不同的test。這可能很瑣碎,甚至很無聊。但是當所有的tests都通過的時候,你終究會理解價值何在。

whtevn

我們會替controllers寫測試。但是integration tests,不是unit tests。我們會測所有api endpoints,然後記下他們在特定input下的各種response。我們也會測資料庫是否正確更新。這樣算是驗證了整個application。
這跟unit test要求徹底獨立的概念不同。從TDD的觀點,先寫unit tests是很合理。但是先寫integration tests更棒。它能協助你弄清楚功能,又不需要像unit test那樣有個逐漸遞增的feedback loop。

我們公司強調integration tests而非unit test。我們規定每個endpoint都必須要有integration test,而unit tests由工程師自行決定。確認特定的method運作正常當然重要。但我個人認為,確認所有API endpoint都符合規格,更重要。

我寫了一個integration test套件。我放在github上,但目前只有幾個範例有寫說明。

https://github.com/whtevn/routest/blob/master/sample/tests/succeed/routest-test.js

也放在npm上了。它不是外掛,只是一個免費工具。好像也算外掛。隨便啦。

https://www.npmjs.com/package/routest

mrargh

我們通常對models寫unit test,然後用web driver integration tests 測controllers – 這樣就都測到了。

philsturgeon

沒事幹才寫吧…但我總是有事幹。
我對libraries,models之類的寫unit test,然後用integration test測其餘部份。
對controllers寫unit test不是壞事,但不需要優先考慮。

WishCow

我不寫。我盡量在controllers內少放logic,把事情都交給services跟models。替controllers寫測試只是再模擬一次他們的互動而已。那樣是可以驗證參數與結果的關係,但對我來說太花功夫了,不划算。

chadcf

如果是API application我才替controllers寫測試。那些算functional tests。web介面的話,我會讓controllers內容少到不需要寫tests。大原則是讓controller action內容少到10行以內,只讓它建立物件、呼叫物件方法,然後回傳response。

跟大部份的創業者不一樣,甚至可以說是反其道而行,DECOmyplace 居家裝潢社群網站創辦人 蔡明宗Jerry拒絕了多家創投公司的投資,如此有個性的品牌營運模式,其中的動力與奧妙到底是什麼呢?

10600424_10153259565407430_3324528413608856562_n

現代人對於自己居住的空間其實都已有一定程度的重視,不論是室內裝潢、局部設計、改造裝修…等等,喜歡設計自己的家的消費者越來越多,Jerry在 2007 年時比身邊的人早一步看見大環境氣氛的改變,便以自己學生時代的資管背景計劃創辦全球居家裝潢社群網站DECOmyplace.com

DECOmyplace.com 說起來是Jerry的第二次創業,相較於第一次2000年的幫人架設網站公司時因經驗的不足與年輕氣盛,累積了以往失敗的經驗,對於此次創業的風險控管更為謹慎,並且是優先以財務狀況為經營公司的目標,堅持「有多少錢做多少事、賺多少錢請多少人」為具體做法,貫徹從哪裡跌倒就從哪裡站起來的正面態度!

 IMAG3715

沒有資金也沒有技術 就不該考慮創業
Jerry認為如果沒有資金也沒有技術的話,就不應該踏上創業這條路。做哪一行就該像哪一行,所以從基礎開始很重要,因此他從創站的第一天就下定決心不輕易接受創投公司的投資,畢竟拿人手軟,無法100%掌握自己在做的事情,不是他樂見的過程與結果。

因此靠著上班這幾年的存款而再次創業的Jerry,在DECOmyplace.com的前3年都是一人公司,連續虧損18個月才開始有微薄的廣告收入,上至到外頭跑業務,下至網站的程式、設計與美工通通都是事必躬親,還至少寫了20,000封信件廣邀全世界各方好手分享居家佈置經驗,來增添網站的可看性與豐富性。

水到渠便成,網站流量自此也開始跟著成長,一步一腳印,過往的辛苦總算是能看見點收穫,但 Jerry 不以此為傲,反而是更以此為信念,確知若是沒有資金也沒有技術還吃不了苦,千萬不要踏上創業這條路。

待續…

文/品牌志特約記者 Alice
圖/DECOmyplace

組織扁平化

組織扁平化(horizontal organization)

組織扁平化的提出及意義

現代企業組織結構理論可以分為兩個階段,

第一階段,從亞當·斯密分工理論開始,至本世紀八十年代,這一階段強調高度分工,組織結構也越來越龐大,組織形式從直線制開始,一直到事業部制,我們可稱之為傳統的科層制組織結構;

另一階段自本世紀九十年代始,這一階段強調簡化組織結構,減少管理層次,使組織結構扁平化。

科層制組織模式中,直線-職能制是企業較常採用的組織形式,其典型形態是縱向一體化職能結構,強調集中協調的專業化。適用於市場穩定、產品品種少、需求價格彈性較大的情況。其集中控制和資產專業化的特點,使得它不容易適應產品和市場的多樣化而逐漸被事業部制組織取代。事業部制組織強調事業部的自主和企業集中控制相結合,以部門利益最大 化為核心,能為公司不斷培養出高級管理人才。這種組織形式有利於大企業實現多元化經營,但企業長期戰略與短期利益不易協調。

隨著企業規模的擴大,科層制組織不可避免的面臨:1.溝通成本、協調成本和控制監督成本上升;2.部門或個人分工的強化使得組織無法取得整體效益的最優;3.難以對市場需求的快速變化作出迅速反應等問題。

扁平化組織,正是由於科層式組織模式難以適應激烈的市場競爭和快速變化環境的要求而出現的。

所謂組織扁平化,就是通過破除公司自上而下的垂直高聳的結構,減少管理層次,增加管理幅度,裁減冗員來建立一種緊湊的橫向組織,達到使組織變得靈活,敏捷,富有柔性、創造性的目的。它強調系統、管理層次的簡化、管理幅度的增加與分權

扁平化組織的特點

扁平化組織與傳統的科層制組織有許多不同之處。科層制組織模式是建立在以專業分工,經濟規模的假設為基礎之上的,各功能部門之間界限分明。這樣建立起來的組織必然難以適應環境的快速變化。而扁平化組織,需要員工打破原有的部門界限,繞過原來的中間管理層次,直接面對顧客和向公司總體目標負責,從而以群體和協作的優勢贏得市場主導地位的組織。 扁平化組織的特點是:

1.以工作流程為中心而不是部門職能來構建組織結構。公司的結構是圍繞有明確目標的幾項“核心流程”建立起來的,而不再是圍繞職能部門;職能部門的職責也隨之逐漸淡化。

2.縱向管理層次簡化,削減中層管理者。組織扁平化要求企業的管理幅度增大,簡化繁瑣的管理層次,取消一些中層管理者的崗位,使企業指揮鏈條最短。

3.企業資源和權力下放於基層,顧客需求驅動。基層的員工與顧客直接接觸,使他們擁有部分決策權能夠避免顧客反饋信息向上級傳達過程中的失真與滯後,大大改善服務質量,快速地響應市場的變化,真正做到“顧客滿意”。

4.現代網路通訊手段。企業內部與企業之間通過使用E-mail辦公自動化系統管理信息系統等網路信息化工具進行溝通,大大增加管理幅度與效率。

5.實行目標管理。在下放決策權給員工的同時實行目標管理,以團隊作為基本的工作單位,員工自主作出自己工作中的決策,併為之負責;這樣就把每一個員工都變成了企業的主人。

把扁平化組織與科層制組織作比較,得到下表:

组织扁平化

扁平化組織模式分類

扁平化組織形式主要有矩陣制團隊型組織、網路型組織(虛擬企業)等。

(1).矩陣制組織結構

矩陣組織結構,是為了改進直線職能制橫向聯繫差,缺乏彈性的缺點,在直線-職能制垂直形態組織系統的基礎上,再增加一種橫向的領導系統而形成的一種組織形式。又可稱之為"非長期固定性組織"。其組織結構如圖1所示。

组织扁平化

它的特點表現在圍繞某項專門任務成立跨職能部門的專門機構上,例如組成一個專門的產品(項目)小組去從事新產品開發工作,在研究、設計、試驗、製造各個不同階段,由有關部門派人參加。這種組織結構形式是固定的,人員卻是變動的,需要誰,誰就來,任務完成後就可以離開。項目小組和負責人也是臨時組織和委任的。任務完成後就解散,有關人員回原單位工作。因此,這種組織結構非常適用於橫向協作和攻關項目。企業可用來完成涉及面廣的、臨時性的、複雜的重大工程項目或管理改革任務。特別適用於以開發與實驗為主的單位,例如科學研究,尤其是應用性研究單位等。

矩陣結構的優點是:

機動、靈活,可隨項目的開發與結束進行組織或解散;由於這種結構是根據項目組織的,任務清楚,目的明確,各方面有專長的人都是有備而來。因此在新的工作小組裡,能溝通、融合,能把自己的工作同整體工作聯繫在一起,為攻剋難關,解決問題而獻計獻策,由於從各方面抽調來的人員有信任感、榮譽感,使他們增加了責任感,激發了工作熱情,促進了項目的實現;它還加強了不同部門之間的配合和信息交流,剋服了直線職能結構中各部門互相脫節的現象;加強了橫向聯繫,專業設備和人員得到了充分利用。

矩陣制的缺點是:

項目負責人的責任大於權力,因為參加項目的人員都來自不同部門,隸屬關係仍在原單位,只是為"會戰"而來,所以項目負責人對他們管理困難,沒有足夠的激勵手段與懲治手段,這種人員上的雙重管理是矩陣結構的先天缺陷;由於項目組成人員來自各個職能部門,當任務完成以後,仍要回原單位,因而容易產生臨時觀念與短期行為,對工作有一定影響。

(2)、團隊型組織結構

團隊型組織中以自我管理團隊SMT(Self-managed Team) 作為基本的構成單位。所謂自我管理團隊,是以響應特定的顧客需求為目的,掌握必要的資源和能力,在組織平臺的支持下,實施自主管理的單元。一個個戰略單位經過自由組合,挑選自己的成員、領導,確定其操作系統和工具,並利用信息技術來制定他們認為最好的工作方法。惠普施樂通用汽車等國際知名的企業均採取了這種組織方式。SMT使組織內部的相互依賴性降到了最低程度。 團隊型組織的基本特征是:工作團隊做出大部分決策,選拔團隊領導人,團隊領導人是"負責人"而非"老闆";信息溝通是通過人與人之間直接進行的,沒有中間環節;團隊將自主確定並承擔相應的責任;由團隊來確定並貫徹其培訓計劃的大部分內容。

它有如下特點

1.自我管理團隊容納了組織的基本資源和能力。在柔性生產技術和信息技術的基礎上,團隊被授權可以獲得完成整個任務所需的資源,比如原材料、信息、設備、機器以及供應品

2.部門垂直邊界的淡化。在充分重視員工積極性、主動性和能力的前提下,團隊消除了部門之間、職能之間、科目之間、專業之間的障礙,其成員經過交叉培訓可以獲得綜合技能,相互協作完成組織任務。

3.“一站式”服務與團隊的自主決策。在簡潔、高效的組織平臺(整體戰略、信息技術、資金等)支援下,團隊被賦予極大的決策權.團隊成員可以自主進行計劃、解決問題、決定優先次序、支配資金、監督結果、協調與其他部門或團隊的有關活動。自我管理團隊具有動態和集成的特點,能針對變化的顧客需求進行“一站式”服務,從價值提供的角度看,自我管理團隊獨立承擔了價值增值中一個或多個環節的全部工作。

4.高層管理者驅動轉向為市場驅動,管理者角色轉換。在扁平化組織中,自我管理團隊對本單位的經營績效負責,其管理人員從傳統的執行者角色轉變為創新活動的主要發起人,為公司創造和追求新的發展機會。中層管理者大為簡化並不再完全扮演控制角色,相反轉變為對基層管理人員提供顧客和供應商信息、人員培訓方案、績效與薪酬系統設計等關鍵的資源,協助團隊間知識、技能和資源的橫向整合。由於急劇的資源分散化和職責的下放,最高管理層的精力主要集中在制定整體戰略、驅動創新過程,扮演設計師和教練的角色。

在基於速度和解決方案提供的競爭中,自我管理團隊只能拿捏相對有限的資源。為滿足顧客渴求,有效的減少成本、降低風險、縮短開發時間,自我管理團隊必須大量依賴與其他團隊或外部組織廣泛的橫向合作;自我管理團隊能夠獨立完成價值增值的一個或多個環節,更為其在組織內部或組織間與其他團隊實現多方合作奠定了基礎。在市場需求驅動的新型組織中,自我管理團隊是其基本構成單位,這種組織的形態必將是扁平的。

網路型企業是虛擬企業的一種, 目前關於網路型組織的一個被較為普遍接受的定義是:網路型組織是由多個獨立的個人、部門和企業為了共同的任務而組成的聯合體,它的運行不靠傳統的層級控制,而是在定義成員角色和各自任務的基礎上通過密集的多邊聯繫、互利和互動式的合作來完成共同追求的目標。

網路型企業組織結構中,企業各部門都是網路上的一個節點,每個部門都可以直接與其他部門進行信息和知識的交流與共用,各部門是平行對等的關係,而不是以往通過等級制度滲透的組織形式。密集的多邊聯繫和充分的合作是網路型組織最主要的特點,而這正是其與傳統企業組織形式的最大區別所在。這種組織結構在形式上具有網路型特點,即聯繫的平等性、多重性和多樣性。

企業的網路化變革過程中,必須通過大力推廣信息技術的使用,使許多管理部門和管理人員讓位於信息系統,取消中間管理層或使之大大精簡,從而使企業組織機構扁平化,企業管理水平不斷提高。

網路型組織的適用前提:經濟全球化,環境高度不確定性。

網路型組織的基本類型

根據組織成員的身份特征以及相互關係的不同,網路型組織可以分為四種基本類型,分別是內部網路、垂直網路、市場間網路和機會網路。以下對這四種類型的網路進行具體說明。

1.內部網路

內部網路包括兩個方面的涵義。第一個方面是通過減少管理層級,使得信息在企業高層管理人員和普通員工之間更加快捷地流動;第二個方面是通過打破部門間的界限(但這並不意味著部門分工的消失),使得信息和知識在水平方向上更快地傳播。這樣做的結果,就使企業成為一個扁平的、由多個部門界限不明顯的員工組成的網狀聯合體,信息流動更快,部門間摩擦更少。與此相適應,企業的組織結構也以生產為中心轉變為以顧客為中心。

2.垂直網路

垂直網路是在特定行業中由位於價值鏈不同環節的企業共同組成的企業間網路型組織,原材料供應商、零部件供應商、生產商、經銷商等上下游企業之間不僅進行產品和資金的交換,還進行技術、信息等其他要素的交換和共用。聯繫垂直網路中各個企業的紐帶是實現整個價值鏈(包括顧客)的利益最大化,因為只有整個價值鏈利益最大時,位於價值鏈中各個環節的企業所創造的價值才能最終實現。垂直型網路的組織職能往往是由價值鏈中創造核心附加價值的企業來履行的,例如通用汽車公司和豐田汽車公司就分別構建了一個由眾多供應商和分銷商組成的垂直型網路,網路內企業通過緊密合作達到及時供應和敏捷製造,大大提高了效率、降低了成本。

3.市場間網路

市場間網路是指由出於不同行業的企業所組成的網路,這些企業之間發生著業務往來,在一定程度上相互依存。市場間網路最為典型的例子是日本的財團體制,大型製造企業、金融企業和綜合商社之間在股權上相互關聯,管理上相互參與,資源上共用,在重大戰略決策上採取集體行動,各方之間保持著長期和緊密的聯繫。金融企業(包括商業銀行、保險公司和其他金融機構)以股權和債權形式為其他成員企業提供長期、穩定的資金支持,綜合商社為成員企業提供各種國內外貿易服務,包括原材料採購與成品銷售、提供貿易信用、規避交易風險等。

4.機會網路

機會網路是圍繞顧客組織的企業群,這個群體的核心是一個專門從事市場信息搜集、整理與分類的企業,它在廣大消費者和生產企業之間架設了一座溝通的平臺,使得消費者能夠有更大的選擇餘地,生產者能夠面對更為廣泛的消費者,有利於兩個群體之間交易的充分展開、機會網路在規範產品標準、網路安全和交易方式方面起到了關鍵作用。典型的機會網路核心企業包括早已存在的郵寄產品目錄公司和剛剛興起的電子商務平臺企業(如亞馬遜eBay等),它們將眾多生產者和消費者聯繫起來,共同構成機會網路。

網路型組織的基本特征

企業內部的網路型組織結構是不確定的,各個公司的網路型組織也並不一樣。但它們都有一些基本特征:

1.合作、民主、自由、寬容。知識化生產時代的產品特點是不斷創新,且是以創造性勞動為主。但是,創新所需要的知識和信息的集合從來就是分佈不平均的。創造性勞動需要上級尊重下級,鼓勵創新,允許失敗,鼓勵不同意見相互交流。網路型組織與此相適應的形式有:合理化建議、同級業績評議等等。

網路型組織的另一個重要特點是自由和寬容的組織文化。例如,3M公司在管理上允許員工有部分上班時間做一些個人的興趣愛好,IBM也允許員工在工作時間做“私活”;有的公司實行自我管理、自我評價,如自行確定工作定額;實行分權和授權,更好地激發和利用人的興趣和愛好。

2.網路型企業供給關係以企業間合作為基礎,企業邊界模糊。在新企業網路型供給關係下,合作具有更為重要的地位,核心企業可以幫助供應商解決技術問題,節約的成本則雙方共用;供給企業也可以修改核心企業的設計要求,減少的成本也可以雙方共用。企業由追求自身利益最大化轉向追求整個價值鏈供應鏈)上的價值最大化。

這樣的合作關係使得企業與企業之間的傳統界限變得模糊,這些相互聯繫的上下游企業組成了一個更大的虛擬企業,也稱之為虛擬一體化供給鏈。

3.網路型組織通過團隊(基層項目小組和高層管理專業小組)來適應創造性勞動對知識的密集性要求。創造性勞動需要不同知識背景的人相互組合,企業團隊就是由此而產生。團隊是加強合作、加強信息交流的一種方式,也是網路型組織的一種形式。

4.網路型組織通過權力和責任本地化來激發人的積極性、能動性與自我管理能力。在實行分權和授權的變革後,即使在非獨立核算的下級單位,決策也並非是由上級部門作出後下達執行,而是下級部門自行決策後上報,或上級與下級商議後決策;重要的不是權力而是業績。設立利潤中心成本中心、劃小和建立獨立的核算單位(以自我管理團隊為核算單位)也是網路型組織的特征之一。

5.網路型組織具有柔性化的特點。柔性化是指在組織結構中設置一定的非固定和非正式或臨時性的組織機構,這些組織機構往往是以任務為導向的,可以根據需要而設置或取消,與正式的組織機構有著網路型而不是直線型的關係。

6.網路型組織具有多文化、個性化和差異化的特點。在網路型組織中,每一個人都是網路組織上的節點,他們之間的聯繫比在傳統直線型組織下更密切。企業內部多種文化和差異、個性則有利於知識和信息的整合。

7.網路型組織通過學習和培訓增加組織的知識密度。具體形式有:職工培訓、教育投資、多崗位輪換等。

扁平化組織模式新架構

扁平化組織結構本身的特征以及嬗變過程,本質上要求其必須對傳統工業企業的組織模式進行變革。近年來,適應內外部環境劇烈變化而出現的扁平化趨勢,不僅使金字塔型的傳統組織模式正在失去效力,而且,使企業與企業之間的組織模式也在發生變化。貫穿於內、外組織變革過程的,是扁平化組織特有的知識共用和部門、組織間的協作。

(1).扁平化組織的內部組織模式

知識團隊構成了扁平化組織內部組織的基礎。美國著名管理學家德魯克指出,“由於現代企業組織由知識化專家組成,因此企業應該是由平等的人、同事們形成的組織。知識沒有高低之分,每一個人的業績都是由他對組織的貢獻而不是由其地位高低來決定的。因此現代企業不應該是由老闆和下屬組成的,必須是由平等的團隊組成的。”扁平化組織本質上可被視為是一知識體系,其競爭優勢的建立主要在於如何通過在一個精益的組織內,對組織所擁有的知識、信息進行整合、創造和管理,從而更直接地面向市場、面向用戶。為了支持這種知識、信息的整合、創造和管理,扁平化組織內部不是以職能為單位,而是形成一個個動態的知識團隊,這種團隊將個體和組織結合起來,促進用戶知識的顯性化和實體化,最終形成完整、統一的市場知識和轉化機制。根本上講,扁平化組織的運作核心就是通過這種知識團隊的自我管理,不斷釋放整體知識能量,進而實現企業價值創造空間的創新和拓展。

1.知識團隊運作的基礎

團隊之所以能成為扁平化組織構造的基礎,其實是同扁平化組織基本特征相關的,在扁平化組織中,人力資源成為組織的第一資源,而人力資源的本質就是凝聚在人身上的知識、信息、技能等。扁平化組織對人力資源的高要求,使得知識員工成為企業知識(特別是市場知識和用戶知識)的主要載體,決策中心下移導致的組織分權化和扁平化,共同促進了團隊代替科層。

2.團隊成員角色的專家化

知識團隊運作的目標追求知識、信息的共用、轉化和創新,為了達到這種目標真正依靠的只有是自我管理的知識專家。這種專家化要求知識團隊成員知識的互補性,因為,團隊項目任務的完成需要不同的專門知識,例如一個戰略咨詢項目需要營銷、生產、人力資源等相關領域的知識,知識團隊成員都應該有自己專長的領域,團隊任務的完成需要這些不同領域的專家協作,協作過程同時也是互相學習的過程和知識的共用、轉化和傳新過程,通過不同領域的專家進行面對面的工作交流,交叉知識的產生其實就是知識的創新。因此,知識團隊成員角色的專家化是團隊知識鏈能力放大機制的前提和基礎。

3.設定團隊目標

作為扁平化組織特定的知識鏈主體,知識團隊必須擁有自己的知識目標。同時,作為組織的一個基本單位,團隊的知識目標必須符合扁平化組織的總體知識發展的要求,或者說團隊知識鏈的效率體現必須要滿足組織整體的知識演化目標。因此,設定團隊目標,既是團隊的共同願景,有利於團隊本身知識的穩固和創新,更為重要的是,能夠實現與組織知識鏈的有效整合,獲得知識的協同效應

4.建立支持結構

知識團隊作為扁平化組織內部的組織基礎,必然涉及與企業整體的介面。在設定團隊目標時,要求團隊目標同企業目標保持一致,但在執行過程當中,存在許多不可控因素,為了進行協調以最大程度發揮團隊的知識能量,完善團隊的 外在組織支持結構將非常重要。扁平化組織的團隊模式是以知識鏈團隊為工作核心,同時有高層知識團隊進行協調,專家系統進行必要的支持。

(2).扁平化組織的外部組織模式

知識不僅在內部具有分佈性(導致決策中心下移),同時,知識還分佈在企業外部,扁平化組織並非知識孤島。為了更好服務於市場,其運行過程中必須吸收供應商、客戶、競爭者和其他外部組織的知識,而扁平化組織的競爭優勢也正在於與其利益相關者之間的密切聯繫上。

1.企業的知識合作機制

扁平化組織具有知識鏈構造的特點,知識團隊就可視為一條知識鏈,團隊對內外部知識選擇、吸收、記憶、轉化、創新和產出,形成一條無限迴圈知識流動的鏈條。知識鏈不僅存在於企業內部團隊層次上,也存在於組織層次上,存在於組織和社會群體之間。扁平化組織同外部組織的知識鏈交流其實是通過知識聯盟實現的。知識聯盟還表示不同的扁平化組織之間的關係,企業是一條知識鏈,一個企業可以參與多條知識鏈,因而不同知識鏈之間存在交叉,當一個企業和其他的企業建立一種知識創新聯合體時,一個知識聯盟就形成了。

知識聯盟的中心目標就是學習和創造知識,特別強調通過聯盟從其他組織學習和吸收知識,或者同其他組織合作創造知識,從而對市場、用戶的需求滿足不僅僅局限在企業本身、企業知識範圍內。知識聯盟的建立主要是基於組織資源、知識和能力的互補性,即聯盟一方具有另一方不具備的資源、知識和能力,以實現聯盟伙伴共同受益,共同服務於同一市場、同一用戶,滿足它們的要求。因此,知識聯盟既密切了其成員組織之間的關係,有助於組織之間相互學習彼此的知識和能力,也有助於組織之間的知識結合,從而創造出新的交叉知識,更有益於市場目標、用戶需要的實現。此外,知識聯盟可以有效地實現聯盟伙伴之間的隱性知識的轉移。如果聯盟伙伴之間只簡單地傳遞顯性知識,那就不需要知識聯盟,而只需買本書或一套公式或參觀瞭解就可以了。所以知識聯盟的重點是學習和吸收對方的隱性知識,其關係就像師徒關係,允許聯盟伙伴之間的各層次人員進行面對面的互動式學習和交流,通過“乾中學”和“教中學”,實現大量隱性知識的交流和滲透,達到所需知識的有效轉移。更為重要的是,知識聯盟中組織的“異質性”避免了組織與文化的內部一體化所造成了思維的“路徑依賴性”,甚至組織間知識相互激活的可能性遠遠高於一體化組織內知識相互激活的可能性。聯盟成員擁有知識的多樣性和異質性更容易導致思維的碰撞,產生嶄新的交叉知識。

2.知識聯盟的管理

第一,建立互動學習的模式,有效促進隱性知識的轉換。互動學習是指兩個企業或多個企業結對或聚群學習。在互動學習中,“學生”企業可充分接近“老師”企業,不僅可以學到“老師”企業中的顯性知識,更重要的,還可以學到“老師”企業的隱性知識,如“怎樣做”和“為什麼這樣做”方面的知識和技能。通過知識聯盟,建立了互動學習的模式,加強了師生間面對面的互動交流與切磋,通過“乾中學”和“乾中教”,實現了隱性知識的有效轉移。通過觀察和模仿“老師”如何做,學會了做事技巧和那些連“老師”本人也不十分清楚的知識,而這些隱性知識僅在一個人面對面模仿另一個人時才能學到。

第二,加強有關知識的學習和積累,不斷提高吸收能力。知識聯盟的核心是企業通過學習知識來培養自身的核心能力。因此,企業的吸收能力的大小,直接關係到企業能否形成核心能力。企業之間的學習效果取決於“學習”企業三方面的能力:認識和評價外部新知識的能力、消化吸收新知識的能力和利用新知識進行創新應用的能力。要提高認識和評價外部知識的能力,關鍵是自己要具備一定數量的、與外部新知識相關的基礎知識。因此,企業在尋找知識聯盟時,必須加強自身有關知識的學習和積累,不斷提高自身的知識存量和改善知識結構。要提高消化吸收外部新知識的能力,實質上是提高企業內化外部知識的能力。企業要在這個內化過程中建立起相應的知識處理系統,以實現外部知識的高效轉化,將內化為企業的知識根植於已建立的知識系統中,形成企業特有的知識——企業核心能力的基礎,從而捉高企業內化外部知識的能力。要提高知識的應用創新能力,必須依賴企業本身的整合能力,而整合能力來源於企業解決自身問題實踐中的不斷“試錯”。企業要鼓勵個人、團隊不斷實踐,敢於“試錯”,以積累各種經驗。

第三,選擇合適的知識聯盟的方式,保證聯盟的時效性。知識聯盟的目的是學習隱性知識,而隱性知識的學習需要一定的時間,這樣才能產生潛移默化的效果,短時間內不可能實現隱性知識的有效轉移。因此,如何選擇有效的方式來保證聯盟的時效性就成為問題的關鍵。企業應根據自己的現狀、企業與聯盟組織之間的關係和經歷等因素來綜合選擇。

第四,加強人力資源配置。由於核心能力實質是“組織中的積累性學識”,而學識的載體是人,核心能力只有通過組織中人的學習才能獲得,因此對知識聯盟的管理重點在於對聯盟的人力資源管理,建立一支支持組織學習過程的人力資源系統。

組織扁平化的條件與步驟

並非所有的企業都適合組織扁平化的,它有一定的適用條件與範圍,並受一些社會因素的影響。

根據企業成長理論,扁平化組織結構應該與一定企業發展階段相匹配。

组织扁平化

如圖,企業成長可分為五個階段:創業階段、集體化階段、規範化階段、精細化階段與合作階段。在精細階段以前,隨著規模不斷擴大,影響區域的日益擴張,企業需要不斷提高科學管理水平,完善規章制度;企業的管理層次也會隨之增加。在合作階段,企業變得越來越龐大,進入國際化市場。但隨著企業機構的高度官僚化,指揮與反饋鏈條越來越長,企業對環境的反應也會越來越遲鈍,此時,企業需要組織扁平化,簡化管理層,縮短指揮鏈條,恢復企業對環境的靈敏性與活力。

組織扁平化要求管理者素質的提高。組織扁平化的過程中必然引起中間管理層的削減。傳統的管理理論要求管理幅度在7人以下為宜,否則會降低管理的效率;而在組織扁平化後,新的組織結構要求管理幅度大為增加,在管理人員減少的同時,要保證管理效率不下降,必然對管理者的素質與能力要求有所提高。

組織扁平化要求Intranet技術的支持 。Intranet技術是組織扁平化的必要支持之一,它比以往任何網路技術更利於發揮扁平化組織的績效。團隊成員工作共用、團隊之間信息交流、團隊與上下層溝通都可通過使用E-mail、OA系統MIS系統等現代網路技術與工具進行溝通,在提高工作效率的同時,大大增加管理幅度。美國組織結構專家郝瑪•巴拉密說:“減少層次和壓縮規模趨勢源於降低成本的需要,當然它們也反映了信息和通訊技術對管理的衝擊。中層管理的作用是監督別人以及採集、分析、評價和傳播組織上下和各層次的信息。但是,它的功能正隨著電子郵件、聲音郵件、共用資料庫資源等技術的不斷發展而減弱。” 組織扁平化的基本實現途徑是流程再造。流程再造即藉助信息技術,以重整業務流程為突破口.將側重於縱向控制的職能部門改造為側重於橫向協作的團隊,實現以顧客需求驅動組織運行。

組織結構的扁平化是一項長期的、艱苦的重大變革,牽涉到的人多面廣,因此要有計劃地、有層次地、有步驟地推行方可見成效。企業實行扁平化工程一般應遵循以下幾個程式:

1.實行危機管理,塑造緊迫感。當經濟景氣時,企業經營者只要把企業放在恰當的環境中,便可確保企業獲利;但是一個組織的生命、有其周期性,當經濟不景氣或者競爭加劇,面臨生死存亡之際,許多偉大的策略也許無用武之地,於是企業必然重新調整其步伐,把經營的重點放在組織結構的設計上來,確認組織變革的必要性。

2.分析現在的組織與工作流程,診斷組織的癥結,提出合理化方案。描繪美麗遠景,以此指點變革努力的方向並建立強有力的指揮組織,而且由高級主管挑頭;鼓勵工作小組發揮團隊合作精神。

3.選擇變革的方案,並推進組織變革。在實施之初,一是要選擇好變革的時機,在企業經營危難之際,也許會得到更多員工的認同,此時變革會順利、快速得多;二是要確定組織變革的範圍和層次,組織重構可以在全公司同時全面展開;也可以分階段、分部門依次實行,然後擴展到全局,這樣可以積累經驗,逐步推廣,從而取得最後的成功。

4.教育培訓。激勵員工,設法消除裁員給員工心理上游來的恐慌是新組織發揮作用的關鏈,用快速有效的管理溝通方法使員工理解變革的必要性,同時強調其個人未來發展的良好機遇。否則,不管是在組織重組過程中還是在重組後.士氣和生產率都會顯著降低,導致整個改組工作的失敗。

西方企業組織結構扁平化

西方企業組織結構扁平化的緣由

自工業革命以來,英國經濟學家亞當·斯密的勞動分工理論幾乎一直成為傳統的西方企業組織結構設計的核心,並由此逐步形成了具有絕對統治地位的傳統的企業組織形式——科層制組織。這種組織形式,以提高勞動生產率為目標,特別強調分工,其組織結構形式,從縱向看,是一個等級分明的權力金字塔,組織被劃分為若幹層次,處在金字塔塔頂的高層管理人員通過管理的“等級鏈”控制著整個組織;從橫向看,組織被分解為若幹個併列部門,每一個部門負責一個專門的工作,按照部門的職能,各司其職,各自獨立。這種組織,縱向是一個以等級為基礎,以命令控製為特征的金字塔結構,橫向是一個以“直線組織”為支柱、以部門職能為核心的框架結構。它的基本運行法則是上層決策、中層管理、基層執行。這種等級分明、分工精細的組織在過去一個相當長的歷史時期曾經起到了提高勞動生產率、提高質量和降低成本的積極效果。但它只適合於以前市場經濟和條件相對比較穩定的時代。那時,由於信息傳遞的不暢,加上工人受的教育一般不多,因此企業需要建立這樣一種體系來收集管理信息,並對工人實施監督。

90年代以來,西方企業面臨的經營環境也發生了巨大變化,多層次的金字塔型科層組織已顯得笨重、遲緩而缺乏靈活性和人情味。而扁平化組織是組織模式的根本性改變,通過減少管理層次、壓縮職能機構、裁減冗餘人員而建立企業的縱橫向都比較緊湊的扁平化結構,使得組織變得靈活、敏捷、快速、高效,從而使企業在變化莫測的市場經濟競爭中立於不敗之地,正如科特所評價的那樣:“一個有更多代理即有一個平坦層次結構的組織,比一個在結構中層有臃腫結構的組織處於更有利的競爭地位”。

西方企業組織結構扁平化的理論淵源

組織扁平化的理論淵源最早可追溯到新制度經濟學,以1937年科斯《企業性質》為開端,之後,又由阿爾欽德姆賽茲威廉姆森等人加以拓展的新制度經濟學提出了企業乃“一系列合約的聯結”的命題,指明瞭企業的合約聯結性質決定了企業並非必然是等級分明的科層組織。1990年哈默錢皮提出革命性企業再造概念,通過對公司的流程、組織結構、文化等進行徹底的急劇的重塑,以達到績效的飛躍。哈預設為,企業再造就是從根本上打破傳統的、建立在縱向勞動分工和橫向職能分工的運作體系,提出以新設計和重建的作業程式(流程)作為企業組織結構基礎的組織形式。美國麻省理工學院教授維斯特尼和馬林等人總結了管理界對再造後“新組織”的論述,認為“新組織”有網路化、扁平化、靈活化、多元化、全球化等特點。1997年道赫德總結:“90年代激烈的全球競爭導致了兩類不同性質的組織創新,一類是以降低成本為目的,另一類則是以提高企業核心能力為目的的。後者突出的表現為使組織更加扁平化、更具柔性和創造性。”

組織結構扁平化對企業管理的影響

1.企業在勞動分工基礎上,更強調系統觀念。組織結構扁平化,旨在讓員工打破原有的部門界限,繞過原來的中間管理層次,從而以群體和協作優勢贏得市場主導地位,因此系統和協作觀念是貫穿扁平化組織組建和運作的核心概念。正如系統學家馮·伯塔朗菲指出的那樣,一個企業組織是一個由許多相互作用的部分組成的開放系統,管理人員應用系統方法就可以闡明系統目標,確定評價系統工作成績的標準,並把企業同各種環境系統更好地聯繫起來。

2.減少中間層,導致“中層革命”。美國管理學家德魯克指出:“組織不良最常見的病癥,也就是最嚴重的病癥,便是管理層次太多,組織結構上一項基本原則是,儘量減少管理層次,儘量形成一條最短的指揮鏈”。面對組織規模的擴大,傳統組織理論認為,由於管理者受精力、知識、能力、經驗的限制,所能管理的下屬人數是有限的。因此,惟有增加管理層次才能實現對人員的管理和控制。然而現代信息技術的發展使得信息、知識的共用可通過電腦網路得以完成,溝通的順暢直接導致原先承擔上傳下達任務的中層管理人員人數的大大減少,帶來“中層革命”。

3.知識的影響力凸現並日益加強。扁平化組織中,影響力並非完全來自職權,知識、信息、人格魅力等有時往往超越職權的影響範圍,在決策和日常運作過程中發揮更大的作用。

4.靈活指揮。統一指揮原則似乎已成為管理的金科玉律。但組織相對簡單時,這一原則顯然是合乎邏輯的。但隨著組織規模的擴大,統一指揮原則經常無法實現,而靈活指揮成為企業控制過程的靈魂。

5.分權。與扁平化相輔相成,分權成為一種必然趨勢,柯達公司總裁羅伯特說:“過去我們的機構臃腫龐大……惟一能使我們發揮協調作用的辦法是縮小機構”。

6.加大控制幅度。信息化、電腦化帶來的間接控制與指揮使控制幅度加大,從而也使“中層革命”和扁平化成為一種現實。

相關鏈接

經營企業,是一門大學問!

有的公司,發展前景欣欣向榮,

公司整體氣氛很有活力;

也有公司表面光鮮亮麗,內部卻死寂一片。

 

當你的公司出現以下這 5 個特徵時,

你就要當心工作不保了…

 

趕緊來看看吧…

特徵一、無大將可用

 

「千軍易得,一將難求。」

這是中國俗語,也是一個顛撲不破的真理。

如果你的企業做大了,

1 個億、10 億,甚至上百億,

如果你找不到大將可用,那你就距離失敗不短了。

 

三國時「蜀中無大將、廖化做先鋒」的故事,

正在中國很多的中小型企業中蔓延。

很多老板還沾沾自喜說自己年輕能幹,

卻不知道自己已經成了企業發展的最大障礙。

 

因為這樣的老板雖然能力很強,

但是在沒有大將的情況下,

往往戰略清晰,戰術失誤。

更可怕的是,在這樣的企業中,

就像三國時候沒有人懷疑諸葛孔明一樣,

老板的旨意成了企業的發展方向,

最終會給企業造成失街亭的危險。

沒有大將,企業就沒有跨越發展的機會。

 

特徵二、中層無能

 

比沒有大將更可怕的,

是企業的中層沒有思想、十分無能。

在我走過的企業中,

中層無能的企業至少在中國占據 60-70%。

很多人都在研究中國企業平均壽命只有 4-5 年,

卻不知道,80% 的企業失敗都和中層無能有關。

 

三鹿的失敗,很多人說是質量問題,

而熟悉三鹿的人都知道,是中層問題。

中層是市場到高層的連接帶,

也是執行和解決市場問題的核心力量。

如果這個層級出現問題,

可以說,企業距離關門的日子就不遠了。

 

 

特徵三、一線腐敗

 

在一個中國式的企業生態中,

腐敗似乎已經是一個普遍的問題了。

如果一個企業家遇到了正直的大將和中層,

那麼我告訴你,你肯定是祖上顯靈了。

 

好比快消品領域,腐敗很常見,

有和經銷商吃公司費用的,

又兼職給別的企業打工的,

有還自己開店的,有費用作假的,

損公肥私、吃裡扒外的,有內外勾結的等等。

 

 

(圖片來源)

 

特徵四、只開會不決策

 

有激情的企業家都有一個共同的特徵,就是決策力。

這個決策是既快又準。

而要達到這個能力的核心,便是要抓住事物的本質和重點。

無數沒有激情的企業家,

天天主持會議,天天研究的同樣的問題,而天天都沒有結論。

天天在開會,天天紙上談兵,

那你就一定是在給企業的衰敗注入基因。

 

 

特徵五、老板愛聽奉承

 

今天成功的企業家中,誰不愛聽奉承?

問題是,多數成功者能夠分清楚

什麼是由衷的讚美,什麼是奉承。

 

喜歡奉承的老板的下屬一般有三個目的:

一是從你那裡要拿到利益;

一是要給你進讒言;一是要架空你。

可以說,這樣的企業未來在哪裡?

如果你的公司出現這幾個徵兆,

恐怕要準備另謀高就了…

身為老闆的你,

也要避免公司出現這些問題唷!

 

好文章 分享給朋友吧~