開發經理的職能

開發經理是個工作壓力比較大的職位。作為“中間人”，你需要在管理層、客戶、銷售 、開發人員等多種角色之間周旋。沒人會注意你的工作做得有多好：一切都運轉順利，工作進展得波瀾 不驚，所有人都各得所需。但如果事情失敗了，不論什麼原因，可都是你的錯。

要成為一名成功的開發經理，秘訣就是管理好期望，第一步就是確保所有人都理解你的職能。你和 你工作相關的人，都要對開發經理的期許達成一致。

我看過很多開發經理的招聘資訊，但我都不太贊同上面的描述。有一個要求深入瞭解大量程式設計語言 和環境，還有一個要求66%的時間進行編程（為什麼不直接寫三分之二？），還有一些要求有PMO認證， 類似的要求不一而足。我承認開發經理的職能是有點兒模糊不清，但像這樣的招聘資訊讓我覺得發布這 些職位的公司並沒有真正思考過開發經理的職能。這種情況對公司和受雇的人來說都後患無窮。

作為開發經理，你要承擔很多責任，但重要的是發布產品。你的目標是採取所有必要的措施，確保 能把產品交付給客戶或市場。要做到這一點，你需要確保Team Dev能儘可能高效地工作，而且要確保他 們有明確的目標（無論是短期的還是長期的），掃除阻礙他們工作的一切障礙。從最初的專案範圍，到 在客戶網站上部署產品，每一步都是你的職責。你可以（而且應該）盡量把事情委派給下屬去做，但你 要檢查事情是否和你預期的一樣，如果不是可要自己投入。

專案範圍界定

作為開發經理，你需要知道如何界定項目的範圍。根據你所在組織的情況以及你和外部群組的協作 方式，這可能是你工作的重要組成部分。如果你經常承擔、負責第三方的項目，那你應該知道如何對 RFP（需求建議書）作出回應，包括交付物、時間表和預算等。即便你只做內部項目，沒有正式的文檔 系統，你也應該養成為每個項目寫一份專案範圍說明書的習慣。另外，如果你從事的是敏捷開發，這些 文檔就要隨著項目的進展持續維護和更新。

“總置頂”項目

這是專案範圍界定的一部分，但它應該單獨說明一下。我聽大家談論過“總置頂”項目 ，這類項目不需要預算和時間表。這可是錯誤的！如果弄不清楚成本和交付物對這些“總置頂 ”項目有怎樣的依賴，那可能會扼殺你的團隊，因為這些“總置頂”項目會拖延進度 、消耗其他工作需要的資源。你承擔的每個項目至少都要有一個內部成本和一個交付物。你要和其他利 益相關方一起協商你所承擔的一切。

管理關聯性

記住，你是“中間人”，任何失敗都是你的錯，即使失敗原因是你無法控制的事情。你 需要和參與的人保持良好、開放的關係。

你不僅要讓你的直接上司瞭解情況，還要讓他的上司和同層級的人知道。此外，你也要讓項目的其 他利益相關人瞭解項目情況。確保他們都在“訊息圈裡”，能定期獲得狀態更新，清楚你的 團隊正在做什麼。

誰處理客戶關係？這些人可是除了老闆之外你最需要知道的人。他們能管理客戶期望、處理投訴（ 真實的或想象出來的）、與客戶保持聯絡。另一方面，他們能讓你苦不堪言，沒和你核對就給客戶確保 ，提交不必要的Bug報告，纏著你按不切實際的時間表執行，諸如此類。

瞭解你的團隊，他們到公司有多久了？每個人分別有什麼優勢和劣勢？誰能和他們協作得比較好？ 他們有多忙？留意他們的生日、紀念日等等……雖然都是些細枝末節的事情，但意義卻非 同小可。

確保管理員知道你在做什麼，並能看到你的進度，這樣他們才會滿意。溝通和可視化是關鍵所在 。我用過各種各樣的工具，讓管理員始終能瞭解狀態、發現更多資訊。使用程式工具箱、公告板、白 板及任何你能想到的工具，以便他們瞭解最新資訊。

如果利益相關者瞭解你和你的團隊遇到的挑戰，那他們可能會少提一些不切實際的期望。我說的是 他們可能會少提，而不是絕不會提。有些管理者永遠不會明白為什麼事情不能“運轉”。這 種情況下你可能得重新找個工作了。

專案計劃

只要你不是在大型項目裡，一般都不需要單獨的專案經理。對小型或中型項目，以及使用敏捷方法 的項目來說，你可以擔任專案經理的角色、承擔相應的責任。但開發經理並不是經過認證的專案經理。 拋開傳統專案管理和敏捷開發之間的爭論不談，開發經理和專案經理的關注點一直都有衝突。作為開發 經理，你的工作是儘可能完成所有的事情，專案經理的工作則是確定什麼時候能完成哪些內容。你必須 要在兩個出發點之間做好平衡。如果你的項目足夠大，需要專業的專案經理或Scrum Master，那就給你 的團隊找一個，不要嘗試著親自扮演這個角色。不過，不論是瀑布模型還是敏捷過程，你都應該確保項 目計劃是處於活動狀態的，要持續更新、跟蹤進度。

過程式控制制

這是工作裡另一個關鍵的部分。不論你用的是敏捷方法還是瀑布方法，你都要掌控過程，讓事情遵 守流程。記住，交付是你的本職所在，任何影響交付的事情都需要你最優先處理。

你採用的開發過程是什嗎？是何種形式的？如果大家說它是“敏捷”過程，那就檢查它 是否真的敏捷（我保留著一張很方便查看的敏捷宣言海報，提醒自己遵循敏捷原則）。你的過程如何得 以改進？不存在完美的系統，要不斷尋求改進過程的方法。我們已經做了很多工作來應對Bug的Root Cause分析，但更多時候卻是過程有缺陷，導致設計不好、代碼糟糕，或者誤解了客戶的需求，以至於 產品不能發布。

委託他人是件好事，但你必須跟進、確保事情都完成了。偉大的想法往往因為沒人檢查處理結果而 在執行中失敗。我接管過好幾個項目，接手前都是各個方面都不錯，唯獨執行不好導致一塌糊塗。

最後，你需要向各個利益相關人報告基於確切度量資料的狀態。所以要用對閱讀報告的人來說有意 義的方式衡量、總結過程。根據你組織的情況確定報告頻率（每天、每周或根據需要）。要明確報告的 頻率、格式和內容。注意閱讀報告的人和他們期望的詳細程度，並達到這一目標。所有這些會讓你的報 告清晰、明確、易讀。這會減少誤解報告的人，但並不意味著能消除誤讀。讀報告的人有很多事情要做 ，可能只會略讀一下，或者按他們的方式理解，所以你要準備好澄清和解釋，不過聽起來可不能是在為 自己辯解。

技術

我多次在工作職位上看見過這個要求。有些公司要求開發經理深入掌握特定領域的知識。作為開發 經理，你並不是技術專家！把這個要求留給進階開發人員和首席開發人員吧。你應該熟悉現有的技術， 瞭解新的和即將推出的技術，但不要讓自己成為專家，這會耗費大量時間、從其他任務上轉移你的注意 力。你要非常瞭解團隊正在使用的工具，看團隊成員是否在有效地使用它們，還要知道團隊何時會在知 識面上出現缺口，但你不應該是“去填補”的那個人。你必須放手，委託團隊的進階開發人 員去掌握空缺的知識。

開發

這也是一個你需要熟悉，但不必是專家的領域。偉大的程式員能寫出最好的代碼，不過通常會是個 糟糕的管理者。你要能區分好代碼和壞代碼，還應該相信你的團隊負責人。你可以在關鍵時刻親自投入 、接手一些開發工作單位，但別忘了要有大局觀、要聚焦於項目的完成。可不能好幾天都埋頭編程，忘了自 己的工作。