【摘要】一旦公司陷入重寫程式碼的困境，開發團隊往往淪為替罪羊。這類問題通常是由產品管理失誤引發的。因為產品經理一直迫使開發團隊滿負荷工作，開發儘可能多的功能。所有軟體架構都存在功能極限，如果忽視產品的基礎技術構架，一旦系統越過崩潰的臨界點，就會造成無法挽回的結果。
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先生授權。
文/ Marty Cagan 譯/歐坤、孫洋
原文：程式設計師