如圖所示,你看到的只是那1%甚至更少,只有不斷的挖掘才能知道的更多前端
本次系統在迭代的時候,進入UAT階段,由用戶驗收功能的時候,用戶使用bug提交系統提交了一個bug,開發人員直接轉給了我,我一看,這哪是bug呀,這是需求,因而趕忙電話確認,聊了半天,最後發現咱們的問題是,業務人員覺得這個功能是理所固然必然會有的,故未在需求上進行確認和指出,最後這個功能因爲缺失,上線後也沒法正常使用,得呢,得再繼續優化並再繼續完善post
回首望去,相似的案例有不少,幾乎每次都是相同的狀況,業務老是說「我覺得這個是確定有的,這麼簡單的啊,還要提需求啊?」,「這個不是標準配置嗎?沒有這個功能我提這個需求幹嗎呢?」測試
而我老是解釋或爭辯說,「不是,咱們聊需求的時候不是這樣說的」,「沒有,你沒有提就是新需求,最差也是個需求變動,若是是變動,就得日後排」優化
尤爲是在系統尚未上線,在0到1的孵化過程當中的時候,這樣的案例比比皆是spa
我心力憔悴,他們心有怨言設計
如今看來,需求是沒有作完的一天,全部的需求,都得分輕重緩急,而不一樣的角度,不一樣的角色,輕重緩急的看待又是不同3d
受時間,資源限制,不可能對一個需求完徹底全,透透徹徹瞭解清楚後,再開始進行開發,那樣,每一個需求可能對系統的改造都是推翻歷來blog
因此我如今的作法是,在需求範圍肯定後圖片
一、先嚼一遍需求資源
對每一個需求先從產品的思惟角度,對系統的影響程度,要修改的範圍,要測試的點有個大概的度的把握。
再本身提問題給本身,爲何要這個需求,需求的出發點是什麼,有沒有更好的解決方案,對歷史數據是否有影響等等,儘量的問倒本身並記錄下本身的問題和答案
經過大體的梳理後,會對這一版的需求有個大體的瞭解,整個過程不會很長,快則1至2個小時,慢則半天,期間可能還會和研發或測試的同窗進行溝通,前端怎麼實現簡單又美觀,後臺現有數據是否知足,測試的邏輯梳理是否有漏洞。
整個流程梳理下來,研發主管及測試內心會有一個大概的底,而且在此過程當中會給不少的建議和意見
二、和業務部門進行詳聊
每次詳聊,咱們的業務同事已經知道個人套路,先問爲何要提出整個需求,需求的目的是什麼,要解決的痛點是什麼,大家但願的流程是什麼樣,再他們描述的過程當中,我也會逐步的拋出我理需求時候遇到的問題,給出個人解決方案徵求他們的意見
之前是我單打獨鬥,如今整個team人員較爲充足,我會拉上咱們的開發,研發主管一塊兒旁聽,從他們的角度去分析需求對系統的影響和提出他們的疑問
整個過程耗時會比較長,至少是3個小時左右的一個用戶訪談時間
三、整理文檔
和用戶訪談結束後,我會用最快的速度,整理出需求文檔,從需求目的,需求邏輯,和需求實現3個層面去描述需求
需求目的主要是回答爲何要這樣作,這樣作的好處,解決的問題等等一些比較寬泛的問題
需求邏輯主要是梳理整個需求的邏輯,對數據的修改的點,對歷史數據的處理,須要測試的點,在這模塊會羅列出不少邏輯性的文字,做爲業務方需求確認的重要信息,以及開發人員,測試人員的開發和測試的出發點
需求實現主要是從圖片上展現系統頁面如何實現需求,有哪些按鈕,有哪些列,有哪些字段展現,此做爲和業務部門確認界面,開發同事照此研發
四、需求總結
文檔整理後,會再花點時間和業務部門進行再次確認,確認文檔中的邏輯內容無誤,確認界面上展現的字段無誤,也可能經歷屢次修改。帶你們確認後,會進行歸檔,歸檔後,無大的邏輯變動的狀況下,再也不接受業務方的變動。咱們會找時間再給研發的同事進行需求的具體講解
其實需求的整理還有不少步驟,以上4步,是我經歷過太多帶血帶肉撕裂的痛慢慢領悟總結出來並如今正在實施的一套方案
在產品的路上,我仍是個小學生,還在不停的摸索,求學
望將來,更進一步