论产品经理的自我修养

如何避免和开发的日常撕逼...

实在是不想写开篇语了...

算了,还是写吧,要不显得文章没头没尾很敷衍...

思考中:怎么写能引起大家的兴趣,使大家读下去呢...

算了, 不玩套路了,直接来:产品和开发的日常撕逼,看似正常,其实可以避免,之前老K一直强调沟通能力的重要性,其实,最最根本的,是产品经理要有基本的自我修养

下面,论产品经理的自我修养:

别YY需求

产品经理提出任何需求,原因一定不是,不是,不是:老板想要、运营需求、竞品已有等等这类**的理由(老K曾在产品经理7神器——说服程序猿一文提出过说服程序猿的法宝,这明显是用来搞笑的,聪明如你们,一定懂得吧)。任何需求,都要从产品目标&用户需求两个层面去考虑,首先找到充足的理由说服自己,然后再去说服技术。

举个例子:比如理财产品都涉及绑定银行卡这样的功能,一般需要手动去输入银行卡号,体验很差。所以PM提出优化方案:用拍照识别银行卡来代替手动输入。这个需求,从产品目标上讲:符合产品科技金融的定位&简化操作可以提高转化和留存;从用户需求上讲,极大的优化了体验,用的爽!

做好信息共享

很多PM在需求评审时只告知要做什么,而不说明为什么要做。是啊,程序猿负责实现功能就好了,说其他的有什么用?然,这种想法是绝对错误的,大家同属一个Team,一定要让每一个人都明确目标,同时也明确自己的努力可以向目标迈进一步。

而且,经验丰富的程序猿会想到功能可能的延伸方向,提前做好可扩展性。

不要强行评估工作量

即使是技术出身的PM,也不要强行去评估工作量并确定工期。切记,专业的事儿交给专业的人去做。

尽量别改需求

对产品来说,改需求是一句话的事儿;对技术来说,改需求可能意味着代码废弃、框架重构...简单说来就是通宵两天写的几千行代码没用了。。

所以,承接第1条,别YY需求,所有的需求都从产品目标&用户需求的两个层面去考虑周全,避免在开发的过程中改需求。

及时反馈结果

功能上线后,达成的效果要及时反馈给程序猿(挑好的说),虽然大部分程序猿并不关心运营指标,但自己的努力取得了很好的效果,他们还是很高兴的。同时,也会建立程序猿对PM的信心,信任PM的眼光,由此形成良性循环,沟通上会更加顺畅。

把握好"度"

前段时间看《我的前半生》,其中贺函对唐晶的一句话让我印象很深刻:你学会了我的所有技能,唯独欠缺的是把握一个"度"(具体台词忘了,大概这个意思...)。

其实很多同学都缺乏这个,怎么讲呢,举个简单的例子:需求会后定好了上线时间,但是在测试过程中发现一个BUG影响很大,难以解决,怎么办?逼开发通宵加班解决BUG?讲道理你没错,确定好了时间就一定按照时间节点走,但这类难以预见的问题影响开发进度,该怎么办呢?

所谓的把握好"度",所谓的人情世故,大概这样吧...


-end

关注公众号:产品经理日记(ID:p_m_diary)回复“PRD”,获取鹅厂内部需求文档模板!

0条评论 添加新讨论

登录后参与讨论
Ctrl+Enter 发表