敏捷开发绩效管理之111.docx
《敏捷开发绩效管理之111.docx》由会员分享，可在线阅读，更多相关《敏捷开发绩效管理之111.docx（24页珍藏版）》请在冰豆网上搜索。
敏捷开发绩效管理之111
敏捷开发绩效管理之一：
序言及“敏捷开发是否考核个人”（绩效考核）
“敏捷开发绩效管理”本身是个伪命题，因为敏捷开发本身不想涉及绩效管理，这就像“C++绩效管理”的搭配差不多。
但是人们选择敏捷开发作为管理方法是有原因的：
更高的交付保障，更高的生产率，更高的质量……这和人们选择C++（而不是C）的原因还是很接近的：
都是为了更高的绩效。
在下面的所有文章中，“敏捷开发绩效管理”都将不再是“敏捷开发中如何做绩效管理”，而是“如何利用敏捷开发提高绩效”。
何为绩效管理
绩效管理常常被片面理解为绩效考核，即如何确定个人的绩效，如何提工资和发奖金的问题。
实际上绩效管理还包含制定绩效目标，制定绩效计划，制定配套的制度推动绩效等等，当然也包括最后的绩效考核，以最终达到绩效持续提升的目的。
上述内容在本系列中都有考虑，并根据笔者以往的经验和经历给出一些实际的案例供研讨使用。
从一个经典问题看绩效管理的出发点
绩效管理不是敏捷开发的要求——如果能理解敏捷开发也不是瀑布模型的要求，敏捷开发爱好者们或许就会释然了——绩效管理是企业管理的要求，是企业为了持续提升自己的绩效而采取的措施。
从这个角度我们来看一个由来已久的问题：
“敏捷开发是否考核个人？
”很多人会脱口而出：
“敏捷开发不考核个人。
”但是如果再问“企业管理要求必须考核个人怎么办？
毕竟工资和奖金不是发到团队总账户上的”估计再下去的回答，就只能说是闪烁其辞了。
其实这也是一个伪命题，所以才导致很难回答。
下面一点点分析。
企业绩效管理的目的不是为了考核个人，而是为了提升企业绩效，所以尝试考核个人的企业实际上在“利用考核个人提升企业绩效”（尽管提升个人绩效会提升企业绩效，但勿入此牛角，因为前面有个尖）。
因此这个问题从原始出发点来看，应该是：
“企业是否应该通过考核个人来提升绩效？
”，那么答案就是：
“敏捷开发有比考核个人更能提升绩效的方法”。
不是因为用了敏捷开发就不能考核个人，而是选择了敏捷开发，就意味着已经选择了比考核个人更有效的提升绩效的方法，因此没有必要让企业管理和敏捷开发较劲，它们打不起来的。
不过这个或者这些更有效的方法是什么呢？
这就是本系列博文的主要内容。
本系列博文将较多涉及团队级别的绩效管理，内容包括团队管理的策略，个体管理，团队的外部目标设定，如何分解到个人，不同团队绩效管理的差异，非物质激励等。
另外一个高级话题则是产品级别的绩效管理，包括产品发布计划，产品版本计划，产品线管理，产品负责人及产品负责人团队，不同产品类型的搭配等等。
但这个话题以另外一个主线组织会更顺畅：
敏捷开发产品管理，因此会形成另外一个系列，但其核心内容仍是“如何通过敏捷开发管理产品提高绩效”，如果您觉得本系列所涉及的范围太窄，敬请关注
（有读者反映每篇文章太长了，本系列会以较多的短篇文章形式发布，以便于选择关心的内容分别阅读。
）
敏捷开发绩效管理之二：
用中医理论管理团队及其绩效（绩效考核，团队管理，自组织团队）
团队管理是个由来已久的话题，各式各样的管理理论和方法层出不穷。
笔者因为工作原因在过去16年里与100多家企业的团队或团队领导者有较为深入的交流，看到了听到了想到了很多相关的内容，下面做一个总结。
不过受个人经历所限，这不是一个客观的全面的总结，而是带有本人的角度和主张，仅供参考。
中医治病的原理
中医和西医看待疾病的角度差别很大。
中医受到当年条件所限，并不知道致病的原因是细菌、病毒还是其他什么。
由于没有显而易见的敌人，中医采取的策略是扶正去邪，就是让让人体自身加强，从而自然地消灭”邪气“。
比如中耳炎，西医的解释是：
“多由感冒引发……急性中耳炎是中耳黏膜的急性化脓性炎症，……致病菌乘虚侵入中耳……常见的致病菌主要是肺炎球菌、流感嗜血杆菌等。
”因此若能将这些病菌铲除，则可治愈。
而中医则认为：
中耳炎是因肝胆湿热（火）邪气盛行引起，就是”情绪激动“导致中耳炎。
因此应先”淡定“，然后配合治疗方可。
中医的解释读者看起来可能感觉不可思议，但我很久以前得中耳炎导致内耳积水的时候去西医看了几天没好（当时也没有感冒），给一位中医朋友打电话求助，他一语道破：
你最近“激动”了，令我大吃一惊，也立刻相信他肯定能治好。
实际治疗过程只有一上午，只使用了两根细针在离耳朵一米远的肢体末端扎了2小时，没有任何其他药物——换言之从表面上看“没有任何东西被任何药物杀死”，但10分钟后鼻腔和耳朵就有明显干燥感，半个月后自愈了。
后来一问，原来他自己也得过此病，去过很多医院（医生各有所长，也有去医院的时候呵呵）花了几千块无法治愈，差点变成“聋子中医”，最后求人不如求自己，自创医术把自己给治好了，还治好了20多个病人。
（他最近开始在梁冬开设的正安药房上班）
扎一米远的地方为何能治好耳朵？
原因是那个地方有个穴位，可以调整和激发自身的自愈能力，由人体自己把疾病治好。
对团队管理的启示
团队也无时不处于众多“病菌”的围困之中，其中一个病菌似乎是“个体懒惰”，而对症下的药自然就是“考核个体”。
很可惜，这个病菌不是致命菌，看下面几个问题就知道了：
“个体差异主要来自于哪里？
”懒惰是一个方面，能力是另外一个方面。
能力相同的人中，最懒的和最勤奋的程序员的工作产出相差多少？
估计能相差30%就算不错了。
那么同是懒惰或勤奋的人，能力最差的和最强的程序员工作产出相差多少？
10倍！
所以，这里有一个大得多的病菌。
“最近M公司和N公司业绩下滑了50%，原因何在？
”因为大家变懒一倍？
或者能力下降50%？
显然不是，他们的产品管理出了问题。
这个病菌大得致命。
那为什么多数软件公司都简单地通过考核个人来提升绩效呢？
因为那样虽然无效，但是却简单。
其实以往的很多处理策略，都有这个倾向，比如：
需求变更频繁，客户说不清楚需求，工期紧，人员流动……对每件事情单个而言，似乎都有几种“青霉素”一针见效：
需求变更频繁？
就走需求变更流程，统计变更数量，向客户递交变更工作量；客户说不清楚需求嘛？
我们写需求让他们签字，需求不签字不开工，签了字就不准变更了；工期紧？
加人加班！
人员流动？
多写文档，不怕流动……等等不一而足。
然而到用的时候就会知道：
几乎所有这些青霉素都导致过敏！
敏捷开发的“不考核个体”的思路，其实和中医理论很相近：
尝试打造一个能自组织自更新的团队，来消除各种问题，而不是就问题论问题地处理。
自组织团队
何为自组织团队？
“领导放权了，让我们管自己，自己估算，自己领取任务，所以我们现在是自组织团队。
”这个认识太浅。
不是简单地去掉领导和流程后就能剩下一个“自组织团队”，这样得到的多半是一个无组织团队——否则这也太简单了，我们的先人和领导们简直是傻子。
事实是：
自组织团队，是一个依靠团队的自组织能力，自我管理自我更新，消除各种有害因素，来达到提升绩效的团队。
仔细分析一下，导致团队或公司绩效差的有害因素有很多：
团队级别的也就是本系列希望讨论的包括（大致由小至大）：
个体懒惰
个体能力差
个体懒惰导致团队懒惰
个体能力差导致整个产品的质量差/进度慢
……
如果领导放权了，我们自己估算，自己领取任务，但这些有害因素仍然在，那么我们就不是一个自组织团队。
我们只是一个生病了不打针不吃药的病人而已。
本文提到了敏捷开发对于提升绩效的主要机制：
不是依靠一个有强大控制能力的领导，或一个固定的流程，而是一种能自我适应和改进的机制，进而让团队进入自组织状态，以自己的方法解决问题。
下一章节将会提到用于取代“个体考核”来激励个体的敏捷因素：
同行压力。
附：
导致团队或公司绩效差的有害因素
产品级别的包括（大致由小至大）：
功能定义错误
产品版本定义错误
产品概念/用户群定位错误
产品线组合错误
……
这些将在敏捷开发产品管理的系列中涉及，敬请关注（尚未开发，作者2011-08-21注）。
敏捷开发绩效管理之三：
个体动力之源——同行压力（松结对编程，师徒制度，跨职能团队，绩效考核）
如果有10个程序员，笔者相信至少有9个是勤奋的。
但是如果有一个10人的程序员团队，其中1个人不是勤奋的，而且仍然拿到与其他人完全相同的报酬——大家猜这个团队会以90%的生产率运行，还是更低的生产率？
不管大家信不信，我是相信后者的。
这个是敏捷开发中对个体管理的出发点，并非我们看到有人在白拿老板的钱而要劫贫济富，而是要打造一个共进退的团队。
本文的部分内容在之前的若干博文中提到过，因符合本系列的内容，在此处从另外一个角度加以说明。
领导压力
领导压力指那种直接由领导监督产生的压力，在“每个毛孔都流着血和肮脏的东西”的时代或企业非常普遍。
特征表现为：
领导深度过问过程而不只是结果，领导现场监督（在计算机时代，则有人发明了一种软件可让领导直接监控员工屏幕）等等。
领导压力的问题在于：
领导很难无处不在无时不在；领导很可能是外行；领导就算不是外行，对单个任务而言，了解程度也一般低于任务承担者。
领导压力一般是面向个体的，因为团队不会帮助领导管理个体，相反其整体上处于帮助个体而疏远领导的状态。
如果你所在的企业越来越关注大家的考勤，已经在办公室安装了摄像头，正在调研一款屏幕监控软件……那么，代打卡现象一定很普遍，坐在电脑前什么也不做的人一定很多，定期切换屏幕的习惯正在大家中间养成……
办公室是一个团队合力解决问题的场所，而不是内部博弈的场所，因此领导压力是一个不明智的选择。
同行压力
同行压力是一种由员工管理员工的方法，因而解决了时间、空间、知识差异的问题。
不过这种管理不是通过授权某人管理另外某人，而是通过为团队指明一个共同利益，从而使其在获取共同利益的时候互相管理。
典型的同行管理行为发生在敏捷开发中的“（每月）计划会议”和“（每日）站立会议”。
在计划会议中，团队在确认谁负责哪个任务之前，先共同估算每个任务的预计工时，之后才自由领取或指派负责人；而在站立会议中，任务的负责人则报告进展情况，如果和计划有大的偏差，需要说明遇到的困难，以便大家进行帮助。
其中所使用的共同估计和共同跟踪是实施成功的关键活动。
同行压力的外在条件
不过有时一些应用敏捷开发很久的开发团队并没有真实感觉到“同行压力”的作用，原因是同行压力的实现需要一些先决条件来支持。
1.跨职能团队
如果分工过于细化，技术壁垒太高，很难展开共同估计。
有些团队本身是跨职能团队（如10个都是开发人员），但却往往因为过度进行模块分工而导致工作无法胡同。
跨职能团队底线是：
任何任务至少有两个人可以完成。
2.先估计后分配
原因显而易见：
若任务已经分配，多数“无关人员”的兴趣和注意力将大大降低。
3.匿名估计
即使是一个跨职能团队，如果第一个人首先说出估计结果时，其他人可能因为各种心理问题而导致无法客观地表达自己的意见，尤其当第一个人是最强或最弱一员的时候。
宽带Delphi和估算扑克是两种常见的匿名估算方法，其中后者因为简单快捷在敏捷开发中广为使用。
4.挑战和优化估计
为了防止计划会变成一个无聊的监督行为，在匿名估计中数值相差较大的组员要进行“挑战（Challege）”，寻求最优化的估计。
之所以称之为挑战，是因为团队不能简单地进行求均值、投票，而是大家分别说出理由（一般估计最低的先说），尝试确认是否有可重用的组件、额外的测试要求等诸多可能影响估计结果的因素，重新投票直至结果接近。
优化估计的过程借助团队的知识和智慧澄清了很多个体似是而非的猜测，结果不但为大家所接受，也更客观。
5.共同跟踪
共同估计是共同跟踪的前提。
只有这样，在跟踪时（比如每日立会上）大家才会关心别人任务的实际情况，在遇到困难时（往往是发生了超出当年计划意料之外的事情），人们会更理解任务为何发生延期，且更容易激发热情去帮助任务负责人。
在一个采用师徒制度和松结对编程的团队，共同跟踪活动不限于每日立会，而是会渗透到日常开发活动中。
6.团队绩效
即认为若某个工作没有完成，责任属于整个团队而不是具体负责人。
这样既可以防止有任务没人接，也可以防止有些人把着任务不放。
在较大的团队里边由于有从众心理，往往很难让一个人在心理上承认自己应为另外9个人中的一个没有完成任务而负有责任。
但当把他们切分成小组时，情况会有所改观。
尤其是师徒制度下师傅的团队责任感会很强。
7.可完成的任务
若任务总是无始无终（比如“开发可重用库”）或很难有标准判断是否完成（比如“需求分析”），则很难估算和跟踪，也无法形成同行压力。
8.开放空间
既包括物理上的开放空间即人们可以观察到每个人在做什么，也包括逻辑上的开放空间即人们可以观察到别人任务的进度。
匿名性被心理学分析为引发违规的重要诱因，比如群体事件中的蒙面者更加胆大妄为。
跨职能团队、共同估算、开放空间等均起到破除个体匿名性的作用。
在开放空间和个人空间之间有由来已久的纷争，仁者见仁智者见智。
不过笔者放弃了所有拥有独立办公室的机会，坚持坐在团队的中间乃至正中央。
因为工作并非永远令人兴奋、感觉顺畅，我非常担心自己会放弃自律而有所松懈。
那时候产生的所有负面效果的第一个受害者是我，而不是公司或其他人。
上述内容在很大程度上已经替代个体考核管理了团队中的个体，帮助他们提升绩效，但如何最终考核他们的绩效（正如前言，工资和奖金毕竟是发放到个人账户上的），日后会有博文再议。
若团队的个体绩效已经与团队的整体绩效对齐，那么他们一起去做什么呢？
那就是我们的下一个话题：
为团队设定外部目标。
敏捷开发绩效管理之四：
为团队设立外部绩效目标（目标管理，外向型绩效）
最近在看德鲁克的书，发现其中很明确地写着“企业的绩效只存在于外部，而企业内部只有成本”的概念和说法，下面结合敏捷开发团队的绩效考核展开谈谈。
敏捷开发有很多“外向型”思维，比如：
关注客户价值，认为可交付的产品才是真正能表征工作进展的因素等等，但尚未直接与目标管理接轨。
外向性思维可以防止部门间壁垒或踢皮球，而转而共同讨论对外交付价值，从下面的对比可以看出这点。
“内向型”绩效及其导向
进度：
“各阶段按时完成率”会导致分析和设计人员草草结束工作，而将大量不确定工作推给开发人员；开发人员则如法炮制，把延期踢给测试人员。
质量：
“千行代码缺陷率”会导致开发人员在很多“是否是缺陷”问题上与测试人员争执不下，另外一些次要的如使用不便、不直观等问题则被长期搁置。
成本：
“与计划相比的人员超支率”会导致项目经理很不愿意接受变更，即使是那些显然能给客户带来巨大价值的。
功能：
“需求规格中需求的完成比例”会导致开发组思维局限于当年编写需求规格时期的认识，而不能在整个漫长的开发过程中不断精化需求。
此外还有一些更可怕的数据，比如“每月生产的代码行数”“每月生产的功能点或故事点数”（这个很有迷惑性）“每月修改的缺陷数”等，都是不恰当的绩效。
德鲁克“企业内部只有成本”的理念指出，无论是文档，代码，可运行软件乃至最终产品，若尚未被销售，都只是成本的一部分。
多数采用内向型绩效的公司和团队，其绩效结果都不好。
究其原因，单个部门/工种/个人各自追求自己的绩效，并不会导致整个项目外部绩效的提升（这称为“合成谬误”）。
某些内向型绩效甚至是互斥的，处于零和状态。
比如测试团队人均发现的缺陷数（测试团队的绩效）与开发人员人均缺陷数（是开发团队的负绩效）并存，则两个团队无论如何都无法同时提升绩效，导致他们永远无法像一个团队一样互相帮助。
若你的公司有这样的绩效，则研发人员与测试人员打架就不用奇怪了。
其他多数内向性绩效，都存在潜在的互斥关系。
比如前面提到的个阶段按时完成率即内部存在互斥，而“需求规格中需求的完成比例”必与“客户需求响应率”互斥。
外向型绩效
下面是一些潜在的“外向型”绩效，由于之前提过不同企业乃至产品的外向型绩效差别很大，请灵活运用。
产品研发型
进度：
“与竞争对手相比同档产品的上市日期比较”适合消费电子类产品。
“响应分销商需求的时间”适合渠道比较强势的情况。
这些外向型绩效应该作用在整个团队上，换言之不管哪个环节导致了进度差，都一起得到底的绩效。
从而促使整个团队一起思考如何提升绩效。
需求和设计人员为了能让开发人员提前开工，可以采取分段写需求和设计的方法，把最影响架构又最不会发生变化的部分先写出来，让开发人员提前开工干活；而开发人员也可能会采取同样的策略，阶段式地发布产品，让测试人员可以提前测试，防止最后缺陷太多导致产品延期；而需求和设计人员又回过头来用开发的进度和测试的缺陷率，来判断产品应该消减功能换取上市时间，还是增加更多功能以换取竞争力。
可见一个为外部目标奋斗的团队，会很容易地团结起来，共同思考提升绩效的最佳策略。
质量：
“每月待处理质量问题数”咨询过的一家ERP公司的实际数据（但他们尚未用这个数据考核），此数据一般符合瑞利分布，因此可预测未来的质量问题数量。
“每月终端用户投诉数”适合消费电子、网络游戏等与客户比较紧密的行业。
“每月分销商投诉数”适合渠道比较强势的情况。
“每月论坛缺陷提出数”适合……我在的一家企业使用BBS免费处理缺陷。
用最终用户提出的抱怨作为外部质量目标的策略，不是说大家不用测试了，把缺陷留给用户。
而是：
用我们测试了但仍漏给客户让其发现的缺陷，来修订我们对缺陷的认识，修订发现缺陷的方法。
有很多产品，收到的客户关于易用性的抱怨，远远多于对功能和常规缺陷的抱怨，就应该将“易用性差”作为核心的质量问题，进而作为质量重点。
我在下载一款总体评价4星半的Android短信软件时，发现近期的评价很多都是“越来越难用了”“没用的功能越来越多”甚至“更新太频繁了（给了1星）”等等，最近的一些评分平均估计会下降到4星以下。
这些抱怨应该当作质量管理的最终考核标准，因为下载者无疑会根据这些评价来决定是否安装软件，而不是看那些“千行缺陷率”“测试人员发现缺陷数”。
成本：
“产品实际投入产出”适合很长的战线。
试想如果是手机研发，应该在开发阶段就做好测试、维护、重刷系统等接口，另外应该优化性能以选择低端硬件，否则整个产品极难保障盈利。
而且还会发生若软件做得好（但软件的研发成本要上升），则可以节省一些硬件资源或减免某些专用硬件的情况。
这时候若要分别考核软件部门和硬件部门，就很难实现了。
需求：
“每月待处理需求数”咨询过的一家ERP公司的实际数据，如果产品试销售过程中此数据很大而且消退很慢（符合瑞利分布），则表明产品与客户的需求不符。
估计也能呈现一些易用性方面的因素。
“客户尖叫度（CustomerScreamingRate）”苹果成功的标志性绩效指标，不谈需求，因为他要超越需求。
要学习这个很难，但要理解并体现其精神。
“软件与硬件需求匹配度”适合消费电子，比如若硬件与软件研发平行，则最终交付产品中交付的软件和硬件应该匹配，而不能“18个功能中，硬件完成了12个，软件完成了13个，但其中6个不重合（就是说这些功能交付不了）”，这样软硬件部门才会共同配合。
某手机厂商很擅长上一条，他们一年的200个项目中，只有3个延期，就是很好地利用了功能排序-软硬件对齐的方法，牺牲次要功能保证上市时间。
项目开发型
产品做的多，项目做的少，不敢多说，请各位补充吧！
为团队设立外部绩效目标的目的，是对齐团队的不同角色、工序、人员的目标，从而互相帮助提升共同的绩效。
外部目标多数可以被客户、用户或市场明确感知，其提升几乎意味着带来收入的增加。
如果想在测试人员发现Bug的时候发奖金但却发现账上没有钱，那就改到客户很少抱怨的时候发吧，那时候账上肯定有钱。
注：
这是一篇旧文，因符合本系列的内容，在进行了很大改动后重新编辑发布在这里。
敏捷开发绩效管理之五：
敏捷开发生产率（上）（故事点估算）
度量敏捷开发的生产率一直是个难题，确切说度量任何开发方法的生产率都是一个难题，但它实际上有答案，这个答案是本文的主要内容。
度量敏捷生产率的目的
真正难以回答的是度量生产率的目的是什么？
很多人都认为是考核绩效，发奖金。
根据上一篇文章的内容我们可以知道，这完全是行不通的：
客户并不购买我们的生产率，生产率高也并不能证明产品或项目盈利，应该为团队设立外部目标，否则很可能得到一个生产率很高，但是实际上很烂产品——质量上或易用性上很差，抑或其他想象不到但一定遇到的原因。
这是我们说为什么用外部目标而非内部目标考核团队的原因。
或许又有人说：
“开发得快不快是团队的事情，产品好不好则是产品负责人的事情。
”这样也不对，相当于我们在自组织之后，当我们享有勇气，尊重，沟通……这些敏捷的特质之后，我们居然得到了一个只关心自己的开发速度，而置客户价值和企业利益于不顾的团队。
“受激励的个体”只被自己小团队的绩效所激励，并不爱也不关心自己的产品，这绝对不是敏捷开发的初衷。
度量生产率的目的不是绩效考核，而是是希望提升生产率绩效。
将度量结果进行横向和纵向比较，可以分析造成生产率差异的原因，并进而提升生产率绩效。
微观度量方法-故事点
故事点估算方法
“每月完成的人天数”这个方法不说了，用尺子量尺子，肯定不行的。
不过通过统计每月的实际投入天数，可以优化人员利用率，并间接提升生产率。
“每月完成的故事点”这个是比较好的方法。
所谓故事点法，就是提前选择一些大家都熟知的、以往做过的、典型的故事，比如：
1.对单个表进行增删改查
2.对父子表的增删改查
3.为一个已经存在的数据表增加一个复杂报表
4.修改一个中等难度的BUG
……
（实际上这些故事应该是具体的，而不是像上面例子中一样看起来更像是“分类”）
然后人拿出当年的历史记录，将当时所投入的人天数称为“故事点数”（也有别的做法但这个最简单）。
比如“对单个表进行增删改查”当年用了4天，那么标准故事点就是4。
当下次估算时，人们又发现有一个故事也是“对单个表的增删改查”，于是就先选定基数为4，再讨论这次与上次比，到底复杂多少。
如果一致认为可能复杂20%，那么故事点就是5。
如果大家的生产率不变，那么这个故事应该5天完成，但是如果结果却是4天就完成了，则表明大家的生产率提高了。
当然不是一个一个故事度量，而是把整个迭代内的故事点加起来度量。
通过纵向比较故事点，可以知道大家是否比以前的生产率提高了。
横向比较故事点比较有难度，因为每个团队乃至项目都会选定自己特有的标准故事，而且极难说明这个团队和那个团队的标准故事的转换关系。
故事点的局限性
在推广故事点这件事情上笔者有所保留，建议尝试但需注意风险，必要时知难而退。
在笔者遇到的这么多做敏捷的企业和人里边，还没有见到有人提到他们的故事点应用是成功的。
原因在于找到大家都熟知的、以往做过的、典型的故事很难，而让所有人记住它们当年的详细情况以便日后对比修订就更难。
04年笔者去做咨询的一家企业有他们的故事点模板（他们并不做敏捷开发，但却使用完全类似的方法），一共有17种标准故事，已经记录了25个项目的故事点数据和实际工作量数据，每个项目从4个故事到上百的故事不等，他们希望笔者能帮他们计算一下“17个标准故事分别对应多少人天”。
终于遇到了又有标准故事又有历史数据的情况，这比所有一穷二白想使用故事点的企业可乐观多了。
这是一个所谓“线性规划”的问题，涉及“最小二乘法”“超越方程”这些玄乎的名词，但却在Excel表里有这个功能，不过是10分钟的事情并不费力，真正费力的是解释其结果：
求解的答案是——某些标准故事是负数，也就是说如果把这几种故事当作负数对待，那么以往发生的25个项目的预测结果与实际结果最符合。
再换一种直白的解释：
用这17种故事预测工作量不准。
或许有人会说他们的17种故事选得不好，或他们的水平很差。
怎么说呢，他们是一家1000多人的电信企业，专职做过程管理的人就有5人，还认真地记录了这么多数据，恐怕当年选定故事的过程也是经
升级会员 