2. 互動設計師必須現場深度參與專案開發，從立項直到產品釋出。開發和測試過程中會出現各種細節問題，必須有一名互動設計師迅速作出決定。 3. 產品的使用者體驗是公司的核心競爭力，必須在內部完成。如果讓我選擇，質量檢驗更適合外包。 只要團隊中有一位稱職的互動設計師，視覺設計也可以外包，畢竟視覺設計公司很多，完全可以滿足需求。此外，使用者研究和可用性測試也可以外包，只是成本較高，對我這種重視測試反饋（參考第22章）的人來說更是如此，所以我建議讓產品經理和互動設計師分擔這項工作。 至於原型製作，你可以從開發團隊借個幫手來做。要讓他明白原型程式碼和產品程式碼毫無關係，原型程式碼絕不能用在實際產品裡。最好直截了當告訴他，原型的所有程式碼都是要廢棄的。 這個話題涉及的範圍很廣，限於篇幅，討論暫告一段落。 我希望以上介紹能為今後的討論奠定基礎。你的團隊有人負責這些工作嗎？還有哪些工作被忽略了？
第5章產品管理與軟體開發 Product Management vs. Engineering 定義正確的產品與正確地開發產品如果說成功的產品是真實使用者需求與現階段可行性方案的結合，那麼產品經理與開發團隊之間（合作）的關係的重要性自然不言而喻了。 產品經理負責定義產品方案；開發團隊最瞭解哪些產品構思是可行的，他們負責產品的開發與實現。作為產品經理，你很快能體會到，只有與開發團隊融洽合作，才有可能開發出合格的產品；否則等待你的將是一段漫長、難捱的日子。 形成合作關係的關鍵是雙方承認彼此平等—任何一方不從屬於另一方。產品經理負責定義正確的產品，開發團隊負責正確地開發產品，雙方相互依賴。你要求開發團隊完成任務， 必須先取得他們的認可，確信為了達到產品質量標準必須這麼第5章產品管理與軟體開發| 23 做：開發團隊也要留給你足夠的空間，設計有價值、可用的產品。 產品管理和軟體開發相互促進。開發人員可以幫助產品經理完善產品定義。別忘了，他們最清楚你的產品設計是否可行。 開發人員幫助產品經理完善產品定義的方式有如下三種。 1.讓開發人員直接面對使用者或顧客，體會使用者的困惑和疑慮，瞭解問題的嚴重性，這樣好點子常常會隨之而來， 譬如，可以邀請一名開發人員參加產品原型測試。 2. 向開發人員瞭解最新的技術發展動向，討論哪些新技術可以用到產品裡。開展頭腦風暴，看看目前已實現的技術或即將實現的技術能不能解決手頭的問題。 3. 讓開發人員在探索（定義）產品的初期階段參與評估產品設計，協助策劃方案。產品經理常犯一類錯誤，即完成產品定義後，便扔給開發團隊，置之不理。這樣做只會貽誤協調需求與可行性的最佳時機，等到發現問題時，為時已晚。 同樣，產品經理也應該配合開發人員的工作，方式如下。 1. 產品經理只定義滿足基本要求的產品（參見第20章）。
24 | 啟示錄：打造使用者喜愛的產品產品經理應該意識到，自己要定義的不是最終產品，而是滿足基本要求的產品。只有這樣，產品管理與軟體開發之間才能形成良好的互動。 2. 一旦產品進入開發階段，要儘可能避免修改產品的需求和設計。雖然有些事情超出你的控制範圍，導致專案波動是不可避免的（開發人員也能理解），但是千萬不要在此時嘗試突發奇想的點子。 3. 產品開發階段難免會產生諸多問題，比如，用例丟失， 用例設計考慮不周全等，這很正常，最優秀的團隊也避免不了。產品經理應該迅速採取行動，在維持產品基本功能、儘量避免修改的原則上，拿出解決方案。 我經常鼓勵出色的開發人員嘗試產品管理工作。我告訴他們，如果產品沒有市場價值，那麼無論開發團隊多麼優秀也無濟於事。很多優秀的產品是程式設計師抓住使用者需求，自己創業研發出來的。放寬眼界不僅僅有利於開發人員自己的職業發展， 也有利於產品、顧客和公司。
第5章產品管理與軟體開發 | 25？ 如何與異地的開發人員溝通？ 如今產品經理與開發團隊各處一方的情況很常見。如果開發團隊不在你身邊，溝通和執行的難度將進一步加大。提高與異地開發團隊之間的溝通效率，我有三條建議。 1. 開發團隊距離越遠，語言、文化、時差帶來的溝通難度越大。如果產品經理不確定開發什麼樣的產品（或者反覆改變想法），異地開發團隊就只能疲於奔命，白費力氣。這簡直就是一場災難，絲毫不亞於醫生開錯藥方。 我將在第18章討論把高保真原型作為產品說明文件基礎的重要性。如果你與開發團隊相隔很遠，無論是討論產品文件的內容，還是討論修改產品設計，一定要藉助高保真原型進行交流。閱讀文件畢竟不輕鬆，如果文件是非母語的，或者闡述不清楚，那溝通效率就更低了。 2. 我們很容易發現和解決本地開發團隊裡出現的各種衝突（比如，兩個管理者給出相互牴觸的指導意見）。 異地開發團隊則會發生很多意想不到的情況，往往過了好幾個月才發現問題，因此，必須有人在本地負責與異地團隊的協調工作。這並不是說所有溝通工作都必須經過此
26 | 啟示錄：打造使用者喜愛的產品人，而是應該明確異地開發團隊只接受他的命令。這項工作可以由本地的專案經理，資深開發人員或者其他主管擔任。 3. 如今商業溝通手段很豐富，除了電子郵件和即時訊息外，還有視訊會議可供選擇。儘管如此，當面交流的優勢依然不可替代。每個季度，產品經理至少應該前往異地與開發團隊見一次面。面對面交流有助於改善（合作） 關係，提高溝通效率。此外，交換人員也是一種有效的溝通方式，可以讓主程式設計師來本地與產品經理共同工作一段時間，或者讓產品經理到異地工作一段時間。 如果是與印度外包團隊合作，由於時差的原因這種合作會讓人覺得非常愜意。每天早晨上班時，對方的專案進展已經擺在面前。你可以用白天（對方的夜晚）檢查、測試程式碼，反饋資訊，顯著縮短專案的迴圈週期。 請注意，如果是在異地開展與產品原型相關的工作， 由於迴圈週期非常短（一天迭代好幾次），你必須隨時準備處理對方的問題，投入更多的精力。 另一種解決異地開發問題的方式是在異地聘請產品團隊。這種趨勢正在興起，我相信它會被更多的公司採用。
第5章產品管理與軟體開發1 27？ 關於業務外包我合作過的所有公司都或多或少有業務外包，但是效果參差不齊。我認為造成效果不佳的原因是多方面的，比如，產品開發流程有問題，或者存在語言、文化差異，但是根本癥結在於選擇業務外包的初衷不對。 外包不是為了節約成本，而是為了實現合理的人員配置。所以才要超越地理位置的侷限，僱用另一個州/區， 或者另一個國家的員工，實現最佳組合。 矽谷的生活成本越來越高，僱主支付給普通員工的薪水遠不夠他們的生活費。願意長途通勤來矽谷工作的外地人畢竟有限。為了聘用優秀的員工，你不得不另尋他法。 好在矽谷以外還有很多優秀人才。我曾有一支優秀團隊，因隊成員分佈在瑞典、印度，以及美國的矽谷和波士頓。我們當時開發的平臺支援兩千萬的使用者，如果沒有這些來自不同國家和地區的精英協助，這個專案不可能成功。 我很喜歡MySQL 這家公司，他們多年來一直貫徹虛擬團隊的理念。表面上，公司的兩個總部位於矽谷和瑞典， 但是他們的產品團隊分散在世界各地。他們是虛擬的團
28 | 啟示錄：打造使用者喜愛的產品隊，充分利用分佈在全球的頂尖資料庫人才和系統軟體高手的力量。雖然管理分散的團隊不容易，但我相信如果 MySQL. 是一家集中式的公司，他們不可能取得今天的成就。 正如二十世紀八十年代製造業被迫外遷一樣，現在有些工作也逐漸從矽谷消失，例如，客戶服務和測試。技術研發也開始出現類似的趨勢。日益普遍的情形是軟體架構師、測試經理、產品經理、設計人員留在公司總部，其他團隊成員要麼集中在異地某處，要麼分散在全球各地。 選擇業務外包的關鍵是要挑選有能力的員工。很多管理者不明白這個道理，得知相同工種的員工在生產效率上存在著二十倍的差異時，他們表現得異常驚訝。你認為哪種團隊更好—由五位精英組成的異地團隊，還是僱用十五個平庸的本地人？提高生產效率產生的價值可以輕易超過僱用本地員工節約的成本。從這個角度來看，聘用居住在高消費城市的頂級程式設計師是划算的。 如果你下決心發包業務，希望你是基於正確的原因— 為產品團隊尋找合適的人選，而不是僅僅為了節省一點兒小錢。