管理者的困境:放權或者崩潰

編者按:原文作者Dreck Sivers是CD Baby網站的創始人,CD Baby是全球最大銷售獨立音樂人CD的網站。Dreck自己也是一名音樂人。他榮獲2003年“全球技術獎”,被《時尚先生》雜誌評為全美年度“最傑出和最睿智”封面人物。

大多數管理者都會陷入放權的困境。你很忙,每件事都要親力親為。你很清楚自己需要別人幫忙,但你沒有足夠的時間尋找並培訓別人來幫你。所以,你更加努力地工作,直到自己崩潰。

下面這個故事講述了我如何放權。

2001年,CD Baby成立三周年。我已有8名員工,但所有其他事情仍然需要我自己做。每週7天,從上午7點工作到晚上10點,自己仍然要經手每件事情。

每隔5分鐘,就會有員工向我請示:

  • “Derek,有個傢伙想修改網站上已經存在的相冊,我該怎麼跟他說呢?”
  • “Derek,我們可以接受電匯作為一種支付方式嗎?”
  • “Derek,有個人今天下了兩個訂單,他想知道我們可不可以給他一起郵寄過去,並且把節省的郵費給他退回去?”

如果整天不停地回答問題,那麼什麼事也做不成。我感覺我好像是每天去上班,然後在過道裏坐著,全職回答員工的問題。

我的忍耐已經到了極限,我不再去辦公室,並且關掉了手機。隨即,我意識到自己正在逃避問題,而不是去解決問題。我必須解決這個問題,要不然就壞了。

經過一夜的反思,我最終在思想上接受放權。

我必須放權,我不是我公司的必需品,沒有我,我的團隊照樣也可以經營公司。

第二天,我一進門,有人就請示我,“Derek,我們昨天收到了一個客戶送來的CD,但他今天改變了主意,他想讓我們退回他的CD。我們給他郵寄了回去,但他又問我們能不能退還他的安裝費用,因為他從未登錄過網站。”
這一次,我並沒有僅僅回答了他的問題,而是把大家都召集起來。

我給大家解釋了事情的經過,和需要解決的問題。我回答了問題,但更重要的是,我解釋了自己思考的過程和回答背後的理念。

“是的,我給他全額退款了。這樣,我們會受到一點損失。但是,最重要的是經常做一些能讓顧客高興的事,只要不過分就行。像這樣一個小小的表示對我們大有裨益,他可能會因此告訴他的朋友們,我們是一家不錯的公司。每個人都要記住,幫助音樂愛好者是我們的首要目標,利潤是其次。你們將來可以根據這條準則來自己做決定,我會完全同意。做那些能讓他們高興的事。要確保每個跟我們做生意的人都會滿意而歸。”

我一一問了每個人,確保他們都理解我的回答。

我讓一位員工起草一本手冊,把這種情況的處理方式記錄下來,並附上解決這種問題的理念。

然後,每個人都回去工作了。

十分鐘之後,新的問題,相同的過程:

  • 1. 召集所有人
  • 2. 回答問題,解釋理念
  • 3. 確保每個人都理解整個過程
  • 4. 讓一名員工把這條記錄在冊
  • 5. 讓他們知道,下次沒有我他們也可以這樣處理問題

2個月之後,沒有員工請示了。

然後我想員工們展示了事情的最後一部分,也就是我自己的工作。作為學習的一部分,他們也需要把這個記錄在冊,然後給其他人看(由教而學)。

現在,公司完全不需要我了。我開始在家裏工作,不再去辦公室了。我甚至教過他們我關於雇傭新員工的思考過程和理念。所以,有兩個新員工是完全由他們發現、面試、雇傭以及培訓的。他們用那本手冊來讓每個新員工理解這種理念以及它的歷史,並且知道怎麼自己做決定。我每週去視察一次,確保一切正常。確實一切正常,他們甚至都沒有什麼事情向我請示。

因為業務由我的團隊負責運作,我可以心無旁騖地改進業務。我去了加利福尼亞,只是弄清楚事情由他們運作。

我現在仍然每天工作12個小時,但是,我把所有時間都花在業務改進、優化以及創新上。對我來說,這才是最有趣的事情。這是在玩,不是工作。

我放權之後,公司市值在四年裏從一百萬增長到兩千萬。管理者和企業家之間有很大的不同。作為管理者你會感覺很自由,直到你意識到如果自己不工作,公司就會倒閉。

要成為一名真正的企業家,你要確保自己能夠離開一年,而當你回來時,你的公司比你離開時運營得更好。

 

如果你不是Programmer,怎麼聘請Programmer呢

 

你需要注意一下幾點:
1. 他們有多堅持己見(固執)呢?

詢問他們有趣的編程主題(如Ruby或Python?)。從他們回答的語調和推理中,可以得到很多資訊。在我們最近一期節目中 ,傑夫說:“當人們對事情有強烈的見解,當他們可以大篇幅地談論一些事情時,這就是一個很好的跡象表明他們對這件事很有熱情。”

2.他們為開源專案做了多少貢獻?

看看他們的貢獻。雖然你可能不是一個programmer,你仍可以知道他們是否寫過一些代碼。而事實上,一個人有所貢獻,是一個良好的開端。“事實上,一直在貢獻意味 著他們正在使用這種工具,”Jamis說。“這就好比抓癢,就像他們接觸到一些他們認為應該加以改進的程式,或接觸到一個錯誤並且自己修復了那個錯誤。參 與程度對programmer是一個很好的鑒別標準。”

3. 他們有多享受編程?

他們不需要在自由時間的分分秒秒都去敲代碼,但是你確實想看到一定程度的熱情。Jamis說,“與其說在業餘時間編碼本身是最重要的事情,不如說它展示了你熱情的態度和有自己的見解。”

4. 他們真的掌控工作? (Do they actually ship?)

瞭解他們如何管理自己的工作。軟體通常出小錯誤——瞭解他們如何避免這種情況。瞭解他們什麼時候按時地完成了項目,並詢問為什麼這個項目是成功的。或 從延遲項目中吸取了什麼經驗教訓。“控制軟體運行的能力是關鍵的,”據傑瑞米說。“他們是如何管理實際需要的任務並在一定的時間內完成,這是很重要的。”

5. 他們掌握了什麼?

皮克斯(Pixar)公司的蘭迪·納爾遜認為,能夠掌控任何一件事意味著也能夠掌控其他事。所以尋找那些掌控著一些事的人。候選人是一個優秀的廚師 嗎?或山地車選手?還是其他什麼人物?”這是一個跡象表明他們也可以做您項目的主導者。“那是一種即使其他登山者幾乎馬上就要到達山頂,仍感覺我將要先到 達山頂的感覺,”尼爾森說。“如果一個人在來到你工作場所之前都沒有涉足,那麼他成為工作的主導者的可能性也是很小的。”

6. 他們的溝通能力如何?

你對編程瞭解的越少,你越需要依靠一個人去解釋程式進度。這就是無論什麼職位都要聘請大作家的原因,這是個好主意。例如,這兒有傑夫解釋的在計畫方案內Basecamp API人員更新到其他專案的例子:

我只是對Basecamp 和Companies APIs的人員進行更新調整。

我們現在允許客戶和公司員工去接觸通過專案認識的人和公司。在此調整之前,公司員工和客戶只能看到對方使用的特定的項目ID。沒有辦法讓他們看到在項目過程中參與的所有人(例如,同事)。

例如,如果API用戶發出的請求,一個是鮑勃,另一個是吉爾,那麼/ people.xml文件將返回給鮑勃和吉爾。如果請求的用戶是管理員, 那麼帳戶中的所有的人都能收到。
這同樣適用於公司管理。

如果一個programmer既能夠編碼,又能講非programmer能聽懂的的話,那麼很多事情是不太可能出問題的。(編注:上面這6點,是招聘官需要知道的注意事項。關於在聘用programmer或開發人員的時候,需要問哪些問題,

試用 Test drive

如果可以,擯棄“全要或無用”的決策模式。雇用一個全職員工是一個很大很困難的決定。為小項目聘請員工,讓他們在空閒時間完成這些專案,這種方式更容易為雙方所接受。《Getting Real》 中的“淺嘗輒止” 一文中談到:

在聘請任何人之前,先給他們一個小項目來考慮。我們就會瞭解他們對待這個項目是如何溝通,工作的,等等。當他們設計或者編寫的時候,就會給你帶來很多發現。你會相當快的學習,無論氛圍是否恰當。

可以用日程安排來堅持這種方式,即使只需要20或40小時,也比什麼都沒有要好。適合或者不適合,都會顯現出來。如果沒有,那就是雙方想要先測試工作而隱藏了自己的問題與風險。

仔細考慮一下,你能提供什麼,並且如何才能讓你的職位盡可能的吸引人,這也是個不錯的主意。壺裏的蜜越多,才會有越多的蜜蜂飛進去。(恩,不管怎樣, 可以肯定這不像一個東西放在那一樣)在《Great Hackers / 偉大的駭客》中保羅點格雷厄姆提供了一份列表,關於如果吸引最優秀的programmer:優秀的開發工具、開源軟體、帶門的房間、一個感興趣的問題和聰明的同事。如果 你有其中的任何一項或者全部,確保讓潛在的雇員能夠瞭解到。

自己動手?

所有這些都會有所幫助,但是很顯然,聘請programmer最好的方法是你自己能至少瞭解一點編程。聘請一份你從來沒有做過的工作,真的是件很困難的事。因此,要在聘請了那些人之後管理他們,格雷厄姆在他的《偉大的駭客》一書中有過如下討論:

我看過關於如何管理programmer的一些文章。事實上有兩種:一個是如果你是programmer,你該做什麼,另一個是,如果你不是programmer,你該做什麼。而第二種可以總結為兩個字:放棄。

問題不在於日常管理。實際上,真正優秀的駭客(hacker)是自我管理的。問題是,如果你不是駭客(hacker),你就不會知道誰才是真正優秀的駭客(hacker)。

確定自己是否能在招聘員工之前瞭解一些編程技術。事實上,傑森在與DHH合作之前就已經開始學習PHP了。同樣的,在我們當中有人學會如何配置伺服器之前,37signals不會聘請系統管理員。如此做來,你就會對尋找應聘者以及你想解決的問題有更深入的理解。

至於你在這過程中犯的錯誤,要記住,這就是“真正的”programmer的工作方式。“運行迭代感覺就像永遠反復的錯誤校正”傑瑞米解釋到。“這聽起來很令人洩氣,但這卻是允許的。該死,甚至測試驅動開發也是反復的錯誤校正。所以,建議你應該先從自己做起。”

日本岛正在下沉

根据钻孔的岩性及年代测定,人们揭示了这块古陆的变迁历史。岩芯中的底砾岩不可能由日本列岛供给,因为439站与日本列岛之间存在着距今6700万-2500万年的老第三纪沉积盆地,因此只能由附近的陆地供给。科学家对这些砾石进行了同位素年龄测定,得到的平均值大于2200万年,这种砾岩的产生,大概是新老第三纪的交界时期在陆地上进行的。据此似乎可以认为,在6700万-2500万年前的老第三纪末,亲潮古陆开始下沉,覆盖在不整合面上的砾岩层成了上部地层的底砾岩。接着沉积了100米厚的浅海砂岩,以后就保持着深海沉积的特性,从新第三纪到整个第四纪时期沉积了近1000米厚的沉积物。其中含有较多的火山灰及硅藻等物体古生物化石,更奇的是距今约1000万年的地层中还含有冰川漂砾,这可能是由冰块或冰山带来的。看起来,这块古陆真是饱经沧桑,在2200万年期间,它竟下沉了近3000米。古陆上不但沉积了大量陆源物质、生物碎屑,还经受了无数次火山喷发的洗礼和冰川、冰块的光临,使其难见天日,而且还会有继续下沉的趋势。

在水深不超过200米的近海大陆架海域,水下探险家们常常发现海底有古森林的遗迹、沉溺的河谷、水下阶地,甚至人类居住的遗址。种种迹象表明,这里曾经是繁华的陆地。那么,为什么过去的陆地现在被海水淹没了呢?不少学者认为,这与地球气候的变化有关。当地球处于寒冷的冰期时,大量的水凝结成固态的冰储存在大陆上,致使全球海面普遍比现代低。在距今约18000-2000年的玉木冰期最盛期,亚洲沿海的海面比现在要低130-160米,从而使现今的大陆架地区广泛出露成为陆地。以后,气候转暖,导致冰川消融,海平面上升,这些地区重新被海水所淹没。

可是,亲潮古陆却处在2600米水深的深海底,它的沉没,只用海平面上升来解释是行不通的。那么,这个深海古陆又是怎样沦为海洋的呢?这是人们关心的主要问题。

惟一合理的推断是,在白垩纪的某个时候,亲潮古陆发生过剧烈的地壳垂直运动。对于这一点,多数学者是认同的,因为人们已经找到了相类似的地质情况。然而,令人不解的是,在离日本海沟仅90公里的地方,在比较短的时间内,发生近3000米的垂直地壳升降,确实是十分奇特的现象。这引起了地质学家和海洋学家的极大兴趣,纷纷寻找它沉没的原因。

是不是因为火山喷发或地震造成地壳垂直升降导致亲潮古陆沉没的?因为这一带正是太平洋板块和欧亚板块的结合部,在2000多万年的时间里,频繁的地震和火山喷发完全有可能使亲潮古陆沉入3000米深的海底。但这种解释无法说明下沉近3000米距离的过程。

有一种流行的看法是,这块古陆的沉没可能是太平洋板块向欧亚板块运动的反映。可依据板块构造理论,板块主要作水平运动,然而亲潮古陆竟能在短期内发生如此显著的垂直下降运动,不能不使人产生疑问。一种意见认为,日本海沟是太平洋板块向欧亚板块俯冲的汇聚带,当其东侧的太平洋板块沿海沟向下俯冲时,可能使它受到了牵引,以致把当年的陆地也拖下了海底。

可是,疑问依然存在,因为这无法解释另一个类似的实例。那是一位于北美纽芬兰东北约550公里的海底山丘,叫做“孤儿海丘”,它现在位于海面下1797米。但深测资料却表明,在1.35亿年前的侏罗纪时期,“孤儿海丘”却是一个高耸于海面之上的陆地。后来它逐渐下沉,直到200万-300万年前的更新世时期才完全沉入水中。

“孤儿海丘”为什么下沉?能用板块构造理论来解释吗?孤儿海丘虽然也位于大西洋与北美洲大陆的交界处,但却不是两个板块的交界处,它和其他附近的海洋与北美大陆同属于美洲板块,东距板块边界即大西洋中脊达上千公里。因此对于它的下沉原因,眼下还难以找到比较合理的解释。

那么,亲潮古陆的奥秘解开了吗?不说别的,它究竟是一块曾与日本相连的半岛,还是一个独立的岛屿,人们尚未弄清楚,于是它为何下沉更使科学家们大伤脑筋。要想解开亲潮古陆沉没之谜,看来还需要借助于后人的智慧。

西方程序員眼中的東方程序員

世界的東方(印度/中國/菲律賓)

是西方(美國/歐洲)的主要軟件外包服務提供者。

  1. 你是否有過與這種離岸外包團隊合作的經歷?
  2. 如果有,感覺如何?
  3. 你對這些來自東方的程序員有沒有一些總結性的看法和觀點(比如:他們是否合作,是否能按時提交代碼,寫出的程序是否有質量?
  4. 依據是什麼?

讀者的回復很踴躍,其中一個被頂的最高的回答是關于印度人的,回答中他說一個印度分包商 給他們開發了一個組件,他認為這是他接觸過的最恐怖的程序,里面最大的一個文件體積超過600KB,大概有3萬多行。

KUI : 這個我倒也見識過-_- 什麼都弄到一個自己的文件上…….

他向上天乞求希望自己永遠不需要去維 護這樣的代碼。這位答復者說他在印度生活了3個月,發現東方人和西方人在文化上的差異很大,印度人很勤奮,但常常卻不能把事情做對。印度人里有個根深蒂固 的文化,就是從不說no,他說即使你到副食品商店里要求買一條毯子,店主也會說“是,先生,稍等一會”,然後派一個小孩到外面商店把東西買回來。這雖然在 生意上是好的做法,但未必適用于做軟件開發。

另外一個回復是關于俄國人的,同樣,他覺得這些俄國人寫的代碼頂多當作原型來使用,最終都會被丟掉,不能用。

我找了很久,終于在帖子的最底部發現一個關于中國程序員的回復,不過內容非常的有趣:

到現在,我在中國已經待了2年多一點時間了(我是個加拿大人),跟中國的開發人員一起共事你會感到非常的奇特。我敢說上面這些關于東方的程序員的總結都是正確的,至少對于中國人是這樣的。我遇到的/一起共事的大多數開發人員基本屬于這種情況:

  1. 缺少上進心和創造性。這里我並不想說他們很差勁或愚蠢。也許更可能是一種文化。在歷史上他們就有一種官本位和 崇尚權威的傳統。于是他們對來自“上面”的糟糕的設計從不提出疑議。同樣,他們更多的是關注技術技巧,而忽略業務領域知識。我費力九牛二虎之力教他們模式 和各種抽象概念,直到他們能應用這些東西到他們手頭的任務中。然而,過不了多久,就像是決堤的洪水,他們竟然肆無忌憚的挑戰權威,至少在技術層面上是這樣 的,我可不想弄得簽證被撤銷。
  2. 磨擦 前面這個問題說過,但我要強調一下。這也許是最重要的一個問題,是產生中國開發人員跟這里的海外同事(這里是加拿大人)共事時產生緊張關系的原因。通常, 我在這里共事的西方人會特意的夸大跟東方人共事時東方人的一些不好的方面。我這些加拿大同事對人友好但在代碼審查時極其的苛刻。如果發現這些中國程序員一 個小失誤或沒有使用好的編寫方法,他們就是發脾氣、大呼小叫。但當他們自己被禮貌的要求也按照這種要求完成他們自己的任務時,他們也會發脾氣、大呼小叫。
  3. 犧牲 中國人並不以介意使用蹩腳的二手器械。我坐壞了三把椅子後才終于要了一把稍微舒服一點的椅子。可是當我坐上這把較好的椅子後,突然感覺不是很好,因為看到 這些中國人仍然坐在好像是中世紀那麼原始的椅子上。然而,等我訪問了這家公司的總部後,我發現這里的程序員的一張桌子就有我們4~6個人的團隊的佔地面積 那麼大,更別提他們的椅子了!

在起初,他們編寫的程序並不是很好。這當然是文化上產生的裂痕,但這也是開始時糟糕的系統設計產生的很陡的學習曲線造成的。但你們知道嗎,兩年之後,這個系統中一些最優秀的模塊都是出自中國公司。于是這就更加明顯的導致了雙方程序員的磨擦加劇…
坦白的說,這幾年走過來不容易,以個人經驗判斷事情的趨勢,我認為對這個問題的看法是正確的。

做為一個中國人,對于西方人對我們的看法和觀點,我覺得不需要去急著找他們的論點漏洞進行反駁。你可感到到他們對東方人的不滿是一種普遍彌漫的氣氛,俗話說,蒼蠅不叮無縫的蛋,我們應該還是先從自身找問題,有則改之,無則加勉。

 

kui : 唉同志們加油啊…………………