品牌行銷策略，產品行銷與設計，各類型行銷推廣案例分享-品牌行銷點點讚
編輯導語：產品在經由市場定位、戰略規劃、產品設計等流程之后，便可以進入正式的開發環節。在這一環節中，產品團隊應當注意哪些事項、以避免造成生產活動的浪費或是團隊工作的不協調？本文作者對敏捷開發進行了總結分享，一起來看一下。
至此，我們可以進入產品開發（生產）階段了。
在工業領域，MVP開發一般在實驗室或研究中心完成，經過測試驗證后，按照產品文檔標準要求在特定的工廠進行批量生產。
實物產品在批量生產過程中遵循“精益管理”的思想，精益管理要求企業的各項活動都必須運用“精益思維”，“精益思維”的核心就是以最小資源投入，包括人力、設備、資金、材料、時間和空間，準時地創造出盡可能多的價值，為顧客提供新產品和及時的服務。
精益管理的目標可以概括為：企業在為顧客提供滿意的產品與服務的同時，把浪費降到最低程度。
企業生產活動中的浪費現象很多，常見的有：
- 錯誤——提供有缺陷的產品或不滿意的服務；
- 積壓——因無需求造成的積壓和多余的庫存；
- 過度加工——實際上不需要的加工和程序；
- 多余搬運——不必要的物品移動；
- 等候——因生產活動的上游不能按時交貨或提供服務而等候；
- 多余的運動——人員在工作中不必要的動作；
- 提供顧客并不需要的服務和產品。
努力消除這些浪費現象是精益管理的最重要的內容。
由于我在實物產品的規模化生產領域缺乏實戰經驗，在此就不再為大家做太多的講述。在互聯網領域，精益的思想同樣適用，并在敏捷開發中體現得淋漓盡致。
本小節，我著重地為大家講解關于敏捷開發的精髓知識內容，幫助互聯網/軟件產品經理實現提高顧客滿意度、降低成本、提高質量、加快流程速度和改善資本投入，使組織社會性的價值實現最大化。
一、敏捷開發宣言
敏捷開發以用戶的需求進化為核心，采用迭代、循序漸進的方法進行產品開發。在敏捷開發中，產品項目在構建初期被切分成多個子產品，各個子產品的成果都經過測試，具備可視、可集成和可運行使用的特征。
換言之，就是把一個大產品分為多個相互聯系，但也可獨立運行的小產品模塊或功能，并分別完成，在此過程中產品一直處于可使用狀態。
在2001年，17位敏捷方法論的擁護者和倡議者聚集在猶他州的雪鳥滑雪場，起草了一份陳述敏捷組織原則的文件。這份文件基本上代表了不同敏捷方法論的共同點，我們稱之為“敏捷宣傳”，也叫做敏捷軟件開發宣言，是指導以人為中心的迭代軟件開發方法，具體四個核心價值內容如圖5-14所示。
圖5-14 敏捷開發宣傳
1. 個體和互動高于流程和工具
項目是通過人來完成的，流程和工具可以幫助人，但絕不能自行完成工作。
雖然，過程和工具都是好東西，但是它們有時也會成為障礙。面對面的直接溝通，比一些流程性的文件和工具溝通，效率要高出很多。
當然最好的是，在溝通后就多方達成的共識形成一個簡要性的文檔備錄。
2. 工作的軟件高于詳盡的文檔
可用軟件的價值是很重要的，因為軟件是為業務目標提供支持的，是可用軟件（而不是文件）為客戶和也會傳遞了高價值。
一般來說，一個敏捷項目的進展情況是由開發了多少可用軟件來跟蹤和報告的。但不是說文檔一無是處，適量的文檔在絕大多數的項目中是有益的和必要的。
敏捷通過尋求“剛好足夠”的文檔來避免這種情況。其中的原則是任何文件的創建都應與為客戶創造的價值直接掛鉤，且不論該價值體現在現狀還是將來。
3. 客戶合作高于合同談判
這個價值觀的核心是越接近你的客戶越好。客戶最清楚他想要什么，即使在需求明確過程中也會包含一些試驗和錯誤。在合同談判期間，試圖避免所有的嘗試和錯誤不發生是不現實的，也是徒勞的。
定位你與客戶的關系很重要，你是選擇對抗你的客戶還是選擇與你的客戶一起為接近方案努力而使每個人都受益？敏捷團隊更愿意和客戶在同一方向一起使勁而不是把力氣花在背離客戶的方向。
4. 響應變化高于遵循計劃
任何一個曾在軟件項目工作過的人都知道這些項目的本質就是變化。即使底層的技術也在快速變化，新的途徑和可能性在不斷地被打開。對變化響應的速度就決定你在市場上的靈活性，循規蹈矩的做事將被市場甩在后面，永遠慢市場半拍，慢慢你的市場會被蠶食掉。
當你讀到這個宣言，你會發現它具有最高原則性，因為敏捷方法論在最高層面上是一致的，但到具體細節上每種方法都會不同。除了敏捷宣言之外，還有12條準則的支持文件，為敏捷宣言提供了更多的擴充細節。
準則1
我們的最高目標是，通過盡早和持續地交付有價值的軟件來滿足客戶。敏捷團隊可以很快將可用軟件交付到客戶手中，并且是開放式地快速更新，給客戶帶來優先級最高地價值。
準則2
歡迎對需求提出變更，即使在項目開發后期；要善于利用需求變更，幫助客戶獲得競爭優勢。
傳統項目管理中的一個原則是設法去影響和控制會導致變化地因素。敏捷項目管理預期到需求會發生變化，并在實際過程中歡迎擁抱這些變化，即使這些變化發生在項目后期。
迅速應對和適應變化能給客戶帶來顯著地競爭優勢，從而應對新的機遇。
準則3
要不斷交付可用的軟件，周期從幾周到幾個月不等，且越短越好。
不同的敏捷方法論采用不同的迭代周期，但都是相對較短的，關鍵是能快速把可用的軟件交付到客戶手上并能利用軟件獲得有意義的回報。較短的迭代周期可以使團隊持續關注客戶的價值。
準則4
在項目過程中，業務人員、產品經理與開發人員必須在一起。敏捷項目管理，讓業務人員、產品經理和開發人員彼此靠近，并時常讓他們在同一個地方一起工作。
通過這樣的方式讓業務人員和開發人員之間沒有隔閡，是因為業務人員和開發人員的共同目標就是通過可用的軟件向客戶傳遞價值。
準則5
要善于激勵項目人員，給他們所需要的環境和支持，并相信他們能夠完成任務。
傳統項目管理，常對員工進行微觀管理，不僅告訴他們要做什么，還告訴他們如何做，無意間形成自上而下的管理方式。
敏捷項目建立了一支強有力的團隊并積極避免微觀管理，要求一個自律的團隊，自發告知開發人員做什么。提供相關資源，給予鼓勵，相信團隊能夠完成任務。
準則6
無論是團隊內還是團隊間，最有效的溝通方法是面對面的交談。非正式口頭的溝通在敏捷項目管理中遠比正式的書面溝通更普遍。其想法是兩個人坐在一起為一個解決方案努力會比他們用郵件來來往往或交換文件更有效率。
面對面溝通是敏捷項目管理的精髓。這種溝通是公開的，任何團隊成員都可以自由參與對話。
準則7
可用的軟件是衡量進度的主要指標。計劃和文件可能是有用的，但是當最根本的目標發生變化時，它們就可能失去應有的價值。
傳統項目往往極其糾結的是，項目的不斷更新使得文件成為一種負擔。真正的價值是通過結果來表達的，結果又是通過可用的軟件來呈現的。
準則8
敏捷過程提倡可持續的開發。項目方、開發人員和用戶應該能夠保持恒久穩定的進展速度。
可持續開發的焦點是在團隊身上，他們會努力保持一個穩定的可持續的進展速度，從而使得團隊成員不會在迭代周期的尾端匆忙趕工。
理想的目標是保持一種可持續的速度，使團隊成員不會感到過度的壓力和筋疲力盡，而是能夠保持在一個理想的強度下工作。
準則9
對技術的精益求精及對設計的不斷完善將提升敏捷性。設計得越完善，維護起來就越簡單，即使遇到變化，穩定和優質的項目會比劣質的項目更加允許團隊快速應對變化。
準則10
要做到簡潔，即盡最大可能減少不必要的工作。這是一門藝術，被所有的敏捷方法所擁護，尤其是精益方法。關鍵點對客戶價值保持關注和毫無猶豫的削減不增加價值的活動。保持簡單不只是一種愿望，它使最基本的原則。
準則11
最佳的架構、需求和設計出自自我組織的團隊。
自我組織是敏捷團隊的核心元素之一。當一個團隊是自我組織型的時候，說明該團隊自己去決定工作如何分配及誰去做某個特定的工作，而不是人力資源部門或管理層來決定。不僅小團隊是自我組織的，較大的跨職能團隊也可以是自我組織的。
準則12
團隊要定期反省如何能夠做到更有效，并相應地調整團隊的行為。
敏捷項目中最可預見的事情就是變更。傳統項目里當項目或階段完成時開會總結是最常見的做法，而敏捷試著通過更頻繁的回顧來完成這項工作。在一個回顧活動中，團隊查看各迭代周期中已完成的工作或發布，并評估下一次如何改進他們的做法。每日站立會議即每天簡單碰頭15分鐘是另一項協調團隊努力方向、團隊自我評定和自我調整的重要方式。
敏捷開發的業務目標是更早地交付價值，價值的交付不僅僅是早晚上線兩天的問題，而是更早上線能夠給自己和客戶帶來更大的價值。越晚交付，價值越低。更快不是絕對速度的快，而是指時間上的早，即通過迭代交付實現分批和更早的交付。
同時靈活地響應變化。當今世界跨界顛覆的案例數不勝數，一個企業的核心能力不再是已有的能力有多強，而是靈活響應變化，快速學習的能力有多好。
注意：在新產品開發中使用敏捷，一定要考慮整體價值的交付，這種交付是可以交付到用戶手中使用的交付，是面向市場的交付。
我曾遇到過一個創業團隊花了一年半的時間，迭代了26個版本，依然沒有完成用戶交付，沒有將產品推向市場，這種悲劇盡量避免。采用做最小可行性產品（MVP）方法可以有效地避免這種情況的發生。
二、Scrum敏捷開發
在敏捷實踐體系中，迭代交付模式是敏捷開發的核心要素。
敏捷開發方法有很多，Scrum提供了迭代管理和持續改進的框架，如圖5-15所示。Scrum中的主要角色包括同項目經理類似的Scrum主管角色負責維護過程和任務，產品負責人代表利益所有者，開發團隊包括了所有開發人員。
圖5-15 Scrum敏捷開發流程
Scrum是一個包括了一系列的實踐和預定義角色的過程骨架（是一種流程、計劃、模式，用于有效率地開發軟件）。
Scrum的最大特色是靈活和增量交付，要求團隊之間有開放的溝通和協作。首先是由產品經理收集和整理需求，然后和開發團隊確定開發列表，接著進入開發沖刺狀態，后面就是日常開會、后期改善。在實際應用中，我們通常將其分為以下5個步驟。
1. 步驟1：創建用戶需求列表
一個產品的需求可能來自客戶、團隊或者產品經理的想法，這些需求的描述必須符合：作為_______，我希望_______，以完成______。這樣的好處是讓整個團隊更容易理解需求，達成共識，圖5-16所示為一個實例。
圖5-16 用戶需求列表（產品功能需求）
2. 步驟2：召開計劃會議和制定開發計劃（計劃版）
Scrum Master負責組織召開計劃會議，產品經理和團隊一起根據需求的重要性、開發量來確定開發優先級，做工作量預估，制定迭代開發計劃（從需求列表中挑選出高優先級 Story（用戶需求）作為本次迭代完成的目標。
這個目標的時間周期是1~4個星期，然后把這個Story進行細化，形成一個Sprint Backlog（迭代代辦事項））。
開發團隊一旦接受這些開發任務，就應該準時完成，不得修改交付標準。
3. 步驟3：執行迭代計劃（任務板）
首先，你需要確定每次Sprint（開發沖刺）的周期，短的周期可以更頻繁地發布產品版本，因此可以從客戶那里更迅速地收到反饋，修正錯誤。
這個周期一般為1~4周。當然，你可以根據團隊成熟程度或迭代任務確定一個合適的迭代周期，比如2周，這樣可以讓開發人員更投入地工作。
所謂Sprint，就是在一定時間內全身心投入開發。這個階段通常用看板來管理需求，每個卡片就是一個開發任務，工作完成后，可以將卡片移到下一個階段，用看板管理需求。
如圖5-17所示：你也可以使用專門的軟件來管理看板，例如國外的Jira、國內的明道。
圖5-17 敏捷開發項目管理看板
在沖刺中，每一天都會舉行項目狀況會議，被稱為“每日站會”。會議在固定地點和每天的同一時間舉行，對于遲到者團隊常常會制定懲罰措施（例如罰款、做俯臥撐、在脖子上掛橡膠雞玩具）。
不論團隊規模大小，會議被限制在15分鐘。所有出席者都應站立，每個人都必須發言。
會議的目標是討論當前的任務的狀態，一個推薦的匯報形式是：我昨天已經做了什么？我接下來準備做什么？現在遇到什么阻礙和問題？
注意在會議中團隊成員不必要針對每個問題進行探討，只是作為一個重要信息的反饋通道，具體問題相關成員在會后私下當面溝通解決，這樣更加高效，避免浪費問題無關成員的時間。
4. 步驟4：產品測試和演示
因為每次的Sprint目標就是交付一個可以用的產品特性，所以測試工作非常重要。
有不少方法可以減少測試周期，比如，你可以減少需求數量，或者讓開發參與測試。
當一個Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成。這時，我們要進行演示會議，也稱為評審會議。
產品負責人和客戶都要參加（最好本公司老板也參加），每一個Scrum團隊的成員都要向他們演示自己完成的軟件產品（這個會議非常重要，一定不能取消）。
5. 步驟5：回顧會議和下一個Sprint計劃
每一個沖刺完成后，都會舉行一次沖刺回顧會議。
回顧會議也稱為總結會議，會議的時間限制在4小時，以輪流發言方式進行，每個人都要發言，哪里做得好、哪里不好都可以提出，總結并討論改進的地方，放入下一輪Sprint計劃。
三、Sprint沖刺會議
沖刺（Sprint）計劃是Scrum中的事件。Sprint計劃的目的是定義在Sprint中可以交付什么，以及如何實現該工作。
Sprint計劃是由整個Scrum團隊協作完成的。與體育界不同的是，Scrum鼓勵總是全速前進，這樣就可以在不斷學習和改進的同時交付可用的軟件。
在Scrum中，Sprint沖刺是完成所有工作的固定時間段，即一個迭代周期。在采取行動之前，必須設置沖刺時間，需要確定時間間隔將是多長時間，沖刺目標以及開始的位置。
沖刺計劃會議通過設置議程和重點來開始沖刺。如果做得正確，它還將為團隊創造動力，提供取得成功的環境。不良的沖刺計劃可能會因設定不切實際的期望而使團隊脫軌。
為了確保沖刺的順利進行，在沖洗計劃中要包含若干會議為沖刺過程提供支持，如圖5-18所示。
圖5-18沖刺計劃包含會議
運行一個偉大的Sprint計劃事件需要一些紀律。產品負責人必須做好準備，結合之前Sprint評審的經驗教訓、涉眾的反饋以及他們對產品的愿景，從而為Sprint做好準備。
為了增加透明度，產品待辦事項列表應該是最新的和細化的，以提供清晰的信息。
Backlog細分在Scrum中是一個可選的事件，因為有些Backlog不需要它。然而，對于大多數團隊來說，最好是在Sprint計劃之前讓團隊一起檢查和細化Backlog。
輸入Sprint計劃的一個很好的起點是產品Backlog，因為它提供了一個“東西”的列表，這些“東西”可能是當前Sprint的一部分。團隊還應該查看在增量中完成的現有工作，并查看容量。
輸出Sprint計劃會議最重要的結果是團隊可以描述Sprint的目標，以及他們將如何開始朝著這個目標工作。這在Sprint Backlog中是可見的。
沖刺計劃應該限制在每周沖刺不超過兩小時。因此，例如，為期兩周的Sprint計劃會議將不會超過兩個小時。這被稱為“時間限制”，或者為團隊完成一項任務設置最大時間量，在本例中是規劃Sprint。
Scrum Master（敏捷教練）負責確保會議的時間安排被理解。如果團隊在時間框內完成之前感到高興，那么事件就結束了。時間框是允許的最大時間，沒有最小時間限制。
在制定沖刺計劃的過程中，很容易陷入“困境”，專注于哪個任務應該先做，誰應該做，以及需要多長時間。
對于復雜的工作，您在開始時所知道的信息水平可能很低，而且大部分信息都是基于假設的。Scrum是一個經驗主義的過程，這意味著你不能預先計劃，而是在實踐中學習。
Sprint計劃需要一定程度的評估。團隊需要定義在Sprint中可以做什么，不可以做什么：估算工作量和團隊能夠承受的容量。
良好的評估需要一個基于信任的環境，在這個環境中，信息可以自由提供，并且在過程中討論假設。如果評估中使用負面的，對抗性的方式完成工作,那么很有可能估算的工作量將很大，會造成不必要的資源浪費。
我們很容易陷入沖刺計劃的細節，忘記沖刺計劃的重點是為下一個沖刺建立一個“剛剛好”的計劃。這個計劃不應該成為團隊背后的搗亂者，相反，它應該將團隊的注意力集中在有價值的結果上，并為組織提供保護。
Scrum的一個關鍵原則是承認客戶可以在項目過程中改變主意，變更他們的需求，而預測式和計劃式的方法并不能輕易地解決這種不可預見的需求變化。
同樣，Scrum采用了經驗方法——承認需求無法完全理解或定義，因此關注如何使得開發團隊快速響應不斷出現的需求。
四、Bocklog用戶故事
Sprint目標在高層次上描述了Sprint的目標，但是也可以在編寫Backlog用戶故事條目時體現。
為了切身了解客戶的需求，有些產品設計的市場和研發團隊嘗試運用基于客戶情形，透過觀察客戶、敘說故事、編寫劇本、再現客戶情境和體驗，從而溝通傳達客戶需求的劇本導引設計法，利用人類內心思考、言詞表達的編故事、說故事的基本能力，將設計者及產品開發有關人員帶入產品使用時的情境，透過這種情境故事，讓設計者將與產品設計有關之信息自我內化吸收，轉換對團隊溝通。
用戶故事是從客戶的角度描述工作的一種很好的方式，如圖5-19所示。用戶描述將缺陷、問題和改進重新集中于客戶所尋求的結果，而不是所觀察到的問題。通過向用戶故事中添加清晰的、可度量的結果，你可以此評估什么時候能完成。
圖5-19 用戶故事示例
項目里不同的參與者有不同的需求，產品經理想跟蹤進度，開發人員想實現，產品經理想功能，產品老大有更高的視角，而用戶想要一個可用的系統，在這些充滿沖突的視角中，想要做出一個人人都支持、皆大歡喜的決定，并且持續保持平衡是很困難的事情。
整個項目組就像一個四驅車，一個角色的強勢就相當于一個輪子轉得過快，這對產品都是損失，導致車子的方向偏移。
我們通過大家一起建立產品全景圖的方式，讓項目組所有人包括用戶站在高空俯視產品，這種同一空間多點對多點的共識就自然地完成了。
我們通過這種一目了然、格式一致的故事地圖，讓項目組所有人都獲得足夠的信息，讓項目有一個明朗的開發流程，如圖5-20所示。
用戶故事地圖作為一種有效的需求工具，可以做到多角色、多視角。
以合作溝通的方式來全面理解用戶需求，涉及的主題包括怎么以故事地圖的方式來講用戶需求，如何分解和優化需求。如果通過團隊協同工作的方式來積極吸取經驗教訓，從中洞察用戶的需求，開發真正有價值的、小而美的產品和服務。
圖5-20用戶故事地圖示例
用戶故事地圖是一個吸引用戶參與設計他們所需產品的便捷手段。我們原型設計階段的所有內容來源于用戶故事地圖，因為故事地圖是用戶全程參與的，所以在我們整個設計過程中都有用戶的身影。
與參與性設計對立的是經驗性設計。
在進行新產品設計時，經驗性設計高度依賴前期的用戶調研，包括用戶訪談和用戶觀察，但是用戶不會成為產品設計的真正參與者，后面的階段基本是靠設計師經驗，幾乎沒有用戶身影。
但參與性設計“用戶故事地圖”通過簡潔明了、場景還原的方式讓用戶參與其中，每個用戶故事都做到站在用戶的角度，使大家快速知道用戶想要什么，為什么要這個。
用戶故事易讀、易懂，我們邊聊故事的同時進行頁面框架繪制，因此能激發用戶的積極性，成為產品設計的參與者。
同時，隨著用戶漸漸掌握如何口頭表達故事來描繪他們的需求，項目組成員與用戶間的關系變得更加親密主動，這種良性的循環使所有人員都獲益良多。
思考：以往我們共識用戶/產品需求的方式有兩種，一種是文檔，翻開一看，那些格式化的語言就變成了世界上最好的催眠曲。讀尚且如此，寫的人會怎么樣？寫文檔的產品經理腦子里一定會回響一個問題：“這東西寫了有人認真看么？”
有文檔看還是好的，還有些產品經理會直接拉上團隊成員聊，撰寫用戶故事地圖，就算交接需求了，這兩種方式你認為哪種更加敏捷有效？這里的共識是點對點的，或者單點對多點的，信息傳遞也會帶來信息內容的損耗，甚至錯誤的信息。
作者：長乘，公眾號：MVP-PM，歷任兩家世界500強企業產品專家！內容摘自：人民郵電出版社《獨具匠心：做最小可行性產品（MVP）方法與實踐》
本文由 @長乘 原創發布于人人都是產品經理，未經許可，禁止轉載
題圖來自 Unsplash，基于 CC0 協議