有時候很小的產(chǎn)品需求，在做決策時需要的時間卻很多，因為其中可能需要涉及到許多決策因素。這類情況下，怎么給出解決方案呢？不妨來看看本文的實戰(zhàn)案例分析。

為什么很小的產(chǎn)品需求，有時候也會耗費很長的時間？一個很重要的原因，就是做決策所需要的時間較多。

最終做決策前，需要事先了解清楚背景、約束條件、用戶、場景等各種因素，一旦在某一處遇到卡點問題，這個需求實現(xiàn)的戰(zhàn)線就會被大大拉長。

本次復盤的這個小需求，就涉及到了用戶角色、技術(shù)實現(xiàn)等方面的決策因素。

一、需求背景

資源上線時需要對比本次上線版本和線上版本的部分代碼配置，標識出具體diff（不同），供開發(fā)人員查驗確認。避免在上線后，因為有不符合要求的diff，導致線上出現(xiàn)問題。

二、具體做了什么？

因為自己開發(fā)diff對比功能的成本較高，所以我們的開發(fā)人員選擇在現(xiàn)成的代碼對比組件上進行修改，來實現(xiàn)產(chǎn)品需求，并成功上線。

三、遇到了什么問題？

需求上線后，未參與開發(fā)的另一位后端同事，發(fā)現(xiàn)了一個被其稱為“不符合直覺”的問題。

原來，在大多數(shù)代碼diff對比時，都是左側(cè)為舊版本，右側(cè)為新版本，就像下面這張示例圖一樣。

但是在我編寫的prd中，版本正好反了過來，左側(cè)是新版本，右側(cè)是舊版本。

而且后來發(fā)現(xiàn)，在技術(shù)實現(xiàn)時，只是代碼版本反了過來，上圖中所示的顏色、??號的標識邏輯還是原來常用的左側(cè)舊，右側(cè)新。

這就導致diff對比是有了，但是既不符合開發(fā)人員的瀏覽習慣，顏色和加減號的標識也不太正確。

需求目的雖然就是能夠看到哪里有diff就行，但是實現(xiàn)的并不好。

四、為什么會出現(xiàn)問題？

事后我自己總結(jié)，我認為出現(xiàn)這些問題的原因有以下2個：

1. 因為并不具備程序員的視角，所以在設(shè)計原型時，僅僅是站在了產(chǎn)品或者是已有業(yè)務邏輯的視角上，自然的認為左側(cè)是新的代碼版本，右側(cè)是舊的代碼版本。
2. 對于技術(shù)實現(xiàn)方案缺乏足夠深的了解，且在產(chǎn)品走查時忽略了版本對比中，具體加減號標識的邏輯問題。

五、如何解決的？

在接收到問題反饋后，我做了以下思考。

1. 這個問題要不要改，怎么改？

不改的話，其實也能知曉新舊版本的diff情況，并沒有什么實質(zhì)性大的影響。

改的話，是讓前端把顏色和加減號的標識，改成符合現(xiàn)在“左側(cè)新右側(cè)舊”的邏輯，還是直接把代碼版本改成符合程序員直覺的“左側(cè)舊右側(cè)新”？

2. 誰來查看diff？

必然是開發(fā)人員了，在上線時，業(yè)務和產(chǎn)品經(jīng)理一般也不會關(guān)注代碼配置的差異情況，所以從這個角度上來說，版本對比的功能，還是要符合開發(fā)人員的閱讀習慣，也就是后端同事說的，要符合開發(fā)人員的直覺。

3. 修復成本多高？

在和開發(fā)同事溝通后，如果想要把代碼配置改成符合直覺的左側(cè)舊版本，右側(cè)新版本，只需要左右兩側(cè)重新取數(shù)就行，修改成本很低。

而要修改顏色和加減號的標識邏輯，需要重新調(diào)研組件中是否可以修改，成本較高，且還不一定能改。

綜合考慮后，還是決定讓開發(fā)同事直接將代碼配置，改成符合直覺的左側(cè)舊版本，右側(cè)新版本。

六、如何改進？

1. 加深對技術(shù)的了解，起碼要知道技術(shù)實現(xiàn)的邏輯，讓自己能夠多視角的思考問題；
2. 產(chǎn)品開發(fā)完成后走查時，要更加細致和全面，不僅要看是否實現(xiàn)了需求，還要看需求實現(xiàn)的方式和效果，以及對整體全局的影響，比如是否會因為一個功能的上線，影響其他功能。