开发管理实践及推书
原创
开发管理推荐读物：《目标：简单而有效的常识管理》
最近为了找到更好的开发管理方法， 又将自己25年前看过的书重读了一遍，开心的发现，软件开发和工厂生产是非常类似的，有着几乎一样的问题和解决方案。印象里当时买这本书，是因为作者是个物理学家，作为学物理的，自然不能错过。
推荐大家可以读一下。也希望看过的同学一起来进行讨论，碰撞出新的火花。
讲回开发管理，我们将开发管理分为几个步骤：
阶段 | 目标 | 问题 | 工厂类比 |
|---|---|---|---|
需求提出 （业务+需求管理部） | 应该有明确的价值收益。 《需求管理办法》，法律法规、战略需求、业务需求(明确年价值回报)三大类 | 没有明确价值无法排优先级，研发资源有限的情况下会导致大量不满 | 订单筛选 |
产品设计（业务+产品） | 基于需求，找到合适的解决方案：加功能，加字段，批量处理，例外处理，操作优化，增加功能，增加模块 | 将“愿望“变成被认可，可落地的”产品描述“ | 订单工艺分解 |
成本评估 （产品+标准） | 在产品设计完成时，快速的进行成本评估。由于是按照产品设计的“功能点“进行评估，考虑到复用的情况，内置了一定的冗余 | 无需具体开发人员配合，而是以公司的技术标准做粗略的评估，目标是快速给出成本范围。 简单、一般、复杂、复杂可复用 | 订单成本评估 |
需求排序（产品） | 根据 价值/成本，进行重要度排序，分为 P0，P1，P2，小微，Bug | 排序后作为正式研发订单池。 研发TL根据项目相关程度，重要级别、关联关系，取出需求 | 订单排产顺序 |
（可选）外包 | 外包成本按照功能点评估的人天成本提报外包预算 | 没有明确预算的外包项目大概率会失控导致失败 | 外包加工 |
开发排期 （TL+GL） | TL以月为单位，前端后端分类，按具体人员进行排期，研发组长可在项目间进行平衡调配 | 防止一个萝卜一个坑的现象，工作量的不平衡会导致大量投诉和怨气。没有工作量的量化数据，也无法获得招聘支持。 | 工序分解及量化 |
测试 （测试+产品） | 测试用例，测试脚本，压力测试 | Bug会导致所有已排期项目延期，从而导致交付大量延迟，测试决定了交付后满意度。 | 质检 |
开发交付 （TL+产品） | 解决Bug，再次提交测试。（由于涉及到跨团队，最终时间和Bug数量正相关） | 研发水平和Bug数量密切相关，低水平的研发效率主要在Bug上浪费了大量时间 | 待出厂终检 |
部署 （TL+运维） | 在测试环境中完成测试后，正确的将系统部署到正式环境。做好详细版本管理和文档记录。部署核对表是基础要求。 | 正式业务环境必须谨慎再谨慎，大规模的系统事故，多数是在交付中产生。 尽量自动化，需要有回滚机制 | 客户交付 |
交付与运维 Devops闭环 （需求+运维） | 根据实际业务情况配置合适的系统资源，对于可预计的业务高峰，进行提前配置。 对于核心业务的全流程服务，进行监控。 | 有详细的指引，保障按正确的使用方式被使用。对于高价值需求，需求部门需要跟进，防止“开发完不用“问题。 保障IT能“第一个发现“核心业务故障 | 售后服务 |
那么如何优化整个流程呢？
首先是一个数字化的全景图，能够清晰的看到瓶颈：
阶段 | 数据指标 | 解决方案 |
|---|---|---|
需求提出 （业务+需求管理部） | 需求总数，过滤需求数，需求量化价值，需求提出时长 | 让业务部门透明的看到自己的需求已经进入哪个阶段？ 针对需求分类分级 |
产品设计（业务+产品） | 完成产品设计数，设计中数量，该阶段累计数，累计时长 | 需要与业务反复讨论，可以使用产品AI相关工具提效补缺，同时文档留存，迭代留痕 |
成本评估 （产品+标准） | 根据子功能确认：简单0.2、一般0.8，复杂2.5，复杂可复用1，快速确认总人天成本 | 0.2/0.8/2.5/1是经验系数，需要提前磨合修正，引入更好的开发工具后，可以提效 |
需求排序（产品） | 根据 价值/成本，进行重要度排序，分为 P0，P1，P2，小微，Bug，每一块累计数量和消耗速度 | 价值/成本作为指标，可与企业盈利目标保持一致，确认在有限的IT投入中，获得最多的收益。 |
（可选）外包 | 外包成本按照功能点评估的人天成本提报外包预算 | 外包是控制成本的重要手段，通过评估快速得到预算，优化外包流程 |
开发排期 （TL+GL） | 将所有开发能力数字化：前端后端每一个人的：能力，产能，Bug率 | 文档驱动开发：AI Coding+低代码平台，极大的提升开发效率 |
测试 （测试+产品） | 基于产品文档的描述，自动生成全量的边界测试用例（测试用例数量） | 尽量采用自动化测试，AI可以辅助建立测试用例和测试脚本。测试人员和开发人员角色融合。 |
开发交付 （TL+产品） | 最终工时确认，与预期工时进行比照 | Bug进入知识库，或者通过复用组件来减少人为失误 |
部署 （TL+运维） | 自动化部署，统计运行效率 | AI自动生成使用文档，AI提供对话式使用帮助。 |
交付与运维Devops闭环（需求+运维） | 基于操作日志对最初价值评估对应的实际价值进行预警 服务器资源开销对应的运维成本 | 运维自动化 自动优化 记录新的微调需求。 |
认知：
- 某个环节的超高效率，并不能产生真实价值，系统在业务中运行才产生价值。
- 交付与运维到需求的完整闭环才是有意义的价值。
- 最慢的环节，制约了产生价值的速率，但是瓶颈是动态的。
- 环节和项目之间有资源竞争关系：常见瓶颈是测试
- Bug是最大的负面影响
- 通过开发全流程的数字化管理，随时发现瓶颈，
- 将AI嵌入合适的场景：需求，Coding，测试，可以较好的提升效率
概括地说一下，有了清晰的目标，有了对各个环节产能的明确估算，有了可调动的资源，通过工具提升效率，通过外包解决瓶颈，通过测试保障质量，最终形成价值闭环。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。
腾讯云开发者
