2017-08-25 4031
公司的項目是一個O2O的電商平臺,我負責的項目是用戶與商家之間的橋梁—-配送系統。這個系統的主要用戶角色是配送員和運營調度人員,so產品也分為配送員app及后端的運營調度系統。話不多說,先上菜,哦不,先上坑!
第一個版本考慮到app為內部員工使用,以及盡快上線的原則,沒有設計強制更新策略。當迭代了兩個小版本后發現,各個版本都有人在使用,甚至有較大功能缺陷的版本也有配送員在使用。發現這個問題后,我們緊急上了強制更新功能,為了這個有強制更新功能的版本及時覆蓋所有配送員,整個團隊也花了不少時間和精力。
填完這個坑,總算是明白了為什么前輩們總是語重心長的說“任何一款app一定要考慮好更新策略”。雖然做產品經理,要尊從二八原則,但并不是完全不考慮小部分的情況,因為沒有哪個公司的執行力能做到100%。強制更新的用戶體驗雖然差,但是對一個內部員工用的產品來說,效率比體驗重要的多。即使是用戶app,也因該預留強制更新功能,出于用戶體驗考慮你可能永遠都不會用,但是以防萬一總是好的。
當然咯,很多朋友會有疑問,iOS強制更新,怎么通過App Store審核?哈哈,方法總比困難多嘛~出于職業精神,我就不在公共場合討論BUG啦(嚴肅臉)!有興趣可以私聊探討哈。
配送員app搶單列表中,配送員可以點擊搶單按鈕進行搶單。但是,會有多種情況導致搶單失敗,比如:
對于這樣的情況,我在第一個版本分別做了2種不同的提示:
本以為給出了明確的提示,萬事OK了。但是,上線后反饋卻很不好:
明明已經超時了,為什么還要顯示在頁面上讓我們搶,搶又搶不到!
確實,這樣的做法很不好。配送是一個對效率要求很高的環節,在這樣的反復搶單失敗中,嚴重損害了配送員搶單的積極性。
不得已,只能在待搶單列表中增加了定時刷新的機制,每隔1分鐘刷新列表。這樣可以過濾掉部分已經被搶或已經超時的訂單,但還是有部分訂單因為超時而搶單失敗。最后,沒辦法,只能做了一個小小的欺騙:將訂單已超時和訂單已被搶的提示都統一成了“手慢了,訂單已被搶”。瞬間問題就解決了,再也沒有聽到有配送員抱怨了,世界又一下子和諧了!
從心理學來說:人們在歸因的時候,更容易得出自己想得到的結論,而不一定是真實的結論。并且出于心理上的自我保護,人們會將導致失敗的外界原因放大,而將自己個人的原因淡化。所以,當因為訂單超時導致搶單失敗時,配送員會抱怨產品的設計問題(外部因素)。但是同樣的結果(問題本質并沒有得到改善);“欺騙”他是因為自己手速慢了,導致訂單被搶,卻沒人再抱怨了(個人因素)。不但沒有配送員抱怨了,反而看到訂單的時候都及時去搶單了,不再挑三揀四,訂單處理的整體效率還得到了提升!
填完這個坑,終于領悟,做產品,不僅要有很高的理性思維,也要有很強的感性思維。有時候,通過理性思維很難解決或解決成本很高的問題,換個維度,通過感性思維,說不定就不費吹灰之力。
第一個版本的調度系統首頁,我做了一個精美的歡迎頁。一開始使用的同事們覺得還不錯,但是過了幾天,大家就審美疲勞了。因為同事們每天要登錄很多次,去查看配送系統中的各項數據,歡迎頁除了一開始的新鮮,對效率的提升毫無幫助。
認識到這個問題后,第二個版本優化時,我將歡迎頁改為一個儀表盤。將工作中的配送員、待取貨的訂單數、待送貨的訂單數、報錯訂單數等重要數據在儀表盤實時展現出來。這樣一來,工作人員一登錄系統,就可以直觀看到他們最想看到的重要數據,而不是一張“精美”的歡迎頁,還要再經過幾次點擊,才能看到他們想看到的數據。
所以,我們在設計產品時,需要時刻提醒自己,產品的用戶是誰。后端產品的用戶是公司內部的同事,相比于美觀,他們更需要的是效率。如金字塔原理一樣,結論先行、重要的結果先行,登錄后最先展現的是重要的數據,這對效率的提升就很有幫助。就如原研哉所說“設計的目的是為了更好的傳達信息”,永遠不要僅為了美觀而設計。
在設計智能派單算法時,一開始,為了體現公平,每個配送員被系統分配到訂單的可能性只取決于配送員當前位置、訂單路線、訂單承諾送達的時間、配送員當前手上配送中的訂單情況等客觀因素。但是后來發現,這樣一來配送員的配送速度、配送滿意度等個性化指標沒法貫徹落實,因為在派單機制中,沒有將這些作為考慮因素。
后來在版本優化時,在智能派單算法中增加了配送員速度、滿意度等個性指標對派單概率的影響。就這樣在智能派單機制中遵從了森林法則,配送速度快的、滿意度高的、超時率低的配送員被派單的可能性更大,相應的績效工資也更高。增加了個性化指標對派單概率的影響后,解決了為了平等而一刀切的情況,形成了良性競爭,對整個配送團隊的效率帶來了很大的提升。
很多時候,公平不是平等,平等是沒有條件的盲目平均,而公平是有前置條件的平等。平等滋生迂腐和低效,而相對的公平能帶來良性競爭和高效。我們在設計產品時要避免平等,而是要用公平去設計規則,來達到產品目標。
一開始,設計調度管理系統的權限時,只設計了賬號和權限2個維度。但是,在實際使用過程中發現這樣很不方便,當要增加一個新同事的賬號時,需要在好幾十種權限中勾選出他需要的權限。不僅過程十分麻煩,還會出現多勾選了不該賦予的高級權限,或少勾選了賬號需要的權限等差錯。
得知了這樣的情況后,在后來改版時,我將權限分了3個維度:賬號、角色、權限。這樣,先對不同的角色賦予不同的權限,如客服、客服主管、客服總監、調度員、配送總監等角色。當新同事加入時,只要將該同事的賬號與對應的角色關聯就OK,不再需要勾選很多權限,大大提高了權限管理的效率,降低了出錯率。而且,當大要開通Boss的賬號時,只需要將客服總監、配送總監等高級角色都賦予Boss賬號即可。
系統的權限管理,可以類比到公司的組織結構管理上:員工由經理管,經理由總監管,而Boss只要管理各業務部門的總監就ok了。正如《簡約至上》中所說,組織是簡化設計的重要策略之一。將繁雜散亂的功能或元素,根據其特性組織分類,形成一個樹形結構,這時候我們就更容易看清問題的本質。一但抓住問題的本質,復雜的問題往往就能迎刃而解。
篇幅原因,就先分享這么幾個我踩過的坑吧,希望我的前車之覆,能為后車之鑒。
作為一條產品狗,我還在不斷挖坑和填坑的道路上前進。復盤的目的只是為了不掉進同一個坑兩次,未來還有更多的坑在等著我!但,那又怎樣,萬物皆有裂痕,那是光照進來的地方!