起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識敏捷開發模式中的需求規劃
敏捷開發對需求規劃的要求是很高的，首先需求是打散的，一個大的項目需求會拆分成很多小的功能完整的需求，以便排定優先級去逐個實現；其次打散的需求全部實現之后，組合起來的要是一個整體，而不是散碎的個體，這樣就要求需求規劃非常完整，需求拆分非常精確。所以個人感覺敏捷開發提升了開發效率，但是對需求規劃的要求更高了。如果是產品經理來擔當PO的話，就是對產品經理的需求規劃能力提出了更高的要求，必須有清晰的思路，很強的需求規劃能力才行，這樣才能保證敏捷開發可以按照既定的設想去一步一步實現產品的設計。
很多人認為既然敏捷開發了，那就應該不用寫文檔了，其實不然，最基本的PRD 還是要有的，哪怕是本來要一口氣寫一份完整的PRD，采用敏捷開發之后，拆分成好幾個部分去寫，最后才合在一起。PRD除了講解需求的作用，還是產品歷史功能追溯、記錄的作用，用來保證需求設計、開發實現、測試驗證的過程是在同一個基準的理解基礎上的，避免出現各自的想法不一致導致的產品形態走樣。要保證整個產品的過程流暢的走下去，首先就得保證需求規劃的過程是完備且正確的。
需求收集
敏捷開發模式下照樣有需求收集的過程，不然開發個什么勁呢，不管是產品經理自己的想法，還是用戶的需求，總有一個收集驗證的過程。那么如何進行需求收集呢？除了老三樣的問卷調查、意見反饋、競品分析外，還可以有數據分析、同事反饋、用戶觀察等。
意見反饋：現在做任何互聯網的產品，一般都會在產品上預留一個給用戶反饋使用意見的口子，這就是我們經常在各個產品中見到的“意見反饋”鏈接頁面或者是按鈕彈窗，用以收集用戶在使用過程當中反饋過來的信息，進而把這些信息收攏起來做統一分析，以得出相應的分析結果，看是否可以轉換為產品需求。具體的處理過程可以參見意見反饋—小功能大設計。
問卷調查其實也是用戶反饋中的一種，用以對特定人群或者不限人群投放預先設計好的問卷調查內容，適當加以鼓勵填寫的措施，以收集到一定數量的用戶填寫信息。
競品分析應該是最常用的一種方式，這種方式最為直觀，可以直接找到相類似的產品進行使用，然后分析其功能點和特性，找出優缺點。這種方式最常見，所以也經常造成功能上先類似的產品之間長的都差不多，也就是大家都說的“天下文章一大抄”，加引號的哈，我們還是有創新的，呵呵。
數據分析的方式是比較適合敏捷開發的，原因在其分析的結果可以快速的反應在開發結果上，以觀察實際更改后的效果，比如一個購物流程，發現用戶老是停留在購物車頁面，就是無法轉換成有效訂單，這個結論一出來，我們就可以去分析購物車頁面是否哪里體驗做的不夠好，導致用戶提交訂單的比率下降，分析的結果可以馬上進行開發改進。
用戶觀察是要坐到用戶旁邊去觀察用戶使用產品的操作過程，不做任何限定，讓用戶以自己的方式隨意使用產品，觀察整個使用過程，適當的還可以進行一些提問。這種方式成本比較高，比較適合觀察公司內部用戶，或者是在用戶的電腦上安裝錄屏軟件，以達到事后觀察的效果。
同事反饋只能小范圍使用，其實就是內部PK，三個臭皮匠頂個諸葛亮，一群產品經理的智慧是比較可怕的，自己設計的產品要勇于拿出去分享，在PD內部做頭腦風暴，有時候會有意想不到的效果。
此外還有微博搜索、博客搜索等信息收集的渠道，不再一一闡述。
需求記錄
把搜集回來的需求做一定的分析之后得出的結論就是我們要記錄的需求條目，也就是可以排到敏捷開發計劃里面去實現的需求列表。一般我們記錄某個需求條目的時候都會考慮到用戶場景，以一個故事的形式表述出來。
用戶故事是從用戶的角度來描述用戶渴望得到的功能。一個好的用戶故事包括三個要素：
1.角色：誰要使用這個功能。
2.?活動：需要完成什么樣的功能。
3.?商業價值：為什么需要這個功能，這個功能帶來什么樣的價值。
用戶故事通常按照如下的格式來表達：作為一個<角色>, 我想要<活動>, 以便于<商業價值>。舉例：
作為一個“網站管理員”，我想要“統計每天有多少人訪問了我的網站”，以便于“我的贊助商了解我的網站會給他們帶來什么收益?！?/p>
需要注意的是用戶故事不能夠使用技術語言來描述，要使用用戶可以理解的業務語言來描述。具體的使用我想大家都非常清楚，畢竟產品經理每天都在和各色的用戶故事做斗爭。
需要注意的是，這樣的需求條目在安排到敏捷開發的計劃當中時，這些用戶故事必須滿足以下條件：
用戶故事的六個特性- INVEST（INVEST = Independent, Negotiable, Valuable, Estimable, Small, Testable ）
一個好的用戶故事應該遵循INVEST原則：
獨立性（Independent）— 要盡可能的讓一個用戶故事獨立于其他的用戶故事。用戶故事之間的依賴使得制定計劃，確定優先級，工作量估算都變得很困難。通常我們可以通過組合用戶故事和分解用戶故事來減少依賴性。
可協商性（Negotiable）— 一個用戶故事的內容要是可以協商的，用戶故事不是合同。一個用戶故事卡片上只是對用戶故事的一個簡短的描述，不包括太多的細節。具體的細節在溝通階段產出。一個用戶故事卡帶有了太多的細節，實際上限制了和用戶的溝通。
有價值（Valuable）— 每個故事必須對客戶具有價值（無論是用戶還是購買方）。一個讓用戶故事有價值的好方法是讓客戶來寫下它們。一旦一個客戶意識到這是一個用戶故事并不是一個契約而且可以進行協商的時候，他們將非常樂意寫下故事。
可以估算性（Estimable）—開發團隊需要去估計一個用戶故事以便確定優先級，工作量，安排計劃。但是讓開發者難以估計故事的問題來自：對于領域知識的缺乏（這種情況下需要更多的溝通），或者故事太大了（這時需要把故事切分成小些的）。
短?。⊿mall）— 一個好的故事在工作量上要盡量短小，最好不要超過10個理想人/天的工作量,至少要確保的是在一個迭代或Sprint中能夠完成。用戶故事越大，在安排計劃，工作量估算等方面的風險就會越大。
可測試性（Testable）—一個用戶故事要是可以測試的，以便于確認它是可以完成的。如果一個用戶故事不能夠測試，那么你就無法知道它什么時候可以完成。一個不可測試的用戶故事例子：軟件應該是易于使用的。
需求優先級
如何判斷需求優先級，這個根據不同的產品需求、業務場景會有不一樣的考量，不過一般可以遵循如下兩個原則：
1、? 價值，包括對產品自身的價值和對用戶的價值，價值越高的優先級越高；
2、? 緊迫性，時間要求越高的優先級越高，特別是線上問題的解決這種；
其他的考量具體的場景都會不大一樣，但是有一點，在評定需求優先級的時候最好數值化，就是給每個需求條目打分，評定一個優先級的值，這樣最直觀，單純的只是說優先級高、中、低不夠直觀，直接給一個數字就直接多了。比如1~10中10代表最高，優先級高的有10，9，8三種，顯然優先級同為高的里面，10的就比8的優先多了。
需求變更
不可避免，我們都需要面對這樣的問題，幸好，敏捷開發最大的優勢就是可以擁抱變化。但也不是說就可以想變就變，產品經理還是要盡量控制好這種變更的發生，只有當一些不可控的因素發生后才行，比如政策法規改了這種，其他的都要盡量避免，所以說在制定需求規劃的時候一定要完善才行。
采用了敏捷模式，不代表產品經理只要和開發人員口頭講一下需求就可以了，還是要有一個完整的需求規劃過程，口頭的方式變數太大，還是會影響到產品的進展的。所謂以用戶痛點為中心的設計，就很適合敏捷的模式，快速迭代更改的都是用戶繼續得到解決或者改善的功能，自然需求優先級也會比較高。需求規劃會貫穿產品過程，這樣才能保證在敏捷的過程中產品的一致性。
?? ?? ??