需求總有漏洞,跟開發過兩三遍才能對完細節,該怎么辦?
遇到“需求寫好,與開發核對細節,但總有漏洞,需要核對兩三遍”這種情況,你是如何應對的?本文就該問題進行探討,一起來看看吧。
群友提問:最近遇到個問題,寫好需求了,總有漏洞,總是跟開發過兩三遍才能把所有的細節對完,大家遇見這種情況多嗎?都是如何自查的。
這題我會。
從我入職現在的公司以來,渡過表現期后,需求有漏洞的問題頻繁爆出,最嚴重的情況在預演環境代碼回滾,以我為主的相干人等寫事故報告。
同事對我的評價:有點粗心,粗心它是個中性詞,再拓展一下就是不拘小節,這種評價有點無關痛癢。
領導對我的評價:不注重細節,不注重細節這個評價就有點挫脊梁骨了。這個點評點到了羞恥心上。
說來也諷刺,工作的前3年我在潛心修煉產品技能,后3年時間里用進廢退。
想了一下,前3年對產品應是存有敬畏之心,后三年不排除油條嫌疑。
我復盤過這個問題,為什么會這樣:
1、技術兜底。團隊關系融洽,跟技術測試私交甚好,需求小修小改基本不是問題,技術同學非常負責,大部分時候產品遺漏的細節他們自己就完善了,比我更注重細節。
再來還有測試把最后一道關口,正常情況下我的環節遺留的細節問題經過兩次嚴篩就被填滿了。
2、懶,自我要求不高。惰性心理,小問題不會出大問題,出了問題也會有人解決。平日工作壓力不大,一個月一個迭代,產品只要在上個迭代開發結束后給出下個版本的內容即可,這也給了我很多投機取巧的機會,我會把工作內容壓到最后時間去做,慢工出細活,趕工的結果可想而知。
3、沒有得到教訓的錯誤不長記性。慣性使然,一旦習慣就很難改變。不失去些什么很難痛徹心扉,況且出現了上線前代碼回滾情況也沒有受到任何懲罰,流程性交了個事故報告這事就結了。
解決這個問題的唯一方法就一個字:查。
在需求有細節漏洞這個問題是有方法可尋的。在我0經驗轉行產品入職第1天被安排獨自負責一個erp系統(無從下手,只想跑路),產品導師傳授給我一個快速上手的方法:拆解->重構,也即找競品進行拆解,然后結合自己的業務進行重構。
需求自查就是上述方法的逆用,需求建好了把它拆掉。拆的過程中遵循三個大方向:拆解業務流程、拆解交互邏輯、切換身份代入。
1. 拆解業務流程
先從業務流拆起,也即先拆框架。拆解業務流的關鍵點一是業務流程是否完整閉環;二是流程是否合乎業務場景;三是異常流程處理機制是否完善。
2. 拆解交互邏輯
拆解完框架業務清晰后就從交互入手,交互其實就是業務的呈現。也是從大到小查起:
一是頁面呈現,信息完成度、優先級、表達是否清晰、少即是多原則;
二是頁面跳轉,跳轉邏輯、最短路徑、操作簡單;
三是細節,組件使用是否準確、按鈕狀態、反饋是否友好、指引是否清晰、概念是否統一、用詞是否專業恰當等。
3. 切換身份代入
需求文檔就是面向產品相關崗位的人,切換身份代入就是從不同的視角去看需求的呈現。
- 用戶:易用性、使用成本;
- 開發:邏輯、開發成本;
- 測試:測試最關注邊界問題、異常情況。
總結
以上只是列出了需求自查時的一些關鍵點,僅做經驗分享,在工作中可以結合自己的實際情況建立需求自查表,并不斷復盤總結進行自查表更新。
之前在星球里看到一位星友分享:如何避免錯誤和怎么面對錯誤。
有一條怎么面對錯誤的觀點在需求自查里也很實用:復盤,吸取教訓。將這次的錯誤獲得的經驗總結下來,形成你的“規則”,避免下次再犯類似的錯誤。
需求自查也是一樣,把那些愛犯的小錯誤、容易漏掉的小細節總結下來,形成需求自查的規則,刻意關注這些規則,會減少犯類似的錯誤。
“刻意練習”是貫穿產品職業生涯的一個詞,產品相關的任何技能都可以通過刻意練習達到。只是在練習的過程中需要對自己足夠坦誠和有足夠的耐心,畢竟寶劍鋒出磨礪出,梅花香自苦寒來。
本文由 @關爾產品舍 原創發布于人人都是產品經理,未經作者許可,禁止轉載。
題圖來自Unsplash,基于CC0協議。
該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。
- 目前還沒評論,等你發揮!