很是道-中小软件公司项目管理（4.1 项目启动并不是项目的起点）

传统项目管理，不管是典型的软件销售服务类型、仍是互联网软件公司。在过程管理中，一般是从需求输入开始。这当中形成的误判范围、过分承诺、信息传递变形甚至黑洞的状况家常便饭。不管企业中是否有诸如PMO或是项目管理委员会这样的组织，大多数都忽视了需求并不是凭空而来，从组织和成本角度上去，不管是创新类公司仍是拥有成熟市场的公司，都应当把需求从售前（需求产生）之时进行度量和梳理。有一句老话“假设（需求）什么都不是，只有当它可以被证伪或证明，才有价值”，有了价值，才会有去实现的必要。

敏捷对售前(需求价值)的局限

传统的敏捷宣言，只关注了在项目过程当中，团队如何保证需求价值的实现，如何交付价值。即敏捷首先假设的是这个项目（需求）的价值是存在的，依据这个价值依据，在项目过程当中持续交付可评估的产品，以达到接近用户真实需求价值的目标。

咱们不妨追问一下敏捷的本质是什么，敏捷宣言的核心价值告诉你们是以下四条

• 个体和互动  高于  流程和工具
• 工做的软件  高于  详尽的文档
• 客户合做      高于  合同谈判
• 响应变化     高于  遵循计划

就这四条核心价值来说，更加贴近于软件开发中的过程管理。就真正的项目全生命周期来看，敏捷忽视了项目启动以前的价值假设过程，若是这个需求的价值假设在商业模式or成本预期or客户（运营）YY之上的，你再怎么努力敏捷也不过是多走几步仍是少走几步掉坑的结局罢了。你们扪心自问一下，你所从事的敏捷项目，有多少是从开始就将商业价值和企业目标与敏捷项目结合起来进行管理的。

软件开发团队一般重视的项目的成功交付和验收，而非项目是否真正为企业（用户）创造了价值。不管是项目型公司仍是互联网公司，开发团队一般在短时间上对项目交付最重视，而从长期看，交付一堆没有达到预期价值甚至毫无价值的产品（功能）时，对团队的损害要远远超过尽早识别不具有价值不须要交付的危害。

那么如何将敏捷扩展到项目启动以前，进行项目全生命周期的敏捷管理呢。这个问题，目前有一个流派，就是将精益思想与敏捷相结合，将企业的价值目标与敏捷过程管理相结合，将商业价值与团队动态管理相结合，重视产品交付价值自己而非项目成功，双方共同在价值最大化的目标和框架下协同工做。经过精益思想的7项原则，很大程度上避免了敏捷对企业（用户）价值层面的假设推论确认过早的问题。

这几个原则的重要性依次以下

一、尊重人

这里的尊重人，来自于精益和敏捷思想中的核心：相信创新来自于人的主动性，而非机器。即便是在精益的发源地丰田，这个流水线的工厂内，也奉行人的主观创造力是第一辈子产力的观点。反观国内的互联网公司和创新工场，管理层和创业团队不多去主动将价值传递到研发团队。不少研发团队也是接到需求就开始评估怎么作，不问为何作，也历来不问价值，就算问了，也只是要求排个优先级而已。这种对企业价值和商业本质的漠视，也致使了技术团队缺少大局观，而只是反过来要求产品作出一个不靠谱的年度规划来预估架构上的合理性。放眼目前的商业环境，都是在不停的市场契机中发现商机，若是靠产品经理或是公司老大就能正确的判断公司将来一年的产品路线，那为何整个中国成功的公司还就是那么几家？作正确的事，永远比正确的作事更重要。

从尊重人的角度出发，公司的管理层首先要放低姿态，认可本身也会犯错，并将商业目标和价值要求，通畅地传达到研发团队。而研发团队在面对需求时，须要多问几个为何要作，勇于质疑价值不明确的需求。

目前在我所在的公司，推行的是对于大中型需求，须要提供《商业画布》和《价值时分表》，经过这两个文档的讨论，明确需求的价值和实现的急迫性，并从中提取需求实现后的上线跟踪指标。这两个工具来自于《精益创业》这本书。感兴趣的童鞋，能够去看看这本书，很经典。

二、消除浪费

在咱们作一项商业决策时，每每是凭借过去的经验和有限的试验及数据作出的假设。这自己没有错，而每每人们犯的错误就是：忽视了验证这个假设可以承受多大的成本。合适的时间，用合适的成本去作合适的事，这也是风口上的猪也能飞那句话本来的意思。

说道理有点枯燥，举个例子吧：

我所在的公司，曾经在B2B快消品市场上，投入过一个业务员端的产品。当时这个产品是给公司内部业务员用的，在开拓外区市场时，根据市场人员的调研和相关领导的从业经验，一致以为外部快消厂商和经销商是须要这个产品的。因此咯，二话不说，为了抢占先机，为了作那个风口上的猪。产品率先将业务员端作了改造，适配了外部经销商和厂家业务员的模式，还没等投入到市场，这个项目就由于种种缘由而收缩，取消了与外部的合做。还好当初留了个心眼，只作了个简单的适配，但也耗费了一个迭代（三周）的成本。从敏捷来看，项目自己一点没有问题，但从商业价值来看，成本的浪费不言而喻。

可能你们看到这里，会有不少疑问：唉，商业价值又不是研发说了算的，领导决定的啊，运营的锅啊，产品的债啊。但回想一下，若是敏捷不能创造价值，那团队的价值如何体现？

所以，当咱们在假设一个价值目标时，要遵循的是成本最小和决策推迟原则。譬如，先来遍线下先行的验证怎么样，我堆两个实习生每天收集数据在excel统计分析后，发在厂家和经销商的业务员的微信群可不能够。这样浪费的成本孰高孰低，一目了然，行不通止损也快。也不用后面咱们又要考虑把这一套代码下线，避免后续还要付出维护成本要来得划算。

三、推迟决策

推迟决策并不是官僚，也不是将责任推诿至他人，而是由于太多拍脑壳和屁股所作的商业决定所带来的高昂实现成本，形成了大量的浪费。而提早决策偏偏违反了第2条的“消除浪费”。

推迟决策的时间点：决策的最佳响应时间点是指，作出决策的成本跟推迟决策形成的损失大体至关的时间点。

推迟决策的实践：在敏捷中，有一个推迟决策的最佳实践：真实期权。听起来挺拗口，下面简单解释下。

期权你们都知道，而真实期权你们拆成“真实”和“期权”两部分来看，即针对项目在分阶段投入成本的状况下，咱们须要有在特定条件下的对各阶段所拥有的三种投资成本的方式：一是放弃投资（即条件不成熟）；二是继续投资（即达到此阶段的约定条件）；三是从新评估未达到的条件，决定是否变动条件或减小投资规模。这些实践，有部分来自于金融期权的数学模型，有部分来源于决策心理学。归根结底，是指在决策时，须要知足事先约定的条件并了解决策所须要的缘由后，再作决策。真实期权的终止日是条件性的而非契约性，你能够延后期权的终止日，直到发现最优解，从几率上来看，推迟决策要比提早决策更能提供价值。

举个例子：公司即将开始一个全新的平台引流项目，咱们有一个商业目标，但愿经过产品来实现日均50万的PV和>=10%的订单转化率，公司之前没有相似的经验能够借鉴，即便有人有相应的经验，在这个平台上也从未实践过。

传统意义上的项目，应该是开始商业计划书，而后PRD，而后项目实现并上线验证。在这里，就埋下了决策陷阱：一开始的目标推导出来的商业计划书中的成本产生的ROI，顶可能是个估算，谁来为估算的决策埋单?我相信没有一我的是有100%的信心和承诺去作这个决策的，即便是计划作得再好，凭经验作出来的也知足不了随时变化的市场和社会环境的变化。那些商业大V给的无非是天花乱坠的计划如何作得详细分解，而这并不是投资的最佳路径。

真实的世界里，咱们要将决策带来的成本损失减到最少。所以，好的作法，在面对一个不可知的目标时，是将目标拆分红不一样的阶段，这个项目由于未知因素太多，但又须要快速推动的话，应该是在商业计划成型以前，作一次小规模的验证，这个验证应该是针对特定的极少部分种子用户，并利用现成的最小化成本（H5工具生成的落地页、现有平台产品的简单对接）去实现，观察预约的指标，总结是否须要调整变现路径和方法，再造成完整的可推论的商业计划（BRD）并划分阶段和成本，而后才是分阶段实施的PRD和条件。有了这样一个先验过程并将阶段验证条件作为下一阶段的决策依据，才能更好的迎接在过程当中不断变化的问题，并最终以最合理化的成本和收益达到项目目标（虽然项目目标可能会调整，但也是基于真实验证下的调整，并且成本并未浪费）。

所以，推迟决策并不是不决策，而是在有先决条件下分阶段去实现项目目标，决定是继续按计划作，仍是终止，或是变动下条件适当投入再看看。

任何一本软件工程教材都会告诉你：假设在分析阶段找到并解决一个错误的成本为1，在设计阶段解决同一个错误的成本就变成10，在实现阶段就变成100，在维护阶段就变成1000。敏捷软件开发中的真实期权实践正是为了不不正确决策所带来的浪费。

四、建立知识

在敏捷团队中，传递知识是一项细微而且不会短时间内看到收益的工做。可是一旦真正创建了一我的人愿意维护的知识库，哪怕这个知识库是存在于代码的规范性注释之上，带来的收益和价值每每随着时间的推移而愈来愈有价值。

这里须要说明的是，团队须要有一些激励机制和本身总结的适用方法，利用现有的知识构建工具譬如wiki、规范化代码注释、甚至是文件服务器上，将知识点先沉淀上去，再进行概括和分类后，从而进行提取、再加工，并落实到由这些知识点产生的改良活动中，并再反馈到知识库中。

这须要领导者鼓励并长期关注知识库的质量，并激励团队作出知识贡献，打造学习的氛围。

而对于进入项目前的售前和需求分析过程，每每借助的是知识库中的两个类别的知识：项目度量、风险库。

在实际知识沉淀过程，须要特别注意这两个方面知识的总结和概括，并交待好事件的来龙去脉和Action的结果。项目度量能够帮助分析和市场人员，大体的评估项目成本和周期（在乐观和悲观两个维度下）。而风险库，是在项目启动前一次最好的检验项目风险的实践活动，而且，随着知识库中风险点不断的积累和概括，检查的清单会愈来愈详尽，会尽量的让你避免拍脑壳决策所带来的失败因子。

五、快速交付

一旦决策下达，团队的快速交付就显得重要了。这个阶段其实就是一个核心"尽早、持续交付有价值的软件，是咱们知足客户的最优先考虑"。这个阶段中，尤其重要的是需求分析。成功的项目各有不一样，但失败的项目却老是那么类似。这固然是句无限抽象的戏说，但需求分析的误差和模糊每每是重要的缘由。回到本章的重点，快速交付在敏捷的售前阶段好像没有任何关系，但若是咱们把任何一个项目阶段（售前、立项、分析、设计、实现、部署、运维）拆开来看，每一个阶段其实都有交付，并且仍然能够围绕”尽早、持续交付有价值的软件“这一核心。

举个例子：

某大型证券公司，咱们有多个团队为此公司进行项目开发。甲方决策人，一般但愿看到有成型的可演示demo才决定是否由咱们承接，这个过程在之前，会由乙方团队赶鸭子上架同样在现有框架和平台下搭一个按甲方领导意思想看的demo，每每还涉及到须要走一些简单的设计和测试工做，等花上一周甚至两周多给领导看时，还要担忧会议上是否时不时报个错，会不会在会议上又提出新的想法。后来，咱们通过讨论，发现人家根本不关心你这套demo后面是否有真实的数据进入系统，就是看看点击后界面的交互和跳转是否按他的想法来，demo中有没有更好的亮点或解决思路。想通以后就简单了，改用axure上吧，对于有比较复杂的逻辑和流程要求的，实在不行就用静态页面整，也比要构建一套须要持久化数据的系统快，毕竟客户只看效果才决定接下来是否是交给你作。这样咱们不只将演示周期缩短到了平均三天左右，并且反馈给客户的速度相应的大大提升，客户的满意度也上来了，会上有个什么改动，回来后调整下原型，也顶多就是半天的时间而已。

六、品质为先

敏捷强调经过测试驱动、自动化工具创建可持续化、平常化的质量检测方法。在售前工做中，咱们须要避免的是销售人员为了迎合客户需求，漫天画饼却给出一个奇低的价格。

所以，在售前阶段，销售的方案和demo必需要和技术团队中的负责人过一下，而且经过知识库判断大至的成本。关于成本判断的方法，后续章节会有一篇专门介绍。

一个有说服力、逻辑严密的售前方案，对客户来讲一是意味着有落地的把握，二是解答了从目标到实现的各个清晰的路径（目标、范围、业务逻辑分析、模块分析、难点分析、项目管理分析、项目预估算），三是回答了项目中确实存在的大机率风险如何避免。若是不能成，并不表明你的价格不合适，只是由于其它非商业缘由而落选（你懂的）。相反，借助这些有质量的方案，当客户真的想作点有价值的事情时，必定会考虑你，因此你在后续还有大量的高价值项目能够介入。

 

七、全局优化

有关于精益管理的介绍，请点击个人另外一篇培训文章《精益产品思想》。同时放上一个参考连接：精益的智库百科连接

 

CMM对售前的模糊

CMM的成熟度模型，更加偏重于项目的执行过程。与敏捷相似，都是假设有一个已立项、清晰的项目目标的前提下，如何按最佳实践去实现项目目标。

限于篇幅，我只举一些CMM中在售前遇到的局限的案例：

CMM也好，CMMI也罢。对售前的过程域，比较匹配的仍是需求管理的过程域，这个过程域强调的是需求理解的一致性。

实际项目中，咱们承接过一个大型集团的协同平台，在售前阶段，甲方提出了一个很宏大的规划，若是用我上面的快速交付法显示不合适了，估计要画几百页原型才能知足。这个时候，首先澄清用户的目标，和项目范围后，才能为接下来的有价值交付铺平道路。所以，接下来的一周，咱们并无提交方案，而是按照初次访谈获得的规划信息，和技术负责人一块儿，对甲方信息中心的关键人员作了一轮访谈，并邀请甲方参观了一些相似的客户项目。取得信任后，咱们在甲方的支持和协助下，对业务部门的核心人员作了一轮访谈，再根据这些信息和访谈纪要，输入出了一份长达98页，装订成两册（一册为项目建设方案建议，一册为方案图集）的文件，影印了10份（没给电子档）交给甲方信息中心和各部门查阅，咱们分别约时间在会前收集意见并反馈和修订，并在接下来的会议中经过讨论，明确了目标的范围和优先级，肯定了各个阶段的里程碑和输入条件后，以第一阶段为重点，才开始制做demo和原型。这个项目最终的招标技术部分，实际上就是按咱们提供的项目建议方案书来的，甲方也很是信任咱们前期作的详细分析确实能落地，而且也看到了部分核心功能的原型，感受很是靠谱，在投标评审中，倾向性给咱们打了最高分（没有任何猫腻），其它公司倒不是不努力，不过大可能是凭过往经验，x软甚至copy了一份在其它集团投标的技术标文件，不少地方彻底不符合甲方的实际业务场景。从这个故事中，不难看出，咱们即便在售前，对需求的澄清是至关慎重的，经过合理的成本付出（方案建议->原型）给用户不断提供分阶段的价值输出，明确项目范围，落实项目的可行性，从而为后续项目的开展提供了良好的可落地基础

项目可否成功取决于售前/商业计划

传统软件管理重视开发过程管理，而一旦开始立项，成本会直线上升。企业的成本永远是有限的，如何避免在大规模投入以前，先小规模验证一遍是否可行，分期投入，按阶段决策。在目前的创新创业大潮中就显得尤其重要。

一家企业的初创资金老是有限的，比如一条100米长的跑道，中间没有任何标识，并且跑道上布满了商业和市场的一切不肯定的因素（竞争迷雾）。每跨一步，不少人认为就离目标近一步，实际上就算方向对了，中间有没有路障，裁判会不会吹黑哨，路上有没有石头和陷阱，这一切都是未知的，你跑得越快可能摔得越重，也可能当你冲刺跑完用尽力气（资金）时才发现偏了那么几米错过了终点线。

因此试错，还得加一句，在最小成本下去试错。推迟你的投资决策，只到条件显现足够你去决策时再作。想要赢，先得活。

往前推是过程管理的精髓

其实，项目管理的精髓无外乎就一条，将过程当中的活动尽可能向前推，不光是开发、测试、集成、维护，甚至包括了咱们都忽略了但其实决定了成败的售前/商业计划。把活动往前推，小规模的利用原型、自动化工具、测试驱动等一切方法去验证，拿到的验证条件越早越好，这样才能避免在后续的项目过程当中由屁股决定脑壳、凭经验臆测的决定，开发完成后才发现行不通而等待转向或衰落要好。

从几率上讲，将错误越早暴露，成本越低。而决策尽可能在条件显现时决定，项目成功性更大。