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