復盤:從事G端產品的這一個月
從接觸G端產品到現在剛好1個月的時間,在這段時間主要的工作內容是學習。學習甲方提供的資料,提煉業務以及業務需求,跟隨業務專家學習如何政務部門的業務進行初步的業務調研(以下簡稱“初調”)。這篇文章主要是講的是筆者對這一個月的工作的一個復盤。
研讀資料
資料不多就一個需求文檔,文檔內容很豐富,包含有:各業務模塊的業務說明,辦理該業務的業務流程圖(沒有按照角色繪制的泳道圖),子系統功能需求說明。
仔細的研讀資料后,有一下幾點是可以確定的:
- 業務明確,總共有十幾個業務模塊,每個業務模塊的業務都有說明,業務邊界也挺清晰的,因為涉及到的業務相差還是挺大的,邊界區分很清楚。
- 業務流程明確,雖然還未細化到角色上,但是也知道到每項業務需要經過幾步,每一步需要做什么。
- 組織架構相對明確,之所以說是相對明確,是因為還沒有細化到科室中的人員角色上,只是有一個大的組織結構。具體的每個業務部門有哪些角色還需要通過調研才知道。
不確定的點也有很多,簡要羅列一些:
- 業務模塊比較清楚了,還需要細化,細化可供角色參與的程度;
- 細化到科室角色的完整組織架構,以及對應角色的業務;
- 泳道流程圖,由哪些角色分先后完成哪一步,然后最終把業務完成;
- 文檔是由一個人寫的,他的描述是否與真實的用戶一致呢:
- 文檔的需求他們是否與真正的業務員調研過,這個沒法確定;
- 領導的想法是怎么樣,是否有遺漏;
- ……
初調
1. 初調需要達到的目標
- 真實需求:深入一線業務員,面對面溝通需求,真實體驗他們的工作場景,了解他們的真實需求;
- 組織架構:通過初調完成完整的組織架構圖,細化到一線業務員角色;
- 角色流程圖:通過初調要摸清他們的在業務模塊中是在第幾個步驟,扮演的時什么角色,做什么樣的操作;
- 現狀:他們是否有現成的系統支撐他們的業務,如果有,調研清楚他們的使用情況,如果條件允許還可以直接上手操作體驗一下,拍照回來詳細分析,也需要調研清楚他們對現有系統的不滿意的地方是哪些,回頭加以分析,避免我們自己設計的踩同樣的坑;
- 集成系統:政務產品,涉及的業務非常廣,涉及的科室也很多,因此經常會有某個業務部門會有自己的業務支撐系統,而且還是運行的比較好,使用體驗都很好的那種。在這種情況下,就不需要再開發一個系統來支撐業務了,只需要集成到平臺。這樣的情況下,初調的時候需要了解清楚現有系統的情況,需要做哪些數據的接入準備等;
- 工作場景:我們平常接觸到的政務部門有些是在大廳窗口,有些是由獨立辦公室,有些是在大辦公室,有些又是在室外工作,不同的工作場景會影響用戶的操作體驗;
- 領導的想法:政務產品領導的想法特別重要,直接影響產品最終的驗收。
2. 初調的方式
我們初調的方式很原始很粗狂,其實就是業務專家直接帶我們就去了要調研的科室,然后就采用疑問——回答的方式進行溝通,將疑惑點記錄下來。也許是因為我不懂業務,始終認為這些專家提問很隨意,沒有邏輯先后,然后提的問題有時候感覺不是平臺建設需要的問題。
總結:沒有調研大綱,提問沒有邏輯現有,想到什么說什么。
建議:
- 在還未進行調研之前,應業務以及科室兩條線分開了解詳情。從業務上要知道總體涉及到哪些業務,各業務劃分到哪些科室。從科室角度出發,各科室涉及哪些業務(至于科室具體負責業務的哪一個環節需要通過調研落實)。
- 進行業務調研之前應該編寫調研大綱,將系統建設過程中可能涉及到的點以及針對需求文檔不清楚的地方按照一定的邏輯順序寫清楚,并打印出來。做到有針對性的提問,而不是憑經驗無邏輯現有的提問。這樣也會避免漏掉一些關鍵問題。
3. 調研文檔整理
從調研達到的目標來反推一下,調研文檔應該包含哪些內容。
- 調研基本信息交代:時間、調研對象、調研業務主體、參與調研的人員;
- 需求梳理:按照業務的流程的先后順序梳理出調研對象參與的是哪一個環節的業務,信息系統解決的哪項業務需求;他們對信息信息系統的交互需求有哪些;
- 流程梳理:完整的泳道角色流程圖;
- 現狀:現在是否有信息系統支撐業務;使用情況;對現有系統不滿意的地方;
- 新需求:在需求文檔中未提及的需求;
- 解決方案:針對業務需求和新需求,我們標準化產品是否有相應的解決方案;針對差異點(與現有系統匹配度不高)的改造方案;新需求(現有產品沒有與之匹配的功能)的解決方案;
- 風險點:針對差異點,新需求的風險在那里,需要向領導交代清楚,方便領導與甲方談判。
本文由@啤酒配咖啡 原創發布于人人都是產品經理,未經許可,禁止轉載
題圖來自Unspalsh, 基于CC0協議
評論
評論請登錄
太有用了
您好,可以和您請教一些問題嗎?