在本文中，作者主要分享的是在一次版本迭代的時候遇到的一些問題，踩到的一些坑。enjoy~

作為一個今年剛走出校門的產(chǎn)品新人，剛一畢業(yè)我就接手了公司的一條產(chǎn)品線（當(dāng)然，產(chǎn)品的整體架構(gòu)已經(jīng)由產(chǎn)品總監(jiān)搭好）。

我負責(zé)的產(chǎn)品線是一個服務(wù)流程化的系統(tǒng)，主要是用于在銷售完成售后之后，讓服務(wù)人員通過系統(tǒng)流程化的為用戶提供服務(wù)，處理業(yè)務(wù)。這個系統(tǒng)包含兩部分：一部分是內(nèi)部服務(wù)人員使用的工單系統(tǒng)，一部分面向用戶的H5頁面。可以大致歸類為一個TO B的產(chǎn)品。

公司原有的工單系統(tǒng)由于是定位于SAAS系統(tǒng)，希望提供給行業(yè)一個通用的解決方案，然后最終發(fā)現(xiàn)并不能銷售出去。因此我接手這條產(chǎn)品線的第一個大版本就是對整個工單系統(tǒng)進行的重構(gòu)，這個版本從今年四月份開始設(shè)計，到最近終于要準備上線。5個多月期間，我經(jīng)歷了一個完成的產(chǎn)品周期，自己也從單純設(shè)計頁面，漸漸成長為可以慢慢提出自己的一些想法并推動實施的人。

這個版本不出意外的話將于下周上線，產(chǎn)品的基本骨架搭建完成。雖然版本成功上線了，但由于其中走過非常多的彎路，導(dǎo)致開發(fā)與我們產(chǎn)品都是非常的疲憊。因此我稱之為一次“失敗”的迭代。

成功固然可喜，但失敗卻十分寶貴。通過這次失敗，我踩了基本上一個剛?cè)腴T的產(chǎn)品經(jīng)理都會踩的坑。因此。我在此做一次復(fù)盤，希望大家引以為戒。

1. 溝通

作為一個產(chǎn)品經(jīng)理，溝通是一個非常重要與關(guān)鍵的技能。不管是需求的獲取、方案的討論以及最終的執(zhí)行，都極度依賴于產(chǎn)品經(jīng)理的溝通能力。關(guān)于溝通，我將分別用三個產(chǎn)品經(jīng)理工作中最常溝通的角色來依次說明我踩到坑與解決的方法。

1.1 需求方——天坑1：需求傳話筒

作為一個主要面向內(nèi)部用戶的產(chǎn)品，產(chǎn)品主要的需求方就是公司的服務(wù)人員。剛開始我很欣喜的發(fā)現(xiàn)需求方給過來的需求是如此的“明確”，甚至自帶“解決方案”。

相較于普通的TO C產(chǎn)品，一天到晚做用戶調(diào)研，揣摩用戶心理，然后提取需求。這種內(nèi)部產(chǎn)品的需求溝通與獲取看似如此之“簡單”，作為產(chǎn)品經(jīng)理只要畫畫原型，然后推動方案實現(xiàn)就好。

因此一開始我就抱著這種想法，一接到服務(wù)人員的需求，馬上去實現(xiàn)，充分體現(xiàn)了年輕人的“朝氣”與“活力”，直到有一次我踩到了下面的坑：

一次，服務(wù)人員反饋過來說，我們H5頁面的提示不夠詳細，他們每個服務(wù)訂單都需要在微信上跟用戶解釋與提示很多東西，希望能在H5中增加更多的提示語，同時把需求提示的地方，時機與文案都給了過來。

面對如此之“明確”需求，我當(dāng)然是馬上開干，拉著設(shè)計馬上設(shè)計出提示語展現(xiàn)的樣式，然后推動開發(fā)進入開發(fā)。由于只是提示語的修改，沒多久版本就上線了。

一段時間之后，與服務(wù)人員一次無意中的溝通發(fā)現(xiàn)，他們的與客戶微信溝通并沒有因為提示語的上線而減少。

1.2 開發(fā)——天坑2：產(chǎn)品該不該懂技術(shù)

關(guān)于產(chǎn)品該不該懂技術(shù)，不同人有不同的看法，主要分為兩種看法：1.產(chǎn)品經(jīng)理不要懂技術(shù)，過多的思考技術(shù)的實現(xiàn)會局限產(chǎn)品的創(chuàng)意；2.產(chǎn)品經(jīng)理應(yīng)該懂點技術(shù)，這樣設(shè)計的產(chǎn)品不至于飄在空中，不能實現(xiàn)。

在做產(chǎn)品之前，我寫過一段時間的代碼（幾個月的網(wǎng)頁前端），同時由于是產(chǎn)品重構(gòu)，是大版本，作為一個產(chǎn)品新人，我在前期設(shè)計的時候充分發(fā)揮了“不怕苦，不怕累”的精神，兢兢業(yè)業(yè)、勤勤懇懇的設(shè)計完了產(chǎn)品的每一個細節(jié)，恨不得把一天掰成兩天，也因此為了趕時間，我沒有與開發(fā)做任何溝通。

最終到需求評審會議上，見識了一回什么叫刀光劍影:當(dāng)我講解完我的方案時，開發(fā)馬上來一句，這個基于我們現(xiàn)有的工期安排與技術(shù)架構(gòu)，是無法實現(xiàn)的。

結(jié)果，在過完第一次評審之后，我把設(shè)計方案做了大幅度的調(diào)整，甚至要去修改整個方案最底層的流程邏輯。但是由于馬上要第二次評審，服務(wù)重新梳理整個流程，因此，只能基于原有的方案強行修改，導(dǎo)致最終方案雖然可以走完整個流程，但是在某些環(huán)節(jié)的銜接上出現(xiàn)“畸形”。

1.3 測試——天坑3：異常情況處理

作為一個產(chǎn)品新人，方案設(shè)計的時候，最難的不是滿足主流業(yè)務(wù)場景的需求，最難的是去思考各種異常情況與解決方案。

一個人肯定是存在思維慣性與思維盲區(qū)的。但正是這種慣性與盲區(qū)常常造成產(chǎn)品的各種各種BUG。

同時有些極其特殊的異常情況，有時候我們可能已經(jīng)想到了，但是覺得實際使用時不會出現(xiàn)，因此沒有出相對應(yīng)的解決方案，結(jié)果到測試時會被測試各種嫌棄（當(dāng)然，被QA在測試過程中檢測出來已經(jīng)是非常幸運了，如果是老板或者用戶提出這個問題那才是真正的嚴重。）

我們這次版本中，有一個頁面在邏輯層面做了限制，只允許同時只有一個人進入該頁面。該頁面中有個按鈕點擊之后會觸發(fā)業(yè)務(wù)流程的流轉(zhuǎn)，同時跳出該頁面。

QA在測試的過程中，一人同時打開兩個該頁面（本產(chǎn)品是web產(chǎn)品，該頁面只限制只用同時有一個人打開該頁面，但沒限制一個人大概多個該頁面），在一個頁面點擊的觸發(fā)流程的按鈕，然后在另一個頁面再次點擊該按鈕，然后就出現(xiàn)了BUG。

理論上，這種BUG，在用戶實際使用過程中是不太會出現(xiàn)的，但是一旦出現(xiàn)，就會降低用戶的產(chǎn)品體驗。

但是從另一個角度來講，這種異常流程的處理會消耗大量的開發(fā)資源，當(dāng)這種異常流程處理提給了開發(fā)，開發(fā)會覺得你特別的“事兒”（我本來不知道這個詞的，但是最近經(jīng)常被開發(fā)用這個詞說指摘，然而我到現(xiàn)在還是不太能準確理解這個詞是什么意思）

2. 方案設(shè)計

作為一個產(chǎn)品新人，接到這個版本任務(wù)時，十分興奮。新人常常有一個毛病，就是拼命壓榨自己的時間，提高效率，巴不得馬上就能完成設(shè)計，快速出成績。但這為我的整個方案設(shè)計埋下了很多問題。

首先是設(shè)計全局性的問題。本次產(chǎn)品重構(gòu)的過程中，與非常多的列表頁，并且列表的字段也有很多重復(fù)的地方，然而我設(shè)計的時候直接就是憑感覺來安排每個頁面每個字段的前后順序，最終原型提交到UI手中的時候，UI不得不花時間，重新整理各個字段的前后順序，保持所有頁面的統(tǒng)一。

第二點是設(shè)計通用性與可擴展性的問題。我們本次設(shè)計工單系統(tǒng)的時候，我們把訂單與工單在設(shè)計時看做一體，做了嚴格的一對一強耦合的關(guān)系。結(jié)果出現(xiàn)了當(dāng)服務(wù)人員需要關(guān)閉工單的時候，把原本不需要關(guān)閉的訂單也必須一起關(guān)閉才行。本版本也不支持一個用戶一筆訂單中購買多個服務(wù)的場景。為了解決這個問題，我們有不得不重新梳理訂單與工單的關(guān)系，在今后的版本中將兩者解耦。

第三點是設(shè)計的完美性。作為一個處女座的產(chǎn)品，相信很多新人會跟我一樣，對自己的設(shè)計會追求完美，力爭覆蓋所有的用戶場景，幫用戶盡可能的解決所有問題，讓用戶用到我們產(chǎn)品的時候，會有一種驚喜的感覺。在本次工單系統(tǒng)的設(shè)計方案中，我這很多流程環(huán)節(jié)，設(shè)置了一些在特定條件下，不需要服務(wù)人員手動去觸發(fā)流程，而是系統(tǒng)根據(jù)一定條件，進行自動的流轉(zhuǎn)。當(dāng)這個方案提交給開發(fā)的時候，遭遇到了很大的抵觸：因為每種設(shè)計背后都必然會對應(yīng)著開發(fā)成本，我們的開發(fā)認為這些開發(fā)成本極高，相較于對服務(wù)人員的效率提升來說是得不償失，我們應(yīng)該把這些開發(fā)精力放在解決主要矛盾上。因此這些自動流轉(zhuǎn)的功能在最終需求評審的時候被砍掉。

3. 最終執(zhí)行

在經(jīng)過千辛萬苦的需求收集與方案評審之后，終于進入了開發(fā)階段，然而此時才是萬里長征第一步。

3.1 需求變更

雖然需求變更是萬惡之源。然而在實際的開發(fā)，難免會出現(xiàn)需求的變更。這來自于兩方面：一是開發(fā)在開發(fā)過程中發(fā)現(xiàn)實際的開發(fā)難度大于原先所設(shè)想的難度，要求砍需求或者變更需求；二是我們產(chǎn)品自身在這過程中，發(fā)送我們原來需求存在漏洞的，需要完善與變更。不管來自于哪方面，最終的結(jié)果都是需要變更需求。

本次迭代有一個流程環(huán)節(jié)是通過數(shù)量來控制狀態(tài)的流轉(zhuǎn)：需要達到一定數(shù)量才會發(fā)生流轉(zhuǎn)，而之前的系統(tǒng)是數(shù)量一發(fā)生變化狀態(tài)就流轉(zhuǎn)。同時，我們每一個列表頁對應(yīng)著訂單一個狀態(tài)。

在開發(fā)這個功能的時候，我們的后端工程師發(fā)現(xiàn)這個狀態(tài)的流轉(zhuǎn)控制，開發(fā)的成本遠大于原先預(yù)想，因此要求變更需求。經(jīng)過一個多小時的討論，我們最近決定把狀態(tài)流轉(zhuǎn)的條件跟以前保持一致，但是在一個列表頁中同時承載這兩個狀態(tài)。

3.2 消息同步

另外一點，前期設(shè)計的時候，需求變更頻繁。而當(dāng)時為了趕進度，產(chǎn)品需求設(shè)計與UI設(shè)計處于半并行的狀態(tài)。而我與與UI又沒有保持及時的溝通，UI照著老的需求來設(shè)計。因此最終輸出給開發(fā)UI稿，開發(fā)實際開發(fā)的時候發(fā)現(xiàn)，UI稿上的文案與最終需求文檔存在較大出入，開發(fā)不得不兩邊來回對照，耗費大量時間。

3.3 新人與需求的完善度

第三點是，本次版本開發(fā)過程，中途加入了兩個新入職的開發(fā)與一個測試。在設(shè)計之初時，由于開發(fā)都是一直是在做工單系統(tǒng)。因此有些需已有的功能，在描述時沒有十分的詳細。常常描述為：“與現(xiàn)有保持一致”。然而當(dāng)新人加入之后，由于對之前版本不了解，開發(fā)時只能憑借自己的感覺去開發(fā)。到最終測試的時候發(fā)現(xiàn)，很多原有的功能與交互出現(xiàn)了問題，最終又花了大量的實際去修改。

4. 后記

由于時間原因，本周我就寫了我在這次版本迭代的時候遇到的一些問題，踩到的一些坑。

下周我會繼續(xù)把握對怎么應(yīng)對，避免這些問題的思考與方案寫出來，與大家一起討論。

當(dāng)然大家也可以在評論區(qū)想我提出你應(yīng)對這些問題的解決方案，我們一起討論。

作者：Jeff，一個做過市場，當(dāng)過運營，寫過代碼，創(chuàng)過業(yè)的產(chǎn)品新人。

本文由 @Jeff姐夫 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自 Pexels，基于 CC0 協(xié)議