# 对研发管理的一些思考
本文分析了项目管理中的研发管理,以研发过程中不同的职能角色为切入点,对项目在整体控制上的宏观和微观认知以及具体的操作做出了思考。
# 一、研发人员
研发人员在一个项目中最关心的是自己工作的目标和方向,以及自己的工作与整个系统的关系是什么。在很多公司的研发过程中,往往忽略了研发人员的需求,研发人员更想看到清晰有条理的目标和需求,方案和技术框架等等,以及作为一个整体自己的角色是什么,当有联调需求的时候,能够根据项目蓝图找到合适的协助人员。
# 1.1 项目WBS
工作分解结构(WBS)是对整个项目工作内容和系统架构进行的解构,通常WBS适用于分解项目管理中所有部门遇到的问题,这里仅使用该思想去分解研发部分的内容,例如下图为笔者最近正在推进的一项个人项目。
# 1.2 最小功能集
最小功能集是系统分解后的最小单元,最小功能集可以分配给1~2个人完成,在完成任务时,需要对技术方案进行讨论,得到可行的技术方案,并有一些定量的指标作为目标,根据80h原则,最小功能集最好在两周内完成,或者至少能够完成基本雏形。
# 1. 技术路线
对于一些比较重要的最小功能集的开发方案,需要职能经理或者技术大牛共同商定,得出一些可行的方案,避免这个过程产生偏差的潜在风险,因为直接让一些人员去完成任务,他们可能在方案选取上产生错误,这些错误可能在后续产生严重的误导或者Delay,又或者他们在工作执行上走一步看一步,导致效率低下。
# 2. 目标与关键任务
技术路线的确定只是一个基本的功能框架,但是这个过程中可能需要分析一些定量的指标,尤其是在包含算法的项目当中。例如一个对实时性要求很严格的控制系统,其图像反馈信息希望控制在300ms以内,帧率达到20以上。这就是一个确定的目标。
根据项目目标,需要设定一些关键任务,例如上述的图传实时性项目,需要分析一些传统流媒体处理工具在对rtsp数据流进行解码时的耗时程序,例如假若一组可靠的实验得出了一个确定性结论:这些工具的解码过程都达到了1s。这就意味着传统工具将无法使用,需要其他方案或者自研性能更好的工具。
指定的方案往往并非百分百可靠,需要去完成这些方案中的关键任务,打通整个流程,这样才能说明方案本身可行,最后再来优化功能细节,追求完美主义。
# 3. 工作日志
尤其是包含算法研发的项目,工作日志非常重要,研究探索的过程可能包含了很多重要信息,这些重要信息可能会形成未来工作的重要参考,在后续文档管理时,需要将这些信息整合起来。
# 1.3 代码管理
# 1. 代码Review
一个最基本的原则就是开发人员不能将代码直接提交到最终的产品代码主分支上,需要由组长或者其他角色确保了研发人员完成了自测过程,对代码进行基本的把关和审核之后才能进行下一步提交。
# 2. 系统测试
在确定好一个版本后,提交到测试部门进行测试工作,测试人员的观察角度会和研发人员不一样,测试工作非常重要,是确保产品质量的关键一步。
# 1.4 文档管理
# 1. 关键实验文档
项目研发过程中,可能会有一些重要的实验,它能作为未来工作的重要经验指标,对于这些实验,要做妥善记录,并确保汇总到最后的功能集文档中去。
# 2. 功能集文档
在完成一个最小功能集任务后,需要形成知识性文档,当未来遇到相同需求的任务,或者进行产品迭代时,这些文档是重要的参考资料。
文档的攥写质量是一件很难控制的事情,可以使用内部专利制度[1]。
内部专利即文档被其他人查阅一次就付一次费用给攥写人;同时,如果总结的方法被使用后,的确防范了问题的再次发生,由此降低的成本也给攥写人分成。
# 3. 文档审核
文档最好有固定的模板,也有专门的人进行质量审核,提供更改建议,不能让用处不大、满是“正确的废话”的文档存入数据库。
# 二、项目经理&职能经理
对于项目经理或职能经理而言,他们不会关注技术细节,而会关注项目的整体实施情况,例如项目进度如何?某一些功能开发是否出现了偏差?
# 2.1 局部进展控制
# 1. 整体与局部偏差状态
研发人员因对技术方案理解有误,而在错误的路线上进行了推进,或者因为个人原因追求技术完美,或技术探索了,增加了额外的工作量,这些都要予以跟踪控制。
# 2. 局部技术阻碍
对于遇到的关键性难题,要请外部人员或者公司大牛予以支持。
# 2.2 整体进展控制
# 1. 项目流程
以软件项目流程为例,主要过程包括:项目立项与启动、项目需求调研、项目设计、项目开发、项目测试与试运行、项目验收。在项目开发前需要理清产品定义、立项评估报告(产品时间节点)、项目失效模式分析、项目成员清单等。
成本、人力投入关系与项目阶段主要输出内容的关系:
- 启动项目:项目章程(5%)
- 组织与准备:项目管理计划(20%)
- 执行项目工作:验收的可交付成果(60%)
- 结束项目:存档的文件(15%)
# 2. 任务分配与人力资源调用
根据WBS和项目成员清单进行合理安排分配。
# 3. 甘特图与里程碑
确定某一项计划的开始和技术时间,以及成果交付。
# 4. 变更管理
变更管理有时候来自于外部客户,有时候来自于内部的需求变化,要有严格的章程对变更进行约束。
# 三、管理层
# 3.1 成本与偏差率
例如国内某知名安全公司使用的是一种以人工成本为基础的项目偏差率计算方式:通过人工成本×时间 + 其他成本,与预算进行对比,通常项目delay了,随着时间的增加,成本会大于预算,当偏差率大于10%的时候,就视为重大责任事故。
以前笔者一直以为delay所造成的影响只有客户方面,但现在才发现其实还有提高项目成本,较少公司的收益,因为如果项目提前完成就能用更多的时间投入到新项目里了。
# 3.2 项目关键节点
管理层在一些项目关键节点,要利用职权对项目进行引导和约束,例如宣告项目启动,让大家进入项目的紧张状态。
# 参考资料
[1] 郭致星. 极简项目管理[M]. 2021年10月第1版第4次印刷. 机械工业出版社, 2021年 :261-261.
← 一些琐碎想法