賬號(hào)重構(gòu)是我做PM之后，經(jīng)手的第一個(gè)項(xiàng)目。

最初的需求，應(yīng)該是原始簡(jiǎn)陋的賬號(hào)體系無(wú)法實(shí)現(xiàn)更換手機(jī)號(hào)，更換微信等需求，也沒法把用戶的微信和手機(jī)號(hào)分別創(chuàng)立的賬號(hào)統(tǒng)一起來(lái)。

于是，為了解決這個(gè)問題，我決定優(yōu)化表結(jié)構(gòu)和邏輯，將手機(jī)號(hào)，三方登錄的UID都降級(jí)，統(tǒng)一在一個(gè)固定的賬號(hào)主ID上。

• 順便……再解決一下登錄頁(yè)面UI太丑交互太過(guò)時(shí)的問題？
• 順便……再增加一下強(qiáng)制第三方綁定手機(jī)號(hào)來(lái)杜絕臟數(shù)據(jù)？
• 順便……把個(gè)人中心頁(yè)面優(yōu)化一下？
• 順便……(╯‵□′)╯︵┻━┻ 產(chǎn)品要控制欲望……再順便開發(fā)要砍人了……

這是第0條經(jīng)驗(yàn)。

【Tip 0】控制欲望，版本封閉

不成熟的小產(chǎn)品可以讓老大幫忙規(guī)劃需求，然后再旁邊記小本本，學(xué)習(xí)一下如何管理需求，安排優(yōu)先級(jí)。（比如要考慮前端后臺(tái)的工作量啦~拆分功能會(huì)受到多大影響啦~用戶體驗(yàn)和商業(yè)價(jià)值孰輕孰重啦~）

下面……是自己這一個(gè)多月來(lái)的血淚教訓(xùn)……適用于一切【常規(guī)功能的重構(gòu)需求】。

【Tip 1】一定要先調(diào)研清楚后臺(tái)邏輯

API的開發(fā)哥哥在需求評(píng)審的時(shí)候，非要我跟前端一起，把頁(yè)面的接口都整理一遍，再跟著后臺(tái)一起爬代碼看邏輯。

在被一行行天書摧殘了一下午后，我發(fā)現(xiàn)PRD基本不用改（= =）……但是，如果在寫PRD之前先受過(guò)摧殘，那么寫起來(lái)至少可以快一倍。所以，還是要謝謝開發(fā)哥哥的傲嬌要求的。

對(duì)于一個(gè)剛剛創(chuàng)業(yè)的小公司，很多功能都是早期應(yīng)急做出來(lái)的，又經(jīng)過(guò)線上時(shí)不時(shí)優(yōu)化的小補(bǔ)丁，可能會(huì)給現(xiàn)在的需求開發(fā)帶來(lái)一個(gè)又一個(gè)的坑。

如果在最開始，沒有把線上的邏輯搞清楚，在開發(fā)階段再填坑，會(huì)付出慘痛的代價(jià)（比如熬夜加班補(bǔ)邏輯的同時(shí)還要被開發(fā)哥哥嫌棄……）

【Tip 2】關(guān)于邏輯

1. 該抄就抄。2. 最核心的邏輯牢牢攥在手心。

該抄就抄

賬號(hào)體系這種只要是一個(gè)有用戶的產(chǎn)品就會(huì)有的常規(guī)功能，在互聯(lián)網(wǎng)普及這么久后，已經(jīng)有了成熟的體系。

那么如果我們想要做這個(gè)功能或者優(yōu)化這個(gè)功能，最應(yīng)該做的，就是……抄啊！

大公司幾億用戶多少年驗(yàn)證出來(lái)解決問題的最優(yōu)方案，也是中國(guó)網(wǎng)民多年來(lái)的操作習(xí)慣……不復(fù)用是傻子么！

咳咳，但是借鑒也是有技巧的。

比如我們是不是希望用戶以手機(jī)號(hào)為主要注冊(cè)用的賬號(hào)，該怎么樣淡化/強(qiáng)調(diào)第三方的入口；各種密碼驗(yàn)證碼的格式和校驗(yàn)；頁(yè)面跳轉(zhuǎn)中注冊(cè)和忘記密碼的入口放哪兒；置灰和文案的小細(xì)節(jié)……歷盡千帆，取百家之長(zhǎng)，選擇最符合自己產(chǎn)品的……原型圖畫好了耶~

ps. 不要忘記加入符合自己公司特色的小創(chuàng)新~（如果有且適合加進(jìn)來(lái)的話……沒必要盲目追求新意）

pps. 也不要忘記兼容產(chǎn)品以前的坑哦~

最核心的邏輯牢牢攥在手心——死也不改

在PRD已經(jīng)定稿以后，開發(fā)過(guò)程中，需求是可以小幅度變更的。畢竟PM不是神肯定會(huì)有考慮不周的地方。

但是核心邏輯，是一定要明確好，并且保證每一個(gè)參與項(xiàng)目的人都了解清楚的。

如果開發(fā)中發(fā)現(xiàn)核心邏輯錯(cuò)了，寧可暫停整個(gè)項(xiàng)目不做，也不能朝令夕改，產(chǎn)品如果對(duì)于自己的邏輯都搞不清楚，那連最后的話語(yǔ)權(quán)也沒有了。

【Tip 3】關(guān)于交互

站在用戶的角度出發(fā)，但別把自己當(dāng)成用戶。

PM是用戶的代言人。

這里的用戶，是所有的用戶，包括各種會(huì)進(jìn)行奇怪操作或是有特殊需求的非主流用戶。

怎么樣能更好更全面地寫好PRD避免遺漏，我想到比較好的方法是：

設(shè)計(jì)頁(yè)面和流程圖要分三遍

1. 第一遍，保證核心的常規(guī)流程是走得通的（比如用戶一步一步登錄或注冊(cè)的過(guò)程），或者通過(guò)賬號(hào)中心綁定手機(jī)號(hào)至成功的操作。
2. 第二遍，保證其他分支流程不存在死循環(huán)或者死胡同（比如進(jìn)行到某一步突然忘記密碼，或者突然斷網(wǎng)或手機(jī)收不到驗(yàn)證碼等），不管什么情況，一定要給用戶反饋。
3. 第三遍，優(yōu)化核心流程的用戶體驗(yàn)。比如可以把一些元素放在一個(gè)頁(yè)面展現(xiàn)不用分多個(gè)頁(yè)面，比如一些按鈕的特效和交互。

多看多琢磨其他產(chǎn)品這塊兒的功能

比如連續(xù)輸入多次錯(cuò)誤的手機(jī)號(hào)，會(huì)出現(xiàn)圖片驗(yàn)證碼，防止爬庫(kù)。

比如有些頁(yè)面涉及表單提交和狀態(tài)更新，點(diǎn)擊返回或者右滑后的頁(yè)面展示和跳轉(zhuǎn)邏輯。

這些細(xì)節(jié)只能說(shuō)多研究，多經(jīng)歷……如果沒有項(xiàng)目經(jīng)驗(yàn)可以積累，那么多多觀摩其他成功產(chǎn)品也總是有幫助的。

【Tip 4】關(guān)于PRD

流程圖比文字更好用。

這次賬號(hào)重構(gòu)我最大的坑就是……寫了一萬(wàn)多字的PRD，結(jié)果開發(fā)基本照著流程圖來(lái)的……（然后我的流程圖還漏了很多元素）

后來(lái)在宣講的時(shí)候，重新畫了一遍流程圖，把一些對(duì)應(yīng)的頁(yè)面跳轉(zhuǎn)和提示都加上去了。感覺開發(fā)同學(xué)理解，和自己說(shuō)明都快了很多。

以后寫PRD，圖文并茂，少說(shuō)廢話。該枚舉的地方用表格，且一定記得加目錄索引。

PRD是PM的臉，別讓他變成下圖所示。

【Tip 5】關(guān)于溝通

當(dāng)面>私聊>群聊

如果每天都隨身帶著手機(jī)，那我的微信步數(shù)肯定要double。

PM請(qǐng)安心當(dāng)一只召喚獸~雖然跑來(lái)跑去很麻煩，但是當(dāng)面溝通比起打字甚至拉群里說(shuō)，提高的效率不是一點(diǎn)半點(diǎn)的。

【Tip 6】關(guān)于職責(zé)

保證可用100%，易用50%

衡量一個(gè)產(chǎn)品的好壞和能否上線，有很多因素，比如：

1. 可用性——是否滿足業(yè)務(wù)需求
2. 易用性——是否有好的用戶體驗(yàn)
3. 美觀性——是否傳遞了公司品牌形象
4. 安全性——是否會(huì)影響線上其他功能，是否存在安全隱患

其中我覺得，產(chǎn)品最主要的是保證100%的可用性，即PRD明確的功能性需求要都實(shí)現(xiàn)。

其次是50%的易用性，可能我們?cè)O(shè)計(jì)的時(shí)候考慮到了80%甚至100%的易用性，但是由于時(shí)間或者其他原因，開發(fā)沒有做。這部分涉及用戶體驗(yàn)的需求是可以后續(xù)版本優(yōu)化，或者為功能性和安全性需求讓道的。

美觀性和安全性，在設(shè)計(jì)的時(shí)候要考慮，但是決定權(quán)交給UI和RD。讓專業(yè)的人，做專業(yè)的事?？梢蕴岢鼋ㄗh甚至異議，但是不要盲目亂做決定。

以上是這次版本迭代整理的幾條心得。感謝包容我這只小菜鳥的產(chǎn)品、UI、開發(fā)、測(cè)試同學(xué)~

希望以后再讀到，會(huì)覺得說(shuō)的都是廢話。

作者：徐家小翼，公眾號(hào)：poemmanager，PM圈萌新一只，求帶飛求指導(dǎo)~~

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