最近准备组织一个关于敏捷的工作坊，不得不又再次被问及敏捷和瀑布到底哪种好。

前段日子在某个产品经理群里，有好几个产品经理也在讨论是否需要写需求规格说明书，用什么方式写比较好。

我一向秉承一个观点，正如邓爷爷说的“管他黑猫白猫，抓到老鼠才是好猫。”

在我看来，敏捷和瀑布没有什么哪种更好的说法，只有哪种更合适你的产品和项目的说法。

同样的，到底是用Word写需求规格说明书，还是用Axure之类的原型工具来写，也没有什么更好的说法，只有哪种更适合你的产品和项目的说法。

Joel Spolsky在他2002年的博文中提到了五大世界的观点。

时过境迁，软件行业发展迅猛，各种工具层出不穷，可能老乔当年的一些定义已经过时了。

但是，当我翻开他的博文合集《软件随想录》的时候，却发现他对于五大世界的划分，在当今软件行业中依旧适用。

老乔将软件世界分成五种，这五种对于软件的质量、用户体验、版本等要求都各不相同。

这些不同也就决定了适用的流程和工具也不尽相同。

注：为了能让大家读懂，我将一些“过时”的词汇用大家熟悉的词来代替。
再注：我们把重头戏放在后面吧！

嵌入式软件

有人问，啥是嵌入式软件？

其实家用电器上非常常见。

你家洗衣机、微波炉用的芯片在出厂前会将软件烧制在上面，这样你才可以通过按几个按钮就可以选择模式和启动机器工作。

对于这类软件，一般对性能的要求会非常高。

用户会期望通过一条指令就能让设备迅速运转。

所以编写嵌入式软件的代码追求的是运行速度，而不是优雅。

你觉得这类软件会进行版本升级吗？

可能有些小伙伴知道“烧机”这件事情，就是以前我们的手机可以通过这种方式进行设备的“破解”。

但是，大部分情况下嵌入式软件时不会进行升级的。

这样就意味着这类软件对质量的要求很高，你没有第二次的机会去做什么Hot Fix。

所以这类软件不论是需求文档还是设计文档的要求都是非常高的。

而且也不会存在纯粹的敏捷，因为它是不允许所谓的“试错”的。

游戏

游戏软件很有一种“赢家通吃”的感觉。

怎么说呢？迅速的抢占市场是最重要的。

同样一款“跳一跳”游戏，一般大家会去玩的总是先出来的那个。

就算后来出现了很多类似的游戏，但是大家比较少去玩了。

另外，一旦通关或者热度过去后，玩家也不大可能再玩了。

游戏软件对质量要求也是比较高的，因为玩家是“最不忠诚”的用户，动不动就放弃你，奔向别人的怀抱。

曾经听一位游戏软件从业小伙伴说过，有的产品团队甚至会同时让三个团队三班倒，24小时不间断的开发以快速抢占市场。

这样的速度，完全不可能让产品经理慢条斯理的去写需求规格，评审等等。

这也就决定了他们采取的流程一定是快速响应、信息共享的。

To C 软件

在2002年，老乔称之为“盒装软件”。

因为当年的互联网软件应用不是很多，还主要集中在网页网站上。

而以老乔工作过的微软为例的Excel软件，是装在塑料盒里售卖的。

所以老乔称之为“盒装软件”。

现在的话，即便是Excel，也基本上不卖光盘了，而是自行从网上下载后，购买“许可”进行安装使用。

To C的软件，一个非常大的特点是：用户量很大。

记得几年前和一个互联网行业的小伙伴讨论需求调研提纲和访谈的时候，他一脸茫然。

对于用户量上十万、百万，甚至更多的软件来说，你让产品经理去做调研提纲和用户访谈，其内心活动估计是：“你在逗我吗？除非我下半辈子只做这一件事情，还不一定做得完。”

对于这类软件，传统意义上的用户访谈等可能就起不了什么作用了。

所以，这类产品开始一些其他的尝试，比如：问卷。

后来发现问卷的水太深，转而通过“埋点”+“主动反馈”的方式收集需求和反馈。

注：关于问卷，我后面会专门开一篇文。

另外，也是因为用户量巨大，所以用户使用的终端五花八门。

虽然移动端目前主流的是安卓和IOS，但是再七八年前，那简直就是一场混战，更不用说在彩屏刚上市的年代了。

那么产品的设计和开发就需要适配多款终端，这里面的复杂性可想而知。

所以对软件产品的兼容性要求很高。

因为用户量巨大，重口难调。

对于软件的风格、配色、易用性的要求会更高。

这种情况现在更为明显。

以我使用时间管理APP的经历为例，我曾弃用一款APP，就是因为界面太丑。

我可以选择的APP那么多，为什么还要“忍气吞声”的使用我不那么喜欢的软件呢？

基于以上的各种原因，To C的软件必须要款速迭代升级（买方市场决定），并且注重易用性和用户体验，而业务逻辑相对简单。

所以，这类软件大都使用迭代的开发模式，比如敏捷。

而且，这类软件会考虑用Axure等原型工具来写需求规格，这样更加直观，毕竟大部分的功能都是基于页面的。

甚至说，由于变化太快，很多公司直接用一些软件工具进行需求、User Story的管理，会画一些草图而不写正式的需求文档。

用过即抛的代码

对于开发来说，有的时候会写一些临时性的代码。

可能是为了验证某种设计，可能是为了别的什么目的。

不管怎样，这类代码写的时候就是做好了被随时抛弃的准备。

针对这部分的流程、文档和工具，一般来说不会做什么规定和约束。

书写的代码一般来说，对于产品经理和BA来说也不可见。

内部软件

大部分的To B的软件，比如ERP，CRM，OA等等都是属于这类软件。

这类软件大部分会针对客户的需求进行定制。

不论是SAP这类国外的厂商，还是金蝶、用友这类的国内供应商，他们提供软件产品，更提供实施服务。

他们的主要利润来源有两个部分，一个是软件产品（一般是按照模块或者许可数量等进行销售），另外一个就是实施费用。

没错，这类“内部软件”买回来一般只能使用基础的功能，而每个企业的管理模式和制度都千差万别。

那怎么办呢？

需要靠实施团队来进行需求调研、解决方案制定，评审过后由客制化团队的成员进行定制开发。

所以这类软件产品会要求比较好的可扩展性、可维护性、可配置性，否则实施成本会很高。

比如，如果不提供审批流程的快速可配置，而需要通过代码实现，那么实施一套OA的成本会迅速被提高。

另外，因为定制只是针对一个用户的，所以该组织使用什么硬件环境、网络环境一般都是已知或者说可获悉的，相对于 To C软件来说，开发的难度一般来说不会特别高。

甲乙双方会在实施前就约定好付费方式，一般会按照里程碑付费。

比如需求阶段结束，解决方案评审完成，作为一个支付里程碑，甲方会支付50%的费用。

这就要求双方都要签字确认，确认的是方案，一般也需要进行归档，所以如果你是用Axure写方案，那就麻烦了，因为没办法签字。

所以，一般来说，这类软件都会需要写非常详细非常正式的方案文档。

另外，这类软件的业务逻辑一般来说比较复杂，特别是客户需求和场景比较复杂的时候，分支case和页面层级特别多。

如果你不写文档，或者说你用Axure来写文档，开发和测试都会更糊涂。

Axure最多是用来和客户做需求确认的时候使用，而且要特别和客户说明，咱这个是假的，是原型，不是可以使用的系统。否则客户可能会觉得自己受骗了：花了那么多实施费用，你就用两个晚上就把系统做好了？

而且因为付多少钱在实施之前就约定好了，大部分按照人天付费，那么项目经理会严格把控项目成本。

即便是你挖掘出来了新需求，除非你能说服客户签订补充合同，另外付一笔钱。或者你能说服老板“吃亏是福”，否则一般情况下是不会做扩展的。

当然，随着云服务的发展，越来越多的To B的软件开始朝着轻量化的方向发展。

但是对于非常复杂和特殊的业务，实施环节还是必不可少的。

还有一点非常有意思，虽然现在满大街都在嚷嚷着“用户体验”，但是To B这类实施软件的用户体验相比于To C的软件简直一个地一个天。

我觉得当你让甲方选择，同样的钱在用户体验和数据安全或者业务流程满足度上进行选择，他们肯定不会选择用户体验的。

更何况，如果想要提升用户体验，对于To B的软件来说，并不是说我软件做的好用就可以了，而是要从甲方的组织架构、文化制度、规章流程上进行优化。

你怎么指望一个需要10个签审节点的流程通过一个软件进行用户体验的优化？

这类软件的升级方式也很特别，通常情况下有两种方式。

一种方式是，在签合同之前的售前阶段，就会有一个宏大的总体方案，然后说这个实施会分为三期或者五期上线。

然后，签合同的时候可能只包括一期的内容。

等到一期内容上线运行后，肯定会有一堆的需求和BUG，这个时候就会在二期一并进行改进。

另外一种方式是，按照约定上线运行一段时间后，可能是三五年。

甲方实在对系统忍无可忍了，而且手头上又有点闲钱了，就决定要升级系统。

这个升级很有可能是直接把原来的系统彻底换掉，也可能是找原来的厂家来做升级。

这里一般来说，甲方会有人来做可行性分析，然后进行评估，哪一种性价比更高，然后交给领导定夺。

说了这么多，你觉得你处在哪个世界中呢？

还是那句话，只有适合的方法和工具才是最好的。

你同意吗？

小婧是一名行走在实践路上的资深业务分析师（BA），如果想与我同行，就请关注我吧！