産品經理在項目開發中扮演的是一個連接者的角色,連接的前提是要熟悉連接對象即兼容對方,善于從對方的角度思考問題。本文将從測試的角度來總結分析産品設計,以此來提升産品設計全面性。
在蘇傑大神的博客文章中有這樣一個觀點:
産品新人如何快速上手的方法之一是寫測試用例。
測試用例是從測試的視角寫的産品描述。測試與産品的邏輯不同,産品抓大放小,測試就是要想清楚各種邊邊角角。
所以,如果團隊正好沒有TC,你來寫一遍,保證對産品的各種細節都很熟悉,也會知道背後用的技術,因為各種限制而造成的各種坑。
一、關于軟件測試
- 從測試方法來分:軟件測試分為黑盒測試、白盒測試、灰盒測試、靜态測試、動态測試、手工測試、自動化測試。
- 從測試階段來分:軟件測試分為需求測試、單元測試、集成測試、系統測試、驗收測試。
黑盒測試也叫功能性測試,在軟件測試過程中大多采用此方式。我所說的産品經理懂測試,針對的即是功能性測試,從功能性的角度做産品的需求文檔,遍曆盡可能多的功能場景。一定不能讓開發和測試找到你的漏洞,那将是産品經理最尴尬的時刻。
有數據表示:
在許多失敗的項目中,70%~85%的返工是由于需求方面的錯誤導緻的。
二、限制邊界值
如果沒有限制輸入框的長度,專業的測試分分鐘可以把開發認為沒問題的程序搞挂。
因此對輸入框的長度限制,是一個産品最底層的功能,我想這也是産品經理的基本素養。進一步的要求是對可輸入字符類型的限制,此項不至于影響到功能,但屬于産品最基本的友好性需求。
下圖是作者好不容易找的一個反面例子:
數值「0」是開發容易忽視的邊界值,在很多場景中0值其實是沒有意義的,比如金額為0元、數量為0等。自己的親身經曆:之前做過一個資金分配的功能,由于PRD沒有說明字段的規則(以為開發小哥哥用腳想想都會明白),然而在做功能驗收的時候,我成功給好友分配了0元。。。
對于這些字段的規則,其實沒有必要在文檔上一一标注,因為很多頁面的字段其實是重複的,這個方法也很容易漏掉一部分字段。一個很好的工作方法是:在全局規範中建立字段規則表。這個方法讓我想起了:大學編程的時候,會統一将全局變量的定義集中放置。
作者抛出一個輸入框對空格的處理的測試用例供大家思考:
- 前面存在空格
- 後面存在空格
- 前後都存在空格
- 中間存在空格
二、遍曆異常邏輯
正常流程隻有一個,異常流程卻異常的多。在很多PM的PRD中,僅僅陳列了正常的業務流程。
很少有開發是會替産品考慮異常邏輯的,所以為了不給自己挖坑,在寫PRD的時候,就要将所有的異常流程都描述清楚,我想在需求評審的時候會更容易通過,也會在開發的眼裡樹立權威。
有人說,無反饋是産品大忌。我想說,反饋不完全也是産品不專業的體現。對于特定事件的反饋,既然有成功的結果,必然會存在對立面——失敗。對于這些事件的總結其實很容易找到規律,很多優秀的PM都會整理一份交互設計自查表,然後會不斷的更新疊代。
善于總結是一個優秀學習者的必要品質,在項目經曆中總結積累遇到的異常情況。有句話這樣說:
“你現在經曆的每一件事,都會在未來某一時刻用上”。
登錄注冊可能是大多數PM童鞋的處女級産品功能,根據我個人的經驗:如果沒有從零到一将這個需求落地,一定是存在認知漏洞的。
我說一個場景,看大家有沒有考慮到:手機号驗證碼輸入框在同一個頁面,在手機号無誤、驗證碼輸入正确的情況下,然後更改手機号(手機号格式合法),提交之後應該如何反饋?
三、關聯性的問題
在項目中,大多數功能模塊往往不是獨立的,一般存在交集或者需要進行模塊間的數據交互。因此一個模塊如果發生了需求變更或者數據丢失,就會影響到相關聯的功能模塊。
曾經做過一個項目,由于平台新增了直營店功能,之前設計的訂單詳情就不适用了,需要融合新需求,财務管理模塊也要做字段的擴展。
關聯信息不允許删除,比如商品類别,假如商品類别是商品的必要屬性,此時就應該禁止正使用的類别被删除。還有一個很重要的關聯性問題是,正在生效的規則是不能被删除。
四 、性能的問題
性能無止境,性能的優化伴随着産品的整個生命周期。測試過程,性能測試處于功能測試之後,也就是說功能大于性能。翻越異常邏輯的大山,從性能角度設計産品,是産品經理進階的又一指标。
作者分别從數據加載、信息的篩選跨度、圖片處理三個方面總結,希望可以抛磚引玉。
關于數據加載其實是一個很大的話題,不僅涉及産品的性能,還影響用戶的使用體驗。我在這裡隻是蜻蜓點水,想要突出對産品性能的重視。
這個問題主要在數據列表等相關的信息流模塊,如果沒有做數據加載條數的限制,一個經驗不足的開發童鞋很可能一下子請求所有的曆史數據,結果可以預見:輕則加載緩慢,嚴重的話直接導緻應用崩潰。
對于信息流頁面的數據加載,一般都會限制單次加載10-20條。
與此相關的另一個問題就是:數據篩選的請求限制。像支付寶這樣大體量的産品,在篩選賬單的時候,也僅僅支持查找6個月跨度的賬單。
圖片是影響産品性能的又一大因素,在前端上傳圖片注意做圖片大小的限制,即使上傳之後技術也要做壓縮處理。圖片的壓縮分為分辨率的壓縮和大小的壓縮,根據業務需求,如果需要展示縮略圖,要在服務端自主生成。
五、寫在最後
說了這麼多,作者并沒有誤導大家把産品重心向測試的角度偏移,畢竟産品還有很多重要的事要做。
一個好的産品經理既不能技術化,也不能業務化,掌握好工作中的「度」,做好「中庸的」連接者。
當然,懂測試,能從測試的角度設計産品隻是優秀産品的一個方面。産品經理這個崗位之所以吸引人正是因為它的定位不明确,它的「難」與「坑」我想也是這個原因。
持續不斷的學習,時刻都在拓寬自己的邊界。懂技術、懂心理、懂設計、懂運營才能更好的連接。
本文由 @ 産品範 原創發布于人人都是産品經理。未經許可,禁止轉載。
題圖來自unsplash,基于CC0協議
,更多精彩资讯请关注tft每日頭條,我们将持续为您更新最新资讯!