在職場上，你永遠想不到會碰到哪些奇葩的問題，甚至這些問題還很難有現成的答案。比如說，作者碰到的這個沒人敢動手的線上問題，其實有文檔，基本上都不會發生。

從產品感知層見底層資源構建；

從產品設計方案見一代產品經理心路歷程；

就差告訴程式師怎麼寫代碼了！！！

一個沒有人敢動手的線上問題

2023 年 8 月的一個工作日 ，被一個產品（支撐供應鏈採購業務的演算法系統）線上問題鬧得哭笑不得。

五手開發說自己沒有改過，還說看過這裡的代碼邏輯複雜，說程式邏輯存在現狀本就會導致問題。可是，就是不知道問題出在哪裡？（擱誰身上不來氣就算你贏）

消失的產品設計 / 技術文件

懷念一手開發、一手測試，可惜走的走、散的散，就連產品團隊自己也不清楚了。另外一個現狀就是，作為演算法產品，其實有很多邏輯構建 + 數據構建的模型存在，這兩部分從領域劃分上其實要算到開發、技術團隊，但是開發 / 技術團隊向來不喜歡做文檔沉澱的，而這個過程產品團隊沒有同步參與對齊，自然在產品相關的過程文檔中也看不到絲毫的蹤跡。最重要的結果就是，現在已經沒有人能夠說得清楚當時的邏輯到底是什麼，也沒有文檔可以翻出來查看。

看清產品：由表及里，從里至外

無奈作為這個產品的四手產品經理（1.0 版本已經是四五年前的事情了，負責的產品經理換了好幾個），只好從產品的感知層開始（看交互介面的信息結構設計、往下再看結構層的業務邏輯）一層一層往下推測勾勒數據結構，然後和資料庫進行假設驗證（拿到資料庫的查詢許可權，在測試環境驗證上層的邏輯和數據的過程對應），確保推演邏輯沒問題。費老大力氣，終於勾勒出來產品核心物件的大致數據結構和關聯，幾個關鍵對象怎麼構建、更新，自然也就標定出來了問題點物件。

但是面對五手開發，程式師自己對代碼邏輯畢竟不熟悉，結果依然是：不敢動！

好在又翻到歷史一次上線記錄出來，以前不是動過這裡一次嘛！（上一次改動這個地方是這個程式師改的）輕車熟路，再來一次。這下開發有了信心，搞定

為什麼重要的東西不見了？

往往面對上述這種歷史問題，處理過程中是非常依賴到過去的文件的，但正如上文所說，文檔往往也稀釋掉了很多冰山下內容：比如核心物件的核心數據如何構建？比如關聯對象間的數據關聯和更新邏輯？等等。雖然偏技術範疇，但個人認為和產品設計文檔能夠結合在一起的話，對於一個敏捷團隊來說絕對是功在千秋、利在當代。

至於為什麼會出現產品技術文件、設計文件的內容缺失，個人認為有兩個方面可以去嘗試思考：

第一點是個人工作習慣問題，不排除負責某個產品的產品經理和開發者，包括測試大家對所有細節都了然於胸，但是卻沒有人願意去把這些內容用文字、用流程圖，甚至用一個簡單的圖形的方式沉澱記錄下來；在敏捷模式裡面我們說，他們都缺少 owner 意識。

第二點就是作為產品文檔的維護者、設計者可能根本沒有意識到、沒有參與到、或者說沒有思考到當然也不會介入到產品底層的數據和關鍵對象的構建邏輯。這就一定會為未來產品也在維護過程中埋下隱患，造成業務團隊、產品團隊和開發團隊之間的脫節。這種脫節往往會可能直接影響到業務，打破敏捷的這種開發節奏，增加大家的溝通、協作成本，影響到其他專案的一些正常進度。更為可怕的是，打擊產品相關人員的信心，導致沒有人願意或者敢去介入動這個產品，包括未來的升級都小心翼翼，生怕再往“搖搖欲墜”的大樓上再添一塊磚瓦，那麼所有人都會傾向於找到時機，重新投入資源去重構這個產品，可我們明明知道 這無疑就是資源的浪費啊。

————— -（手動分割線）————— -

題外話，往往我們透過文檔，看一份文件的寫作風格、邏輯表述、與關鍵技術實現互為支撐的要求與預留，其實也窺探一二文檔創作者當時的心路歷程，妙不可言。

題圖來自 Pixabay，基於 CC0 協定

該文觀點僅代表作者本人，人人都是產品經理平臺僅提供資訊存儲空間服務