• 2008年11月30日

    运营官札记:需求方 vs. 管理者

    版权声明:转载时请以超链接形式标明文章原始出处和作者信息及本声明
    http://www.blogbus.com/ittalks-logs/31964845.html

    本篇的语境是一个网络公司,不是其它类型的公司。

    项目的需求方,不应该成为项目的管理者;一个管理者,不应该成为项目的需求方。

    这是我很鲜明的就项目执行方面的一个观点。这个观点,看似顺理成章,但在实际操作中,有非常多的人,其实是反其道而行之的。

    比如说,类似于“产品经理在很多企业里,几乎没有实权,这是不对的”这种说法得到很多人的认同。但如果按照我的观点,这是天经地义的。产品经理当然不应该有实权(底下管两个产品助理不在此例)。

    我们来看看需求方和管理者究竟都需要干些什么。

    需求方最核心的职责就是明确你的需求,或者说,清晰地拉出你的需求清单以及需要完成的时间进度。业务单位和开发单位互相经常会出现彼此无法理解的囧境(在网络企业里,业务单位和技术开发单位,在我看来,压根就是两个国度操着不同语言的人),于是需要一个类似于需求分析者的角色来做“翻译”。这被我称为所谓的“产品经理”(但我更愿意用项目经理来称呼,有鉴于一致的误解,我就不再喋喋不休地告诉各位叶公好龙的叶其实是读she的)。

    所以,需求方的职责就是两个:明确需求,明确时间。至于这需求如何完成的,甚至是如何最优化完成的,不是需求方的事。既然不是ta的事,ta又需要什么样的实权去push各类开发人员呢?

    管理者需要干什么?就是带领ta的手下去努力完成各类需求,并且,最好是最优化地完成。这里面涉及到具体的方案选型,也涉及到给手下不断地打气,还涉及到评估手下的工作情况。

    所以,管理者的职责就是:保时(遵守时间)保质(选型最优)保量(不缩减需求)地督促带领自己的团队去完成需求。为了做到这点,ta是有实权的,可以成为一方面的主管。

    所以,需求方完全没有必要成为管理者,如果非要去成为管理者,那是这个企业的协同作战机制出了问题,用一个错误去弥补另外一个错误。

    好了,我们现在再来看看另外一种经常出现的企业错误,那就是管理者去充当需求方。

    管理者最大的优势在于ta握有资源,但如果得不到某种程度上的限制,ta就会无限制地去使用ta的资源,比如说:无限制地扩大ta的需求,或者以个人偏好去决定需求的优先层级。

    如果这个管理者仅仅是部门leader级的管理者,问题还不算太大,但如果这个管理者是企业高层级的leader,可能会引发不必要的麻烦,以及,判断上的失误。

    作为管理者,要懂得接受需求方的需求制约,这是需要一些智慧的。而作为需求方,要明白自己的工作界限,轻易不要插手执行部门的内部事务,同样,需要智慧。

    这不是在比谁的头衔大,也不是在比谁的资格老,这是一种职业的专业精神,是一种修炼。

    分享到: