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

作為一個今年剛走出校門的產品新人，剛一畢業我就接手了公司的一條產品線（當然，產品的整體架構已經由產品總監搭好）。

我負責的產品線是一個服務流程化的系統，主要是用于在銷售完成售后之后，讓服務人員通過系統流程化的為用戶提供服務，處理業務。這個系統包含兩部分：一部分是內部服務人員使用的工單系統，一部分面向用戶的H5頁面?？梢源笾職w類為一個TO B的產品。

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

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

成功固然可喜，但失敗卻十分寶貴。通過這次失敗，我踩了基本上一個剛入門的產品經理都會踩的坑。因此。我在此做一次復盤，希望大家引以為戒。

1. 溝通

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

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

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

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

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

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

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

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

1.2 開發——天坑2：產品該不該懂技術

關于產品該不該懂技術，不同人有不同的看法，主要分為兩種看法：1.產品經理不要懂技術，過多的思考技術的實現會局限產品的創意；2.產品經理應該懂點技術，這樣設計的產品不至于飄在空中，不能實現。

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

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

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

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

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

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

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

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

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

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

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

2. 方案設計

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

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

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

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

3. 最終執行

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

3.1 需求變更

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

本次迭代有一個流程環節是通過數量來控制狀態的流轉：需要達到一定數量才會發生流轉，而之前的系統是數量一發生變化狀態就流轉。同時，我們每一個列表頁對應著訂單一個狀態。

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

3.2 消息同步

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

3.3 新人與需求的完善度

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

4. 后記

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

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

當然大家也可以在評論區想我提出你應對這些問題的解決方案，我們一起討論。

作者：Jeff，一個做過市場，當過運營，寫過代碼，創過業的產品新人。

本文由 @Jeff姐夫 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自 Pexels，基于 CC0 協議