作者/Jeff 編輯/儒商詩人

來源于：人人都是產品經理

作者：Jeff 姐夫

全文共 6209 字，閱讀需要 13 分鐘

/ BEGIN /

我負責的產品線是一個服務流程化的系統，主要是用于在銷售完成售后之后，讓服務人員通過系統流程化的為用戶提供服務，處理業務。

這個系統包含兩部分：一部分是內部服務人員使用的工單系統，一部分面向用戶的H5頁面——可以大致歸類為一個To?B的產品。

公司原有的工單系統由于是定位于SAAS系統，希望提供給行業一個通用的解決方案，然后最終發現并不能銷售出去。

因此我接手這條產品線的第一個大版本就是：對整個工單系統進行的重構。

這個版本從今年四月份開始設計，到最近終于要準備上線。

5個多月期間，我經歷了一個完成的產品周期，自己也從單純設計頁面，漸漸成長為可以慢慢提出自己的一些想法并推動實施的人。

雖然版本成功上線了，但由于其中走過非常多的彎路，導致開發與我們產品都是非常的疲憊。

因此我稱之為一次“失敗”的迭代。

成功固然可喜，但失敗卻十分寶貴。

通過這次失敗，我踩了基本上一個剛入門的產品經理都會踩的坑。因此。我在此做一次復盤，希望大家引以為戒。

迭代后的復盤

一、溝通

作為一個產品經理，溝通是一個非常重要與關鍵的技能。不管是需求的獲取、方案的討論以及最終的執行，都極度依賴于產品經理的溝通能力。

關于溝通，我將分別用三個產品經理工作中最常溝通的角色來依次說明我踩到坑與解決的方法。

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

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

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

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

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

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

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

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

關于產品該不該懂技術，不同人有不同的看法，主要分為兩種看法：

產品經理不要懂技術，過多的思考技術的實現會局限產品的創意；

產品經理應該懂點技術，這樣設計的產品不至于飄在空中，不能實現。

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

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

結果，在過完第一次評審之后，我把設計方案做了大幅度的調整，甚至要去修改整個方案最底層的流程邏輯。

但是由于馬上要第二次評審，服務重新梳理整個流程，因此，只能基于原有的方案強行修改，導致最終方案雖然可以走完整個流程，但是在某些環節的銜接上出現“畸形”。

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

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

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

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

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

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

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

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

二、方案設計

作為一個產品新人，接到這個版本任務時，十分興奮。

新人常常有一個毛病，就是拼命壓榨自己的時間，提高效率，巴不得馬上就能完成設計，快速出成績。

但這為我的整個方案設計埋下了很多問題。

首先是設計全局性的問題。

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

第二點是設計通用性與可擴展性的問題。我們本次設計工單系統的時候，我們把訂單與工單在設計時看做一體，做了嚴格的一對一強耦合的關系。

結果出現了當服務人員需要關閉工單的時候，把原本不需要關閉的訂單也必須一起關閉才行。

本版本也不支持一個用戶一筆訂單中購買多個服務的場景。為了解決這個問題，我們有不得不重新梳理訂單與工單的關系，在今后的版本中將兩者解耦。

第三點是設計的完美性。作為一個處女座的產品，相信很多新人會跟我一樣，對自己的設計會追求完美，力爭覆蓋所有的用戶場景，幫用戶盡可能的解決所有問題，讓用戶用到我們產品的時候，會有一種驚喜的感覺。

在本次工單系統的設計方案中，我這很多流程環節，設置了一些在特定條件下，不需要服務人員手動去觸發流程，而是系統根據一定條件，進行自動的流轉。

當這個方案提交給開發的時候，遭遇到了很大的抵觸：因為每種設計背后都必然會對應著開發成本，我們的開發認為這些開發成本極高，相較于對服務人員的效率提升來說是得不償失，我們應該把這些開發精力放在解決主要矛盾上。因此這些自動流轉的功能在最終需求評審的時候被砍掉。

三、最終執行

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

3.1 需求變更

雖然需求變更是萬惡之源。然而在實際的開發，難免會出現需求的變更。

這來自于兩方面：

開發在開發過程中發現實際的開發難度大于原先所設想的難度，要求砍需求或者變更需求；

我們產品自身在這過程中，發送我們原來需求存在漏洞的，需要完善與變更。

不管來自于哪方面，最終的結果都是需要變更需求。

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

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

3.2 消息同步

另外一點，前期設計的時候，需求變更頻繁。而當時為了趕進度，產品需求設計與UI設計處于半并行的狀態。而我與與UI又沒有保持及時的溝通，UI照著老的需求來設計。

因此最終輸出給開發UI稿，開發實際開發的時候發現，UI稿上的文案與最終需求文檔存在較大出入，開發不得不兩邊來回對照，耗費大量時間。

3.3 新人與需求的完善度

第三點是，本次版本開發過程，中途加入了兩個新入職的開發與一個測試。

在設計之初時，由于開發都是一直是在做工單系統。因此有些需已有的功能，在描述時沒有十分的詳細。常常描述為：“與現有保持一致”。

然而當新人加入之后，由于對之前版本不了解，開發時只能憑借自己的感覺去開發。到最終測試的時候發現，很多原有的功能與交互出現了問題，最終又花了大量的實際去修改。

失敗后的反思

一、溝通

1.1 與需求方溝通

在運營或者其他公司內部人員溝通需求時，他們經常會根據他們當前業務遇到的問題，直接向我們產品提出一些十分明確的需求。

但由于他們不是專業的產品，而且業務人員往往容易陷入在具體的業務中，導致他們提出的一些需求只能解決片面的或者當前業務中一小部分的問題，而不能通盤去考慮最優的方案。

因此在與業務人員溝通需求時，我們可以使用“5個Why”的方法：就是對于一個事情，連著追問5個為什么（當然，5只是一個通常的數量，需要根據實際情況進行增減）

例如，有個人跟你說,他需要你給他造一把錘子。當你接收到這個需求時，按照5個Why的方法追問他：

Q：你為什么要一把錘子？

A：我需要在墻上釘一個釘子。（第一層）

Q：為什么要在墻上釘一個釘子？

A：因為我要在墻上掛一幅畫。（第二層）

Q：為什么需要在墻上掛一幅畫？

A：因為我的房間太單調了。（第三層）

Q：為什么會覺得房間太單調了？

A：因為我女朋友不喜歡我的房間。（第四層）

Q：為什么你女朋友不喜歡你的房間？

A：因為她覺得這個房間沒有家的感覺。（第五層）

你看當我們連著追問5個為什么之后，我們就會發現：錘子只是問題的表象。

問題的根源是：他的女朋友沒有家的感覺。

因此我們最應該解決的是：讓他女朋友有個家的感覺，而不是簡單的給他一把錘子。

當然上述的例子，在實際的工作中，有些時候由于資源限制（人力，時間，成本，公司方向等），我們可能無法直接解決第五層的問題，當時當你了解到第五層原因時，會對你理解與解決前幾層的問題有非常大幫助：可以幫助你精確的定位問題與問題的邊界，同時也會讓你更加理解這個需求發送的場景。

1.2 與開發溝通

產品需不需要懂技術，業界一直爭論，沒有定論，我只是根據我個人的實際情況與經驗總結：產品可以不動技術，甚至在設計初期可以完全不用考慮技術實現；但是當你想把一個想法準備落地時，最好先與開發進行溝通，了解下方案的技術成本。

當與開發溝通時，最好不要直接問開發一個東西能不能實現。

如果你這樣問只會有兩個結果：一個是技術萬能，啥都可以做；一個是當前技術架構不支持，不能做。

當與開發溝通時，你最好把我們當前用戶遇到問題與對這個問題的思考先告知開發。讓他知道我們為什么要設計這樣的方案。

同時，如果可以，準備多個方案與開發進行溝通，讓他們從技術角度選擇一個最友好的方案。

你會發現當你做到以上這兩點，有時開發不僅不會來反對一些技術成本大的方案，反倒他會從技術角度給你提出一些你沒有想到的方案。

1.3 與測試溝通

測試經常會提出很多異常流程的處理問題，這種異常流程包含兩種：一是我們設計之初就沒有考慮到的異常流程；一個是實際運用中不可能觸發異常流程或者極小觸發的異常流程。

作為一個測試，他的本職工作是找出產品設計或者開發中的問題，至于解不解決我們產品應該根據實際情況進行權衡：

對于前一種異常流程，沒啥好解釋的，趕緊認錯，修改需求，完善異常流程的處理；

對于后一種異常流程，我的建議是跟開發溝通下覆蓋成本，如果成本極大那就放過這些異常情況（僅針對內部工具而言，TO C的產品最好做到盡善盡美）。

與測試溝通時，注意盡量不要說：你這個問題不是問題（提出的BUG不是BUG，提出的異常流程不是異常流程）。當你這么說的時候，作為一個測試會很容易覺得你在否定他的工作。

當他提出一個異常流程而你覺得不需要去覆蓋時，你可以說：恩，這個流程是會出現你說的這種異常，但是我覺得XXXX，所以我覺得可以不要去覆蓋。一般來說，只要你的理由合理，測試是不會來跟你糾結的。

二、設計

2.1 異常流程

產品設計使我們作為一個產品的本職工作與技能。

作為一個產品新人（包括我自己），常常有一個毛?。合肟焖俚耐瓿扇蝿?，快速的出成績，得到別人的認同。

這種著急的心態，常常導致我們做產品設計時會陷入正常的業務流程中，而沒有考慮異常流程的處理。

關于異常流程的處理，有一個七字真言在實際的工作中，十分的實用：增刪改查顯算傳。

增刪改很好理解：就是當數據增加、刪除、修改時頁面會出現什么情況；查就是怎么獲取數據，這包括篩選，搜索，排序；顯的意思是數據該怎么顯示，算是頁面內的數值是怎么得到的，怎么計算的；傳是各種各樣數據是怎么傳輸的，實時還是非實時，哪些需要提交服務器或者從服務器獲取等等。

2.2 全局性

在我們公司，有KPI的評級體系：當你把本職工作做到最好，只能得到B；只有當你對你的工作提出更好的改進方案并實施時，才能拿到A。

回到我們設計中來，我們接到一個需要，把他盡善盡美的完成，按照上述的評價標準，你最好只能是個B。

那怎么拿到A呢？那就是產品設計的時候，不止考慮到當前的需求，更高考慮整個業務流程與業務的發展。設計產品的時候充分考慮全局性，通用性與可擴展性。

要考慮到這個層次，首先要要求你本身對你所負責對接的業務流程十分熟悉，甚至熟悉程度超過該業務的業務人員。

同時在開始設計之初，先不要去考慮具體細節與流程，而是去考慮這個需求影響到現在的幾個業務模塊，這些業務模塊與本需求需要修改的模塊之間是怎樣的關系，有哪些影響。

在大體設計完成之后，再去思考，本次設計方案與哪些模塊發生了關系，如果關聯模塊發生的改變，本模塊該怎么處理。

簡單來說就是，需要時常跳出具體需求，把整個產品作為一體來考慮方案。

三、執行

3.1 需求變更

不管前期需求設計的多么完善，實際開發中難免會出現需求變更。引起需求變更的原因主要有兩種：

開發在開發過程中發現實際的開發難度大于原先所設想的難度，要求砍需求或者變更需求；

我們產品自身在這過程中，發現我們原來需求存在漏洞的，需要完善與變更。

關于前一種需求變更，我們需要與開發討論是否有更方便，但不會影響最終效果的方案來解決這個需求，如果由那我們可以去變更需求；若沒有，那作為產品我們應該說出可以說服開發去心甘情愿大費周章去開發的理由，同時也需要考慮到項目可能延期帶來的后果。

關于后一種需求，我們變更時，先去與開發溝通，承認問題，希望開發能接受這個變更。

同時不管哪種原因變更了需求，最好做到以下兩點：

變更完需求，告知整個項目組，包括測試，開發，設計等；

變更完需求，記錄下變更情況，包括變更內容，變更原因，變更時間，變更人。

3.2 需求完善度

當我們對某一頁面的細節做了些許變更，其他沒有變更時。描述清楚變更點后，可以寫其他與現狀保持一致。但是別忘了吧這個頁面之前的需求地址給出了，方便新人對這個頁面不熟悉時，也可以找到這個頁面詳細的需求描述。

四、總結

這是我對我第一次產品迭代的復盤與思考。希望對大家有所啟發。

做了一段時間的產品經理，我慢慢發現：作為一個產品經理，本質上是一個資源的協調者——我們需要做的是在公司有限的資源下，盡可能的滿足業務的發展需求。

換句話說：產品經理是用來解決“社會主義初期的主要矛盾”：業務日益增長的需求同匱乏的公司資源之間的矛盾。

因此作為一個產品經理，需要鍛煉與發展的也就是資源協調的能力：這包括協調溝通能力與抽象提煉重組的能力。

/ END /