拒絕“開發腦”

1 背景

工作這幾年觀察到一個非常有意思的現象：有些開發會深陷開發思維。

案例1：純資料思維：

産品讓你做一個導出功能，其中有一項是性别字段字段，資料庫存的是0表示女，存1表示男，有些同學導出 excel 時，直接講值導出為 0 和 1 ，😳......

案例2：已删除問題：

團隊中有些同學負責維護員工資訊、群資訊和部門資訊等，員工、群、部門有可能被删除，那麼對他們而言，删除之後查詢就查不到了。

但是設想一下，對于商家而言，建立一個活動時選擇了 5個員工，有些員工被删除之後，再檢視之前的某個活動時，隻有1個員工了或者1個員工都沒有了，作何感想？

或許我們可以做降級，如果查不到員工或群，可以降級為[該員工已删除]、[群已解散] 等字樣，如果一個活動出現多個 [該員工已删除]、[該群已解散] 這種是不是也很崩潰呢？

案例3：快照問題：

比如你在做電商平台，使用者下單之後産生了争議，如商品的功能和描述不符，并提供了截圖，如果提起申訴之前商家删除了商品或者修改了商品描述，不認賬，那該如何是好？

案例4：深翻頁問題

比如團隊做一個檢視某個直播的使用者觀看記錄的功能，有些直播可能關鍵人數特别多。

觀看記錄包括：使用者昵稱、觀看開始時間、觀看結束時間、觀看時長、性别、省份等。

産品要求支援跳頁，可以翻到最後一頁，技術上挺難實作怎麼辦？

2 啟示

2.1 使用角度：以終為始/換位思考

我們做某個子產品，想清楚這個功能是給誰用的，如果他用這個功能會有哪些不友善的地方，如果有該怎麼改進？

很多開發，尤其是工作年數不多的開發，很容易将技術視角帶到産品層面，最後的東西很像是資料庫表字段直接映射的管理頁面。

我們要站在使用者視角去看功能，而不僅僅是技術視角去開發功能。

有了這種思維之後

案例1：我們自然地想到需要将 0 和1 轉為對應商家更容易了解的描述。

案例2 的情況我們可以要求底層接口支援查詢已删除的員工、群和部門的接口來更好地滿足業務需求，給使用者提供更好地使用體驗。

案例3： 如果我們沒有思考清楚業務上要解決的問題，商品編輯後隻儲存最新版這種“直線思維”似乎也沒錯。但是遇到糾紛時就很難查證。

我們可以在訂單中存儲商品的版本，商品每次編輯都存儲快照，儲存證據。

即使産品沒有思考到這一點，我們甚至也可以主動去回報。

2.2 業務角度：思考價值

站在業務角度可以思考這個功能對使用者的幫助的程度，該功能的必要性究竟多大。

思考功能的本質是為了滿足使用者什麼樣的要求，權衡投入産出比。

為了滿足 案例4的要求需要付出很大的代價或者現有的公司存儲方案還不支援，可以和産品聊非要做到這麼“極緻”的代價。

翻到最後一頁，無非是為了看觀看時長最長的資料，那麼我們提供排序接口不就可以了嗎？

産品可能會說商品還有檢視所有資料的場景，那麼我們提供資料導出的excel 的功能不就可以了嗎，商家還可以自己通過 excel 進行個性化統計等。

總結

工作越久越發現很多問題不僅僅是技術問題更是産品層面的問題，開發人員不僅要懂技術，還要思考産品的價值和未來發展方向。

懂産品的技術才可以更好地設計好方案來滿足目前需求，應對未來的變化，才能更好地發揮技術的價值。

拓展閱讀

《為什麼技術同學需要有更多的業務思考？》