我們已經知道伴隨需求的第壹個特點:對某個功能有很強的依賴性，不能單獨存在，而是作為某個功能模塊的壹部分存在。
在這個練習案例中，購物車是主要的功能模塊，其目的是將人們想要購買的物品放在壹起，最終實現支付場景的整合。
購物車的原型來源於人們在現實超市中的購物習慣。我們經常在商場買很多商品，每選壹件商品都要付錢，特別麻煩。機緣巧合，壹個商人在1937發明了購物車，然後在1994，這個購物車被做成壹個互聯網產品的logo，就是“亞馬遜”。
事實上，購物車是作為購物籃的升級產品而設計的，其目的是通過增加購物籃的裝載空間來減輕人們的身體負擔，而康恩親自增加了人們購買的商品數量。這和我們在網上的購物車是有本質區別的。
互聯網的裝載空間幾乎是無限的，幾乎沒有身體負擔。我們現在使用的購物車在第壹階段被設計成“購物籃”。可惜找不到購物籃的設計背景，不妨大膽想象壹下。
我們在案例中提到了七個選項，分別是商品編輯、商品失效管理、批量支付、促銷指導或提示、賬單領取、賬單拆解、個性化推薦。
我壹定沒有告訴過妳，每個函數都有受眾，也就是函數操作的目標是什麽。如果從功能的受眾角度來分析，很容易把這七個功能分為兩類，壹類是操作購物車內的商品，壹類是操作購物車外的商品。
雖然購物車設計的初衷是讓人們多購物，但其切入方式與廣告不同。購物車增加產品銷量的核心價值是減少人們的購物壓力，而不是推薦購物。
這意味著購物車本身的受眾是針對已經確認購買的商品，即購物車中的商品，而不是推薦購物。
此時，我們可以排除推廣指導、計費和個性化推薦。
現在作為購物車的伴隨需求，我們可以選擇的選項有商品編輯、商品失效管理、批量支付、賬單拆分。
剩下的四個功能，有很多東西我們可以分析。這裏以批量支付為例，重點分析壹下。這個函數很特殊。
在這種情況下，購物車指的是淘寶的購物車，所以我們需要正確識別這種批量支付的含義。按照淘寶app的實現方式，這裏的批量支付是指批量選擇進行支付。
他不是說我們可以壹次性支付購物車裏的所有商品，而是可以選擇壹次性支付購物車裏的多個商品。
在壹些電商產品中，購物車的批量支付不是可選的。我們會選好商品並最終將其從購物車中移除，最終實現批量支付。
顯然，在淘寶的眼裏，購物車除了人們想買的商品之外，還可以作為“收藏欄”。
我們在分析伴隨需求的時候，可以判斷在取消功能的情況下，除了功能的受眾是固定的以外，原來的功能模塊是否還能正常使用。
我們把淘寶批量支付的“收款欄”概念去掉，只保留整個購物車的支付操作，所以購物車還是可以用的。
其實不僅僅是批量支付，商品編輯、故障管理、賬單拆分等功能也是缺失的，會影響功能的使用，但不會導致功能無法使用的這類。
事實上，伴隨而來的需求往往是承擔了大部分投訴的需求。看似每壹個需求都能提升用戶體驗，卻沒有辦法給產品帶來直接價值。當購物車的需求與產品本身的需求發生沖突時，我們會優先考慮更多的體現產品，讓用戶有更大的購買產品的欲望，而不是完善購物車的功能。
這是我在上壹篇文章中提到的伴隨需求的另壹個特點，可以舍棄。
我們可以想象壹下，如果淘寶購物車裏的商品無法編輯，沒有無效的商品管理，無法打開訂單，所有這些功能都需要我們反復取消商品，選擇商品來完成，我們還會用淘寶嗎？
其實我們還是會用淘寶，原因很簡單，我們不是去購物使用購物車的商品管理功能，而是使用購物車的商品管理功能進行購物。
在這個練習案例中，正確答案是1236，也就是說，在淘寶的購物車模塊中，商品編輯、無效商品管理、批量支付、賬單拆分都屬於購物車的伴隨需求。
“@”曾慧娟:
127是伴隨需求。
評論:
關於第7點，我們不妨考慮壹下。沒有購物車，我們也可以對商品進行個性化推薦。其實各大電商產品在很多地方都使用了個性化推薦，最常見的使用方式是首頁和搜索。因此，第七個選項，個性化推薦，只是購物車的壹個入口，而不是與購物車相關聯的需求。(也可能是響應式需求，營銷同事提出的想植入購物車的模塊。)
“@”開明的生活:
4567是伴隨需求。購物車的主要功能是實現商品的存儲和支付，收藏、拆卸、推薦、暗示廣告都是在購物車必須編輯和取消、實現支付後增加交易量。
評論:
在這裏，功能必然性和伴隨性的概念被混淆了。陪伴是指壹種需求的性質，而不是判斷需求是否必要。事實上，伴隨需求可能是必要的或補充的。
在這種情況下，盡管4、5和7不是必需的功能，但它們也不需要附加到購物車上。而1236，雖然是必備功能，但其實這部分功能的缺失並不會讓整個購物系統崩潰。最大的可能是會降低人們購物的樂趣，讓我們覺得累贅。
“@”春天:
購物車的核心是用來批量添加商品和結算的。我理解商品的編輯就是商品的增刪，所以2到7是半條命。
評論
妳提到了商品編輯，但在妳的回答中，妳給出了無效商品管理和個性化推薦。其實商品編輯和無效管理都屬於購物車的伴隨需求，而個性化推薦不是。
“@ Plateau”24567是伴隨需求。購物車的核心功能是編輯商品和支付。其他如無效商品的管理、引導、收集和拆解都是伴隨需求。
評論
關聯需求除了不是核心需求，還對核心功能有明顯的依賴性，沒有核心就不能單獨存在。如果從這個角度考慮，457選項就排除了。
同時，核心需求和必須存在的需求之間存在差異。必須存在的需求不是先做，而是核心需求先做。同時，必須存在的需求也可能是伴隨的需求。我們可以認為這部分需求在某些場景下是非常容易被推遲和取消的，比如商品編輯。
在妳們的回答中，有壹個明顯的傾向。我們很容易認為商品編輯和批量支付是購物車的必要需求。事實上，並非如此。
對於商品編輯來說，我們在淘寶的使用頻率大概不到1%。其實我們不需要編輯所有商品的數量，這只是少數商品帶來的需求。
關於批量支付，實際情況是我們混淆了購物車的使用和收款欄的使用，給我們的需求分析帶來了混亂。我想我們的購物車裏壹定有壹些商品，但是我們忽略了它們。
同時，並不是所有的電商產品都需要購物車，就像購物車的存在使命是方便人們壹次性購買多件商品壹樣，更適合產品豐富的超市和商場。我們必須更客觀的區分用戶壹次購買多件商品的需求是高還是低。
現在，如果妳正在做電商產品，或者準備從事電商產品，相信妳對購物車及其功能有了更深的了解。不要因為某個功能必須存在，就將其定義為更高層次的需求。許多必須存在的需求不壹定是緊急的，許多伴隨的附屬需求實際上必須存在。
我想現在大家對伴隨需求有了更深刻的理解。
在下壹篇文章中，我會繼續寫伴隨的需求。如果妳有合適的實踐案例，請給我留言。
感謝您的閱讀。