需求性質：什麼是伴生性需求

標籤：

作為 產品經理，我們工作的重點之一就是收集整理需求，那在這些需求中，哪些是剛需，哪些優勢伴生性需求呢？本文和大家分享的就是伴生性需求相關內容， 伴生性需求在整個產品生命過程中佔據極大的比重，如果說創造性需求是可以燎原的星星之火，伴生性需求便是為火焰燃燒提供的若干枯草。 什麼是伴生性需求 在我們做產品時，存在許多沒有太大價值，但又必須具備的功能，這部分需求我統一定義為“伴生性需求”，屬於某些主幹需求的衍生枝幹。·  當我們決定開發帳號系統後，除了註冊和登入是必須的功能，與之相對應的還會包含修改密碼，找回密碼這些非常規功能，此時，修改密碼，找回密碼就屬於典型的伴生需求，·  我們向使用者提供了上傳照片的功能，對應的就需要提供刪除照片，儘管用的人非常少，使用頻率也非常低。 伴生性需求必須存在，但卻不是非常的緊急 ，實際上，許多團隊，往往會將伴生性需求挑選出來，必要時將這部分需求捨棄，置入下個版本的反覆項目計劃。正如他的定義一樣， 伴生性需求必須存在，但缺少這部分需求，並不會造成多數使用者的不滿 ，損失非常有限。產品經理加班的情況僅次於研發人員，實際上我們是一群和時間賽跑的人，與團隊中的其他成員一樣，我們也希望這個版本能夠儘快的上線，投入到市場使用，然後獲得非凡的成就。而即使再多的資源，再多的人力，也沒有辦法同時開啟所有需求，這是伴生性需求的一個特點，他總是承擔著我們減負的第一個重擔。 伴生性需求的捨得特色成熟的產品經理懂得砍需求，懂得對需求做減法，這個能力看上去很飄渺也很個性，可能大家聽了許多次也只能幻想，手握數千需求，談笑間，便砍去· 五百，對於這中間如何少的，為什麼有些需求能砍，為什麼有些需求不能砍，想來會非常困惑。需求有主次，我們做產品的過程中，在每個版本裡都會體現出需求的主次，需求的順序，MVP  理念，需求優先順序乃至於  kano  模型的都可以體現出這個觀點。我們會圍繞核心需求投入許多資源，這些核心需求也就是我們的主要需求，同樣的，我們會捨棄次要的需求，必要時，我們會捨棄一些看上去非常核心，但實際上他是僅次於主要需求的一個最大的次要需求。現在告訴大家一個方法，能夠極大的增加大家砍需求的能力。現在我們有5 個需求，但我們的資源以及我們的時間只允許做 3 個需求，你會捨棄那些需求呢？1.  為使用者上傳的照片增加貼紙功能2.  做一個開放式的群聊，全平台使用者可參與群聊進行互動3.  開放上傳原圖，使用者可選擇上傳原始大小的照片4.  允許單次上傳多張照片，即批量上傳5.  開發斷點續傳的功能，使用者上傳照片失敗，可點擊繼續上傳，已上傳的照片不需要重新上傳這個題目其實很難回答，  也缺少正確答案，在不同的環境下，我們會有不一樣的選擇，需求的取捨與很多因素有關，並不是單一因素造成的，但是，將問題稍加修改以後，我想你現在會進行取捨了。現在我們有5 個需求，但我們的資源以及我們的時間只允許做 3 個需求，你會捨棄那些需求呢？1.  為使用者上傳的照片增加貼紙功能  [伴生需求2.  做一個開放式的群聊，全平台使用者可參與群聊進行互動3.  開放上傳原圖，使用者可選擇上傳原始大小的照片4.  允許單次上傳多張照片，即批量上傳  [伴生需求5.  開發斷點續傳的功能，使用者上傳照片失敗，可點擊繼續上傳，已上傳的照片不需要重新上傳是不是很容易識別出來，基本所有的伴生需求， 在優先順序裡都是可以被捨棄的，但並不是完全捨棄，只是在下一個階段或者未來的某個時機，再來做，也許到那時，該需求就已經不再是伴生性需求，而是創造性需求了 。只要我們能識別出需求性質，是被出伴生性需求，我們就能自己嘗試去砍功能。 伴生性需求的特徵作為減負的一個絕佳選擇，是伴生需求的應用特徵，  而我們能夠如此應用還要歸功於伴生性需求本身的特色，即 伴生需求無法單獨存在，對其他功能具備極強的依賴和從屬性質。修改密碼的功能對於我們來講太常見了，這個功能便是典型的伴生性需求，若我們的帳號系統，僅支援第三方帳號登入以及簡訊驗證碼登入時，該功能便失去了存在的價值。離開了自訂密碼這樣一個欄位，修改密碼的功能在邏輯上就已經不成立了，換言之， 修改密碼便是設定密碼的伴生性需求同樣是設定密碼的伴生性需求還包括了” 找回密碼 “ 這個功能。如果設定的功能都不存在，那麼圍繞密碼展開的修改密碼以及找回密碼就不再具備任何意義了。 我們所認識的伴生性需求，最典型的特徵便是依附於其他功能而存在，本身是無法單獨存在於產品內的。作為一款圖片社交產品，允許使用者刪除照片以及對照片設定隱藏加密功能，也是一組鮮明的伴生性需求。不論是對照片做任何形式的處理，或者業務，都需要建立在照片成功上傳的基礎之上，圍繞照片展開的一系列功能均屬於從屬且依賴於被上傳的照片而存在。這些功能的操作主體便是被上傳的照片。可如果這個主體不存在，這些功能還會發生  效應嗎？  若使用者上傳照片的功能被阻塞，那麼這個照片的本體就不複存在，也就無法再圍繞該主體展開功能型操作了。現在，許多產品做的很重，而且這個問題的兩處重災區一個是從0 到 1 的過程中，堆積了大量需求，1.0 版本研發了一年多的時間上線，在這些問題的背後，便是我們將若干的伴生性需求當成了真正的使用者需求。現在，你是否學會如何捨棄某些需求，以及如何辨識出伴生性需求呢？ 伴生性需求”做功能“伴生性需求本身是作為需求存在，可在做的時候，我們卻不能將他當做需求來理解，這部分需求更多的是以功能補充的形式存在，極少使用者反饋裡會提及到這些。因此，這也是最適合新人入門的一個領域，藉助對伴生性需求的駕馭，會協助我積累更多的功能庫，逐步的掌握功能的使用方法以及開發過程。我們關注伴生性需求，不需要考慮他是否符合人性，是否存在需求，是否存在影響力，只需要去思考如何做會更好一點，這會逐漸的增加我對功能的駕馭能力。許多新人會容易犯的一個錯誤，不太重視文案，過多的將精力花費到了功能設計以及看各種資料上， 這其實是捨本逐末的做法。《精益至上》  這本書裡提到了這樣一個案例：某電商網站的使用者新增很難提升，在一次最佳化嘗試下，資料呈現了客觀的增長，這個小小的最佳化，只是將註冊按鈕的位置做了一些調整，可以說沒有進行任何功能的新增，只是調整了局部的布局。與之同樣的，我們也能從文案中看到差異，我們以一句簡單的注釋來舉例：1.  參與活動，有機會贏蘋果 72.  贏蘋果 7 ，參與活動，你也可以兩句文案很難說誰好誰壞，但我們能清晰的從這兩句話感受到不同的資訊，第一句，我們認為參與活動是主體，贏得東西是輔助的，第二句，則變成了贏蘋果7 是主要的，而活動只是輔助的資訊。在做伴生性需求時，當盡善盡美，此時我不需要為整個產品的商業價值負責，不需要為使用者需求負責，但我們需要對功能負責，讓功能更容易被大家接受，不顯得粗糙，難用。 僅僅是將伴生性需求做出來，是無意義的，而且會極大的損害自己的成長，這個階段的我們更多的與功能貼近，嘗試更好的去表達功能，而布局和文案的使用反而是這個階段對我們的兩大挑戰。來源：人人都是產品經理

需求性質：什麼是伴生性需求