作為產品經理或者互動設計師，亦或者UI設計師，每天都會遇到各式各樣的需求。有的一句話，有的一個簡單的文件，有的只是一個線框圖，各種程度的資料，不一而足。特別是如果在一個ued部門內的時候，處理的需求更為繁雜。如果沒有一個比較好的處理排序優先順序的方法，很容易將需求層級搞混亂，從而導致整體研發進度受影響。當前在需求分析階段，比較受歡迎的主要是KANO模型分析法、BCGmatrix分析法、MoSCoW分析法，這三個又被稱為“需求分析三劍客”。還有一個最近也比較受歡迎的分析方法，就是RICE法則，又稱為大米法則。在一個團隊中，不會過於去依賴某一個分析法，綜合的運用和考慮才能夠更高效和快速的處理當前的需求池。這四個方法，難不成在我們日常處理工作需求的時候，一個一個的去嘗試？顯然，這是一種對照葫蘆畫瓢的行為。在比較長的工作專案中，我們多少有了一些運用的經驗和理解。希望接下來的講述，也可以對你解決多而複雜的需求分級有一定的幫助。一、簡略思路BCGmatrix分析法、RICE分析法，這兩個的針對物件層級都含有產品層，或者說使用者體驗要素中的戰略層考慮。而KANO模型分析法和MoSCoW分析法，偏向針對的是具體的產品功能層級，所以，在我們考慮需求優先順序初步判斷的過程中，可以優先使用BCGmatrix和RICE分析法進行判斷。這其中RICE分析法，也可以針對產品功能層級進行分析（後文會詳細闡述）。BCGmatrix從對使用者價值和對公司價值維度，也可以涉及到功能層級。但這並不妨礙優先使用此兩個方法。透過前兩個方法，就可以優先排除一部分偽需求存在，但是下沉到產品功能層級的時候，就不可以再接著運用RICE方法了。可以從BCGmatrix分析法角度，篩選出需求的維度（對使用者價值高還是對公司價值高）偏向。再結合接下來的兩個分析法，以團隊實際和公司業務實際，來判斷需求處理的策略和優先順序。二、具體運用思路01、波士頓矩陣分析法波士頓矩陣是由波士頓諮詢公司創始人布魯斯·亨德森於20世紀60年代首創，被視為企業戰略策劃時代的一個節點。作為分析企業成長（企業實力）與市場份額（市場引力）之間的關係的工具，它高度概括了企業戰略決策的一般方法，最早用於分析企業的市場增長率和市場份額（市場佔有率），又稱為“市場增長率-相對市場份額矩陣分析、產品系列結構管理法等。雖然波士頓矩陣方法最初並非應用於網際網路領域，但是後來經過變化升級，漸漸的開始在網際網路領域應用。特別是在產品需求優先順序的判斷上。1.1、產品層篩選依據當前公司或者團隊產品偏向，或者新的業務場景需求對於當前公司產品的增長率或者市場佔有率影響性，初步區分需求池中真偽需求存在。此時，有些內容需求恐怕需要進行完整的報告文件，比較偏向戰略層的決策，都是上層推動的。你的意見建議，必須拿出有力的證據，才可以讓管理層認識到你的建議是對的。例如在“易出行”（已隱去真實專案名稱）中，當時涉及到幾個新的業務場景接入的問題，涵蓋掃碼、維保、充電等，那麼到底優先接入哪個場景的業務？關於戰略層的決策，嗯，一般做為產品經理或者互動設計師，是沒有許可權參與的，除非你已經達到總監級別了。當時，比較看好的是維保和充電，主要是結合當時市場層熱度以及結合我們內部那個專案主營業務來決定的。但是，卻忽略了團隊的資源配置以及所處那個階段的更為重要的是搶佔垂直市場，而不是去和其他已有實力的人搶份額。當然，關於最終的建議和討論是我們UED部分大佬去和老闆說明的。但是關鍵點你是可以和老大去表明的。1.2、產品功能層篩選正如上圖所示，對使用者有價值的需求，一般屬於使用者需求；對公司有價值的需求，一般偏向產品需求。這個時候，就看一下，其需求的本質是偏向哪一種型別了。a、明星功能需求即對使用者有價值，同時對公司也有價值的產品功能需求。可以既滿足使用者的部分需求，又可以實現產品的部分目標需求。和在企業規劃中一樣，處於雙高級別，是優先順序最高的需求。例如，在我們某一個場景的門店列表中是否增加導航入口這一功能，一方面，使用者購買之後，可以快速方便的去到附近門店消費，一方面門店提升了營業額，對我們平臺的信任度增加，這個功能就可以劃歸明星類產品需求。b、問題功能需求問題類需求雖然表面對公司沒有直接的商業價值，但是從對使用者價值角度而言，可以提升使用者的滿意度和忠誠度，所，綜合來說，這類需求從本質上來說也是對公司有價值，只是不直接。之所以是問題需求，因為會隨著時間或者業務變化，會變成明星需求或者現金牛需求，甚至會變為瘋狗需求。最終走向，存在不確定性，有很大的風險。例如，掃碼挪車這個需求，這個是一個不高也不低的需求，但是對於使用者而言，很多時候，又是一個非常必要的存在。特別是一二三線城市，因為各種原因，總有需要聯絡車主挪車的情況。它短期內，對於公司產品來說，其實算是一個雞肋的功能，和主營業務沒有強相關。但是對使用者的確有價值的，所以，我們在前期推廣的時候，很多人還是比較樂意註冊，但是出現了一個小失誤，就是沒有處理好註冊使用的流程限制門檻，比較繁瑣。結果可想而知。c、現金牛需求這類需求比較明顯的自然就是對公司有明顯的價值，但是從使用者角度而言，多少會有一些負面影響。從理論上來說，應該儘量避免對使用者體驗造成不良的影響。但是，需要看公司產品的情況的。例如，當前各種遊戲非常火熱，當然，似乎遊戲一直都是比較熱的。但是在你玩遊戲的過程中，會常常引導你去看直播，這種體驗，你應該不陌生。那麼像是某易或TX為啥這麼做呢？之前公眾號也有文章說明，這種就屬於現金牛類需求，公司的目的就是希望引流賺錢以盈利。d、瘋狗類需求最後這種需求，就是和第一類需求相反的“雙低”需求，也就是我們常說的偽需求。需要你判斷出，並儘量去排除掉。其實從以上幾個需求型別的分類闡述，就可以看出對於問題類需求和現金牛需求，考慮的時候，需要多考慮一步。在產品成長初期，例如我們之前的“易出行”，獲取使用者增長和提升使用者的留存率是第一要考慮的，那個時候，我們並沒有去考慮如何去盈利。所以，問題類需求優先順序高於現金牛需求。但是如果產品處於穩定成熟期，例如，現在的很多超級APP，公司的目標自然都是以提升盈利水平為第一要務，像是“拼多多、瑞幸”等。除此之外，我們在考慮需求的時候，涉及的因素是非常多的。上述的波士頓矩陣也只是提供我們一個分析的思路和處理的方向。自然還有其他的方法，可以幫我們進一步的去驗證其合理性，例如：RICE法則。2、RICE分析法一個好的優先順序排序框架可以幫助你用清晰的思考去理清專案裡面的每個因素，並以嚴謹、一致的方式將這些因素結合起來。但是你可能很難找到一個能讓你以一致的方法去對比不同思路的系統。所以，我們需求掌握不止一種分析思考的方法，才可以有效的管理我們的工作和生活。RICE是用來評估各專案需求的四大因素的首字母縮寫：觸達（Reach），影響力（Impact），信心度（Confidence）和努力（Effort）。觸達（reach）為了避免出現主觀需求的偏差，我們應該評估每個專案在既定時間內會影響多少人。對於我的團隊來說，就是“在一個季度內，這一個專案將會影響到多少客戶？”觸達範圍是衡量每個時間段內產生的使用者數或活躍數。也許會是“每季度客戶數”或者“每月交易額”。儘可能使用產品指標中真實的測試資料而非虛構的資料。最終，我們選取的是DAU和MAU。舉例：1、：每個月，目前有10W個客戶（總部支援，有推廣位，且每月都有營銷活動），能夠進入到註冊漏斗的階段，有30%的人選擇這個選項，那觸達的結果就是每月100，000 x 30% = 30，000個客戶。2、：每個季度，每個使用該功能的客戶都能看到這個改變。那觸達的結果就是每季度60,000個客戶。3、：這個改變將會對50W個現有客戶造成一次性影響，但並沒有持續的影響。那觸達的結果就是每季度60，000個客戶。影響力（impact）關注專案中直接影響結果的資料，評估獨立個體的影響程度。對於團隊來說，就是“當有客戶接觸這個專案，它能夠提供多少轉化率？” 你的團隊也許會用其他的指標來取代，比如“提高使用率”或者“最大化使用者滿意度”。影響力很難精確的衡量，所以可以設定幾個加權選項：3代表“重大影響”，2代表“高度影響”，1代表“中度影響”，0.5代表“低度影響”，以及最小的0.25代表”輕微影響“。這些數字將作為權重值與各項評分相乘，加權得出評估結果。選擇影響力的權重值看起來似乎不太準確，另外的一種方法就是依靠個人的經驗直覺。舉例：1、：對所有看見它的客戶而言，它都能產生巨大的影響。則影響分數為3。2、：這對每個客戶而言將有比較少的影響。則影響分數為1。3、：產生的影響程度適中，則影響權重為2。信心（confidence）為了遏制對於鼓動性強但概念不明的想法的熱情，需要把評估的信心水平也考慮進來。如果你認為一個專案本可以有巨大的影響力，但是並沒有足夠的資料來支撐這樣的看法，這時，你對該專案的掌控度源於你的“自信度”。自信度是一個百分數，可以採用一個有多項選擇的量表來輔助避免決策失誤的可能性。100%是“信心程度高”，80%是“中等”，50%是“低”。任何時候，如果信心程度低於50%，那根本就是天方夜譚。坦白告訴自己，你的評估，到底有多少事實和資料支援？舉例：1、：我們有影響範圍的量化指標、影響力的使用者研究、努力程度的工程評估。那麼這個專案有100%的信心度分數。2、：我有資料支撐影響範圍和努力程度，但是對影響力不是很確定。這個專案有80%的信心度分數。3、：影響範圍和影響力可能比評估的還要低，努力程度可能比評估的還要高。這個專案有50%的信心度分數。努力/工時（effort）為了能夠快速發展並用最少的努力獲得影響力，從團隊的所有成員出發，去評估一個專案需要的時間總量，包括產品、設計和開發。努力程度的評估是以“人-月”（一個團隊成員一個月的工作）為單位對努力程度進行評估（我們團隊的日常評估是“人-天”，這裡我們採用他們的單位）。這裡會出現許多未知情況，所以為了讓評估留有餘地，在這裡我採用整數，或者用0.5來代表任何小於一個月的工作。不像其他的正向因素，更多的努力程度是一件壞事，因此我把它放在了分母，來除總的影響力。舉例：1、：該專案將需要1周的規劃，1-2周的設計，以及2-4周的工程時間。我給它的1“人-月”的努力程度分。2、：該專案將需要幾周時間來規劃，非常多的設計時間，一個工程師來做至少需要兩個月。我給它的2“人-月”的努力程度得分。3、：該專案只需要1周時間來規劃，沒有新的設計，而工程時間需要半月開發。我給它0.5”人-月“的努力程度得分。RICE分析計算公式一旦你完成了這些因素的預估，把它們合併成一個單一的得分，這樣你就能一目瞭然的比較不同專案的分數了，如下方公式：怎麼說呢，這個RICE法則分析，和後面的KANO模型分析在量化指標這塊，比較好明晰的。但是迴歸產品業務場景來說，比較難以一時間可以看出，先做哪個的力證。所以，關於RICE法則，產品可以多考慮一下，因為在我們看來，這個更多的是偏戰略層的。互動或者使用者體驗設計師，可以做到了解其分析原理即可。參考資料：https://www.intercom.com/blog/rice-simple-prioritization-for-product-managers/03、MoSCoW法則分析在PRINCE2中有一種叫MoSCoW的排序法。其名稱是4個級別的首字母縮寫。這4個級別分別是：Must：必須做的/必須有的；Shoud：應該做的/應該有的；Could：可以做的/可以有的；Wouldnot：現在不可做/現在沒有的。以之前易出行後臺服務系統為例，在定製化開發軟體產品前，專案組和產品經理通常會開展使用者調研。在調研中，不同使用者會從自身場景提出許多需求。當期專案的產品功能應該滿足哪些使用者的哪些需求就成了一個亟待回答的問題。MoSCoW排序法提供了一種思考方式，引導大家圍繞交付物展開思考：哪些需求是必須有的、對應的功能是必須做的，如果缺失則產品不可行、或者會嚴重影響使用者最終的使用目的；哪些需求對應的功能如果可能的話是應該有的，即便使用者可能沒有想到或意識到；哪些需求對應的功能是可以有的，即便本期專案沒有也無傷大雅，或者有其他替代方案；哪些是不能有的，是一些不合理的需求。使用MoSCoW排序法的優點是：1）體現了PRINCE2關注產品（最終交付物）的原則。在使用MoSCoW為需求排優先順序的時候，實際上是圍繞交付物思考，在排序的同時劃定了產品的功能範圍以及當期專案範圍，一舉多得。避免了盲目響應需求、輕重緩急拎不清，導致的範圍蔓延。2）明確了產品（交付物）的定位和演進方向。這一點在PRINCE2中沒有明確提到，但在工作中卻能實實在在感受到的。我們仍以易出行車主服務系統為例：使用者提出的需求實際上是從自己角度出發的，往往方向差異很大。對需求響應的排序，實際上影響了產品定位——到底要解決誰的什麼問題。系統上線後，使用者在使用中還會不斷提出新需求，一些需求如果不仔細斟酌就盲目響應，會導致系統被改成“四不像”，淪為功能模組的堆砌，背離系統設計之初的定位，這個時候，特別是內部孵化專案或者中小型團隊公司的專案，還容易受直接管理層的意見左右，雖然這種情況，難以避免，但是希望我們可以明確一個立場“這個公司不是你的，但是這個專案在由你負責的時候，就是屬於你的”所以，它的好壞也是你職業生涯中的重要一筆，希望可以必要的時候，力爭一下。。此時，運用MoSCoW方法，能協助專案組或產品經理理清思路，明確產品演進的方向。但同樣的，這個分析方法也有其一定的缺陷，比較明顯的就是：must和should兩個層級的需求輸出的時候，會產生一定的迷惑。因為這兩個層級，比較難以區分。嗯，所以，這個時候，kano模型分析法也許就該走上前臺了。不同的優先順序排序方法背後是不同的思想和視角，但是我們可以從自身需要出發，去結合合適的方法，而不是按本文的順序去一一試驗哈。
作為產品經理或者互動設計師，亦或者UI設計師，每天都會遇到各式各樣的需求。有的一句話，有的一個簡單的文件，有的只是一個線框圖，各種程度的資料，不一而足。特別是如果在一個ued部門內的時候，處理的需求更為繁雜。如果沒有一個比較好的處理排序優先順序的方法，很容易將需求層級搞混亂，從而導致整體研發進度受影響。當前在需求分析階段，比較受歡迎的主要是KANO模型分析法、BCGmatrix分析法、MoSCoW分析法，這三個又被稱為“需求分析三劍客”。還有一個最近也比較受歡迎的分析方法，就是RICE法則，又稱為大米法則。在一個團隊中，不會過於去依賴某一個分析法，綜合的運用和考慮才能夠更高效和快速的處理當前的需求池。這四個方法，難不成在我們日常處理工作需求的時候，一個一個的去嘗試？顯然，這是一種對照葫蘆畫瓢的行為。在比較長的工作專案中，我們多少有了一些運用的經驗和理解。希望接下來的講述，也可以對你解決多而複雜的需求分級有一定的幫助。一、簡略思路BCGmatrix分析法、RICE分析法，這兩個的針對物件層級都含有產品層，或者說使用者體驗要素中的戰略層考慮。而KANO模型分析法和MoSCoW分析法，偏向針對的是具體的產品功能層級，所以，在我們考慮需求優先順序初步判斷的過程中，可以優先使用BCGmatrix和RICE分析法進行判斷。這其中RICE分析法，也可以針對產品功能層級進行分析（後文會詳細闡述）。BCGmatrix從對使用者價值和對公司價值維度，也可以涉及到功能層級。但這並不妨礙優先使用此兩個方法。透過前兩個方法，就可以優先排除一部分偽需求存在，但是下沉到產品功能層級的時候，就不可以再接著運用RICE方法了。可以從BCGmatrix分析法角度，篩選出需求的維度（對使用者價值高還是對公司價值高）偏向。再結合接下來的兩個分析法，以團隊實際和公司業務實際，來判斷需求處理的策略和優先順序。二、具體運用思路01、波士頓矩陣分析法波士頓矩陣是由波士頓諮詢公司創始人布魯斯·亨德森於20世紀60年代首創，被視為企業戰略策劃時代的一個節點。作為分析企業成長（企業實力）與市場份額（市場引力）之間的關係的工具，它高度概括了企業戰略決策的一般方法，最早用於分析企業的市場增長率和市場份額（市場佔有率），又稱為“市場增長率-相對市場份額矩陣分析、產品系列結構管理法等。雖然波士頓矩陣方法最初並非應用於網際網路領域，但是後來經過變化升級，漸漸的開始在網際網路領域應用。特別是在產品需求優先順序的判斷上。1.1、產品層篩選依據當前公司或者團隊產品偏向，或者新的業務場景需求對於當前公司產品的增長率或者市場佔有率影響性，初步區分需求池中真偽需求存在。此時，有些內容需求恐怕需要進行完整的報告文件，比較偏向戰略層的決策，都是上層推動的。你的意見建議，必須拿出有力的證據，才可以讓管理層認識到你的建議是對的。例如在“易出行”（已隱去真實專案名稱）中，當時涉及到幾個新的業務場景接入的問題，涵蓋掃碼、維保、充電等，那麼到底優先接入哪個場景的業務？關於戰略層的決策，嗯，一般做為產品經理或者互動設計師，是沒有許可權參與的，除非你已經達到總監級別了。當時，比較看好的是維保和充電，主要是結合當時市場層熱度以及結合我們內部那個專案主營業務來決定的。但是，卻忽略了團隊的資源配置以及所處那個階段的更為重要的是搶佔垂直市場，而不是去和其他已有實力的人搶份額。當然，關於最終的建議和討論是我們UED部分大佬去和老闆說明的。但是關鍵點你是可以和老大去表明的。1.2、產品功能層篩選正如上圖所示，對使用者有價值的需求，一般屬於使用者需求；對公司有價值的需求，一般偏向產品需求。這個時候，就看一下，其需求的本質是偏向哪一種型別了。a、明星功能需求即對使用者有價值，同時對公司也有價值的產品功能需求。可以既滿足使用者的部分需求，又可以實現產品的部分目標需求。和在企業規劃中一樣，處於雙高級別，是優先順序最高的需求。例如，在我們某一個場景的門店列表中是否增加導航入口這一功能，一方面，使用者購買之後，可以快速方便的去到附近門店消費，一方面門店提升了營業額，對我們平臺的信任度增加，這個功能就可以劃歸明星類產品需求。b、問題功能需求問題類需求雖然表面對公司沒有直接的商業價值，但是從對使用者價值角度而言，可以提升使用者的滿意度和忠誠度，所，綜合來說，這類需求從本質上來說也是對公司有價值，只是不直接。之所以是問題需求，因為會隨著時間或者業務變化，會變成明星需求或者現金牛需求，甚至會變為瘋狗需求。最終走向，存在不確定性，有很大的風險。例如，掃碼挪車這個需求，這個是一個不高也不低的需求，但是對於使用者而言，很多時候，又是一個非常必要的存在。特別是一二三線城市，因為各種原因，總有需要聯絡車主挪車的情況。它短期內，對於公司產品來說，其實算是一個雞肋的功能，和主營業務沒有強相關。但是對使用者的確有價值的，所以，我們在前期推廣的時候，很多人還是比較樂意註冊，但是出現了一個小失誤，就是沒有處理好註冊使用的流程限制門檻，比較繁瑣。結果可想而知。c、現金牛需求這類需求比較明顯的自然就是對公司有明顯的價值，但是從使用者角度而言，多少會有一些負面影響。從理論上來說，應該儘量避免對使用者體驗造成不良的影響。但是，需要看公司產品的情況的。例如，當前各種遊戲非常火熱，當然，似乎遊戲一直都是比較熱的。但是在你玩遊戲的過程中，會常常引導你去看直播，這種體驗，你應該不陌生。那麼像是某易或TX為啥這麼做呢？之前公眾號也有文章說明，這種就屬於現金牛類需求，公司的目的就是希望引流賺錢以盈利。d、瘋狗類需求最後這種需求，就是和第一類需求相反的“雙低”需求，也就是我們常說的偽需求。需要你判斷出，並儘量去排除掉。其實從以上幾個需求型別的分類闡述，就可以看出對於問題類需求和現金牛需求，考慮的時候，需要多考慮一步。在產品成長初期，例如我們之前的“易出行”，獲取使用者增長和提升使用者的留存率是第一要考慮的，那個時候，我們並沒有去考慮如何去盈利。所以，問題類需求優先順序高於現金牛需求。但是如果產品處於穩定成熟期，例如，現在的很多超級APP，公司的目標自然都是以提升盈利水平為第一要務，像是“拼多多、瑞幸”等。除此之外，我們在考慮需求的時候，涉及的因素是非常多的。上述的波士頓矩陣也只是提供我們一個分析的思路和處理的方向。自然還有其他的方法，可以幫我們進一步的去驗證其合理性，例如：RICE法則。2、RICE分析法一個好的優先順序排序框架可以幫助你用清晰的思考去理清專案裡面的每個因素，並以嚴謹、一致的方式將這些因素結合起來。但是你可能很難找到一個能讓你以一致的方法去對比不同思路的系統。所以，我們需求掌握不止一種分析思考的方法，才可以有效的管理我們的工作和生活。RICE是用來評估各專案需求的四大因素的首字母縮寫：觸達（Reach），影響力（Impact），信心度（Confidence）和努力（Effort）。觸達（reach）為了避免出現主觀需求的偏差，我們應該評估每個專案在既定時間內會影響多少人。對於我的團隊來說，就是“在一個季度內，這一個專案將會影響到多少客戶？”觸達範圍是衡量每個時間段內產生的使用者數或活躍數。也許會是“每季度客戶數”或者“每月交易額”。儘可能使用產品指標中真實的測試資料而非虛構的資料。最終，我們選取的是DAU和MAU。舉例：1、：每個月，目前有10W個客戶（總部支援，有推廣位，且每月都有營銷活動），能夠進入到註冊漏斗的階段，有30%的人選擇這個選項，那觸達的結果就是每月100，000 x 30% = 30，000個客戶。2、：每個季度，每個使用該功能的客戶都能看到這個改變。那觸達的結果就是每季度60,000個客戶。3、：這個改變將會對50W個現有客戶造成一次性影響，但並沒有持續的影響。那觸達的結果就是每季度60，000個客戶。影響力（impact）關注專案中直接影響結果的資料，評估獨立個體的影響程度。對於團隊來說，就是“當有客戶接觸這個專案，它能夠提供多少轉化率？” 你的團隊也許會用其他的指標來取代，比如“提高使用率”或者“最大化使用者滿意度”。影響力很難精確的衡量，所以可以設定幾個加權選項：3代表“重大影響”，2代表“高度影響”，1代表“中度影響”，0.5代表“低度影響”，以及最小的0.25代表”輕微影響“。這些數字將作為權重值與各項評分相乘，加權得出評估結果。選擇影響力的權重值看起來似乎不太準確，另外的一種方法就是依靠個人的經驗直覺。舉例：1、：對所有看見它的客戶而言，它都能產生巨大的影響。則影響分數為3。2、：這對每個客戶而言將有比較少的影響。則影響分數為1。3、：產生的影響程度適中，則影響權重為2。信心（confidence）為了遏制對於鼓動性強但概念不明的想法的熱情，需要把評估的信心水平也考慮進來。如果你認為一個專案本可以有巨大的影響力，但是並沒有足夠的資料來支撐這樣的看法，這時，你對該專案的掌控度源於你的“自信度”。自信度是一個百分數，可以採用一個有多項選擇的量表來輔助避免決策失誤的可能性。100%是“信心程度高”，80%是“中等”，50%是“低”。任何時候，如果信心程度低於50%，那根本就是天方夜譚。坦白告訴自己，你的評估，到底有多少事實和資料支援？舉例：1、：我們有影響範圍的量化指標、影響力的使用者研究、努力程度的工程評估。那麼這個專案有100%的信心度分數。2、：我有資料支撐影響範圍和努力程度，但是對影響力不是很確定。這個專案有80%的信心度分數。3、：影響範圍和影響力可能比評估的還要低，努力程度可能比評估的還要高。這個專案有50%的信心度分數。努力/工時（effort）為了能夠快速發展並用最少的努力獲得影響力，從團隊的所有成員出發，去評估一個專案需要的時間總量，包括產品、設計和開發。努力程度的評估是以“人-月”（一個團隊成員一個月的工作）為單位對努力程度進行評估（我們團隊的日常評估是“人-天”，這裡我們採用他們的單位）。這裡會出現許多未知情況，所以為了讓評估留有餘地，在這裡我採用整數，或者用0.5來代表任何小於一個月的工作。不像其他的正向因素，更多的努力程度是一件壞事，因此我把它放在了分母，來除總的影響力。舉例：1、：該專案將需要1周的規劃，1-2周的設計，以及2-4周的工程時間。我給它的1“人-月”的努力程度分。2、：該專案將需要幾周時間來規劃，非常多的設計時間，一個工程師來做至少需要兩個月。我給它的2“人-月”的努力程度得分。3、：該專案只需要1周時間來規劃，沒有新的設計，而工程時間需要半月開發。我給它0.5”人-月“的努力程度得分。RICE分析計算公式一旦你完成了這些因素的預估，把它們合併成一個單一的得分，這樣你就能一目瞭然的比較不同專案的分數了，如下方公式：怎麼說呢，這個RICE法則分析，和後面的KANO模型分析在量化指標這塊，比較好明晰的。但是迴歸產品業務場景來說，比較難以一時間可以看出，先做哪個的力證。所以，關於RICE法則，產品可以多考慮一下，因為在我們看來，這個更多的是偏戰略層的。互動或者使用者體驗設計師，可以做到了解其分析原理即可。參考資料：https://www.intercom.com/blog/rice-simple-prioritization-for-product-managers/03、MoSCoW法則分析在PRINCE2中有一種叫MoSCoW的排序法。其名稱是4個級別的首字母縮寫。這4個級別分別是：Must：必須做的/必須有的；Shoud：應該做的/應該有的；Could：可以做的/可以有的；Wouldnot：現在不可做/現在沒有的。以之前易出行後臺服務系統為例，在定製化開發軟體產品前，專案組和產品經理通常會開展使用者調研。在調研中，不同使用者會從自身場景提出許多需求。當期專案的產品功能應該滿足哪些使用者的哪些需求就成了一個亟待回答的問題。MoSCoW排序法提供了一種思考方式，引導大家圍繞交付物展開思考：哪些需求是必須有的、對應的功能是必須做的，如果缺失則產品不可行、或者會嚴重影響使用者最終的使用目的；哪些需求對應的功能如果可能的話是應該有的，即便使用者可能沒有想到或意識到；哪些需求對應的功能是可以有的，即便本期專案沒有也無傷大雅，或者有其他替代方案；哪些是不能有的，是一些不合理的需求。使用MoSCoW排序法的優點是：1）體現了PRINCE2關注產品（最終交付物）的原則。在使用MoSCoW為需求排優先順序的時候，實際上是圍繞交付物思考，在排序的同時劃定了產品的功能範圍以及當期專案範圍，一舉多得。避免了盲目響應需求、輕重緩急拎不清，導致的範圍蔓延。2）明確了產品（交付物）的定位和演進方向。這一點在PRINCE2中沒有明確提到，但在工作中卻能實實在在感受到的。我們仍以易出行車主服務系統為例：使用者提出的需求實際上是從自己角度出發的，往往方向差異很大。對需求響應的排序，實際上影響了產品定位——到底要解決誰的什麼問題。系統上線後，使用者在使用中還會不斷提出新需求，一些需求如果不仔細斟酌就盲目響應，會導致系統被改成“四不像”，淪為功能模組的堆砌，背離系統設計之初的定位，這個時候，特別是內部孵化專案或者中小型團隊公司的專案，還容易受直接管理層的意見左右，雖然這種情況，難以避免，但是希望我們可以明確一個立場“這個公司不是你的，但是這個專案在由你負責的時候，就是屬於你的”所以，它的好壞也是你職業生涯中的重要一筆，希望可以必要的時候，力爭一下。。此時，運用MoSCoW方法，能協助專案組或產品經理理清思路，明確產品演進的方向。但同樣的，這個分析方法也有其一定的缺陷，比較明顯的就是：must和should兩個層級的需求輸出的時候，會產生一定的迷惑。因為這兩個層級，比較難以區分。嗯，所以，這個時候，kano模型分析法也許就該走上前臺了。不同的優先順序排序方法背後是不同的思想和視角，但是我們可以從自身需要出發，去結合合適的方法，而不是按本文的順序去一一試驗哈。
產品設計師做需求分析，掌握“3+1”個分析法，就夠了！（上）
資訊抽取 常識
自然語言理解 資訊抽取 常識