画图解决“在什么时候”的问题
框架4：用时间轴说明“在什么时候”
做事要一步一步走
现在我们已经知道客户需要我们在哪里对软件产品有所修改。假设我们确信经营方式可以提高销售额（这是个很大胆的假设，但我们会在“为什么”的框架部分处理这个假设），接下来的问题是“它需要多少时间”。进行这些升级会用几周、几个月，还是一年甚至几年？显然，我们面临的是“在什么时候”的问题。此时，“视觉化思考宝典”告诉我们：用时间轴吧。
在我们看到“在哪里”之后—随着时间的推移—我们也看到了对象会在质和量方面进行变化。为了向别人展示这些变化，我们用一条时间轴来描绘它们在不同时间里的各种状况，或者描述随着时间变化的对象关系。
时间轴：基本绘画方法与要求
1.时间是条单行道。尽管大家对于第四维度
和时间本性的讨论十分感兴趣，但它们与商务中的时间问题无关。对我们来说，我们将把时间看成一条从昨天到明天、由左至右的直线。第四维度的说法也许并不一定符合那些满世界飞、整天倒时差的商务人士；时间呈直线性的理论又是一个先入为主的偏见，但这二者都是非常有用的。
2.重复的时间轴形成生命循环。鸡生蛋，蛋生鸡。上上下下的市场循环周期，日复一日、月复一月、年复一年—时间轴一遍遍地重复。当它们这样重复时，我们就称它们为“生命循环”，可以用无尽的圆圈表示，或者在时间轴末尾加上一个“回到开头”的箭头。对我们来说，无论时间轴重复与否，我们创建它的方式总是一样的。如果我们不能确定起点，就可以顺着生命循环圈，在任何一个地方立上一块里程碑作为起点。
3.环形Vs.线性。时钟和直尺都是由一条单线构成的，只是时钟恰好头尾相连。循环性的时间轴在很多方面都可以更精确地表示重复的生命循环圈。它不仅容易画（尤其当每个步骤都伴有具体文字说明时），而且也更好认读、更好记。如果你的重点是要强调某个特定循环圈的重复性，循环性的时间轴和日历（就像古阿兹特克人和现代占星学家所使用的那样）就是再好不过的工具了。但即便在这种情况下，我也建议你创建一个直线式的时间轴，这样你可以加上很多细节。
要做一个SAX 公司的项目时间轴，我们需要从画一个坐标系开始。而且，既然一条时间轴可以展示处于时间推移中的事物的关系，这就很容易了。从现在开始，当我们在时间轴上往右移一段距离，就意味着经过了一段时间。我们一直在SAX 公司研发软件产品，因此知道时间轴应该从何时开始，就让我们从最初的那一刻开始画这条时间轴。
在SAX 公司，每个项目都是从确定我们需要注意哪些基本问题开始的，我们称之为“发现”阶段。而且我们早就沿着这条思路一路走下来了：想办法让我们的软件产品能够更吸引杰森。
一旦我们在难题上有了较明确的认识，就可以提出可能的解决方法，我们称之为“概念设计”。此时我们就要确定将要诞生在我们手里的这个软件具有哪些方面的特性。
解决方案设计之后，我们就要开始实施了。这时我们进入的阶段是“研发”：为所有的个人软件组件和整个应用程序编写代码。
一旦全部写完，就得开始进行“测试”了。这一阶段的测试包括漏洞测试、第一轮测试、在一小群消费者中进行测试和最后在人数更多的一组消费者中进行“用户接受度”的测试。
当测试完成后，所有的漏洞和错误都得到了处理，我们就做好了销售的准备，我们称最后这步叫“发放”。这时我们会把软件打包，送到需要使用它的消费者手里。我们也在这时将应用程序传到用户支持团队那里，以便我们能够收集反馈信息，研究软件的下一个版本。
这就是我们的软件研发时间轴。它是一个简单的、高品质的、以执行为导向的、单张的图。正如SQVID告诉我们的那样，如果听众初涉软件行业，并且对这些重要步骤很感兴趣，那么我们就应该创建这样的图了。这是一个有用的开始，一旦实施起来，我们就需要更详尽的信息。把这个图看成起点，再重新画图，这次就会显示更多细化的信息了。我们从同样的时间轴开始，但目的已经和刚才不同了。
上一个时间轴没有???确地反映出时间。它展示了时间推移的过程，但没有展示这5个阶段各自需要多少时间。所以现在要做的第一件事就是把每个阶段的箭头拉长，以此来表示相应的持续时间—我们可以根据之前的经验来推算各阶段的时间。
过去的经验让我们可以较好地估计每个阶段实际所需要的时间，所以我们就可以把日程添加进去：
会有许多人共同为这个项目工作，所以我们在图的一侧列了一个项目团队的清单，可以在图中标注出它们在每个阶段各自进行的活动和工作。
现在我们设置了两个坐标，正如我们之前画的图，但这次我们在同一个区域里展示的是两类不同的信息：“谁”（团队）和“在什么时候”（时间轴）。有了这两个坐标，我们就可以开始标出“什么”。这些里程碑式的标注标志着一个阶段的结束和另一个阶段的开始。
我们怎么知道什么时候每个团队的工作进行到什么阶段呢？当然，里程碑并非真的存在，它只是在时间上预设的某些时刻。我们的项目能否成功，就得衡量一下我们实际已经做了什么—哪些事务是可以延续到下一个项目中去的。比如，一旦业务团队完成了它的“商业基础研究”，设计团队完成了“用户需求研究”，市场销售团队完成了“市场研究”，接着我们就能开始概念设计了。
这些可传送的文件内容十分重要，它们是所有重要问题的结果。不过，这些文件什么时候完成对于整个计划是非常关键的，我们也需要了解创建它们需要哪些条件。此时我们就需要加入工作流程：它们是一系列任务清单，每个团队的工作都需要照着清单来，以便知道完成这些重要文件需要依次做哪些工作。加入工作流程后，这张更详尽的时间图就完成了，我们也能随之了解这个项目会耗费多长时间。
为了做到这一点，我们会用到第一个混合框架—时间序列图。虽然我们还没看到过这样的图，但其实我们对它已经很熟悉了—它只是在一个时间图上叠加了一个“有多少”的图，这两个框架我们都很熟悉。简单地说，一个时间序列图标出了某个事物随着时间的推移在数量上的变化。为了能显示价格、比率、数字和温度等因素的升落，这个框架合并了两个基本框架的坐标系—我们可以在不同的时间点衡量同一个事物的变化。
创建一个时间序列图可以让我们清楚，和过去相比，现在完成一个完整的软件研发周期需要花费多少资金。如果需要900万美元，那么我们最好先将它与以往的花费比较一下。如果减少了，我们拿到这笔钱就相对容易；如果增多了，我们就得再为这个项目多方考虑一下。
像其他的时间轴一样，将横坐标设为时间，而将纵坐标设为数量。坐标确定后就可以加入前些年的产品研发支出了。我们可以从前些年的项目管理文件中找到这些数据。1996年，SAX 公司以“超级经管师”软件第一版向市场打出第一炮，那么我们就从这一年开始吧。第一年，创建“超级经管师”第一版用了不到50万美元，这是一个10人团队在一年内夜以继日、无数个周末加班的劳动成果。两年之后第二版的推出，花了4倍的钱，达到了200万美元。原因很简单：这个团队增至40个人，成本也就相应增加了。到了2000年，公司发布“超级经管师”第三版则花了600万美元，这个版本也使得SAX 公司成为行业的领头羊。
随后，噩运来了。2001 年底，公司的整体市场份额下滑，不得不裁员以避免负债的危险。相应的开支下降了，因为团队人员越来越少，整个公司对于发布新的版本也不再那么充满热情。
从2002年开始，研发开支随着每次软件的发布而增加。2006年推出的“超级经管师”第六版，投入的研发资金为600万美元，再次达到了2000年创下的最高纪录。按照这种趋势，我们将来的投入将会达到900万美元。
但这并不说明一切。尽管我们非常想从执行官们那里得到900万美元，并且用这张时间序列图证明投入是值得的，但我们也很清楚，他们会想知道我们还没有想到的一点：投入这些开支后怎么才能让公司的总体收支保持平衡？
为了回答这个问题，我们会再创建一个时间序列图，横坐标不变，纵坐标反映公司的总体收益，坐标的最高值从1000万美元（我们所听过的在软件发布上投入最多的资金额）变为最高收益4000万美元。我们仍然从1996年公司总体收益达到约100万美元时开始标注，4年过后，收益飙升至2100万美元。
好景不长，2001年接下来的两年里，公司的收益跌了一半以上，甚至市场复苏后我们仍然抑制不住地下滑。
2004年，收益反弹了，两年里上升到了3000万美元。然后就停在那里了：销售额平平，收益平平。这种状况让我们又回到了最初的问题，它让我们开始建立“谁/什么”的框架。
单独来看，这两张图告诉我们两件事：第一张图，显示研发支出似乎是以某种较为稳定的比例上升的；第二张图显示收益（尽管还是很高）已经开始不再往上走了。但此刻我们把两张图放到一起，想法和问题也会由此产生。为了把两张图放到一起，我们将不得不把支出图移下来，对好相应的数字。
对好相应的坐标值后，我们就可以开始同类比较了，由此可以看到与收益相比较的研发支出是怎么变化的。
我们看到执行官们对900万美元的反应了：如果4年前，在研发支出上30%的增加就能带来约300%的收益增长，而两年前30%支出增加的结果却是收益平平，那么，现在再增加30%的研发支出，如何保证让收益有所增加呢？
我们看到了需要回答的问题，现在我们就来考虑怎么回答它。
