观点
基于软件行业已有的知识、前人的整理和近十年实际工作的总结，针对如何做好项目管理和软件开发这一个话题，我提出一个核心的新观点：那就是，基于价值交付驱动，打造软件研发团队和建立对应合适的指标体系。
回归起初，最基本的标准化软件研发流程，只是为了让组织内部、专业岗位之间明确协作、分工和流转的顺序和流程，这是一个从无到有的改变；而近几年聚焦于提升研发效率、加快研发速度和缩短迭代周期的，都是聚焦于研发内部的提升，即用相同的人员配置在同样的时间周期内尽可能完成更多数量的交付。例如：DevOps、敏捷开发、Scrum、XP。
我之所以提出基于价值交付驱动，是想让负责软件研发的负责人，能和企业一同完成更大范围的协同。
软件的价值不在于研发好做出来发布上线就完事了，还要让人们学会使用、好用、能用，最最为重要的是要让软件系统发挥和体现它的价值，为业务带来收益。
我始终坚持一个观点：软件是给人用的。
何谓价值交付驱动？
如果要翻译成英文，应该是：Value-Deliver Driven Development。基于价值进行交付，具象一点就是，这个功能做好后，能带来什么好处？
投入了这么大的研发成本、人力和时间，做好的软件和新功能，它能赚钱吗？能带来GMV的提升吗？能帮我们获取更多用户吗？能提高订单的支付转化率吗？能解决客户目前最核心的痛点吗，是用户关心关注的问题吗？能帮助业务现场或内部团队确确实实提升他们的工作效率吗？能帮助企业完成规模化的运作吗？能帮助公司或部门或销售完成他们制定的年度目标KPI吗？
研发效率再快，但做出来的功能不是业务部门或市场所需要的，最终还是会大打折扣。犹如一辆120时速的车，开得贼快，但就是不来目的地接乘客！真让人着急！
因此，为了支撑配合业务部分完成销售和市场目标，让价值流动更为快速、响应变化和需求，在公司发展规模化、技术驱动商业化和IT交付工厂化的背景下，我们调整以往的关注点，改为关注和专注于价值交付，是一个更有利于企业实现盈利的视角和转变。
价值交付驱动型的软件研发团队指标体系设计
在《Thoughtworks洞见-研发效能度量指标》一文中，提到并罗列了软件研发合适的指标分类：规划进度、快速反馈、团队转型、辅助决策、工程能力这五大方面。结合以上的指标，叠加上业务研发团队的实际管理所取得的成效，我对研发指标的体系进行了调整升级，使之更符合人、符合业务、符合中国国情的指标。
规划进度
主要作用是：预测未来、回顾过去、清楚当下、识别风险、量化质量。
规划进度：
- 项目集
- 项目燃尽图
- 项目甘特图（要支持跨项目的甘特图合并）
- 需求排期表（工时+排期）
- 速率图
- WBS工作拆解图
- 人月交付需求数量
快速反馈
主要作用是：在客户需求/问题提出到软件上线交付使用的这一段过程的快速反馈和闭环。
快速反馈：
- 线上故障处理
- 主流程订单通知
- 技术工单处理
- 客户满意度和回访
- 服务器监控指标
- 系统部署的频率（是否更快更精更稳定）
团队转型
主要作用是：为团队、管理层和企业指出不合理的地方，以及需要改变的方式。
团队转型：
- 手工测试的耗时
- 人员配置比例
- 单元测试覆盖率
- 修复Bug的耗时占用
- 自动化占比
- CI/CD自动化发布
- 知识库文档
- Bug漏测率
- 内部效率提升
辅助决策
帮助企业经营、创始人或高管进行研发资源、费用和收益的评估。
辅助决策：
- 前置时长
- 里程碑
- 变更前置时长（即等待和阻塞的耗时）
- 年度执行计划表
- 功率分配比例
- 交付的价值
- 研发投入和ROI
- 激励考核培训体系
工程能力
主要作用是：找出软件研发团队的弱点，持续改进。
工程能力：
- 系统性能优化（进行必要的重构和技术优化）
- 服务器扩容
- 安全系数
- SLA服务水平
- 业务系统的健康检测
- 标准化研发流程
- 最佳实践
如何设计适合自己研发团队的指标？
确实，根据不同规模的企业、上下文信息、业务类型和特点、研发团队的历史情况和当前管理人员的风格和经验不同，再加上每年企业制定的目标和发展方向及重心的动态变化，很难设计一套放之四海皆准的研发指标。但基于我们想达到的效果、基于我们的落脚点，再反推软件研发的起脚点，就很好设计出适合和属于自己的团队指标和提升方向。
同样，我也认同莫把度量当目标。度量就应真实、全面，度量出来的数值无非好坏、高低，只要能体现和说明以及指出当前团队不合理和值得改进的地方，就是一个好指标。
例如下图中，通过YesDev记录的这两年数据，某个研发团队发现，在相同人员配置的情况下，2023年完成交付的需求更多、Bug更少（即质量更优），那么就是一种进度。
如何选择合适的研发协同工具？
诚然，这也是一个值得反复提问的问题。因为如何想找到一个适合的工具，还要能指导我们不断提升的工具，还能满足未来动态变化过程中不同阶段的组织发展需求，确实是值得深入研判的一个灵魂问题。工具是基本的必要条件，但如何用好工具也是一个不过绕开的话题。
光有工具不行。纵使再优质的纸张、再昂贵的铅笔、再好的尺子，没有建筑师的规划和设计，也设计不出来跨海大桥的图纸。因此，你的团队里需要有一位有经验、有能力、有想法、懂老板、懂企业、懂管理、能带领团队不断进行重组、改革、学习和提升的Leader或敏捷教练。
与其问，如何选择一个合适的研发协同工具，还不如问：如何找到一位合适的研发管理才人。
参考
参考：Thoughtworks洞见-研发效能度量指标（1、2、3） by 张思楚
insights.thoughtworks.cn/research-de...
关于作者
黄禅宗 dogstar，果创科技创始人，YesApi果创云亿级流量PaaS平台创始人、YesDev研发协同SaaS创始人，累计服务3万+开发者； 前唯品会高级开发工程师，千万级架构经验； 前MobVista高级工程师、前租租车技术经理； 10年以上互联网经验，对软件领域有独特见解；PhalApi开源框架作者，著有《良质!》等电子书；退役士兵，华南师范大学软件工程专业，喜欢交流分享。