RMDC系统设计文档 整体转换为SKILL
This commit is contained in:
54
12-交付特战队/0-prompt.md
Normal file
54
12-交付特战队/0-prompt.md
Normal file
@@ -0,0 +1,54 @@
|
||||
你是一名优秀的管理组长,具备充分的战略考虑,熟悉中国国企内部组织架构的规则与游戏规则。
|
||||
|
||||
我们本来承担了很多的工作内容,由于之前的组织架构不够合理,我们可能存在大量打黑工的情况,因此我自己撰写了[1-原始文档.md](1-%E5%8E%9F%E5%A7%8B%E6%96%87%E6%A1%A3.md),经过优化与调整 最终上报给领导审批的方案是[2-优化版本.md](2-%E4%BC%98%E5%8C%96%E7%89%88%E6%9C%AC.md).
|
||||
|
||||
效率提升参照的文件为
|
||||
我建议的组织架构图片为
|
||||
|
||||
经过领导的考虑,领导建议参考去年郭忠勇场景特战队模式先成立交付特战队进行试点,如果效果好再考虑分拆成组。参考场景特战队的组建方案按照他们的想法梳理一版交付特战队的方案吧,考核目标和考核办法可以先提供想法和思路,后续我们会拉着研发产品和市场讨论后再确认
|
||||
[3-统一交付特战队.md](3-%E7%BB%9F%E4%B8%80%E4%BA%A4%E4%BB%98%E7%89%B9%E6%88%98%E9%98%9F.md)
|
||||
|
||||
其他信息
|
||||
1. 部门存在技术支撑中心的交付团队,但是他们的角色偏向于交付经理.我们团队的定义是向上承接飞行服务平台和监管平台的市场化交付需求,需要联合技术支撑中心的交付团队,共同完成市场化交付任务.我们侧重于技术类型的交付,如售中交付部署,售中的定制化开发的持续交付部署,售后的版本更新,故障维护等.需要明确责任边界,但是暂时有点困难.
|
||||
2. 考核内容
|
||||
1. 由于市场化项目很多,我们保证的是技术类交付的按时按质完成
|
||||
1. 不要写交付效能提升,而是从交付部署开始时间,在规定时间内完成
|
||||
2. 区分不同的交付部署环境,不同系统部署
|
||||
3. 飞行服务平台
|
||||
1. 纯内网(4A系统) 7个工作日 服务器可以访问公网 3个工作日
|
||||
4. 监管平台
|
||||
1. 纯内网(4A系统) 7个工作日 服务器可以访问公网 4个工作日
|
||||
5. 飞行服务平台+监管平台
|
||||
1. 纯内网(4A系统) 8个工作日 服务器可以访问公网 5个工作日
|
||||
6. 已有任意系统,新增部署另一系统
|
||||
1. 纯内网(4A系统) 3工作日 服务器可以访问公网 2个工作日
|
||||
2. 支持监管与飞行服务平台新功能标准化部署方案
|
||||
1. 如业务系统修改底层架构,新增中间件,底层的标准化部署方案就需要更新
|
||||
2. 应该按照先研发团队自行部署试用,然后才能稳定标准化方案的流程
|
||||
3. 飞行服务平台与监管平台的标准化部署方案
|
||||
3. 项目持续交付更新,需要及时响应,按时完成
|
||||
4. 重要运行环境稳定性保障维护
|
||||
1. DEMO环境 研发考核类项目(CHBN对标测试)环境
|
||||
2. 建立专门的运行环境保障SOP
|
||||
3. 发挥SRE工程师的职责
|
||||
3. 特战队成立的背景
|
||||
1. 任一珂(组长) 王子文 袁雪波 这几年一直都在干相关的工作
|
||||
2. 交付部署就像是果树的果实,是从基础架构设计,运行环境维护,多年技术积累沉淀(犁地,施肥,播种,收割)出来的,水到渠成
|
||||
3. 多年的经验积累与技术沉淀,深谙底层架构的通电与堵点,基础架构技术的优化与实现方法
|
||||
4. 特战队的人员
|
||||
1. 领导安排的人员是 任一珂 王子文 袁雪波 郑岩 龙卫
|
||||
2. 请基于新的特战队人员安排人员职责划分
|
||||
3. 王子文 袁雪波是核心成员
|
||||
5. RMDC系统
|
||||
1. 不只是项目信息管理,重点功能介绍
|
||||
2. 交付物构建:能够一个界面实现从代码到项目交付物的产出
|
||||
3. 持续交付更新:能够实现全国任意项目的一键跨公网微服务升级更新
|
||||
4. 项目统一监控中心:可以查看全国任意项目的实时运行状态,提高系统稳定性
|
||||
5. 权限控制能力:实现谁提交的、谁审批的、谁更新的的全生命周期记录,可以复盘审计
|
||||
6. 项目信息控制:可以查看全国任意项目的详细部署信息,极大提高定制化开发效率
|
||||
6. 两个研发团队需要配合完成国产化信创环境的改造适配工作
|
||||
7. 视频流媒体部分的标准化部署方案
|
||||
8. AI功能 GPU服务器的标准化部署方案
|
||||
|
||||
|
||||
请你基于上述的信息,帮我撰写一份<统一交付特战队>的组建方案
|
||||
125
12-交付特战队/1-原始文档.md
Normal file
125
12-交付特战队/1-原始文档.md
Normal file
@@ -0,0 +1,125 @@
|
||||
剑哥,秉承能够充分发挥自身能力为部门发展,提供研发团队、部门协同流畅性,提高市场交付支撑效率的出发点。
|
||||
|
||||
在此斗胆提出自己一点小小的看法与建议,叨扰剑哥,还望能够查阅指正!
|
||||
|
||||
## 工作传承
|
||||
|
||||
先从软件开发模式讲起,传统时代(刀耕火种)的软件开发,就是前端、后端、运维一起上,就像是镰刀割麦子、弯腰插麦子,这在小农经济时代是可以的,但是人肉推进模式终究是效率很低下,人员损耗率很高,无法应对现在高达50个以上的市场化项目的拓展、交付、维护。
|
||||
|
||||
自动2013年云计算时代,15年之后云原生时代之后,开发进入现代农业机械化时代,大型联合收割机可以进行高效、自动化的作业,是传统小农种植不可比拟的效率及规模。
|
||||
|
||||
想到实现农业机械化时代,需要应用到大量的云原生的技术和方法。国内外大型互联网团队均有基础架构(设施)研发团队,用以研制大型生产机械,这部分现在的组织架构是很欠缺的。
|
||||
|
||||
从20年入职成研院以来,入职的目标即为基础架构(设施)研发团队,但是项目初期阶段,市场化项目规模不大,研发大型农业机械的成本极高,投入产出比不高,小农经济更有性价比。但是现在到了关键时候,市场项目过多,传统小农模式已经到了崩溃的边缘,要么就是海量人力的投入,要么就需要研制大型农业机械,迈入现代化农业生产阶段!
|
||||
|
||||
## 现有架构存在的问题
|
||||
|
||||
像我23年给你提过的一样,组织架构需要交付部署(由于技术支撑团队不承接此部分工作)团队,职责、权责清晰。
|
||||
|
||||
### 交付部署
|
||||
|
||||
1. 在之前云平台的架构里面,交付部署明明重要,却没有单独的职责分配
|
||||
2. 飞行服务组承担 飞行服务、监管平台的交付部署工作
|
||||
3. 监管平台貌似很害怕我和雪波不给他们部署?我搞不懂这种思想产生的原因
|
||||
1. 实际我们不抗拒监管部署,因为对我们来说都是一样的。不满的是职责、权责不清,我们是打黑工的角色
|
||||
2. 可能是极力想隐藏我和雪波的关键工作角色(虽然工作内容价值不高,但是交付环节很重要)
|
||||
|
||||
### 项目维护
|
||||
|
||||
1. 随着市场化项目的增多,项目的售后维护工作日渐增多
|
||||
2. 主要是安全漏洞修复问题
|
||||
1. 服务器漏洞(基线漏洞):全部是我和雪波去修复,占用大量的时间,成果非常不好
|
||||
2. 代码漏洞(渗透漏洞):需要由开发人员修复,我和雪波去部署更新。
|
||||
3. 定制化开发-持续交付部署
|
||||
1. 由于现在定制化项目太多,持续交付部署持续进行,部署环节割裂耗时很长【后文重点优化】,虽然我已经优化了锄头镰刀,但是小农模式下人力还是要被耗死
|
||||
2. 还有伴发的很多问题,如安全、审计问题
|
||||
|
||||
### 基础环境维护
|
||||
|
||||
研发环境维护
|
||||
|
||||
1. 无职责、权责分配
|
||||
2. 存在280台以上的服务器,没有时间进行日常的维护保养工作,
|
||||
3. 经常性的主机故障导致演示平台崩溃,
|
||||
4. 由于部署时间过早,架构老旧,旧演示平台运行极度卡顿
|
||||
|
||||
演示DEMO环境维护
|
||||
|
||||
1. 无职责、权责分配
|
||||
2. 研发人员没有研发环境使用,研发效率极度底下
|
||||
3. 监管组同事因为我和雪波还在极力维护演示环境,居然直接拿演示DEMO环境开发
|
||||
|
||||
重大事故
|
||||
|
||||
1. 25年春节大年三十,演示DEMO环境崩溃,主机故障无法恢复
|
||||
2. 一群人拉了一堆群,聊了各种问题,显得很热闹
|
||||
3. 实际还是我和波哥 将DEMO环境整体迁移,重新部署才恢复正常
|
||||
|
||||
### 基础架构平台开发
|
||||
|
||||
小农经济不具备此部分的工作,只能抽空进行镰刀、锄头的优化工作。
|
||||
|
||||
### 权责、职责不分、混乱
|
||||
|
||||
1. 出任何事情拉一群人,实际没有干活的
|
||||
2. 监管平台成立交付支撑组
|
||||
1. 存在挂羊头卖狗肉的情况,前端开发全都挂进去
|
||||
2. 监管平台部署,5年的技术沉淀,龙卫根本干不来
|
||||
3. 最终还是袁雪波一个人默默承担了所有
|
||||
4. 即使有独立的小组,仍然无法支撑规模化的市场化项目部署工作
|
||||
3. 还有 既然已经组织切分(分家了),监管平台交付部署的工作,后面我和袁雪波是接还是不接,管还是不管呢?
|
||||
|
||||
## 新的工作内容
|
||||
|
||||
从23年我向您提及至今,深感现在小农经济模式的巨大弊病与限制,研发人力耗损严重,规模化的市场化项目难以支撑与维系。
|
||||
|
||||
在一珂的授意与指挥下,我最近开启了大型联合收割机的研制工作
|
||||
|
||||
### RMDC基础平台
|
||||
|
||||
1. 全称为Runtime Management & Development Operation Center,中文系统名称为 运行环境管理及开发运维中心
|
||||
2. 本系统旨在解决日益繁多的跨公网市场化项目、众多开发环境、演示环境等运行环境的开发、监视、运维问题,提供一站式中心化的管理、控制、操作能力,具备权限控制、流程审批、审计追溯的功能特性。(类似于 一网统飞,此平台实现 中移凌云运行环境的 一网统管)
|
||||
3. 重点功能介绍
|
||||
1. 交付物构建:能够一个界面实现从代码到项目交付物的产出
|
||||
2. 持续交付更新:能够实现全国任意项目的一键跨公网微服务升级更新
|
||||
3. 项目统一监控中心:可以查看全国任意项目的实时运行状态,提高系统稳定性
|
||||
4. 权限控制能力:实现谁提交的、谁审批的、谁更新的,如果出了问题均可以追责
|
||||
5. 项目信息控制:可以查看全国任意项目的详细部署信息,极大提高定制化开发效率
|
||||
4. 效率提升评估
|
||||
1. 交付物构建:一次构建节约人力成本10分钟,平均每天构建150次,每天节约开发人员工时为25小时!
|
||||
2. 持续交付更新:一次更新节约人力成本15分钟,平均每个项目每年更新300次(雄安已经更新超过500次),市场化项目数量为25个计算,每年能够节约人力成本1875小时(8小时工作计算,达到234人天)。考虑到项目的驻点运维人员开支,大概率可以节约1.5个运维人员的年度成本!
|
||||
3. 项目信息控制:一次信息查找节约10分钟,平均每天查找15次以上,每天节约的开发人员工时为 2.5小时!
|
||||
|
||||
### 建议的组织架构
|
||||
|
||||
1. 充分考虑到职责、权责划分,公司也是综合部、 产品中心,研发中心、技术支撑中心
|
||||
2. 提高部门团队研发效率,将研发从小农经济模式转向现代农业机械化时代
|
||||
3. 去除很多组织架构上面的障碍
|
||||
4. 斗胆给出一些部门组织架构的建议
|
||||
1. 将现有监管平台的交付支撑组拆解,形成独立于监管平台和飞行服务平台的组,类似于产品组,整体的架构图就形成为
|
||||
2. 行业组进行市场化拓展 对接产品组
|
||||
3. 产品组负责中移凌云产品打造,对接监管平台 飞行服务平台
|
||||
4. 最后是基础架构组(交付支撑组)用于为研发两个团队提供如下支撑工作
|
||||
1. 交付部署职责
|
||||
2. 项目售后维护职责
|
||||
3. 研发环境维护管理职责
|
||||
4. 演示DEMO环境维护管理职责
|
||||
5. 准生产、生产环境维护管理职责
|
||||
6. 基础架构平台开发职责(大型联合收割机)
|
||||
5. 基础架构组 人员清单
|
||||
1. 组长 任一珂
|
||||
2. 王子文
|
||||
3. 袁雪波
|
||||
4. 郑岩
|
||||
5. 郝昊
|
||||
6. 之前的工作模式就是这样的划分,现在可以明确职责、权责
|
||||
|
||||
平台基础架构 (软件开发中的话术,类似于平台运行的地基)
|
||||
|
||||
平台运行环境维护(DEMO环境 生产环境 研发环境等 280多台服务器 )
|
||||
|
||||
交付部署 (项目第一次落地)
|
||||
|
||||
持续交付更新(定制化开发需要,每次更新很费时间)
|
||||
|
||||
项目售后维护 (50多个项目需要维护,安全问题维护、版本升级、运行环境清理等)
|
||||
BIN
12-交付特战队/1.1-efficiency.png
Normal file
BIN
12-交付特战队/1.1-efficiency.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 5.1 MiB |
BIN
12-交付特战队/1.2-group-arch.png
Normal file
BIN
12-交付特战队/1.2-group-arch.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 899 KiB |
94
12-交付特战队/2-优化版本.md
Normal file
94
12-交付特战队/2-优化版本.md
Normal file
@@ -0,0 +1,94 @@
|
||||
**文档主题:关于优化部门组织架构以提升规模化交付效能的建议汇报**
|
||||
**汇报人:** 王子文
|
||||
**日期:** 2026年1月9日
|
||||
|
||||
---
|
||||
|
||||
### 剑哥:
|
||||
|
||||
您好!
|
||||
|
||||
基于对部门当前业务高速发展的观察,秉承“提升研发团队协同流畅性、提高市场交付支撑效率”的初衷,我结合近期在基础架构平台(RMDC)上的实践,对部门组织架构和工作模式有一些思考。
|
||||
|
||||
现整理如下,供您审阅参考。
|
||||
|
||||
### 一、 背景:从“手工作业”迈向“自动化工厂”
|
||||
|
||||
自2013年云计算普及至2015年云原生时代到来,软件研发与交付模式发生了质的飞跃。
|
||||
|
||||
* **传统模式(小农经济)**:开发、运维、交付高度耦合,依靠人力堆砌(“镰刀割麦”)。在项目初期或单一项目阶段,这种模式具备灵活性,性价比尚可。
|
||||
* **现代化模式(机械化作业)**:依托云原生技术与自动化平台(“联合收割机”),实现标准化、规模化交付。
|
||||
|
||||
**现状判断:**
|
||||
从2020年入职至今,我见证了团队的快速发展。目前我们面临着**50+市场化项目**并发交付、维护的挑战。现有的“人肉推进”模式由于边际成本过高,人员损耗率上升,已难以支撑当前的市场规模。我们需要从“人力密集型”向“技术密集型”转型,补齐基础架构(设施)研发能力的短板。
|
||||
|
||||
### 二、 现有架构面临的痛点与挑战
|
||||
|
||||
**[此处建议插入图片:现有工作流程中的痛点鱼骨图或流程阻塞图,展示开发、交付、维护中的断点]**
|
||||
|
||||
当前组织架构在面对大规模市场化交付时,主要存在职责边界模糊、权责不对等的问题:
|
||||
|
||||
#### 1. 交付部署职责不清
|
||||
|
||||
* **现状**:交付部署环节在流程中缺乏独立明确的责任主体。目前实际上由特定技术人员承担了监管平台、飞行服务平台等全线的交付压力。
|
||||
* **问题**:由于缺乏明确的部门职能定义,交付工作往往被视为“临时性支撑”,导致工作量无法量化,权责边界模糊,难以形成标准化的交付SOP。
|
||||
|
||||
#### 2. 存量项目维护压力巨大
|
||||
|
||||
随着市场化项目增多,售后维护成为巨大的隐形负担:
|
||||
|
||||
* **安全漏洞修复**:基线漏洞目前完全依赖核心开发人员逐一修复,耗时巨大且效果难以复用。
|
||||
* **持续交付瓶颈**:定制化项目频繁变更,导致部署环节割裂。即使优化了工具,在现有模式下依然耗费大量人力。
|
||||
|
||||
#### 3. 基础环境维护缺失
|
||||
|
||||
目前约有 **280台+** 服务器缺乏专职维护:
|
||||
|
||||
* **演示环境不稳定**:无专人对演示DEMO环境进行生命周期管理。以25年春节期间DEMO环境故障为例,虽然最终通过紧急迁移恢复,但暴露了缺乏日常巡检和应急预案的短板。
|
||||
* **研发效率受损**:由于资源管理混乱,甚至出现演示环境被直接用于开发的情况,严重影响了资源的隔离性和稳定性。
|
||||
|
||||
---
|
||||
|
||||
### 三、 解决方案:工具+组织双管齐下
|
||||
|
||||
为了打破上述瓶颈,在相关领导的指导下,我们已启动了基础架构平台的自研工作,并建议配合组织架构调整以发挥最大效能。
|
||||
|
||||
#### 1. 工具层面:RMDC基础平台(已落地)
|
||||
|
||||
**系统全称**:运行环境管理及开发运维中心 (Runtime Management & Development Operation Center)
|
||||
**核心定位**:中移凌云体系的“一网统管”底座。旨在解决跨公网、多项目、多环境的集中化管理难题。
|
||||
|
||||
|
||||
**核心效能提升数据(实测):**
|
||||
|
||||
| 功能模块 | 效能提升点 | 量化数据(预估) |
|
||||
| --- | --- | --- |
|
||||
| **交付物构建** | 自动化流水线,替代人工打包 | 单次节约10分钟。日均150次构建 → **每日节约 25工时** |
|
||||
| **持续交付更新** | 一键跨公网微服务升级 | 单次节约15分钟。按25个项目、年均300次更新计算 → **年节约 1875工时** (约234人天) |
|
||||
| **项目信息控制** | 集中化信息看板,告别碎片化查找 | 单次查找节约10分钟。日均15次以上 → **每日节约 2.5工时** |
|
||||
| **综合收益** | **降低对驻点运维的依赖** | **预计可节约 1.5名 运维人员的年度人力成本** |
|
||||
|
||||
#### 2. 组织架构层面:成立“基础架构组”
|
||||
|
||||
建议参考公司“综合部、产品中心、研发中心、技术支撑中心”的标准化架构,在部门内部明确**公共技术底座**的定位。
|
||||
|
||||
|
||||
**建议调整方案:**
|
||||
将现有的交付支撑职能剥离并重组,成立独立于业务线(监管/飞行)之外的**基础架构组(或交付支撑组)**。
|
||||
|
||||
* **职责定位**:
|
||||
1. **基础设施研发**:负责RMDC平台(“联合收割机”)的持续研发与迭代。
|
||||
2. **标准化交付**:统一承担所有产品线的交付部署标准制定与实施。
|
||||
3. **环境全生命周期管理**:统筹管理研发、演示、准生产及生产环境,确保稳定性(包含280+台服务器维护)。
|
||||
4. **技术兜底与售后**:负责共性安全漏洞修复、基线加固及重大技术故障处理。
|
||||
|
||||
|
||||
* **建议人员构成**:
|
||||
* 组长:任一珂
|
||||
* 核心成员:王子文、袁雪波、郑岩、郝昊
|
||||
|
||||
### 四、 总结
|
||||
|
||||
通过“明确分工”与“工具赋能”,我们希望将研发团队从繁琐的重复劳动中解放出来,让业务组聚焦业务逻辑,让基础组聚焦效能提升。这不仅是对现有痛点的解决,更是应对未来更大规模市场化交付的必要准备。
|
||||
|
||||
以上是我的浅见,不当之处,请剑哥批评指正!
|
||||
53
12-交付特战队/3-统一交付特战队.md
Normal file
53
12-交付特战队/3-统一交付特战队.md
Normal file
@@ -0,0 +1,53 @@
|
||||
统一交付特战队组建方案
|
||||
一、背景
|
||||
现状问题:当前生态能力整合不充分,交流多、转化少;标准产品与场景脱节,亟需借助生态力量补足;细分场景需求逐渐凸显,而军团主要统筹大监管、应急领域,对于细分行业场景支撑力有限。
|
||||
核心目标:以3+1场景(机场安防、自然资源、医疗物流、交通)为切口,打通“需求洞察→生态整合→方案设计→商业闭环”的全链路,输出可复用的场景化模板。
|
||||
二、定位
|
||||
聚焦"连接"与“提效”,主动构建场景生态能力通道,将分散的产品能力、生态资源、市场诉求转化为端到端落地的场景解决方案,并输出标准化作战工具。
|
||||
三、人员
|
||||
为确保提升研发团队协同流畅性、提高市场交付支撑效率,团队聚焦XXXX场景,配置核心成员5名:
|
||||
任一珂(兼队长):负责XXXXX
|
||||
王子文(副队长):负责XXXXX
|
||||
袁雪波:负责XXXXX
|
||||
郑岩:负责XXXXX
|
||||
龙卫:负责XXXXX
|
||||
四、职责
|
||||
(一)负责机场安防、自然资源、医疗物流、交通3+1场景市场化闭环
|
||||
1.解决方案:
|
||||
围绕机场安防、自然资源、医疗物流、交通形成3+1融生态解决方案,同时形成场景营销套件,并分享至军团与行业组,开展区域中心解决方案培训推介,支撑省市公司业务拓展;
|
||||
2.衔接生态:
|
||||
围绕机场安防、自然资源、医疗物流、交通3+1场景,灵活运用现有服务包与引入服务包强化生态协作,联动生态场景能力丰富场景解决方案,发展行业渠道生态建立,场景顶层对接拓宽商机触点,协同行业组开展属地生态对接,提升3+1场景下的属地支撑能力;
|
||||
3.拓展项目:
|
||||
围绕机场安防、自然资源、医疗物流、交通3+1场景,主动推介方案对接项目需求,积极配合军团与行业组,开展有效商机跟进支撑;
|
||||
4.商务模式:
|
||||
围绕机场安防、自然资源、医疗物流、交通3+1场景,基于现有产品化能力包装场景拓展策略,优化商务模式,立足项目实际设计项目落地模式,对于有价值的商务模式,组织军团及行业组开展专题探讨并尝试复制;
|
||||
5.形成样板间
|
||||
围绕机场安防、自然资源、医疗物流、交通3+1场景,形成可演示、可参观、可推介的项目样板,及时分享军团及行业组,支撑项目拓展复制;
|
||||
(二)负责服务包全生命周期管理
|
||||
1.引入
|
||||
协同军团及行业组,收集提炼产品服务包需求,周期性开展服务包引入立项及采购相关工作;
|
||||
2.定价
|
||||
协同产品组,开展已产品服务包院内相关定价工作;
|
||||
3.上架
|
||||
针对完成定价的产品服务包,协助完成集团上架相关流程推动;
|
||||
4.销售
|
||||
根据市场化需求,制定服务包销售策略(融入场景、资费包等),助力产品服务包市场化销售;
|
||||
5.流程穿通
|
||||
针对在售产品服务包相关业务,制定使用流程和验收规范、明确业务交付标准,指导军团、行业组的使用交付过程合规,助力产品市场化交付;
|
||||
五、分工原则
|
||||
(一)与产品与解决方案组紧密协作,完成产品能力可秀可售可落;
|
||||
(二)与监管军团高效协同,完成3大场景方案商业闭环;
|
||||
(三)与南、北区行业组有效衔接,完成场景项目需求支撑落地。
|
||||
六、考核目标(第一季度开始执行)
|
||||
可先提供关键考核点供部门参考:
|
||||
(一)利润指标(30%):500万,根据完成金额线性得分;(第三季度考核值300万)
|
||||
(二)场景样板(30%):6个,根据完成数量线性得分;(第三季度考核值4个)
|
||||
(三)解决方案(15%):形成4大场景营销套件并持续共享更新,根据完成情况评分;
|
||||
(四)服务包管理(20%):打通服务包流程,形成销售&交付标准,根据完成情况评分;
|
||||
(五)其他工作(5%):完成领导交办工作,根据完成情况评分;
|
||||
七、考核办法
|
||||
可先提供关键考核思路部门参考:
|
||||
(一)场景应用打造解决方案特战队与支撑条线(云平台系统组-监视控制组、应急军团组、监管军团组)拉通考核。
|
||||
(二)根据考核目标完成情况,部门与产品组共同考核,分别占60%和40%。
|
||||
(三)专项攻坚特战队成员绩效名额进行单列,不回归所在班组名额比例管理。
|
||||
|
||||
BIN
12-交付特战队/关于优化部门组织架构以提升规模化交付效能的建议汇报.docx
Normal file
BIN
12-交付特战队/关于优化部门组织架构以提升规模化交付效能的建议汇报.docx
Normal file
Binary file not shown.
Reference in New Issue
Block a user