編輯導語:產品有表面的規則,即當我們注冊或者使用一款產品時會明確讓我們知道的有形規則;同時也存在無形規則,需要我們去探尋其背后的道理。本文作者基礎自己的實際體驗,為我們分享了一個案例。
這個選題來自于十二本人的一次打車經歷,故事背景是這樣的:許多次晚上出差從首都機場打車回家,都發現很難被接單,甚至還一度懷疑自己是不是因為哪次遲到被某個平臺拉黑了之類的,直到某次一個首汽的小哥告訴我背后的真相:
從首都機場到望京難打車的原因在于離機場的距離剛好卡在了分界線上,比較近但沒那么近,比這個距離再近一點就可以送完本單再回來機場排隊接一個單;比較遠但沒那么遠,司機師傅辛辛苦苦排隊一晚上進場就為了接一個大單,比起在機場停車場幾小時的停車費和等待時間來說,望京的出行單性價比極低。
所以,說白了,我以及和我一樣晚上打車從機場回到望京附近的人們都是被規則“誤傷”的用戶,也不算“誤傷”,有可能是被“戰略性放棄”。
一、為什么機場要設置這樣的規則?
規則的初心是為了提高效率,避免無序帶來的更多混亂和低效問題。機場附近臨近晚上公共交通也沒了,無論遠近,大部分用戶都不得不選擇打車,因此機場附近接到大單的概率比較高。不少出租車深諳此道,因此會固定時間段在機場或者高鐵站附近“趴活”(北方方言,等單的意思)。
但機場的容納量有限,如果不設置規則,所有的司機在相應時間段都往機場附近趕的話,不僅機場的停車場會陷入癱瘓,想進的進不來,想出的出不去,機場附近的幾天路也會被堵的水泄不通,誰也回不去,越來越多的人和車堵在機場,機場的正常運轉就會出現問題。
因此,需要設置規則,每輛網約車一個晚上只允許在機場排隊接單一次。
🤯 但新規則又會面臨新的問題。
接單一次對于機場管理變得方便了,但一次接單的收益可能天差地別,大單可能抵得上市內跑普通小額單,稍近一點可能差不多旱澇保收,和在市內跑差不多,但小單卻有可能還得賠錢。
原因是在機場等候的時間成本以及交的高額停車費,如果跑一單小單的話收入幾十塊錢,減去油錢剩下的利潤可能還覆蓋不了支出。那么來機場等單面臨著可能賠錢的風險,為了養家糊口,大多數人可能會選擇規避風險,那么機場就從一個車來車往水泄不通的極端到了另一個無車可坐的極端。
那么,兩個極端中間如何找到平衡?
辦法就是幫助出租車司機規避風險,無論大中小單,至少能夠做到不賠錢,因此需要設定一個邊界值,高于邊界值的距離的單只允許接單一次,低于邊界值由于面臨少賺錢甚至賠本的風險,因此要在規則上做相應的補償。
機場不可能直接通過補貼的形式來照顧這部分司機的利益,最低成本補償的方式就是允許他們返回再接一單。因此來機場等單又成為了一個旱澇保收的選擇。
————除非你剛好接到望京的用戶。
所以,機場設置這樣的規則無可厚非,至少保證了機場能正常運行,晚上的大多數用戶能打到車回家,大部分司機能接到單并且拿到不錯的收入。
規則是為了公平,大部分人的公平犧牲了規則邊界的公平,犧牲了接到望京單的出租車司機的收益和打車回望京的用戶體驗。
二、被一刀切的規則砍掉的用戶體驗
在機場打車的case中,核心沖突在于有限的規則無法面對無限可能性,因此終歸會有不適用的場景,會有被卡在邊界的人群。產品經理在創建屬于自己的產品規則的時候,不得不面臨這樣的難題。
雖然完美的規則可能不存在,但盡可能考慮更多邊界場景,設計容錯性更高的規則,減少被規則誤傷的場景和用戶量級應該是我們持續要追求的事情。
雖然并不否認規則的合理性,但是還有沒有別的辦法,可以解決一下住在望京附近的用戶從機場回家的打車難問題呢?
1. 調整一下回機場接單的邊界閾值
解決不了問題,那我們就解決“問題”本身,這也是一種思路。把這個邊界閾值調得更遠,讓打車回望京的單不再卡在邊界上,司機接完這一單還能再回到機場接一單。
從問題本身來看,打車回望京難的問題的確被解決了。
但從全局來看,問題只是從望京被轉移到另一個地區,并沒有被真正的解決。不過,想要完全解決這個問題的出發點可能本身就是有問題的,如果不奔著解決問題,而是降低問題的影響范圍,這個或許是一個不錯的思路。
假設從機場打車回家的用戶目的地和機場的距離呈現正態分布,而望京剛好是正態分布的最高點(純屬個人YY簡化的模型),那么邊界線往前或者往后稍稍偏移都能讓更少的乘客和司機被影響。
正態分布示意圖(來源網絡)
當然,邊界往前或者往后帶來一系列的關聯問題也應該被考慮到。
比如,如果回機場接第二單設置的距離閾值比望京更遠了,意味著司機來機場接單的最低收入有所提高(假設司機接兩單的收入比一單來望京的收入低的可能性極小),這可能意味著更多的司機選擇來機場接單,機場的負載量,去機場公路的通行能力和機場乘客對用車的需求量可能會小范圍失衡,或許需要通過提高機場的停車費來讓系統重新恢復平衡。
如果回機場接第二單設置的距離閾值比望京更近了,反之亦然,愿意來機場接單的司機可能會減少。
2. 預留一個buffer來對沖影響
這個思路來源于紅綠燈。本身汽車的通行只有兩種狀態,走和停,對應也應該只有兩種燈的狀態,綠燈和紅燈。那么為什么會出現黃燈呢?
我的理解是,黃燈相當于紅綠燈之間的一個buffer(明明是三個燈的電影,黃燈卻不能擁有姓名hhh)。雖然汽車的通行只有兩種狀態,但是從走到停并不是一個瞬時的事情,而是需要一定的時間,根據車速不同,停下來需要的時間也不一樣,而且每個人對距離的預判和車速的預判存在個體差異。
有些人看見綠燈只剩下兩秒了會停車,而有些人看見綠燈只剩下兩秒了會加速。設置紅綠燈的初衷是為了減少事故的發生,但如果一刀切的規則對應沒法一刀切的用戶行為,可能會導致更多事故的發生。
比如加速沖過去的用戶臨近紅綠燈發現沖不過去然后急剎車,后面的車來不及反應而追尾,再或者雖然沖過去了,但是因為路口比較寬,還沒完全通過的情況下,水平方向其他車輛開始通行導致事故等等。
所以,黃燈的出現預留了一個buffer,對于大多數人來說,綠燈結束意味著不可通行就會剎車,黃燈給了一個剎車的緩沖時間,在本通行方向即將紅燈之際,清空路口的緩存車輛,好讓水平方向的綠燈開始時能夠暢想整條道路的通行權。
借鑒到機場case的話,怎么預留buffer呢?
例如:假設本來的分界線是15km,小于15km的話可以回機場接第二單,大于15km的話只能接一單。
是否可以將分界線模糊為15-19km呢?小于15km可以回機場接第二單,大于19km的話只能接一單。15-19km之間雖然只能接一單,但是可以獲得一張七折停車券,相當于變相補貼司機。
這樣即使接到望京附近的用戶,收入也不會太差,而且模糊了15km的精準分割線,降低了司機對望京附近單的敏感程度,一定程度上也能提高用戶的體驗。
這種預留buffer的模式也可以借鑒到其他場景,會顯得更加人性化,而不是死板。比如公司規定9:00算遲到,但是實際上可以9:10開始考勤,晚于9:10才算遲到,這個10min的buffer可以不寫在規則里,否則大家都會用9:10做ddl,9:00的規則就形同虛設了。
大多數人會遵守規則早到公司,少部分人踩點到或者沒擠上電梯導致晚到幾分鐘,這10min的buffer相當于預留了上樓的時間。人性化的好處是減少了一刀切帶來的“遲到1min被罰款的員工對公司死板規則的憤懣之情”,同時又能起到規則的有效制約作用。
可能這道題還有其他解法,待評論區小伙伴提供更多思路~
三、關于設計規則的checklist
根據平常對于規則的觀察,梳理了以下的checklist,即在設定規則前后需要思考以下問題:
- 這個規則設定的目的是什么,是制定社群運營的規則或者公約,用于維護社群氛圍?還是為了讓大多數人參與進來,且保證相對公平,設計游戲規則?
- 規則是對所有人生效嗎?還是對部分人生效?
- 如果規則對部分人生效的話,看到規則的另一部分人是完全不受影響還是會有利益受損or心理不平衡(舉個例子,公司規定女性用戶三八節放假一天),這種影響是否可能沖擊系統的穩定性
- 哪類人可能從規則中獲益,這類人獲益是否損傷其他人的利益(即游戲是否為零和博弈);
- 如果是游戲規則的話,是否存在輸家和贏家,輸家和贏家是否有獎勵或者懲罰;
- 為了保證規則的有效運行,是選擇懲罰違背規則的人,還是選擇獎勵遵守規則的人?
- ……
最后一點想展開講講,TO 懲罰違背規則的人,OR TO選擇獎勵遵守規則的人,That is a question。舉個例子,作為一個社群運營,自然是不允許發廣告的行為的,因為廣告內容會干擾到其他用戶的正常交談,降低群內內容質量。
所以大多數社群選擇在群公告注明:“本群禁止發小廣告,一旦發廣告則踢出群聊”,即違背規則的人被懲罰。由于群主和群成員大多數不存在雇傭關系,所以懲罰不可能特別大。
但是對于大多數陌生人群來說,踢出群聊雖然對于發小廣告的人影響極小,只要他努力混進群里在管理員沒反應過來之前發幾條廣告,但凡有人對廣告有興趣的話就血賺,畢竟即使人被踢出去了,鏈接永遠留在了各位群成員的聊天記錄里。所以這樣的規則導致小廣告行為屢禁不止。
但上次進了一個群,群規是這樣寫的:本群不允許廣告,如果發廣告則需要補償群內成員,發一個不少于群內人數X0.5元的紅包。這樣的規則意味著懲罰違規行為的同時,獎勵了遵守規則的用戶。當然,也有可能這人不愿意發紅包,最終還是只能退出群聊。
但是這個規則優化的好處在于:
- 一方面,留了buffer,不是不能發廣告,但是發廣告會影響到群內其他人的利益,因此需要有所補償。如果連懲罰都不愿意遵守也還可以直接踢出群聊處理。
- 另一方面,群內氛圍的維護不再是管理員一個人的責任,大家的利益也通過這一條規則被關聯起來,一旦有人發廣告,每一位成員都有責任監督(和搶紅包),因此,這類行為能更快被發現,影響范圍也降到最低。
#專欄作家#
李濤,微信公眾號:檸檬two,人人都是產品經理專欄作家。新人產品經理,專注于產品求職分享和社交/社區賽道產品思考。
本文原創發布于人人都是產品經理,未經許可,禁止轉載。
題圖來自 Unsplash,基于 CC0 協議