项目中的经济学（二）：时间的价值
经济课老师经常语重心长的对我们说：你们学习经济学之后，要尝试着对一些现实问题进行分析，能够对事物建立多角度的看法。上回《项目中的经济学（一）》我们聊了机会成本的问题，这次我们聊一聊时间问题。
时间紧迫是大家工作中最常见，也最常被折磨的问题之一。几乎没有见过哪个项目是时间完全充足的，反之我们经常会听到：
“今晚就要”
“下班前能做出来吗”
“明天提测”
···
等催促的话，如同沉重的大山一样压在我们的肩上。为了缓解压力，不但要有沉稳而强大的内心、良好的沟通能力、扎实的技术功底，我们最好还能掌握一些经济学方法论。一方面能够对时间建立客观合理的认识，另一方面也能利用这些方法与同事进行更有效的沟通。“时间价值”理论，就是解决时间问题的一种有效尝试。
什么叫“时间价值”
金融行业中有一句话叫做“今天的一块钱不等于明天的一块钱”，说的就是货币是有时间价值的。这个概念在商品经济中客观存在，如金钱可以存入银行以获得利息、可以运用于公司的经营活动以获得利润、可以用于投资以获得投资收益等。货币经历一定时间的投资和再投资能够增加价值，以利息、利润和投资收益等形式来表现。
项目和货币虽然不是同种属性的事物，但项目同样也有时间价值，存在以下三种特征：
项目本身有初始价值
项目运行过程会耗费时间
初始价值会产生更多价值
一般项目的目的，无非是耗费最短的时间来实现最多的增值。我们通过一个案例，来说明项目是如何依靠时间价值理论来实现流程改善的。
一个真实的案例
2016年初，部门正在紧锣密鼓地进行互联网转型重要载体App的第一个版本的研发工作。因为存在团队刚刚组建、bug不断出现、需求方向经常调整、开发设计资源极其紧张、部门间隔阂等的原因，我们连续经历了两次失败的尝试。后来总结出来两个最让我们受伤的问题：
人员配备上，产品和交互人员都是本公司的，而UI设计、开发都是外包的。外包人员存在工作能力差距，这给项目带来很多不确定性。更让人头疼的是不论能力强还是弱都不是最合适的，能力强的我们要提防产品核心思路和代码泄露，能力弱的又很耽误研发进度甚至犯下低级错误，曾经就出现测试服务器地址打到生产包上的重大事故；
业务和IT系统配合过程中，我们经常遇到让人崩溃的坑。有时候刚刚调试平稳，突然冒出来一个特别棘手的问题，导致项目进度受阻，需求重新梳理，甚至重新开发；
在这个案例中，假设人员、业务、IT系统等固有缺陷在短时间内是无法解决的，那应该如何进行改善呢？答案就是，迭代开发、小步快跑——互联网圈常见的一种方法。
结合经济学的知识，我们引入一个公式：
最终值=基础值+迭代提升值
在这个公式中，等式左边的最终值就是项目最终完成的状态，它等于基础值和迭代提升值之和。基础值是目前的现状，迭代提升值是针对基础值的提升，即迭代提升值=基础值x迭代提升率，所以把等式改为：
最终值=基础值x（1+迭代提升率）
而迭代提升率是跟迭代次数和单次迭代提升率有关的，即迭代提升率=迭代次数x单次迭代提升率。可推算出：
最终值=基础值x（1+迭代次数x单次迭代提升率）
而迭代次数=总时间/单次迭代时间，把这个表达式代入等式，得到最终公式：
这样就把公式分解为最终值、基础值、总时间、单次迭代时间、单次迭代提升率这些具体参数。
一般情况下，项目的基础值、总时间是固定的，为了提高最终值，我们可以从另外两个变量来着手：降低单次迭代时间，或者提高单次迭代提升率。
1.降低单次迭代时间
在等式其他变量不变的情况下，因为单次迭代时间是分母，所以减小单次迭代时间能提高最终值。
在本项目中，针对前面提到的两个问题，产品总监提出了一条名为“踢皮球”的要求：每个人都把手头的工作以最快的速度处理完毕，然后转给下一个流程。此“提皮球”不是指常规意义上的把责任踢给别人，而是高效的将工作成果输出。具体来说：
T日，产品经理们把需求以最简单和方便的形式表现出来，然后“踢”给交互设计师；
T+1日，交互设计师以最快的速度完成交互初稿，然后“踢”回给产品组，当天即进行评审，交互修改方案；
T+1/2日，交互和产品组把方案“踢”给UI设计师和研发人员，立即开始进行任务拆分；
后面的研发、测试流程也类似。
整个过程要求每个阶段迅速通过，一旦闷在某个阶段，时间一旦超过某个上限则迅速上报给项目组进行集中解决。项目组按日跟踪和汇报进度情况。为了保证整体进度，有时候某个流程甚至只完成70%的完美程度即可以“踢”给下个流程，剩下的30%留待后续处理，当然这样做是对大局不造成太大影响的基础上。
这种“踢皮球”的方法，对于解决项目开始时的混乱状况是非常有效的。需求和交互迅速传递给外包人员，可以很好的解决大家对项目进度的认知不统一问题，加快工作节奏。同时，能够让无法预知的坑早点充分暴露，利于协调时间去寻求解决方案。
2.提高单次迭代提升率
在等式其他变量不变的情况下，提高单次迭代提升率能提高最终值。
对于团队来说，成员工作能力的提高都有个过程，不是短期能够突破的。这就需要通过一些制度的建立来保证迭代的顺利进行，同时制度也能反过来推动个人工作能力的提高。
为了提高单次迭代提升率，团队引入敏捷式开发制度，其中的一项就是任务拆分。任务拆分是个非常耗费心神的工作，但能起到非常有效的作用。交互和产品组把方案“踢”给UI设计师和研发人员后，马上召集研发人员开会进行任务拆分。
拆分工作是个落实到细节的工作，按照从大到小、从主到次、从整体到局部的顺序，把每一个需求、每一个bug、每一个改进点进行深入拆解，直至拆解到大家认可的局部细节。然后针对每个细节，都配备对应的人员、设定完成时间、预估完成结果、讨论完成方案，并每日汇报进度情况。这种深入到细节来逐条解决的方法，让单次迭代的质量有了显著提升。
最终，通过努力改进工作流程、提升工作质量，从3月份项目启动，部门以突破常理的速度，从无到有只花了不到3个月的时间，就完成了一款全新App的上线，在公司内外高压下证明了自己。
在上面的案例中，经济学给我们提供了一个从另外的视角看问题的思路。如果我们再深入思考一下，其实最终值计算公式，在等式两边任意参数已知的条件下，可以计算出未知参数。比如，如果已知的参数为最终值、基础值、单次迭代时间、单次迭代质量，就可以分析出总时间这个参数。
另外，在很多团队中，有人喜欢采用诸如强行Push、拍桌子、找领导推动，甚至跪地、画大饼、异性混搭等方法，这些方法的有效性值得怀疑，并且前者会造成同事关系紧张，后者会降低自己的身价。革命不是请客吃饭，大家都是为了同一个目标去工作，立足于正确的方法论，找出共同利益点、进行平等善意的沟通，应该是更优的选择吧。
