企业研发管理的一些理念doc.docx
《企业研发管理的一些理念doc.docx》由会员分享，可在线阅读，更多相关《企业研发管理的一些理念doc.docx（25页珍藏版）》请在冰豆网上搜索。
企业研发管理的一些理念doc
第章
覆盖产品生命周期的研发管理体系
族质量管理体系
项目管理知识体系（）
敏捷开发思想
和面向对象方法论
企业常见的研发管理问题
组织结构和人力资源管理问题
产品生命周期管理问题
项目管理问题
技术开发问题
跨部门协作问题
管理工具问题
互联网企业的研发弊病
其它问题
企业研发管理解决方案介绍
集成化研发管理方法论（）介绍
模型
的优点
集成化研发管理平台（）介绍
功能介绍
的优点
企业研发管理的一些理念
企业的根本目标是“合法地赚取尽可能多的利润，使企业利益最大化”。
企业所有的特定目标和行动（例如研发和管理等）都是围绕根本目标开展的,不能和根本目标抵触.
企业研发管理的指导思想是：
结果导向,并且关注过程.
✧“结果导向”是指：
以最终产生的经济效益来衡量研发项目的业绩，追求利益最大化。
✧“关注过程”是指：
将期望的结果分解到每个过程域（即工作环节）去实现,努力把每项工作做好，从而得到好的结果。
一般地，好的过程才可能得到好的产品,而差的过程只会得到差的产品。
衡量研发工作优劣的三个关键指标是：
质量、时间和成本。
人们在工作的时候总是希望：
做得好（即质量高）、做得快（即时间少）而且少花钱（即成本低）。
如果出现三者难以同时兼得的情况，那么决策者一定要搞清楚质量、时间、成本之间的复杂关系，判断孰重孰轻，给出优化和折中的措施。
综上所述，我们可以总结企业研发管理的目标：
✧基本目标:
让所有人员有条不紊地开展工作,在预定的时间和成本之内，开发完成质量合格的产品，从而使企业和个人获得预定的利益.
✧奋斗目标：
调动一切积极因素,努力提高产品质量、提高工作效率并且降低成本，使企业和个人获得比预定目标更多的利益。
在企业中，研发项目所涉及的主要过程域有:
✧项目管理过程域：
立项管理、结项管理、项目规划与监控、风险跟踪和变更控制。
✧项目研发过程域:
需求开发、设计、实现、测试、发布与验收等。
✧机构支持过程域：
质量管理、软件配置管理和文档管理、客户服务和产品维护等。
上述过程域中的任何活动都会影响研发项目的质量、时间和成本。
人们显然难以一股脑地把所有的事情做好.
在企业里，大部分工作是成熟的，有现成的模式可以套用,应当走规范化路线;而另外小部分工作可能是独特的，并不适宜套用规范（也可能没有规范可以套用），那么应当采用超越规范化的管理方式。
一般地,企业既需要大量的规范化管理方式，又需要小量超越规范化的管理方式。
通常前者约占，而后者约占（这里仅仅是建议比例）。
国内大部分企业的研发管理现状是：
规范化管理太少，非规范化的管理太多，到处都是“土匪游击队”的运作方式。
阻碍国内企业发展的瓶颈问题通常不是技术问题，而是杂乱无章的管理。
国内企业喜欢标榜自己是“高科技企业",在开发高科技产品的同时，自己内部的管理却非常落后。
真是“鞋匠的儿子没鞋穿”，这是对企业的莫大讽刺。
本书倡导的研发管理思想是：
以追求商业利益最大化为总目标，将提高质量、提高效率、降低成本的方法融入到所有过程域中，形成适合于本企业的研发管理规范；开发和部署与规范配套的管理工具，从而有效地帮助企业依据规范开展研发管理工作。
常见方法论介绍和优缺点分析
2。
2.1覆盖产品生命周期的研发管理体系
早在年,美国公司创作了（，产品及周期优化）方法论.关注的要素有：
Ø正确决策
Ø项目小组构成
Ø开发活动的结构
Ø开发工具与技术
Ø产品战略
Ø技术管理
Ø资源管理
算得上是产品生命周期和流程管理领域的方法论鼻祖。
诞生之后，很多企业和学术机构不断地提出了适合于本行业的研发管理方法论,概念和术语“之多、之大”令人眼花缭乱、茫然失措。
世纪年代初，公司遭受了巨大的经营挫折，年亏损额高达亿美元.为了摆脱经营困境，实施了以系统性研发管理解决方案为核心的企业再造方案。
引进了方法论，并获得了巨大的成功.从年到年总共节省了亿美元的费用，产品平均开发周期由年下降到个月。
在的基础上，总结了一套行之有效的产品开发模式，称之为（,集成产品开发）。
不仅内部使用,而且还把方案卖给别的企业而赚了不少钱。
年，华为公司成为国内第一家引入和的大型企业，据说花费上亿元人民币，方案供应商自然是.华为公司在推广过程中遭遇重重困难，付出了高昂代价,最终评价是成功的。
目前华为已经是国内最大的电信设备供应商，也可以说是国内最大、最好的高科技企业。
在企业流程改进领域，华为创作了一句广为流传的名言：
“先僵化，再优化，后固化”。
相似地，上海贝尔阿尔卡特为了建立适合自身发展需求的研发管理体系（类似于），从年开始引入方法论,公司在研发管理体系的投入累计达数千万元人民币。
本人是该项目的。
我和组员们最初接触的时候，觉得神秘高深，很是仰慕.我们和公司的咨询师相处了个多月，最大的工作成果是制订了“新产品开发流程”，如图所示。
有一天，我凝视着那幅花费了一百多万元经费而产生的流程图，突然发现：
所有的流程细节都是我们自己制订的，咨询师仅仅告诉我们几个先进的概念和术语而已，并没有给予任何超出我意料的革新，竟然被他赚了那么多的钱。
图根据方法论制订的新产品开发流程
之后一年，我亲身感受到，所谓国际先进的研发管理方案,实际上效率低下、浪费很大.于是我和合作伙伴创作了面向国内中小型企业的研发管理方法论（）和管理平台（），并于年创业.由于有前车之鉴，我们不做华而不实的事情，我们的价值观是“为客户创造的利益必须高于客户付出的成本”。
由于有亲身经历,我对和方案作个简要的评论,以便读者辨析:
和方案适合于指导大型企业的“软硬件产品研发和制造”流程改进,由于涉及面很广，实施过程中会遭遇重重困难，可能导致半途而废；投入经费巨大，见效时间比较长，企业可能挺不住；如果成功,则有巨大的长期收益，但是失败的可能性比成功的可能性高得多。
如华为和上海贝尔阿尔卡特之类的研发管理体系,根本不适合于国内中小型企业，因为尝试不起、承担不起。
2.2.2族质量管理体系
国际标准化组织（）为了满足国际经济交往中质量保证活动的需要，在总结各国质量保证制度经验的基础上,经过近十年的工作,于年发布了质量管理和质量保证标准系列.年进行了第一次修订，形成了族标准。
年又进行了重大修订,发布了新标准（版）。
族标准问世至今，已经被全世界几乎所有行业广泛采纳。
人们到商店买东西，随处可见“本产品通过质量认证”的标记。
“产品通过质量认证”几乎成为上市销售的必要条件。
尽管族标准已经在各行各业普及，功劳莫大。
但是人们在实践中发现族标准对低技术的生产企业帮助很大,但是对以研发为主的企业的帮助比较弱.主要原因如下：
（）称得上是“放之四海皆准"的标准,但是适用面越广意味着专业性越弱。
例如,生产瓜子的小工厂和生产软硬件系统的企业，都可以采用族质量标准。
显然前者的成功经验不能套用到后者上。
标准不可能对“软件、嵌入式系统、集成电路”等领域的质量问题有深入的论述，所以它对企业的质量管理缺乏专业性的指导，其专业程度远远不及。
（）基于的质量保证活动,其关注的焦点是“输入、输出”是否符合既定的流程.对于低技术的企业而言，如果“输入、输出”都符合既定的流程,那么基本可以断定产品的质量不错。
然而对于高科技企业而言，“输入、输出"都符合既定的流程并不意味着能够生产出高品质的产品，因为研发水平对产品质量的影响更大。
对于“软件、嵌入式系统、集成电路”这类以智力创作为核心的产品而言,质量标准的指导价值不高。
我对“软件、嵌入式系统、集成电路"此类研发企业的建议是，学习和应用质量标准是有意义的,但是不必费时、花钱去搞认证（除非公司策略需要），因为行业人士并不看重认证。
2.2.3
年月，美国联邦政府委托卡内基梅隆（）大学软件工程研究所（）开发了一套用于评估软件承包商能力的方法。
于年月发布了一套软件过程成熟度框架和一套成熟度问卷。
年,将软件过程成熟度框架发展成为软件能力成熟度模型（，）,诞生了。
年，推出了,这是目前世界上应用最广泛的版本.
十几年来，的改进工作一直在不断地进行。
美国国防部希望把现在所有的以及将被开发出来的各种能力成熟度模型，集成到一个框架中去。
到年，演化成为（，能力成熟度模型集成）.不仅适合软件，而且适合于软件、硬件结合的系统，这是对最大的改进.
从世纪年代至今，软件过程改进成为软件工程学科的一个主流研究方向,其中和是该领域举世瞩目的重大成果。
是世界范围内用于衡量软件（硬件）过程能力的事实上的标准，同时也是软件（硬件）过程改进最权威的指南。
将能力成熟度分为个级别，这个成熟度等级为评价机构软件过程能力提供了一个有序的级别，如图所示。
同时也为机构的软件过程改进工作指明了方向，让人们分清轻重缓急，指导人们一步一步地改进过程能力，而不是企图跳跃式地前进。
人们往往搞不清楚和软件过程改进的关系，而将二者混为一谈。
下面作个比喻来解释：
把“软件过程改进”比喻为“学英语,提高英语能力”，那么就好比是“英语等级评估标准（考试大纲）”。
一般情况下，英语等级考试的成绩反映了英语能力.但是，在特别擅长应试的中国，英语考试成绩很好并不见得英语能力很好，甚至可能差到“哑巴英语”的程度.这种“特性”传染到软件领域，不少企业虽然通过了高级别的等级评估，但是其实际能力却非常低下。
软件过程改进的真正目的是提高机构的软件过程能力，而不是为了达到高等级。
“汝果欲写诗,功夫在诗外"，这是很好的启示。
图的个能力成熟度等级
年至年，我在上海贝尔有限公司负责的研究和推广工作，公司的每个事业部都有软件（硬件）过程改进人员.公司在过程改进方面的投入巨大，取得了一些成效，但是没有达到我的期望值。
感慨很多，一言难尽.此处,我对过程改进做个简要的评论，供同行企业参考.
一、等级评估：
从狂热回归理性
－年是国内企业进行等级评估最狂热的时期，主要原因有:
（）年,刚刚在国内兴起，感兴趣（学习、研究）的人非常多.近几年国内出版了不少关于、软件过程改进的书籍，相关论坛、会议也比较多.有良好的群众基础.
（）那个时候认证已经被国人搞臭了，而当时国内等级评估还很少见，企业达到级、级是很荣耀的事情。
物以稀为贵，人们把认证的目光从转向了.
（）为了扶持当地软件企业，鼓励软件出口，各地方政府相继出台了“资助企业搞等级评估的政策"。
最先搞评估的企业尝到了甜头,自己拿到了比较吃香的等级证书，昂贵的评估费用大多由政府支付了。
这一催化剂,进一步激发了企业搞评估的热情。
－年期间，国内有数百家企业通过了级、级评估，大部分企业搞评估是“为了拿证书”而不是“真正提高软件过程能力”。
到年,国内评估从狂热回归理性。
主要原因有：
（）地方政府基本上不再资助企业进行等级评估了。
企业自己掏钱搞评估就舍不得了，要掂量是否值得（理性的表现）。
（）由于国内通过级、级评估的企业已经很多,而且评估时“放水”现象严重,评估的声誉已经大不如年。
（）最让人失望的是，虽然有些企业通过了级、级评估,但是实际的软件过程能力却依然低下。
有些企业实施后，质量没有明显提高，反而进度更落后了,成本增加了，人员更累了。
现在软件业界普遍关注的是:
企业如何以比较低的代价有效地提高软件过程能力.等级评估则退居次要地位.
二、的盲区和常见应用问题
用指导企业的软件过程改进工作是相当不错的，但是企业要做的重要事情显然不仅是软件过程改进.企业最关注的是生存和发展问题，一切离不开赚钱。
本身不谈如何赚钱的问题.它假设了美好的前提条件,即企业有充足的人员、资金和时间从事软件过程改进，当软件过程能力提高了，那么产品的质量、生产率自然就上去了（同时成本也下降了），企业自然能够获取更多的利润。
软件过程改进对企业经济效益的贡献是间接的，从投入到产出，时间相对比较长。
遗憾的是，国内大部分企业没有能力提供那么好的前提条件,企业最缺乏的资源往往就是人员、资金和时间，企业领导当然想把资源用在“刀刃”上，即赚钱最多最快的地方。
当软件过程改进和其它直接赚钱的事情“发生资源冲突”时，只好“拆东墙，补西墙”，往往减少软件过程改进的资源。
如果完全按照的要求遍历“个关键过程域和百余个关键实践”的话,无疑会占用大量的资源，资源冲突在所难免，失败的风险很高.所以切勿照搬，一定要根据企业的实际情况（企业发展战略、产品特征、资源状况）给出软件过程改进的措施。
对软件项目管理和机构过程管理论述很深入，但是对软件开发的核心工作即“需求开发、软件设计、编程、测试、维护”论述非常少,把它们压缩为一个过程域叫做“产品工程”（），近乎一笔带过。
所以导致一个怪现象，管理人员觉得真是好，而大量开发人员学了后却很是迷惘，感觉对他们的开发工作没有直接的指导作用。
方法论有个明显的倾向，即“管理的规范化”重于“开发的规范化”。
级的个关键过程域全部是论述项目管理的，而唯一论述“需求开发、软件设计、编程、测试、维护”的“产品工程”关键过程域则放在级.
对于国内大多数软件项目而言,技术开发占总工作量的％以上，而项目管理占总工作量的％以下,因为企业销售的是软件产品，而不是管理。
明眼人都看得出,技术开发的规范化要比项目管理的规范化更为迫切与重要（至少也是同等吧）。
由于强调过程改进要循序渐进,不要跳跃式前进。
人们自然而然地会先把精力集中在级的个关键过程域上,而忽视了技术开发的规范化,这显然是误区.如果这样做的企业通过了级评估，然后声称他们能够把产品做得又快又好，无疑是自欺欺人。
三、对应用的建议
在软件过程能力比较低的企业里，经常会发生项目开发过程混乱、产品质量低下、进度延误、成本高昂等问题.一批人马累死累活地做完产品后,马上又因质量问题被折腾得焦头烂额。
这种现象反反复复地发生，让人疲惫不堪。
有远见的企业领导应当下决心去改进软件过程能力.提高软件过程能力实际上就是“练内功”，“练内功"没有捷径可走，唯有走“规范化”之路.即：
制定适合于本企业的软件过程规范,并按照此规范执行。
是衡量企业软件过程能力的国际标准,它对软件过程改进有很多有益的指导。
仅仅对等级评估做了强制要求，但是对企业“如何进行软件过程改进”没有强制要求，的数百页文本并不是“放之四海皆准”的,企业可以采纳也可以不采纳。
对于软件过程改进而言，和等等都是用来参考的，而不是用来迷信的.企业在参考业界推荐的标准或规范时，要舍弃那些听起来很先进但是对本企业无益处的东西,只选取对企业有实用价值的东西。
2。
2。
4项目管理知识体系（）
项目管理协会（,）于年在美国宾州成立,是目前全球影响最大的项目管理专业机构,该机构的项目管理专家认证（，）被广泛认同。
的突出贡献是总结了一套项目管理知识体系（,）.请注意不是的缩写.
总结了项目管理实践中成熟的理论、方法、工具和技术，也包括一些富有创造性的新知识.
把项目管理知识划分为个知识领域:
综合管理、范围管理、时间管理、成本管理、质量管理、人力资源管理、沟通管理、风险管理和采购管理。
每个知识领域包括数量不等的项目管理过程.
把项目管理过程分为个阶段：
（）启动.开始项目或进入项目的新阶段。
启动是一种认可过程，用来正式认可一个新项目或新阶段的存在。
（）计划。
定义和评估项目目标，选择实现项目目标的最佳策略，制定项目计划。
（）执行。
调动资源，执行项目计划。
（）控制。
监控和评估项目偏差，必要时采取纠正行动，保证项目计划的执行，实现项目目标。
（）结束.正式验收项目或阶段，使其按程序结束。
每个管理过程包括输入、输出、所需工具和技术。
各个过程通过各自的输入和输出相互联系，构成整个项目管理活动。
根据重要程度,又把项目管理过程分为核心过程和辅助过程两类。
核心过程是指那些大多数项目都必须具有的项目管理过程,这些过程具有明显的依赖性，在项目中的执行顺序也基本相同。
辅助过程指那些视项目实际情况可取舍的项目管理过程。
在中，核心过程共个,辅助过程共个.
一共有个项目管理过程，按所属知识领域分为类，按时间逻辑分为类，按重要程度分为类。
如表所示，其中灰色字为辅助过程.
表项目管理过程一览表
启动
计划
执行
控制
结束
综合管理
项目计划编制
项目计划执行
综合变更控制
范围管理
启动
范围规划
范围定义
范围审核
范围变更控制
时间管理
活动定义
活动排序
活动周期估计
进度安排
进度控制
成本管理
资源计划
成本估计
成本预算
成本控制
质量管理
质量计划
质量保证
质量控制
人力资源管理
组织计划
人员获取
团队建设
沟通管理
沟通计划
信息分发
绩效报告
行政收尾
风险管理
风险管理计划
风险识别
定性风险分析
定量风险分析
风险响应计划
风险监控
采购管理
采购计划
招标计划
招标
选择供应商
合同管理
合同收尾
和对比简评：
论述的项目管理方法仅仅适用于软件项目，但是不适用于其它行业的项目管理;论述的方法适用于任何行业的项目管理，但是对软件项目管理而言,的针对性不够强。
不仅论述软件项目管理，而且论述整个机构的软件研发管理；的方法局限于项目管理，对于企业研发管理则不够用.
基本上不谈“成本管理”和“人力资源管理”，它先假设机构有充足的资金和人力资源,通常不切合企业实际情况；的“成本管理”和“人力资源管理”可以弥补的不足。
建议：
对于软件机构研发管理或者软件项目管理，采用为主导的方法论，并结合的知识，取长补短。
2。
2.5敏捷开发思想
年，为了解决许多公司的软件团队陷入不断扩大的过程泥潭,一批业界专家概括出了一些可以让软件开发团队具有快速工作、响应变化能力的价值观和原则,他们称自己为敏捷联盟（）。
他们起草了一个旨在鼓励更好的软件开发方法的宣言，称为敏捷联盟宣言（），如表所示.然后在该宣言基础上制定了条原则用于指导实践。
该宣言和条原则是敏捷软件开发方法的核心。
表敏捷软件开发宣言
我们正在通过亲身实践和帮助他人实践，揭示更好的软件开发方法。
我们认为：
●个体和交互胜过过程和工具
●可以工作的软件胜过详尽的文档
●与客户合作胜过合同谈判
●及时响应变化胜过遵循计划
虽然右项很有价值,但是我们认为左项有更大的价值。
敏捷软件开发的条原则如下：
（1）我们最优先要做的是通过尽早地、持续地交付有价值的软件来使客户满意.
（2）即使到了开发的后期,也欢迎改变需求。
敏捷过程利用变化来为客户创造竞争优势.
（3）经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好.
（4）在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
（5）围绕被激励起来的个人来构建项目。
给他们提供所需的环境和支持,并且信任他们能够完成工作.
（6）在团队内部,最具有效果并富有效率的传递信息的方法,就是面对面的交谈。
（7）可以工作的软件是首要的进度度量标准。
（8）敏捷过程提倡可持续的开发速度。
责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
（9）不断地关注优秀的技能和好的设计会增强敏捷能力.
（10）简单——把无需做的工作最大化的艺术——是最根本的.
（11）最好的构架、需求和设计出于自我组织的团队.
（12）每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。
人们在敏捷软件开发宣言和项原则的指导下,创作了更多的富有特色的开发方法和最佳实践。
例如“敏捷的面向对象设计",请参考《：
，，》（.著），中译本为《敏捷软件开发:
原则、模式与实际》。
例如“敏捷建模”，请参考《：
》（.著）,中译本为《敏捷建模：
极限编程和统一过程的有效实践》.
本文作者的观点如下：
敏捷软件开发宣言和条原则并非普遍适用。
我大约赞同其中的％，我和软件人员交流的时候，有时会引用其中的原则，感慨甚多,忍不住拍案叫好。
但是约有的内容我并不认同，主要原因是“过于理想化、绝对化，不适合国情”。
我认为“宣言"中的左右项都很重要,但是不能绝对地说左边项“胜过”右边项，这是“一刀切”的结论，没有考虑成千上万个企业的具体情况。
上述项原则中的（）、（）、（）项,看似很好，但是不符合中国软件机构的普遍现状,实际上可能行不通。
我个人比较赞同的是（）、（）、（）、（）、（）项。
敏捷开发方法表达了“简单、快速、实用”的软件开发思想，它不是成熟的理论、也不是事实上的标准（不像、那样具有严密的理论体系,被企业广泛接受）。
即使人们认同某些原则,但是不同的人往往有不同的理解，实践差异很大.
敏捷开发方法对于提高个人、小型团队的工作效率是很有帮助的（如果用对了的话）。
但是企图用它指导大型、中型软件机构的研发管理是有很高风险的，它的某些主张是局部观点而不是全局观点，如果把握不好分寸的话可能导致整体混乱，而“整体的混乱"会淹没“局部的好处”。
作者研制的“精简并行过程（）"的理论基础是“软件工程、、”.为了提高效率，局部借鉴了“敏捷软件开发的思想”，用于裁减过于冗长、笨重的过程规范。
2.2.6和面向对象方法论
（）是公司推出的软件过程模型,它是软件业界迄今为止商品化最成功的软件过程模型。
的近千页文档可以从公司的网站（）下载,中文版也已经发布.
的主要特征是:
✧采用迭代的、增量式的开发过程，如图所示。
✧采用语言描述软件开发过程.
✧有一系列功能强大的软件工具支撑（公司的软件产品）。
是三位面向对象大师、、创作的面向对象建模语言，年被国际对象管理组织（）采纳为国际标准。
是独立于过程的，可以应用于任何开发过程模型.
由于和都是公司的研究成果，两者有天然的联系。
的文档里面充满了模型,需求建模、分析与设计、实现、测试等阶段的角色的主要工作都是用来描述的。
与配套的软件工具相当完备，例如面向对象分析设计工具，配置管理工具，变更控制工具，需求管理工具，文档生成工具,测试工具，还有工具等。
年,斥资亿美元收购了公司。
现在国内软件开发人员学习、使用盗版的劲头很足，相关书籍和网站也越来越多，造成了一派红火的景象.但是完整采用的国内企业则非常少。
图模型
及其配套软件工具是重量级的软件研发管理解决方案，它面向的是高端用户，对用户的财力、开发和管理能力要求都很高：
✧首先，用户得有钱买的软件工具，否则光有方法论如同纸上谈兵。
软件工具都是非常昂贵的，例如配置管理工具几乎是每个项目成员都要使用的，但的每个大约美元，这个费用相当于中国普通程序员一年的工资收入!
显然,大部分国内企业没有钱购买公司的软件工具。
✧如果要使用方法，得先熟悉，否则除了模型图之外你基本上看不懂细节内容。
可是在普通企业里,大部分人（尤其是领导和管理人员）不熟悉。
学习和的难度远高于和。
✧项目经理和开发组长要有能力控制迭代过程,否则迭代式开发就变得混乱无序和漫无边际。
可是国内很多项目经理连瀑布式开发过程都控制不住,他们又怎么能够管理好迭代过程呢？
使用的风险是很高的.
根据上述分析和许多同行的反馈，我们可以得出一个结论：
及其配套的软件工具基本上不适合于国内中小型软件机构，只有大型企业才用得起。
企业常见的研发管理问题
2。
3。
1组织结构和人力资源管理问题
✧组织结构臃肿，效率低下，存在一些不能产生效益的职位。
✧项目矩阵关系比较复杂,项目成员不知道听“职能经理”还是“项目经理”指挥。
✧项目经理之上的领导太多。
能干的人都是搞管理了，谁在第一线把活干好？
✧岗位和职责不清晰,而且经常变动,好多人
升级会员 