三权鼎立形式的软件开发方式

什么是三权鼎立形式的软件开发方式？估计所有的开发者都听说过瀑布式开发模式，xp测试驱动开发模式等等，这是从软件的开发方法来说；而我要说的，是催生软件最终成型/上线所需要的公司组织架构模式的，跨部门，跨组协作方式的软件开发方法。二者着眼点完全不同。

根据互联网源远流长的来源，几乎从一开始（实际也不长，在国内顶多十几年时间），互联网公司的领导者们就发现了一个尖锐的矛盾，那就是用户体验（UED）和开发出的软件的易用性方面的矛盾。简单来说，就是开发者开发出来的互联网产品，自己觉得相当满意，经过一番颇费口舌的培训和讲解之后，各部门领导和老板也都很满意；然而网站上线，产品发布之后，纷至沓来的互联网用户却不买账，不这么看，他们可能普遍觉得你这个互联网网站/产品，非常的难以使用，自己想浏览的内容很少或者干脆没有，换句话说，这个网站不具有粘性，用户不乐意在这个网站久呆，或者不乐意将网站放入收藏夹下次再来。
这成了互联网初期一个非常伤脑筋的问题，至少老板很受伤，程序员则悠然自得。
为了解决这一问题，聪明的老板马上想到，可以组织一个新的部门，对程序员开发网站进行监督和牵制，同时，还有一个好处，也可以在不懂技术的领导，总监们和技术人员之间架起一个桥梁，起到润滑和交流沟通的作用-于是产品部门应运而生了，这是一群介于技术人员和领导之间的群体。他们本身可以懂，也可以不懂技术，但却引领技术人员，设法灌输领导，老板的思想，同时，最大可能的考虑用户体验。某种意义上，产品人员是一个互联网网站/产品的最初用户，经过了产品人员的把关，再通过互联网站输出自己的产品，思想等，显然比从程序员直接输出要好很多。可以说，在互联网初期，这是一个伟大的变革。
因为产品部门的诞生，非常好的解决了程序员，公司各级领导，公司业务部门（运营，销售，BD等）以及用户之间的种种矛盾。

互联网初期，几乎就是产品和技术两大部门在互相合作。若干年后，一些先驱者开始提出测试驱动及若干测试理论，论证了测试的重要性，这时，QA部门粉墨登场了。至此，三权鼎立的三大部门，产品，技术，QA全部出现，并且巧妙的实现了互相制衡的作用（这一点本文不论述），一直沿用到现在，虽然在实践的过程中，在不同公司文化的沉淀中，产生了各种不同的侧重形式。但是根据笔者的经验，只要是沿用了这种组织架构方式来进行软件开发，那么结果通常就是，delay,delay再delay.
幸好有一句话解除了delay所带来的困惑，那就是在互联网的世界里，大力赞成缓慢发布。

为什么肯定的有delay说呢？我们先来看产品部门。随着时代前进的步伐，产品部门从初期的利大于弊的地位，渐渐的需要重新界定了。
首先，一个众所周知的问题，在这三方中，通常技术人员的薪资比较高，而做黑盒测试的QA人员薪资处于最低或者和产品设计人员持平。因为这个原因，非常容易造成基本产品设计人员和测试人员都是一些初出茅庐的新手，同时为了更好的使用户满意，我们也更趋向于招聘一些不太懂互联网的人，用他们的思维角度去设计各类网页页面，因此，大量产品设计人员的水平可想而知（不包括精细算法，用户行为心理研究等高精尖专的产品设计人员，这类产品人员往往自己以前也进行过编码和程序方面的专业积累，水平令人尊敬）。
相反的，开发人员则很多是在互联网行业有多年从业经验的开发者，然而这种开发模式中，首先假定了开发人员根本不懂UED。
随着互联网时代的不断深入，可以说，现在的程序员，有哪个在开发互联网站之前，自己没有访问过任何网站呢？对于一个网站上基本的功能，例如CRUD，列表页面显示，图片，文件上传下载，视频音频播放等，有几个程序员没有自己亲身访问过呢？用户体验（UED）已经不再是用户和程序员之间的障碍，一个提交按钮应该怎么放置，相信一个初级程序员也懂得。可以毫不夸张的说，大部分程序员本身已经可以担当起基本产品人员的职责。
起根上说，对于那些完全不懂技术的产品人员设计，由于他们本身不具有开发人员的很强的逻辑思考行为，所以设计出的网站，产品的种种功能，基本上都不能自圆其说，可以说是漏洞百出。设计样品交到开发人员手中，稍微揣摩就会发现很多漏洞，这个时候只能再打回重新进行设计，时间首次被delay。然而更糟糕的是，由于各种历史原因，如果遇到在这一环上非常较真的产品设计人员，明知是错，也绝不承认。在这种互相扯皮的状态下，往往是开发者明知道这样行不通，也只好按照错误百出的方案进行编码。其结果可想而知。

其次，随着时间的推移，产品部门的一些弊端渐渐被放大并传播开来。到现在（2011年），已经形成了一些固有的思维模式。几乎所有的公司都有绩效考核，技术人员需要绩效考核，产品人员和QA测试人员也需要。这就直接带来了部门间的利益冲突。在利益驱动下，不言而喻，产品人员是不希望技术人员按时完成任务的，通常无论技术人员怎样努力，都会被各种设计变化所包围而拖延工期，正所谓计划赶不上变化。那么，此时通常再次delay，而不明就里的领导，显然倾向于把责任归咎于技术人员。往往总监级以上的领导，不懂技术，不是技术人员出身。也不愿意给技术人员话语权，更愿意倾向于产品人员(有更多的共同语言？)。
同时，经常的，还需要产品人员来带领这个项目和团队。可是，如果这个产品人员是新手，正好应了一句老话，兵熊熊一个，将熊熊一窝。
从自己多年开发经验上来说，感觉开发者很多都极具理想主义，并且普遍存在严重的偏执狂症状，表现出来就是自信心极度膨胀，不服输，甚至不认错。还可能一些人完全听不进去产品人员的想法，完全脱离产品需求而追求自己的理想状态。这样的开发思维当然必须改进纠正，但同时，产品设计上的需求，在开发时就频繁修订，必然使软件开发的时间delay。

那么，从产品设计到技术实现这个环节上，就已经形成了必然发生的delay。

接下来QA测试人员隆重登场。然而目前国内所说的测试，基本都是指黑盒测试，大致等同于游戏开发那种游戏试玩者一样。当然，需要进行大量的边缘和阈值等测试。前面已经说过，如果遇到那种漏洞百出的设计，而产品人员又拒不承认，其实开发时，开发者已经知道错误百出，那么测试者一经测试，也会迅速发现这个产品到处都是漏洞，错误百出。此时，他们自然而然的觉得这些错误是开发者造成的，开始抱怨技术人员，这样的软件也好意思拿来送测，你们开发部的人都是吃屎的啊，立即挑出无数多bug，打回修订，或者直接以bug过多为由，不予测试（达不到测试要求），打回重新开发。请注意，这个时候产品部门的任何可能的犯过的错误和责任都被忽略了。软件的完成/上线时间再一次delay。

从上面对三者间互相协作的论述，不难看出，以这种方式来完成一个软件，要想按时完成，实在是有些天方夜谭，痴人说梦。而透过这些文字，又清楚的说明，这三者之间，只有开发者，程序员是最辛苦的一群人，需要耗费大量的脑力和体力，不断对软件进行修修补补，只有最终满足要求才可放行，否则必被打翻在地，不得翻身，寝食难安。而其他二者最大的作用就是监督和质量保证。

最后说一点题外话，软件到底是写出来的，还是测出来的，抑或是产品人员设计出来的？一个成型的软件以最大程度体现了软件开发者的思维模式，逻辑习惯甚至宗教信仰，国家出生地等复杂的因素，在行家眼里，她并不是一堆毫无生命力的，冷冰冰的英文字母组合。富有经验的从业人员，不难从这些跳跃着带有个人和地域色彩的思想和逻辑的复杂的代码中，看到软件开发者们深远的具有自身特质的清晰的影像。
然而这种三权鼎立形式的软件开发方式，往往极大的贬低了软件开发人员，毫无理由的提升了其他二者的地位。。。

评论

34 楼 sharong 2011-06-30  

wangshare 写道

如果有这样一只团队，不是三足鼎立的。在这个团队里大家的目标是一致的，团队成员包含设计，开发，qa，对于团队的评估相比个人评估更重要。

that's the point！非常赞同，现在这种三足鼎立的方式，就是弄成3个部门各自为政，各有各的绩效，所以就不是一股合力了

33 楼 wangshare 2011-06-29  

如果有这样一只团队，不是三足鼎立的。在这个团队里大家的目标是一致的，团队成员包含设计，开发，qa，对于团队的评估相比个人评估更重要。

32 楼 dayang2001911 2011-06-29  

抛出异常的爱 写道

技术人员没有职业道德是主要原因。
QA没有足够的能力是次要原因。
设计人员应该是项目成功失败的主要责任人。无论是设计失败，还是沟通失败，进度虚幻 都是他的问题。

说的感觉靠谱了一些
再好的制度，如果力量不向同一个方向用的话也没用

31 楼 dayang2001911 2011-06-29  

抛出异常的爱 写道

comet12345678 写道

互联网成功的产品从来不是产品经理构想出来的。

。。。。。。。。。。。。。互联网产品有99%的想法完善，改变，调整来自产品经理或是由产品经理审批过的。。。。。。。。。

大多数开发工作也是为了完善改变调整。
点子其实不值钱

我觉得程序员应该现实的看待

30 楼 hbyk3344 2011-06-27  

sharong 写道

什么是三权鼎立形式的软件开发方式？估计所有的开发者都听说过瀑布式开发模式，xp测试驱动开发模式等等，这是从软件的开发方法来说；而我要说的，是催生软件最终成型/上线所需要的公司组织架构模式的，跨部门，跨组协作方式的软件开发方法。二者着眼点完全不同。

根据互联网源远流长的来源，几乎从一开始（实际也不长，在国内顶多十几年时间），互联网公司的领导者们就发现了一个尖锐的矛盾，那就是用户体验（UED）和开发出的软件的易用性方面的矛盾。简单来说，就是开发者开发出来的互联网产品，自己觉得相当满意，经过一番颇费口舌的培训和讲解之后，各部门领导和老板也都很满意；然而网站上线，产品发布之后，纷至沓来的互联网用户却不买账，不这么看，他们可能普遍觉得你这个互联网网站/产品，非常的难以使用，自己想浏览的内容很少或者干脆没有，换句话说，这个网站不具有粘性，用户不乐意在这个网站久呆，或者不乐意将网站放入收藏夹下次再来。
这成了互联网初期一个非常伤脑筋的问题，至少老板很受伤，程序员则悠然自得。
为了解决这一问题，聪明的老板马上想到，可以组织一个新的部门，对程序员开发网站进行监督和牵制，同时，还有一个好处，也可以在不懂技术的领导，总监们和技术人员之间架起一个桥梁，起到润滑和交流沟通的作用-于是产品部门应运而生了，这是一群介于技术人员和领导之间的群体。他们本身可以懂，也可以不懂技术，但却引领技术人员，设法灌输领导，老板的思想，同时，最大可能的考虑用户体验。某种意义上，产品人员是一个互联网网站/产品的最初用户，经过了产品人员的把关，再通过互联网站输出自己的产品，思想等，显然比从程序员直接输出要好很多。可以说，在互联网初期，这是一个伟大的变革。
因为产品部门的诞生，非常好的解决了程序员，公司各级领导，公司业务部门（运营，销售，BD等）以及用户之间的种种矛盾。

互联网初期，几乎就是产品和技术两大部门在互相合作。若干年后，一些先驱者开始提出测试驱动及若干测试理论，论证了测试的重要性，这时，QA部门粉墨登场了。至此，三权鼎立的三大部门，产品，技术，QA全部出现，并且巧妙的实现了互相制衡的作用（这一点本文不论述），一直沿用到现在，虽然在实践的过程中，在不同公司文化的沉淀中，产生了各种不同的侧重形式。但是根据笔者的经验，只要是沿用了这种组织架构方式来进行软件开发，那么结果通常就是，delay,delay再delay.
幸好有一句话解除了delay所带来的困惑，那就是在互联网的世界里，大力赞成缓慢发布。

为什么肯定的有delay说呢？我们先来看产品部门。随着时代前进的步伐，产品部门从初期的利大于弊的地位，渐渐的需要重新界定了。
首先，一个众所周知的问题，在这三方中，通常技术人员的薪资比较高，而做黑盒测试的QA人员薪资处于最低或者和产品设计人员持平。因为这个原因，非常容易造成基本产品设计人员和测试人员都是一些初出茅庐的新手，同时为了更好的使用户满意，我们也更趋向于招聘一些不太懂互联网的人，用他们的思维角度去设计各类网页页面，因此，大量产品设计人员的水平可想而知（不包括精细算法，用户行为心理研究等高精尖专的产品设计人员，这类产品人员往往自己以前也进行过编码和程序方面的专业积累，水平令人尊敬）。
相反的，开发人员则很多是在互联网行业有多年从业经验的开发者，然而这种开发模式中，首先假定了开发人员根本不懂UED。
随着互联网时代的不断深入，可以说，现在的程序员，有哪个在开发互联网站之前，自己没有访问过任何网站呢？对于一个网站上基本的功能，例如CRUD，列表页面显示，图片，文件上传下载，视频音频播放等，有几个程序员没有自己亲身访问过呢？用户体验（UED）已经不再是用户和程序员之间的障碍，一个提交按钮应该怎么放置，相信一个初级程序员也懂得。可以毫不夸张的说，大部分程序员本身已经可以担当起基本产品人员的职责。
起根上说，对于那些完全不懂技术的产品人员设计，由于他们本身不具有开发人员的很强的逻辑思考行为，所以设计出的网站，产品的种种功能，基本上都不能自圆其说，可以说是漏洞百出。设计样品交到开发人员手中，稍微揣摩就会发现很多漏洞，这个时候只能再打回重新进行设计，时间首次被delay。然而更糟糕的是，由于各种历史原因，如果遇到在这一环上非常较真的产品设计人员，明知是错，也绝不承认。在这种互相扯皮的状态下，往往是开发者明知道这样行不通，也只好按照错误百出的方案进行编码。其结果可想而知。

其次，随着时间的推移，产品部门的一些弊端渐渐被放大并传播开来。到现在（2011年），已经形成了一些固有的思维模式。几乎所有的公司都有绩效考核，技术人员需要绩效考核，产品人员和QA测试人员也需要。这就直接带来了部门间的利益冲突。在利益驱动下，不言而喻，产品人员是不希望技术人员按时完成任务的，通常无论技术人员怎样努力，都会被各种设计变化所包围而拖延工期，正所谓计划赶不上变化。那么，此时通常再次delay，而不明就里的领导，显然倾向于把责任归咎于技术人员。往往总监级以上的领导，不懂技术，不是技术人员出身。也不愿意给技术人员话语权，更愿意倾向于产品人员(有更多的共同语言？)。
同时，经常的，还需要产品人员来带领这个项目和团队。可是，如果这个产品人员是新手，正好应了一句老话，兵熊熊一个，将熊熊一窝。
从自己多年开发经验上来说，感觉开发者很多都极具理想主义，并且普遍存在严重的偏执狂症状，表现出来就是自信心极度膨胀，不服输，甚至不认错。还可能一些人完全听不进去产品人员的想法，完全脱离产品需求而追求自己的理想状态。这样的开发思维当然必须改进纠正，但同时，产品设计上的需求，在开发时就频繁修订，必然使软件开发的时间delay。

那么，从产品设计到技术实现这个环节上，就已经形成了必然发生的delay。

接下来QA测试人员隆重登场。然而目前国内所说的测试，基本都是指黑盒测试，大致等同于游戏开发那种游戏试玩者一样。当然，需要进行大量的边缘和阈值等测试。前面已经说过，如果遇到那种漏洞百出的设计，而产品人员又拒不承认，其实开发时，开发者已经知道错误百出，那么测试者一经测试，也会迅速发现这个产品到处都是漏洞，错误百出。此时，他们自然而然的觉得这些错误是开发者造成的，开始抱怨技术人员，这样的软件也好意思拿来送测，你们开发部的人都是吃屎的啊，立即挑出无数多bug，打回修订，或者直接以bug过多为由，不予测试（达不到测试要求），打回重新开发。请注意，这个时候产品部门的任何可能的犯过的错误和责任都被忽略了。软件的完成/上线时间再一次delay。

从上面对三者间互相协作的论述，不难看出，以这种方式来完成一个软件，要想按时完成，实在是有些天方夜谭，痴人说梦。而透过这些文字，又清楚的说明，这三者之间，只有开发者，程序员是最辛苦的一群人，需要耗费大量的脑力和体力，不断对软件进行修修补补，只有最终满足要求才可放行，否则必被打翻在地，不得翻身，寝食难安。而其他二者最大的作用就是监督和质量保证。

最后说一点题外话，软件到底是写出来的，还是测出来的，抑或是产品人员设计出来的？一个成型的软件以最大程度体现了软件开发者的思维模式，逻辑习惯甚至宗教信仰，国家出生地等复杂的因素，在行家眼里，她并不是一堆毫无生命力的，冷冰冰的英文字母组合。富有经验的从业人员，不难从这些跳跃着带有个人和地域色彩的思想和逻辑的复杂的代码中，看到软件开发者们深远的具有自身特质的清晰的影像。
然而这种三权鼎立形式的软件开发方式，往往极大的贬低了软件开发人员，毫无理由的提升了其他二者的地位。。。

29 楼 抛出异常的爱 2011-06-27  

comet12345678 写道

互联网成功的产品从来不是产品经理构想出来的。

。。。。。。。。。。。。。互联网产品有99%的想法完善，改变，调整来自产品经理或是由产品经理审批过的。。。。。。。。。

大多数开发工作也是为了完善改变调整。
点子其实不值钱

28 楼 hsiss 2011-06-26  

互联网产品在试探阶段和稳定成型阶段的管理模式是不一样的

试探阶段
产品部门确定一个核心主题立项,然后不断找各种投资人或者对互联网有深刻理解的人论证可行性,然后找目标客户进行市场调查确定前进方向.
研发部门(包括运维，ued,ui,qa,qc等)需要进行价值论证,范围、进度、成本、质量是相互影响的，需要进行权衡
过早引入绩效考核或者竞争机制、激励机制都是非常不明智的，使大家的注意力没法放到工作本身，而是相互之间推卸责任
要想活着进入下一阶段，各部门需要相互紧密配合，密切合作，荣辱与共
至于设计，产品部门负责指定大方向、尽早体验设计成果、以及在研发部门需要的时候确定细节，因为产品部门与市场和目标客户接触较多，这方面有资源；研发部门进行具体的设计，把内容具体化。这有一点像拍电影，编剧只是写剧本，剧本上只有干巴巴的几句话；导演会把一个场景的人集中起来协调，指导演员应该怎么演，真正起作用的还是演员本身，因为导演不可能把眼神、动作、语气、神态等各方面都说得清清楚楚。同样具体的功能做得好不好要靠开发人员的微设计
由于节奏非常快,并且无法明确划分责任,互联网产品在试探阶段不要外包

稳定成型阶段
这一阶段要根据公司的企业文化和在前一阶段形成的内部人员结构状况还有资金状况来灵活制定,总之产品部门可以找新的增长点,运维来稳定现有的业务,开发改进现有业务,
成立专门的技术部门来改进技术和对新增长点做技术考评

总之,
产品负责人要对市场很敏感,但立项须谨慎,在成本收益方面多衡量
研发负责人要时刻做价值认证,确保研发部门的工作总是对产品的价值有最大化提升的功效
胡言乱语,欢迎批判

27 楼 comet12345678 2011-06-23  

互联网成功的产品从来不是产品经理构想出来的。

26 楼 jackra 2011-06-22  

sharong 写道

sarstime 写道

虽然有些偏激，不过确实有时会存在这样的情况。但是lz也基本上是从技术人员角度出发考虑问题的。

虽然产品经理的能力，经验良莠不齐，但是一个好的产品经理对产品的导向确实决定了一个产品的成功与否。

老板一般不是技术出身就对了，有商业眼光的老板才能成功，如果你的老板只是一个技术出身，眼里只有技术的人，那我觉得你还是赶紧闪吧。

不是吧，根据统计，IT公司60%的老板是技术出身，别把技术人员想成只会和电脑打交道的书呆子。我的看法，做技术的人是喜欢挑战的一群，对生活充满激情和热爱的人，这样的人往往更具有商业眼光，所以创业成功指数更高。

嗯嗯。
以前公司很多所谓的业务人员觉得自己很NB，其实都是代码写不好的没办法才去学业务，然后这些人一下翻身做主人。不知道这帮人为什么这么喜欢折腾，还喜欢各种推卸自己的愚蠢行为导致的后果，最后居然还真有人买账，把所有问题都推给开发人员。

开发技术人员背黑锅的情况，现在是个普遍存在的现象。阁下能说出原因，也是颇有自己想法。
其实很多技术出身的管理人员，比这些所谓的业务专家和商业人员更加了解软件整个的风险和可能出现的问题。一旦他们翻身做主人，那么必然面临有高成本不可控的开发到低成本高质量的开发一轮洗牌，那时候，所谓的什么业务专家和商业人员，嘿嘿嘿嘿。。。。。。
技术人员们，把自己知识学好，然后准备往上跳吧。之后就是一片天地。

25 楼 BruceXX 2011-06-22  

昨天我老婆还说我，真是一个不识时务的家伙，  貌似我们不是在米国，国内模式就是这样，除非你告别程序员的生涯。。。

24 楼 sharong 2011-06-20  

抛出异常的爱 写道

sharong 写道

ray_linn 写道

matyhtf 写道

在facebook，要增加什么功能是程序员说了算。产品设计人员负责提建议，画饼，勾起程序员的兴趣。

画饼本身就是种设计，程序员只是工具。

但是facebook是程序员说了算，请到网上参考facebook的开发模式相关文章

facebook开发的是应用平台
他们的游戏插件都是非本公司程序员作的。。。。。。。

说到底他们的客户是程序员。。。。

不是吧，facebook的开发模式，网上有一篇文章来着，以前看过，是以工程师主导的，产品为辅。异常兄可以google之。

23 楼 抛出异常的爱 2011-06-17  

sharong 写道

ray_linn 写道

matyhtf 写道

在facebook，要增加什么功能是程序员说了算。产品设计人员负责提建议，画饼，勾起程序员的兴趣。

画饼本身就是种设计，程序员只是工具。

但是facebook是程序员说了算，请到网上参考facebook的开发模式相关文章

facebook开发的是应用平台
他们的游戏插件都是非本公司程序员作的。。。。。。。

说到底他们的客户是程序员。。。。

22 楼 sharong 2011-06-17  

ray_linn 写道

matyhtf 写道

在facebook，要增加什么功能是程序员说了算。产品设计人员负责提建议，画饼，勾起程序员的兴趣。

画饼本身就是种设计，程序员只是工具。

但是facebook是程序员说了算，请到网上参考facebook的开发模式相关文章

21 楼 ray_linn 2011-06-17  

matyhtf 写道

在facebook，要增加什么功能是程序员说了算。产品设计人员负责提建议，画饼，勾起程序员的兴趣。

画饼本身就是种设计，程序员只是工具。

20 楼 comet12345678 2011-06-17  

产品经理设计产品是个貌似合理的划分，设置。传统行业设置产品经理有一定道理，互联网产品经理做得事情基本上就是堆砌功能，为设计而设计，为工作而设计。

19 楼 matyhtf 2011-06-17  

在facebook，要增加什么功能是程序员说了算。产品设计人员负责提建议，画饼，勾起程序员的兴趣。

18 楼 lgsun592 2011-06-16  

终于理解同学做 用户体验（UED） 是干啥的啦，做外包缺少这块啊

17 楼 ray_linn 2011-06-16  

单来说，就是开发者开发出来的互联网产品，自己觉得相当满意，经过一番颇费口舌的培训和讲解之后，各部门领导和老板也都很满意；然而网站上线，产品发布之后，纷至沓来的互联网用户却不买账，不这么看，他们可能普遍觉得你这个互联网网站/产品，非常的难以使用，自己想浏览的内容很少或者干脆没有，换句话说，这个网站不具有粘性，用户不乐意在这个网站久呆，或者不乐意将网站放入收藏夹下次再来。


----- 这个就是典型的技术导向而非项目导向造成的后果，技术始终是为项目服务的，是support team，项目团队是core team，做成什么样的产品，是产品经理根据市场调查得到的，不是让技术人员来决定的。

16 楼 抛出异常的爱 2011-06-16  

技术人员没有职业道德是主要原因。
QA没有足够的能力是次要原因。
设计人员应该是项目成功失败的主要责任人。无论是设计失败，还是沟通失败，进度虚幻 都是他的问题。

15 楼 skypengyc 2011-06-16  

百度的：产品经理的定义，一般来说，产品经理是负责并保证高质量的软件产品按时完成和发布的专职管理人员。他的任务包括倾听用户需求；负责产品功能的定义、规划和设计；做各种复杂决策，保证开发队伍顺利开展工作及跟踪程序错误等，总之，产品经理全权负责产品的最终完成。另外，产品经理还要认真搜集用户的新需求、竞争产品的资料以及研究产品的发展趋势等。

看完之后觉得，跟你说的有出入。