在日常工作中,時常能看到產(chǎn)品和程序員因為某個需求的問題大打出手蛾魄。每當(dāng)此時虑瀑,我就想說打工仔何苦為難打工仔?如果你是新手滴须,想要避免發(fā)生這種情況舌狗,以下技能必不可少。
①設(shè)計清晰的業(yè)務(wù)流程和產(chǎn)品原型
程序員最怕的不是不懂技術(shù)扔水,而是邏輯不縝密把夸,思維不清晰的產(chǎn)品經(jīng)理。產(chǎn)品主流程設(shè)計完了铭污,分支流程忘記做了恋日,在需求溝通會的時候一溝通就發(fā)覺問題。
舉個例子:在做一個分銷電商系統(tǒng)的時候嘹狞,普通商品自購能夠省錢岂膳,分享能夠分傭,那當(dāng)這個商品參加了拼團(tuán)磅网、秒殺谈截、砍價活動的時候還可以參加分銷嗎?可以的話金額怎么計算涧偷?不可以的話流程又要怎么走簸喂?
在評審普通商品購買流程時就得把營銷活動的商品是否參加分銷出兩個方案,讓財務(wù)(一般不叫燎潮,但涉及到成本核算的時候會叫上)喻鳄、相關(guān)技術(shù)人員、產(chǎn)品負(fù)責(zé)人一起評審确封。
②完整準(zhǔn)確的表達(dá)需求
產(chǎn)品經(jīng)理在給開發(fā)描述需求時除呵,大多都會寫PRD文檔再菊,但實際上很多程序員都不看文檔,尤其是后端開發(fā)颜曾,只要是他覺得流程差不多能理解纠拔,他就不會去看你文檔里面的文字寫了什么,當(dāng)出現(xiàn)疑問時更愿意走過來跟你當(dāng)面交流泛豪。此時描述需求的能力就顯得尤為重要稠诲。我個人一向喜歡在描述需求時按照結(jié)果+場景+描述的順序進(jìn)行敘述。
比如我想讓開發(fā)同事在商品詳情頁面尾部加個“猜你喜歡”功能诡曙。我會結(jié)合草圖然后跟他說:聰哥臀叙,我要提個需求,功能是商品詳情頁面尾部加個“猜你喜歡”功能岗仑。【結(jié)果】
用戶在瀏覽完一個商品但這個商品不是他想要的能夠通過最下方的猜你喜歡繼續(xù)逛聚请,而不是直接跳出小程序荠雕。【場景】
后臺需要新增標(biāo)簽管理模塊驶赏,總共兩級標(biāo)簽炸卑。創(chuàng)建商品時關(guān)聯(lián)標(biāo)簽,含有相同標(biāo)簽的就會在猜你喜歡處展示煤傍「俏模【描述】
有的產(chǎn)品經(jīng)理在描述一個功能時,一上來就是我給你描述下競品是怎么做的蚯姆,然后就巴拉巴拉一堆五续,最后開發(fā)就會說一句,你講重點龄恋,我們的產(chǎn)品要做什么東西疙驾,流程是什么樣的。
③懂點技術(shù)
雖然產(chǎn)品經(jīng)理不會技術(shù)郭毕,程序員也不會說啥它碎,但是他們更喜歡會懂點技術(shù)的產(chǎn)品經(jīng)理,這樣溝通能夠更有效显押,而不是靠拍拍腦袋扳肛、拍拍大腿就讓程序員實現(xiàn)需求,完全不考慮能不能實現(xiàn)及實現(xiàn)難度如何乘碑。產(chǎn)品經(jīng)理并不需要懂代碼挖息,只要在提需求想清楚實現(xiàn)原理,然后跟開發(fā)討論兽肤,這樣幾乎不會有什么矛盾旋讹。
舉個例子殖蚕,我要做個問卷功能,字段由后臺自定義添加沉迹,此時我會把前后端原型做出來睦疫,然后在前端對應(yīng)字段做個標(biāo)注:此處字段調(diào)后臺接口,然后跟前后端開發(fā)同事進(jìn)行討論鞭呕,問他們這樣是否可行蛤育。
大部分情況下,我的想法都是行得通的葫松,所以他們也樂于在閑暇時跟我探討一些簡單的技術(shù)原理瓦糕,方便我能更好的跟他們溝通。
除了以上三點之外腋么,還有一個最重要的必殺技咕娄,那就是鍛煉身體,提高抗壓能力珊擂。