项目管理中存在设么样的经济学理论？作者从这个角度切入与你分享。
互联网行业工作几年，发现一个现象：不论大公司小公司，不论是设计狮、产品汪、运营喵、程序猿，平时可能都在默默的钻研自己的岗位，但一到周末或者假期，我的朋友圈就被他们各种积极向上、欣欣向荣的学习活动所霸占。
有参加行业会议的、有参加培训的、有读MBA的、有上辅导课的、有在家网络自学的···这些人也许就是你工位旁边正在偷偷玩农药的小张、到点去接孩子的老王、每天独来独往的单身狗大强。尤其身边一些看着普通、实际上碉堡的人经常让我佩服至极。
在这些人的感召下，我也简单的学了一点经济领域的知识，只因处于金融中心上海，学经济拥有着种种便利。另外听别人说经济学从更本质的角度看世界，而且不要求本身的专业，任何学科都能从中汲取养分。
从本文开始，跟随金融学习的进度，开始整理学习收获的心得，和大家一起交流。同时鞭策自己不断学习和思考。
工作中，不论我们是从事什么工作岗位，取舍是我们常常需要面对的情况。举个例子：
如图所示，上线了某个要求用户进行设置的新功能，针对如何引导用户，存在A、B两种解决方案：
A方案是在刚进入产品时，先弹出全覆盖弹层，先让用户进行设置，然后再允许用户使用；B方案是默认进行某种设置，但是允许用户立即进行更改。
对于上述案例，我们要付出两种类型的成本：第一种成本是项目需要花费的时间、投入的资本、人员的薪水、竞品的状况等，这些内容其实不作为必须考虑的成本，因为不论执行A、B哪一种方案，都需要付出这些成本。从经济学的角度，我们假设A、B两种方案的时间、资本、薪水、竞品这些成本都是是常数（因子），通过这类成本花费的比较是无法判断哪个方案更优秀的。
那如何比较A、B方案的真实成本呢，这时候需要引入另外一个概念：
机会成本（Opportunity Cost）：为了得到某种东西所必须放弃的东西。
A方案的机会成本，其实是必须要放弃的B方案，当然反过来说，B方案的机会成本也是必须要放弃的A方案。如果选择A方案，那么用户必须自己去做出选择。如果用户面对的是比较专业、比较冷门的概念（这种概念在金融领域常常见到），这对于小白用户来说是极为不友好的。用户只好要么为了搞懂概念另外去学习，要么直接离开这个功能。即使用户被迫弄懂概念并做出选择，也未必是他们想要的。而且更没有提供给用户方便的修正和调整的工具。
反过来分析，如果使用了B方案，看似失去了选择的机会，但实际上用户选哪一个都没有绝对的对与错，选任意一个都不会对使用造成太大影响，无非是需要一定时间的习惯。另外，选择任意方案都可能让用户习惯固定下来，以后再也不会进行设置。
比较起来，显而易见强迫用户对于他们不熟悉的、过分专业的领域来进行抉择，对产品体验带来更加严重的影响，机会成本更高。
虽然经济学中常见的比较对象一般都是成对的，但是在上面的案例中，不论采用A或者B方案都达不到最佳效果，这时候会引发思考：也许真正的解决方案既不是A也不是B，而是还有更优的解决方案，比如C、D、E方案。
如果当时决定采用A方案，那采取这个行为的机会成本就是B、C、D、E方案的可取之处。从这个角度分析会让大家都紧张起来，采用任何方案的机会成本都是很高的。由此大家就会更少一点拍脑袋决定的行为。
项目中的经济学（二）：时间的价值
经济课老师经常语重心长的对我们说：你们学习经济学之后，要尝试着对一些现实问题进行分析，能够对事物建立多角度的看法。上回《项目中的经济学（一）》我们聊了机会成本的问题，这次我们聊一聊时间问题。
时间紧迫是大家工作中最常见，也最常被折磨的问题之一。几乎没有见过哪个项目是时间完全充足的，反之我们经常会听到：
“今晚就要”
“下班前能做出来吗”
“明天提测”
···
等催促的话，如同沉重的大山一样压在我们的肩上。为了缓解压力，不但要有沉稳而强大的内心、良好的沟通能力、扎实的技术功底，我们最好还能掌握一些经济学方法论。一方面能够对时间建立客观合理的认识，另一方面也能利用这些方法与同事进行更有效的沟通。“时间价值”理论，就是解决时间问题的一种有效尝试。
金融行业中有一句话叫做“今天的一块钱不等于明天的一块钱”，说的就是货币是有时间价值的。这个概念在商品经济中客观存在，如金钱可以存入银行以获得利息、可以运用于公司的经营活动以获得利润、可以用于投资以获得投资收益等。货币经历一定时间的投资和再投资能够增加价值，以利息、利润和投资收益等形式来表现。
项目和货币虽然不是同种属性的事物，但项目同样也有时间价值，存在以下三种特征：
一般项目的目的，无非是耗费最短的时间来实现最多的增值。我们通过一个案例，来说明项目是如何依靠时间价值理论来实现流程改善的。
2016年初，部门正在紧锣密鼓地进行互联网转型重要载体App的第一个版本的研发工作。因为存在团队刚刚组建、bug不断出现、需求方向经常调整、开发设计资源极其紧张、部门间隔阂等的原因，我们连续经历了两次失败的尝试。后来总结出来两个最让我们受伤的问题：
在这个案例中，假设人员、业务、IT系统等固有缺陷在短时间内是无法解决的，那应该如何进行改善呢？答案就是，迭代开发、小步快跑——互联网圈常见的一种方法。
结合经济学的知识，我们引入一个公式：
最终值=基础值+迭代提升值
在这个公式中，等式左边的最终值就是项目最终完成的状态，它等于基础值和迭代提升值之和。基础值是目前的现状，迭代提升值是针对基础值的提升，即迭代提升值=基础值x迭代提升率，所以把等式改为：
最终值=基础值x（1+迭代提升率）
而迭代提升率是跟迭代次数和单次迭代提升率有关的，即迭代提升率=迭代次数x单次迭代提升率。可推算出：
最终值=基础值x（1+迭代次数x单次迭代提升率）
而迭代次数=总时间/单次迭代时间，把这个表达式代入等式，得到最终公式：
这样就把公式分解为最终值、基础值、总时间、单次迭代时间、单次迭代提升率这些具体参数。
一般情况下，项目的基础值、总时间是固定的，为了提高最终值，我们可以从另外两个变量来着手：降低单次迭代时间，或者提高单次迭代提升率。
在等式其他变量不变的情况下，因为单次迭代时间是分母，所以减小单次迭代时间能提高最终值。
在本项目中，针对前面提到的两个问题，产品总监提出了一条名为“踢皮球”的要求：每个人都把手头的工作以最快的速度处理完毕，然后转给下一个流程。此“提皮球”不是指常规意义上的把责任踢给别人，而是高效的将工作成果输出。具体来说：
整个过程要求每个阶段迅速通过，一旦闷在某个阶段，时间一旦超过某个上限则迅速上报给项目组进行集中解决。项目组按日跟踪和汇报进度情况。为了保证整体进度，有时候某个流程甚至只完成70%的完美程度即可以“踢”给下个流程，剩下的30%留待后续处理，当然这样做是对大局不造成太大影响的基础上。
这种“踢皮球”的方法，对于解决项目开始时的混乱状况是非常有效的。需求和交互迅速传递给外包人员，可以很好的解决大家对项目进度的认知不统一问题，加快工作节奏。同时，能够让无法预知的坑早点充分暴露，利于协调时间去寻求解决方案。
在等式其他变量不变的情况下，提高单次迭代提升率能提高最终值。
对于团队来说，成员工作能力的提高都有个过程，不是短期能够突破的。这就需要通过一些制度的建立来保证迭代的顺利进行，同时制度也能反过来推动个人工作能力的提高。
为了提高单次迭代提升率，团队引入敏捷式开发制度，其中的一项就是任务拆分。任务拆分是个非常耗费心神的工作，但能起到非常有效的作用。交互和产品组把方案“踢”给UI设计师和研发人员后，马上召集研发人员开会进行任务拆分。
拆分工作是个落实到细节的工作，按照从大到小、从主到次、从整体到局部的顺序，把每一个需求、每一个bug、每一个改进点进行深入拆解，直至拆解到大家认可的局部细节。然后针对每个细节，都配备对应的人员、设定完成时间、预估完成结果、讨论完成方案，并每日汇报进度情况。这种深入到细节来逐条解决的方法，让单次迭代的质量有了显著提升。
最终，通过努力改进工作流程、提升工作质量，从3月份项目启动，部门以突破常理的速度，从无到有只花了不到3个月的时间，就完成了一款全新App的上线，在公司内外高压下证明了自己。
在上面的案例中，经济学给我们提供了一个从另外的视角看问题的思路。如果我们再深入思考一下，其实最终值计算公式，在等式两边任意参数已知的条件下，可以计算出未知参数。比如，如果已知的参数为最终值、基础值、单次迭代时间、单次迭代质量，就可以分析出总时间这个参数。
另外，在很多团队中，有人喜欢采用诸如强行Push、拍桌子、找领导推动，甚至跪地、画大饼、异性混搭等方法，这些方法的有效性值得怀疑，并且前者会造成同事关系紧张，后者会降低自己的身价。革命不是请客吃饭，大家都是为了同一个目标去工作，立足于正确的方法论，找出共同利益点、进行平等善意的沟通，应该是更优的选择吧。
联系客服
