開(kāi)發(fā)經(jīng)理是個(gè)工作壓力比較大的職位。作為“中間人”，你需要在管理層、客戶(hù)、銷(xiāo)售、開(kāi)發(fā)人員等多種角色之間周旋。沒(méi)人會(huì )注意你的工作做得有多好：一切都運轉順利，工作進(jìn)展得波瀾不驚，所有人都各得所需。但如果事情失敗了，不論什么原因，可都是你的錯。
要成為一名成功的開(kāi)發(fā)經(jīng)理，秘訣就是管理好期望，第一步就是確保所有人都理解你的職能。你和你工作相關(guān)的人，都要對開(kāi)發(fā)經(jīng)理的期許達成一致。
我看過(guò)很多開(kāi)發(fā)經(jīng)理的招聘信息，但我都不太贊同上面的描述。有一個(gè)要求深入了解大量編程語(yǔ)言和環(huán)境，還有一個(gè)要求66%的時(shí)間進(jìn)行編程（為什么不直接寫(xiě)三分之二？），還有一些要求有PMO認證，類(lèi)似的要求不一而足。我承認開(kāi)發(fā)經(jīng)理的職能是有點(diǎn)兒模糊不清，但像這樣的招聘信息讓我覺(jué)得發(fā)布這些職位的公司并沒(méi)有真正思考過(guò)開(kāi)發(fā)經(jīng)理的職能。這種情況對公司和受雇的人來(lái)說(shuō)都后患無(wú)窮。
作為開(kāi)發(fā)經(jīng)理，你要承擔很多責任，但重要的是發(fā)布產(chǎn)品。你的目標是采取所有必要的措施，確保能把產(chǎn)品交付給客戶(hù)或市場(chǎng)。要做到這一點(diǎn)，你需要確保開(kāi)發(fā)團隊能盡可能高效地工作，而且要確保他們有明確的目標（無(wú)論是短期的還是長(cháng)期的），掃除阻礙他們工作的一切障礙。從最初的項目范圍，到在客戶(hù)網(wǎng)站上部署產(chǎn)品，每一步都是你的職責。你可以（而且應該）盡量把事情委派給下屬去做，但你要檢查事情是否和你預期的一樣，如果不是可要自己投入。
作為開(kāi)發(fā)經(jīng)理，你需要知道如何界定項目的范圍。根據你所在組織的情況以及你和外部群組的協(xié)作方式，這可能是你工作的重要組成部分。如果你經(jīng)常承擔、負責第三方的項目，那你應該知道如何對RFP（需求建議書(shū)）作出回應，包括交付物、時(shí)間表和預算等。即便你只做內部項目，沒(méi)有正式的文檔系統，你也應該養成為每個(gè)項目寫(xiě)一份項目范圍說(shuō)明書(shū)的習慣。另外，如果你從事的是敏捷開(kāi)發(fā)，這些文檔就要隨著(zhù)項目的進(jìn)展持續維護和更新。
這是項目范圍界定的一部分，但它應該單獨說(shuō)明一下。我聽(tīng)大家談?wù)撨^(guò)“總置頂”項目，這類(lèi)項目不需要預算和時(shí)間表。這可是錯誤的！如果弄不清楚成本和交付物對這些“總置頂”項目有怎樣的依賴(lài)，那可能會(huì )扼殺你的團隊，因為這些“總置頂”項目會(huì )拖延進(jìn)度、消耗其他工作需要的資源。你承擔的每個(gè)項目至少都要有一個(gè)內部成本和一個(gè)交付物。你要和其他利益相關(guān)方一起協(xié)商你所承擔的一切。
記住，你是“中間人”，任何失敗都是你的錯，即使失敗原因是你無(wú)法控制的事情。你需要和參與的人保持良好、開(kāi)放的關(guān)系。
你不僅要讓你的直接上司了解情況，還要讓他的上司和同級別的人知道。此外，你也要讓項目的其他利益相關(guān)人了解項目情況。確保他們都在“消息圈里”，能定期獲得狀態(tài)更新，清楚你的團隊正在做什么。
誰(shuí)處理客戶(hù)關(guān)系？這些人可是除了老板之外你最需要知道的人。他們能管理客戶(hù)期望、處理投訴（真實(shí)的或想象出來(lái)的）、與客戶(hù)保持聯(lián)系。另一方面，他們能讓你苦不堪言，沒(méi)和你核對就給客戶(hù)許諾，提交不必要的Bug報告，纏著(zhù)你按不切實(shí)際的時(shí)間表執行，諸如此類(lèi)。
了解你的團隊，他們到公司有多久了？每個(gè)人分別有什么優(yōu)勢和劣勢？誰(shuí)能和他們協(xié)作得比較好？他們有多忙？留意他們的生日、紀念日等等……雖然都是些細枝末節的事情，但意義卻非同小可。
確保管理人員知道你在做什么，并能看到你的進(jìn)度，這樣他們才會(huì )滿(mǎn)意。溝通和可視化是關(guān)鍵所在。我用過(guò)各種各樣的工具，讓管理人員始終能了解狀態(tài)、發(fā)現更多信息。使用程序工具箱、公告板、白板及任何你能想到的工具，以便他們了解最新信息。
如果利益相關(guān)者了解你和你的團隊遇到的挑戰，那他們可能會(huì )少提一些不切實(shí)際的期望。我說(shuō)的是他們可能會(huì )少提，而不是絕不會(huì )提。有些管理者永遠不會(huì )明白為什么事情不能“運轉”。這種情況下你可能得重新找個(gè)工作了。
只要你不是在大型項目里，一般都不需要單獨的項目經(jīng)理。對小型或中型項目，以及使用敏捷方法的項目來(lái)說(shuō)，你可以擔任項目經(jīng)理的角色、承擔相應的責任。但開(kāi)發(fā)經(jīng)理并不是經(jīng)過(guò)認證的項目經(jīng)理。拋開(kāi)傳統項目管理和敏捷開(kāi)發(fā)之間的爭論不談，開(kāi)發(fā)經(jīng)理和項目經(jīng)理的關(guān)注點(diǎn)一直都有沖突。作為開(kāi)發(fā)經(jīng)理，你的工作是盡可能完成所有的事情，項目經(jīng)理的工作則是確定什么時(shí)候能完成哪些內容。你必須要在兩個(gè)出發(fā)點(diǎn)之間做好平衡。如果你的項目足夠大，需要專(zhuān)業(yè)的項目經(jīng)理或Scrum Master，那就給你的團隊找一個(gè)，不要嘗試著(zhù)親自扮演這個(gè)角色。不過(guò)，不論是瀑布模型還是敏捷過(guò)程，你都應該確保項目計劃是處于活動(dòng)狀態(tài)的，要持續更新、跟蹤進(jìn)度。
這是工作里另一個(gè)關(guān)鍵的部分。不論你用的是敏捷方法還是瀑布方法，你都要掌控過(guò)程，讓事情遵守流程。記住，交付是你的本職所在，任何影響交付的事情都需要你最優(yōu)先處理。
你采用的開(kāi)發(fā)過(guò)程是什么？是何種形式的？如果大家說(shuō)它是“敏捷”過(guò)程，那就檢查它是否真的敏捷（我保留著(zhù)一張很方便查看的敏捷宣言海報，提醒自己遵循敏捷原則）。你的過(guò)程如何得以改進(jìn)？不存在完美的系統，要不斷尋求改進(jìn)過(guò)程的方法。我們已經(jīng)做了很多工作來(lái)應對Bug的Root Cause分析，但更多時(shí)候卻是過(guò)程有缺陷，導致設計不好、代碼糟糕，或者誤解了客戶(hù)的需求，以至于產(chǎn)品不能發(fā)布。
委托他人是件好事，但你必須跟進(jìn)、確保事情都完成了。偉大的想法往往因為沒(méi)人檢查處理結果而在執行中失敗。我接管過(guò)好幾個(gè)項目，接手前都是各個(gè)方面都不錯，唯獨執行不好導致一塌糊涂。
最后，你需要向各個(gè)利益相關(guān)人報告基于確切度量數據的狀態(tài)。所以要用對閱讀報告的人來(lái)說(shuō)有意義的方式衡量、總結過(guò)程。根據你組織的情況確定報告頻率（每天、每周或根據需要）。要明確報告的頻率、格式和內容。注意閱讀報告的人和他們期望的詳細程度，并達到這一目標。所有這些會(huì )讓你的報告清晰、明確、易讀。這會(huì )減少誤解報告的人，但并不意味著(zhù)能消除誤讀。讀報告的人有很多事情要做，可能只會(huì )略讀一下，或者按他們的方式理解，所以你要準備好澄清和解釋?zhuān)贿^(guò)聽(tīng)起來(lái)可不能是在為自己辯解。
我多次在工作職位上看見(jiàn)過(guò)這個(gè)要求。有些公司要求開(kāi)發(fā)經(jīng)理深入掌握特定領(lǐng)域的知識。作為開(kāi)發(fā)經(jīng)理，你并不是技術(shù)專(zhuān)家！把這個(gè)要求留給高級開(kāi)發(fā)人員和首席開(kāi)發(fā)人員吧。你應該熟悉現有的技術(shù)，了解新的和即將推出的技術(shù)，但不要讓自己成為專(zhuān)家，這會(huì )耗費大量時(shí)間、從其他任務(wù)上轉移你的注意力。你要非常了解團隊正在使用的工具，看團隊成員是否在有效地使用它們，還要知道團隊何時(shí)會(huì )在知識面上出現缺口，但你不應該是“去填補”的那個(gè)人。你必須放手，委托團隊的高級開(kāi)發(fā)人員去掌握空缺的知識。
這也是一個(gè)你需要熟悉，但不必是專(zhuān)家的領(lǐng)域。偉大的程序員能寫(xiě)出最好的代碼，不過(guò)通常會(huì )是個(gè)糟糕的管理者。你要能區分好代碼和壞代碼，還應該相信你的團隊負責人。你可以在關(guān)鍵時(shí)刻親自投入、接手一些開(kāi)發(fā)任務(wù)，但別忘了要有大局觀(guān)、要聚焦于項目的完成?？刹荒芎脦滋於悸耦^編程，忘了自己的工作??。
我把自動(dòng)化測試和質(zhì)量保障分開(kāi)是因為我覺(jué)得它們有著(zhù)不同的功能。兩項工作通常都會(huì )指派給QA團隊成員，但我發(fā)現把它們分開(kāi)考慮是有益的。自動(dòng)化測試包括單元測試和測試腳本，而質(zhì)量保障是手動(dòng)檢查系統，不僅僅是為了Bug，還要關(guān)注一致的外觀(guān)和體驗、性能、用戶(hù)接口和設計問(wèn)題。（參見(jiàn)“測試vs.檢查”）。
有些事情可謂“一勞永逸”——花費99%的時(shí)間去做，剩下1%的時(shí)間享受成果。自動(dòng)化測試就是這樣子的。記住Jell-O果凍編碼原則，一個(gè)系統“此消”就會(huì )“彼長(cháng)”，恰如果凍按下一頭，另一頭就會(huì )彈起來(lái)。我曾經(jīng)遇到的情況是，每個(gè)人都確定代碼改動(dòng)的影響非常小，結果“小”到導致十多個(gè)自動(dòng)化測試用例執行失敗。這還只是自動(dòng)化測試僅覆蓋了90%代碼的情況下，很慶幸剩余的10%代碼沒(méi)有出現新Bug。
作為開(kāi)發(fā)經(jīng)理，你需要知道測試的代碼覆蓋率是多少。單元測試覆蓋了多少基本代碼？自動(dòng)化測試又覆蓋了多少？具體的值是在增加還是在減少？一個(gè)好的QA組長(cháng)會(huì )告訴你這些數字，但你應該有一個(gè)系統，至少要能評估具體的值。代碼覆蓋率的降低幾乎不可避免，你可以忍受一段時(shí)間，但有些時(shí)候你必須減慢開(kāi)發(fā)速度，以便QA團隊能跟進(jìn)上來(lái)。如果不關(guān)注測試的代碼覆蓋率，發(fā)布的代碼就可能到處是Bug。
我見(jiàn)過(guò)所謂的“冒煙測試”，但它只是質(zhì)量保障過(guò)程的簡(jiǎn)單替代。QA還需要找出不一致性、偏離規范、性能下降等問(wèn)題。作為開(kāi)發(fā)經(jīng)理，你的工作就是積極主動(dòng)地去做、確保完成這些測試。讓QA團隊加入開(kāi)發(fā)圈子，以便讓他們知道接下來(lái)要做什么。我一般會(huì )為開(kāi)發(fā)計劃制定幾個(gè)獨立的QA計劃，并保證它們的時(shí)間和開(kāi)發(fā)計劃同步。然后鏈接代碼變化，這種方式能讓開(kāi)發(fā)人員在不同的位置給測試寫(xiě)備注，而不會(huì )和編碼備注混雜在一起。
QA測試失敗的原因有很多，比如糟糕的測試、代碼變化、對規范的誤解，以及網(wǎng)絡(luò )和系統錯誤。要知道測試失敗的根本原因，你必須要讓開(kāi)發(fā)人員和QA團隊一起工作。如果你的QA人員是開(kāi)發(fā)團隊的一部分，這并不難做到；萬(wàn)一他們有各自的經(jīng)理，那你必須與他們的經(jīng)理進(jìn)行協(xié)調。
根據項目的復雜度，發(fā)布版本也會(huì )是一個(gè)單獨的項目。簡(jiǎn)單系統的發(fā)布可能只是簡(jiǎn)單地構建一下、拷貝覆蓋可執行文件；而對復雜系統來(lái)說(shuō)，發(fā)布可能需要構建大量的包（可執行文件、組件、Jar文件或DLL），添加數據庫腳本，甚至添加一些第三方應用。要確保每個(gè)組件的版本都正確可是件困難又耗時(shí)的工作。在非常復雜的項目里，你可以指定一個(gè)Build Master來(lái)跟蹤版本。無(wú)論如何你都要有一塊記錄組件及下個(gè)發(fā)布所需版本的公共區域，并且要確保每個(gè)人都能訪(fǎng)問(wèn)、能根據需要更新它們。
你還要發(fā)布代碼歸檔，準備、測試安裝程序，編寫(xiě)、發(fā)布版本說(shuō)明，并保證合適的人能訪(fǎng)問(wèn)新版本（舊版本至少要改名，防止訪(fǎng)問(wèn)的人弄混當前版本）。
部署往往被看成是發(fā)布管理的一部分，不過(guò)我覺(jué)得應該單獨看待。
如果你有Beta測試站點(diǎn)，這就變得更加重要了。準備好站點(diǎn)發(fā)布新版本本身就是一個(gè)項目。誰(shuí)使用你的產(chǎn)品？他們能接受新版本么？已經(jīng)了解修改內容了么？怎么報告問(wèn)題、表示贊許？測試周期是多長(cháng)？你準備好在最短的停機時(shí)間內回滾版本了么？
測試結束后，你的客戶(hù)會(huì )接受么？上面的所有問(wèn)題都必須在推出版本之前得以解決。
這是大家都討厭的一部分工作，但它是工作的一部分，其間還需要做一些最困難的決定。預算、員工的雇用和解雇、爭奪資源和空間、寫(xiě)報告、評估等，所有內容你都沒(méi)在學(xué)校學(xué)過(guò)，但在工作過(guò)程中你可要全部學(xué)會(huì )。最重要的就是“知道自己不知道什么”！我見(jiàn)過(guò)很多優(yōu)秀的管理者會(huì )在這部分工作里迷失，你要是自以為是，公司和你自己就會(huì )陷入很多法律問(wèn)題。如果你對所做的事情有一丁點(diǎn)兒的懷疑，就研究一下、尋求幫助、找一些行家。自以為是會(huì )讓你的公司受到起訴，你也會(huì )遭到指責，所以再強調也不為過(guò)。
這是行政管理職能的一部分，但值得單獨說(shuō)明一下。讓合適的團隊成員擔任合適的角色是永遠達不到的理想狀態(tài)，但這并不意味著(zhù)你可以不努力去做。達到合適的水平很棘手，大型團隊的花費要比小型團隊的多、但效果卻不及小型團隊，不過(guò)你不應該讓每個(gè)人都百分百投入。你需要預留一些空閑時(shí)間，以便團隊能夠應付突發(fā)的新增需求，而不會(huì )給項目帶來(lái)風(fēng)險。
如果團隊成員因為家庭事務(wù)或其他原因需要休假，不要太緊張。就我個(gè)人而言，只要這個(gè)人是有效率的團隊成員，我就會(huì )批準。已經(jīng)有大量研究表明，（在合理范圍內的）高缺勤率實(shí)際上比近乎全勤的團隊更有效率。這是因為有人休假時(shí)，他平時(shí)負責的部分就需要團隊的其他成員去學(xué)習。所以讓團隊成員因個(gè)人原因休假實(shí)際上會(huì )提升團隊的效率。
出現人員流動(dòng)可能會(huì )是個(gè)好事情。我告訴年輕的開(kāi)發(fā)人員應該每五年換一個(gè)公司。這樣做可以接觸不同的環(huán)境和技術(shù)，以及不同的過(guò)程。我看簡(jiǎn)歷的時(shí)候會(huì )關(guān)注這方面的內容，所以我也希望我團隊里的人可以繼續發(fā)展。你需要對此作出規劃，不能因為項目或系統的特定部分只有一個(gè)人知道而懇求他留下來(lái)。確保信息和知識是團隊內共享的，而不是集中在一兩個(gè)關(guān)鍵人物那里。
最后，每個(gè)開(kāi)發(fā)經(jīng)理都會(huì )經(jīng)歷解聘。無(wú)論是因為金融原因（團隊裁員）還是表現不佳，你都必須做好準備，了解公司的政策和程序。你甚至要知道法律責任。在加拿大，無(wú)故解聘某人需要遵守法定解雇要求，人們也享有普通法里“提前通知”的權利：有時(shí)間找下一份工作，沒(méi)有收入損失。只符合法定要求會(huì )引來(lái)非法解雇的訴訟，所以最好從一開(kāi)始就讓他們能夠接受，而不是跑去找律師。善待他們會(huì )贏(yíng)得好的口碑，在準備重新雇用人的時(shí)候這可沒(méi)什么壞處。
上面的清單可不短。你不必是任何一個(gè)方面的專(zhuān)家，事實(shí)上不是專(zhuān)家才最好。不是專(zhuān)家的話(huà)，你才不會(huì )在做更有價(jià)值的事情時(shí)深入、接手某項具體的工作。
對我來(lái)說(shuō)，如何成為一名開(kāi)發(fā)經(jīng)理最好的例子來(lái)自制造業(yè)里Bata鞋的故事。在原來(lái)的工廠(chǎng)里（現在在捷克共和國），Thomaz Bata把辦公室建在貨運電梯里。無(wú)論哪一樓層出現生產(chǎn)問(wèn)題，Thomaz Bata都能把整個(gè)辦公室移到那一層進(jìn)行微觀(guān)管理，直到問(wèn)題得以解決。然后他會(huì )下到一樓，不受生產(chǎn)樓層的干擾、繼續運營(yíng)公司。需要的時(shí)候進(jìn)行微觀(guān)管理，其他時(shí)候讓團隊繼續工作、你處理其他的事情。
聯(lián)系客服
