注：此文為筆者在閱讀硅谷產(chǎn)品集團創(chuàng)始人/前eBay高級副總裁Marty Cagan的《啟示錄》之后寫下的結合自身工作與文章的一些讀書筆記。
前言
此前也讀過蘇杰寫的《人人都是產(chǎn)品經(jīng)理》和《淘寶十年產(chǎn)品事》等一些書籍，也許是當時從業(yè)經(jīng)歷尚淺，只能讀到其中的兩三成淺層內(nèi)容。在從業(yè)2年以后，在kindle上讀到了這本讓我愛不釋手的《啟示錄》，在找了好幾家電商之后，終于買到了這本紙質(zhì)書，實在是因為他解答了我在做一名產(chǎn)品經(jīng)理的時候太多的困惑。在實際工作中，與我同齡的上司帶我探索產(chǎn)品的工作方法和奧義，而在這本書，則是一位資深的、優(yōu)秀的產(chǎn)品經(jīng)理帶我去了解他所定義的產(chǎn)品經(jīng)理。
這本書當中，我首先最想談的是第二十六章《合理運用敏捷方法》。在我畢業(yè)以后工作的第一家公司（某知名電商），在我成為產(chǎn)品經(jīng)理之后跟隨的第一位leader，恰好也是eBay的前技術經(jīng)理，到國內(nèi)之后擔任技術總監(jiān)，他也時常提到敏捷開發(fā)。然而我其實并不能清楚地定義出什么是敏捷開發(fā)，在工作的零碎片段中對敏捷開發(fā)的大體印象就是“小步快跑，快速迭代”？就是當我們需要完成一個功能的開發(fā)時，只需要做到能夠驗證想法的程度即可，不必盡善盡美，當時的我以為敏捷只是與開發(fā)密切相關，于產(chǎn)品而言只需要有概念即可。后來換了一家公司（某知名互聯(lián)網(wǎng)），合作的是一位有經(jīng)驗的項目管理，在項目中會時常提到敏捷開發(fā)，那時我以為敏捷開發(fā)是項目管理當中的一個概念。但是直到我拜讀了《啟示錄》以后，才明白到敏捷于產(chǎn)品經(jīng)理而言也相當重要，并且滲透到產(chǎn)品工作的方方面面，對于產(chǎn)品開發(fā)項目而言是一個偉大而重要的概念。
作者在此章提到了產(chǎn)品軟件領域使用敏捷方法的訣竅。產(chǎn)品軟件（product software）是相對于定制軟件（custom software）的概念，區(qū)別在于軟件本身以什么為發(fā)展的核心。產(chǎn)品軟件即以產(chǎn)品自身的市場需求、使用這款軟件的大多數(shù)人的需求而定義需求和軟件發(fā)展計劃，產(chǎn)品經(jīng)理的任務就是發(fā)掘大多數(shù)人的需求，常見于2C的產(chǎn)品；而定制軟件則是以出資做這款軟件的人的需求為主，出資方的意志代替了廣大用戶的意志，而產(chǎn)品經(jīng)理面向的用戶則變成了出資方，常見于2B的產(chǎn)品。
回歸正題，作者所說的這十個在軟件產(chǎn)品領域使用敏捷方法的訣竅如下（不適用于定制軟件）。
1. 產(chǎn)品經(jīng)理即產(chǎn)品負責人（product owner），他代表了客戶的需求，因而需要與產(chǎn)品開發(fā)團隊保持密切的聯(lián)系，協(xié)助督促開發(fā)進程，及時解決出現(xiàn)的問題。
2. 使用敏捷方法絕不等于省略產(chǎn)品規(guī)劃。
3. 產(chǎn)品經(jīng)理和設計師的工作進度應該比開發(fā)團隊領先一兩個迭代周期，確保你們有足夠時間攻克難題。
4. 盡量把產(chǎn)品設計工作拆分成獨立的部分，分而治之，但也不能拆的太細——好比設計建筑不能一次只設計一個房間。
5. 產(chǎn)品經(jīng)理的主要任務是定義有價值、可用的產(chǎn)品原型和用戶故事（user story），作為開發(fā)的基礎。
6. 讓開發(fā)人員自主劃分迭代周期。
7. 產(chǎn)品經(jīng)理和交互設計師必須出席每天的晨會。
8. 除非達到了產(chǎn)品經(jīng)理的要求，否則不要輕易發(fā)布新版本。
9. 在每次迭代完成后，產(chǎn)品經(jīng)理應該向團隊展示產(chǎn)品現(xiàn)狀，以及下次迭代的產(chǎn)品原型，讓大家看到工作成果，同時加深大家對產(chǎn)品的理解，增強團隊對這種開發(fā)方式的信心。
10. 在團隊內(nèi)展開敏捷培訓。
現(xiàn)在主要是想要圍繞作者提到的這某些點，結合我自身的經(jīng)歷來談談，主要也是做一個自我的對照和總結。
1. 產(chǎn)品經(jīng)理即產(chǎn)品負責人（product owner），他代表了客戶的需求，因而需要與產(chǎn)品開發(fā)團隊保持密切的聯(lián)系，協(xié)助督促開發(fā)進程，及時解決出現(xiàn)的問題。
作者提到的第一點是最為關鍵，也是最為理想的情況。然而現(xiàn)實是從我畢業(yè)工作到現(xiàn)在，產(chǎn)品經(jīng)理和產(chǎn)品負責人以及權責基本上沒有出現(xiàn)過對等的情況，主要情況有兩種：第一，產(chǎn)品經(jīng)理與產(chǎn)品負責人并非同一人，與實際產(chǎn)品和開發(fā)團隊關系并不密切；第二就是作者在第二章提到的，產(chǎn)品營銷人員和產(chǎn)品經(jīng)理的一些工作范圍交叉。
第一種情況，主要是出現(xiàn)在一些年輕的產(chǎn)品經(jīng)理身上。剛進入第一家公司的時候，因緣際會成為了產(chǎn)品經(jīng)理。當時在一個內(nèi)部小創(chuàng)新團隊，團隊leader是技術總監(jiān)，而我就成為了團隊唯一的產(chǎn)品?？偙O(jiān)是團隊的owner，項目的目標人物基本以他為原型，所以我們的需求主要來源于他。此時回頭再看，其實當時的團隊就有點像定制軟件，完全圍繞客戶而不是用戶進行開發(fā)，那么我其實就只是一個“制作產(chǎn)品文檔”的產(chǎn)品專員，客戶認為怎么樣才是對的我們就如何做，但是是不是符合用戶，沒有沒有足夠量的數(shù)據(jù)去驗證（當然這又涉及到項目冷啟動的學問了），因此不得而知。在開發(fā)的實際過程中，owner忙于其他工作，并無太多精力投入到實際產(chǎn)品的細節(jié)打磨當中。最后，可想而知項目并沒有得到很好的發(fā)展。這種情況對于初生產(chǎn)品經(jīng)理會相對痛苦，由于缺乏經(jīng)驗，可能作出的判斷有偏差，并且沒有數(shù)據(jù)和經(jīng)驗支撐證明自己的想法，因此不斷地需要向上級請示。特別當你上司是一個對細節(jié)很在意的人，那么你做的產(chǎn)品細節(jié)一旦不符合他的想法，你的需求就必須推翻重做。
可笑的是，你的設計和開發(fā)人員面對這種需求變更的時候，會問一句，“你不才是產(chǎn)品經(jīng)理嗎？”如果你沒有辦法阻止和PK掉不合理的需求變更的話，結果就是我們會喪失下游的工作伙伴對我們的信任。因此我們應該學會的是兩點，第一點是如何管理好需求的變更，這其中也涉及到一些項目管理的節(jié)奏和方法；第二是如何管理你的上司，如何讓你的上司信任你和放權給你。
第二點是作者在第二章用了長篇大論進行論述的問題，產(chǎn)品營銷人員和產(chǎn)品經(jīng)理的工作交集主要有三種誤區(qū)。
1- 由市場營銷人員定義產(chǎn)品；
2- 兩人分擔定義產(chǎn)品的工作；
3- 一人兼任兩項工作
筆者現(xiàn)在也深陷這個問題的漩渦之中，正好看到作者對這個問題的一些看法，在此我也簡單說下。筆者現(xiàn)在的工作主要是偏向營銷類的產(chǎn)品，目前的工作基本是處于第二種情況，兩人分擔定義產(chǎn)品的工作。主要問題在于大家并沒有清楚認識到彼此的工作職責應該是什么。
產(chǎn)品經(jīng)理負責詳細定義待開發(fā)的產(chǎn)品；產(chǎn)品營銷人員負責向外界宣傳和推廣產(chǎn)品。
即使負責是一款營銷類的產(chǎn)品，如常見的營銷H5，也應該“為每款產(chǎn)品指派一名專職的產(chǎn)品經(jīng)理”，將產(chǎn)品需求和用戶體驗設計相結合。產(chǎn)品營銷人員定義的產(chǎn)品，很容易忽略用戶體驗的環(huán)節(jié)。
每個項目的目標是明確的、突出的，但是評估產(chǎn)品成功與否的指標卻非只是項目目標是否達成。而產(chǎn)品營銷人員很容易只為了項目目標而去定義產(chǎn)品，忽略了產(chǎn)品生命周期應該關注的一些健康的指標，產(chǎn)品經(jīng)理則不然。產(chǎn)品經(jīng)理的任務就是打磨產(chǎn)品細節(jié)與體驗，并且與交互設計師交集較多，因此在思維方式本身會關注比較多在產(chǎn)品本身；而產(chǎn)品營銷人員的精力除了在產(chǎn)品本身以外，還得關注產(chǎn)品的營銷、渠道、推廣成本等等，因此對產(chǎn)品本身的關注度肯定不如產(chǎn)品經(jīng)理。這也是作者最后一點說的，當一個人兼任兩項工作的時候，第一是會有精力方面的問題；第二點就是并非每個人都能有能力在產(chǎn)品營銷和產(chǎn)品管理方面均具有突出才能的。
2. 使用敏捷方法絕不等于省略產(chǎn)品規(guī)劃。
在產(chǎn)品之間或者產(chǎn)品研發(fā)之間的討論中，許多人常常會聽到一句話，“先簡單做吧”。這句話，引起了許多人的誤解，敏捷開發(fā)就是邊做邊看？這其實是有具體的使用場景的一句話。
我能想到的場景有如下一些
- 已有中長期產(chǎn)品規(guī)劃，討論的需求細節(jié)屬于整個產(chǎn)品的非核心部分；
- 產(chǎn)品本身對于此需求細節(jié)有經(jīng)驗把握，認為此細節(jié)并不會為目標帶來太大數(shù)據(jù)、體驗的提升；
- 此需求細節(jié)不影響整體效果，可灰度收集數(shù)據(jù)再作細化；
因此并非使用敏捷方法則是省略產(chǎn)品規(guī)劃，相反的，是對產(chǎn)品規(guī)劃了然于心，明白哪些是核心，哪些細節(jié)不追求完美也無傷大雅。正如作者所說“只不過在敏捷環(huán)境里，規(guī)劃周期應該適度縮短，反復迭代，采用輕量級的機會評估方法替代冗長的市場需求文檔”。
此外還想提到一點。對于已經(jīng)相對成型的客戶端產(chǎn)品來說，功能點的搭建一般會比較零碎，因此零碎的功能需求比較適合小步迭代。一來是鑒于客戶端的特性，最好是保證了主體功能完整以后，快速上線灰度收集用戶數(shù)據(jù)，看用戶對此功能的反應是好是壞，若是反映良好再迭代細化。這樣既可以減少試錯成本，也可以堅定和增強產(chǎn)品研發(fā)的信心。二來則是顧及用戶對于新版本的感受，慢慢過渡會比一下子給用戶一個可能無法適應的新版本來的要好。
對于相對完整的一次營銷活動，例如H5來說，則需要相對完整的規(guī)劃。營銷活動一般是一次性產(chǎn)品，用戶使用過一次（指活動完結）后則沒有保留的價值了。因此營銷活動的產(chǎn)品規(guī)劃必須是最完整最細致，不能有一絲漏洞。但是對于營銷活動而言，敏捷則是在保證活動主流程完整的情況下，對于非核心部分的適當舍棄，當數(shù)據(jù)表現(xiàn)符合預期時，再迭代固化成可用的插件或模型。
3. 產(chǎn)品經(jīng)理和設計師的工作進度應該比開發(fā)團隊領先一兩個迭代周期，確保你們有足夠時間攻克難題。
一個項目總體說來可分為幾個階段。
“需求期 - 研發(fā)期 - 測試期 - 灰度期 - 運營期”
在研發(fā)期之前，產(chǎn)品經(jīng)理和交互設計師就必須交付一份完整的和達成統(tǒng)一的文檔。交互設計師與產(chǎn)品經(jīng)理的關系最為密切，分工也會略有重合。交互設計師側重界面本身的合理性、邏輯性，是表現(xiàn)層面和用戶感知層面的的組織者，交付成果給到UI進行設計，為研發(fā)期儲備原材料；而產(chǎn)品經(jīng)理除了考慮用戶感受層面的邏輯以外，還需要考慮項目數(shù)據(jù)目標、前后臺數(shù)據(jù)交互可行性、項目時間安排等等。由于產(chǎn)品經(jīng)理在產(chǎn)生需求文檔的時候，更多考慮邏輯和項目目標，因此需要交互設計師幫助糾正一些給用戶感知到的信息，使得流程更加順暢，信息傳達到位。兩者意見達成一致以后，就交付到給視覺設計師進行表達，并且需要一定時間進行三人的意見統(tǒng)一。項目越大，產(chǎn)品經(jīng)理、交互設計師、視覺設計師需要花費協(xié)調(diào)的時間就越多。而研發(fā)資源總是稀缺，因此交付到研發(fā)手上的需求必須是清楚的、完整的，一來是提高研發(fā)的效率，二來則是使得需求上游人員思考清楚產(chǎn)品需求細節(jié)與規(guī)劃，減少需求返工帶來的人力浪費。
其他部分在書中均有敘述，我也無太多想要說明的，在此就不展開贅述了。最后想要提到的一點就是注意向團隊展示項目成果增強信心以及展開敏捷培訓。在實際參與項目的經(jīng)歷當中，發(fā)現(xiàn)許多聲稱使用敏捷開發(fā)的團隊，除了項目經(jīng)理以外，并無太多人真正明白敏捷開發(fā)的含義。而使用此種開發(fā)方法的團隊若是對敏捷開發(fā)的真正含義無法理解，則容易產(chǎn)生內(nèi)耗。即大家無法朝著同一個目標，走同一條路，花費大量時間在討價還價上，無法達到默契合作的境界。如此不但浪費開發(fā)時間，也會影響大家對項目的信心。因此展開敏捷培訓以及展示敏捷項目成果，能夠有效解決這些問題。
