中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

作者總結了自己在一個2B產品研發過程中遇到的幾個坑與大家分享，希望可以給各位帶來幫助。

2B 產品經理，特別是創業公司的 2B 產品經理，往往戰斗在和客戶溝通需求的第一線，同時也身兼和組內或者公司內開發對接、調整需求的第一責任人。由于信息在傳播過程中難免會有損失，以及客戶變更需求簡直比女人翻臉還快，所以，研發過程中如何和需求方（客戶）保持良好溝通以此來保證產品順利交付已經是 2B 產品經理的生存必備技能之一。

以下幾點是我在上一個 2B 產品研發過程中遇到的幾個坑，希望可以幫助到正在遇到同樣問題或者可能遇到類似問題的你。

1.畏懼客戶，若不是客戶主動聯系絕不會主動多問一句

這個簡直可以是 2B 產品研發過程中的命門死穴般的大忌。為什么這么說，主要是由于 2B 客戶盡管是需求方，但是他們對于自己想要什么，以及能夠提供什么，后期如何配合我們的工作幾乎可以算是一無所知。只經過簡單的幾次需求溝通會議，就定下來的需求清單是經不起推敲的?；蛟S大流程走下來是沒有問題的，但是諸多細節都必須和客戶一一對過。

有些產品經理生性害羞，有的產品經理甚至會覺得客戶三天兩頭改需求真“煩”。對于這些產品經理，幾乎可以預料到在中期交付的產品功能一定和客戶最初所想相差甚遠。如果需求方吹毛求疵起來，少則要增減一些字段。更多的則直接是底層邏輯修改。到時候別說開發了，估計老板想要掐死產品的心都有了。

比如：在上個項目中我負責的一個 O2O 產品。其中時間控件的設計需要考慮到該服務點的承載量。而且作為一個全局控件，在多個頁面以及主功能流程上都有用到。最初需求溝通的時候我僅僅溝通了營業人員上下班時間。但后來開發過程中我發現還需要考慮到節假日上班時間以及服務站點的營業時間。若不是及時溝通，后來要修改的接口數絕不會少。

2.覺得關注產品研發進度是項目經理的事情

有的大公司里項目經理和產品經理之間有明顯的界限，這些公司的項目經理往往具備技術背景并且在公司里有一定的聲望。針對這種情況，產品經理其實不必過多過問產品研發進度，定期和項目經理合一下就好了。但是更多時候公司里的項目經理不怎么“給力”，或者公司領導直接兼任項目經理。這時產品經理還是最好跟跟項目進度。畢竟我們是戰斗在第一線的人，面對需求方和老板的隨時發難，要做到胸中有譜。另外還有一點，就是經常和研發過產品進度，可以幫助我們更好的把控產品研發新走向，除了額外可以學到技術上的零碎東西，有時候還可以替研發同事們排憂解難。

比如原型上的某個控件開發難度比較大，及時更換為網上已經封裝好的用開源控件，可以節省下不少人力成本。再比如有時候交互上的一點邏輯調整可以讓后臺工程師直接減少幾十行的 Code 數。

3.不和產品的實際使用者確認產品 Demo

我個人覺得讓產品實際使用人員在設計階段就參與進來是件不錯的事。大家都知道 2B 產品需求對接方往往是企業管理者，他們往往不實際使用，或者并不是使用產品最多的人。他們最關心的不是產品性能而是確保產品功能點能夠 Cover 他們的業務線，讓投入產出比達到配比最優。用戶體驗，產品交互細節等等對他們來說無所謂。對產品好壞最有發言權的人應該是產品的最終使用者。因此我們應該珍視他們的建議。有時候產品經理絞盡腦汁苦思冥想了很久的方案其實是脫離實際業務場景的。我們自嗨式的陶醉在某個交互里，但說不定在實際場景中并沒有那么好用，甚至不能用。為了杜絕這種事情發生，我們應該從設計階段到研發交付這段時間內都不斷的讓產品最終使用者參與進來。

比如，有些時候產品經理對實際的業務場景并不是十分熟悉，并不能特別好的掌握產品的實際業務層級。這個時候”卡片分類法”就派上用場。讓實際使用者來為我們出謀劃策。另外，產品即將交付的時候找來幾個實際使用者做冒煙測試也是不錯的選擇。他們是最熟悉自己業務場景的人，幾乎可以測試到所有在實際業務中高頻的場景。若真的存在流程問題，我們可以及時調整優化。

4.不重視文檔更新、部門內的報聯商

由于工期短、人手往往短缺、資源不足這樣的現狀下導致2B 產品需求變更非常頻繁，每一次更改都需要更新文檔。但忙起來常常容易遺忘掉，從而釀成許多不應該犯的錯誤。很多時候和客戶溝通后，我們更改了原型上的一處小細節，并且通知了我們自以為會影響的開發，但這中間總會遺漏一些人。并且在研發后期極易出現扯皮。

比如測試驗收的時候發現界面多處對不上。移動端同事說：“我就是按照原型開發的”，然后打開了手頭兩個月前你發給他的原型，但測試手頭的原型是你昨天發給他的最新版，其中就頁面層就有至少 20 多出的細小修改。這部分的人力成本誰來 Cover 呢？這個鍋恐怕最后還是會讓產品背。

好的需求文檔管理方式有很多種，我就不班門弄斧了。自己常用方法是最簡單的一種：每次更改原型后都會郵件發送整個項目人員。郵件正文中我會簡要標明本次修改點，并明確告知最新文檔的地址。

• 文檔命名方式：產品名稱 + 版本號 + 修改日期；
• 文檔更改記錄：RP 原型文件上有更改記錄、若有其他 PRD 也在表頭首先注明文檔更改的部分

不給對方和自己扯皮的機會，也不會因為自己的失誤、遺漏增加他人的工作量，是我們和開發之間信任的基石。

5.不做產品復盤會

但凡渴求進步、蒸蒸日上的公司、項目組都會在產品發布完畢后開一個小小的產品研發復盤會。分析下從立項到結項這一系列過程中部門的得與失。至于怎么開、開的質量如何其實和領導氣質有很大關系。我們作為小小的 PM 有時候想使勁也使不上來。但至少應該做好自己的那一份。也就是在產品復盤會上認真深刻的反思項目中產品層面的得與失。

其中應包含的內容有：本次研發過程中產品部門做的好的點，不足的點。對于不足的點盡可能說的細一些，理解的深刻一些，最好可以深挖出不足的深層原因，并提出相應的解決對策。只有自己總結出的足夠深刻的見解才能在腦海中形成記憶。作為產品經理應該珍惜每一次產品復盤會的機會。不僅是自己重新審視整個項目從 0 到 1 的機會也是一個自我學習、迭代的好機會。這次的閃光點就是將來的寶貴經驗。這次的失敗之處就是以后重點關注的內容。

本文作者：晞仔（lolitaxi61）個人公眾號：晞仔的生活實驗室

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