隐性KPI:对项目管理的合理追求

2019-04-17    来源:劣松的博客

容器云强势上线!快速搭建集群,上万Linux镜像随意使用

问题:在产品发展和项目推进过程中,如何追求项目管理的科学性和合理性,是恰当的?

下文中提到的所有项目管理观点,全部都以“利于产品发展”为最高优先级的大前提,其他利于团队团结、公司发展等细节都次之。(当然都是可以方向一致、相辅相成的,你懂的。)

在一个产品发展过程中,根据架构背景、项目背景、产品背景三个方面的因素,综合考虑当前项目管理的最后方案,才能保证“利于产品发展”的目标。三个背景缺一不可,少评估一个,就多一份风险,默默的埋藏在执行过程中,并且很难被再次发现。

将三个层面的背景梳理清楚,才有可能综合的判断问题根结,假设:

架构背景:

1、产品、运营、视觉三个方面的跨部门合作;

2、各个部门中的团队考核标准不同,晋升机制不同,团队氛围不同;

3、各个部门中团队,前期没有进行过磨合,并且供职于不同领域的产品;

项目背景:

1、产品上线初期的快速迭代优化状态;

2、竞争市场非常激烈;

产品背景:

1、社区产品,依据线上情况及需求变动,随时作出产品动作;

2、产品负责制,说白了,就是产品部门说了算,并对产品最终负责;

“架构背景”所导致的实际问题:

Q1:架构背景不同,导致:团队之间的思维模式及个人愿景不同(架构无法改变)

Q2:不同的思维模式及个人愿景,导致:合作过程中的细节及方向分歧

Q3:细节及方向分歧,导致:合作过程中的过度讨论及精力消耗,以及最终决策权的实施

Q4:在消耗精力的讨论过程中,反复由产品实施最终决策权,导致:产品负责制的外在表现更强,即产品强势

Q5:产品强势,导致:其他非产品团队成员的工作归属感减弱、工作挫折感增强

面对可怕的Q5,当其他非产品团队成员怨声载道的时候,如何很好的解决这个问题?这也是我们目前要做的选择。

PS:在架构背景不同的前提下,尝试统一思维模式,让不同团队的个人愿景与产品愿景一致。能做到吗?

答:当然可以用各种方式统一跨部门、跨地域团队的个人愿景与项目愿景,比如项目宣讲、团队洗脑。但要质疑的是,这种仅限于表层的苦口婆心,是否真正能够战胜不同的架构背景?在当前的产品背景和项目背景下,我认为不可能。此类产品及项目背景,决定了该项目属于创业项目(大公司也有无数个创业型项目),这种创业项目,不允许让项目核心成员把精力聚焦在团队默契培养和远景统一方面。

如很多同行所说,大公司里搞创业产品,困难比创业公司更大。就是这个原因吧。

产品初创期间,没有一个强有力的默契的大团队,就已经是危险的了。面对这种困难,选一条错路来与架构背景死磕,就更危险了。

下面看看各种解决方案的优劣:

针对Q5的解决方案1:

1、制定明确的需求确认过程,三方或N方共同确认,由产品方面组织,说服各方,正正规规的抹平分歧,降低产品强势的感觉;

2、制定明确的流程控制策略,明确各个环节的时间节点和责任人,并跟踪各节点,控制流程进度,拉平产品部门与其他部门的地位,克服产品部门的封闭感。

即,侧重法制。

方案1的风险:

风险1:对抗“产品强势”而做出的流程设计,导致:合作过程中的需求确认更加严谨、分歧讨论更加频繁、进度控制更加流程化,即“死板的需求、无谓的讨论、机械的流程”。

比如:需求管理无弹性,导致试错成本增大,让各方需求提出更加谨小慎微。为需求做减法,可不是以扼杀积极性为基础。

分歧讨论的频繁发生导致各参与成员逐渐形成逃避分歧的行为惯性,或者导致各个参与成员在无谓的细节中浪费大量时间。

进度控制流程化导致任务质量与时间节点之间的矛盾更加突出。

风险2:“死板的需求、无谓的讨论、机械的流程”,导致:各个团队之间的合作关系比较机械,即将合作过程中的社会规范变为市场规范。

比如:过去我可以跟其他团队成员,共同完成一个作品。现在,我是让其他团队成员为我的产品完成一个任务。

面对靠谱的合作人,我可以因为更高的质量,而放宽时间进度。现在,时间进度的死板与分歧讨论的挫折感,让我与他都开始不自觉的规避违背流程的事情发生。

最终,冰冷的市场规范与无谓的时间浪费,导致:迭代速度下降、产品决策效率降低,影响产品健康度。

标签:

版权申明:本站文章部分自网络,如有侵权,请联系:west999com@outlook.com
特别注意:本站所有转载文章言论不代表本站观点!
本站所提供的图片等素材,版权归原作者所有,如需使用,请与原作者联系。

上一篇:博客和论坛链轮的操作步骤与技巧

下一篇:浅谈项目管理(二)