文章详情

干项目太累,那是因为你姿势不对

任性小编 1个月以前

每一个项目都有不同的生命周期,而不同的项目到底选择哪种开发模式,对你能否顺利将项目进行下去有很大影响。

 

我们可以利用一些工具,帮助我们判断选择最合适的方法。

 

今天给大家介绍一个工具——Stacey矩阵

       3.jpg

 

通过这张图,我们可以简单明了的划分项目,选择相对应的方法行动。

 

1区:Simple

需求很明确,使用的技术也很确定。这类项目就是简单的项目(Simple)
甲方需要什么我们很清楚,我们怎么做也很清楚。
比如注册一个新公司,需求很明确,手续也很清楚,就那么几步规定动作,因此大量代理机构都可以帮你完成这个项目。
既然需求明确,怎么实现也清楚,最好提前把计划做到位,预测型,也可以成为“瀑布型”开发模式最适合。

 

2区:Complex

需求很明确,技术方案并不确定。

也就是说怎么实现不知道,这类项目叫复杂的项目(Complex),也叫棘手的项目。

比如,无人驾驶,这项目需求明确吧?

“无人驾驶”四个字把需求说的明明白白,就是不要人开,车自己会走。

但是“无人驾驶”研究了几十年,各种方法都试过了,一直也没搞定。

直到今天,随着人工智能的发展,才开始让无人驾驶技术逐渐变得现实起来。

所以,像这种需求很明确,技术方案不确定的项目,我们需要用“迭代型”开发,一步步摸索着实现。

 

3区:Complicated

技术很确定,需求却不明确,这类项目是烧脑型的项目(Complicated)。

其实这种项目我们在实际工作中经常会遇到。

比如,客户想让你开发一个软件,问你会什么语言啊?C语言你会吗?Java你会吗?

你说,这些我都会,但是你到底想要一个实现什么功能的软件呢?

客户懵圈了。

如果你遇到这样的项目,那么“增量型”开发就是适合的方法。

先把客户能够确定的、表达清楚的部分做出来,一边做一边想一边交付,一点点增加实现。

 

4区:Chaotic

需求不清楚,怎么实现也不清楚,这叫混乱状态的项目(Chaotic)

如果你遇到这样的项目,最好的解决办法就是——别碰。

远离这种混乱的项目,也是给自己节省点精力。

 

5区:Hazy

就是图中紫色区域,需求不是特别明确,技术方案也不是特别确定。

当我们发现这个项目需求是什么不是特别明确,用什么技术能实现也不是特别明确时,最好用敏捷开发,这种方式也是很多公司在使用的方法。

因为在实际工作中,需求时刻在变,人们对于需求的理解也时刻在变。

而且,随着项目的进行,努力的目标和成功的标准也可能发生变化。

这就意味着项目环境也在不停的变化。

因此,使用“敏捷型”开发,适应性强,灵活机动,拥抱变化。

 

因为现在很多IT公司都采用敏捷开发瀑布开发的模式,所以今天我们来聊聊这两种开发模式的区别。

 

网上流传着一个一个很有趣的“敏捷和瀑布”对比例子,给大家作为阅读参考:

 

敏捷开发

  • 客人到餐馆来点菜(新项目)

  • 不确定客户想吃什么的时候,通常选好餐厅后会先看看餐厅的菜单(客户往往提不出具体的需求)

  • 根据图文菜单,客人点了十个菜(根据原型和设计稿,基本确定了需求)

后厨开始准备(项目启动)

  • 配菜、炒菜,先上了两盘,让客人尝了尝味道(先提供可用实例给客户用)

  • 客人说还不错,后厨继续准备后面的菜,陆续上菜(不断迭代,不断测试)

  • 上菜过程中,客人突然发现有个菜的味道太淡了,让后厨加了点盐又端上来了(敏捷的好处,可以不断测试和需求变更)

  • 又上了两盘,不够辣,又拿到后厨加了辣(敏捷的坏处,需求没有提前明确,反复迭代,增加了工作量)

  • 到最后两盘时,客人要求换两个菜,还好没炒(迭代的好处,随时接受需求变更)

客人吃完,很满意(基本满足了全部的要求)

 

 

瀑布模型开发

  • 客人到餐馆来点菜(新项目)

  • 不确定客户想吃什么的时候,通常选好餐厅后会先看看餐厅的菜单(客户往往提不出具体的需求)

  • 根据图文菜单,客人点了十个菜(根据原型和设计稿,基本确定了需求)

  • 后厨开始准备(项目启动)

  • 根据客人的下单配菜,炒菜(基本上不会主动去了解完整需求)

  • 半个小时了,菜还没上桌,客人饿极了(项目启动后很长一段时间客户什么都看不到)

  • 再过了二十分钟,十个菜都一起上来了(项目最终一次交付)

  • 客人说,有几个菜挺好的,但是有个菜味道淡了,有两个不够辣,还有两盘重复了想换掉(我是买单的,我要变需求)

  • 这时候大堂经理来了,说,“味道淡了可以加盐,不辣可以加辣,但是换菜不行,已经炒好的那两盘菜也是要算成本的”(瀑布的坏处,需求变更比较麻烦)

  • 于是,后厨只给客户加了盐,加了辣

  • 客人吃完,不是很满意,下次不来了(没有满足需求)

 

 

总的来说,在现在管理项目过程中,并没有严格的按照完全的敏捷或者完全的瀑布模式,都是各自掺杂了其他的方式。

 

在实际项目过程中,过于强调模式并没有意义,重要的是能不能预防问题的发生,在问题发生之后能不能用最小的成本解决,模式更多起一个参考作用。

 

最后一句话送给大家:少研究一些主义,多关注一些实际问题。


阅读 71
0
0
收藏成功