作者從三個(gè)層面，對自己參與過的產(chǎn)品項(xiàng)目進(jìn)行了簡單總結(jié)，希望你能從中得到一些收獲。

本人所在是一家零售電商綜合平臺，集團(tuán)為了更極致的用戶體驗(yàn)，提高自身物流配送能力，于年前公司收購一家同行快遞公司。在此背景下，IT信息部為了業(yè)務(wù)能夠順利整合雙方資源，業(yè)務(wù)能按照計(jì)劃進(jìn)行融合，故提前進(jìn)行系統(tǒng)融合規(guī)劃設(shè)計(jì)，保證公司收購后的平滑過渡。

本人作為項(xiàng)目組的核心成員，親自從需求調(diào)研至項(xiàng)目上線運(yùn)維的全流程進(jìn)行了參與。目前項(xiàng)目已順利結(jié)項(xiàng)，下面來從3個(gè)方面進(jìn)行總結(jié)，特別是本人犯過的錯(cuò)，踩過的坑。本人第一次投稿，針對不合理之處，還請各位大俠指正。

需求調(diào)研：深刻理解業(yè)務(wù)，細(xì)致搜集資料

每一個(gè)產(chǎn)品經(jīng)理都明白對業(yè)務(wù)理解的重要性，但并不是每個(gè)產(chǎn)品經(jīng)理都能明白除了自己要深入理解之外，還必須要讓項(xiàng)目組的開發(fā)、測試也要進(jìn)行理解。回顧整個(gè)項(xiàng)目，對需求調(diào)研過程中需要注意的地方總結(jié)如下：

1. 需求調(diào)研過程中，一定要對業(yè)務(wù)現(xiàn)場的每個(gè)操作場景要做圖片、視頻資料采集，保證后續(xù)可反復(fù)查看理解；本人在業(yè)務(wù)現(xiàn)場進(jìn)行需求調(diào)研的過程中，自認(rèn)為自己對業(yè)務(wù)的理解就可以了，所以沒有認(rèn)真對業(yè)務(wù)現(xiàn)場進(jìn)行圖片和視頻的資料采集，只是簡單圖片拍照。待需求整理完，與開發(fā)測試進(jìn)行溝通的時(shí)候，發(fā)現(xiàn)他們不能理解真實(shí)的操作場景，僅憑照片不能完全還原全部細(xì)節(jié)，導(dǎo)致本人對業(yè)務(wù)現(xiàn)場進(jìn)行二次調(diào)研搜集資料，浪費(fèi)了不少精力。待二次調(diào)研搜集資料后，發(fā)現(xiàn)后續(xù)在項(xiàng)目過程中還是會反復(fù)用到視頻資料來理解業(yè)務(wù)。
2. 需求調(diào)研過程中，除了需要對業(yè)務(wù)流程進(jìn)行梳理之外，還必須關(guān)注業(yè)務(wù)量、用戶角色分工、用戶素質(zhì)、使用場合（如網(wǎng)絡(luò)環(huán)境）等細(xì)節(jié)；本項(xiàng)目中，由于涉及兩個(gè)公司業(yè)務(wù)流程的融合，初期只是針對業(yè)務(wù)流程進(jìn)行梳理融合，并未關(guān)注流程中的用戶角色分工，導(dǎo)致初版設(shè)計(jì)模型中的部分產(chǎn)品功能不能滿足業(yè)務(wù)需要，只能進(jìn)行二次設(shè)計(jì)。

舉例：分撥現(xiàn)場進(jìn)行裝車環(huán)節(jié)，業(yè)務(wù)流程在雙方流程中其實(shí)都一致：需裝車開始—-掃描包裹—-裝車完成—-發(fā)車確認(rèn)。

由于公司目前業(yè)務(wù)量比較少，業(yè)務(wù)現(xiàn)場整個(gè)操作流程都是一個(gè)人單獨(dú)完成，故現(xiàn)有功能設(shè)計(jì)是將整個(gè)流程整合在一個(gè)功能頁面負(fù)責(zé)完成的。

本項(xiàng)目中，業(yè)務(wù)梳理結(jié)束后，針對該模塊進(jìn)行設(shè)計(jì)時(shí)，也自然的按照現(xiàn)有功能設(shè)計(jì)方案，將整個(gè)裝車流程功能設(shè)計(jì)整合一個(gè)功能頁面負(fù)責(zé)完成。

待初版模型交付業(yè)務(wù)溝通后，發(fā)現(xiàn)設(shè)計(jì)中忽略了用戶角色分工的考量，不能滿足業(yè)務(wù)需要。新公司的業(yè)務(wù)量大，業(yè)務(wù)現(xiàn)場的用戶角色分工細(xì)致，并不是一個(gè)人完成全流程，而是多角色配合完成。所以對該流程進(jìn)行二次設(shè)計(jì)，將針對每個(gè)用戶角色功能進(jìn)行區(qū)分設(shè)計(jì)。

產(chǎn)品設(shè)計(jì)：千萬要關(guān)注細(xì)節(jié)

1.不要著急進(jìn)行產(chǎn)品功能設(shè)計(jì)，需在此之前，在業(yè)務(wù)流程梳理明確的基礎(chǔ)上，定義好系統(tǒng)框架。

2.產(chǎn)品設(shè)計(jì)過程中，特別是需求文檔編寫時(shí)，一定要對細(xì)節(jié)性進(jìn)行明確定義。產(chǎn)品上線后一般主流程都沒有大問題，往往出問題最多的都是一些小細(xì)節(jié)的問題，所以在需求定義階段，在文檔中需要對細(xì)節(jié)問題進(jìn)行明確定義，比如null和空的問題、字段長度、小數(shù)點(diǎn)、枚舉值定義等小問題，往往小細(xì)節(jié)會導(dǎo)致大問題。針對接口交互，一定要考慮好異常數(shù)據(jù)接收處理、數(shù)據(jù)接收先后順序、接口并發(fā)、接口回執(zhí)等問題。

本人在此項(xiàng)目中，負(fù)責(zé)設(shè)計(jì)的接口曾出現(xiàn)過因?yàn)榻涌诓l(fā)過大導(dǎo)致生產(chǎn)問題產(chǎn)生。雖然系統(tǒng)邏輯上設(shè)計(jì)了校驗(yàn)規(guī)則，但是在上游系統(tǒng)在毫秒級的短時(shí)間內(nèi)下發(fā)多條數(shù)據(jù)的情況下，下游接收系統(tǒng)同時(shí)按照規(guī)則校驗(yàn)時(shí)失效，導(dǎo)致接收方數(shù)據(jù)處理產(chǎn)生異常。后來經(jīng)過接收系統(tǒng)在接口處理中加入了排隊(duì)處理機(jī)制才解決此問題。

3.產(chǎn)品設(shè)計(jì)初期，不能只考慮功能設(shè)計(jì)，還需要提前考慮性能設(shè)計(jì)。雖然產(chǎn)品性能多是開發(fā)需要考慮的問題，但是在產(chǎn)品設(shè)計(jì)過程中，產(chǎn)品一定要對自己的功能的業(yè)務(wù)量進(jìn)行預(yù)估，并與開發(fā)提前溝通產(chǎn)品設(shè)計(jì)方案。否則待到上線后發(fā)現(xiàn)性能存在瓶頸，這個(gè)時(shí)候再來調(diào)整方案很可能就是傷筋動(dòng)骨了。

項(xiàng)目管理：要有主人翁精神

在項(xiàng)目管理過程中，產(chǎn)品一定要有主人翁精神。產(chǎn)品上線后遇到的任何問題，不管是開發(fā)原因還是測試原因?qū)е聠栴}產(chǎn)品，產(chǎn)品都必須負(fù)有責(zé)任，開發(fā)交付后除了測試人員測試產(chǎn)品之外，產(chǎn)品也必須主動(dòng)全方位驗(yàn)證自己產(chǎn)品，全面發(fā)現(xiàn)問題。這樣也能更好發(fā)現(xiàn)自己功能上的雷區(qū)，更好理解產(chǎn)品實(shí)現(xiàn)邏輯，未來出現(xiàn)問題也能更快的定位原因。

本人在項(xiàng)目過程中，要求產(chǎn)品團(tuán)隊(duì)每周定期匯報(bào)自己發(fā)現(xiàn)的產(chǎn)品問題以及解決方法，并將此類問題解決后要求與測試團(tuán)隊(duì)共享并回歸測試。分析此類問題，發(fā)現(xiàn)很多問題都是測試團(tuán)隊(duì)未發(fā)現(xiàn)的問題。通過此方法，可以讓產(chǎn)品與測試更為深入的了解產(chǎn)品對應(yīng)的用戶場景以及功能邏輯設(shè)計(jì)。

溝通非常重要，產(chǎn)品要協(xié)調(diào)開發(fā)，測試，業(yè)務(wù)，PMO，UED多個(gè)部門和人員，所以產(chǎn)品要善于溝通，遇到問題要勇于承擔(dān)責(zé)任。開發(fā)，測試有資格甩鍋，但產(chǎn)品永遠(yuǎn)不能甩鍋。

每次總結(jié)后，總會發(fā)出這樣的感慨“我X，這么簡單的錯(cuò)誤我竟然沒注意”。是的，人往往容易忽略簡單的小細(xì)節(jié)，但成功的產(chǎn)品往往就是優(yōu)秀在細(xì)節(jié)。作為一個(gè)產(chǎn)品經(jīng)理，一定要多總結(jié)，不要忽略細(xì)節(jié)，把產(chǎn)品做到精致。

本文由 @?Hank 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自unsplash，基于CC0協(xié)議