一句话经验
说实话,这个管理风格并不明显, 不算敏捷, 甚至有些繁琐, 但是却是风险最低的. 在多方(UI,UE,RD,PM,QA,业务) 合作的过程中这样协作方式还是能保障大家则责权清楚(到底是谁的锅),还是很有必要的.
说明
下面的表格,会对角色, 动作, 互相的依赖 做一个梳理
- UI: User Interface 美工
- UE: User Experience 交互
- RD: Research Development 研发
- PM: Production Manager 产品
- QA: Quality Assurance 测试
- BD: Business Development 业务
表1 时序动作图
| 阶段 | 角色 | 动作 | 指标 |
|---|---|---|---|
| 酝酿期 | PM | 根据需求理解PRD草稿 | |
| 业务 | 业务需求 | 有些需求没有业务参与, 直接来自产品或CEO | |
| 评估期 | PM | 输出PRD文档, 根据评估意见调整修改PRD | |
| RD | 评估PRD, 技术实现评估 技术预演 | ||
| UE | 根据PRD给出UE交互图, 参考原有UE规范 | ||
| UI | 在RD评估完之后, 制作 | ||
| 启动期 | PM | 产品的使用预期, 如果通过埋点证明预期 | DAU,人力节省等 |
| RD1 | 给出人日估算(根据项目复杂度和探索性预留10%-20%的弹性时间) | 一定要考虑UI和UE才能给出人日评估. 探索性: 新项目, 新的知识点, 新技术方案 | |
| RD2 | 和研发各方确认后给出排期, 排期包括 开发,联调,提测,上线时间点 | 复杂度: 协作要求高的地方. 实现难度高的地方 | |
| 业务 | 启动会 | 阐述开发目的, 给大家画饼 | |
| 开发期 | RD后端 | 和前端一起约定接口文档和数据类型 | |
| RD前端 | 搭建项目, mock数据, 组件化开发 | 原则: 先难后易, 先主干后细节 | |
| PM | 对有争议实现细节给出可执行方案 | 明确产品的开发目的 | |
| RD | 负责的系统需要有设计文档, 复杂的项目需要有结构文档 | ||
| 联调 | RD | 部署dev环境 | 前后端,或依赖端之间联调 |
| QA | 提出测试用例并组织大家评估 | 测试用例基于PRD, 是可以修改的. 如果有争议,RD可以找产品最终决定, 要带上QA一起讨论 | |
| RD | 根据测试用例,自测通过 | 并且冒烟通过 | |
| 提测 | RD | 主R发提测邮件 | 注明测试地址和测试方法 |
| QA | 部署test/beta环境, 并测试 | 有时候环境部署是RD来完成的,或者协助的 | |
| PM | 产品验收 | 对比产品方案 | |
| UI | UI验收 | 对比实现效果 | |
| QA | 二次验收 | 对修复的bug进行验收, flow操作 | |
| RD | 根据QA提出的bug进行修改, 如果是产品方案的瑕疵可以将bug转给产品 | 如果有争议如要产品介入, 最好每天碰一下 | |
| RD | 合并分支, review代码 | ||
| 上线 | RD | 发布stage环境测试 | |
| QA | 二次回归 | ||
| RD | 发布production环境 | ||
| PM&QA | 线上回归 | ||
| 灰度上线 | hotfix | ||
| 正式上线 | 全量 | ||
| 总结期 | PM | 效果评估 | 如果效果不好, RD下次再排期的时候可以找PM多理论一下 |
| RD | 总结评估和开发过程中的碰到的问题和坑, 下一期塞进去些技术需求 | 整理wiki和分享 | |
| RD | 主R组织大家讨论管理和协作方面的问题 | 整理wiki和分享 |
表1.1 排期表
表2 依赖关系路径
估时 & 排期
PRD清晰且明确 -> UI按照PRD来 -> UE过程明确 -> RD预演了技术 -> 没有并行项目干扰 -> 给出估时 -> 各方确认时间点 -> 确认排期
提测
前端开发完毕 -> 前端之间联调完毕 -> 后端开发完毕 -> 后端之间API和服务化开发完毕 -> 前/后端联调完毕 -> 测试环境部署完毕 -> 确认了测试用例 -> 自测完成 -> 冒烟完成 -> 提测
表3 异常处理
| 异常 | 处理 | 归类 |
|---|---|---|
| prd改动 | 周知RD和QA, RD默默的掏出一把菜刀来 | 开发过程中 |
| 时间不够用 | 申请延期或者找空余的人力来补充 | 开发过程中 |
| 妈的方案想简单了 | 换个方案,可能不完美但是work | 开发过程中 |
| 环境有问题,有依赖别的开发组 | 封闭开发或者加班搞 | 提测过程 |
| 某个点实现和PRD有严重出入 | PRD可能模棱两可, 其实最后就看谁强势,谁更好被说服 | 提测过程 |
思考所谓管理
###管理的Loop
总结 -> 形成SOP -> 推动执行 -> 收集问题 -> 改进 -> 总结
简单说就是讲事情分成若干个环节, 制定每个环节的标注, 提前告知每个环节可能出现的风险.
在一堆不(各)同(怀)角(鬼)色(胎)的人之间达成共识, 处理纠纷. 最后得出一个妥协后的产品.
有了标准的生命周期之后, 可以推出简化版的SOP和复杂版的SOP供大家执行.
跟开发一个框架Framework差不多, 在性能和成本之间不停的取舍. 为今后的使用总结经验
SOP, Standard Operating Procedures, 标准作业程序