软件研发的这些误区，你中了吗？
极客时间编辑部
讲述：初明明大小：4.61M时长：05:02
你好，欢迎收听极客视点。
1. 关注需求 vs 关注任务
在办公室里看得最多的场景，无非是每一个人都并行工作在很多事务上，忙至深夜。而“努力”的结果还是交付时间一而再、再而三地延期。事务性工作的本质还是任务驱动，关注基本的开发任务，因为任务是片段的、部分的，缺乏产品需求及目标的整体性。个体上，虽然任务完成很多，但因为缺少与其他任务在产品需求层面的拉通，也难以保证产品需求交付的按期交付。这就像忙碌的仓鼠，虽然不停歇地在滚轮上奔跑，但依然在原地。
而软件交付的本质，是持续、快速、高质量地交付有效价值。业务或产品需求才是有效价值的体现。需求来源于用户问题和业务目标，可以从业务目标、业务场景、功能需求等几个不同的维度分解需求，分解完后的需求，依然保持其完整性、独立性，可测可发布，每一个需求的交付，都是一次假设验证的过程，是业务价值创造的机会。
所以，在软件交付协作中，通过精益交付看板可视化需求流动，才能做到价值驱动；只有通过需求，以一个整体视角，可视化“端到端”的价值流，才能做到在协作过程中的前后（职能）拉通。始于用户问题的提出，终于用户问题的解决。
所谓，outcome over output，就是尽可能在最小化 output 的同时，最大化 outcome。output 是任务产出，outcome 是需求结果。站在老板的角度，才不看你完成了几个任务，他关心的是交付了多少特性需求。
这里的要点是，以需求为单位进行协作，更关注业务价值视角。通过精益交付看板可视化需求交付过程。
2. 流动效率 vs 资源效率
资源效率，指的是那种视人为资源，关注人效，制造局部繁忙。然而局部资源效率的提升，并不能使整体效率提升。这是为什么呢？
因为，产品交付的整个过程，需要协同所有职能，包括（但不限于）业务、产品、开发、测试和运维。关注资源效率，一是软件的交付取决长短板；二是每个职能进行局部效率优化，容易形成效率竖井，即局部来看，效率很高，产出了很多中间制品，竖井之间的交接形成了批量，整体效能并未得到任何改善。
以流动效率为核心，就是要以需求为流动单元，从用户来，然后快速流向用户，加速需求的 Time to market。流动效率的快慢直接决定了用户响应、获取反馈的效率。以流动效率为核心，必须拉通交付流程中的所有职能，打破组织壁垒。同时，聚焦流动效率，可以帮助组织即时暴露协作中的问题，如阻塞、等待等，这些问题可能是协作问题，也有可能是工程能力问题。
软件研发过程中的主要问题，永远都不是闲着的资源，而是闲着的需求。
这里的要诀是资源效率，是关注个人人效，关注人力的利用率，繁忙的局部资源效率，并不能在整体上带来流动效率的提升。
3. 关注问题 vs 关注活动
僵尸式站会，指的是那种照搬方法论框架，追求形式主义的站会现象。这一现象，人们往往会面临“站会是要站着开，还是坐着开？计划会议需要分上下午两场，还是集中在下午？”这样的问题。过分关注活动的形式，而忽略了问题本身就是本末倒置。
方法论框架的目的是为了交流理解的需要，而不是生搬硬套，照本宣科。软件项目协作，应该关注问题的解决，阻塞的移除，关注需求如何快速从前一道工序流动到下一道工序。项目协作中，应该关注：
当前有哪些阻塞
哪些到期应该交付，而不能交付的需求
依赖有哪些
交付的价值流中是否有中断
当前交付过程中的瓶颈有哪些
我们建议的站会 6+1，是对协作中关注问题的一个指南。“6”指的是瓶颈和队列、关键缺陷、重点关注的需求、阻碍和问题、到期或即将到期的需求、中断，“1”指的是未反映在看板上的问题。
不建议照搬哪个方法论的框架，方法论框架的目的是为了交流理解的需要，而不是生搬硬套，照本宣科。
以上就是软件研发的三个误区，其余 4 个误区将在下文继续分享，欢迎持续关注。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
精选留言
由作者筛选后的优质留言将会公开显示，欢迎踊跃留言。
收起评论