读《与熊共舞》

    熊：食肉目熊科的一种大型笨重的哺乳动物，危险的动物(俺家的熊反对：切，小熊维尼，多可爱啊)。嘿，此熊非彼熊，黑瞎子是也。 
    在美国童话《戴帽子的猫歌谣》中：Terwilliger大叔每周六都要“蹑手蹑脚下楼梯/偷偷摸摸出门去/与熊共舞华尔兹"。说实话，对于这个故事，俺是不大感冒的啦，倒是前阵子看过的《断臂山》片中的黑熊，刚一站立，准备与小伙儿共舞一曲，哪料到，小伙儿却不解风情，连同其坐骑屁滚尿流，回到驻地，却成就另外的一段啥啥啥……

    好了，书归正传。 
    翻开这本不厚的小册子(8开，200余页)：
    有风险才有机遇，我们需要正视风险。 
    技巧、知识、诚实、胆量，方能与熊周旋。
    与熊共舞的爪痕，是我们肩上光荣的徽记。
    精彩，读来令我有些热血沸腾，嘿。

    本人没有大项目的管理经验，虽对于书中的讲解深以为是。但绝谈不上深刻的体会，也不敢妄评。下面，我只是按原书的五大部分，提取出其中的经典观点，记录之，以便于以后进一步阅读，理解。   

    序 
    在早餐前请相信六件不可能的事，
    在我们的行业里，这似乎就是软件项目管理者最需要的能力。
    但是，
    只应该相信有权相信的事情，这才是风险管理。 

    Why？为什么要进行风险管理? 
    不要去做毫无风险的项目，机遇总是伴随着风险，如果选择逆风而行，请你睁大眼晴，而当你勇于面对风险时，恭喜你，你作为一个成年人，已经成熟了。
    那么，风险又是什么呢？
    简单的讲：它是未来可能发生的导致不好结果的事情。
    那怎么办呢？
    如果你在风险变为现实之前做了避免转化的工作，那就是缓解了风险，

    就软件行业，我们先提升一步：软件项目本身的延期可能是更大工程的风险(书中有经典例子)。谁为忽视风险的代价埋单，谁就应该负责管理风险。

    你有多大勇气投身于一个充满风险的项目，直接取决于你对风险有多少认识和准备，只有负面的思考才能让你避免在风险面前束手无策。
    风险管理为不确定性划定边界，没有边界的不确定性会使人变得厌恶风险或者是鲁莽蛮干。
    当好运成为管理策略中不可或缺的一部分时，你就有麻烦了。

    好了，进行风险管理吧!

    Why Not? 为什么大多数人不进行风险管理？
    但，有人讲了：顾客不能面对风险，你所讲的风险的不确定性太广了，程序员会将风险作为工作低效的借口，评估风险的相关数据太少了，再说了，我也没见到其它人进行风险管理。好了，我不会进行风险管理，但我可以让风险不发生。
    公司讲了：这可不行，本公司倡导：你可以犯错，但不可以不确定。
    实际上，公司高层对于风险，往往采取选择性近视，
    当你小心翼翼地不让自已被铁路的枕木绊倒时，你有没有注意迎面而来的那辆火车呢？
    当然，也有一些风险无需管理，比如：无法克服的风险，可以忽略的风险，别人的风险。

    实际上，软件项目中“控制失败的后果”比“获得更大的成功”更为重要。

    How？那该如何着手管理风险？      
    首先，应该给不确定性划定界限。也就是作出明确的不确定性边界的承诺：我们将在时间A到时间B之间完成任务，恰恰，这也是判定企业是否成熟的重要标识。
    不确定性范围与N点之前的时间之比大概是在150%-200%之间(N点：最早可能交付产品的时间点)，尽管，大多数人当这个值超过15%就感觉很不舒服。

    对于那些"可能必须完成的任务"应给于足够的预估。你必须承认项目的中问题可能重复出现。
    对于风险，我们可以选择远离(可能损失利益)，可以包容(预留资金，时间)，可以缓解(减少包容成本)，躲避?(oh,my god，你应该双手合十，向天祈祷)。注意：担心风险并不是风险管理。
    对于包容，你应该首先计算其成本：损失 * 可能性。
    对于致命风险，这不应该是你做的，把它推给你的领导吧。 

    你应该基于N点来进行日程安排，同样，针对客户的承诺，针对项目成员的目标也应基于N点。如果可以，将风险的调查结果公诸于众。 
    对于你不知道的，你要大声问自已：我到底知道什么？
    风险图(前面的不确定性图)：可以帮助你在“一无所知”到“完全确信”之间找到自已的位置。
    对于比较复杂的混合风险，你可以抽取样点来构造风险图(有相应工具)。

    调查显示：项目实际时间是计划时间的1.3倍的可能性至少有一半。
    我们必须允许需求变更，但，合理的需求增量是每1%。
    注意：不要相信新员工马上可以替代老员工，这是愚蠢的假设。
    为了避免规约崩溃，可以通过规约签字来与各方达成共识。
    对于较小团队，个人的生产效率会成为核心风险。

    如何发现风险？
    首先，正确的说出风险。可采取共同发现风险的方式(书中提出若干小花招)，然后构造情况，分析根源。另外，让参与者共同讨论各自的的赢状态来找出难以发现的风险。
    
    然后呢？
    将项目分为多个版本，估计每个版本的EVR，按此来度量完成度。
    采用增量开发，但是注意：
    增量开发中的每个版本必须有实际价值，应该尽量暴露项目中的弱点。对于增量开发的极限情况，做到随时可以交付一个最终版本。增量开发的设计蓝图是必不可少的。
    对于高风险的项目，增量式方法是必不可少的。

    还有什么？ 
    实际上，缓解风险的最佳方法是：提交开发。呵，这个建议可以放之四海皆准。

    How Much? 我们应该际担多大价值的风险?
    成本和收益应该在同一精度上指定，在项目前，我们应该判断是否值得去承担风险。   
    对于项目的价值，不应该建立在对市场的幻想上，我们在努力完成项目的同时，往往忽略了去跟踪它是否实现了收益。
    产品的价值分布在哪里？这需要我们去评估。然后，将价值/成本比较高的放入较早的版本，如果你无法确定其价值，即无法判定版本优先级，那很简单，把问题推给客户。

    价值越高，我们才应该冒更大的风险。很正确的一句话。
    但实际上，现有绝大多数IT公司的哲学是：价值少，那没办法，我们只能压缩成本(时间)。(呵，承担了更大的风险)。实际上，价值确实会决定风险，但影响的应该是项目的选择。

    Whether or not? 你执行了风险管理吗？

石头 于 2006-05-12