国外亚洲成av人片在线观看,热99re久久精品这里都是精品,天堂网在线最新版www,国产成人av区一区二区三,51久久成人国产精品麻豆

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

在蘇杰大神的博客文章中有這樣一個觀點：

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

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

所以，如果團隊正好沒有TC，你來寫一遍，保證對產(chǎn)品的各種細節(jié)都很熟悉，也會知道背后用的技術，因為各種限制而造成的各種坑。

一、關于軟件測試

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

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

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

在許多失敗的項目中，70%~85%的返工是由于需求方面的錯誤導致的。

二、限制邊界值

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

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

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

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

對于這些字段的規(guī)則，其實沒有必要在文檔上一一標注，因為很多頁面的字段其實是重復的，這個方法也很容易漏掉一部分字段。一個很好的工作方法是：在全局規(guī)范中建立字段規(guī)則表。這個方法讓我想起了：大學編程的時候，會統(tǒng)一將全局變量的定義集中放置。

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

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

二、遍歷異常邏輯

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

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

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

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

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

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

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

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

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

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

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

四 、性能的問題

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

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

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

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

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

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

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

五、寫在最后

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

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

當然，懂測試，能從測試的角度設計產(chǎn)品只是優(yōu)秀產(chǎn)品的一個方面。產(chǎn)品經(jīng)理這個崗位之所以吸引人正是因為它的定位不明確，它的「難」與「坑」我想也是這個原因。

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

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

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