产品管理者人才模型详解.docx
- 文档编号:25047944
- 上传时间:2023-06-04
- 格式:DOCX
- 页数:26
- 大小:292.11KB
产品管理者人才模型详解.docx
《产品管理者人才模型详解.docx》由会员分享,可在线阅读,更多相关《产品管理者人才模型详解.docx(26页珍藏版)》请在冰豆网上搜索。
产品管理者人才模型详解
产品管理者人才模型详解(上)含前言
PostedbyUCPMon2011-9-119:
44:
22 View2645 Comments25
本文由UCPM原创,欢迎转载,但请注明出处和作者,谢谢!
前言
在阿泡的《YES!
产品经理》(原名:
《泡面是如何泡成的-产品经理的101问》)连载中,第八问是对产品经理的人才模型进行了一个说明,但是因为篇幅的原因,只能点到为止,因此,很多朋友反映能不能进一步展开来说明一下。
联盟把朋友们的反馈和阿泡说了,阿泡还是那个样子,哼哼唧唧的,列举出了一大堆理由,比方说工作太忙了,周扬安排新项目了,甚至还摇头晃脑地说“春困秋乏,这都立秋了,我很困啊”为理由不想干这个活,其实在联盟看来,以上理由纯属无理,根本原因就是一个字:
懒。
不过要搞定阿泡,其实也很容易,于是,联盟又一次使出杀手锏,明确告知阿泡,如果不完成这篇专题,稿费扣一半,此招果然有效,这小子乖乖就范了。
临了,我们当然还得做一下思想工作,再次语重心长地和他说,别忘了,是谁成就了你阿泡,不是别人,就是广大的信任和支持你的朋友们,为他们多做些事情,难道不应该吗?
看着阿泡汗流雨下的样子,联盟知道,阿泡一定会认真完成这篇专题的。
最后,阿泡和联盟说,因为已经在连载中对人才模型有了一个说明,在专题中就以亲身经历的案例来对第八问中的知识点进行一个说明吧。
因此,在这篇专题中,没有什么大道理,完全都是阿泡的亲身经历,按照阿泡的说法,就权当是《YES!
产品经理》的补充版内容吧。
第一篇:
产品管理者人才模型-个人素养要求
在阿泡认为的产品管理者人才模型中,首先需要的是个人素养的要求,在个人素养中,阿泡大致把它分为五个具体的方面,参见图1:
关于对个人素养以及所包含的五个方面的说明这里就不再说了,可以参见连载的第八问,阿泡只来通过自己的一些亲身经历来说明一下为什么我会认为这五个方面是我认为需要产品管理者注意的。
1)个人修养
关于个人修养,讲一个阿泡以前的一个同事的事情,当然,这位同事也是产品经理,暂且就把他称为是L吧。
那是阿泡刚做产品经理不久,公司有几款产品进入到了冲刺阶段,其中就包括我和L各负责的一款产品,L和我一样,也是刚刚做这个工作时间不长。
大家应该有这样的体会,在IT行业里,尤其是软件和互联网这个领域,年轻人特别多,虽然这样可以让企业很有活力,但是年轻人易冲动,想事情不够全面,甚至不计后果的情况也是现实存在的。
那段时间,因为大家的压力都比较大,因此,所有的产品团队中都给人一种紧张和压抑的气氛,貌似只要有一点火星就可能引爆潜在的冲突。
很不幸,这个火星在L的团队中出现了,一天,我们都正在工作,突然就听到L和他的团队中的一个程序员吵了起来,声音越来越大,我们赶忙过去劝,但是可能是情绪挤压的太久了,我们的劝解根本无济于事。
同时呢,一些不太入耳的话也在双方嘴里说了出来,在短短几分钟内,整个冲突升级,由嘴仗变成了肢体冲撞,最终形势变成了不可挽回的全武行。
最让我惊奇的是,L竟然蹭的一下子跳到工位上,居高临下地向那个程序员发起了对地攻击,我很惊讶产品经理竟然有这样好的身手,怪不得L经常和我夸耀他在学校的时候篮球打的很不错的,呵呵。
最终惊动了负责产品和研发的副总,他出面后,这场冲突才得以结束。
经了解,事发的原因很简单,L负责的产品在测试中发现了一个bug,于是,L让这个程序员修改一下,但是这个程序员暂时没有时间,而L又认为这个bug是比较严重的,因此,就有些着急和不高兴,就比较生硬的多说了两句,结果,程序员不干了,于是就和他争执起来,然后就是冲突升级,直到拳脚相加。
我本以为俩人被副总教育一下就好了,但是最终的结果却超出了我的意料,事发后的第二天,俩人双双主动离职,我问L为什么啊,公司并没有要求你们这样做啊,L苦笑着摇摇头,只是反问了我一句:
你觉得我还有脸待下去吗?
从这个事情中我们可以看出,作为一个产品经理,个人修养好坏其实是你是否成熟的一个主要表现,在第八问中我也说了,在产品管理工作中,个人修养的最核心表现就是“尊重团队中的每个人,相信团队中的每个人”。
而产品经理如果缺乏这种修养,最终损害的除了公司之外,还有就是自己的职业道路。
2)创新意识
对于产品经理而言,创新首先是一种意识,然后才是能力。
为什么怎么说呢,我还是以阿泡的一个朋友来说明吧。
我们暂且把这个朋友称为M,他应该算是互联网这个圈子里玩的比较早的那群人,98年左右就有了自己的站(他的最后一个站是提供下载的),并且还在现在一个很著名的B2C网站(其实这家网站最早并不是从事B2C的,而是做资讯的)做过负责人,还曾经负责过一款05-06年很有点名气的下载软件(虽然被评为十大流氓软件之一,但是那个时候互联网是遍地流氓的,呵呵)。
之所以介绍他的一些信息,并不是有夸耀他的意思,而是要说明我在创新意识上的一些观点。
有一次,大概是06年的样子,M和我说,他想改造他的下载软件,并且也有了大致的想法,当时在我看来,我在他面前,只是一个学生而已,于是赶忙拿本提笔想听听他有什么样的伟大想法和创意。
在M把他的想法描述完后,我颇有些失望,这算什么创意啊,甚至在我看来,连有趣都谈不上,更别说伟大的要颠覆什么了(互联网是有这样的心理的,动不动就要颠覆什么,或者就是创造出了什么伟大的模式,伟大的产品)。
M的想法很简单,这不是一个下载软件吗,但是在他看来,用户下载软件的目的大部分是为了安装使用(这不是废话吗,下载软件不就是为了安装使用,呵呵,但是我们按照用户细分的角度来说,除了安装使用,也有很少一部分用户下载并不是为了安装,也有收藏经典软件版本的,比方说ACDSEE3.2,现在微软的图片浏览器的功能也基本达到了这个水平),但是对于大部分的用户来说,他们会面临一个比较普遍的问题,就是要安装的软件如何才能更好的匹配自己的系统环境,因此,他的想法是通过这个软件把这个业务流程打通,从用户选择软件开始,直到安装并正常使用,包括后续的卸载,他要在这个软件里把这些应用都整合进去,按照当时流行的一个词就是:
一站式。
大家仔细想想,确实没什么惊人之处,因此才让我感到对这个想法颇有些失望。
现在来想,可能是自己对于软件应用的熟悉才造成了自己有这样的感觉,总觉的这样的产品做出来其实没什么多大价值。
当然了,从现在来看,360的软件管家以及类似的软件其实就是M当时的想法而已,可惜的是,支持他这个想法的公司最终没有善始善终,哎,对于产品经理而言,有一个好想法,没一个好老板也是一种悲哀啊。
产品经理有一个伟大的想法NB吗,以前我觉的很NB,但是现在我觉的一点都不NB,因为在我看来,能够解决消费者现实问题并切实可行的想法才是一个产品经理值得NB的。
这样的想法有两个标准:
(1)实事求是:
也就是说,这个想法的诞生一定是基于消费者现实的问题的,而这种问题是具有普遍性,并且消费者渴望有人来解决的。
而绝不是把我们自己当成消费者来看消费者会有什么问题,这样,就很有可能因为我们对于潜在或者现实问题的过于熟悉而轻视,或者是无视它对于消费者的现实性。
一次,和一个互联网公司的人聊天,他就说他们公司产品经理的产品创新的机制就是把自己当成消费者,然后做产品,并且还对这种机制洋洋得意,当然,人家确实有一个用户量很大的产品,但他忽视了一个前提,那就是这个产品的商业模式是免费,我当时就想了,如果你能用收费的模式做到这样的规模,那才是NB。
(2)量力而行:
NB的想法需要落地才行,再好的想法实现不了,或者大打折扣的实现,这反而会事与愿违。
有不少公司就是这样,很多不错的想法缺乏实现的基础,最终只能让这些想法被打上“空想”的标签。
当然,这就是我在前面说到的,创新首先是意识,然后才是能力的意思。
因此,关于这点,我简单总结一下,NB的想法来源于现实,而现实则来源于消费者现实和潜在的问题,而消费者现实和潜在的问题则来源于整个业务流程当中出现的不足,正因为有了手动刮胡刀,才有了刮胡泡的诞生,呵呵,对于产品经理来说,我们要发现的这些不足不仅包括产品介质本身的,更应该包括整个业务流程当中出现的,这才是我们创新意识的来源。
发现现实的不足并改进它,这是你的职责,发现潜在的不足并知道未来如何改进它,这是你的价值。
3)沟通能力
在我看来,沟通能力分为两类:
(1)语言沟通能力;
(2)书面沟通能力。
因为我们习惯于把沟通仅限于语言层面,而对于书面沟通则不太重视,因此,在这里我就只谈一下书面沟通的事情。
书面沟通,顾名思义,就是通过书面文件的形式来传递相关的信息,尤其对于产品经理来说,这点是非常重要的,因为一方面你需要通过相关的文档来记录高层的想法并细化出来,另一方面还需要通过这些文档来指导团队的工作,也就是说,产品经理要撰写的文档既是想法的记录,又是实践的指导。
这就要求产品经理在通过书面进行沟通的时候,务必要做到“准确、全面、到位”,说到底,就是达到三个标准:
(1)知道相关文档写什么;
(2)知道相关文档怎么写;(3)知道相关文档写到什么程度就可以了。
就阿泡了解的情况来看,大部分朋友的问题集中在第三点上,就是相关文档写到什么程度就可以了。
接下来就讲一个我亲身经历的。
还是刚做产品经理的时候,开始写PRD,关于PRD写什么,怎么写,这里就不多说了,阿泡的拙作中有详细的样例说明(植入广告一次),说说写到什么程度吧。
在PRD中,通常都会有对使用流程的规格说明,那个时候,我就知道说明到什么程度就可以了,于是就花了不少时间做了很多,很细的流程图出来,作为PRD的附录。
老大看了后,对我说道,这样来定义流程的规格,不能说不对,但是有些过了,我当时有些不满,毕竟是自己辛辛辛苦做出来的,竟然得到这样的评价。
老大看我有些不满,于是就继续说道,对于产品经理来说,在制作PRD的工作中,只需要定义清楚关键的规格指标就可以了,而无需对相关的指标定义的过于详细,因为过于详细的定义很有可能会束缚开发人员的思维,毕竟实现一个应用可以有很多个思路,而你定义的越详细,这种影响就会越大。
我还是有些不解,于是问道,那不定义不就更好了,让开发人员天马行空去想不是更有利于思考吗?
老大摇摇头,这样也不行,因为不去定义就会影响效率,也就是说,定义的太详细,会影响效果,定义的太粗糙,或者不去定义,会影响效率,因此,产品经理在PRD中要把握好这个尺寸。
我问他怎么具体把握,他说,这个需要多去实践,但是有一些原则可以借鉴,就拿这个流程图来说吧,定义到什么程度就可以了呢?
很简单,你只需要说明某一个流程,应该输入什么,然后输出什么,在处理过程中可能会出现什么样的情况,并出现什么样的交互就可以了。
就拿咱们这个播放软件最基础的打开硬盘视频文件(还有光盘和网络两种形式)播放的流程来说,输入是什么呢,就是软件支持的视频格式,输出是什么呢,自然是呈现出来的音视频,但是,在输入的时候会出现一些可能的问题,比方说,用户选择了软件不支持的视频格式,那么,你只需要说明当出现这样的情况的时候,软件会如何和用户交互就可以了,比方说,可以弹出窗口提示格式不对,或者在视频界面说明格式不对,等等,这个定义好就可以了。
我还是有些抬杠,说,如果这么简单,我不定义难道开发人员不知道吗?
老大笑笑,继续说道,他们当然知道了,但是如果你不定义的话,他们就会按照他们的思路去做,而这些思路很有可能是不符合用户期望的体验的,比方说,输入了不支持的视频格式,开发人员可能会通过播放器无播放反应来作为一种体验,而这种体验绝对是用户不期望看到的。
因此,产品经理在定义规格的时候,只需要说明关键操作的关键指标就可以了,至于具体的实现,产品经理无需考虑。
后来也接触了不少朋友在这个工作上的情况,我的感觉就是许多该做的没做到位,无需做的太多的反而做了一大堆,这应该就是书面沟通能力欠缺的具体表现。
在阿泡的拙作中,基本上列举了产品经理最常见到的26个文档,并且对这些文档如何撰写都有比较详细的说明,希望大家在看了后,能够对这方面的能力有一个更进一步的重视。
4)抗压能力
真正的产品经理压力一定是很大的,这是众所周知的。
而能否处理好这种压力,直接影响到产品经理在工作中的效果。
大家可以回顾一下第一点-个人修养-中L的表现,说到底,还不就是因为抗压能力不够造成的。
现在很多产品经理年纪并不大,年轻人容易头脑发热,容易冲动,遇到事情不能冷静全面的思考,其实这是做产品经理的一大忌,在国外,鲜有这么年轻的产品经理,很多都是职场和商场中的老油条,但是国内毕竟有自身的特点,我们也必须承认这种现实。
但是,阿泡在这里提一点的就是,年轻人太脆,很容易被压断,要想不被压断,把自己磨练的柔韧一些是必须的。
至于怎么做,阿泡也没好的办法,但是有一个阿泡认为还算是个人经验的东西说一下,就是作为产品经理,必须要有一个“看的开,拿的起,放的下”的心态,事事都较真注定是做不好产品经理的。
5)自管能力
自管能力,就是指自我管理能力。
产品经理的事情太多了,缺乏自我管理能力很容易让自己做许多事倍功半的工作。
05年的时候,阿泡在一家互联网公司做产品经理,有一段时间的工作就让阿泡疲惫不堪,什么工作呢,说起来好笑,兼职给客服部门做客服。
怎么回事呢?
很简单,随着公司用户量的增加,客服部门进行了扩招,很多新人进入,说实话,很多人对业务都不是太熟悉,当然,在前期的时候,产品部进行必要的支持是没有问题的,但是这也得有个限度吧,但客服部门可不这么想,估计是用产品经理用顺手了,但凡和产品有点关系的事情,就一个电话转接就转到产品经理这边来了,因为阿泡负责的是公司基础的产品,因此,被“点”的次数也就比较多了,这还不算,有时候,还得面临“出台”的情况,直接到客服部门去做支持,呵呵。
阿泡脸还薄,人家让“出台”就得去,客服部门也感觉这是情理之中的,就这样持续了大概一个月,实在受不了了,每天的时间就这样被一块块的切割完了,这还指望能做什么更重要的事情呢。
于是,我和老大说明了一下情况,于是在老大们的集体协商下,这种情况才逐渐减少。
自管能力其实对自己是一个考验,大道理不说,至少有一点是需要考验的,就是作为一个产品经理,你是否有说“不”的勇气和能力。
之所致这涉及到勇气,是因为有很多产品经理朋友和阿泡一样,脸皮都很薄,几乎不会说“不”,尤其是面对客服这样女性比较多的部门,根本拉不下脸来说“不”。
接下来就是能力,为什么阿泡说要说“不”需要能力呢?
很简单,因为你总得明白或者还需要告诉对方,你为什么要说“不”。
无理由的拒绝只会让你的地位一落千丈,而有理有据的拒绝才是产品经理保持地位和让人继续支持的前提。
而要想做到有理有据,绝对是一种能力。
产品管理者人才模型详解(中)
PostedbyUCPMon2011-9-119:
51:
15 View1333 Comments4
本文由UCPM原创,欢迎转载,但请注明出处和作者,谢谢!
第二篇:
产品管理者人才模型-相关管理知识
在阿泡认为的产品管理者人才模型中,相关的管理知识也是产品经理需要必备的,具体原因大家都知道,毕竟产品经理是一个需要综合学科知识的职位,如果不具备相关的管理知识,不能说你做不好产品管理这个工作,但有一点可以肯定,想做更长,做到更高,做到优秀,基本是不可能的。
在相关管理知识中,阿泡大致把它分为四个具体的方面,参见图2:
1)战略管理
战略并不是很虚或者可有可无的,阿泡曾经看过一个国外对产品管理者的调查,调查问“你认为公司制定的战略对现实的工作有什么样的帮助”,大部分的被调查者认为“虽然战略对现实的工作并不能提供直接的帮助,但是却可以让我们更为有目标和有方向的进行工作,能够让我们更容易知道未来要做什么”。
关于战略,阿泡也没什么大道理可讲,从这个调查中我们可以看出,学一些战略管理方面的知识,应该至少有三点作用:
(1)目标:
也就是说,一个明确且可行的战略,可以为业务的发展确定一个清晰的目标。
(2)方向:
也就是说,通过制定一个战略,可以让业务的执行人知道应该开展什么样的工作。
(3)节奏:
也就是说,通过制定一个战略,可以对业务发展的进度进行相应的管理和控制。
大家可能感到说这些还是有些虚,好,我就讲讲我是如何关注这个知识的学习的。
其实刚做产品经理的时候,我和现在好多朋友一样,都认为战略不是我们这个职位需要去考虑的,但是一件事情的发生让我的观念有了变化。
大概是02年底的时候,公司安排我负责一个基于移动平台(当时公司认为现有的移动平台主要是wince和palmos)的图像应用产品,主要方向就是实现在移动平台上的电子相册,功能大致包括制作和编辑,这个想法刚刚提出的时候,老大就一再和我强调千万不要忙着立项,设计和开发,首先要想清楚这个产品到底未来的发展会是什么样的,然后要完成一个对这个产品长期的规划再进入到具体的实施阶段。
当时我并不理解为什么要花时间去做这个工作,按照我以往的习惯,想法一提出,立马就开始产品的设计,根本不会去想未来会怎么样,但是现在老大提出了要求,没办法,做吧,但是怎么做呢,根本不会。
老大给了些思路,我来举一个例子吧,要知道这类产品未来有多大的市场,肯定得知道产品所依赖的移动平台的发展趋势,比方说移动终端未来五年会达到一个什么样的量,而这往往会决定我们这个产品的市场销量。
这是我当时做的一个预测,我是做了五年的,因为据IDC预测,从2002年起,整个PDA市场将以每年17%的速度增长,2002年的出货量达到了1700万台。
这其实就是基于现在对未来的一种预测和评估,就是一种典型的战略角度的思考,当然了,关于这个还有很多的,比方说对现实和潜在竞争者的评估和预测,对市场可能出现的需求变化的预测,对移动终端新技术发展的预测等等。
当然了,我当时肯定是不具备这样的能力和经验的,仅仅能够做到这一点,比较可惜的是我当时只看到了wince和palmos的发展,并没有意识到在移动OS这个领域会出现更多的竞争者,而我们当时关注的wince和palmos则显示出了疲态。
这就是战略管理的价值,对未来如果不能有效的预测,甚至出现错误的预测,那么,输掉的不仅仅是一个产品,而就会是一个市场。
关于如何做产品战略,在阿泡的拙作中有详细的说明,大家可以直达从哪些方面来思考。
其实说到底,战略做的好不好,就是两点:
(1)你能看多远;
(2)你能看多广。
2)项目管理
在阿泡的拙作中,对产品管理和项目管理的关系和区别有专门的一篇在进行说明,详细的就不讲了,大家可以去看看第二十三问。
这里只说说我是如何用项目管理的思想来指导自己的工作的。
首先,我会对自己的工作进行一个整体的安排,我自己用excel做了一个小工具,叫《项目排期表》,以一年为时间单位。
然后,基于这个排期表,来针对具体的产品制定年度的实施计划,同样,也做了一个小工具,叫《XXXX产品项目实施表》。
最后,在某个项目完成后,还会对整个项目进行评价,当然,也有一个小工具,叫《XXXX产品评价表》。
其实说到底,产品经理用项目管理的思想来指导自己的工作,并不复杂,通过三个表来支撑就可以了。
当然,我们必须清楚,这三个表分表在产品管理过程中代表着什么。
《项目排期表》:
确定的是一个整体的计划和方向,通常以一个财年来计算。
《产品项目实施表》:
确定的是具体产品的输入、处理、输出的管理,在这个表中,还可以细分为四个子表:
实施计划;进度监控;项目确认;项目维护。
《评价表》:
则是在某个项目完成后,要对这个项目进行相应的评价,主要包括八个方面:
时间控制;目标实现;资源争取;流程理解;工作态度;创新意识;团队精神;项目可控。
产品经理的项目管理毕竟和项目经理的项目管理还不是完全一致,我们只是采用项目管理的思想来让产品管理的工作更有序和有节奏,也没有必要花太多的时间和精力去做项目管理的具体工作,当然,如果你的公司要求你必须扮演产品经理和项目经理的双重角色,那就另当别论了。
总之一句话,只需要借鉴项目管理的思想,把一个项目的输入、处理和输出这三个关键阶段把握好就可以了。
3)时间管理
现在关于时间管理的知识也比较多,联盟里也提供了一些这方面的知识,大家要是有时间可以去看看。
为什么我要把时间管理也作为产品经理需要掌握的一个管理知识呢,可能我不说大家也能明白,如果产品经理没有一个优秀的时间管理能力,你日常的工作可能就会陷入一种无序、混乱并缺乏有效产出的境地。
关于时间管理,有个朋友曾经和阿泡探讨过,其实说到底,做好时间管理,其实就是做好两个方面的工作:
效率和效果。
再简单解释一下这两个工作的含义。
效率:
对于产品经理而言,就是指我们在现实的工作中,花费时间和有效时间的一种比例,花费时间是总时间量,比方说我们一天工作了8个小时,那么,在这8个小时中有多少时间是在按照我们的计划来开展的,这种按照计划执行的时间就是有效时间,这种对有效时间的管理就是我们的效率。
效果:
但是效率有高有低,这就涉及到了第二个概念,效果,也就是指在有效时间内我们对相关事务工作顺序的排序,常见的咱们都知道的,就是按照事情的“重要”和“紧急”来形成一个矩阵,然后根据矩阵中的事务排序来开展工作,这就是我们的产出效果。
一句话总结一下:
效率就是在有效时间内知道做哪些事情(即上面提到的计划内的事情)。
效果就是在有效时间内知道如何做好这些事情(即上面提到的如何区分计划内事情的“重要性“和”紧急性“)。
时间管理就说这么多吧,阿泡不是时间管理的专家,说的多了,难免就有些露怯了,呵呵!
4)团队管理
产品经理绩效的产生依赖于业务团队的工作,这是大家众所周知的,因此,能否对业务团队进行有效的管理,将直接影响到产品经理工作的成绩。
团队好不好管理呢?
说实话,对于国内大部分的产品经理来说,非常不好管理的。
最典型的莫过于就是你如何让相关业务团队能够遵从于产品目标而不仅仅是团队成员个人的绩效目标。
记得05年的时候,我在一家互联网公司做产品经理,当时负责公司的一款基础产品,公司为了改善这款产品,投入了很大的力量,成立了一个40多人的研发团队,这个团队由一个项目经理负责,而产品经理负责的则是产品的设计和进调的跟进与资源的协调。
按理说,业务团队自然是以业务目标(例如产品是否实现了规格所定义的指标,是否能够如期上线等等)为主的,而业务目标自然也是由产品经理来控制的。
但是,问题出现了,项目经理要为进度和质量负责,在遇到一个技术问题的时候,他通常会基于这两点来思考如何改进,那么,就很容易出现这样一种情况,改进的思路和方法可能会影响产品规格的指标的实现。
作为开发人员,这个时候应该听谁的呢?
同样是按理说,应该是听产品经理的,但是事实是他们几乎不会去听产品经理的,因为他们的月度绩效是由项目经理来考评的,如果不听项目经理的,那么月度绩效则会受到一定的影响,说的通俗点,就是每个月领到的工资就会有变化。
因此,那个时候我们就显得很纠结,定义好的产品规格却不能圆满实现,出现问题则几乎无法对开发团队有效的干预,本来并不是复杂的事情,往往要通过各自的老大沟通才能解决。
在这样的情况下,效率和效果又从何谈起。
但是,作为产品经理,至少在短期内你必须面临这样的团队管理的问题,怎么能做好呢,抛开公司体系可能出现的影响,仅从个人来说,磨练一些团队管理的技巧是必不可少的。
比方说如何
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 产品 管理者 人才 模型 详解