10人产品团队管理实践及感悟_第1页
10人产品团队管理实践及感悟_第2页
10人产品团队管理实践及感悟_第3页
10人产品团队管理实践及感悟_第4页
10人产品团队管理实践及感悟_第5页
已阅读5页,还剩16页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1、10人产品团队管理实践及感悟我是一个典型的从一线产品经理成长起来的小组长,网上有很多讲解团队管 理的文章,大都是偏理论的,我的这个提供是比拟偏实操的,是一些拿来即可用 的方法工具,希望我的这些总结和感悟,能够帮助到很多跟我一样的成长中的初 级管理者。先说一下团队的情况。首先是组织架构层面,这个团队原来就是一个纯粹的研发团队,由研发组长和三 个研发小组组成。在我进组之前,这个团队大概运营这30个小工具,这些工具 的用户量或大或小,成熟度也不一。我是2018年12月份进的组,是这个团队的第一个产品经理,直接挂在研发组 长下面。2020年组织架构调整,独立出来了一个产品组,2020年下半年产品组长和

2、研 发组长双双异动了,产品组长空缺了一段时间。从2020年12月份我开始暂代组长,也来了一个新的研发组长。2021年5月份研发组长异动,新来了一个产品组长,兼任研发组长。相互配合,做至I1+1=2而不是1+12 ,但其实1+12也是很多团队常见的 现象。由于所有产品基本上都是我都干过,对于产品非常熟悉,所以分工对于我来说不 是太费力,但也中间也出过问题,说完招聘、分工,再说说协作。依据整个产品从需求调研到上线运营的流程,协 作分为好几大块,产品内部协作、产研协作、产研测协作、产品运营协作。正常 来说就按研发流程来即可,但总有一些不在正常研发流程内的场景,例如客户 反应线上问题时,我们如何能快速

3、解决线上问题,并及时修复缺陷,例如迭 代日历中给的测试时间太紧张怎么办。这些问题都没有标准的工作流程,每个团队有他自己的行事风格,所以只能是拉 上关键人讨论行得通的协作流程和职能分工,监督执行,并反复优化这个流程。但在协作过程中有一个要注意的就是,不能偏袒产品团队,不要有屁股,要客观 地看问题判责任,否那么自己就会失去公信力,一单研发不认可你这个人了,之后 所有的协作、协调都会变得困难。3.工作规划和落地执行这局部要求一丢丢专业能力和一些基本的管理方法。在工作规划方面,自己要能 定清楚年度目标,拆解到季度。落地执行方面,就是通用的工程管理能力和戴明 循环。这局部更多是体力活,一开始是我做好所有

4、的规划,包括目标和落地计划, 大家来执行,但是这种就调动不起大家的积极性,好像是这是我的目标,而不是 组员自己的目标。后来逐渐形成一个产品规划制度,分为两大局部:年度产品规划:每年春节前领导和几个组长定好年度OKR ,并与各级领导对齐。这些Object成为 本年度我自身的考核指标,也是部门的KPIO这里面的一局部Key Result变为组员的Object,组员要将自身的Object拆解为下 一级的KeyResult,形成组员的考核指标。这些拆解会形成一篇总的年度OKR的文档在做季度总结和规划时我会翻出来看一 看,年度总结的时候也要对照这个文档来。季度产品规划:每季度的倒数第二周,我会根据年度规

5、划+当时的情况,定好下一个的OKR ,并与 领导对齐,在周会上与组员同步。每季度的倒数第一周,组员要拆自己的OKR ,要写上达成KR所需的Action ,并跟 我来对齐。最终形成产品组的季度OKR文档,注意这个文档里只放OKR ,不是工 作清单,现实中每个人除了 OKR (主要任务)外还会有很多杂活要干。这个周我还 要做本季度的工作总结每季度的第一周,我们单独开规划同步会,跟研发同步上季度产品建设和运营的情 况,并讲解下季度的规划和工作思路,同时这一周组员还需要将工作拆解开来形成 工作排期表,排期表上不仅包括OKR中的任务,还包括其他细碎的任务,需要写清 楚每项工作的起止时间。每季度的第二周,

6、微调OKR和工作排期表。当周给隔级领导汇报上季度工作总结和 本季度公祖规划。做季度规划的前后一个月是挺累的才妾下来每周就是按照工作排期表检查工作进 度,辅导组员达成目标。最难的地方在于制定的OKR ,在制定OKR的时候,往 往会犯几种问题:OKR写得高大上,既不定性也不定量,不可衡量。和KR之间不是因果关系,达成KR并不会达成0KR个数太多,外加一堆Action,根本做不完,实质是没找到关键KR在制定OKR的时候,我常问组员几个灵魂问题:.现在的KR描述地太泛了,你这个词指的是什么?你要做的是A还是B还是C ?.你觉得拿到这些KR , 0就能达成了吗?.这个指标的统计口径是什么,现在已经有数了

7、吗?怎么才能统计出来?.怎么考核你这个KR达成没有,拿到什么结果我该给你打A ?另外说一点我对OKR的理解,整个部门的0可以是一个方向性的0,是一个比 较虚的0 ,然后用KR来衡量0实现没有,而且不同的阶段可以从不同的维度 用不同的指标来衡量0 ,所以KR必须是非常具体的一些阶段性成果。然后还有一些日常管理工作,像组员积极性建设、组员能力培养、协调资源、解 决协作问题等等,这个我是看了本工具书10人以下小团队管理手册来速成的,只要认知上知道自己该干些啥,思想和身体上不偷懒,运气不要太差遇上奇葩选手,日常管理可能累,但并不难。二.通过机制让团队逐渐变好解决了上面的三座大山之后,一个团队差不多就可

8、以跑起来了,可以持续地去为 组织创造价值,但是并不代表这个团队就是一个积极的、正能量的、欣欣向荣的 团队。事实上整个2021年我都过的挺累的,一个是所有东西都要从0到1 ,另一个是 我既要做一些管理的事情又要当一线的大头兵,所以每天都把自己折腾的很累, 好像这个组好像离了我可能业绩就达不成了似的(其实地球离了谁都照样转), 总是不放心。现在反过头来看,虽然当时我把组员之间的职能分工定义的很清晰,但是我个人 跟组员之间的职能边界却不清晰。对于该干什么不该干什么,该干到什么程度都 把握不好。1.提供型组会,队成员的凝聚场1.提供型组会,队成员的凝聚场的协作问题、有这么多矛盾隐藏了很久才爆发出来,最

9、后得出来的结论是我们产 品组开的会太少了,以至于没法及时让上下级和平级都认识到一些问题的存在。 想必大家看到这里也会笑了,一般都是觉得各种会太多了,但我们组的人一致认 为会开的太少了。其实这是我个人风格导致的直接结果。我个人是非常不喜欢开会的,总归是绝大 局部会的效率都非常低,漫无目的的讨论简直浪费生命,所以我基本上从来都不 开会,有什么事情就直接找我,我能解决的话绝不墨迹推脱。最直接的一个结果 就是我们产品组一整年基本上都没开过组会,我都是通过周报或者私底下的沟通 来了解大家的工作进度,组员就没有一个合适的渠道来去给我反应日常问题。但是我又不想开一个干巴巴的组会,传统的组会就是每个人汇报自己

10、这周的工作 进度,然后领导讲一讲问题。我在网上也看了很多开组会的方法,我把自己当一 个普通员工去感受这个整个组会,就感觉满满的都是上级的压力、非常不开心, 久而久之这样的组会就会变成“一言堂只有领导在那发言,组员都不乐 意发言。组会气氛沉闷、成员普遍觉得与自己没大关系,这也是事实上绝大局部 组会的现状。当时我面临的问题一个核心问题组员的专业能力缺乏导致业绩、产品效果 总不达预期。之前设立了季度学习制度,每一季度一个学习主题,月底轮流提供 学习成果,这个制度最后执行地很差,大家普遍没花额外的时间去学习总结。所 以我把专业能力提升和横向信息拉通作为组会的两个核心目标,逐渐形 成了一下组会模式:组会

11、之前,每个人不用花时间去准备长篇大论的汇报材料的,轻松参会就行,每个 人轮流做会议纪要。组会上大家不用汇报工作进度,工作进度在组会之后以简报的形式发在群里。组会的第一趴是我来提供一些横向的信息,比方说最近公司的营收很大,咱们要 多多支持创收的需求,比方说618到了,研发要备战,大家可用的研发资源实 际上是比上个季度要少的,可以侧重做一些运营工作。这个期间大家其实会简单 的讨论一下这些大的环境的变化对于自身工作的影响、如何调整工作节奏和优先级, 整体持续大概10分钟。组会的第二趴是大家提问,主要是需要我知道的重要的外部信息、需要我支持的地 方、需要我帮助解决的问题,比方说跟业务的目标对不齐,需要

12、我去找业务负责 人对齐目标,比方说有个内部客户期望购买我们的产品,有什么要注意的。 一局部问题我会当场解答,另一局部问题会留给我的待办,期间也会有简单的讨论, 整个过程持续约15分钟。组会的第三趴是个人工作提供,事先我会指定一两个同学提供近期的工作成果,比 如说产品的市场调研报告,比方说产品商业化计划,一般是讲10分钟, 然后大家点评、讨论,这个过程中,我会顺势指定一下下一次的提供人。整体持续 30分钟左右。组会之后,会议纪要发给所有的产品和研发,要求研发侧按照会纪要中的内容配合 我们工作。这种组会形式,对于我个人而言,有3个好处:.通过工作提供大家共同点评的方式减轻了我作为监督者的工作量.自

13、然而然地给到提供者适度的工作压力,并且是定期给到压力.自然而然让每个人都能相互了解彼此的工作,一个目标的实现不再只是某个人的事,大家群策群力对于组员而言,也是有3个好处:.不用光听我一个人说,自在.每周顺便学点别的领域知识,省事.同时可以过一把点评者的瘾,开心整个组会的气氛是比拟好的,经常会有人笑出声。目前存在的问题还是我说的太 多了,后来设了一个规矩,只要我说话连续超过三分钟,任何人都可以打断我。 之后还要继续改良组会的模式,尽量让大家说的多一些,相互促进,我就做一个 服务大家的角色就好了。这种组会模式对于管理者的要求其实是比拟高的,要求管理者了解每一件事情的 推进的方式、进度,这样才能做到

14、组会上不汇报工作细节而是直接讲问题。因此 这种模式应该也只适用于1020个人的小团队,管理者直线管理所有人。人再 多一些的话,管理者几乎不可能做到了解每一件事情的进度,肯定是要依靠再下 一级的小组长来管理好整个团队的。2. 一周一个戴明循环,即循环团队也循环自己一年之际在于春,一周之际在于周一,周一是我一周中最累的一天。由于组会上 大家没有汇报工作进度,所以我肯定还是要另找机会跟大家对齐工作的思路的, 确保一周过后我们能拿到一些确定性的结果。所以每个周一我会对照整个季度大 家的工作排期表,逐项检查工作的进度,然后找到对应的人,去让他给我讲拿这 个结果的思路、风险、需要沟通的人,需要协调的部门,

15、再给他纠偏。找所有人 逐个对过思路和进度之后,我会规划一下自己这周的要做的事情,形成一个待办 清单。再遇上老板找我、紧急需求、临时会议,这一天基本上就从早忙到晚、精 疲力尽。周二周三周四就相对轻松,30%的时间用来支持组员工作,70%可以用来干自 己的事,去思考未来要解决的关键问题和问题的解法、做产品规划、做横向的项 目、了解行业咨询等等。周五一天就是各种会(PRD评审会、组会)+写周报。周六日是学习+放松。一般周六上午会看混沌学园的直播课,周日花两个小时针 对性地补一些知识,例如新做的工程有知识盲区、老板推荐的好书、文案OR心 理学等产品经理的基本技能。剩下的时间都是放松打球、唱歌、聚餐、看

16、 剧、尝试新菜谱。比起之前的状态来说,还是要好很多的。之前自己很焦虑,工作没有规划和节奏, 每天都事无巨细折腾自己,一发现问题就会找组员聊,搞得组员不清楚问题的轻 重缓急、作没有节奏感,并且周六日还难以防止地要加班来完结大大小小的事。 现在就是周一忙一天,后面就比拟轻松,也能腾出时间来做一些有挑战性的事, 你好我好大家好。大家都知道我有一个九阴神功”工作本,每周占一页纸,这 页纸上有三个局部:第一局部是我这一周的待办事项清单,一般会有七八条,再多我也干不完。这个待 办清单由两局部组成,一局部是上周组会留给我的待办,一局部是我自己规划这周 要做的事情。第二局部是产品组会上我要同步的信息,这些信息

17、是在我这一周工作过程中记下来 的,一般会有三四条。第三局部是我要在产研组会上同步的信息,也是一周工作过程中总结出来的,一般 涉及到协作问题、工作方向和策略。这一周其实就是一个小的戴明循环PDCAO周一是做计划Plan ,周二到周四是 执行Do ,周五的组会就是check ,周会上的待办项其实就是改进措施Act0这 个戴明循环逐渐转起来之后,自己的状态就会逐渐由筋疲力尽变为忙而不累,同 时团队成员反而比之前更投入工作。但这种工作方法也要求自己要做到周事周 清,不拖延,保持一贯适中的工作强度。我也有emo状态不好的时候,一般当 周就少干点自己的事,绝不会拖延团队需要我干的事,不拖累团队。周一到周日

18、有时候会失眠,这种情况下我一般跑到客厅看书催眠,随机地读一些 书。总的下来看书的进度是一个月一本,强度并不大,但贵在坚持。自我感觉读 书的一个特点是转化率特别高,虽然书看得不多,但大多数能记下来,能用起来, 有时还会给其他人讲。3.多定标准少发表意见,最大化释放队创造力日常防止不了需要指导组员工作,一开始别人问我他的产出物有什么问题没有, 3.多定标准少发表意见,最大化释放队创造力之就会发现组员越来越依赖于你,什么事都等着你做决定,甚至当方案最终出了 问题时,组员会说这是你说的要这么干的呀,那个时刻就感觉很无奈。后来就觉得肯定是自己出问题了,就去看书,去想到底是哪里出了问题。有一天 是看短视频

19、就突然开窍了,别问我为什么,有时候就是两件看似毫不相干的问题 之间能相互启发。所谓授人以鱼不如授人以渔,我之前就是直接告诉别人正确的 做法,是鱼,那什么是渔呢。思索良久后,恍然大悟,渔就是做事 好坏的衡量标准,我的做法在这个衡量标准下是一个好的做法,但在这个衡量标 准下可能也有其他好的做法。所以如果我能把衡量的标准总结出来,那么只要组 员的产出物在这个标准之上,就是好的产出物。再后来就开始持续地总结不同产出物的衡量标准:例如PRD ,什么样的PRD是 一个好的PRD ,我就把PRD的组成局部,考前须知,优秀PRD案例总结出来, 之后再让我看PRD ,我会先问符不符合这个标准,复合之后我再给你看

20、具体的 业务问题。具体一点的,例如说做宣传海报,有宣传目的、明确目标人群、明确 想传达的信息点、找10个人看海报能GET到这些点、海报上有转化用户的外链, 那么这个海报就是个好海报。总结这些标准的过程是痛苦的,有时候会发现自己的专业水平也是有短板的,并 不能一下子说出什么样的才算好的。所以这一整套下来,也倒逼自己进一步提升 了专业能力。实行了一段时间授人以渔后,明显感觉大家的投入程度上来了,对自己的要 求高了,会做出一些你意想不到的惊喜。其实再想一想,也确实是这个道理。之2018.122020.1研发组长研发小组研发小组A研发小组A TOC o 1-5 h z VV研发小组研发小组研发小组AB

21、C我 临时2021.5至今产品组长产3VVV研发小组研发小组研发小组ABC其次是在人员配比方面,这个组研发人数一直都是40人左右。但之前是没有产 品经理的,产品经理的人数也不是从0忽然一下子增到10的,而是从1个2前大家其实很懵的,不知道为什么按我那样做就是好的,相当于被束缚者了。当 他们知道标准后,我不再限制达成目的方式,创造活力被激发了,他们自然而然 会找到最适合他们自己的前进之路,整个组也走向一个良性循环。三.总结最后,谈谈自己对管理这门学问总的一个感受。我在这方面应该还是刚刚入门, 但按网传没开过100个人根本不算会做管理,我也依然是个弟弟。在初级管理者被赋予的这些职能里,定义团队价值

22、和目标是最不容易胜任的, 这要求的是管理者有不一样的认知能力,而这个能力又是无法速成的, 确实需要经验、视野、思考,只能靠自己日积月累,且有玄学;目标落地和团队 建设等其他职能,个人感觉只要真心实意带团队、不偷懒去实践最基本的管理方 法,是可以在半年内速成的。当然,如果是带一个上千人的团队,管理者还会有稳定团队、传承文化等更抽象 的职能,又会有一些玄学,但这已经是中高级管理者考虑的事了,是另外一说。以下推荐一些好书和课程,希望能帮到跟我一样的小组长;如果其他好书, 也欢迎大家推荐给我。. 10人以下小团队管理手册:这本书的内容篇幅并不多,I天就可读完,里面都是最基本的管理理论,日常管理过程中几

23、乎全会用上,个人认为这个就是初级管理者 的工具书,必读且需常常温习,市面上很多初级管理者培训营的培训I内容也不会超 越这本书,非常实用。.场域领导力-关系视角下的高绩效团队打造:这本书的篇幅也是1天就可读完,但 就有点玄学,是从性格和心理上来讲解不同类型的组员对于团队的影响,但也算是 管理者的基本知识了,组建团队的时候一定是需要知道自己团队缺什么样的人。.极简工作法:对常用的工作方法做了个介绍,例如清单工作法番茄工作法, 所有职场人都应该掌握这些方法,.混沌学园-人力资源工程是CEO的第一工程:这个课可以帮助建立最基本的人力 资源的概念,我个人非常受用,反复听了几遍。混沌学园里面的课程都是讲认

24、知、 哲学、创新的,专为企业用户打造,每周都更新课程,学费1000多一年,并不便 宜,内容偏玄学,建议高级产品经理和管理者看。个人最喜欢的是其中认知思维和 理论与商业案例结合的课程,可以很直观的感受到认知理论是如何应用于实际工作 的。个一3个,经历了 3年多时间慢慢增加到10个的。另外这个组之前也是没有前 端的从2021年下半年开始有了自己的前端,经过1年的时间开展到4个前端。总结来说,这个组花了三年多的时间才到达了各种角色人员配比平衡的一个状 态。从2018年年底我进组一直到2020年年底的这段时间,我基本上就是一个大头 兵。这段时间的专业能力成长很快,也充满了辛酸泪,回头单开一篇提供,以下

25、 的提供和总结就从我暂代组长开始说起。一、接收团队后的三座大山不管是空降过来还是从内部成长起来的管理者,新接手一个团队之后基本上都需 要解决以下三个问题:.定义团队价值和目标.招聘合适的人、定义这些人的分工、建立各种协作机制.做好年度、季度、月度工作规划、借助管理手段确保绩效落地如果是空降过来的管理者,还会有一个额外的过程,就是知人一识人一用人一 建立信任和权威。对于产品组内而言,我倒是没有这个过程,因为我是第一个产品经理,是最熟悉 产品的,也熟悉所有一线工作的同事,之前就已经建立了一些专业权威。但是跟我合作的这个研发组长以及他底下的小组长是都换过的,所以跟他们之间有一个 磨合和建立信任的过程

26、。2021年上半年合作的这个研发组长是其他组的研发老人,之前就认识,所以整 个建立信任的过程还是挺快的,我们从一起工作到产出一些成果不过就是一个月 的时间。2021年空降的这个领导就不一样,对于他来说(我现在领导),当时 他就有建立信任和权威的这么一个过程,我跟他磨合了有大概三个月的时间,才 开始有一些真正的产品/团队管理上的动作。下面展开讲一讲我解决三座大山的过程和感悟。1.定义团队价值和目标整个2020年团队是比拟混乱的,直接领导和间接领导都变了两回,大家对于2020年在做的事情又有一些不认可,再加上这个团队原来人均运维着一个小工 具,小组之间几乎没有联系,所以这个团队的成员,不管是产品还

27、是研发,普遍 是比拟迷茫的,对这个部门的目标和价值普遍没有认知,也不太认可自己在做的 事,基本上可以用一盘散沙来形容这个团队。我跟研发组长接手之后,恰逢组内制定2021年工作计划。对于手上拿的这30个工具,我跟研发组长一致认为需要聚焦,我们按照工具的建设成熟度、使用范 围大小、工具本身的差异化价值的大小,给所有工具的后续开展做了一个分类。工具建设成熟度工具使用范围高大低小口把那些有一定成熟度的、在整个集团范围内都有差异化价值的工具拿出来作为后续重点建设的工具;那些没有差异化价值的工具,不管使用面大小,通通 都做下线处理,让用户迁移到集团的其他同类工具上;那些有差异化价值但是建 设尚不成熟的工具

28、,我们尽量不扩大使用面,按需建设。这样一波操作下来,其 实就只剩下了 5个工具是我们要重点建设的,在这个事之后我们也建立了一个价 值准那么我们只做整个集团范围内有差异化价值的工具,并且要做精做好,绝不 重复造轮子。后来这个价值准那么和我们对于这些工具的处理方式也得到了大家的普遍认可,所 以大家有了第一个共同认同的目标一推进下线这些不太可能产生大价值的工 具。但是我们选出来了接下来要重点的建设的工具,并不等于就定义清楚了团队的目 标和价值,那5个工具之间还是几乎没有关联,大家仍然不知道我们为什么而存 在。老实说我当时不具备定义目标和价值的能力,没有那个sense。之前当大头 兵的时候,我就只管建

29、工具、推广使用、降本增效就完事儿了,根本没有从公司 的角度想过我们解决了公司的什么问题,后来才知道价值的一些基本维度 营业本钱、运营效率、销售收入、客户体验。B端产品价值维度企业需求B端产品价值生产资料需求生产力企政策、监管需求风险控制效率提升需求效率I价值创造需求用户价值品牌价值盈利能力赋能需求改变竞争格局竞争力1 1实现二次增长曲线市场价值1当时就到混沌学园里听课,去学习定义问题思考问题的一些最基本的逻辑,去看案例,再对照自己的工作。当时针对保存的这5个工具,具体做了几件事:.站在公司的视角、用户的视角上看这些工具解决的到底是怎样的一个问题,产生的 价值属于什么维度。.去市场里找同类产品,

30、搞清楚自己做的这个工具到底是不是市场化的一个产品,市 场上是怎么量化这个工具的价值的。.把这些工具当B端产品看,定义清楚这些工具的客户、用户、合作伙伴。.理想情况下这个工具的产品架构、能力清单。最后总结出几个视角下我们工具的价值:公司视角下,提高特定类型需求的研发效率、同时控制系统平安风险。业务视角下,提升客户导入效率、提升一线运营效率。产品视角下,为公司贡献基础技术组件,未来有商业化的可能。接下来全年目标的定义也自然是根据这几个价值点来的,类似于降低客户导入 周期一系统平安防护能力建设商业化工程应用和收入。总的来说这个阶段倒用不上多少管理技巧,主要是考验管理者的认知能力, 具体又表现为几个方

31、面:.多角度看待问题的能力:从部门、公司、行业、市场等不同层次不同视角来看待问 题。.定义关键问题的能力:我们到底要解决的是谁的什么问题,如果你定义的问题对于 任何一个角色来说都不是问题,那这个问题或许确实是个问题,但没有价值。.把价值转化为目标的能力:当定义了一个有价值的问题后,那么用什么手段来解决 这个问题呢,我们要建一个怎样的产品能力或运营体系,到达怎样的一个目标,怎 么衡量目标是否到达了。2.招聘、分工.协作招聘一个人的时候,并不是说有了编制就随便招一个人,人也不是越多越好。我 是从以下几个维度来评估是不是要新招人手的:.公司是不是有编制和预算?有的话才能考虑加人,否那么只能替换现有人。.目前的总工作量是不是让团队严重超载了,除去那些可做可不做的工作外,团队是 否需要高强度加班才能完成全年目标?加人是不是能提升团队产能?如果工作量严 重超载,并不是一定要加人进来,可以考虑降低目标;如果不能降低目标,也要看 加人是不是能提升产能,如果可以提升那么可以考虑加人;如果不能提升产能,就要 考虑去提升现有人的能力;.是不是找到了新的价值点,有一个很大的问题需要专门的人来

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论