產(chǎn)品經(jīng)理是一個協(xié)作型職業(yè)，所以經(jīng)常會在工作中遇到來自于各方各面的溝通問題。有的時候問題多起來真的讓人很頭疼。
比如，你的工作中一定會遇到過下面這些問題。
開發(fā)哥哥A會跑過來告訴你，這個需求實現(xiàn)不了，你想辦法吧。
開發(fā)哥哥B會跑過來告訴你，你這個邏輯有問題，走不通，想出來再提需求好嘛？
你們這是在搞事情??！說好的大家和樂融融的好好工作呢！為啥要為難我這個可憐的小土狗！
既然你們要搞我，那我就要有相應(yīng)的對策才行，怎么能天天讓你們虐。
針對于不同的部門，應(yīng)該采取不同的處理方式，將他們當(dāng)成你的用戶，滿足他們的痛點和需求。
下面來解鎖姿勢！
對付開發(fā)哥哥的正確體位解鎖方式
大家都是一起搞事情的，開發(fā)哥哥們也不會一直針對你。他來跟你說不行的時候，你以為他真的不行了嗎。
要知道他們都是傲嬌的單身漢，怎么能輕易說自己不行。
那就要從以下幾個方面來把把脈了。
-
用戶需求與場景是否明確
現(xiàn)在大多數(shù)團隊在與開發(fā)團隊做需求評審時，就略過了用戶需求的說明階段，而直接去講功能。這樣對于開發(fā)來說就很難去理解場景，只能片面的去做功能，腦海中無法形成完整的場景認(rèn)知，寫的代碼就會只針對于他所理解的業(yè)務(wù)邏輯來做處理。
等做出來以后經(jīng)常會發(fā)現(xiàn)與你所說的有很大的出入。
這里我們就要求跟開發(fā)哥哥們講清楚，用戶是誰？什么時候會用？怎么用？以及為什么要用這個功能？
把用戶需求與場景pia一下呼上去，開發(fā)哥哥門恍然大悟，oho~是這樣蛤？
-
功能業(yè)務(wù)邏輯是否考慮完善
講完需求，這時候開發(fā)哥哥一定會說：需求算是明確了。諾~來，給我們看下完整的業(yè)務(wù)流程吧，別挖坑了，講明白點。
這時候你戰(zhàn)戰(zhàn)兢兢的打開你的visio，亮出了你畫了很久的業(yè)務(wù)流程圖。
開發(fā)哥哥看了你的業(yè)務(wù)流程圖，啪一聲打你臉上！
“這個輸入框輸入什么內(nèi)容？能輸入多少字符？特殊符號能輸入嗎？是必填項嗎？
這個模塊數(shù)據(jù)哪里來的？我靠，這個字段改不了，影響之前的邏輯了，我們來不及改！”
你一臉蒙蔽黑人臉，蛤？我沒考慮?。浚?br>
我們不是老板，做一個功能只考慮用戶需求。
最終還是需要落地的，需要所做的功能具備可執(zhí)行性。
功能必須描述清楚開始與結(jié)束。
數(shù)據(jù)需要知道來源，如何存儲。
字段需要定義好異常情況，為空情況，以及字段類型和長度。
-
對產(chǎn)品是否有改進(jìn)作用，數(shù)據(jù)上是否有所提升
終于說清楚了需求和流程。就可以拿出最后一招了。畢竟開發(fā)哥哥也是有追求的。希望自己辛辛苦苦寫的代碼會有人用??！不然天天加班揮汗如雨橋下的代碼都去吃土了嘛！
這時候應(yīng)該拿出我們作為產(chǎn)品經(jīng)理應(yīng)有的數(shù)據(jù)敏感力，pia一下呼出你的數(shù)據(jù)化分析。
嗯。我們今天做的這個功能會對用戶有這樣那樣的影響，我們預(yù)估會提升用戶X%的注冊率or轉(zhuǎn)化率...
怎么樣？方法很簡單有木有？
3招啊！不用4招、5招，7、8招啊。我們要的就是簡單實用。
記住，沒有人在工作中來無緣無故的挑你毛病的，拿出你的職業(yè)范兒來，我們只做有效的溝通！
