团队管理与培养机制

对外 docs/校方文档包/04-团队管理与培养机制.md

团队管理与培养机制

用途:向学院说明"团队怎么管、学生怎么成长、质量怎么保证" 版本:v1.0 草案


一、管理原则

  1. 成果导向:按任务验收管理,不按考勤管理;
  2. 透明规则:任务、验收标准、计酬规则全部公开,白纸黑字;
  3. 学业优先:任何管理要求都不与学生的学业冲突;
  4. 双方知情:团队进展与涉及学生的重要事项,定期向学院通报。

二、组织架构

      我司项目对接人(对接贵院联络教师)
                │
      驻实验室指导工程师(现场驻场 + 远程)
                │
   ┌────────────┼────────────┐
   │            │            │
  后端方向      前端方向      测试/文档方向
(学生若干)    (学生若干)    (学生若干)
  • 驻场指导工程师:我司全职派驻的技术负责人,负责任务派发、技术指导、代码评审、质量验收、日常沟通;
  • 学生组长(技术协助):由团队中能力与责任心突出的学生担任,负责技术答疑与新人陪同,不参与任何报酬评定(避免同学间的利益冲突);
  • 联络教师:贵院指定,对接团队状态与学业协调。

三、任务怎么派(任务卡制)

每一份任务以任务卡形式下发,包含:

字段 说明
任务标题 一句话说明做什么
背景与目标 为什么做、做完什么效果
验收标准 写完才能派——写不出验收标准的任务不派发
任务量 预估工作量(人天),派发时确认
截止时间 与学业安排协调后确定
交付物 代码 + 测试 + 文档 + 自测记录

规则:

  • 任务派发前工程师 与成员确认工作量,锁定后不随意追加;
  • 需求变更重新派卡,责任清晰;
  • 口头任务一律不算——无卡不干活、不结算。

四、质量怎么保证

  1. 验收标准前置:每张任务卡写清"做完什么样算合格";
  2. 代码评审(Code Review):所有代码经 工程师评审通过后才算完成;成员之间也互相评审,培养工程习惯;
  3. 双周演示验收:每两周一次成果演示,我司负责人参加,欢迎学院老师观摩;
  4. 完成的定义(DoD):代码合入 + 有测试/验证 + 有文档 + 有自测记录,缺一不算完成;
  5. 返工规则:因需求不清导致的返工不计入成员负担;因质量不达标导致的返工不额外计酬——激励一次做对。

五、学生怎么成长(三级路径 + 培养期)

5.1 入组培养期(约 4 周)

周 内容 产出
第 1 周 环境搭建、工程规范、代码库导览 第一个小改动合入
第 2 周 与工程师/老成员结对完成第一个真实小任务 首个任务验收
第 3 周 独立承接小任务(1-2 人天) 独立交付
第 4 周 独立承接标准任务 正式进入交付节奏

5.2 三级成长路径

等级 能力定位 任务类型 说明
见习 L1 在指导下完成明确任务 修 bug、补测试、页面还原、文档 入组默认等级
独立 L2 独立完成标准任务,能主动澄清需求 完整接口、完整页面、测试模块 连续达标后升级
骨干 L3 能承接模块级任务、能带新人 模块设计、技术攻关、带教 需通过我司评审

等级与任务难度、报酬水平挂钩;升级降级均以书面评估为依据,学生可申诉。

5.3 培养活动(每周固定)

  • 每周技术分享:学生轮流主讲 30 分钟(讲技术点或本周踩的坑);
  • 代码评审:所有人的代码都被评审、也评审别人的代码;
  • 一对一成长沟通:工程师每月与每位学生谈一次,形成成长记录。

六、评估与调整(透明规则)

情形 处理
任务按期交付 正常计酬,累积升级评估
交付质量不达标 退回修改,说明问题,不额外计酬
连续不达标 书面告知 → 给予改进期(约 2 周)→ 仍不达标则结束协作
主动退出 提前 2 周告知,交接完成,已交付照常结算
涉及学业风险 先与联络教师沟通,学业优先

承诺:所有评估以书面记录为依据,不做突然淘汰;不因评估向学院作负面评价式通报。


七、对学院的开放与透明

  1. 双周演示欢迎学院老师参加;
  2. 月度简报(进展、学生状态概览,不含个人负面评价)提供给联络教师;
  3. 涉及学生的重大事项(安全事故、协议变更、规模调整)第一时间通报学院;
  4. 学院可随时了解任何一位学生的参与情况。

八、一句话总结

用真实项目 + 明确标准 + 全程指导,让学生在"被要求的交付"中真正成长;用透明规则 + 学业优先,让学院放心。