第章基本产品

第20章　基本产品　Minimal Product

削减功能还是延长工期？

我号召产品团队放弃老式的产品设计方式。比如，不再试图定义最终产品，转而定义只满足基本要求（价值、可用性、可行性）的产品，简称基本产品。一旦基本产品定义完成，通过了用户测试，它就是一个不可分割的整体，去掉任何元素，都不可能获得预期的效果。

你见过这样一幕吗？产品经理制作了完善的产品说明文档，详细标注了各项产品功能的重要等级。然后，开发部门根据这份文档估算开发成本和开发时间。虽然剔除了开发团队力不能及的功能，但得到的进度表还是比产品经理设想的多几个月时间。于是双方开始协商，先是争论估算是否准确，然后不得不削减功能，缩小测试范围，减少公开测试时间，要求雇佣额外的开发人员……不知不觉时间已经流逝。我猜测你多半见过这一幕，即使没有见过，也能猜到结果：最后开发出来的产品完全不是有机的整体，产品经理不满意，开发人员不满意，用户更不会满意。很多团队把这种情况看成理所当然的、不可避免的，其实这是不合理的流程造成的结果。因此，我建议采用另一种产品设计方式。

第一，产品经理与设计师合作设计产品的高保真原型，这个原型只具备实现商业目标的最基本功能要求，以及良好的用户体验和吸引力。只设计基本功能的产品可以把复杂度降到最低，把开发时间减到最少，因而是非常重要的。

第二，邀请一位开发人员（比如架构师或主程序员）参与设计原型。请他检查原型，帮助产品经理和设计师估算各种功能的直接成本和间接成本，指出设计上的误区，并分析、评估尚不确定是否可行的功能。等产品原型确定时，他详细估算出所有产品功能的时间成本。这样一来，各项功能孰去孰留已经明了，而且对各方都是透明的，开发团队心里也有底了。

第三，请真实用户验证（测试）产品原型，这一点至关重要。在产品团队全力开发产品前，产品经理和设计师必须确信产品是用户需要的，然而仅仅相信还不够，必须通过用户测试来验证。这好比不能仅仅因为开发人员相信代码没问题，就允许发布代码一样，必须对代码展开测试。

一旦基本产品确定，通过了目标用户的测试，就不可能再削减任何功能。如果还能削减，那说明你定义的不是基本产品。

当然，根据产品原型估算的开发时间也不是完全准确，比如，对某些功能的开发时间的估计可能过于乐观。如果出现这种情况，只能延长工期，不能削减功能，因为你已经没有东西可削减了。尽管如此，由于估算的依据从一纸文档变成了精减功能的原型，精度还是大大提高了。即使延长工期，情况也远没有以前严重。

由于开发的是基本产品，一旦进入软件开发环节，产品经理就不能再随意修改设计。过去产品经理经常要求更改产品设计，主要是因为一开始构思不全面、不彻底。设计高仿真原型能够迫使产品经理改掉这个坏毛病。

有人认为，类似Scrum这样的敏捷开发方法可以用另一种方式解决这个问题。虽然我也建议大家采用敏捷方法（因为敏捷方法确实有其优点） ，但它并不能解决这个问题，反而可能带来新问题。相关内容请参考第26章。

因此，设计产品时一定要考虑哪些功能是最重要的，争取设计出只满足基本要求的、不可删减的产品。就像我从前的老板常说的——断腿的狗打不了猎。