软件开发中的抓大放小vs极致细节思维

  最近在开发过程中，遇到了好多次 “这个需求点这次要不要做？” 的问题， 主要有两方阵营，比如以研发主导的 “这次先不做、等必要的时候再做” ，另外一方是以PM主导的 “这个不做需求不完整，可能影响用户体验” 。争议主要出现在一些小需求或者细节点上，一般不是啥核心功能，比如一些鸡肋需求或者有些极端异常case的处理。 前者的主要观点是“这个需求不重要可能会浪费时间，有哪些时间还不如做一些更重要的事”，后者的主要观点是“这个点虽然不是核心功能，但没有的话可能让用户决定我们产品有缺陷。” 如果遇到的两方脾气不好，甚至可能闹到剑拔弩张的情况。

  这两种不同的观点其实就是我标题上说的两种不同思维模式导致的，前者的思维模式更偏向于 “抓大放小，优先解决主要矛盾”，而后者的思维模式就是“细节决定成败，不放过一个问题”。不同的人在这两种思维模式上有不同的倾向，就是孰对孰错、孰优孰劣。这仿佛是个无解的哲学问题，下面我给出我对这个问题的答案，仅仅是一份我自己的观点，大家也可以在评论区探讨下。

  首先，我作为研发，大部分情况下的决策都是“不做”，因为做了会显著增加我的工作量，软件开发过程中也存在二八定律，80%的功能只占开发时间的20%，而剩余20%的功能需要额外投入80%工作量。剩下20%的功能ROI是极低的，这是我的第一个理由。 其次，很多需要点和细节点只是别人的假设，并不一定代表真实的场景，大部分情况下这个需求点是伪需求，直接拒绝可以有效避免研发人力的浪费。

  我们举个我所遇到的例子。我们公司的业务建立在某云之上，如果该云厂商宕机我们业务一定会挂，这显然从业务上讲这是不可容忍的，如果你去问老板，你希望自己的产品稳定性是多少，他一定会回答是100%。有一定技术经验的人都知道100%的稳定性是不可能达到的，我们只能无限趋近于100%。 摆脱单云依赖，我们唯一的选择就是要支持多云备份，然而这个成本巨高，可能需要我们全部技术吭哧吭哧改造几个月来完成，这对于一个以业务快速发展的团队来说也是不可接受的。在这件事上，我们都选择了坦然接受云厂商可能宕机的风险，选择抓大（业务发展）放小（极致的稳定性），

  再举一个决策完全相反的例子。我在入职阿里参加新员工培训的时候，听老员工将讲到了阿里曾经的去IOE项目，就是要在阿里巴巴的IT架构中，去掉IBM的小型机、Oracle数据库、EMC存储设备。其中我印象比较深的就是他讲到支付宝替换Oracle数据库过程中，他们投入了巨大的成本做数据稳定性一致性的验证，因为金融级别的数据就是要求100%的准确性，这种情况下就是追求极致的思维模式。

  可能有些同学也看出来以上两个案例决策结果不一致的原因。表面看是业务场景的不同，虽然我在案例一中没有具体介绍我们的场景，但大家也能看出来我们是可以接受不可用风险的，而且云厂商宕机其实算是小概率事件(虽然前两天阿里云就出事了)，短暂出问题后我们的损失远小于投入人力建设多云备份的能力的。而反观支付宝替换Oracle数据库的事，他们处理的是金融相关的数据，也就是和钱相关的数据，比如给你少算一分钱，这不仅仅是一分钱的问题，而是信任的问题，一旦出问题公司可能就黄了，所以他们出问题的成本是非常高的。 虽然这两个场景得出了不一样的决策，但其背后都遵循同一个原则，就是投入产出比最大化，大白话就是在同样的收益下成本最小或者在同样的成本下收益最大。

  投入产出比最大化 这个思路相信正常人都是认同的，那为什么同样一件事不同的角色在抓大放小和极致细节之间选择不同的思维方式？ 答案就是不同的人对收益和投入的评估结果是不一样的，有些时候做一件事投入的成本和预期收益是很难量化的，大家只能凭借自己的经验和感受做一个简单的评估，这个时候每个人评估的结果可能就会出现差异。我举一些观察到的现象（不一定完全准确）

• PM倾向于高估收益低估成本
• 研发倾向于低估收益
• QA倾向于高估风险
• 管理层和PM一样容易高估收益低估成本
• 不了解技术的人容易低估技术成本
• 乐观的人任意高估收益，悲观者容易高估风险
• 容易替别人低估成本，替自己高估成本
• 如果最近出过严重问题，容易高估风险
• ……

  有些是角色使然、有些是性格使然、还有些是环境使然，这些都很难控制，只能多沟通、建立规范、多尝试，各方在软件开发过程中，可以参考下这些建议，希望可以尽可能减少在成本和收益上的认知偏差。

1. 在评估收益时,我们应该考虑功能对用户和业务的实际价值，而不仅仅是满足用户的要求。很多用户需求可能只是“好奇心”或者“完美主义”,真正使用时作用不大。我们需要区分核心价值和边际价值。
2. 评估成本时，不要只看短期投入,还要考虑带来的长期维护成本。一个小功能可能需要持续Debug、完善、升级,总成本远超初期开发。
3. 沟通时,各方应摒弃主观偏见,不能因为立场不同就互不信任。研发应直面PM的质疑,而PM也应理解技术难点。管理层要站在全局角度平衡各方诉求。
4. 可以建立一套清晰的规范，说明不同类型需求的优先级原则、成本评估模型等,减少鸡肋需求的争议。并且可根据实际情况不断完善这套规范。
5. 在可行范围内，应该允许小规模试错,因为很多收益和成本在实际开发前难以准确预测。通过最小可行产品快速验证idea,再决定下一步优化方向。

  软件开发过程中的抓大放小和极致细节两种思维模式并没有明显的对错之分，至于不同的人选择不同的思维模式，源自于不同角色对收益和成本的认知偏差。但我认为在软件开发的不同阶段中，有着适合的不同思维模式，所以还是需要有倾向性的。 比如在软件开发初期或者资源有限的情况下，可以更倾向于抓大放小。但在软件稳定期更应倾向于极致细节。 当然如果遵循投入产出比最大的原则，一切都是可以自然而然改变的。比如在软件发展的过程中，有些功能初期不重要，但后期可能会变的很重要。所以还需保持开放和灵活的心态，根据不断变化的实际情况调整开发策略和优先级。