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

1 溝通

1.1與需求方溝通

在運營或者其他公司內(nèi)部人員溝通需求時，他們經(jīng)常會根據(jù)他們當前業(yè)務遇到的問題，直接向我們產(chǎn)品提出一些十分明確的需求。但由于他們不是專業(yè)的產(chǎn)品，而且業(yè)務人員往往容易陷入在具體的業(yè)務中，導致他們提出的一些需求只能解決片面的或者當前業(yè)務中一小部分的問題，而不能通盤去考慮最優(yōu)的方案。

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

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

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

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

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

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

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

A：因為我的房間太單調(diào)了。（第三層）

Q：為什么會覺得房間太單調(diào)了？

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

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

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

你看當我們連著追問5個為什么之后，我們就會發(fā)現(xiàn)，錘子只是問題的表象。問題的根源是他的女朋友沒有家的感覺，因此我們最應該解決的是讓他女朋友有個家的感覺，而不是簡單的給他一把錘子。

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

1.2與開發(fā)溝通

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

當與開發(fā)溝通時，最好不要直接問開發(fā)一個東西能不能實現(xiàn)。如果你這樣問只會有兩個結(jié)果：一個是技術萬能，啥都可以做；一個是當前技術架構不支持，不能做。

當與開發(fā)溝通時，你最好把我們當前用戶遇到問題與對這個問題的思考先告知開發(fā)。讓他知道我們?yōu)槭裁匆O計這樣的方案。同時，如果可以，準備多個方案與開發(fā)進行溝通，讓他們從技術角度選擇一個最友好的方案。你會發(fā)現(xiàn)當你做到以上這兩點，有時開發(fā)不僅不會來反對一些技術成本大的方案，反倒他會從技術角度給你提出一些你沒有想到的方案。

1.3與測試溝通

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

作為一個測試，他的本職工作是找出產(chǎn)品設計或者開發(fā)中的問題，至于解不解決我們產(chǎn)品應該根據(jù)實際情況進行權衡：對于前一種異常流程，沒啥好解釋的，趕緊認錯，修改需求，完善異常流程的處理；對于后一種異常流程，我的建議是跟開發(fā)溝通下覆蓋成本，如果成本極大那就放過這些異常情況（僅針對內(nèi)部工具而言，TO C的產(chǎn)品最好做到盡善盡美）。

與測試溝通時，注意盡量不要說：你這個問題不是問題（提出的BUG不是BUG，提出的異常流程不是異常流程）。當你這么說的時候，作為一個測試會很容易覺得你在否定他的工作。當他提出一個異常流程而你覺得不需要去覆蓋時，你可以說：恩，這個流程是會出現(xiàn)你說的這種異常，但是我覺得XXXX，所以我覺得可以不要去覆蓋。一般來說，只要你的理由合理，測試是不會來跟你糾結(jié)的。

2 設計

2.1 異常流程

產(chǎn)品設計使我們作為一個產(chǎn)品的本職工作與技能。

作為一個產(chǎn)品新人（包括我自己），常常有一個毛?。壕褪窍肟焖俚耐瓿扇蝿眨焖俚某龀煽?，得到別人的認同。這種著急的心態(tài)，常常導致我們做產(chǎn)品設計時會陷入正常的業(yè)務流程中，而沒有考慮異常流程的處理。

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

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

2.2 全局性

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

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

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

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

3 執(zhí)行

3.1 需求變更

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

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

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

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

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

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

3.2 需求完善度

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

4 總結(jié)

這是我對我第一次產(chǎn)品迭代的復盤與思考。希望對大家有所啟發(fā)。

做了一段時間的產(chǎn)品經(jīng)理，我慢慢發(fā)現(xiàn)，作為一個產(chǎn)品經(jīng)理，本質(zhì)上是一個資源的協(xié)調(diào)者，我們需要做的是在公司有限的資源下，盡可能的滿足業(yè)務的發(fā)展需求。換句話說，產(chǎn)品經(jīng)理是用來解決“社會主義初期的主要矛盾”：業(yè)務日益增長的需求同匱乏的公司資源之間的矛盾。

因此作為一個產(chǎn)品經(jīng)理，需要鍛煉與發(fā)展的也就是資源協(xié)調(diào)的能力：這包括協(xié)調(diào)溝通能力與抽象提煉重組的能力。

相關閱讀

一個產(chǎn)品新人的第一次失敗迭代復盤（上）

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

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

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