技术优先VS业务优先——本文是两种不同计划方式的效率和效能对比
注：下图中同一颜色的卡片表示具有类似的技术特征的story，比如含有布局类似的页面等。
计划方式A：技术优先
制定计划的思路如下图所示，倾向于并行解决技术问题，最后做集成。
毫无疑问，这种方式可以实现Dev的效率最大化，即同样时间内，Dev可以产出更多的特性。
期间BA和QA都很难插上手，BA无法就当前产出是否符合设计预期给Dev团队反馈（自然也就很难去发起变更lol），QA因为无法就新增特性是否满足质量要求给Dev团队反馈（但仍然可以就新提交是否破坏既有功能做检查）。
计划方式B：业务优先
Dev倾向于率先打通第一条通道，BA和QA可以在最早的时候接入，对就当前产出是否符合设计预期和质量标准，给出反馈（顺便也会发起变更）。
下图是技术优先方式的各角色投入系数，第四周全体打满（投入系数1为打满），第五周OT到1.5，以给缺陷收敛充分的投入。
下图是业务优先方式各角色投入系数，第五周投入分别为BA 0.2，Dev 0.5，QA 0.8。没有OT，第五周的时间各角色分别有一部分精力投入到下一个版本的计划制定中去，做对未来的投资。
从效率上看，结论如何呢？
OT了的技术优先在总体产出上会多出大概10%，胜过没有OT对未来投资的业务优先。
从效能上看又如何呢？
技术优先，对需求质量要求更高，中间反馈缺乏，使得所有的业务和质量风险集中在最后阶段，往往最后结局是团队迫于时间点压力上线不符合预期的产品。
这样做的最大的弊端是：无论团队怎样努力OT，都不会做得比起初的设计更好。做得更好的可能性，被消除了。
这种情况可以称之为契约的惩罚，自行理解含义。
业务优先，对需求质量相对略低，中间反馈丰富，业务和质量风险均摊在整个研发周期内，无集中风险点，最终上线的产品特性都是符合甚至超过业务涉及预期和质量要求的。
这样做的最大收益是，使得做得更好更精成为可能。
这种情况可以称之为协作的奖赏，含义自行理解。
能坚持看到这一行的，实属不易，真不忍心给再出道题考你:P
问:产品A和产品B，哪个效能更优？
（注:打中，上线效果符合预期称为打中）
原文链接：http://hi.baidu.com/whoistonyli/item/4571d6ffdbc4c1e8a835a2a3
