产品管理:用流程规避风险

标签: 产品管理 风险 | 发表时间:2011-08-09 09:27 | 作者:劣松 Dynamic
出处:http://ucdchina.com/rss/all

最近一直在跟的一些项目,过程中出现了一些反复,原因有很多。深入分析一下问题根结,希望以后能避免。

关键词:产品负责制、确认层级机制、产品脊梁、靠谱

问题:
1、项目初期,产品原则已经开会统一、皆大欢喜,但中期却在产品原则上出现分歧。甚至在产品面临上线时,还有人为该产品赋予新的定位。
2、产品设计环节中,在产品需求和定位已确认的情况下,纠结在“不符合需求、偏离定位”的设计细节,僵持不下、浪费时间、拖垮精力。
3、跨部门合作的项目,设计部门提交的工作结果,经常被他们自己的上层或左右推翻重来,即使对产品有利,却伤害整个项目,伤害自己人。

根据这些问题,需要问很多为什么。

为什么初期统一过产品原则,中期却出现原则上的分歧?“发起分歧者”所具备的必要条件是什么?

首先需要问公司:产品负责制,到底有没有明确和落实?其实,产品人员已经也应该,把对产品的长期责任,承担在自己身上。但是公司层面和总监层面如果没有强有力的确认产品负责制的归属,我们这种自我承担的产品负责制,永远不会在关键时刻发挥作用,而只会左顾右盼。

在产品负责制尚不明晰的情况下,即使团队核心成员开会确认了产品原则,也永远不会有一个强有力的角色把产品原则贯彻到每一个阶段,初期产品定位和产品原则的会议确认,是没有力度的,只是表面上的统一而已。

原因很简单,当一切顺风顺水、条条大路通罗马的时候,旅游团众大佬必然跟着美女导游就OK了。当路遇挫折时,导游就算熟悉路途中的险恶,也仍然不是无法把自己伪装成团队的菩萨,左右不了各位大佬的想法。(默契,可以克服这一问题。但在大公司的营盘里面,想培养一个默契而完整的项目团队,一般是可遇不可求的。但默契的产品小组还是有的。)

在以上这种情况下,发起分歧者有什么必要条件?一是长期跟进产品,了解最初的产品原则和定位;二是了解整个团队的工作重心和产品市场情况,而不是只熟悉自己所管部门的情况。可悲的是,熟悉了以上两点的人,往往不会做出不靠谱的决策,而去伤害整个项目。

既然已经确定了产品需求,为什么会出现“不符合需求、偏离定位”的设计细节?为什么会在这种问题上浪费时间?

这种问题出现非常正常,当设计人员没有做充足的竞品分析,也没有充分理解产品的情况下,总会在设计时出现偏差。只要产品人员说明需求和修改原因,说服设计人员回归需求即可。可怕的是“僵持不下”,设计人员坚持己见,认为设计细节是正确的、靠谱的、符合产品需求的,产品人员却无法认同。僵持不下时,应该搁置问题,继续推进项目,而不是在这种问题上纠结一个下午,还把各种用户调研、应用实例搬出来说理。

最终做决定时,如果依旧僵持不下,那么谁对产品长期负责,谁做决定。谁对产品长期负责?回归的上一个问题。

为什么“工作结果”可以推翻重来?谁赋予了提交者“提交的权利”,又是谁赋予了推翻者“推翻的权利”?

首先要问的问题是:是不是根本没有明确“确认层级”的工作流程,或者只是口头明确、表面默契而已?
比如一个设计稿,当然要由直接负责人A确认,没有问题了,再交到下一步去执行。那么这个负责人A需要评估:自己是否能够保证这一个确认结果是最后结果。如果不能保证,那么再提交上一层的负责人,让他确认。但如果上层负责人曾经授权了负责人A的确认权限,就不应该在A已经确认之后,轻率的推翻确认结果。

在这种确认过程中,应该在每一个项目实施之前明确“相应的设计工作,需要有相应的确认层级”,这一点至关重要!“确认层级”都不明晰的情况下,首先应该检讨的不是设计质量没有达到要求,而是为什么会出现这种流程上的漏洞,让不符合设计质量的东西推进到下一步骤。漏洞不堵住,就没有资格反复插手,这样既伤害团队,也拖垮自己。

相反,当指定了项目设计工作的确认层级之后,再出现提交设计稿不合格、推翻设计工作不符合流程的情况,就可以明确的质疑“提交的权利”和“推翻的权利”,是否符合“确认层级”的流程。这个时候,是能力问题的就调整确认层级或更换负责人、是流程问题的就贯彻流程,比大家互相装无辜更加务实。

最后感叹一下,产品经理是妥妥的炮灰,哪个环节出问题,都可以揭出产品规划和项目管理的漏洞和伤疤

一个产品项目,从立项、交互、视觉、开发、测试等各个阶段,总会因为各种问题而反复伤害。尤其是跨部门合作、多环节配合的流程,伤害问题发生的隐患比比皆是。这个过程期间,产品经理的职责,就是想尽办法,避免各种伤害的发生、避免各种伤害打击到核心成员、伤及团队重心。

可悲的是,在大部分环境下,卑微的产品人员不仅无法预估各种隐患问题,对于已经发生的伤害问题也没有足够的防备资源和职权。这个时候,产品经理,就是妥妥的炮灰,众口一铄,灰飞烟灭。最后,产品经理仍然必须站起来,拖着被各种问题所累的核心成员,继续把项目推进下去。

不知道这种情况,在其他公司是否常见。当没有固化的产品负责制和确认层级管理机制的时候,深埋问题的跨部门团队开发产品,然后暴露出一堆问题,一遍又一遍的伤害每一个产品。所以,这种公司总是出现一堆一堆的打折产品,承担着一堆又一堆不给力的数据和市场境况,最后担责到产品人员身上,该调走的调走、该跳槽的跳槽,再招进下一批未知轻重的欣欣向荣者,如此反复、以至无穷。

关键角色位置的靠谱牛人,是产品的脊梁

产品团队,碰到这种复杂的情况,唯一的救命稻草,就是产品各环节的关键位置,有靠谱的关键角色把持,然后这类关键角色需要保持持续的头脑清醒、精神集中,在任何阶段都能回溯最初的产品原则、评估当前的团队重心和高层要求,统一麾下执行者的行动,并说服高层。从这个角度讲,没有那么多流程管理和部门配合的小团队产品和创业公司产品,要更加安全、更加靠谱。近期组里的一个小众产品,没有大资源投入、没有多部门合作、没有高层压力、没有战略意义,虽然选择了一条难路,但整个产品从设计到运营,让外人看来,显得张弛有度、节奏明确,这就是一个明显的例子。

只要人靠谱,做什么都是靠谱的。如果人本身不靠谱,在任何角色上,都会出问题。至于什么问题:细节不到位、文档及版本控制逻辑不清楚、决策前后矛盾、协调成员配合乏力、工作重心聚焦不正确、沟通不主动……比比皆是。

希望自己靠谱一点。

 

源地址:http://www.lyingsong.com/?p=334

相关 [产品管理 风险] 推荐:

产品管理:用流程规避风险

- Dynamic - 所有文章 - UCD大社区
最近一直在跟的一些项目,过程中出现了一些反复,原因有很多. 深入分析一下问题根结,希望以后能避免. 关键词:产品负责制、确认层级机制、产品脊梁、靠谱. 1、项目初期,产品原则已经开会统一、皆大欢喜,但中期却在产品原则上出现分歧. 甚至在产品面临上线时,还有人为该产品赋予新的定位. 2、产品设计环节中,在产品需求和定位已确认的情况下,纠结在“不符合需求、偏离定位”的设计细节,僵持不下、浪费时间、拖垮精力.

敏捷流程中的产品管理

- - 人人都是产品经理
对于敏捷开发,讲它的价值、方法的内容已经够多. 而对于需求、设计、测试这三个环节,如何适配并融入敏捷开发的流程,却着墨寥寥. 本文主要从产品设计及需求表达两个方面,介绍如何在敏捷开发的背景下,保证产品设计不挖坑,并为开发人员提供的高效支撑. 文中所述适用于中小规模的团队,产品形态以web端非成熟期产品为最匹配.

产品管理的前世今生—昨天

- Frank Cai - 《程序员》杂志官网
作为“产品管理的前世今生”系列文章首篇,本文介绍了产品管理体系所依赖的理论基础、所属的学科范畴、经历的阶段以及一些常识性的概念错误. 说到产品管理体系的诞生,问10个产品管理者,会有9个告诉你宝洁的故事. 确实如此,国内几乎所有的产品管理者,不分行业,都无一例外地知道产品管理者诞生于宝洁公司,并以此作为工作的标杆而津津乐道.

产品管理过程的核心管控方法

- - CSDN博客推荐文章
产品管理过程是一个复杂过程,好的管理者都知道如何抽丝剥茧,让复杂的过程简单化. 最近也有很多人问我,我们在产品管理过程中有什么好的思路可以分享. 首先,我相信不同的PM有不同的方法,没有所谓的一定最好,只有通过实际环境使用过才能逐步形成自己靠谱的方法. 抽出一些时间,我把我认为较为有效的经验大致整理了一下分享给大家.

《Scrum敏捷产品管理》读书笔记

- - CSDN博客研发管理推荐文章
提到产品管理,在Scrum中,首先就想到的角色是产品负责人. 因此我们先来看看产品负责人(Product Owner),以及这个角色的特征:. 然后对于大型产品而言,一个产品负责人是不够的,所以存在产品负责人扩展的问题. 对于产品负责人,常见的问题有:. Kano model (卡诺模型)可以帮助我们选择合适的功能,开发出吸引人的产品.

文章: 从关系数据库向NoSQL迁移:采访Couchbase的产品管理主管Dipti Borkar

- - InfoQ cn
尽管关系数据库用于存储数据已经有几十年的历史,而且对很多用例而言,这仍然代表着一类可行的方案,但NoSQL正在成为人们当前的选择,尤其是考虑可伸缩性和性能的时候. 本文是对Couchbase的产品管理主管Dipti Borkar的采访,主要谈到了从关系数据库向NoSQL迁移的挑战、收益和过程. QCon北京2013,架构设计,大数据云计算等十八项专题,1月6日前报名7折.

创业风险面面观

- Vincent - FT中文网_英国《金融时报》(Financial Times)
这是每一个想创业的人必须回答的终极问题. 在你开始创业之前,请认真思考一下,自己是否真的具备创业的决心和迫切欲望. 因为在生活中,荣耀的代价向来不菲,而在这个特殊的竞技场上,对于大多数人而言,代价可能更为高昂. 毕竟,当你不惜一切代价投身事业之时,“一切代价”不只是说说而已——它很可能成为现实. 你不能简单地仅以自己的资金来衡量创业的风险.

单面煎蛋,拿风险换美味

- ZX - 谣言粉碎机 - 果壳网
流言: 单面煎鸡蛋无法彻底杀死蛋内的残留细菌,容易引起恶心、呕吐和腹泻等中毒现象. 除此之外,生蛋白还会阻碍身体吸引维生素H,如严重的话,会导致皮疹、皮肤炎、脱发等状况. 真相: 鸡蛋是一种比较容易受到细菌污染的食品. 如果母鸡完全健康,刚刚下的鸡蛋中倒也不会有过多细菌. 不过,这种理想情况毕竟不大可靠,通常的母鸡体内可能会有一些致病细菌.

Godaddy的域名注册风险分析

- 0M - 月光博客
  据南方都市报的报道,国内知名的电影资料库网站时光网被关的原因终于有了答案,时光网关闭据称与涉黄有关,万网的工作人员称,万网是接北京市通信管理局的通知,称时光网“传播色情、淫秽”,因而停止了对该域名的解析,该工作人员还说,该通知并没有明确恢复解析的期限,“如果想恢复,必须找北京市通信管理局或者工信部.

使用ifttt背后的巨大风险

- Jack - 月光博客
  ifttt,是一个新生的网络服务平台,通过不同其他平台的条件来决定是否执行下一条命令. ifttt基于任务的条件触发,类似编程语言,让用户可以根据他们设计的流程设计一些小程序,让网络服务能够对某些行为作出反应.   ifttt 是一项创造性的应用,但是我和我的朋友们必须重视其背后隐藏的风险. this 称为 trigger,而 that 称为 action.