我的主管經(jīng)常對我們說：產(chǎn)品經(jīng)理最重要的能力就是判斷優(yōu)先級，不然就不叫產(chǎn)品經(jīng)理，而是需求經(jīng)理。以前我聽了總是不以為然，覺得判斷優(yōu)先級就是優(yōu)先做緊急的和實現(xiàn)成本低的需求，毫無技術(shù)含量；而設(shè)計師需要從用戶的整體使用流程綜合考慮，給出一個理想而完整的方案。所以很長一段時間，我都覺得產(chǎn)品經(jīng)理大多是在做救火的事情，而只有設(shè)計師才有條件和能力從用戶的角度全盤考慮，從根本上解決問題。
直到今年遇到這兩件事情，我才有了不一樣的認識。
不會判斷優(yōu)先級的悲劇
年初時，主管發(fā)動了一場關(guān)于易用性方案的PK活動。一個產(chǎn)品經(jīng)理拿出了彈層引導(dǎo)的方案（在每個頁面都有若干引導(dǎo)），當時我簡直笑壞了，心想這不是在破衣服上打補丁嗎，完全是治標不治本的做法；我拿出了自己的方案：從深層次分析易用性不好的原因，重新梳理流程，給出了一個全新的方案，該方案從根本上改進了易用性問題，使用流程大幅縮減，信息結(jié)構(gòu)簡明易懂。當時我講完我的方案，收獲了全場的掌聲。很多人表示開了眼界，從沒想過還可以這么做，也見識了交互設(shè)計的專業(yè)性。
但最后主管選擇了彈層的方案。理由是我們承辦了一個活動，短期內(nèi)將有非常大量的用戶迅速涌入，而目前產(chǎn)品的易用性存在很大問題，我們必須在最短時間內(nèi)以最小代價解決。兩個方案擺在面前，怎么判斷優(yōu)先級，不是看哪個方案好就選哪個，而是要圍繞業(yè)務(wù)目標。
最近一段時間，易用性的事情又重啟了。因為之前經(jīng)過幾個月“打補丁”的改進方式，易用性還是沒有很明顯的起色，主管很不滿意，讓我也進入這個項目好好看看。我覺得機會終于來了，是時候把我當時的思路和方案重新拿出來了（由于時間已經(jīng)過去大半年，業(yè)務(wù)方面發(fā)生了很多變化，于是我的方案也有所更新，但思路基本不變，還是從整體使用流程考慮，給出較完整的方案）。
review的時候主管說不想看這些看似正確卻抓不住重點的東西，要看具體改進了哪些點。幸好我早有準備列出了一個list，里面羅列了和線上相比具體的改動點。主管一條一條的看，問我：你覺得哪條是最緊急的，是有關(guān)業(yè)務(wù)生死問題的？我愣了一下，回答：幾乎都不是。主管說你們要把所有改動的list列出來，根據(jù)業(yè)務(wù)目標排好優(yōu)先級，不然你們短期是一定拿不到結(jié)果的。
當時我很不解，我一直覺得用戶體驗是一個完整的過程，不是一個個零散的點。怎么能用改bug的方式去改進用戶體驗?zāi)?。以前好歹我也做過幾年的交互設(shè)計，也沒出現(xiàn)過什么問題，為什么在這里就玩不轉(zhuǎn)呢。
問題出在哪里
我仔細思考了之前做交互設(shè)計的經(jīng)歷，發(fā)現(xiàn)忽略了這樣幾個客觀事實：一是產(chǎn)品經(jīng)理在向設(shè)計師提需求之前，其實已經(jīng)分解并排好優(yōu)先級了；二是改版和日常迭代往往是分開的，很多日常迭代的需求可能和界面無關(guān)，產(chǎn)品經(jīng)理自己消化掉了；三是對于現(xiàn)在在做的復(fù)雜平臺型產(chǎn)品，功能邏輯的設(shè)計遠大于界面影響，所以必須從表層使用問題滲透到功能層面，易用性問題才有解（對比流暢而完整的設(shè)計方案，功能是相對獨立的）。由于我們這里產(chǎn)品經(jīng)理和交互設(shè)計師的分工并沒有那么明確，當大家共同own易用性改進這件事情時，我還在按照以前交互設(shè)計師的思路做事情，而沒有根據(jù)業(yè)務(wù)節(jié)奏排列優(yōu)先級sense的缺點也就暴露無疑了。
產(chǎn)品經(jīng)理側(cè)重于從產(chǎn)品整體角度（包括業(yè)務(wù)目標、功能邏輯、技術(shù)資源、用戶體驗）去考慮問題，并排列優(yōu)先級；而設(shè)計師側(cè)重于在既定優(yōu)先級判斷基礎(chǔ)上從用戶角度考慮界面設(shè)計。太過考慮業(yè)務(wù)目標，難免忽視了用戶體驗；而太過于考慮用戶體驗，短期內(nèi)又很難達成業(yè)務(wù)目標。怎樣保證在產(chǎn)品設(shè)計過程中最大限度的不影響體驗，又能按照業(yè)務(wù)要求拿結(jié)果呢？這里面其實大有學(xué)問。
如何圍繞業(yè)務(wù)目標及用戶價值判斷優(yōu)先級
一、高風險的大手術(shù)還是低風險的物理療法
由于我們的產(chǎn)品有比較復(fù)雜的歷史背景，所以易用性問題非常突出：功能設(shè)計復(fù)雜而冗余、信息結(jié)構(gòu)冗余、操作流程復(fù)雜缺乏引導(dǎo)，所以我們首先要面臨一個選擇：是根據(jù)收集到的問題逐一改進，還是整體重構(gòu)。之前就這個問題，我和產(chǎn)品經(jīng)理發(fā)生了巨大的分歧，我強烈建議整體重構(gòu)，因為用戶的問題其實都是建立在目前糟糕的設(shè)計上的，所以不能哪兒痛醫(yī)哪兒，而是要抓住問題根源，徹底根除；而產(chǎn)品經(jīng)理的意見是先改容易改的以及可以快速見到成效的用戶問題，這樣才能拿到結(jié)果。
其實從產(chǎn)品整體視角來看，答案很明顯：老用戶已經(jīng)養(yǎng)成較穩(wěn)定的使用習慣，且目前正處在商業(yè)化進程中，一切不容有失；而新用戶主動使用的場景還不明顯。所以小步快跑的方式是最穩(wěn)妥的。但是如果是站在設(shè)計師的角度來看，就比較容易迷失在其中。這也是我之前一直強調(diào)的“眼界”和“格局”，說出來容易，但真正做到其實很難。
二、迭代開發(fā)與增量開發(fā)
現(xiàn)在我們已經(jīng)確定不做整體重構(gòu)，而是定期、快速的產(chǎn)出，那么分解需求的標準、形式應(yīng)該是怎樣的呢？正巧上周公司有一個相關(guān)的培訓(xùn)，我聽了后覺得收獲很大。當時老師舉了一個例子：如果你有五塊錢，你又不想一下子花出去，你是拆成五個一塊錢，還是撕成五瓣呢？如果是拆成五個一塊錢，那每張一塊錢都是可以立即花出去的，而撕成五瓣的話，每一瓣都無法使用了。這也是迭代開發(fā)的精髓，即把大塊的需求拆分成獨立的、可交付的若干完整需求，再開發(fā)上線。
用一幅圖來說明（圖片來源于網(wǎng)絡(luò)）：
迭代開發(fā)
增量開發(fā)
迭代開發(fā)中，每一次的交付物都是完整、用戶可用的。如同上圖的蒙娜麗莎像，雖然第一幅圖比較粗糙，但是用戶可以看到完整的輪廓，不影響對整體的理解，而且過程比較可控，可以隨時修改；而增量開發(fā)中，每一次的交付物雖然精細，但對用戶來說不可用，必須全部完成才能拼成一個完整的、用戶可用的產(chǎn)品，且風險不可控，一旦發(fā)現(xiàn)之前的存在問題，也很難回頭了。
而學(xué)過繪畫的人也都知道，畫畫是先從輪廓開始、逐步迭代、精細化的過程，而不是增量的過程，除非是畫過千百次這樣的畫，已經(jīng)完全胸有成竹。但顯然這對我們這樣一個創(chuàng)新型、充滿各種不確定的產(chǎn)品來說不太合適。
三、MVP原則拆分需求
現(xiàn)在我們已經(jīng)確定要以迭代開發(fā)而非增量開發(fā)的形式來拆分需求了，那么具體該怎樣分解呢？
在培訓(xùn)課堂上我們做了這樣一個練習：聽課人員分成兩個小組，每個小組的成員分別在貼紙上寫出自己每天早上從起床到出門需要做的所有事情，組長把所有的內(nèi)容匯總，再分類展示，得到用戶故事地圖:
老師問大家，整個過程大概要多久？大家回答：一個小時左右。老師說：假設(shè)有一天你起晚了，并且這一天你要參加一個非常重要的會議，不能遲到?，F(xiàn)在你只有五分鐘的時間出門，你會從其中選擇哪些？
大家一致選擇了上廁所、刷牙、洗臉、換衣服、關(guān)門、鎖門這幾項。雖然大部分事項被省略掉了，但其實并不影響大家出門。這也就是MVP的理念，即“最小化可行產(chǎn)品”，它無疑是簡陋的、粗糙的，但是它是完整的、基本流暢的、用戶可使用的產(chǎn)品。這樣，既可以在最短時間內(nèi)有所產(chǎn)出，又保證了用戶體驗的連續(xù)性（不至于因為砍掉太多功能而根本無法使用）；同時使用這種方法，可以讓項目所有成員都看到一個完整的用戶場景，可據(jù)此快速討論出優(yōu)先級，避免“只見樹木、不見森林”的情況，節(jié)省了大量的時間。
對于一個老產(chǎn)品的快速迭代，通過這種方法也可以快速判斷出功能的優(yōu)先級。然后我們可以重點看該功能對應(yīng)的用戶反饋，歸納出問題的核心原因，得出解決方案，再通過業(yè)務(wù)價值、問題程度、預(yù)計效果、開發(fā)成本等因素綜合判斷具體的優(yōu)先級。
選購指南：
本公司主要為山東地區(qū)的商業(yè)、企業(yè)單位及個人提供各類定制開發(fā)服務(wù)，如：軟件定制開發(fā)、APP定制開發(fā)、微信定制開發(fā)以及P5業(yè)務(wù)支撐平臺等整體的信息化解決方案，能夠滿足各種大中小型商業(yè)、企業(yè)及個人的需要。
