有害的“这样效率最高”思维

http://cugesoft.cn/blogs/harmful-thinking-for-high-productive/

在与一些人交流时经常碰到对方说，你的方法好是好，就是不如现在的方式效率高，因此并不愿意作出改变。我们来分析下，为什么说这样的思维方式是有害的。

不拆分需求效率最高？

有些团队包括技术背景出身的PO不愿意按可交付的方式拆分需求，原因是原来的方式虽然不能频繁交付，但最节省时间，效率最高。

这种思维是有害的，首先：频繁交付的一大目标是通过快速反馈确保探明真正的需求，构建和交付的是正确的产品，而不是为了更高效率地在给定时间内完成更多的需求内容。Do the right things, 花费的代价可能更高，但避免了南辕北辙式的整体错误或陷入进退两难的焦油坑中无法自拔。通过频繁交付，即便在给定时间内不能完成全部需求，缺失的也不过是价值较低的特性，对客户价值的损害有限。历史经验也表明，项目中最大的浪费不是多花了10%－20%的时间来开发，而是构建了错误的产品，添加了根本没人会去用的特性。

从另外的角度来看，在大多数项目中，真正开发的时间只占整体项目时间的20-30%， 即便省出了开发时间的20%，占总体项目时间的比例也只是 30%＊20% ＝ 6%， 为了这个6%却去冒不能及时获得有效反馈的风险，长远来看并不值得。

在非常自信不拆分的特性就是真正想要满足的需求时，整个一大块不拆分，也可称之为“冲坡式开发”，团队必须具有足够的能量冲过去，否则就有可能造成溜坡，不仅所有努力白费，还可能造成其它严重后果。在某些特定情况下，“冲坡式开发”还是必要的，这时就要注意集聚足够的能量，以及在技术上采取必要措施，比如通过临时分支等方式避免对主干的干扰，尽量做到可以随时叫停（止损策略）而不会对整体造成影响。

因此我们说：

• 效能比效率更重要，错误的事情效率越高害处越大，确保做对的事情，额外花些代价也是值得的。
• 保持战略灵活性，增强应对变化的能力，随时可停可前进，甚至可以从容选择撤退。

  
  

  按Component或架构层拆分需求来做效率最高？

  因为团队技能的问题，很多组织还是习惯按组件或者架构层次来划分团队负责领域，这样在拆分需求时，一个团队内的用户故事显然无法覆盖端到端，如果迭代计划也缺乏协调，后果就是各种互相依赖，很难做到持续交付。

  结论：

• 单独的组件开发可能效率最高，但互相等待和扯皮的时间大大增加，整体效率反而很低
• 组件或架构层团队使团队成员的思考视角变的狭窄，很难培养系统级的人才，在需要时也无法有效调配人员

  
  

  按waterfall方式来做效率最高？

  Waterfall效率高的幻想出现在项目早中期，后期往往陷入焦油坑中无法自拔，丧失应对变化的能力，一旦决定舍弃一部分产品特性时，很大部分的努力也白费了。

  一个人独立做效率最高？

  我们常常看到，关键时期，一个系统出了严重bug，一堆经理层层发布指令，号召必须在最短时间内搞定，最后我们可以发现，所有的焦点集中在一个开发人员身上，其他人即便想帮忙，短时间内也无法贡献太多，这个开发人员如果成功将bug搞定，则会被视为英雄，否则，便会成为替罪羊。

  如果我们按模块把责任细化到每个人头上，互相交叉太少，需要投入更多人员协同作战短时间内把问题搞定的时候，就很难办到了。 单人打法，就像是巷战，全凭个人能力，而不是全方位立体团队协作模式，短时间内局部也许效率确实很高，缺点也很明显：质量能否保证，取决于个人，个人的微小错误可能会被放大，系统中的各个模块质量差别可能很大。

  考虑各种情景，长期看单打独斗模式在关键时刻往往会出严重问题。比如需要协同作战的时候，效率可能无法提高；人员一旦变化，对整体的影响也会比较大。