最初的阶段，这些流程和逻辑只是存在于管理者头脑中，在执行的过程中，通过设计公司管理者给下属下达的任务发布出来。随着公司的发展，管理者会希望将这些流程标准化，以文件的方式记录下来。随着文件越来越多，系统越来越庞大，查找文件，维护迭代文件以及执行，都会越来越困难。更好的方法，是将这些流程逻辑梳理成一套在线运行的软件系统，你可以将其理解为一个基于网页浏览器和手机操作系统的APP。专业术语叫做SaaS, Software as a Service 软件即服务。

在这几种方式中不变的是输入和输出的内容，输入端都是公司的运营流程和逻辑，输出端是执行。几种方式下，改变的是交互界面。

口头交互——文件交互——软件界面交互

最近接触到的几家公司，都有将公司运营管理流程和逻辑梳理总结为一套SaaS的需求。其中一家设计公司向我们展示了一份比较详细的文件，提出他们想要做到的功能——也就是一家设计公司项目运营管理的所有内容。此刻我已经知道他们在想什么了，所以我问了一个问题： “你们希望这个SaaS用多长的时间来开发？”

得到的回答是， “一个月。”

这个回答进一步印证了我的猜想。

将公司运营流程逻辑梳理为一个SaaS工具这件事，可以理解为一个典型的互联网产品开发。我提出的问题其实是产品开发方法路径的问题。

软件开发最开始是借鉴的建筑设计公司的工作方法，因为先有建筑师后有程序员嘛，连名词都是直接拿过来用的，软件开发岗位中的 “架构师”，跟建筑师的英文是同一个词Architect. 这导致在我还没有转行进入互联网产品开发的时候，领英就总是给我推荐软件开发公司的职位。后来软件开发的项目管理理论研究将建筑设计项目管理理论抛在了后面，包括软件开发本身，都已经进化成了互联网产品开发。

最初略的分类，软件/互联网产品开发方法流程就两种：

1. 瀑布

2. 敏捷

瀑布就是事先做好整体规划，然后按照分析-计划-设计-代码-测试-发布 的流程将产品做出来。这个很像建筑设计中的 概念方案-方案-初设-施工图-现场服务，所以也很好理解，当设计公司想要梳理工作流程为SaaS的时候，想到的一定是瀑布流的方法。瀑布流的最大问题是，产品开发时间太长，在被验证符合期待之前投入精力太多，导致风险巨大。

敏捷开发需要在一个最粗略的框架下，找到目前最紧要的需求，将这一部分提取出来，做一个能够运行的最小功能产品，发布使用之后，根据用户和市场反馈，进行调整。这个最小功能产品运行顺利之后，再逐步添加更多的功能，而且每次都只添加有限的功能，测试反馈有效之后再添加一点儿。这就是我们熟知的互联网产品迭代。这样的好处是，每一步的风险都在可控范围内。

瀑布流方式很像是计划经济乌托邦，这个方法的起点，就是假设计划的制订者是全知全能的，我们也知道，其实这个全知全能者是不存在的，所以软件和互联网产品开发已经很少采用瀑布流的方法了。

敏捷开发是典型的右派逻辑，看起来没有宏大理想，就当下问题解决问题，日拱一卒，积跬步以致千里。这种方法开发出来的产品更像是长出来的生物，具有更强大的生命力。要以设计公司熟悉的场景来说，那就好比是整体规划，分期实施。

我也知道要跟设计公司领导说明白瀑布流方法是不可行的，会非常困难，但是还是得说。只能以我们自己的惨痛教训来说了。

其实我们在两年前就已经开发出了现有Time-cost的大部分功能，很神奇吧？曾经效率如此之高，难道我们这两年来一直在原地踏步？

非也。

那时候的产品叫Project-cost，就是用瀑布流的思维和方法设计和开发的。交互设计和界面设计做好之后交给软件外包团队开发，外包团队给出的工作周期是3个月，结果延期了半年！也就是说，开发了9个月才勉强上线。这就完了？没有！一个开发了9个月的产品几乎不能顺利使用！运营一个月之后我们就将其下线，从头来过！当时还不知道为何外包团队掉链子掉成这个样子，现在来看其实就是工作流程惹的祸啊。陡然做出一个这么复杂的产品，产品经理(其实就是我自己)又不是全知全能的神仙，根本想不到那么仔细，各种考虑不周叠加到一起，结果就是前后花了接近一年的时间，做出一个根本没法用的产品——多么痛的领悟。

回到原点重新出发之后的Time-cost就才用了敏捷开发的方式，一点一点的迭代而来。每个版本都控制在两周左右完成开发。中间我们也走错过方向，那损失也就是两周，而不是一年！就这样心有猛虎细嗅蔷薇，日拱一卒，又过了两年，才达到了当初那个大计划设定的目标。

敏捷开发也有自身的问题，由于产品是 “长”出来的，长到一定的阶段，会发现原有框架已经利用饱和，再在上面添加够功能就会越来越困难。这就到了需要重新搭建构架，再将所有功能都重做一遍的时候了。这很痛苦，但好的产品都需要不停的涅槃重生。当下的Time-cost在新增子项的开发中，正好遇到了这么一个阶段，顺势重构，所以这个版本的开发耗时特别长，不过这个坎马上就要迈过去了，涅槃重生后，Time-cost会取得更加好的拓展空间，以容纳更多更强大的功能，为设计公司运营管理提供数据支持。

回到之前我问的问题跟设计公司管理者给我的回答，所以说我很清楚管理者对这个工程的想法——跟我们三年前出发的时候是一模一样啊，所以我也很能理解。

惨痛教训告诉我们，只有敏捷开发是有效的。将公司管理流程梳理为SaaS的正确打开方式，是提炼最紧要的需求，做出一个最小化可用产品(MVP, Minimum Viable Product),验证运行正常之后，再逐步添加功能。

系统应该是长出来的，所以这个过程注定不会太短，而且需要随着时间和公司发展状况的调整而及时调整，永无止境。

能够想到将设计公司管理的交互界面从面对面的交互向人机交互转移，已经是理念上的飞跃，将大部分设计公司抛在后面，如果贯彻执行下去，这些设计公司将获取更大的优势。总的说来，整个建筑设计相关行业都处于行业成熟后期，在这样的时期运营公司，拼的就是执行力和管理能力。

是时候开启数据化精细管理之旅了。