微光PM博客-产品路漫漫,和微光一起学习互联网产品经理职责、产品运营SEO、营销推广。 O(∩_∩)O~SEO运营Club点击这里给微光发消息

与程序员/设计师那些相爱相杀的日子-微光产品经理实践总结

产品经理 微光 1984℃ 0评论
先做下背景介绍:
本人:微光,产品经理,产品经验1年,2016年成功项目:PC端平台全站改造,各端银行交易系统项目(从16年初到9月底上线);消费金额app项目。所承担的工作:产品调研,需求分析、产品策划、PRD文档撰写、项目跟进、项目测试、项目二期优化。所在行业:互联网金融- P2P ,公司性质 :创业型

团队人员配置,其中并非每个人都是老手。
产品:2人,我是其中一员。
UI:2人
PC后端技术:3人
移动端程序:3人
前端:2人
————————— 与程序员/设计等相爱相杀的日记—————————

2016年7月7日

事件经过:

app一新项目要与后端技术做接口。做到途中,后端技术发现APP上新项目设计页面与PC功能,APP设计图都不符合,便质问我,技术做出的东西都不看吗?我回答:我并不知道他们做完了,且做完也未告诉我,(产品都一直忙于测试PC、微信端,app今天技术刚测提出需求进行测试)最后不欢而散,后端技术只能按照最后调整完的设计图做接口。
事件诱因:

1、APP这一新项目是新增的,老板要求8号做完接口,时间紧张。

2、公司目前无专职项目管理,一般由产品经理负责催跟项目,还主负责测试。三端产品都要负责,7月底要上线三端大版本更新。

3、项目需求当时有变动,跟后端技术负责人口头说明并确定了如何变动,设计图未改,未交付新设计图。

事件总结:

1、及时更新设计稿,交付下去,避免后期扯皮。

一般情况,设计师只看产品经理的RP,前端只看设计稿,研发只看前端做出的来的网页或demo,这样一环套一环下去,若从头就开始错误,会增加一系列的修改时间成本,最后背黑锅的一定是产品经理。研发同学一般都不爱看文档的,他们埋头写代码的时候是不太会去考虑这个设计合不合理,需求是否正确,所已在开产品研讨会时就尽量交代清楚要注意的点。

2、 对于提的需求考虑清楚,不要急于给予答复并安排下去。
微光本人就是个急性子,很多时候对于提出的需求,当时考虑不周全就草率的同意了,之后再慢慢琢磨发现这种解决方法并不好,会造成需求的再次变更,这样技术人员即使不打你,心里也会暗暗不爽,怨你想的不周到。

3、及时跟进研发同学的制作进度,并解决其中的问题。

产品交付研发并不表示产品经理的责任就轻松了,在微光所在的公司,是没有项目经理、测试工程师存在的。除了各部门负责自己部门的工作进度外,对外交涉主要就落在了产品经理头上。跟进项目进度,了解项目进展阶段,进行复测,尽量避免将问题留到下一个阶段。

2016年7月11日

 事件经过:

我们有个研发同学开会不喜欢做笔记,当时再三确定的需求,等过些天再跟进时,有些具体的地方便会忘记或记忆不清楚。产品同学在撕逼的过程中(包含我)还为此翻过脸。最后叫来一起开会的研发组长当面一起明确了一遍。
事件总结:
对于每一项需求、规则,尤其是需求变更,能写就写下来,不要偷懒;最好发邮件通知。
好处:
1、锻炼自己对产品细节的把控力、逻辑规则的描述能力,保证自己忘记时有的可看。毕竟每个人的记忆力有限,时间一长,很多细节的东西就会记忆不清楚。
2、会避免很多次重复的口头解释、避免双方内心的暗暗不爽,避免很多不必要的细节沟通上的扯皮。

更新中……

转载请注明:产品经理/SEO实战 » 与程序员/设计师那些相爱相杀的日子-微光产品经理实践总结

喜欢 (0)or分享 (0)
发表我的评论
取消评论

表情

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址