互联网技术团队的绩效管理互联网大讲堂X.docx
《互联网技术团队的绩效管理互联网大讲堂X.docx》由会员分享，可在线阅读，更多相关《互联网技术团队的绩效管理互联网大讲堂X.docx（101页珍藏版）》请在冰点文库上搜索。
互联网技术团队的绩效管理互联网大讲堂X
文件编码（008-TTIG-UTITD-GKBTT-PUUTI-WYTUI-8256）
互联网技术团队的绩效管理互联网大讲堂X
互联网技术团队的绩效管理-互联网大讲堂-
2010年12月22日
15:
06
主讲：
余波>>>
时间：
2010-12-2215：
00至17：
00
地点：
互联网大讲堂
群号：
余波：
各位群友大家好，非常高兴今天能够和大家探讨一下研发绩效管理方面的东西。
先简单介绍一下我自己，我叫余波，来自5173，5173是一家电子商务公司，提供网游虚拟物品的交易服务，可以简单理解成垂直领域的淘宝，在虚拟物品交易这个细分市场，我们一直是领跑者。
目前平台上每年产生的交易有数十亿，交易平台的注册用户和日均PV都是千万级。
我刚刚加入公司时，技术团队只有二三十人，随着公司的成长，目前技术团队已经扩张到两百多人。
团队从小到大的过程，是不断克服各种问题的过程，在这个过程中我们积累了一点心得，今天和大家探讨的内容就是其中一部分：
互联网技术团队的绩效管理。
今天的话题分为几个部分：
1、绩效考核的诉求
2、绩效的来源
3、互联网研发团队绩效方案设计
4、考核结果的应用
5、集中问答
绩效考核的诉求：
在做绩效考核之前，我们要问自己一个问题：
我们做绩效考核是为了什么呢
我的答案是为了识别团队的产能分布，以便在分布的基础上实施针对性的管理策略。
假如我们是在打仗的话，那么这个绩效考核就是为了收集一线情报，有了情报的支持，我们就会比较有方向，而不是凭直觉、拍脑袋。
所以，如果一个绩效考核办法，不能把杰出的10％和需改进的5％分辨出来，无论方案本身多么豪华，也是失败的。
这两端的部分，往往是我们管理工作的重点，10%的优秀分子，是火车头，是驱动力，他们能够基于现状，创造解决问题的方法，然后让85%的人使用它们的方法来产生更好的绩效，这10%的人，某种程度上决定了团队的未来；而后面5%的人，往往是产能的黑洞，这些人占用资源不说，往往还是抱怨、委屈和无能之集大成者，这些人如同病毒，自己所产生的价值有限不说，还有可能严重干扰别人，往往团队中那些怪怪的味道，都是从这些人身上散发出来的。
所以，这也是管理者需要分配多一点精力的人群，当然，如果企业要裁员，通常也是把名额给这些人。
只是在我的相像中，另外5%是可以通过管理手段改善的，这是管理者的责任，当然也是我个人的一个感性假设，当然被考核者，往往是比较不希望自己被揪出来的放在太阳下烤的，在我们制定绩效考核方案的过程中，曾经多次调研走访一线工程师，他们有一个普遍的声音，就是希望最终的结果是一片和谐，要么大家都是50分，要么大家都是90分，但如果真按照他们的意愿来操作，我敢打赌，我们将慢慢失去那杰出的10%，然后，我们怎么可能在杰出人才越来越少的情况下攻城略地呢说到这里，我们还要认识到一个事实：
平凡的大多数（85%）是中坚力量，他们有稳定的绩效产出，而且不容易跳槽，容易跳槽的是那10%的人，还有5%容易“被跳槽”的人，为什么需要绩效考核我们就说到这。
绩效的来源：
团队很小的时候靠的是个人能力，种子选手，以一挡十那种，当团队达到一定规模的时候，种子选手的作用已经不是十分明显，中竖力量是“平庸的大多数”，这个时候流程的作用会非常明显，用流程来产生规模效应，同时用流程来规避对种子选手的过分依赖，降低绩效风险（种子选人是最不稳定的人群），当团队更大的时候，平庸的大多数已经成百上千了，团队和工作的多样性让流程的局限性充分暴露出来，此时，靠的是一种类的解决方案，所有员工自动自发的创造性、生产力，这种自动自发出来东西的有效性，需要用文化和价值观来驱动和指导，以上三个阶段，是一种大概的划分，其实在任何一个规模下，三个维度都是互相补充的：
人、流程、文化。
所以，我们所有的努力其实都是基于这三个方面的认知和努力；
人：
首先人的方面，个人能力很容易理解，当然是越强越好，当然要在人力成本的限制条件下，除此此外，还有一个东西很重要，那就是合适的组织结构（单元）
我们每个项目组有一名项目经理带三四名工程师，我们发现这是一个非常精巧的配比，组员的效率容易挖掘，管理成本比较低，协同高效，所以，后期虽然整个团队规模不断变大，但也都是基于这样的项目单元，通过细胞分裂的方式来扩展的。
这种在业务推动下的自然分裂是非常经济和现实的，基于项目类型的同质分裂，分裂出来的项目组的工作内容（项目类型）大同小异。
与此同时，随着团队规模的不断扩大，分工越来越精细，还会有新的工种出现，新工种会专注于某一细分基础模块的工作，这是一种异质分裂，典型的新工种是架构师，团队规模很小的时候，设置专职架构师是件满奢侈的事情，项目经理往往是以一当十的用的，如果有一件事情不知道该给谁做，通常都是由项目经理兼的，当系统规模越来越大的时候，着眼于全局的架构设计，再由项目经理兼做几乎是不可能胜任的，这个时候就必须依赖专职的架构人才，成立架构师团队，不然大家就成天火烧屁股了，架构师团队和项目团队的关注点是有很大不同的，前者我们称为创新线，更多关注创造力，后者称为项目线，关注项目吞吐。
针对这两条线，我们设置不同的绩效管理办法，用不同的指标进行绩效跟踪。
组织结构问题解决了，我们相当于把一台“拖拉机”变成了“法拉利”。
正当我们踌躇满志准备上路时，我们发现摆在面前的是一条泥泞的小路，请问法拉利能够跑过原来的拖拉机吗，即使能够跑过，我想也不敢跑太快吧，一不小心底盘就报销了，舍不得啊，为了让法拉利们能够跑得快一点，我们需要一条高速公路，在高速公路上，我们设定规则，要求速度达到多少才能够上去，像拖拉机这种压根就不让上了，从而保证车流吞吐，这条高速公路就是流程，当我们已经不是三五个人加几条枪的时候，流程对绩效的影响是巨大的（因为流程，更多是为那85%服务的）。
流程：
流程的设计，最怕生搬硬套，我有两个关键体会：
1、注意各协作团队的综合能力配比，关注瓶颈节点，比如收费站，就是高速公路的一个瓶颈节点，还有容易出车祸的路段也是瓶颈节点，直接影响车流吞吐（排队啊），体到我们的工作现场也有类似的典型瓶颈，比如，当QC资源不足时，项目质量很大程度上要依赖开发团队自己，这个时候再强调什么理论上的职责分工就是不切实际的，这个时候要通过诸如代码走查制度、加强单元测试来弥补，这其实是一种典型的用开发换测试的做法。
目的是打掉整个流程的瓶颈；
2、控制流程本身的成本，够用就好，开发资源不足时，还一定要出详细的设计文档；QC资源不足时，还要求一定要有完整的测试用例，这些都是学院派干的事情，靠谱的流程都是经过裁剪的，以牺牲某种特性来换取更大的好处，所谓两权相害取其轻，否则，我们付出的流程成本基本上是打了水漂，更重要的是，流程成本不光是指我们遵循这个流程所花费的时间，还有繁琐的流程所吃掉的工作热情。
文化：
在我的理解中，所有的文化都是为了制造幸福感，当一个人幸福并快乐的时候，这本身就是一种强大的生产力，我依然记得在BenQ时，当时的副总张安佐有一句话“每天早上眼睛一睁开，就能够一跃而起的人是最幸福的”，某种程度上，我们所有人都在追求能够让自己每天一跃而起的事情，比如对于一个母亲那可能是为家人准备一顿丰盛的早餐，那么照顾好这个家就是她一跃而起的动力，而之于我们，如果一份工作能够让我们一跃而起，那我们怎么可能没有效率，一跃而起是源于我们内心对于团队及团队所做的事情的深深的认同，这种认同是一种人性文化的深耕。
以上部分，是有关绩效来源的一些思考
互联网研发团队绩效方案设计：
先要介绍一下技术团队的生存背景，对于一家电子商务公司来说，其真正的产品是“交易服务”，交易服务由两方面构成，一个是产品和技术提供的在线交易平台（生产工具），另外一个是客服提供的过程服务（生产），而负责将“交易服务”卖出去的责任更多的落在营销（市场、运营），持续、快速的交付对用户有价值的交易服务，是电子商务公司的核心竞争力，对于技术团队来说，持续、快速的交付高质量的平台特性，是技术团队的生存根本，鉴于这样的特点，我们的项目特点是追求短平快，百分之七八十的项目的实施周期都在一周以内，项目规模很小，偶尔有大的项目，我们也是想尽办法把它分解成一二三期，从而降低项目的实施周期，这样做的好处是显而易见的。
让一个特性最快与用户见面，是验证它是否有效的最好办法。
结合大部分项目周期都在一周以内的特点，我们把项目绩效的度量周期定为一个月，每个月会进行一次绩效回顾，让各项目组总结调整，注意，我们只是把月度作为度量统计的单位，绩效考核的周期还是以季度为周期的，月度的度量，决定项目奖金的分配。
而季度绩效考核，影响的是季度奖，为什么不选择月考呢有两个原因：
首先如果每个月考一遍，管理成本太高了，其次，绩效考核的目的就是在对产能分布进行识别，我们还有20%的跨月项目的，用季度这样的宽度，可以更好的覆盖，让各个项目组之间的比对数据更具参考价值
在上述原则的指导下，我们接下来谈谈具体绩效考核方案的设计，技术团队绩效考核方案的制定，整体遵守几个原则：
１、使用项目绩效分，来衡量项目业绩
２、使用非项目绩效分（事件绩效分），来衡量日常工作之外的创新、拓展贡献
３、对于同一类型岗位，使用统一考核模型（权重和算法可调）
４、对于差异性较大的小工种，使用个性考核办法
５、管理职能与执行职能考核分离
根据以上原则，我们将考核方案分为四条线：
项目线、创新线、管理线、标准线，同时，整个绩效考核的维度框架，统一为：
主营业绩80%、事件绩效15%、综合评定5%；主营业绩，是指你的岗位职责要求你承担的责任表现；什么是非项目绩效（事件绩效）呢顾名思义，就是项目之外的贡献产生的绩效，这个名字是我们一开始时候在项目部推出来的，现在已经在整个技术部门应用，所以现在叫称作“事件绩效”会更贴切些。
作为技术部门，项目一直是我们的主营内容，我们在制定KPI时，也是重点关注这个部分，比如通过人均项目绩效分来衡量项目产能。
然而日常工作中还有很多贡献不在KPI中，比如内部讲师作培训、比如招聘面试等等。
这部分没在KPI上反应出来的贡献，显然不是无关紧要的，此外，这些事情还与员工的工作热情有很大的关联，人们总是对做擅长的事情充满热情，比如擅长演讲的人乐意去作培训，擅长沟通的人乐意去面谈，对代码有洁癖的人乐意去做CodeReview等等，如果这些贡献不能够在绩效上反应出来，做和不做没什么区别，谁还愿意做下去呢，热情在萎缩的同时，整个团队的能量也在萎缩，除此之外，当团队越来越大，面对的事情也会越来越复杂，一线的情报传递上来往往会延时或失真，管理工作也因此往往会很被动，这个时候就需要激发一线员工的创造力和热情，让他们去开动脑筋，他们想出来的事情往往更加切合实际，而我们从中识别出“重要”的部分加以大力推动，岂不快哉，这样一来，我们就有了一个巨大的脑库，有源源不断的点子来推动团队的发展。
事件绩效的量化，我们也有一套办法
基本思路就是按照事件的价值大小，分级给一定的分值，然后评估时又分解成基础分和执行效果分，有一个换算公式：
绩效分=基础分+价值基数*目标效果系数
，“综合评定”，其实就是给管理上级拍脑袋的，大家可以注意到，这个比例非常小，这个靠感觉的不敢给的很大，当然，在团队很小的时候，我们也通常是别无选择的拍脑袋，那个时候是靠“英雄人物”推动绩效的。
我们前面提到几条考核线，每一个考核维度在不同绩效线，也有不同的含义，比如项目线主营业绩就是指项目贡献度，使用项目绩效分来衡量，这个绩效分由多个因素构成，比如编码工作量、比如协调工作量等等，我们有一个评审委员会，专门负责分配绩效初始分，每一个项目都会有一个初始分，后面还会根据项目的测试质量等级、进度执行情况对分值进行加减，具体的评分细则我就不展开了。
创新线的主营业绩分解成：
发起多少提案，有多少提案被评审通过（可靠性和价值评估），有多少提案被应用推广。
创新线是稀缺资源，所以现在用数量积分的方式操作，也是为了鼓励创新。
管理线，是指部门经理以上,主营业绩是指：
部门人均绩效指标、提前商定的关键目标，标准线，主要是给一些助理类的职位的，不展开。
以上，是绩效考核方案的整体设计框架，这个思考框架，其实不局限于技术团队，某种程度上是普适的。
考核结果的应用
坚持一个原则：
一定要认真的做绩效反馈，即直接上级，要和下属进行绩效面谈，告诉下属，哪里做的好，哪里做的不够，如果想获得更好的绩效，未来的努力方向是什么，以及可以利用的资源有哪些，这方面虽然说的内容不多，但非常重要，正如我们一开始说的，绩效考核的目的是识别产能分布，然后采取相应的管理动作，那么绩效反馈便是其中一个管理动作，一切的管理动作都是围绕“改善绩效”展开的，而最有效的，往往是面对面的谈话辅导，当然，谈话之后，还会有绩效跟进工作，这是一个持续改进的循环。
问题
1、前面讲到：
后面5%的人往往是成事不足败事有余的人，但团队中往往存在一种人：
人个能力很强，但喜欢生事，挑动别人“造反”。
这种人如何去考核和处理。
这种人，一旦拿下，就会是一把快刀，而且会非常“忠心”。
那么问题变成了，他凭什么听我们的所以，我觉得这个问题的视角不是怎么处理他，而是怎么去培养自己的驾驭能力。
你之所以是他的领导，那么你就应该有一些东西，是比他有优势的。
我的做法与大家分享一下。
1、首先我们不要有畏惧心理，如果你一开始就怕了，对方就可以感受到你怕了，首先首先要克服自己的这个心理；2、对于对方的优势，一定要给予足够的肯定和赞赏，最好在公开场合表达肯定；3、在前面两个基础上，寻找机会，用霹雳手段告诉对方的缺点，一定要足够直接，一个人能力很强，通常是指某一方面很强，就一定有一些方面是不够的。
2、容易跳槽的10%是哪些人
就是能力特别强的人那群人，这群人往往业绩非常好，心气也很高，有很多企业给他们发橄榄枝。
对于这些人，更多的是给他们自己想要的东西，往往是尊重、认可。
3、创业团队，本来就没几个开发人员，遇到技术骨干成员突然离开，项目开发又在进行中，如何处理呢
技术骨干离开，是很杯具的事情。
我也遇到过，坦白的讲，人已经离开了，就没什么好办法了。
创业团队在初期选择合作伙伴的时候一定要慎重，不要因为项目急，就随便用人。
另外，创业团队一定要舍得给期权。
大家都是在赌一个未来。
一个人，愿意进你的公司，就是相信这个公司的未来的，否则，他没有必要进来的，进来之后，又要走，是因为动力不足。
不愿意分享公司的未来，肯定是要走的。
创业公司太难了，要什么没什么，还不给点希望，能不走嘛。
期权是防火墙，有了防火墙，要做的事情还很多，如何增加团队的动力，是另外一个大的话题，收集下，我们回头看时间要不要讨论。
4、绩效考核做的太过。
。
很多人只以绩效目标为工作目标。
。
更多的人为了更好的绩效制造和解决更多的问题从而体现自己的业绩结果造成大量的时间和资源的浪费
5、完全背离了绩效作为手段是促进企业发展的目的请问这个问题有什么好的解决办法吗
这个问题，有点难度。
这是一个度的问题，这是管理者要面对的问题。
管理工作从来都是动态的。
绩效方面也不应该是死的，每个阶段都要定义不同的绩效目标
可能一段时间内，追求项目吞吐，下一估时间追求项目质量和稳定性，还有可能是追求创新实践。
绩效考核是”管“的手段，但是能让那10%留下来，肯定需要一些”理“的手腕。
千万不要静态的看待任何一个制度，一个管理者，要时刻解决两个问题：
方向和动力。
我们开车从上海到北京，没人走直线吧，管理者，就是通过绩效手段，来转方向盘，左打打，右打打，打着打着就到北京了，关键问题是，管理者如果自己都不知道要去哪，那就惨了，另外一个是动力的问题，我们都想去北京，可以走到半路没油了，肯定到不了北京，那管理者，就要知道哪里有油，哪里能够加上，加的成本是多少。
6、还有另一个kpi在设计之初做的比较表面化虽然也做了价值观和专业度两方面的内容以及权重但是因为缺乏具体的度量方式造成kpi考核实际上只是上级领导的一句话而已。
请问这种情况有没有办法能在后期进行补救的
价值观考核和业绩考核要分开进行，业绩考核决定你能不能保住这个饭碗，价值观考核，是决定你有没有晋升的空间，所以，这两个东西，不要搞到一起来。
普通员工，还是以做好事情为主，要考核价值观，也是在招聘的时候过滤。
7、绩效考核制定需要不需要公开，大家齐参与
需要，必须全员参与，要公开透明，而且是必须透明。
让公众来监督这个制度，完善这个制度。
在决策上，我比较赞同一句话：
听大多数人的意见，和少数人商量，做自己的决定。
但一旦决策了，制度的运行及运行的结果，都要透明公开，这样，会省去很多力气，来做监管。
7、一个团队的teamleader模式是需要对这个团队所有成员的工作都精通么如果不精通是不是就做不好管理呢
不需要，管理者，是解决方向和动力的问题，不是解决怎么开车的问题，但，最好是某方面的专家，总归要在某一方面有话语权，不然很容易被挑战。
同时，要在心态上接受专家们确实比较自己专业。
8、刚才余波老师谈到团队绩效考核时，讲了5个原则，其中有一条说“管理职能与执行职能考核分离”。
我赞成管理职能与执行职能分离，但我想请问，履行管理职能之前是否必须有执行岗位的经验呢
9、赞同必须有一线的经验，完全不懂业务，是不可能做好管理的。
这样的人，在上任之前，应该放到一线呆一段时间。
我这里想分享一下，DDI的能力模型。
DDI认为，一个人的成功因素有四个方面的因素。
这个模型当中，知识和经验，就是刚才大家所说的专业技能方面的东西，其实是比较容易学会的。
但“能力”和“个性”这种东西，是普适的，是比较重要，却又非常难的。
我们之所以能够领导别人，更多的取决于“行为能力”和“个性”。
比如“客户至上”，这种能力，就是普适的，不管在什么岗位上，如果都会在自己的行为中表现出客户至上的能力，那么就很好。
10、绩效评审委员会怎么的组成
这个委员会非常关键，因为他直接影响公平性。
我们是从各个项目组选比较资深的同事担任，这些同事在上岗之前要进行相应的培训，进行几轮试打分，以校正每个人的打分价值系。
我们以前的打分工作，是由一个权威人士一个人承担的，但因为他的精力不够，后来才有了评审委员会。
一个人做的好处是，标准是一样的。
那么这个权威人士以前的打分标准，就是参照系，我们在培训的时候，就以这个参照系作为坐标，来校正。
同时，这些评审委员不能够给自己组的项目打分。
同时，权威人士，每月会随机抽取5%-10%的项目，进行打分，将打分的结果与委员会结果进行比对，校正，相当于稽查。
同时，每个项目组如果觉得自己的打分是不合理的，可以投诉，进行仲裁。
群聊天信息详细原件:
漫步人生-产品14:
04:
34？
第22期话题：
互联网技术团队的绩效管理？
嘉宾：
余波；
主持人：
一诺
时间：
2010-12-2215：
00至17：
00；
`一诺-运营14:
49:
48？
互联网技术团队的绩效管理嘉宾：
余波；时间：
2010-12-2215：
00至17：
00即将开始请嘉宾和听众准备知识盛宴不容错过？
拾麦-设计（01）14:
50:
04？
老徐（5）14:
50:
26？
踏春-移动互联
（2）14:
53:
00？
坐等
鹧鸪-策划推广（3）14:
53:
22？
搬马甲坐等
豆子-产品（）14:
53:
52？
介绍一下嘉宾把
:
]泽[:
-PM（）14:
54:
39？
？
余波-电子商务14:
54:
55？
自曝一下：
踏春-移动互联
（2）14:
55:
48？
信息对抗专业。
ResetCpus-运营
（2）14:
57:
25？
信息对抗；，。
。
“波波”哥；
求解释；
豆子-产品（）14:
57:
49？
解密反解密我乱猜滴
余波-电子商务14:
57:
59？
嘿嘿，就是这个方向
余波-电子商务14:
58:
13？
密码学、基础协议之类的东西
余波-电子商务14:
58:
27？
回头再聊这个，等下我们就开始今天的分享了
豆子-产品（）14:
58:
33？
顶
`一诺-运营14:
58:
43？
还有两分钟哦看来大家对今天的嘉宾好奇心很重啊？
ResetCpus-运营
（2）14:
58:
53？
？
`一诺-运营14:
58:
55？
1分钟倒计时？
漫步人生-产品14:
59:
24？
`一诺-运营14:
59:
31？
大家有什么问题可以小窗发给我？
`一诺-运营14:
59:
52？
今天我暂代理漫步
`一诺-运营15:
00:
37？
下面友情今日嘉宾开始今天的分享？
`一诺-运营15:
00:
51？
余波-电子商务15:
00:
54？
各位群友大家好，非常高兴今天能够和大家探讨一下研发绩效管理方面的东西。
余波-电子商务15:
01:
11？
先简单介绍一下我自己，我叫余波，来自5173，
圆规-运营+产品（）15:
02:
38？
余波-电子商务15:
03:
07？
5173是一家电子商务公司，提供网游虚拟物品的交易服务，可以简单理解成垂直领域的淘宝，在虚拟物品交易这个细分市场，我们一直是领跑者。
目前平台上每年产生的交易有数十亿，交易平台的注册用户和日均PV都是千万级。
余波-电子商务15:
03:
40？
我刚刚加入公司时，技术团队只有二三十人，随着公司的成长，目前技术团队已经扩张到两百多人。
团队从小到大的过程，是不断克服各种问题的过程，在这个过程中我们积累了一点心得，今天和大家探讨的内容就是其中一部分：
互联网技术团队的绩效管理。
余波-电子商务15:
04:
10？
今天的话题分为几个部分：
1、绩效考核的诉求
2、绩效的来源
3、互联网研发团队绩效方案设计
4、考核结果的应用
5、集中问答
余波-电子商务15:
04:
48？
在我分享的过程中，各位有可能会产生一些问题，为了保证整个分享的流畅，建议各位先找个地方记下来，或者小窗发给主持人一诺，我们在后面时间来集中互动，谢谢各位。
余波-电子商务15:
05:
22？
那我们正式开始吧
余波-电子商务15:
05:
36？
在做绩效考核之前，我们要问自己一个问题：
我们做绩效考核是为了什么呢？
余波-电子商务15:
05:
50？
我的答案是为了识别团队的产能分布，以便在分布的基础上实施针对性的管理策略。
余波-电子商务15:
06:
12？
假如我们是在打仗的话，那么这个绩效考核就是为了收集一线情报，有了情报的支持，我们就会比较有方向，而不是凭直觉、拍脑袋。
余波-电子商务15:
06:
40？
所以，如果一个绩效考核办法，不能把杰出的10％和需改进的5％分辨出来，无论方案本身多么豪华，也是失败的。
余波-电子商务15:
06:
59？
这两端的部分，往往是我们管理工作的重点。
余波-电子商务15:
07:
19？
这10%的优秀分子，是火车头，是驱动力，他们能够基于现状，创造解决问题的方法，然后让85%的人使用它们的方法来产生更好的绩效。
这10%的人，某种程度上决定了团队的未来。
余波-电子商务15:
07:
54？
后面5%的人，往往是产能的黑洞
余波-电子商务15:
08:
05？
这些人占用资源不说，往往还是抱怨、委屈和无能之集大成者
余波-电子商务15:
08:
28？
这些人如同病毒，自己所产生的价值有限不说，还有可能严重干扰别人
余波-电子商务15:
08:
50？
往往团队中那些怪怪的味道，都是从这些人身上散发出来的。
余波-电子商务15:
09:
05？
所以，这也是管理者需要分配多一点精力的人群
余波-电子商务15:
09:
18？
当然，如果企业要裁员，通常
升级会员 