新闻风向标常用的项目管理工具有哪些2023/1/15 17:13:45

会呼吸的痛

每一个项目都有不同的生命周期，而不同的项目到底选择哪种开发模式，对你能否顺利将项目进行下去有很大影响。我们可以利用一些工具，帮助我们判断选择比较合适的方法。常用的项目管理工具有哪些因此，这就是选择IT培训的原因，不可否认其带来的积极影响。

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





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


1区：S


需求很明确，使用的技术也很确定。这类项目就是简单的项目(S)


甲方需要什么我们很清楚，我们怎么做也很清楚。


比如注册一个新，需求很明确，手续也很清楚，就那么几步规定动作，因此大量代理机构都可以帮你完成这个项目。


既然需求明确，怎么现也清楚，比较好提前把计划做到位，预测型，也可以成为瀑布型开发模式比较适合。


2区：C


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


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


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


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


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


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


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


3区：C


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


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


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


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


客户懵圈了。


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


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


4区：C


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


如果你遇到这样的项目，比较好的解决办法就是别碰。


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


5区：H


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


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


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


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


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


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


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


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


敏捷开发


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


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


根据图文菜单，客人点了十个菜(根据原型和设计稿，基本确定了需求)后厨开始准备(项目启动)


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


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


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


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


到比较后两盘时，客人要求换两个菜，还好没炒(迭代的好处，随时接受需求变更)客人吃完，很满意(基本满足了全部的要求)


瀑布模型开发


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


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


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


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


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


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


再过了二十分钟，十个菜都一起上来了(项目比较终一次交付)


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


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


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


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


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


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


常用的项目管理工具有哪些就介绍到这啦，比较后一句话送给大家：少研究一些主义，多关注一些际问题。