每一次的功能更新,産品經理總會期待獲得用戶的肯定。這就要求在每一個新功能上線之前,産品經理需要做好規劃。本文作者以OA系統新功能規劃為例,對功能叠代的需要注意的關鍵步驟和問題進行了總結~
“Hi,我想在把這個功能放在OA上,能實現嗎?”每次聽到這句話,都會夾雜着又害怕又期待的複雜情緒。你不知道同事們可能提出什麼五花八門的想法,而每一個新需求,是他們對你的認可和期待,也是對自己的挑戰。
做OA産品快1年,是時候對自己進行複盤,那麼就來聊聊,筆者是如何規劃OA的新功能的吧。
一、熟悉業務,了解需求OA上的功能,筆者個人習慣分成2種。
一是功能使用對象為特定人群,比如具體出勤統計,使用對象為考勤專員,由人為統計每個月的出勤情況轉為OA自動統計。
二是涉及到多種角色的功能,比如招聘管理,這裡面涉及到的主要人員有用人部門、招聘hr、面試官、高層,每個角色在這個業務裡均有不同程度的參與。
與所有産品規劃一樣,OA第一步也是熟悉業務,了解業務的前因後果與症結,才知道要如何下手。筆者最常用的是以下2個方式。
1. 參考競品
拿招聘管理舉例,筆者在開始時按照自己的了解,羅列了招聘的流程,初步規劃了功能結構,但畢竟自己的角度是單一的,在沒接觸過招聘行業的情況下,視線非常局限。
參考市面上已經商業化的産品是一個很好的方式,找到頭部産品,去分析他們的功能結構、使用場景,可以讓自己更全面的了解業務。能夠商業化的産品,是經過市場考驗的較為成熟的,頭部之所以能站在頂端,也必然有其優勢。
同樣,善用搜索,可以通過一些平台找到競品的評價,進一步确認用戶的關注點。
2. 用戶訪談
如果把規劃需求比為做菜,那麼參考競品就是知道别人的菜譜;而做内部OA系統就是把這道菜做的符合自己的口味,需要去掉自己不喜歡的食材,對自己的口味進行配比。
還有什麼比面對面聊天更能了解用戶需求呢?直接找對應人員聊呀!
大家都想通過系統取代繁瑣的工作,提高效率,且OA使用頻率高,功能設計會直接影響到自己的日常使用體驗,所以同事們對于訪談都比較積極。對方沒有時間的話,多約幾次總能約到的!
B端功能的角色分類較為分明,比如前述招聘管理中的幾個角色。所以最好各個角色都找代表進行訪談。
二、功能設計
1. 畫流程圖、思維導圖
把業務以流程圖的形式畫出來,羅列每個流程對應的角色和功能。這樣能夠幫助自己捋順邏輯,并且在設計具體原型時不會歪掉重心,不遺漏功能。後續跟需求方、開發過需求時,也可以協助講解,讓聽衆更好理解原型設計。
2. 思考角色的關注點、功能的排部
在完成前一步後,要做什麼功能、功能之間的跳轉邏輯心裡已經有數了,現在是功能如何排部的問題。
這裡可以從角色、從場景出發。
還是拿招聘模塊舉例,這裡面涉及了那麼多角色,每個角色的關注點并不一緻。hr關注整個流程,而面試官很可能隻負責面試考察候選人的水平,他關注的是今天我有多少個面試安排,在什麼時間,我要如何規劃今天的工作,至于招聘進度結果如何,面試官并不關心。那麼面試官涉及到的部分,是否可以抽出來做一個突出呢?
OA的目的是提升效率,需要讓不同角色更輕松的看到自己關注的部分。
3. 确定具體細節
到這裡,産品原型的設計已經大緻成型了,但是細節不能被忽視,以下方面的問題需要過一遍:
1)考慮不同角色的操作權限和數據查看範圍,是否需要做對應的權限規劃,權限規劃是否變更,上線後要如何進行維護;
2)考慮功能、數據之間的關聯。B端産品功能之間更加環環相扣,說幾個常見的情況:A數據同時用在多個地方,影響着多個功能;B數據變化了會影響C數據的變化;D操作完成後要觸發定時任務E。大模塊内的數據關系容易記住,模塊與模塊之間的關聯也不要遺漏;
3)考慮特殊情況。使用人數多了,總會有特殊情況,在B端産品,特殊情況更多是邊界情況,會導緻流程無法繼續進行,而不是體驗不佳可以适當兼容。所有能想到的問題,不要帶着“大家正常不會這樣做”的态度去無視,必須想好對應的處理方案,這部分可能還會需要跟需求部門一定讨論特殊情況的處理規則。
三、上線後的跟進、叠代
發布上線後,除常規的功能叠代、體驗優化外,筆者還會特别關注以下2個方面:
1. 數據、狀态是否正常
B端産品存儲了大量的業務信息,數據、狀态無誤是OA正常運行的基礎,有些問題在測試時并不能完全發現。
2. 未考慮到的情況并及時回複處理
産品規劃時需要盡可能考慮到各種情況,然所有的考慮都是基于已有的經驗,上線後也許會遇到新的問題,這需要pm和開發能夠及時應對處理。
以上,就是筆者當前規劃OA功能的大緻流程。總結OA的幾個重點就是數據正确、使用穩定、提高效率。有任何意見和想法,都歡迎進行交流~
本文由 @希音 原創發布于人人都是産品經理。未經許可,禁止轉載
題圖來自Unsplash,基于CC0協議
,更多精彩资讯请关注tft每日頭條,我们将持续为您更新最新资讯!