大家好！今天让小编来大家介绍下关于光伏运维公司组织架构_公司运营中心人员架构的问题，以下是小编对此问题的归纳整理，让我们一起来看看吧。
文章目录列表:
1.互联网公司研发效能团队多种组织架构和优劣势分析2.公司运营中心人员架构
互联网公司研发效能团队多种组织架构和优劣势分析
这是「[互联网公司研发效能团队建设] 」的第二篇。为啥研发效能要是一个相对独立的团队呢？独立的研发效能团队是最大化行使职能的必要保障。我一直认为组织架构是第二生产力(第一是人)。搭好台子好唱戏。台子左右不平，前高后低，再大的角都可能崴脚跌跟头。
我们可以定义研发效能团队的工作边界是(需求管理+任务管理+项目管理)平台+devops+APM+应用运维，负责从用户需求提出到上线、到应用运维的整个过程，它的存在就是为了打破团队之间割裂、各自为战的情况，同时可以把各个团队共性的需求集中统筹，使整个开发活动能够顺畅、高效的运行。研发效能团队一旦和某一个团队在一起，却没有更高的视野去思考这个事情，把控好业务方向，业务可能就会跑偏。研发效能靠近哪个团队，就会侧重哪个团队的业务，对哪个团队服务的职能就做得好，对整个研发过程的关注度就会降低，从而研发效能团队的定位和作用会受到影响。
研发效能团队和运维团队在一起，这种组织架构我是看到过的。一开始快手的运维小伙伴也同时负责流水线部分的建设。这个是可以理解的，因为运维小伙伴负责公司的基础设施，公司的服务想要上线到运维的基础设施上必然要有一个上线系统。顺手牵羊，运维小伙伴就把流水线也给做了，他们也只做到了流水线。流水线之前的部分就没参与，因为那些和运维关系不大，同时受限于人力物力，运维小伙伴就没涉及流水线前面的部分。和机器运维部分相比，产研场景更靠前，涉及产品经理、项目管理、RD和QA同学部分的流程化、标准化、自动化要难得多。这种组合优劣势非常明显：
研发效能团队和QA团队在一起，这种组织架构我是看到过的。后来组织架构调整，研发效能团队就和QA小伙伴在一起了。如果研发效能和QA团队在一起形成合力，做的事情和影响力绝对高高的，这也是我见到的能最好地发挥1+1>2的组织结构。只可惜天时地利都占了，效果却并不理想，非常可惜。
根据我长期的观察，觉得主要是用人+定位的问题；这里主要谈定位的问题，研发效能+QA这个组合，其实是在两个专业领域发力，然后在一起的合力产生更大的效果，而不是在QA平台上长出一个研发效能平台。快手效率工程在这一点上则做的不错，研发效能团队支持所有的平台建设，通过接口和内部的QA自动化测试平台进行打通，各自业务都能按照自己的节奏走，同时还可以在「结合」的功能点上进行合作、共建、互相支撑。
研发效能团队和PMO团队在一起。这种组织架构我也经历过。PMO在业务线给研发效能团队推广平台，带来用户诉求，研发效能支撑这些用户诉求并在日常工作中给予支撑和支持。这种模式的关键点是研发效能团队要直接扎到一线人员中。否则平台最后容易成为一个项目管理平台，最大程度满足了PMO小伙伴的管理诉求，而不是一线产研团队的小伙伴的诉求。一线团队在那骂平台做得不切实际，不好用，体验差，都是没做过产研团队的人臆想的需求；研发效能团队也很叫屈，你说的需求我都做了啊。实际上平台做的需求都是「PMO的」需求，并没有解决「一线实际用户」的痛点。
项目管理专家型的意见和建议，需要认真对待和评估，同时千万不能忽视一线实际用户的诉求。当然这里也有合作正向的例子可以参考。
此表格为服务端研发效能涉及的部分工作。从上面的表格，我们就可以看到每个角色关注不同的研发效能域，即便是同一研发效能域，不同角色的关注度程度也不一样。有的公司觉得研发效能和运维团队都是公司的「成本中心」，都是支撑团队，于是把研发效能和运维团队放到一起，组成一个大的「infra」、「基础平台」或者「平台架构」团队，实际上应该从用户的角度出发，把研发效能团队推向他的客户身边。运维团队并不是研发效能服务的第一用户，我们的主要用户是产品经理、项目经理、RD和QA小伙伴，只是运维团队支撑研发效能团队，离我们最近经常打交道，我们是运维资源的大客户而已。
所以我更趋向于成立独立的研发效能团队、行使职能。如果非要和其它团队在一起，那么和研发团队在一起，这是第二选择；只不过因为RD小伙伴通常以业务线/产品线进行闭环到一个独立的团队，而研发效能团队作为公共资源又很难划分到某一业务线/产品线。第四选择是和QA组成一个大团队，这种组合有利于质量保证平台的建设，最后是研发效能和运维在一起。
而快手效率工程走了另外一条路，我们把以上所有支撑平台的产研（包含部分运维平台的建设）都划分到一个团队去支撑，相当于研发效能+QA平台支撑+基础架构平台+运维平台(部分），避免了重复建设、同时资源利用最大化。最后取得的结果和效果也很不错，我个人认为在1000人以下的规模可以采取这种组织架构。千人以上可以参考我下篇文章的内容，主要讲了产研团队在2000人左右，研发效能团队的组织架构和团队建设。
公司运营中心人员架构
软件开发的过程包括：用户需求分析、系统概要设计、系统详细设计、编码、测试等环节。但是对于一个企业解决方案而言在软件开发的每一个过程中由于项目组人员的复杂性可能会存在着较为复杂的情况。在本文中企业解决方案是指业务部门提出了对系统的需求，通过招投标选择了一个或多个开发商，参与项目的人员包括业务部门、企业IT部门、开发商和最终用户。此外，在这里也对企业的类型限定为功能型的组织架构，对于项目型组织架构的企业存在的问题可能相对较少一些。
在第一部分将介绍目前许多软件项目大多使用的组织架构及其职责，指出其不足之处，然后说明该种组织机构的实质是什么。第二部分将给出作者认为较好的组织机构，并对其职责进行了较为详细地描述。
在本文中基于如下的企业解决方案为例进行展开：A企业的采购部门提出了建立B2B电子商务的需求，经过和IT部门合作选择了B和C两家开发商，其中B开发商负责B2B网站的开发，C开发商负责数据分析和报表的开发。参加需求调研和参与测试的供应商包括D、E和F。
1 功能型的组织架构
对于功能型组织架构的企业而言，对于前言中提出的B2B项目的组织架构一般而言。这种组织机构的特点是按照企业的组织架构组成了企业解决方案的组织架构，其最上层--也就是项目经理的角色--是企业的较高级别的管理人员。在接下来的一层分别是业务部门和IT部门的管理人员。由于供应商是经常和业务部门进行沟通的，因此将供应商的相关人员安排在业务部门负责人的下面，而一般开发商和IT部门有较多的沟通，因此将开发商放在IT负责任的下面。
这种组织机构存在着以下的不足：
1） 项目经理应该对整个项目的成功负责，但是考虑到企业的高层管理人员其他相关工作已经非常满，因此很难有时间来承担起项目经理的角色。
2） 由于第一个先天的缺陷，导致了整个项目的决策会较为缓慢。比如当业务部门和IT部门产生矛盾时，由于较高级别管理人员可能没有时间来了解矛盾细节而导致业务部门和IT部门会就某些事情争执不下，很难达成统一的认识，导致项目的拖延。比如，就项目范围而言，可能在需求分析阶段会有不一致的地方。
3） 当开发商和业务部门产生了矛盾的时候--比如对需求的完成程度--解决这些问题也会较为拖延。由于问题最终需要一层一层地汇总到IT部门负责人和业务部门负责人这里进行解决。
4） 开发商A和开发商B产生矛盾分歧的时候解决问题也存在着困难，因为A和B都在为自己争取的利益，当产生矛盾时，双方会产生相互推委的现象。
5） 由于业务部门负责人和IT部门负责人可能也有许多其它工作，因此实际上变成了业务部门实施人员和IT部门实施人员来推进项目管理。由于其所处于项目的较低层，因此处理问题的能力有限。
总结为一句话，这种组织机构可能产生的后果就是在项目组织的职责不明确，决策缓慢，项目拖延等问题。
2 改善的组织架构
针对于功能组织架构存在的问题点，下面将论述作者认为较好的组织架构。首先考虑到企业较高管理层人员的时间关系，因此不适合将他们放在项目经理的位置上，而是将高管人员置于评价者和支持者的位置。在上一部分谈到了业务部门和IT部门可能会存在着争执，如何解决这个矛盾，结合第一个问题点的解决，就是将业务部门和IT部门的相关负责人共同组成双人的项目经理，这里对两个项目经理的要求是业务负责人要较为精通业务但是也要具有IT的相关知识，IT负责人要熟悉IT，了解IT项目的特性并且熟悉IT项目管理和业务流程，他们也需要有充足的时间花在项目上，此外一个较高的要求是他们必须有较强的沟通能力。这样就形成了高管进行评价和支持，业务和IT相关负责人来具体管理项目的项目决策、支持和管理层。项目经理主要进行项目的范围管理、时间管理、质量管理和沟通管理。尤其值得一提的是项目的需求变更必须由项目经理牢牢把握，因为许多企业项目不能按时、按质完成的主要原因是需求变更无法有效控制，而设置业务和IT人员作为项目经理的设置方式可以有效地避免存在以上的问题。
由于项目经理是管理人员，对于业务和IT一般而言并不是专家，这时考虑到IT项目在需求分析和IT架构设计阶段需要专家的支持。因此建议增加业务和IT专家对项目经理进行专业级的支持，这些专家可以来自公司内部，也可以来自相应的咨询公司或监理公司。业务和IT专家的支持可以保障项目能够避免业务上的错误，也可以较宽深的视野来评判IT架构。
此外作者推荐较为扁平的组织架构，除非项目非常庞大。作者建议每位项目经理直接下属控制在5人左右，如果项目较大，项目的组织机构要向纵深发展一些。业务部门项目经理主要负责协调业务部门的实施人员和供应商的参与人员，而IT部门的项目经理主要负责协调IT部门实施人员和开发商的项目经理。这里需要提醒的是对于实力较强的开发商，可以只负责管理到开发商项目经理这一层，而对于一些规范性不太强，项目经验不足的供应商。业务/IT部门的项目经理需要和业务/IT专家一起为开发商制定开发规范和进行项目管理的指导。
以上所描述的企业解决方案的组织架构可以由图3来表示，这是一个较为扁平的组织架构，通过业务/IT相关负责人的共同管理，可以较为高效地推进项目。在这里还需要提出的一点就是，一旦确定项目经理，必须给他们一定的权力，比如项目组员的选取以及对项目组成员的考核，否则还是会出现项目经理很难协调某些项目组成员。
3 总结
在许多项目管理的书籍中对软件项目管理进行了理论上和理想中的描述。在作者的《企业信息系统项目管理的问题点和对策》一文中，结合项目管理理论论述了企业信息化过程中项目管理中存在的问题点。考虑到企业软件项目中存在着太多不成功的案例，结合关键链技术，作者完成了《企业软件项目关键链技术》，在其中作者论述了如何将关键链技术应用在软件项目管理中。
但是在实际企业解决方案的项目管理中，作者也发现了在具备了业务/IT素养的企业，人员沟通的问题是导致项目失败的重要原因之一。正是出于解决企业项目管理中存在的各种问题，本人一直也在考虑如何才能够更加有效地推进企业的解决方案类的项目管理问题，这也是本文产生的一个原因。
由于许多企业是功能型的组织架构，因此对于IT解决方案的项目管理让其转变为项目型的架构太困难了以至于很难实现，因此作者在一开始介绍了功能型的项目组织架构，并且指出了其中存在的问题点。为了克服这种组织架构的弱点，同时也考虑到企业的功能型组织架构，作者提出了一种较为理想的组织架构，这也是作者在企业IT项目管理中一直试图实现的一种组织架构，并且也发现本质上如图3所示的组织架构确实可以有效地推进项目。
当然，组织架构只是项目的一个方面，组织架构中的人必须能够发挥各自的职责才是项目成功的保障。
基础部门：1财务、2行政人事
运维部门：
3 客服部（兼充当GM或论坛版主，还兼游戏评测....三班倒或四班倒）
4 技术支持部（服务器架设维护等）
运营部门：
5 网站部门（网站开发维护、充值系统billing技术、美工兼市场宣传材料等美术工作）；
6 市场部门（商务拓展BD、媒介、渠道、活动策划专员/文案、工会专员、市场文案、地面推广）
一个运营公司基本就是上述职能划分，某些具体岗位归属是根据leader的能力和精力而定的，但怎么都要有人独立或兼任完成。职能不会变，只会再拆分细化；而构架会因时因人而变。
CEO外，一般设一个COO，根据能力会把运维和运营两大块都归COO直接领导，运维工作相对简单，多是常规性routine工作。核心是市场部门，因为他们更多是处理不确定性的事务或涉及外部的事务。
一般每日要出三份报告：用户数据报告、收入相关数据报告和客服简报。关键性数据KPI可设定为后台自动以短信形式每日1次-3次发送到高管手机上。
我有国内多家上市游戏公司的某一时点的组织构架图，也有我做的组织构架图示及详注。上市游戏公司的组织构架是网上公开有的，早已发生变化；基础模块解说是我传到网上的，你google一下应该还能找到。
“组织结构”是静态、块状的，侧重权责划分和回报体系；实际上后面隐藏着一个更重要的动态的、线状“公司运作流程图”，侧重公司主要事务在公司内部的流转和部门之间的协同。
求追加
