上周我總結了，我作為一個產品新人在第一次負責的迭代中，遇到的一些問題，犯的一些錯誤，主要是三方面：第一個是溝通，第二個是設計，第三個是執行。上周的文章：一個產品新人的第一次失敗迭代復盤（上）我將在本文從這三個點展開來講下我對怎么避免這些問題的方法與思考。

1 溝通

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 設計

2.1 異常流程

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

作為一個產品新人（包括我自己），常常有一個毛?。壕褪窍肟焖俚耐瓿扇蝿?，快速的出成績，得到別人的認同。這種著急的心態，常常導致我們做產品設計時會陷入正常的業務流程中，而沒有考慮異常流程的處理。

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

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

2.2 全局性

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

回到我們設計中來，我們接到一個需要，把他盡善盡美的完成，按照上述的評價標準，你最好只能是個B。那怎么拿到A呢？那就是產品設計的時候，不止考慮到當前的需求，更高考慮整個業務流程與業務的發展。設計產品的時候充分考慮全局性，通用性與可擴展性。

要考慮到這個層次，首先要要求你本身對你所負責對接的業務流程十分熟悉，甚至熟悉程度超過該業務的業務人員。同時在開始設計之初，先不要去考慮具體細節與流程，而是去考慮這個需求影響到現在的幾個業務模塊，這些業務模塊與本需求需要修改的模塊之間是怎樣的關系，有哪些影響。在大體設計完成之后，再去思考，本次設計方案與哪些模塊發生了關系，如果關聯模塊發生的改變，本模塊該怎么處理。

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

3 執行

3.1 需求變更

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

• 一是開發在開發過程中發現實際的開發難度大于原先所設想的難度，要求砍需求或者變更需求；
• 二是我們產品自身在這過程中，發現我們原來需求存在漏洞的，需要完善與變更。

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

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

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

1. 變更完需求，告知整個項目組，包括測試，開發，設計等；
2. 變更完需求，記錄下變更情況，包括變更內容，變更原因，變更時間，變更人。

3.2 需求完善度

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

4 總結

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

做了一段時間的產品經理，我慢慢發現，作為一個產品經理，本質上是一個資源的協調者，我們需要做的是在公司有限的資源下，盡可能的滿足業務的發展需求。換句話說，產品經理是用來解決“社會主義初期的主要矛盾”：業務日益增長的需求同匱乏的公司資源之間的矛盾。

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

相關閱讀

一個產品新人的第一次失敗迭代復盤（上）

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

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

題圖來自Pixabay，基于CC0協議