產品問題剖析實例及文檔缺失的思考與應對
在職場上,你永遠想不到會碰到哪些奇葩的問題,甚至這些問題還很難有現成的答案。比如說,作者碰到的這個沒人敢動手的線上問題,其實有文檔,基本上都不會發生。
從產品感知層見底層資源構建;
從產品設計方案見一代產品經理心路歷程;
就差告訴程序員怎么寫代碼了?。?!
一個沒有人敢動手的線上問題
2023年8月的一個工作日 ,被一個產品(支撐供應鏈采購業務的算法系統)線上問題鬧得哭笑不得。
五手開發說自己沒有改過,還說看過這里的代碼邏輯復雜,說程序邏輯存在現狀本就會導致問題??墒牵褪遣恢绬栴}出在哪里?(擱誰身上不來氣就算你贏)
消失的產品設計/技術文檔
懷念一手開發、一手測試,可惜走的走、散的散,就連產品團隊自己也不清楚了。另外一個現狀就是,作為算法產品,其實有很多邏輯構建+數據構建的模型存在,這兩部分從領域劃分上其實要算到開發、技術團隊,但是開發/技術團隊向來不喜歡做文檔沉淀的,而這個過程產品團隊沒有同步參與對齊,自然在產品相關的過程文檔中也看不到絲毫的蹤跡。最重要的結果就是,現在已經沒有人能夠說得清楚當時的邏輯到底是什么,也沒有文檔可以翻出來查看。
看清產品:由表及里,從里至外
無奈作為這個產品的四手產品經理(1.0版本已經是四五年前的事情了,負責的產品經理換了好幾個),只好從產品的感知層開始(看交互界面的信息結構設計、往下再看結構層的業務邏輯)一層一層往下推測勾勒數據結構,然后和數據庫進行假設驗證(拿到數據庫的查詢權限,在測試環境驗證上層的邏輯和數據的過程對應),確保推演邏輯沒問題。費老大力氣,終于勾勒出來產品核心對象的大致數據結構和關聯,幾個關鍵對象怎么構建、更新,自然也就標定出來了問題點對象。
但是面對五手開發,程序員自己對代碼邏輯畢竟不熟悉,結果依然是:不敢動!
好在又翻到歷史一次上線記錄出來,以前不是動過這里一次嘛?。ㄉ弦淮胃膭舆@個地方是這個程序員改的)輕車熟路,再來一次。這下開發有了信心,搞定??
為什么重要的東西不見了?
往往面對上述這種歷史問題,處理過程中是非常依賴到過去的文檔的,但正如上文所說,文檔往往也稀釋掉了很多冰山下內容:比如核心對象的核心數據如何構建?比如關聯對象間的數據關聯和更新邏輯?等等。雖然偏技術范疇,但個人認為和產品設計文檔能夠結合在一起的話,對于一個敏捷團隊來說絕對是功在千秋、利在當代。
至于為什么會出現產品技術文檔、設計文檔的內容缺失,個人認為有兩個方面可以去嘗試思考:
第一點是個人工作習慣問題,不排除負責某個產品的產品經理和開發者,包括測試大家對所有細節都了然于胸,但是卻沒有人愿意去把這些內容用文字、用流程圖,甚至用一個簡單的圖形的方式沉淀記錄下來;在敏捷模式里面我們說,他們都缺少owner意識。
第二點就是作為產品文檔的維護者、設計者可能根本沒有意識到、沒有參與到、或者說沒有思考到當然也不會介入到產品底層的數據和關鍵對象的構建邏輯。這就一定會為未來產品也在維護過程中埋下隱患,造成業務團隊、產品團隊和開發團隊之間的脫節。這種脫節往往會可能直接影響到業務,打破敏捷的這種開發節奏,增加大家的溝通、協作成本,影響到其他項目的一些正常進度。更為可怕的是,打擊產品相關人員的信心,導致沒有人愿意或者敢去介入動這個產品,包括未來的升級都小心翼翼,生怕再往“搖搖欲墜”的大樓上再添一塊磚瓦,那么所有人都會傾向于找到時機,重新投入資源去重構這個產品,可我們明明知道 這無疑就是資源的浪費啊。
—————-(手動分割線)—————-
題外話,往往我們透過文檔,看一份文檔的寫作風格、邏輯表述、與關鍵技術實現互為支撐的要求與預留,其實也窺探一二文檔創作者當時的心路歷程,妙不可言。
本文由 @Kris_3zzz 原創發布于人人都是產品經理。未經作者許可,禁止轉載
題圖來自 Pixabay,基于CC0協議
該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務
- 目前還沒評論,等你發揮!