1.敏捷开发
  • 客人到餐馆来点菜(新项目)
  • 不确定客户想吃什么的时候,通常选好餐厅后会先看看餐厅的菜单(客户往往提不出具体的需求)
  • 根据图文菜单,客人点了是个菜(根据原型和设计稿,基本确定了需求)
  • 后厨开始准备(项目启动)
  • 配菜、炒菜,先上了两盘,让客人尝了尝味道(先提供可用实例给客户用)
  • 客人说还不错,后厨继续准备后面的菜,陆续上菜(不断迭代,不断测试)
  • 上菜过程中,客人突然发现有个菜的味道太淡了,让后厨加了点盐又端上来了(敏捷的好处,可以不断测试和需求变更)
  • 又上了两盘,不够辣,又拿到后厨加了辣(敏捷的坏处,需求没有提前明确,反复迭代,增加了工作量)
  • 到最后两盘时,客人要求换两个菜,还好没炒(迭代的好处,随时接受需求变更)
  • 客人吃完,很满意(基本满足了全部的要求)
    (在举个例子)
打个比方,客户说他想要造一座金字塔,你作为“咨询师”,认为这座金字塔要造10年,肯定不能指望一次设计好就一口气做完,于是问客户这个金字塔是要干什么?客户说要当坟墓,于是,你提出先做一个小坟墓的功能,能装木乃伊那种。客户同意了,你哐哧哐哧做了一个月,制造了一个小型地下墓室,演示给客户看,客户看了,一拍大腿,说看到这个墓室才想明白,其实他要的不是金字塔,要的是一个有排场的墓地,这样简陋埋在地下的墓室不够牛逼,于是你和客户达成第二阶段设计,做一个带兵马俑方阵来让这个墓地显得有排场,客户同意了,于是你又哐哧哐哧做了一个月,做了一个小型兵马俑方阵。客户看了兵马俑方阵,又一拍大腿,说这个方阵还真牛逼,但是能不能增加一些现代元素,把古代兵马俑换成现代装甲兵团,你于是又……(如此,周而复始,每个阶段只完成客户一个需要,当然,我上面只是一个荒诞的例子,但是你应该能够get到敏捷的含义。)
2.瀑布模型开发
  • 客人到餐馆来点菜(新项目)
  • 不确定客户想吃什么的时候,通常选好餐厅后会先看看餐厅的菜单(客户往往提不出具体的需求)
  • 根据图文菜单,客人点了十个菜(根据原型和设计稿,基本确定了需求)
  • 后厨开始准备(项目启动)
  • 根据客人的下单配菜,炒菜(基本上不会主动去了解完整需求)
  • 半个小时了,菜还没上桌,客人饿极了(项目启动后很长一段时间客户什么都看不到)
  • 再过了二十分钟,十个菜都一起上来了(项目最终一次交付)
  • 客人说,有几个菜挺好的,但是有个菜味道淡了,有两个不够辣,还有两盘重复了想换掉(我是买单的,我- 要变需求)
  • 这时候大堂经理来了,说,“味道淡了可以加盐,不辣可以加辣,但是换菜不行,已经炒好的那两盘菜也是要算成本的”(瀑布的坏处,需求变更比较麻烦)
  • 于是,后厨只给客户加了盐,加了辣
  • 客人吃完,不是很满意,下次不来了(没有满足需求)
3、总结

但总的来说,在现在管理项目过程中,并没有严格的按照完全的敏捷或者完全的瀑布模式,都是各自掺杂了其他的方式。在实际项目过程中,过于强调模式并没有意义,重要的是能不能预防问题的发生,在问题发生之后能不能用最小的成本解决,模式更多起一个参考作用

最后借用民国时候的一句话:少研究一些主义,多关注一些实际问题(net)

作者:zhaur
链接:https://www.jianshu.com/p/ca5f242cf2bb
来源:简书
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。