程式碼之道

第5部分 (第2/4頁)

？ 所有功能和質量上的需求都可以被驗證。

我也已經談到了，我們還有機會把規範書寫得不那麼正式一點，並且更容易被理解。

那麼誰該為糟糕的規範書負責呢？其實我們都有責任。不過，糟糕的規範書主要還是由不良的習慣和糟糕的工具造成的。只要做一些小小的改變，並且使用大大簡化的模板，我們就能改進我們的規範書，改善部門之間的溝通，並且促進工種之間的關係。總而言之，這樣做可以讓我們在微軟工作得更加開心而富有效力。

第9章

成為管理者，而不是邪惡的化身

本章內容：

2003年2月1日：“不只是數字——生產力”

2004年9月1日：“面試流程之外”

2004年11月1日：“最難做的工作——績效不佳者”

2005年9月1日：“隨波逐流——人才的保持和流動”

2005年12月1日：“我能夠管理”

2006年5月1日：“不恰當的比較——病態團隊”

微軟文化中有這麼一部分：“不要抱怨任何事情，除非你已經為它找到了建設性的改進意見。”沒錯，我常常抱怨我們的管理層。更糟糕的是，我在這個公司的12年時間中有8年是在做管理者。“那你對管理者的改進有什麼建設性的意見呢？”很有趣，你應該這麼問。

如今，新任的管理者可以得到相當多的扶持，但是當我第一次成為一名主管的時候，我與以前的管理者共事的經歷成為了我惟一的資本。我做得還行，不過我也從工作中和我的導師那裡學到了大量的東西。5年之後，我加入了現在的這個組織。給新任主管和經理提供我曾得到過的有效而具體的幫助，成了我工作中頭等重要的事。I。　M。　Wright寫的關於管理的文章中，很多都直接來自於我為新任管理者準備的資料。

在這一章中，I。　M。　Wright論述瞭如何進行有效的管理，而不必讓你成為惡魔。第一個欄目教導管理者要合理使用度量，並指出了一名卓越工程師所具有的特徵。第二個欄目談到了面試和招聘。第三個欄目帶你一起走過了管理績效不佳者的敏感地帶。第四個欄目涉及到了人才的保持和流動。第五個欄目揭示了成為一名優秀管理者的最低要求，以及如何才能從優秀提升到卓越。最後一個欄目傳授了把一個病態團隊變得健康而富有生產力的秘方。

坦率地說，我從來就沒想要成為一名管理者。我已經做了17年成功的個體貢獻者和架構師。我最後成為管理者，是因為我對產品有一些自己的想法，我想了解如何去運轉起一個業務。令我驚訝的是，我發現管人比程式設計更加讓我著迷和滿足。也許其中的部分原因是我當上了爸爸——養育一群孩子跟發展一個團隊在很多方面是相似的。但更主要還是因為跟人相比，電腦是可預測的、死板的。哈，當然，電腦能夠給你帶來驚喜和快樂，但那個程度還達不到人給你帶來的。我仍然熱愛程式設計，不過我發現跟人打交道要更加有益得多。

——Eric

小心你希望得到的東西

2003年2月1日：“不只是數字——生產力”

只有我是這樣嗎，還是外星人接管了我們所有管理者的大腦，讓他們深信，數字能夠精確地代表一個產品的質量或者一個開發者的價值？我們到底還要忍受多少令人作嘔的資料收集、分析和預測，才能讓那些被誤導的管理者得到足夠的滿足，以使他們不再來打擾我們、讓我們能夠做自己的工作？如果我們能夠集中精力在編碼上面的話，我們其實能夠完成比現在多得多的工作，難道只有我一個人內心深處有這種感覺嗎？

不過，目前的趨勢是，對我們創作的東西及其創作方式做越來越多的“度量”，並且使用這些度量去判斷我們產品的優點——還有人的優點。似乎解放我們的大腦是有益的。你是否意識到，有多少自作聰明的管理者靠“編碼成功度量”給團隊成員評分，然後很輕易地就對他們判斷最正確的人放馬後炮？

作者注：《Interface》的編輯要求我寫一篇關於度量的文章。我不認為這就是當初他們腦子裡想要的東西，但最後期限擺在那裡，我也交出了他們規定字數內的文字。

《Interface》上的文章是“度量開發者的生產力”，它很好地在用於衡量開發者的各種度量，與極度使用度量的弊病之間做出了平衡。這些弊病中最主要的是，度量很容易被當作“遊戲”。管