拯救面临崩溃项目(谢新华)

Name：Mail：Mobile：中科院计算所培训中心从面临崩溃项目拯救过程看项目监控方法谢新华@tianbo.com.cn2软件项目成功的要素：•依靠一个组织来完成，团队是关键•管理上有序而且有效，开发过程正式和受控•计划期限和成本目标应该达到•项目的成功不取决于个人英雄式的行为•个人在团队中能充分发挥作用•各个要素以统一协调的方式运转•时间、资金和质量三角约束得以平衡•任何成功项目都需要敏捷性，敏捷的动态性更需要有效监控。ClaudeShannon3项目领导者四项关键能力•制定有效的规划（计划）•项目过程中的监控和调整•计划、监控与调整以可度量的方式进行•组织人力资本，有效调配人力物力，充分发挥人的主观能动性4制定发布规划两种思考路线：•先确定完成日期，再看在这个时间内能实现多少功能。•先确定需要完成的功能集，再看需要多少时间完成。5集体评估计划的有效性•与竞争对手相比，这个计划完成后有优势吗？•开发这个产品会不会盈利？•它能够节省足够的开支吗？•该产品是否能够占据所期望的市场份额？•时间长一些或者短一些，项目能达到可接受的目标吗？包含在在发布计划中额外信息与假设：•小组成员需要什么样的技术背景？•小组需要哪些成员？•迭代周期有多长？•第一次迭代从什么时候开始？•昀后一次迭代什么时候结束？6•通过反馈和调整使项目走向正确的方向•在变和不变中寻求平衡•迭代过程是一项集体运动，成功的核心因素是团队迭代模型7速度驱动的迭代规划迭代规划是把目标限定在一个迭代周期之内，视野窄，可以精细考虑，任务时间安排往往是以小时来计。速度驱动的迭代规划比较适合于项目比较大而复杂，要求开发过程正规严谨的企业要求。8承诺驱动的迭代规划承诺驱动是迭代规划包含了速度驱动的大部分内容，不过基本的思路是不太一样的。它不是应用“昨天我们做得如何”来规划，而是要求开发小组把用户故事逐步地加入到迭代规划中去，直到他们无法承诺完成更多地描述为止。9成本基准的建立理解每一阶段的成本情况为了建立成本基准，我们可以在计算现金流的基础上，按照每个阶段的总计时来再次计算基准。对于使用的每个资源，可以为下列内容指定资源成本：标准费用：元/小时。加班费用：元/小时。单位使用成本：通常是使用某种消费品的总体费用。对于时间较长的活动，可以分成开始、中间和结束三个阶段分配成本。10任务基准的建立建议里程碑时间是整个项目时间的1/1211项目处于崩溃边缘的判断准则1，从时间监控数据上判断•时间超支往往是项目处于危险的信号，•项目超支趋势是蠕变而不是突变•查看已经结束的昀近3个时间段。检查滞后时间是不是随着时间的流逝稳定增长？•目前的总滞后时间是否大于总项目时间的25%？25%数字是一个报警临界点，如果超过这个值，就可以认为项目严重滞后。12检查进度趋势（三个问题）：•滞后程度：把总滞后时间除以已经逝去的时间，是否在增长？具体地说一个月前的滞后时间，是不是大于两个月前的滞后时间？在这个月，滞后时间会不会再次增长呢？•滞后时间是否稳定：滞后是具体的事件，还是稳定的长？•是否触发报警：目前的滞后时间是否大于相对总时间的25%？如果上面三个问题都是“真”，那么把项目停下来进行重新评估是个好主意。13时间超支情况示例时间段（原计划时长的1/12）状态累计超支（超支时间/每时间段时长）1按时0%2滞后50%3滞后110%4滞后160%5滞后160%6滞后165%→7滞后170%分析第四个时段之前的情况：在第二时段：累计超支50%，也就是相对于已逝去的时间，项目滞后1/4（50/200）在第四个时段结束的时候：项目滞后40%（160/400）这种滞后已经很严重了。时间超支相对于项目总长为13%（160/1200），并没有达到阈值，但可以看出发展的趋势很不好。14注意：项目早期阶段出现进度滞后，若不加以处理，项目的滞后程度将会随着时间的流逝而增加，到项目后期阶段，滞后程度将很难消减，越晚越难消减。在这个项目中，在第四个时段以后采取了措施，改善了项目滞后状况。项目第四个时段到第七个时段：项目滞后增加值开始减小，大约在5%左右，那么沿着这个趋势推论，在项目结束的时候总的时间超支应该在15%（195/1200）。16%的超支尽管不是个很好的结果，但绝不能视为灾难。结论：这个项目还处于可控状态，不过这个项目需要密切监视。因为项目后期的任务比前半段艰巨（资产、复杂度、压力都会增长），以确保不会滑进超支增长的状态。152，从预算监控数据上判断如果我们已经有了进度报警器，是不是还需要有预算报警器呢？很多经济学家认为预算和时间是可以互相转换的？这个观点有的时候是正确的，但不尽然。例如，为了赶进度，大量增加了团队成员，这时候进度是满足了，但预算却可能超过了预期。我们遇到的大部分情况是，时间的超支是可以控制而且是可以接收的，但由此引发的预算超支是不可接受的。所以，除了进度报警器以外，还需要有预算报警器。16需要思考的问题•项目进度检查结果是不是进入灾难？如果是，有没有必要对剩余工作的成本进行预算？•如果项目进度检查结果显示在可控范围之内，那么根据项目在昀近三个时段的预算超支情况，按照相似的超支增长率，推测项目在新的时间表结束时的预算超支，这个超支费用是不是在机构承受范围之内？•项目的客户和用户昀近是不是提供了反馈？市场调查的数据是不是做了更新？项目原来的成本/价值和ROI分析是不是依然有效？17以12个月的项目来讨论（注意：预算不是平均分配在每个时间段上的）。预算超支示例项目时间段各时间段的预算超支累计预算超支10%0%2-3%-2%310%4%440%19%550%28%→660%35%分析：第6个月当月超预算60%，前6个月总支出超过35%。从预算方面来看，项目开头不错，从第3个月开始出现超支问题，一直到第6个月，超支情况持续加重。18从最近3个时段计算超支增长率增长率的计算公式：（本时间段增长率-上一时间段增长率）/上一时间段增长率*100%以第6时间段为基点计算：第四个月增长率（4%～19%）：375%；第五个月增长率（19%～28%）：47%；第六个月增长率（28%～35%）：25%；结论：在第四个月有一个增长率急剧的上升，我们需要调查这个急剧的上升是如何造成的？原因在什么地方？而第五个月以后增长率实际上在逐步下降，这就随着问题的发展对趋势有了一个基本的判断。19利用Excel建立监控表，可以方便的进行回归分析，以预测未来走势。20分析：整个项目原定预算200万元，到第6个月结束的时候，已经花去了：720000+252000=972000元预测到项目结束的时候，要花去：2000000+1640000=3640000元那么，预计从第6个时间段开始到项目结束的时候，我们还需要花去：3640000-972000=2668000元我们的问题是，再花去270万把这个项目完成值还是不值？如果不值，这就是报警信号！预算警报发出以后是不是这个项目就不值得开发了（撤销项目）？那也不一定。通过消减项目范围可以把开支减少到可接受的程度，消减项目其他开支也可以做到这一点。213，从质量监控数据上判断项目的问题分类：•危急：如果不纠正这个问题，产品可能无法使用；•严重：如果不纠正这个问题，可能会损害到软件产品一个或者多个主要功能；•轻微：如果不纠正这个问题，软件产品的主要功能也能运行。主要考虑：•危急类问题的列表是不是在变长？•问题是不是正在被解决？•新问题的增加速度如何？22如何判断问题很严重？•如果严重类问题的数量很多，而且没有变小的趋势，那么情况也很严重•根据机构的历史和专家的评估，对于克服危急类问题所需要的时间，是不是有客观的估计？•质量问题列表是不是做了正确的归类？•问题是不食草率的被删除了？•是不是限制新问题加入列表？不要小看QA的作用：如果组织有了很好的质量保证过程，那么从项目一开始质量问题就可以很好的监控。在项目启动的时候，立即为团队安排一名中立的质量保证（SQA）专员，是非常重要的事情。23项目问题列表时间段轻微类问题数量严重类问题数量危急类问题数量10002180031410410815254364512272595→8631489101112分析：危急类问题：第6时段减少了1个，第8时段又增加了3个，这种活跃性表明在后期（9～12时段）还会增加，可见，危急类问题的数量正在增长，可能会失控。在机构的历史中，这种规模的增加需要花费多少时间呢？这决定了我们需不需要担忧。严重类问题：第6时段增加了8个，第7时段减少了3个，在第8时段又增加了5个，这种波动性的状态表示问题在不断解决，应该不需要担忧。结论：问题在不可控的增长，但不一定就是触发了警报，24质量上的灾难警报的数据案例项目问题列表时间段轻微类问题数量严重类问题数量危急类问题数量100021800314104100152580645143725165→8631889101112在过去三个时段，严重类和危急类的问题都在稳定增长，如果这个趋势继续下去，项目很可能会陷入灾难。还需要注意，轻微类问题对项目失败影响非常小，尽管他通常是超支（时间、预算）的帮凶，但是，在考虑质量的时候，一般不去考虑它。254，合理的利用经验和常识•数据是重要的，但数据远不是一切。•如果把自己的“常识”和上面的分析方法结合起来，就可以产生非常好的效果。•项目监控测量数据具有先天的不完备性，所以需要利用我们的常识来弥补它们的不足。•数据驱动的决策过程只要不是特别费力，就会十分有效。但是如果需要花费很长的时间来处理前面的数据完成对项目的评价，就没有多少实践上的优势了。•当一个项目深陷困境的时候，决策过程所花的时间越长，麻烦就会越大，解决麻烦所需要的成本就会越高。26判断一个项目是不是陷入灾难的合理时间：•计划6个月时间完成，有4个开发人员的项目，通常1天完成评价工作。•计划2年完成，150个开发人员的项目，可能需要2周时间完成评价。•一般来说，任何评价都要控制在2周之内完成。不要害怕作出决定：对决策者来说，害怕作出错误的决定而迟迟不作决策，对项目将会造成重大损失！不存在完美无缺没有风险的决策。如果数据还没有100%的说服力，那就要依靠经验和常识。不一定什么事都依靠测量，我们所需要知道的就是灾难离我很近了，需要快速离开，这就是决策！27监控不是目的，监控是为行动提供依据：一旦判定项目进入灾难，那么就只有两种选项：1）放弃2）拯救。如果选择拯救，那么启动灾难拯救过程：1）了解国际上很多机构拯救灾难项目的成功经验2）了解本机构历史上拯救灾难项目的经验3）了解本机构的文化和组织特征4）就需要建立相应的拯救过程，利用有序的、一致的、没有歧义的方法，使项目走向成功。28典型灾难拯救过程291，停止项目暂停所有的开发活动，并给团队分配拯救工作。对待项目开始走向灾难的几种态度：•期待奇迹发生•平静的等待死亡•依靠运气继续运行认知：不死不活的项目只会吸纳宝贵的资源，却永远也不会达到目标。停止项目是强有力的信号：拯救过程开始运行了。明确与以前的常规方法区别：增加人手、加班加点、项目延期等。30问题：1）谁来停止项目？管理层的决定，让利益相关人员参与决策。注意：避免由于偏见、感情因素、个人利益等使决策变得复杂和滞后。我们应该有足够的准备，并具备说服的技巧，说服是对问题的演绎，而不是希望管理层以势压人。2）高层管理者的支持在拯救过程中无法避免会产生很多问题，需要高层管理者强有力的支持。注意：如果高层管理者对危机认识不足，或者只提供了有限的支持，那么这样的拯救过程成功的机率不大。312，选定评估者聘请一个顾问，进行项目评估，两种方法：1）聘用一名外部的专业人员来领导拯救过程为什么这是明智的决定？当项目陷入困境的时候，经常会有激动的拥护者和反对者，决定被情感操纵的情况很常见。内部评估者可能会由于害怕难以说出的麻烦，很难做出有效的评估。所以尽可能从外部公司寻找评估者，可以提高评估的客观性和公正性。2）也可以在公司内部寻找评估者评估者与项目的关系越远越好，绝不可以与项目本