产品经理,请不要再对工程师说“我只要结果”

老实说,我个人很不喜欢那种对着工程师叫嚣“我只要结果”的产品经理。除非你是公司的CEO或者CFO,否则我不认为你有理由回避过程的复杂性。最起码的要求是,相关产品在用户面前所呈现的业务信息量,产品经理应该100%地了解。举个简单例子:如果校内网的产品经理无法向用户解释“如何将一个好友添加为‘特别好友’”,那就太失职了,至少我认为是失职的。

在我自己控制的产品中,我一定是要了解所有业务细节的。由于项目繁忙,我也曾将手头已经拿到的项目转手外包给第三方开发团队,自己做起“产品经理”。作为产品经理去领导工程师,如果高高在上的提出一个粗略的要求就像等结果,99%会荒废掉这个项目。和工程师打交道,“尊重”两个字最重要。你能想象一个工程师是这样工作的么:

(虽然是老图了,感谢Fenng的及时分享)

具体实施起来,除了基本的劳动报酬尊重外,更需要尊重对方的,是明确的需求和时间表(Schedule)描述:一定要面对面对着屏幕将需求说清楚,细化到每一个按钮点击后的效果,并且制定好时间表,否则工程师提交回来的成品八成是一个“四不像”。

而作为工程师或者Vendor,我很难说服自己去会为一个不懂HTML的产品经理效劳。结合06年到现在许多项目的经验来看,至少在我coding的时候,是希望能有一个规范的阶段需求说明的。产品经理毕竟不是PR、市场总监,没有必要把大把的时间和精力放在产品之外的地方;产品经理也不是创意总监,不需要每天都有新点子冒出来,而程序逻辑更是严谨的算法实现,再flexible的架构也无法满足所有的业务需求,简单点说,你不能今天让我开发一个Twitter明天就让这玩意像Facebook那样工作。即便是Prototype阶段的开发也做不到。当然,工程师对于尊重自己的产品经理,则应以“责任”为报答

总之,“产品经理”这个title已经被滥用了:越来越多不适合做产品经理的人开始做起了产品经理。这是一种事倍功半的分工:他们对公司赋予产品的期望一无所知,又不知如何与工程师们沟通、交代需求。往往一个很不错的点子胎死腹中。真正优秀、称职的产品经理,其工作强度绝不亚于研发工程师。如果一家公司的工程师都忙得加班到凌晨转钟,而产品经理们还在家里睡大觉的话,八成这家公司离死亡不远了。只可惜我们的工程师没有“罢工意识”:“长痛”肯定比“短痛”更痛苦的。

PS,近期更新缓慢,我真的很累,附图一张。大家猜猜墙上是什么:)

揭秘:墙上其实是一个ActionScript类。由于太大,而且历经多个版本的修改,因此我将一个历史版本贴到了墙上,laptop上小字看起来实在太累:(看来还是有不少朋友猜对呢,哈哈:)