传统项目管理，无论是典型的软件销售服务类型、还是互联网软件公司。在过程管理中，通常是从需求输入开始。这当中造成的误判范围、过度承诺、信息传递变形甚至黑洞的情况屡见不鲜。无论企业中是否有诸如PMO或是项目管理委员会这样的组织，大多数都忽视了需求并非凭空而来，从组织和成本角度上去，无论是创新类公司还是拥有成熟市场的公司，都应当把需求从售前（需求产生）之时进行度量和梳理。有一句老话“假设（需求）什么都不是，只有当它能够被证伪或证实，才有价值”，有了价值，才会有去实现的必要。
敏捷对售前(需求价值)的局限
传统的敏捷宣言，只关注了在项目过程中，团队如何保证需求价值的实现，如何交付价值。即敏捷首先假设的是这个项目（需求）的价值是存在的，依据这个价值依据，在项目过程中持续交付可评估的产品，以达到接近用户真实需求价值的目标。
我们不妨追问一下敏捷的本质是什么，敏捷宣言的核心价值告诉大家是如下四条
-
个体和互动 高于 流程和工具
-
工作的软件 高于 详尽的文档
-
客户合作 高于 合同谈判
-
响应变化 高于 遵循计划
就这四条核心价值来讲，更加贴近于软件开发中的过程管理。就真正的项目全生命周期来看，敏捷忽视了项目启动之前的价值假设过程，如果这个需求的价值假设在商业模式or成本预期or客户（运营）YY之上的，你再怎么努力敏捷也不过是多走几步还是少走几步掉坑的结局罢了。大家扪心自问一下，你所从事的敏捷项目，有多少是从开始就将商业价值和企业目标与敏捷项目结合起来进行管理的。
软件开发团队通常重视的项目的成功交付和验收，而非项目是否真正为企业（用户）创造了价值。无论是项目型公司还是互联网公司，开发团队通常在短期上对项目交付最重视，而从长期看，交付一堆没有达到预期价值甚至毫无价值的产品（功能）时，对团队的损害要远远超过尽早识别不具备价值不需要交付的危害。
那么如何将敏捷扩展到项目启动之前，进行项目全生命周期的敏捷管理呢。这个问题，目前有一个流派，就是将精益思想与敏捷相结合，将企业的价值目标与敏捷过程管理相结合，将商业价值与团队动态管理相结合，重视产品交付价值本身而非项目成功，双方共同在价值最大化的目标和框架下协同工作。通过精益思想的7项原则，很大程度上避免了敏捷对企业（用户）价值层面的假设推论确认过早的问题。
这几个原则的重要性依次如下
1、尊重人
这里的尊重人，来自于精益和敏捷思想中的核心：相信创新来自于人的主动性，而非机器。即使是在精益的发源地丰田，这个流水线的工厂内，也奉行人的主观创造力是第一生产力的观点。反观国内的互联网公司和创新工场，管理层和创业团队很少去主动将价值传递到研发团队。很多研发团队也是接到需求就开始评估怎么做，不问为什么做，也从来不问价值，就算问了，也只是要求排个优先级而已。这种对企业价值和商业本质的漠视，也导致了技术团队缺乏大局观，而只是反过来要求产品做出一个不靠谱的年度规划来预估架构上的合理性。放眼目前的商业环境，都是在不停的市场契机中发现商机，如果靠产品经理或是公司老大就能正确的判断公司未来一年的产品路线，那为什么整个中国成功的公司还就是那么几家？做正确的事，永远比正确的做事更重要。
从尊重人的角度出发，公司的管理层首先要放低姿态，承认自己也会犯错，并将商业目标和价值要求，通畅地传达到研发团队。而研发团队在面对需求时，需要多问几个为什么要做，敢于质疑价值不明确的需求。
目前在我所在的公司，推行的是对于大中型需求，需要提供《商业画布》和《价值时分表》，通过这两个文档的讨论，明确需求的价值和实现的急迫性，并从中提取需求实现后的上线跟踪指标。这两个工具来自于《精益创业》这本书。感兴趣的童鞋，可以去看看这本书，很经典。
2、消除浪费
在我们做一项商业决策时，往往是凭借过去的经验和有限的试验及数据做出的假设。这本身没有错，而往往人们犯的错误就是：忽视了验证这个假设能够承受多大的成本。合适的时间，用合适的成本去做合适的事，这也是风口上的猪也能飞那句话原本的意思。
说道理有点枯燥，举个例子吧：
我所在的公司，曾经在B2B快消品市场上，投入过一个业务员端的产品。当时这个产品是给公司内部业务员用的，在开拓外区市场时，根据市场人员的调研和相关领导的从业经验，一致觉得外部快消厂商和经销商是需要这个产品的。所以咯，二话不说，为了抢占先机，为了做那个风口上的猪。产品率先将业务员端做了改造，适配了外部经销商和厂家业务员的模式，还没等投入到市场，这个项目就因为种种原因而收缩，取消了与外部的合作。还好当初留了个心眼，只做了个简单的适配，但也耗费了一个迭代（三周）的成本。从敏捷来看，项目本身一点没有问题，但从商业价值来看，成本的浪费不言而喻。
可能大家看到这里，会有很多疑问：唉，商业价值又不是研发说了算的，领导决定的啊，运营的锅啊，产品的债啊。但回想一下，如果敏捷不能创造价值，那团队的价值如何体现？
因此，当我们在假设一个价值目标时，要遵循的是成本最小和决策推迟原则。譬如，先来遍线下先行的验证怎么样，我堆两个实习生天天收集数据在excel统计分析后，发在厂家和经销商的业务员的微信群可不可以。这样浪费的成本孰高孰低，一目了然，行不通止损也快。也不用后面我们又要考虑把这一套代码下线，避免后续还要付出维护成本要来得划算。
3、推迟决策
推迟决策并非官僚，也不是将责任推诿至他人，而是因为太多拍脑袋和屁股所做的商业决定所带来的高昂实现成本，造成了大量的浪费。而提前决策恰恰违反了第2条的“消除浪费”。
推迟决策的时间点：决策的最佳响应时间点是指，做出决策的成本跟推迟决策造成的损失大致相当的时间点。
推迟决策的实践：在敏捷中，有一个推迟决策的最佳实践：真实期权。听起来挺拗口，下面简单解释下。
期权大家都知道，而真实期权大家拆成“真实”和“期权”两部分来看，即针对项目在分阶段投入成本的情况下，我们需要有在特定条件下的对各阶段所拥有的三种投资成本的方式：一是放弃投资（即条件不成熟）；二是继续投资（即达到此阶段的约定条件）；三是重新评估未达到的条件，决定是否变更条件或减少投资规模。这些实践，有部分来自于金融期权的数学模型，有部分来源于决策心理学。归根结底，是指在决策时，需要满足事先约定的条件并了解决策所需要的原因后，再做决策。真实期权的终止日是条件性的而非契约性，你可以延后期权的终止日，直到发现最优解，从概率上来看，推迟决策要比提前决策更能提供价值。
举个例子：公司即将开始一个全新的平台引流项目，我们有一个商业目标，希望通过产品来实现日均50万的PV和>=10%的订单转化率，公司以前没有类似的经验可以借鉴，即使有人有相应的经验，在这个平台上也从未实践过。
传统意义上的项目，应该是开始商业计划书，然后PRD，然后项目实现并上线验证。在这里，就埋下了决策陷阱：一开始的目标推导出来的商业计划书中的成本产生的ROI，顶多是个估算，谁来为估算的决策埋单?我相信没有一个人是有100%的信心和承诺去做这个决策的，即使是计划做得再好，凭经验做出来的也满足不了随时变化的市场和社会环境的变化。那些商业大V给的无非是天花乱坠的计划如何做得详细分解，而这并非投资的最佳路径。
真实的世界里，我们要将决策带来的成本损失减到最少。因此，好的做法，在面对一个不可知的目标时，是将目标拆分成不同的阶段，这个项目因为未知因素太多，但又需要快速推进的话，应该是在商业计划成型之前，做一次小规模的验证，这个验证应该是针对特定的极少部分种子用户，并利用现成的最小化成本（H5工具生成的落地页、现有平台产品的简单对接）去实现，观察预定的指标，总结是否需要调整变现路径和方法，再形成完整的可推论的商业计划（BRD）并划分阶段和成本，然后才是分阶段实施的PRD和条件。有了这样一个先验过程并将阶段验证条件做为下一阶段的决策依据，才能更好的迎接在过程中不断变化的问题，并最终以最合理化的成本和收益达到项目目标（虽然项目目标可能会调整，但也是基于真实验证下的调整，而且成本并未浪费）。
因此，推迟决策并非不决策，而是在有先决条件下分阶段去实现项目目标，决定是继续按计划做，还是终止，或是变更下条件适当投入再看看。
任何一本软件工程教材都会告诉你：假设在分析阶段找到并解决一个错误的成本为1，在设计阶段解决同一个错误的成本就变成10，在实现阶段就变成100，在维护阶段就变成1000。敏捷软件开发中的真实期权实践正是为了避免不正确决策所带来的浪费。
4、创建知识
在敏捷团队中，传递知识是一项细微并且不会短期内看到收益的工作。但是一旦真正建立了一个人人愿意维护的知识库，哪怕这个知识库是存在于代码的规范性注释之上，带来的收益和价值往往随着时间的推移而越来越有价值。
这里需要说明的是，团队需要有一些激励机制和自己总结的适用方法，利用现有的知识构建工具譬如wiki、规范化代码注释、甚至是文件服务器上，将知识点先沉淀上去，再进行归纳和分类后，从而进行提取、再加工，并落实到由这些知识点产生的改良活动中，并再反馈到知识库中。
这需要领导者鼓励并长期关注知识库的质量，并激励团队做出知识贡献，打造学习的氛围。
而对于进入项目前的售前和需求分析过程，往往借助的是知识库中的两个类别的知识：项目度量、风险库。
在实际知识沉淀过程，需要特别注意这两个方面知识的总结和归纳，并交待好事件的前因后果和Action的结果。项目度量可以帮助分析和市场人员，大致的评估项目成本和周期（在乐观和悲观两个维度下）。而风险库，是在项目启动前一次最好的检验项目风险的实践活动，并且，随着知识库中风险点不断的积累和归纳，检查的清单会越来越详尽，会尽可能的让你避免拍脑袋决策所带来的失败因子。
5、快速交付
一旦决策下达，团队的快速交付就显得重要了。这个阶段其实就是一个核心"尽早、持续交付有价值的软件，是我们满足客户的最优先考虑"。这个阶段中，尤为重要的是需求分析。成功的项目各有不同，但失败的项目却总是那么相似。这当然是句无限抽象的戏说，但需求分析的偏差和模糊往往是重要的原因。回到本章的重点，快速交付在敏捷的售前阶段好像没有任何关系，但如果我们把任何一个项目阶段（售前、立项、分析、设计、实现、部署、运维）拆开来看，每个阶段其实都有交付，而且仍然可以围绕”尽早、持续交付有价值的软件“这一核心。
举个例子：
某大型证券公司，我们有多个团队为此公司进行项目开发。甲方决策人，通常希望看到有成型的可演示demo才决定是否由我们承接，这个过程在以前，会由乙方团队赶鸭子上架一样在现有框架和平台下搭一个按甲方领导意思想看的demo，往往还涉及到需要走一些简单的设计和测试工作，等花上一周甚至两周多给领导看时，还要担心会议上是否时不时报个错，会不会在会议上又提出新的想法。后来，我们经过讨论，发现人家根本不关心你这套demo后面是否有真实的数据进入系统，就是看看点击后界面的交互和跳转是否按他的想法来，demo中有没有更好的亮点或解决思路。想通之后就简单了，改用axure上吧，对于有比较复杂的逻辑和流程要求的，实在不行就用静态页面整，也比要构建一套需要持久化数据的系统快，毕竟客户只看效果才决定接下来是不是交给你做。这样我们不仅将演示周期缩短到了平均三天左右，而且反馈给客户的速度相应的大大提高，客户的满意度也上来了，会上有个什么改动，回来后调整下原型，也顶多就是半天的时间而已。
6、品质为先
敏捷强调通过测试驱动、自动化工具建立可持续化、日常化的质量检测方法。在售前工作中，我们需要避免的是销售人员为了迎合客户需求，漫天画饼却给出一个奇低的价格。
因此，在售前阶段，销售的方案和demo必须要和技术团队中的负责人过一下，并且通过知识库判断大至的成本。关于成本判断的方法，后续章节会有一篇专门介绍。
一个有说服力、逻辑严密的售前方案，对客户来说一是意味着有落地的把握，二是解答了从目标到实现的各个清晰的路径（目标、范围、业务逻辑分析、模块分析、难点分析、项目管理分析、项目预估算），三是回答了项目中确实存在的大机率风险如何避免。如果不能成，并不代表你的价格不合适，只是因为其它非商业原因而落选（你懂的）。相反，借助这些有质量的方案，当客户真的想做点有价值的事情时，一定会考虑你，所以你在后续还有大量的高价值项目可以介入。
7、全局优化
有关于精益管理的介绍，请点击我的另一篇培训文章《精益产品思想》。同时放上一个参考链接：精益的智库百科链接
CMM对售前的模糊
CMM的成熟度模型，更加偏重于项目的执行过程。与敏捷类似，都是假设有一个已立项、清晰的项目目标的前提下，如何按最佳实践去实现项目目标。
限于篇幅，我只举一些CMM中在售前遇到的局限的案例：
CMM也好，CMMI也罢。对售前的过程域，比较匹配的还是需求管理的过程域，这个过程域强调的是需求理解的一致性。
实际项目中，我们承接过一个大型集团的协同平台，在售前阶段，甲方提出了一个很宏大的规划，如果用我上面的快速交付法显示不合适了，估计要画几百页原型才能满足。这个时候，首先澄清用户的目标，和项目范围后，才能为接下来的有价值交付铺平道路。因此，接下来的一周，我们并没有提交方案，而是按照初次访谈得到的规划信息，和技术负责人一起，对甲方信息中心的关键人员做了一轮访谈，并邀请甲方参观了一些类似的客户项目。取得信任后，我们在甲方的支持和协助下，对业务部门的核心人员做了一轮访谈，再根据这些信息和访谈纪要，输入出了一份长达98页，装订成两册（一册为项目建设方案建议，一册为方案图集）的文件，影印了10份（没给电子档）交给甲方信息中心和各部门查阅，我们分别约时间在会前收集意见并反馈和修订，并在接下来的会议中通过讨论，明确了目标的范围和优先级，确定了各个阶段的里程碑和输入条件后，以第一阶段为重点，才开始制作demo和原型。这个项目最终的招标技术部分，实际上就是按我们提供的项目建议方案书来的，甲方也非常信任我们前期做的详细分析确实能落地，并且也看到了部分核心功能的原型，感觉非常靠谱，在投标评审中，倾向性给我们打了最高分（没有任何猫腻），其它公司倒不是不努力，不过大多是凭过往经验，x软甚至copy了一份在其它集团投标的技术标文件，很多地方完全不符合甲方的实际业务场景。从这个故事中，不难看出，我们即使在售前，对需求的澄清是相当慎重的，通过合理的成本付出（方案建议->原型）给用户不断提供分阶段的价值输出，明确项目范围，落实项目的可行性，从而为后续项目的开展提供了良好的可落地基础
项目能否成功取决于售前/商业计划
传统软件管理重视开发过程管理，而一旦开始立项，成本会直线上升。企业的成本永远是有限的，如何避免在大规模投入之前，先小规模验证一遍是否可行，分期投入，按阶段决策。在目前的创新创业大潮中就显得尤为重要。
一家企业的初创资金总是有限的，好比一条100米长的跑道，中间没有任何标识，而且跑道上布满了商业和市场的一切不确定的因素（竞争迷雾）。每跨一步，很多人认为就离目标近一步，实际上就算方向对了，中间有没有路障，裁判会不会吹黑哨，路上有没有石头和陷阱，这一切都是未知的，你跑得越快可能摔得越重，也可能当你冲刺跑完用尽力气（资金）时才发现偏了那么几米错过了终点线。
所以试错，还得加一句，在最小成本下去试错。推迟你的投资决策，只到条件显现足够你去决策时再做。想要赢，先得活。
往前推是过程管理的精髓
其实，项目管理的精髓无外乎就一条，将过程中的活动尽量向前推，不光是开发、测试、集成、维护，甚至包括了我们都忽略了但其实决定了成败的售前/商业计划。把活动往前推，小规模的利用原型、自动化工具、测试驱动等一切方法去验证，拿到的验证条件越早越好，这样才能避免在后续的项目过程中由屁股决定脑袋、凭经验臆测的决定，开发完成后才发现行不通而等待转向或衰落要好。
从概率上讲，将错误越早暴露，成本越低。而决策尽量在条件显现时决定，项目成功性更大。