工作多年，相信大部分技术人与我一样都已经走上了技术管理的岗位或者是已经在路上了；众所周知的是，管理岗之所以重要，因为领导者的短板，会变成整个团队的灾难。一个有前途的企业或是组织，如何选择一位优秀的领头人或是培养一个优秀的领头人是所有高层管理者或者BOSS最需要直面的问题。自然而然，对于基层管理岗的能力认定以及培养难度都会相对比较高。任人唯亲的最大代价，是消耗掉真正做事人的积极性，使得团队能力持续退化，出现没有大公司的命，得了大公司的病。最终创业失败或是项目投资失败。本文对技术团队的基层管理办法做出一些浅显的研究，也是想能够做好一个团队，做好一个产品，实现一个被信任的人该履行的价值。本文分享仅仅作为理想标准参考，需要各位根据实际情况灵活处理，不足之处，敬请不吝赐教。感谢阅读！
一、组织架构与权责
一条线一个头，出问题直接找人，不甩锅。
| 角色 | 管什么 | 对什么负责 |
|---|---|---|
| 技术负责人 | 技术方案、人员安排、代码质量、交付进度 | 交付率、故障率、产能 |
| 后端 / 前端开发 | 写代码、改 bug、做需求 | 个人交付点数、bug 率 |
| 测试 / 运维 | 测 bug、部署运维 | 漏测率、系统稳定性 |
规矩：技术线只有技术负责人一个出口，产品 / 老板找技术就找他，不直接找开发。开发有问题先找技术负责人，但保留越级通道。
二、需求点评估流程
不用人天，用需求点？ 这个其实有待商榷采用什么样的方式更好，人天的话可能产品人员不好评估这个人天，本文暂时先以点数为任务时长及难易度分级，需求只需要按照需求点评估其复杂度即可。
1、点数分级
| 点数 | 复杂度 | 大概啥样 |
|---|---|---|
| 1 点 | 很简单 | 改文案、调样式、加字段，半天搞定 |
| 2 点 | 一般 | 小功能、小接口，1~2 天 |
| 3 点 | 中等 | 完整功能模块，前后端都有，3~5 天 |
| 5 点 | 复杂 | 新模块、有技术难点、依赖第三方，1 周以上 |
不用精确数字。估不准很正常，相对大小差不多就行。
2、评估流程（防止一言堂）
第1步：产品讲需求
→ 迭代规划会上讲清楚：做什么、为什么、验收标准
→ 技术负责人、所有开发、测试、产品都参加
第2步：开发各自估点
→ 每个需求，开发们自己先估，不说出来
→ 不是技术负责人一个人估，所有人都参与
第3步：差异讨论
→ 点数差得多的，拿出来聊
→ 估高的说说难在哪，估低的说说为什么简单
→ 技术负责人可以带节奏，但不能直接拍板
第4步：技术负责人定，但要给理由
→ 最后还是他定点数
→ 但和大家平均估点差很多的，必须说理由
→ 说不出合理理由，产品和老板可以质疑
第5步：记录在案
→ 每个需求多少点、谁估的、定了多少，全记下来
→ 后面复盘用3、防估高三招
| 招数 | 怎么操作 |
|---|---|
| 历史基线 | 跑 3 个迭代就有数据了，同样的人一个迭代平均做多少点。下次承诺的比基线低 20% 以上，必须解释。 |
| 交付率挂钩 | 估高了承诺多，完不成交付率低；估低了承诺少，产能低。估高估低都有代价，最优解就是估准。 |
| 产品对比权 | 产品不懂技术，但懂历史。"上次差不多的需求才 2 点，这次为啥 5 点？" |
三、开发任务拆分
拆得越细越好评估、好追踪，但别拆到小时，累死人。拆到 "天" 级别就行。
拆分原则
- 一个任务不超过 5 天/点，超过的必须拆
- 每个任务有明确验收标准，做完能验证
- 每个任务有明确负责人，不搞 "大家一起做"
- 前后端分开拆，别混在一起
拆分示例
错："做用户管理模块" ------ 太大
对：
- 用户列表页面（前端，3 点）
- 用户列表接口（后端，2 点）
- 新增用户功能（前端 2 点 + 后端 2 点）
- 编辑用户功能（前端 2 点 + 后端 2 点）
- 删除用户功能（前端 1 点 + 后端 1 点）
- 用户权限控制（后端，3 点）
任务状态
就四个状态，看板上拖就行：
- 待开始 → 进行中 → 待测试 → 已完成
工具随便选：飞书项目、Trello、禅道，能用就行。
四、工时与进度管理
看结果，不看过程。
进度怎么追踪？
- 看板追踪：每个人自己更新任务状态，老板想看自己看板上看，不用问人
- 一周一次周会：同步进度、对齐目标、解决问题（详见后面例会制度）
- 阻塞当天说：遇到卡壳的，群里说一声或者直接找技术负责人，别等周会再说
- 紧急事随时叫人，不用等开会
加班怎么算？
- 偶尔加班正常，常态化就有问题，至于加班工资的问题，自己考虑，笔者这里不建议任何公司采用义务加班的方式，即使是员工自己估算不准或能力不足导致需要加班补进度，也不建议！当你想要一个优秀的员工的时候，你首先应该将其当做一个与你无差的人！
- 迭代内承诺的任务，正常时间完不成的，自己想办法（说明评估有问题，下次调整）
- 临时紧急需求（线上 bug、老板临时加的），算额外点数，不计入迭代承诺
- 长期靠加班才能完成 → 要么人不够，要么评估有问题，要么效率低，必须复盘
五、考核细则
全是数字，不看态度，不看关系，不看会不会来事。采用分数制或者其他可以量化的标准。
1、技术负责人考核（满分 100 分）
| 指标 | 权重 | 计算方式 | 打分规则 |
|---|---|---|---|
| 迭代交付率 | 35% | 实际完成点数 ÷ 承诺点数 × 100% | ≥90% 满分，每低 5% 扣 10 分 |
| 线上故障率 | 25% | 迭代内 P0/P1 bug 数量 | 0 个满分，P0 每个扣 20 分，P1 每个扣 10 分 |
| 需求交付产能 | 20% | 迭代人均交付点数 | 达历史基线满分，超了加分，低了扣分 |
| 产品满意度 | 10% | 产品负责人结构化问卷打分 | 按得分折算 |
| 团队稳定性 | 10% | 团队成员流失率 | 0 流失满分，因管理不善走 1 个扣 20 分 |
| 下属及客户投诉 | 额外权重 | 投诉经查实故意打压，针对 | 扣20分，酌情处置！ |
2、普通开发考核（满分 100 分）
| 指标 | 权重 | 计算方式 | 打分规则 |
|---|---|---|---|
| 个人交付点数 | 40% | 迭代完成并验收通过的点数 | 达基线满分，超了加分，低了扣分 |
| bug 率 | 30% | 个人负责模块的 bug 数量 | 按严重程度扣分 |
| 代码评审通过率 | 15% | 一次通过的比例 | ≥90% 满分 |
| 协作评价 | 15% | 产品 / 测试 / 同事结构化打分 | 按得分折算 |
3、软技能考核细则（占总分 15%）
| 指标 | 权重 | 计算方式 | 打分规则 |
|---|---|---|---|
| 会议表达能力 | 3% | 360 度环评得分（同事 40%+ 协作方 30%+ 领导 30%），去掉最高最低分取加权平均 | 5 档行为锚定打分：5 分 = 逻辑清晰几句话说清重点；4 分 = 能说清偶尔啰嗦；3 分 = 能表达但需追问；2 分 = 半天说不清楚浪费时间；1 分 = 基本不发言或说不到点上 |
| 逻辑总结能力 | 3% | 360 度环评得分（同事 40%+ 协作方 30%+ 领导 30%），去掉最高最低分取加权平均 | 5 档行为锚定打分：5 分 = 快速总结结论 / 行动项 / 责任人；4 分 = 能总结清楚偶尔漏点；3 分 = 大概总结需别人补充；2 分 = 经常漏关键点；1 分 = 基本不会总结 |
| 协调沟通能力 | 3% | 360 度环评得分（同事 40%+ 协作方 30%+ 领导 30%），去掉最高最低分取加权平均 | 5 档行为锚定打分：5 分 = 跨角色沟通顺畅能推进事；4 分 = 大部分能自己解决偶尔卡住；3 分 = 能沟通但效率一般；2 分 = 经常卡壳需领导出面；1 分 = 沟通费劲容易吵架 |
| 责任心 | 3% | 360 度环评得分（同事 40%+ 协作方 30%+ 领导 30%），去掉最高最低分取加权平均 | 5 档行为锚定打分：5 分 = 先解决问题再追责，主动背锅还能兜底；4 分 = 自己的事负责到底不甩锅；3 分 = 基本负责但先撇清自己；2 分 = 经常甩锅先找别人原因；1 分 = 能推就推事不关己 |
| 创新能力 | 3% | 360 度环评得分（同事 40%+ 协作方 30%+ 领导 30%），去掉最高最低分取加权平均 | 5 档行为锚定打分：5 分 = 经常提改进方案且落地有效；4 分 = 偶尔提好建议有被采纳；3 分 = 有想法但很少说或不太靠谱；2 分 = 基本不提建议按部就班；1 分 = 拒绝改变不想试新东西 |
4、绩效工资挂钩
| 考核得分 | 绩效工资比例 |
|---|---|
| 90 分以上 | 120%（超额奖励） |
| 80~90 分 | 100%（全额） |
| 70~80 分 | 80% |
| 60~70 分 | 50% |
| 60 分以下 | 0% |
5、结果应用
- 月度：算绩效工资，当月兑现
- 季度：排名，前 20% 加薪候选，后 10% 谈话改进
- 年度：连续 4 个季度前 20% → 大幅加薪 / 晋升；连续 2 个季度垫底 → 淘汰
薪酬结构：固定工资 60% + 绩效工资 30% + 奖金 10%。固定保底，绩效浮动，奖金看公司整体。
六、防止一言堂：五道防线
技术负责人有权力，但有笼子关着。
第一道：评估权 ------ 集体估点
需求点是大家一起估的，技术负责人只能最终定，不能凭空定。定得离谱，产品和老板可以质疑。
第二道：决策权 ------ 重大决策必须评审
| 决策级别 | 怎么定 |
|---|---|
| 小决策（单个功能实现） | 开发自己定，技术负责人审核 |
| 中决策（跨模块、工具选型） | 技术负责人提方案，团队讨论，负责人拍板 |
| 大决策（架构变更、技术栈更换） | 正式评审，全员参加，反对意见记录在案 |
大决策，他可以坚持自己的方案，但所有反对意见必须记下来。后面出问题，这就是追责依据。敢担责就可以拍，不敢担就别拍。
第三道：人事权 ------ 招人开除老板说了算
- 招人：技术负责人一面（技术面），老板必须二面，都同意才能进
- 开除：技术负责人可以提议，但必须拿数据证据，老板核实后决定
- 调薪晋升：看考核数据，不是一句话的事
第四道：信息权 ------ 数据全公开
- 每个人的交付点数、bug 数、考核得分，全团队公开
- 迭代数据、bug 数据、评审记录，所有人都能看
- 代码评审全员可见，技术负责人的代码也必须有人评审
阳光是最好的防腐剂。公开了，想搞小动作也难。
第五道：反馈权 ------ 员工有地方说话
- 匿名反馈渠道：有问题可以匿名提，老板直接看
- 越级沟通权：明确规定可以直接找老板，技术负责人不能打击报复
不是鼓励什么都越级，那会乱套。但这个通道必须存在，而且大家都知道存在。
七、防止内斗与小团体：保护能人，打散圈子
有人的地方就有江湖，完全消灭内斗不可能。但可以做到：斗不起来、搞小圈子占不到便宜、能干的人不会被挤走。
1、防止拉帮结派：五招
| 招数 | 具体操作 |
|---|---|
| 人事权拆开 | 招人老板二面，开除要数据证据，调薪看数据。他说了不算，圈子就拉不起来。 |
| 轮岗制 | 每半年到一年交叉轮岗，换模块做。不让一个人长期占一块地搞 "自留地"。关键系统至少两个人懂。 |
| 代码评审公开 | 所有代码走 MR，全员可见评审记录。自己人的烂代码直接过、别人的代码故意卡，这种事公开了就不敢太过分。 |
| 中层领导 1on1 | 与一线员工保留沟通渠道。技术负责人搞小动作，下面的人不敢跟他说，但敢跟老板说（只要老板值得信任）。 |
| 团队满意度调查 | 每季度匿名打分，占技术负责人考核 10%~15%。搞小圈子、偏袒人，满意度就低，他自己绩效工资就少。 |
2、保护能力强但有性格的人：三条铁律
能力强的人大多有性格：直、傲、不好管、说话冲、不拍马屁。这种人最容易被排挤，但往往是真正干活的。把他们逼走了，剩下的都是会来事的，团队就废了。
铁律一：只看结果，不看态度
- 交付数据占 85% 以上，"协作评价"" 态度 " 这类主观指标最多 15%
- 交付点数多、bug 少、质量高 → 就是好员工
- 说话冲、不爱社交、不拍马屁 → 没关系
明确告诉所有人：我们这里不看你会不会来事，看你活干得好不好。
铁律二：禁止以 "沟通不好"" 态度有问题 " 打压人
- 想罚人、想开人，必须拿数据说话：交付低？bug 多？哪条指标不行？
- 拿不出数据，光说 "态度不好"" 不好管 "，不算数
- 老板要明确表态：能力强、有性格的人，我保。 只要活干得漂亮，性格上的小毛病，能容。
铁律三：能人有直通车
- 能力强的员工，有想法、有意见，可以直接找老板聊
- 不需要经过技术负责人同意
- 技术负责人不能因为员工越级而打击报复，发现了严肃处理
给能人一个 "上面有人" 的感觉，技术负责人就不敢轻易动他。
3、防止内斗：三个机制
| 机制 | 怎么操作 |
|---|---|
| 权责清晰 | 每个人负责什么、什么事归谁管，写清楚。出了问题找得到责任人，不用抢功推责。边界模糊的地方，技术负责人及时划清。 |
| 冲突摆上台面 | 有矛盾当面说，不许背后嘀咕、拉帮结派。技术负责人解决不了的找老板评理。背后搞小动作的，发现一次严肃处理。 |
| 利益一致 | 团队整体交付率、整体质量，和每个人的奖金都有关系。团队好大家都多拿，团队差谁都别想好过。不是零和博弈，是一荣俱荣。 |
4、老板的角色：守夜人
- 公正：不偏不倚，只看数据和结果，不看谁跟你关系好
- 保护能人：能干的人被排挤了，你要站出来说话
- 及时干预：发现小团体苗头，早点掐灭，别等养大
- 以身作则：你自己不拉帮结派、不搞小圈子，下面才不敢搞
上梁正，下梁就歪不到哪去。老板自己公正、透明、只看结果，下面的人就知道搞关系没用，好好干活才是正道。
八、营收与成本核算
产品赚不赚钱、技术值不值，得算清楚，不能一笔糊涂账。
1、技术成本怎么算到产品上？
用迭代成本法，简单粗暴，不用算到每个功能：
一个迭代的技术成本 = 技术团队月工资总成本 ÷ 月迭代数（一般2个）举例：
技术团队 8 人，月工资总成本 8 万。一个月 2 个迭代。
一个迭代技术成本 = 8 万 ÷ 2 = 4 万
这个迭代全做 A 产品的需求 → A 产品技术成本 4 万。
多个产品共用迭代的，按需求点比例分摊：
迭代总点数 100 点，A 产品 60 点，B 产品 40 点
A 产品分摊 60% = 2.4 万，B 产品分摊 40% = 1.6 万
2、产品利润怎么算？
产品月度利润 = 产品单次营收 - 技术成本 - 服务器成本 - 获客成本 - 其他成本- 技术成本：迭代成本分摊
- 服务器成本：云服务、数据库、CDN，按实际用量分摊
- 获客成本：广告费、内容费、销售提成
- 其他成本：办公、工具、人事分摊
产品负责人的奖金和这个利润挂钩。利润多奖金多，利润少奖金少，亏损就没奖金。
3、技术团队的 "内部收入"
技术团队是内部服务方，"内部收入" 就是各产品分摊过来的技术成本。
- 技术团队内部收入 = 各产品分摊的迭代成本之和
- 技术团队 "利润" = 内部收入 - 团队实际工资成本
- 这个 "利润" 可以作为技术团队奖金池的一部分
说白了：技术团队效率高，同样的人能做更多迭代，内部收入就多，奖金池就大。倒逼提高效率，而不是磨洋工。
补充：个人产出价值与 ROI 核算
1、个人成本
| 成本类型 | 包含 | 算法 |
|---|---|---|
| 直接成本 | 工资 + 社保 + 公积金 + 年终奖 | 年度总支出 ÷ 12 |
| 间接成本 | 办公 + 工具 + 管理分摊 | 公司总间接成本 ÷ 总人数 |
个人月成本 = 月直接成本 + 人均月间接成本2、个人产出价值
单点价值 = 迭代技术总成本 ÷ 迭代总交付点数
个人产出价值 = 个人交付点数 × 单点价值 × 质量系数| 质量系数 | 条件 |
|---|---|
| 1.0 | 0 个 bug |
| 0.9 | 1~2 个 P2 bug |
| 0.7 | 3~5 个 P2 或 1 个 P1 bug |
| ≤0.5 | 1 个 P0 或 多个 P1 bug |
3、个人 ROI
个人ROI = 个人月产出价值 ÷ 个人月成本 × 100%| ROI | 结论 | 处理 |
|---|---|---|
| >150% | 超值 | 加薪、晋升、重点培养 |
| 100%~150% | 合格 | 正常发展 |
| 70%~100% | 基本合格 | 观察、辅导 |
| <70% | 赔钱 | 谈话改进、不行淘汰 |
4、用途与边界
用来干嘛：调薪参考、淘汰参考、资源调配参考
别用来干嘛：不直接挂当月工资、不精确算营收、不公开攀比
核心：大概齐就行，看趋势和相对值，别算到几块几毛。心里有杆秤，谁值谁不值，数据说话。
九、迭代流程与例会制度
两周一个迭代，节奏固定。会议最少化：一周一次周会，其他不开。
1、任务依赖关系先标清楚
每个任务在看板上标依赖：
| 依赖类型 | 啥意思 | 例子 |
|---|---|---|
| 无依赖 | 拿到就能做，不用等别人 | 纯前端页面、独立小工具 |
| 后端前置 | 前端要等后端接口出来 | 用户列表页面 → 等用户列表接口 |
| 前端前置 | 后端要等前端定了字段 | 很少见，一般反过来 |
| 互相依赖 | 前后端要一起联调 | 支付流程、复杂交互 |
工具上怎么实现？看板里每个任务加个 "依赖" 标签，或者直接在任务描述里写 "依赖 XXX 任务"。不用搞复杂的甘特图，20 人以下的团队，看板标清楚就够了。
2、迭代内的滚动节奏（两周迭代实际长这样）
第1~2天：后端先动，前端先搭架子
→ 后端：先做核心接口、数据结构
→ 前端：先搭页面框架、写静态页面、mock数据，现在ai随便生成mock数据，别跟我扯浪费前端工时！
→ 测试：写测试用例、准备测试数据
→ 不用等所有人都准备好了才开始，谁的活先能做谁先上
第3~6天：前后端并行，逐步对接
→ 后端出一个接口，前端就接一个
→ 不用等全部接口做完才联调，出一个接一个，滚动推进
→ 测试：先测已经做完的模块，做完一个测一个
→ 技术负责人每天扫一眼看板，看有没有卡壳的、有依赖没解开的
第7~8天：主体功能联调完
→ 大部分功能前后端联调通了
→ 测试测出的bug，开发边改边回归
→ 剩下一些边角功能、复杂逻辑继续做
第9~10天：集中测试 + bug修复 ，没测试的话可以交给开发测。但是要有测试步骤！！！
→ 主要功能都做完了，测试集中测
→ 开发集中改bug
→ 回归测试跟上
第11天：回归 + 收尾
→ bug改完了，回归测一遍
→ 还有小问题继续修
→ 文档、部署脚本这些收尾的活
第12天：演示验收
→ 产品验收，通过了就算交付
→ 没通过的，要么改，要么挪到下一期
第13天：周会 + 复盘 + 下一期规划
第14天：缓冲 + 遗留bug处理3、前后端并行的关键：接口约定先行
很多团队前端干等后端接口，浪费时间。其实不用等，接口约定先定下来，前端就能先干。
具体做法：
- 迭代第一天，前后端一起定接口约定
- 接口地址、请求参数、返回字段、错误码
- 写个简单的接口文档（不用太正式，能看懂就行）
- 双方确认，签字（或者群里确认）
- 前端用 mock 数据先开发
- 接口约定定了，前端就可以 mock 数据，先把页面和逻辑写了
- 等后端接口出来了，直接替换成真实接口，联调一下就行
- 后端按约定出接口
- 后端按约定写接口，写完一个通知前端
- 前端接一个，有问题及时反馈
这样前后端基本能并行，前端不用干等，效率至少提 30%。
4、测试滚动介入，不是最后才测，没测试的话可以交给开发测。但是要有测试步骤！！！
别等全部开发完了才给测试测，那最后两天 bug 扎堆，改都改不完。
- 做完一个测一个：开发说 "这个模块做完了"，测试就先测这个
- 早测早发现：早测出 bug，早改，不堆到最后
- 测试提前准备用例：开发写代码的时候，测试就写测试用例，等功能出来直接测
5、谁来协调排期？
技术负责人排，周会上对齐。
- 迭代规划会上，技术负责人把任务依赖、大概顺序排一下，大家看一眼有没有问题
- 迭代过程中，技术负责人每天扫一眼看板，发现卡壳的、依赖堵了的，及时协调
- 周会上，大家对齐一下进度，调整一下后面的排期
不用搞太复杂的排期工具，看板 + 依赖标记 + 周会对齐，足够了。
20 人以下的团队，搞甘特图、搞精细排期，反而浪费时间，灵活调整更重要。
6、协调不好会怎么样？怎么防？
常见的坑和对策：
| 坑 | 怎么防 |
|---|---|
| 前端干等后端接口 | 接口约定先行，前端 mock 数据先做 |
| 测试最后扎堆测 bug | 滚动测试，做完一个测一个 |
| 某个任务卡了，后面全堵了 | 技术负责人每天看板扫一眼，发现阻塞及时协调 |
| 有人闲死有人忙死 | 技术负责人动态调配，闲的人帮忙做别的 |
| 依赖关系没理清，做到一半才发现要等别人 | 迭代规划会上就把依赖标清楚，别等做的时候才发现 |
说白了：技术负责人的核心价值之一，就是把人和事排顺了，让大家尽量不闲着、不堵着。
排期排得好，同样的人能干更多活；排得不好，一半时间在等别人。
周会怎么开（每周一次，1 小时）
别扯别的：
| 环节 | 时间 | 内容 |
|---|---|---|
| 数据同步 | 10 分钟 | 上周交付多少点、多少 bug、什么进度 |
| 本周计划 | 20 分钟 | 这周做什么、谁负责、优先级 |
| 问题与风险 | 20 分钟 | 有什么阻塞、需要什么支持、怎么解决 |
| 其他事项 | 10 分钟 | 通知、调整、自由发言 |
规矩：
- 准时开始准时结束，不等人
- 只说工作相关的，别扯闲篇
- 能私聊解决的别拿到会上说
- 每个问题必须有结论、有负责人、有时间点
进度靠工具看，不靠开会盯。真有人摸鱼？交付数据会说话，周会上数据一摆，谁干多干少一目了然，比天天开会盯着有用多了。
十、落地步骤：分三步走
别一步到位，容易翻车。
第一步：先量化，不挂钩（第 1 个月）
- 先把需求点、交付率、bug 数这些数据统计起来
- 只统计，不扣钱不奖钱
- 让大家先适应，也校准基线
- 指标不合理的地方调整
第二步：半挂钩，试运行（第 2~3 个月）
工资的事情，这个要酌情考虑，很容易搞到大动脉，让有能力的走了，留下臭鱼烂虾混日子吸血！
- 绩效工资开始挂钩，但只挂 50%
- 比如绩效工资 3000，先按 1500 浮动，剩下 1500 固定
- 让大家感受到压力，但不至于太痛
- 继续调整指标，跑顺流程
第三步：全面正式执行（第 4 个月起）
- 绩效工资 100% 挂钩
- 排名公开
- 淘汰机制启动
- 该奖的奖，该罚的罚，该走的走
十一、最后说几句实在的
- 制度是死的，人是活的。跑起来发现不对就改，别死守规则。
- 老板自己要守规矩。不能因为关系好就改分数，想加塞就加塞。制度定了，老板自己先遵守，不然全白搭。
- 不要把鸡蛋放在一个笼子里，不要过分信任某一个具体的人除非是亲儿子，但是要小心亲儿子把自己送进去篡位夺权。嘻嘻，要是碰到个李世民儿子还行，有能力，碰到个蠢的，家底都败光了！！！
- 淘汰要快。不行的人给一次机会，不行就走。小团队养不起混子，一个混子能气走十个能干的！！！！
- 别搞太复杂。小团队，制度越简单越好。能跑起来的简单制度，比完美的复杂制度有用 100 倍。
一句话总结：用数字说话，用结果拿钱，用制度管人，用淘汰兜底。 干得好的多拿，干得差的少拿，混日子的走人。就这么简单。