為什麼團隊交付時,需要功能清單

編輯導語:在產品設計流程中,雖然我們在需求評審環節就已經將具體的功能要求解釋給技術和團隊,但後續驗收時,技術並不是一定按照我們的想法來設計——畢竟雙方的溝通是有差異的。 這種情況下,如何避免雙方理解不一致的問題?提交功能清單,或許是一個比較好的解決辦法。

為什麼團隊交付時,需要功能清單

當產品經理依照功能結構製作原型時,要求是一個管理員列表頁,我們會想到什麼呢?

首先要在頁面展示管理員表格,有相應的增刪改查操作;

其次,需要針對表格字段設置相應的搜索入口,方便數據查找。

這樣看來,該頁面的功能已經完成,如圖所示。

為什麼團隊交付時,需要功能清單

在團隊驗收項目之後,可交付成果被提供給客户,這時客户方發現某一搜索入口存在問題:當用户輸入管理員姓名想要搜索數據時,只記得管理員姓什麼,這時輸入姓氏,結果卻顯示為空。

於是客户提出bug修改意見,開發檢查代碼後發現,是因為該搜索入口設置的是精準搜索導致,這給產品帶來了不好的使用感,也降低了客户的滿意值,最後功能遭到返工。

項目覆盤時,團隊成員針對這類情況進行討論,發現存在這種情況的原因是,在產品設計階段,產品經理並未對這一點的設計進行標註。可能是主觀認為該功能點一定是前後模糊搜索,又或是落下了對這一細節設計的思考。

結果就是開發未接收到產品經理的想法,開發過程中根據自己的理解做成精準搜索,最後導致客户搜索不到數據。

而且就算開發想到了用設置模糊搜索,那麼模糊搜索還分前後模糊搜索、前模糊搜索、後模糊搜索,1/2的比例猜對後,該功能點還有2/3的比例可能被返工,一來二去項目效率就被降低。

這時如果有一份可以將功能細節明確,規範記錄的功能清單,將搜索框的配置要求進行標註,記錄邏輯功能設計要求,就顯得格外重要。看到這裏你也許會問,功能清單是什麼?在這之前不是已經有功能結構圖了嗎?

一、什麼是功能清單

功能清單也可以叫需求清單、功能列表,是一種將項目功能需求通過文字的形式記錄,方便團隊成員查看的交付性質的文檔。

相比於通過使用思維導圖整理的功能結構來説,功能清單主要以excel的形式存在,涵蓋功能模塊、功能點、功能描述等多個維護字段,其交付質量越低,開發時間就會產生越多損耗。

比如註冊頁面存在上傳文檔的功能,產品經理調研後認為文件上傳需要支持jpg、pdf、png、tif格式,並且字段必填,將功能清單交付開發後,開發可以對這一功能的細節需求清晰明瞭,降低不必要的返工率。

為什麼團隊交付時,需要功能清單
二、功能清單的優點

功能清單的存在,在開發期間為項目維護帶來了些許便利,主要體現在以下幾點:

1. 提高開發效率

開發過程中,如果只參考原型製作,當遇到一些未進行明確標註的設計,比如搜索入口的配置。

看起來精確搜索和模糊搜索都可以將內容搜索出來,但實際上,精準搜索顯示的內容數量較少,甚至可能出現搜索結果為空的情況。

這樣的功能設計一旦錯誤,就可能會對產品產生不好影響,需要開發二次修改。如此反覆修改代碼,調整項目邏輯,開發效率就會被大大降低。

當遇到此類原型上不易表達的內容時,如果存在功能清單作為標準,將這些設計要求通過文字的方式記錄;

如:這個搜索入口要求設置模糊搜索,即可讓開發清晰的瞭解到某個功能點的細節要求,降低返工率,增強工作效率。

設計過程中遇到的細節功能點,可以思考調研後,通過功能清單進行記錄,供開發及其他團隊成員查看,提升工作效率。也方便後期檢查功能是否做錯,是否對產品的使用產生不好體驗感,使得開發期間功能不遺漏、無錯誤,不影響產品使用。

2. 釋放產品經理的時間

項目開發期間,當開發編寫程序,遇到一些細節問題,比如一個搜索入口的搜索配置,可能需要去詢問產品經理具體的設計思路。這時如果沒有功能清單,產品經理自己可能也會忘了調研某一細節,或者沒有記錄調研結果,忘記了當時的思考內容。

就需要再次結合設計情況,思考該功能點的需求,然後告知開發,工作時間被無必要的增加雙倍甚至更多。而且沒有一個規範的記錄,很可能每次的思考會被他人的話術所幹擾,造成每次的思考結果不一致,對產品的使用造成了不好的影響。

但如果在設計初期就將這些細節記錄呢?當有開發經理詢問時,產品經理可以直接將文檔交付開發,解決後期還會存在詢問其他細節的可能;並且在設計期有文檔進行了細節記錄,也可以防止產品經理自身漏掉對一些細節功能的思考。

所以,產品經理需要對產品設計需求進行管理,也就是編寫功能清單。

與注重視覺交互體驗的原型相比,功能清單重點在於補全原型、細節設計。

編寫功能清單,將字符長度、排序規則等不易在原型顯示的內容通過功能清單記錄,使得功能設計規範,不出錯;也方便自己與他人查看,釋放更多時間去做別的事情。

3. 保障團隊氛圍

團隊氛圍很容易便能展現這個團隊是否有凝聚力,大家都希望自己所在的工作環境輕鬆而愉快,但這種氛圍很容易被打破。

當項目交付後,發現本應該模糊搜索的功能做成了精確搜索,使得搜索內容不全面,影響產品使用,就需要產品經理去和開發溝通,安排返工。

開發可能會不願意,已經做好的功能不願意因為一些小細節去二次修改,但產品經理不是不講道理的人,如果是一些能夠接受的,不影響使用,但與產品經理設計初衷不一致的功能,其實並不會返工。返工的往往是那些,對產品有不好影響的功能。

這時一份記錄全面的功能清單便可降低此類情況的發生概率,通過功能清單,將細節記錄,比如列表頁面的搜索入口全部設置為模糊搜索,這一記錄的內容就是該功能的設計標準。

開發期間,一切除特殊情況,都按照標準來製作,避免一些沒必要的討論,也節省大家的時間。

對於團隊來説,溝通是在所難免的,適度的溝通有助於團隊內成員之間的交流,改善了團隊成員信息不對稱的問題。

功能清單就擔當起了部分的溝通作用,將可能存在的問題點提前思考並標註,如若再出現問題,需要有人出面承擔相應責任時,直接拿清單進行對比,避免了一些沒必要的衝突,團隊氛圍得以維護。

作者:桃浪;公眾號:桃浪產品日記

本文由 @桃浪 原創發佈於人人都是產品經理。未經許可,禁止轉載

題圖來自Unsplash,基於CC0協議

版權聲明:本文源自 網絡, 於,由 楠木軒 整理發佈,共 2424 字。

轉載請註明: 為什麼團隊交付時,需要功能清單 - 楠木軒