posts - 188,comments - 176,trackbacks - 0
在大公司工作,首先要面对的是公司现有的流程、规定和条框。其次,基于成本考虑,多数大公司都采取矩阵式管理,核心部门都是共享资源,产品经理要确保争取到足够的资源才能研发出产品。作为一名初来咋到的产品经理,更是要理解这两点才能高效地开展日常工作。

对于公司现有的流程、规定和条框等硬性政策可以自主去学习了解,但对于如何在矩阵式架构中充分开展工作,在与Leader、伙伴的学习之余,更多还是要结合个人情况去揣摩、理解、总结和反思,形成一套自己的工作方法。日常工作中,大部分时间都在与市场部、UED部、开发部、测试部、运营部的伙伴进行产品沟通、需求评审及问题跟踪,不同部门承担的职能不同,使得产品经理在与这些伙伴的工作配合中除了发挥自身专业之外,对于软技能的运用也是非常重要的。

        写完这篇小结时刚好读完《全新思维》,结合工作实践和书中的观点,以部门合作的角度来分享一些对产品软技能的理解:

1、市场部,关注的是产品的销售量及利润额,产品经理在与市场伙伴的工作配合中应该充分发挥自身专业素质,以产品体验为己任,在市场销售与产品体验之间取得平衡,避免牺牲产品体验来片面得追求市场份额。同时,与市场伙伴的日常沟通中,更多的要以『故事、产品思维』去沟通交流,增强互信。

2、UED部,关注的是产品的用户体验,产品经理在与UED伙伴的工作配合中,应该将产品的业务诉求、产品流程以及产品原型与UED伙伴充分交流和沟通,在UED伙伴充分理解产品需求的前提下,产品经理更多的是提出自身对产品交互及视觉的建议,具体的产品交互及视觉设计过程尊重UED伙伴的专业意见。同时,与UED伙伴的日常沟通中,更多的要以相对『设计、共情思维』去沟通交流,增强互信。

3、开发部,关注的是产品按期保质保量完成代码开发及BUG修复,产品经理在与开发伙伴的工作配合中,应该先输出高质量的产品需求文档,在需求评审环节,技术细节充分听取开发的专业意见。代码开发过程中,碰到产品需求与技术实现存在偏差时,非原则性的问题,尊重开发人员的意见。同时,与开发伙伴的日常沟通中,更多的要以严谨的『系统思维』去沟通交流,增强互信。
4、测试部,关注的是按期保质保量完成系统测试及BUG发现,产品经理在与测试伙伴的工作配合中,应该先输出高质量的产品需求文档,为测试伙伴编写测试方案及用
例提供依据。需求评审过程中,充分听取测试伙伴对需求中存在的异常流程、产品边界及性能测试等方面的专业意见。系统测试过程中碰到测试BUG,第一时间判断是需求问题
还是开发问题,需求问题应充分评估影响面,开发问题要主动协调开发伙伴进行BUG修复。如需求变更的影响面较大、开发技术实现遇到瓶颈导致影响产品进度,在协调无果的
情况下,及时与产品领导、技术领导汇报和沟通。同时,与测试伙伴的日常沟通中,更多的要以严谨的『系统思维』去沟通交流,增强互信。
5、运营部,关注的是提升产品的用户活跃度及用户质量,产品经理在与运营伙伴的工作配合中,应该充分发挥自身专业素质,以产品体验为己任,在推广指标与产品体验之间取得平衡,避免牺牲产品体验来片面得追求推广指标。同时,与运营伙伴的日常沟通中,更多的要以『故事、产品思维』去沟通交流,增强互信。
6、兄弟产品部,关注的是产品对接后对其产品的价值及影响。产品经理在与兄弟产品伙伴的工作配合中,应该充分阐述自身产品的背景、定位、价值、目标、用户场景及业务流程、产品原型、路标规划,充分听取兄弟产品的专业意见,求同存异。同时,与兄弟产品伙伴的日常沟通中,更多的要以『产品、系统思维』去沟通交流,增强互信。
7、产品部Leader,关注的是产品整体的路线规划及产品过程的关键节点把控,与其他部门Leader的沟通协调,产品团队的成长与建设。作为产品经理,应该以事实和数据来与产品部Leader汇报工作,在产品整体的路线规划下,完成自己所负责的产品生命周期管理;对研发过程中碰到的需求变更、设计方案、技术瓶颈、测试问题等可能影响产品里程碑的风险及时与Leader沟通。
posted on 2015-07-05 08:12 cheng 阅读(5633) 评论(0)  编辑  收藏 所属分类: 互联网产品

只有注册用户登录后才能发表评论。


网站导航: