T公司做互联网个人软件的,其WEB相关的产品经理(PM)都很“盲”,网盲的盲。因为这些人大都是刚毕业就找过来的,没有任何经验的毕业生,而且很多都是和互联网专业不相干的,在到公司之前甚至都不了解公司的产品。他们每天背负的任务只有一个――“收入”,很少去研究行业发展和相关产品,更不要提如何做好产品的设计了。
有事实为证:某PM到其他部门同事的座位上讨论产品,看到同事正在使用一个竞争产品,该PM问:“这个是什么?!感觉很不错呀!”。实际上这个竞争产品已经出来很久了,而且在业内较有名气,作为产品经理他们竟然不知道。当设计师仔细告诉这个产品是什么、怎么用、怎么好以后,他们回到座位依然会打电话问“那天你用的那个xxx是什么来着?怎么下载?”。同事晕倒。
他们的PM和UE之间经常这样合作:PM突然想出来一个好的赚钱的点子(或者上头因为“业绩不好”压过来一个任务,他们又想出来了一个“强奸用户”的办法),什么都没有准备或者只准备了一个“项目说明”,描述”我们想达到什么目的”,然后就直接拿跑去跟UE的同事说:我们有一个新项目,要怎么向用户收钱,你给我们“交互一下”吧…
B公司做互联网社区,他们的PM个个都是“职业网虫”,对于互联网和自身业务理解非常深。这些人大都是从各大互联网社区中挖掘出来的,也有很多是专业非常对口能力很强的高才生。他们没有收入指标只有简单的流量压力,每天在想的事情就是如何为网站创造更大的流量更好的粘度,从而卖掉更多的广告。他们对于产品设计也有自己的理解,但对于界面设计这种他们认为“很无关紧要很容易”的事情向来不屑一顾。
之所以说他们是“职业网虫”是因为他们每天都混迹在中国各大网站上,每天都在不停的关注着业界动态和网站数据,不停的分析和体验着用户的行为。互联网上新出来的东西他们总是第一个先接触,互联网上所有的“意见领袖”他们都很熟悉,他们每个人都有自己的博客,在各大社区上都有自己的马甲…
接下来也说说他们和UE之间典型的工作方式:当要发起一个项目时,PM从来不会和任何其他部门的同事商量,他们只会在自己部门内部讨论并直接形成“结论”,然后他们会成立小组,所有小组成员分工撰写详细的PRD。PRD的详细程度甚至到“界面上的某个按钮应该放在什么位置,应该多大”。等PRD写完之后,回去找UE的同时进行“设计”,并要求每个设计细节必须遵照PRD…
有事实为证:某PM到其他部门同事的座位上讨论产品,看到同事正在使用一个竞争产品,该PM问:“这个是什么?!感觉很不错呀!”。实际上这个竞争产品已经出来很久了,而且在业内较有名气,作为产品经理他们竟然不知道。当设计师仔细告诉这个产品是什么、怎么用、怎么好以后,他们回到座位依然会打电话问“那天你用的那个xxx是什么来着?怎么下载?”。同事晕倒。
他们的PM和UE之间经常这样合作:PM突然想出来一个好的赚钱的点子(或者上头因为“业绩不好”压过来一个任务,他们又想出来了一个“强奸用户”的办法),什么都没有准备或者只准备了一个“项目说明”,描述”我们想达到什么目的”,然后就直接拿跑去跟UE的同事说:我们有一个新项目,要怎么向用户收钱,你给我们“交互一下”吧…
B公司做互联网社区,他们的PM个个都是“职业网虫”,对于互联网和自身业务理解非常深。这些人大都是从各大互联网社区中挖掘出来的,也有很多是专业非常对口能力很强的高才生。他们没有收入指标只有简单的流量压力,每天在想的事情就是如何为网站创造更大的流量更好的粘度,从而卖掉更多的广告。他们对于产品设计也有自己的理解,但对于界面设计这种他们认为“很无关紧要很容易”的事情向来不屑一顾。
之所以说他们是“职业网虫”是因为他们每天都混迹在中国各大网站上,每天都在不停的关注着业界动态和网站数据,不停的分析和体验着用户的行为。互联网上新出来的东西他们总是第一个先接触,互联网上所有的“意见领袖”他们都很熟悉,他们每个人都有自己的博客,在各大社区上都有自己的马甲…
接下来也说说他们和UE之间典型的工作方式:当要发起一个项目时,PM从来不会和任何其他部门的同事商量,他们只会在自己部门内部讨论并直接形成“结论”,然后他们会成立小组,所有小组成员分工撰写详细的PRD。PRD的详细程度甚至到“界面上的某个按钮应该放在什么位置,应该多大”。等PRD写完之后,回去找UE的同时进行“设计”,并要求每个设计细节必须遵照PRD…
T公司的这种情况造成的后果是:他们的设计师往往很累,项目进行的更累,而且容易出现设计和需求的偏离。
设计师在设计之初都很难真正理解PM的具体需求,PM也没有能力描述清楚需求,导致项目总是在不停的反复。甚至往往由于时间关系,产品设计稍微达到预期就得上线,不能做到本可以达到的更好效果。在这里设计师走着走着成了产品的主导者,最终很容易就发现产品的发展偏离了原始的方向,按照设计师那个不完整理解的构想走了…
设计师在设计之初都很难真正理解PM的具体需求,PM也没有能力描述清楚需求,导致项目总是在不停的反复。甚至往往由于时间关系,产品设计稍微达到预期就得上线,不能做到本可以达到的更好效果。在这里设计师走着走着成了产品的主导者,最终很容易就发现产品的发展偏离了原始的方向,按照设计师那个不完整理解的构想走了…
B公司的这种情况造成的后果是:对于设计并不擅长的PM在做设计,设计师成了摆设。设计师成了“界面”的制作者,很少能够真正参与到设计。
遇到对于项目要求比较简单的产品还好,最多只是细节设计出现一些比较白痴的问题。等遇到对于设计要求较高的产品时(比如交互要求很强的软件产品),PRD文档的“直线描述方式”不能表达清楚完整的产品设计。由于PM坚持自己主导设计,结果导致设计一团糟,而本可以做好设计的设计师却没有机会参与到其中。项目拖延时间,公司蒙受损失。在这里产品经理成了设计师,一个按钮一个颜色都会产生争执,最终的产品设计不是极其普通就是极其糟糕,更好的设计效果不能出来。甚至陷入到了产品的细节难以自拔…
遇到对于项目要求比较简单的产品还好,最多只是细节设计出现一些比较白痴的问题。等遇到对于设计要求较高的产品时(比如交互要求很强的软件产品),PRD文档的“直线描述方式”不能表达清楚完整的产品设计。由于PM坚持自己主导设计,结果导致设计一团糟,而本可以做好设计的设计师却没有机会参与到其中。项目拖延时间,公司蒙受损失。在这里产品经理成了设计师,一个按钮一个颜色都会产生争执,最终的产品设计不是极其普通就是极其糟糕,更好的设计效果不能出来。甚至陷入到了产品的细节难以自拔…
(以上为两种极端情况的假设,请勿对号入座)
其实这里存在一个最基本的问题:产品经理是应该只给出简单需求,还是应该直接给出设计方案?
我的答案是:两种极端都不行。
我的答案是:两种极端都不行。
angela写“如何了解用户”的时候我们回复说:“其实所有的用户研究最主要的问题就是解决:‘用户需要什么,用户希望要什么’”。同样的道理拿到这里通用:
如果你渴了,希望我帮你解决这个问题。那么不要告诉我“给我来碗稀饭”,这样我没法了解你的真实需求,如果恰巧我没有稀饭,你只好饿着;也不好只告诉我“我渴了”,这样在我有水又有稀饭的时候,可能只会给你一杯水,不便于我直接给出更合理的方案(对于水和稀饭其实你更想要稀饭);你可以告诉我“我渴了,给我来碗稀饭吧”。如果有稀饭,我会直接给你。如果有水没有稀饭,我会说“我给你来碗水吧。现在没有稀饭”。
如果你渴了,希望我帮你解决这个问题。那么不要告诉我“给我来碗稀饭”,这样我没法了解你的真实需求,如果恰巧我没有稀饭,你只好饿着;也不好只告诉我“我渴了”,这样在我有水又有稀饭的时候,可能只会给你一杯水,不便于我直接给出更合理的方案(对于水和稀饭其实你更想要稀饭);你可以告诉我“我渴了,给我来碗稀饭吧”。如果有稀饭,我会直接给你。如果有水没有稀饭,我会说“我给你来碗水吧。现在没有稀饭”。
如果只给出简单需求,会大大提高沟通的成本,特别是设计师理解需求的成本,往往会造成设计过程的反复。如果直接给出设计方案,势必造成设计师没有发挥的空间,而PM不是专业的设计者(或者说没有时间、或者不应该深度参与到具体设计中)却要主导设计的所有细节,最后造成糟糕的设计成果。
所以,我并不赞成Banlon和子条他们说的:“老妈子就是老妈子,妹子就是妹子,哨子就是哨子”。哨子不只是有必要告诉老妈子今天街上是否热闹有多少客人,还有必要建议老妈子今天让什么样的妹子先出台,什么样的妹子可以在后面等更有钱的主,但只是建议;老妈子也不只是应该把客人分配给妹子,还有必要建议妹子用什么样的方法对付什么样的客人,但只是建议。老妈子不能代替妹子伺候客人。
所以,我并不赞成Banlon和子条他们说的:“老妈子就是老妈子,妹子就是妹子,哨子就是哨子”。哨子不只是有必要告诉老妈子今天街上是否热闹有多少客人,还有必要建议老妈子今天让什么样的妹子先出台,什么样的妹子可以在后面等更有钱的主,但只是建议;老妈子也不只是应该把客人分配给妹子,还有必要建议妹子用什么样的方法对付什么样的客人,但只是建议。老妈子不能代替妹子伺候客人。
绕了这么多,其实想说的很简单:
什么人做好什么事,是规矩。但如果什么人只管做好什么事,就是团队最大的忌讳。协作才能真正提高效率。
PM的需求文档不应该只是需求,还应该有粗糙的够“解释需求”的“设计方案”。设计师拿到需求时应该结合PM的“设计方案”去理解需求,这样更快也更直观。但PM的“设计方案”只是为了说明需求的“方案”,对于设计只是 建议,不是必须遵循的“方案”。
什么人做好什么事,是规矩。但如果什么人只管做好什么事,就是团队最大的忌讳。协作才能真正提高效率。
PM的需求文档不应该只是需求,还应该有粗糙的够“解释需求”的“设计方案”。设计师拿到需求时应该结合PM的“设计方案”去理解需求,这样更快也更直观。但PM的“设计方案”只是为了说明需求的“方案”,对于设计只是 建议,不是必须遵循的“方案”。
转载出自UCDChina