剛進(jìn)入國(guó)內(nèi)某分散式長(zhǎng)租公寓公司時(shí)，接受到的一個(gè)任務(wù)是將維修員使用的PC端移動(dòng)化，本文主要是講述的是產(chǎn)品設(shè)計(jì)過程。
用戶對(duì)工具型產(chǎn)品的核心需求是效率，具體個(gè)人覺得可以分為四方面：
流程框架：流程真實(shí)映射用戶需求過程，正確對(duì)接后臺(tái)各模塊，契合用戶使用習(xí)慣
功能劃分：功能簡(jiǎn)單易上手，信息分級(jí)清晰，減少誤操作
三方交流：維修進(jìn)度出現(xiàn)問題時(shí)能及時(shí)反饋，幫助用戶解決
快捷尋找：將急需處理的工單與重要信息優(yōu)先、突出呈現(xiàn)，提高工作效率
這四方面是基礎(chǔ)，和移動(dòng)端的使用場(chǎng)景決定了需求的交互架構(gòu)和功能。
立項(xiàng)背景
過去，PC端是為了管理維修而建。隨著業(yè)務(wù)的發(fā)展，簡(jiǎn)單修改后臺(tái)后對(duì)底層維修員開放了部分權(quán)限，維修員通過移動(dòng)瀏覽器訪問后臺(tái)進(jìn)行工單操作，維修員數(shù)量增加后，原系統(tǒng)效率低下的問題開始凸顯，不方便、不穩(wěn)定，難以適應(yīng)移動(dòng)化工作的新要求，主要有以下問題：
項(xiàng)目目標(biāo)
1.將PC上常用的功能與信息剝離并遷移到APP上；
2.相比于PC的繁瑣操作，APP需要簡(jiǎn)化流程并避免重復(fù)輸入相同信息，提高效率；
3.輔助業(yè)務(wù)方優(yōu)化原業(yè)務(wù)流程；
4.利用移動(dòng)端可輕易采集信息的特點(diǎn)，監(jiān)控維修員的行為并加以規(guī)范。
需求流程
項(xiàng)目按照標(biāo)準(zhǔn)流程進(jìn)行管理，概括為需求交付（調(diào)研設(shè)計(jì)評(píng)審）→需求開發(fā)→需求測(cè)試→上線驗(yàn)收四步。
一、需求交付
1、需求調(diào)研
在需求調(diào)研階段，我們需要了解我們做此項(xiàng)目的業(yè)務(wù)背景（問題來源、涉及的部門/同事及流程）、項(xiàng)目目的（愿景和功能要點(diǎn)）和實(shí)現(xiàn)方式（基于現(xiàn)有系統(tǒng)改造還是打造新系統(tǒng)，前端用APP還是H5等）
針對(duì)此項(xiàng)目，我們調(diào)研需求時(shí)需要確定項(xiàng)目的需求方/關(guān)聯(lián)方有哪些部門和同事、需要解決的問題都羅列出來，如：
在確認(rèn)對(duì)接人之后，我分別對(duì)接需求方進(jìn)行現(xiàn)有業(yè)務(wù)流程的調(diào)研梳理，在調(diào)研業(yè)務(wù)流程時(shí)，有三種方法：
1.在對(duì)接人工作時(shí)觀察其操作行為，并聆聽和記錄對(duì)方的反饋——涉及報(bào)修人、一線維修員、二線調(diào)度人員與客服、管理經(jīng)理等；
2.獲取現(xiàn)有業(yè)務(wù)流程相關(guān)的文檔，如部門培訓(xùn)文檔和系統(tǒng)操作手冊(cè)等——涉及維修員培訓(xùn)手冊(cè)、原PC后臺(tái)文檔、報(bào)修人前臺(tái)后臺(tái)流程文檔；
3.獲取現(xiàn)有業(yè)務(wù)依托的后臺(tái)賬號(hào)，直接上去查閱或操作已有數(shù)據(jù)——涉及報(bào)修人端、維修員端、admin端。
經(jīng)過上述過程后，基于項(xiàng)目的目標(biāo)，收集好相應(yīng)記錄，再將各需求部門的流程進(jìn)行整合，統(tǒng)一輸出一份跨職能流程和項(xiàng)目功能列表，如下：
注：只展示一部分
2、需求設(shè)計(jì)
基于調(diào)研階段確定的內(nèi)容，在需求設(shè)計(jì)階段，產(chǎn)品需要輸出原型，讓需求方可以提前感知項(xiàng)目未來的界面和操作流程。
產(chǎn)品結(jié)構(gòu)圖：
3、部分原型頁面
文檔備注：
1、技術(shù)細(xì)節(jié)提前與研發(fā)人員溝通了解，減少反復(fù)修改的次數(shù)；
2、不同狀態(tài)的工單詳情頁大同小異，總結(jié)其差別后用表格歸納方便開發(fā)人員；
3、復(fù)雜流程除了頁面原型以外，線框畫出流程；
4、將業(yè)務(wù)細(xì)節(jié)與對(duì)應(yīng)崗位人員也在文檔內(nèi)做備份，方便將來其他產(chǎn)品經(jīng)理查看文檔；
5、狀態(tài)變化節(jié)點(diǎn)按規(guī)范統(tǒng)一標(biāo)明，push節(jié)點(diǎn)、內(nèi)容等用表格整理歸納。
設(shè)計(jì)細(xì)節(jié)：
1、輸入過或數(shù)據(jù)庫里已有的字段直接調(diào)取，減少輸入內(nèi)容，提高維修員使用效率；
2、從前臺(tái)限制維修員操作，減少管理成本；
3、簡(jiǎn)化操作流程，去除繁雜的中間步驟，優(yōu)化現(xiàn)有工作系統(tǒng)；
4、只展示必要信息，通過信息合理分級(jí)、頁面布局優(yōu)化、消息高頻提示等舉措增加維修員專注程度；
5、對(duì)接風(fēng)控、增加定位等舉措，從前臺(tái)監(jiān)控維修員的工作行為，帶來了更好的管理效果。
4、數(shù)據(jù)埋點(diǎn)
基于業(yè)務(wù)需求、產(chǎn)品迭代需求，對(duì)app頁面埋點(diǎn)，通過SDK上報(bào)埋點(diǎn)的數(shù)據(jù)結(jié)果，記錄、匯總并進(jìn)行分析，推動(dòng)產(chǎn)品的優(yōu)化或指導(dǎo)管理運(yùn)營(yíng)。
5、其他注意點(diǎn)
1、數(shù)據(jù)兼容
由于項(xiàng)目上線前，已有原PC系統(tǒng)，移動(dòng)端上線準(zhǔn)入相關(guān)功能需要考慮原有數(shù)據(jù)是否同步和處理，保證PC、移動(dòng)的一致性。
2、用戶設(shè)備
服務(wù)端app的用戶經(jīng)常使用低端安卓機(jī)，性能差、屏幕小、耗電高，需要對(duì)這些特點(diǎn)做對(duì)應(yīng)優(yōu)化。例如，在輸入框輸入內(nèi)容時(shí)，有些低端安卓機(jī)的系統(tǒng)自帶鍵盤沒有確認(rèn)搜索的按鍵，所以搜索框旁得放置確認(rèn)按鍵。
建立產(chǎn)品設(shè)計(jì)需求自查表
1、各個(gè)流程節(jié)點(diǎn)中的通知形式與內(nèi)容（彈窗、通知欄通知和短信等）是否確定；
2、前臺(tái)內(nèi)容是否需要后臺(tái)添加字段并返回內(nèi)容；
3、用戶的提交操作、狀態(tài)變化是否有toast反饋；
4、設(shè)計(jì)過程中是否考慮到臨界和極值情況，比如數(shù)量大小，內(nèi)容長(zhǎng)度、圖片大??；
5、是否和UI設(shè)計(jì)師溝通頁面中內(nèi)容的字?jǐn)?shù)長(zhǎng)度，設(shè)計(jì)細(xì)節(jié)；
6、需求開發(fā)完成后是否對(duì)產(chǎn)品中的一些關(guān)鍵操作埋點(diǎn)；
7、是否考慮到流程中會(huì)存在中間狀態(tài)，如何對(duì)中間狀態(tài)進(jìn)行設(shè)計(jì)，
比如維修員完成工單本狀態(tài)的操作后，需要手動(dòng)操作工單進(jìn)入下一狀態(tài)，這一時(shí)期應(yīng)該如何設(shè)計(jì)；
8、需求設(shè)計(jì)是否能夠形成閉環(huán)；
9、需求設(shè)計(jì)是否充分考慮到目標(biāo)用戶、場(chǎng)景、核心功能；
10、用戶操作完后返回上一層是否需要自動(dòng)刷新數(shù)據(jù)；
11、信息填寫頁面是否考慮過需要給用戶緩存內(nèi)容；
12、信息填寫頁面是否對(duì)填寫順序以及內(nèi)容跳轉(zhuǎn)有要求
13、設(shè)計(jì)過程中需要考慮到用戶拇指的點(diǎn)擊區(qū)域，在靠近拇指的地方放置點(diǎn)擊操作入口；
14、做網(wǎng)站要考慮瀏覽器兼容問題，前端設(shè)計(jì)還需要考慮極值（文字、數(shù)量、行數(shù)）、對(duì)齊方式（參數(shù)物、對(duì)齊類型）；
16、遷移PC功能到APP時(shí)，需要注意是否需要做多終端數(shù)據(jù)互通和數(shù)據(jù)一致性問題；
17、用戶操作完成后跳轉(zhuǎn)到哪里，是否需要緩存進(jìn)度條；
19、數(shù)據(jù)為空、網(wǎng)絡(luò)連接斷掉等情況如何處理。
其他小結(jié)：
1、app用戶有教育程度低、學(xué)習(xí)能力差的特點(diǎn)，應(yīng)盡可能減少用戶誤操作與學(xué)習(xí)成本，app結(jié)構(gòu)層盡可能簡(jiǎn)單、清晰；
2、用戶的注意力和時(shí)間是有稀缺性的，一切的需求（功能，交互路徑、視覺UI）必須考慮到優(yōu)先級(jí)的問題；
3、給與用戶操作反饋，無論是正向還是逆向，比如當(dāng)維修員處于等待申請(qǐng)批準(zhǔn)的狀態(tài)時(shí)，用戶最需要的就是獲知申請(qǐng)進(jìn)度與結(jié)果第一時(shí)間通知，所以必須有對(duì)應(yīng)設(shè)計(jì)；
4、產(chǎn)品經(jīng)理需求的主動(dòng)性要掌握在自己手里，需求的來源、受理和用戶盡量要自己第一手接觸，而不是引用別人講的；
5、產(chǎn)品設(shè)計(jì)需要考慮用戶以往的習(xí)慣，包括操作上和心理預(yù)期的；
6、需求方有無限個(gè)偽需求，面對(duì)一個(gè)需求確認(rèn)問題，同一個(gè)對(duì)接人可能前后給出兩個(gè)截然相反的答案，眼見為實(shí)耳聽為虛，產(chǎn)品經(jīng)理一定明確需求；
7、對(duì)已有后臺(tái)的改動(dòng)牽一發(fā)而動(dòng)全身，如有必要修改也應(yīng)該多方確認(rèn)。
二、需求開發(fā)、測(cè)試
1.開發(fā)階段
需求討論明確、原型更改沒有異議后，產(chǎn)品經(jīng)理需要根據(jù)產(chǎn)品功能復(fù)雜度等綜合因素，安排開發(fā)進(jìn)度。開發(fā)進(jìn)度的安排尤其重要，因?yàn)槿绻_發(fā)期限過長(zhǎng)，則容易導(dǎo)致開發(fā)人員缺少激情產(chǎn)生惰性，而開發(fā)期限過短則會(huì)使開發(fā)人員心理壓力過大，容易降低代碼質(zhì)量從而對(duì)后期版本更新產(chǎn)生隱患。
當(dāng)正式進(jìn)入開發(fā)階段后，產(chǎn)品經(jīng)理需要做的是：一邊跟進(jìn)開發(fā)進(jìn)度，把控開發(fā)質(zhì)量，一邊設(shè)計(jì)下一版本產(chǎn)品原型。
這一階段對(duì)于產(chǎn)品經(jīng)理也尤其重要。產(chǎn)品從0到1的過程以實(shí)現(xiàn)核心功能、減少產(chǎn)品bug為主，而當(dāng)?shù)谝话姹景l(fā)布后，需要根據(jù)市場(chǎng)變化和產(chǎn)品理念進(jìn)行迅速迭代。因此這個(gè)開發(fā)階段是產(chǎn)品經(jīng)理思考產(chǎn)品發(fā)展方向和規(guī)劃下一版本改進(jìn)目標(biāo)的關(guān)鍵時(shí)刻。
2.溝通技巧筆記
可以通過問題的發(fā)生的概率和帶來的影響、方案帶來的提升和開發(fā)的成本去說服對(duì)方：
1.當(dāng)你想要解決一個(gè)問題的時(shí)候需要考慮一下這個(gè)問題發(fā)生的概率和帶來的影響；當(dāng)你告知?jiǎng)e人你有一個(gè)方案的時(shí)候需要考慮下方案帶來的提升和開發(fā)的成本。這幾件事情想明白之后你才可以去和你的同事溝通；
2.發(fā)生設(shè)計(jì)問題時(shí)先判斷發(fā)生頻率，立即評(píng)估，而不是立即去改。因?yàn)榇藭r(shí)產(chǎn)品已經(jīng)開發(fā)過半，返工和延期都是很影響研發(fā)進(jìn)度的，而且還會(huì)影響到后續(xù)功能的設(shè)計(jì)。發(fā)生頻率很低的問題可能重要但是不緊急，可以推后到后續(xù)版本更新中解決。當(dāng)需求進(jìn)開發(fā)后發(fā)現(xiàn)設(shè)計(jì)缺陷時(shí)，或是要和其他部門競(jìng)爭(zhēng)開發(fā)資源的時(shí)，先評(píng)估。
3.如果真要修改設(shè)計(jì)，必須通過郵件讓大家明確產(chǎn)生這種修改的原因，讓所有人明白，這個(gè)是全團(tuán)隊(duì)的大事。
好的溝通是確保未來長(zhǎng)期良好合作的基礎(chǔ)。
三、上線驗(yàn)收
更新迭代
產(chǎn)品從0到1的過程以實(shí)現(xiàn)核心功能、減少產(chǎn)品bug為主，而當(dāng)?shù)谝话姹景l(fā)布后，需要根據(jù)業(yè)務(wù)變化迅速更新迭代。因此上線后產(chǎn)品經(jīng)理也不能松口氣，需要跟進(jìn)bug修改，繼續(xù)思考產(chǎn)品優(yōu)化方向。
