產(chǎn)品經(jīng)理在項(xiàng)目開發(fā)中扮演的是一個(gè)連接者的角色，連接的前提是要熟悉連接對象即兼容對方，善于從對方的角度思考問題。本文將從測試的角度來總結(jié)分析產(chǎn)品設(shè)計(jì)，以此來提升產(chǎn)品設(shè)計(jì)全面性。

在蘇杰大神的博客文章中有這樣一個(gè)觀點(diǎn)：

產(chǎn)品新人如何快速上手的方法之一是寫測試用例。

測試用例是從測試的視角寫的產(chǎn)品描述。測試與產(chǎn)品的邏輯不同，產(chǎn)品抓大放小，測試就是要想清楚各種邊邊角角。

所以，如果團(tuán)隊(duì)正好沒有TC，你來寫一遍，保證對產(chǎn)品的各種細(xì)節(jié)都很熟悉，也會(huì)知道背后用的技術(shù)，因?yàn)楦鞣N限制而造成的各種坑。

一、關(guān)于軟件測試

• 從測試方法來分：軟件測試分為黑盒測試、白盒測試、灰盒測試、靜態(tài)測試、動(dòng)態(tài)測試、手工測試、自動(dòng)化測試。
• 從測試階段來分：軟件測試分為需求測試、單元測試、集成測試、系統(tǒng)測試、驗(yàn)收測試。

黑盒測試也叫功能性測試，在軟件測試過程中大多采用此方式。我所說的產(chǎn)品經(jīng)理懂測試，針對的即是功能性測試，從功能性的角度做產(chǎn)品的需求文檔，遍歷盡可能多的功能場景。一定不能讓開發(fā)和測試找到你的漏洞，那將是產(chǎn)品經(jīng)理最尷尬的時(shí)刻。

有數(shù)據(jù)表示：

在許多失敗的項(xiàng)目中，70%~85%的返工是由于需求方面的錯(cuò)誤導(dǎo)致的。

二、限制邊界值

如果沒有限制輸入框的長度，專業(yè)的測試分分鐘可以把開發(fā)認(rèn)為沒問題的程序搞掛。

因此對輸入框的長度限制，是一個(gè)產(chǎn)品最底層的功能，我想這也是產(chǎn)品經(jīng)理的基本素養(yǎng)。進(jìn)一步的要求是對可輸入字符類型的限制，此項(xiàng)不至于影響到功能，但屬于產(chǎn)品最基本的友好性需求。

下圖是作者好不容易找的一個(gè)反面例子：

數(shù)值「0」是開發(fā)容易忽視的邊界值，在很多場景中0值其實(shí)是沒有意義的，比如金額為0元、數(shù)量為0等。自己的親身經(jīng)歷：之前做過一個(gè)資金分配的功能，由于PRD沒有說明字段的規(guī)則（以為開發(fā)小哥哥用腳想想都會(huì)明白），然而在做功能驗(yàn)收的時(shí)候，我成功給好友分配了0元。。。

對于這些字段的規(guī)則，其實(shí)沒有必要在文檔上一一標(biāo)注，因?yàn)楹芏囗撁娴淖侄纹鋵?shí)是重復(fù)的，這個(gè)方法也很容易漏掉一部分字段。一個(gè)很好的工作方法是：在全局規(guī)范中建立字段規(guī)則表。這個(gè)方法讓我想起了：大學(xué)編程的時(shí)候，會(huì)統(tǒng)一將全局變量的定義集中放置。

作者拋出一個(gè)輸入框?qū)崭竦奶幚淼臏y試用例供大家思考：

1. 前面存在空格
2. 后面存在空格
3. 前后都存在空格
4. 中間存在空格

二、遍歷異常邏輯

正常流程只有一個(gè)，異常流程卻異常的多。在很多PM的PRD中，僅僅陳列了正常的業(yè)務(wù)流程。

很少有開發(fā)是會(huì)替產(chǎn)品考慮異常邏輯的，所以為了不給自己挖坑，在寫PRD的時(shí)候，就要將所有的異常流程都描述清楚，我想在需求評審的時(shí)候會(huì)更容易通過，也會(huì)在開發(fā)的眼里樹立權(quán)威。

有人說，無反饋是產(chǎn)品大忌。我想說，反饋不完全也是產(chǎn)品不專業(yè)的體現(xiàn)。對于特定事件的反饋，既然有成功的結(jié)果，必然會(huì)存在對立面——失敗。對于這些事件的總結(jié)其實(shí)很容易找到規(guī)律，很多優(yōu)秀的PM都會(huì)整理一份交互設(shè)計(jì)自查表，然后會(huì)不斷的更新迭代。

善于總結(jié)是一個(gè)優(yōu)秀學(xué)習(xí)者的必要品質(zhì)，在項(xiàng)目經(jīng)歷中總結(jié)積累遇到的異常情況。有句話這樣說：

“你現(xiàn)在經(jīng)歷的每一件事，都會(huì)在未來某一時(shí)刻用上”。

登錄注冊可能是大多數(shù)PM童鞋的處女級產(chǎn)品功能，根據(jù)我個(gè)人的經(jīng)驗(yàn)：如果沒有從零到一將這個(gè)需求落地，一定是存在認(rèn)知漏洞的。

我說一個(gè)場景，看大家有沒有考慮到：手機(jī)號驗(yàn)證碼輸入框在同一個(gè)頁面，在手機(jī)號無誤、驗(yàn)證碼輸入正確的情況下，然后更改手機(jī)號（手機(jī)號格式合法），提交之后應(yīng)該如何反饋？

三、關(guān)聯(lián)性的問題

在項(xiàng)目中，大多數(shù)功能模塊往往不是獨(dú)立的，一般存在交集或者需要進(jìn)行模塊間的數(shù)據(jù)交互。因此一個(gè)模塊如果發(fā)生了需求變更或者數(shù)據(jù)丟失，就會(huì)影響到相關(guān)聯(lián)的功能模塊。

曾經(jīng)做過一個(gè)項(xiàng)目，由于平臺(tái)新增了直營店功能，之前設(shè)計(jì)的訂單詳情就不適用了，需要融合新需求，財(cái)務(wù)管理模塊也要做字段的擴(kuò)展。

關(guān)聯(lián)信息不允許刪除，比如商品類別，假如商品類別是商品的必要屬性，此時(shí)就應(yīng)該禁止正使用的類別被刪除。還有一個(gè)很重要的關(guān)聯(lián)性問題是，正在生效的規(guī)則是不能被刪除。

四 、性能的問題

性能無止境，性能的優(yōu)化伴隨著產(chǎn)品的整個(gè)生命周期。測試過程，性能測試處于功能測試之后，也就是說功能大于性能。翻越異常邏輯的大山，從性能角度設(shè)計(jì)產(chǎn)品，是產(chǎn)品經(jīng)理進(jìn)階的又一指標(biāo)。

作者分別從數(shù)據(jù)加載、信息的篩選跨度、圖片處理三個(gè)方面總結(jié)，希望可以拋磚引玉。

關(guān)于數(shù)據(jù)加載其實(shí)是一個(gè)很大的話題，不僅涉及產(chǎn)品的性能，還影響用戶的使用體驗(yàn)。我在這里只是蜻蜓點(diǎn)水，想要突出對產(chǎn)品性能的重視。

這個(gè)問題主要在數(shù)據(jù)列表等相關(guān)的信息流模塊，如果沒有做數(shù)據(jù)加載條數(shù)的限制，一個(gè)經(jīng)驗(yàn)不足的開發(fā)童鞋很可能一下子請求所有的歷史數(shù)據(jù)，結(jié)果可以預(yù)見：輕則加載緩慢，嚴(yán)重的話直接導(dǎo)致應(yīng)用崩潰。

對于信息流頁面的數(shù)據(jù)加載，一般都會(huì)限制單次加載10-20條。

與此相關(guān)的另一個(gè)問題就是：數(shù)據(jù)篩選的請求限制。像支付寶這樣大體量的產(chǎn)品，在篩選賬單的時(shí)候，也僅僅支持查找6個(gè)月跨度的賬單。

圖片是影響產(chǎn)品性能的又一大因素，在前端上傳圖片注意做圖片大小的限制，即使上傳之后技術(shù)也要做壓縮處理。圖片的壓縮分為分辨率的壓縮和大小的壓縮，根據(jù)業(yè)務(wù)需求，如果需要展示縮略圖，要在服務(wù)端自主生成。

五、寫在最后

說了這么多，作者并沒有誤導(dǎo)大家把產(chǎn)品重心向測試的角度偏移，畢竟產(chǎn)品還有很多重要的事要做。

一個(gè)好的產(chǎn)品經(jīng)理既不能技術(shù)化，也不能業(yè)務(wù)化，掌握好工作中的「度」，做好「中庸的」連接者。

當(dāng)然，懂測試，能從測試的角度設(shè)計(jì)產(chǎn)品只是優(yōu)秀產(chǎn)品的一個(gè)方面。產(chǎn)品經(jīng)理這個(gè)崗位之所以吸引人正是因?yàn)樗亩ㄎ徊幻鞔_，它的「難」與「坑」我想也是這個(gè)原因。

持續(xù)不斷的學(xué)習(xí)，時(shí)刻都在拓寬自己的邊界。懂技術(shù)、懂心理、懂設(shè)計(jì)、懂運(yùn)營才能更好的連接。

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

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