文/ Marty Cagan  譯/歐坤、孫洋

　　Marty Cagan是享有世界聲譽的產品管理專家，曾經擔任網景副總裁、eBay產品管理及設計高級副總裁。本文是他回顧自己二十多年來從事軟件產品管理工作的總結和經驗分享，談到了產品管理與軟件開發的關系，以及軟件開發人員如何轉型做產品管理。

　　產品管理與軟件開發的關系

　　如果說成功的產品是真實用戶需求與現階段可行性方案的結合，那么產品經理與開發團隊之間（合作）關系的重要性自然不言而喻了。

　　產品經理負責定義產品方案；開發團隊最了解哪些產品設計是可行的，他們負責產品的開發與實現。作為產品經理，你很快能體會到，只有與開發團隊融洽合作，才有可能開發出合格的產品，否則等待你的將是一段漫長難挨的日子。

　　形成合作關系的關鍵是雙方承認彼此平等——任何一方不從屬于另一方。產品經理負責定義正確的產品，開發團隊負責正確地開發產品，雙方相互依賴。你要求開發團隊完成任務，必須先取得他們的認可，確信為了達到產品質量標準必須這么做；開發團隊也要留給你足夠的空間設計有價值、可用的產品。

　　產品管理和軟件開發相互促進，開發人員可以幫助產品經理完善產品定義，別忘了他們最清楚你的產品設計是否可行。

　　開發人員幫助產品經理完善產品定義的方式有如下三種。

• 讓開發人員直接面對用戶和顧客，體會用戶的困惑和疑慮，了解問題的嚴重性，好點子常常會隨之而來，譬如，可以邀請一名開發人員參加產品原型測試。
• 向開發人員了解最新的技術發展動向，討論哪些新技術可以用到產品里。開展“頭腦風暴”，看看目前已實現的技術或即將實現的技術能不能解決手頭的問題。
• 讓開發人員（或主程序員）在探索（定義）產品的初期階段參與評估產品設計，協助策劃方案。產品經理常犯一類錯誤，即完成產品定義后，扔給開發團隊便置之不理。這樣做只會貽誤協調需求與可行性的最佳時機，等到發現問題時，為時已晚。

　　同樣，產品經理也可以協助開發人員的工作，方式如下。

• 產品經理關注產品的基本要求（核心功能）。產品經理應該意識到，自己定義的不是最終產品，而是滿足基本要求的產品雛形。只有這樣，產品管理與軟件開發之間才能形成良好的互動。

• 一旦產品進入開發階段，要盡可能避免修改產品的需求和規劃。雖然有些事情超出你的控制范圍，變動是不可避免的，開發人員也能理解，但是千萬不要在此時嘗試突發奇想的點子。

• 產品開發階段難免會產生諸多問題，比如，用例丟失，或者用例設計考慮不周全等。這很正常，哪怕最優秀的產品團隊也避免不了。產品經理應該迅速采取行動，在維持產品核心功能、盡量避免修改的原則上，給出解決方案。

　　我經常鼓勵出色的開發人員嘗試產品管理工作。我告訴他們，如果產品沒有市場價值，無論開發團隊多么優秀也無濟于事。很多優秀的產品是程序員抓住用戶需求，自己創業研發出來的。放寬眼界不僅僅有利于開發人員自己的職業發展，也有利于產品、顧客和公司。

　　如何與異地的開發人員溝通？

　　如今產品經理與開發團隊各處一方的情況很常見。除了印度軟件外包業務，大型公司的分支機構之間，以及公司與被收購的子公司之間，都可能出現這種情況。

　　如果開發團隊不在你身邊，溝通和執行的難度將進一步放大。異地開發出現的問題常常導致團隊士氣低落，有人甚至公開質疑異地開發能否真正節約成本。

　　提高與異地開發團隊之間的溝通效率，我有三條建議。

• 開發團隊距離越遠，語言、文化、時差帶來的溝通難度越大，確定完善的產品說明文檔就越重要。如果產品經理不確定開發什么樣的產品（或者反復改變想法），異地開發團隊只能疲于奔命，白費力氣。這簡直就是一場災難，絲毫不亞于醫生開錯方子。如果你與開發團隊相隔很遠，無論是溝通產品文檔的內容，還是討論修改產品設計，一定要借助高保真原型進行交流。閱讀文檔畢竟不輕松，如果文檔是非母語的，或者闡述不清楚，那溝通效率就更低了。

• 本地的開發團隊很容易發現和解決各種沖突（比如，兩個管理者給出相互抵觸的指導意見）。異地開發團隊則會發生很多意想不到的情況，往往過了好幾個月才發現問題。這是因為異地開發人員不得不揣摩各種不同的意見（但經常揣摩錯）。因此，必須有人在本地負責與異地團隊的協調工作。這并不是說所有溝通工作都必須經過此人，而是應該明確異地開發團隊只接受他的命令。這項工作可以由本地的項目經理、資深開發人員或者其他主管擔任。

• 如今商業溝通手段很豐富，除了電子郵件和即時消息外，還有視頻會議可供選擇，此外，語音電話業務（VoIP）大大降低了國際長途通話費用支出。盡管如此，當面交流的優勢依然不可替代。每個季度，產品經理至少應該前往異地與開發團隊見一次面，與軟件架構師、管理者當面交流。面對面交流有助于改善（合作）關系，提高溝通效率。此外，交換人員也是一種有效的溝通方式，可以讓主程序員來本地與產品經理共同工作一段時間，或者讓產品經理到異地工作一段時間。

　　按照我介紹的方法與優秀的開發團隊合作是一種特別的享受。如果是與印度外包團隊合作，那么由于時差的原因這種合作會讓人覺得更加愜意。每天早晨上班時，對方的項目進展已經擺在面前。你可以用白天（對方的夜晚）檢查、測試代碼，反饋信息，顯著縮短項目的循環周期。

　　請注意，如果是在異地開展與產品原型相關的工作，由于循環周期非常短（一天迭代好幾次），你必須隨時準備處理對方的問題，投入更多的精力。

　　解決異地開發問題的另一種方式是在異地聘請產品團隊。這種趨勢正在興起，我相信這種模式會被更多的公司采用。你大可不必為此擔心。我們曾經用了10年時間在異地培養專業的開發和測試人員，培養專業的產品經理和設計人員很可能還要再花10年時間。

　　程序員想重寫代碼？

　　產品經理最擔心聽到開發人員這樣抱怨：“不能再增加功能了！我們得停下來重寫代碼。代碼庫一團糟，就像紙糊的老虎，根本應付不了持續增加的用戶。我們維護不下去了！”

　　這一幕在很多公司上演過，現在依然在不斷重演。1999年eBay遭遇這一幕時，公司瀕臨崩潰的情形超出所有人想象。Friendster幾年前也發生過這種情況，當時他們正在向MySpace開放社交網絡用戶。網景與微軟展開瀏覽器大戰時，也發生過類似的事情，最后的結果大家都知道。事實上，沒幾家公司能渡過難關。

　　一旦公司陷入這種困境，開發團隊往往淪為替罪羊。經驗告訴我，這類問題通常是由產品管理失誤引發的。因為產品經理一直迫使開發團隊滿負荷工作，開發盡可能多的功能。所有軟件架構都存在功能極限，如果忽視產品的基礎技術構架，一旦系統越過崩潰的臨界點，就會造成無法挽回的結果。

　　在重寫代碼的過程中，用戶無法看到產品的任何改進。你可能認為重寫代碼至多也就幾個月，但是實際花費的時間無一例外要多得多。你只能坐在一旁，眼睜睜看著用戶投奔競爭對手，而這個時候，競爭對手恰恰在不斷地改進產品。

　　如果你還沒有遇到這樣的情形，未雨綢繆很有必要——你需要預留一定的研發技術能力，在eBay被稱為余量（headroom）。很多因產品迅速膨脹產生的問題都與擴展規模有關，余量意味著避免觸及技術能力的上限，為用戶數量的增長預留空間，為事務增長預留空間，為新增功能預留空間，保證產品的基礎技術構架能夠滿足團隊的要求。

　　與開發團隊合作應該遵循以下原則：在產品管理上為開發團隊預留20%的自主時間，讓他們自由支配。開發團隊可以利用這些時間重寫代碼、完善架構、重構代碼庫中有缺陷的部分，或者更換數據庫管理系統，提高系統性能，避免“我們需要停下來重寫代碼”的情形發生。

　　如果你的糟糕處境已經初現端倪，應該拿出至少20%的資源進行調整，而我擔心有些團隊連20%都不愿意拿出來。如果你已經身陷重寫的困境，說明公司危在旦夕，這里給出一點建議供你參考。

　　第一步，針對開發團隊確定的產品修改目標并制訂切實可行的計劃和時間表。通常，有經驗的開發團隊估計的開發時間八九不離十，但是重寫代碼是個例外，因為多數團隊都沒有重寫代碼的實際經驗，估計往往過于樂觀。你必須審時度勢，仔細檢查每處細節，確保計劃切實可行。

　　第二步，只要有可能，最好把重寫目標分成幾大塊，實現遞增修改，讓用戶感受到產品的改進，哪怕會因此把9個月的工作時間延長至2年，也一定要采用這種方式。重寫代碼時，保證讓用戶看到功能的改進——即使會占用少則25%，多則50%的開發資源——對保持產品（尤其是互聯網產品）的市場占有率至關重要。

　　第三步，由于開發用戶可見功能的資源有限，必須謹慎選擇正確的產品特性，并確保產品定義的正確性。

　　eBay起死回生后，我們發誓絕不重蹈覆轍，馬上開始新一輪的代碼重寫，把危機甩在身后。事實上，由于發展迅速，eBay已經重寫了三次代碼，最后一次采用了完全不同的編程語言和架構。開發團隊花了幾年時間，大規模地改寫了幾百萬行代碼，同時在不影響用戶群的情況下，開發了大量新功能。這是我知道的最驚心動魄的中途重建網站的故事。

　　臨渴掘井不如未雨綢繆，為防患于未然，別忘了預留20%的余量。如果你從未與開發團隊談過這件事，今天就去找他們吧。

　　軟件開發人員如何轉型做產品管理？

　　我與開發人員接觸，發現他們很關心這樣一個問題：如何從軟件開發向產品管理轉型？

　　開發人員希望向產品管理轉型，有時是因為參與探索（定義）產品后，嘗到了影響產品決策的甜頭，不再滿足于只做編程的工作。有時是因為對現有產品很失望，他們認識到如果產品沒有價值，開發團隊再優秀也無濟于事。​

　　我認識的很多優秀的產品經理都是開發工程師出身。接下來，我將探討從軟件開發轉型到產品管理時可能遇到的問題和挑戰。​

　　開發人員轉型做產品管理有其無與倫比的優勢——對產品可行性的敏銳嗅覺。如果他們對用戶行為進行深入分析，學習一些和產品管理有關的技巧，就能成長為出色的產品經理，打造出用戶喜愛的產品。

　　轉型的第一步，是清楚地意識到自己和目標客戶是截然不同的。花一些時間和真正的客戶交往，就會很容易意識到這一點。不要想當然地認為，只要我喜歡這個產品，知道如何操作，用戶也一定會喜歡這個產品，知道如何操作。

　　第二，學會“移情”（empathy），懂得站在用戶的角度思考問題。其實，用戶并非一無所知的菜鳥，只是他們的工作和擅長的領域與你不同罷了。要做到換位思考，最簡單的方法是花時間與用戶做面對面的溝通。注意，這并不意味著用戶能提出真正的產品需求；挖掘產品需求是產品管理的任務。

　　第三，轉變思想。作為開發工程師，你的任務是優化開發流程和效率。但作為產品經理，你的工作則是定義產品、優化用戶體驗，打造出用戶喜愛的產品。這一點看似容易，只有當你面臨一個兩難抉擇，比如項目發布時間與用戶體驗出現沖突的時候，你才能體會其中的困難。

　　第四，保持謙遜的品格。向用戶展示產品時，大多數人的反應可能會與你的預期背道而馳，這時謙遜就顯得格外重要。仔細傾聽來自用戶的聲音，日復一日，你的理解力會得到極大提升。但前提條件是必須擁有開放的心態來面對用戶的批評。

　　第五，改變討論風格。很多互聯網企業中，工程師都喜歡圍繞著某些決策爭論不休，激情四射。可多數情況下，這些產品的技術決策有明確的判斷標準，比如運行速度更快、規模更合適、容錯度更高、擴展性更好等等。而產品定義和用戶體驗的決策中并不存在這樣的標準。這時候就需要你改變以前的討論風格，提高說服和辯論的技巧，讓他人接受你的觀點。

　　最后，處理好和原部門的關系。成為產品經理后，你和開發部門的關系會變得很難處理。他們會變得異常敏感且難以溝通，會采取各種各樣的方式來挑戰你，質疑你的技術能力，不會輕易作出承諾。你需要學會放手，讓工程團隊做好他們的本職工作，并參與到產品開發的流程中來。產品管理的工作已經夠讓人頭大了，相關的技術決策就放手讓他們來處理吧。

　　我強烈建議公司建立暢通的渠道為開發人員的轉型提供便利，一定會培養出許多杰出的產品經理。即使轉型不成功，開發人員還是決定回去編程，但產品管理的觀念也為他們樹立了“科技以人為本”的思想，對他們今后的工作是極其有益的。

　　作者簡介：過去20年，Marty Cagan作為負責定義和開發產品的高級經理人為多家一流企業工作過，包括惠普、網景通信、美國在線、eBay。他親歷了個人電腦、互聯網、電子商務的起落沉浮，致力于通過寫作、演講、培訓幫助客戶打造富有創意的產品。為此，他撰寫了《Inspired: How to Create Products Customers Love》一書，創辦了硅谷產品集團公司（SVPG）。在此之前，他的最后一份工作是擔任eBay產品管理及設計高級副總裁，負責規劃全球電子商務網站的產品和服務。

　　本文節選自華中科技大學出版社《啟示錄：打造用戶喜愛的產品》一書和作者的博客。該書從人員、流程、產品三個角度介紹了現代軟件（互聯網）產品管理的實踐經驗和理念。特此感謝華中科技大學出版社與Marty Cagan先生授權。