浅析软件项目管理中的小问题

在现在这个项目做了有半年的时间了，发现进度远没有想象中的快，什么原因呢?

按需求定制设计可以根据自己的需求进行定制，做网站、成都网站制作构思过程中功能建设理应排到主要部位公司做网站、成都网站制作的运用实际效果公司网站制作网站建立与制做的实际意义

我归纳了一下，主要有下面两点：

1.使用敏捷开发

2.角色分配

敏捷开发，这是现在非常时兴的一个词，听起来挺牛逼的，敏捷，让我们感觉用了它就会“快”。在被这种开发模式折磨了1年多的我想说，其实它跟其他所有的事情都一样，它有自己适用的领域，假如错误的以为任何项目用敏捷开发都能敏捷，那就是自找苦吃。

为什么?敏捷开发的特点就是根据用户的需求迭代，一个迭代解决一个迭代的问题，对于一个对于架构清晰的项目来说，这样每一个迭代都会有一些成果。而对于有些项目而言，比如说杀毒软件，磁盘分析器等等，对于这种产品类的项目，很多时候它的需求都是一开始需要定义清楚的，客户名义上是广大的PC用户，实际上是PM或是PGM，PM说这个项目里面我们要做3个功能，那我们就需要做3个功能，多一个不行，少一个也不行，如果PGM在你做了3个功能后告诉你，要加一个功能，而且这个功能在旧的架构上是很难实现的，那么这个PGM就是不合格的，为什么?因为他加大了项目的成本。所以，我想说的是，如果需求是由我们自己定义，而且我们很清楚要做一个什么东西的时候了，采用敏捷开发的风险可能会加大，因为它过多的依赖于“迭代”，认为迭代可以解决大多数的问题，可是实际情况远不如此乐观!当你的PM对你我们要加这个新功能，之前的定义的功能不行这个迭代要改的时候，作为一个程序员，我们能做什么呢?去跟PM说，对不起，我们之前的底层架构不支持这种变态的需求，PM会告诉你，我就是代表客户，这个功能就得这么做，我说了算，为什么不支持，我们不是采用的敏捷开发吗，敏捷开发的特点不是迭代来解决问题吗?

老实说，瀑布模型的好处之一，就是你的PM可以少几个变需求的理由，PM一个星期变一次需求，我们程序员就没有幸福可言了，所以，我想劝有些项目经理，别拿需求的变更当做理所应当的，你不是一个娇生惯养的小孩，没有必要变的需求就不要变，如果你把敏捷开发的需求变更当做是你隔三差五变需求的理由，那下个项目，当你的程序员听说你要用敏捷开发，肯定想抱头痛哭。你是产品的设计师，这个产品的外观功能，应该一开始就定义好，不要前一个月说要做个电饭煲，这个月又说要在电饭煲加个微波炉的功能，如果你手下的程序员任劳任怨，把微波炉的功能真的加进了电饭煲，那只能说PM幸运，碰到了技术牛人，并且技术确实是可行的，但是如果功能实现不了，那么PM可能就怪开发者，觉得他们技术不行，心想我用的是敏捷开发，为什么我给了你们时间缺不能解决问题呢?

时间确实是可以解决问题，但是作为开发者更希望把时间多花在需求分析阶段，而不是修改旧的代码上。

开发模型只是一种工具，依赖敏捷开发这个工具，并不是解决所有问题的万金油。

作为项目经理，你不光要对客户负责，更需要对产品负责，对你手下的程序员负责。其实，假如做不到后面两点***点也不好做到，因为项目很可能经常delay，到***客户不满意，或者产品上线的时候早已经落于市场上其他的产品。

角色分配的问题在整个软件开发过程也是很重要的，说简单点就是分工要明确，按照博弈论的观点，假如我们每个人的目标都是合理的，那么我们通过相互的制约很好的推进项目的周期，但是如果角色分配的不合理，比如说职责重复，缺少角色等等，那么开发的过程中就会遇到很多利益冲突，解决不好，就容易导致团队不和谐，没有凝聚力等等，最严重的情况就是大家各自为政，都听不进别人的意见，大家都是会为别人着想的人，但是有时候想得太多，总是会觉得不合理，不公平，难免影响工作情绪。

在我现在这个项目就有类似的问题，首先，就是没有一个架构设计人员，经验丰富的开发和经验较浅的开发做的事情是差不多的，整体架构的设计名义上是大家一起来做，但是在开发过程中就发现了问题，对于一个架构变动，没有人有决策能力，TM只会说，有问题跟我说，然后你发现了问题告诉他，他却不知道和谁来商量，经过和一个个的开发者进行了讨论，认为这个架构的变更确实是必须并且可行的时候又要开一次会，来讨论怎么来做这个变更，由谁来负责这个变更，所以说，SD是必须的。而在一次会议上我听别人说做SD必须要有10年的经验，我觉得有点可笑，有很多优秀的开发在很早就做上了架构师，我认识的人里面就有一个，其实我觉得逻辑思维能力较强，有整体架构思想，并且对项目中使用技术有一定研究就可以做SD了，倒是我不明白现在为什么很多软件公司都特别在乎工作年限，认为做了10年IT就是万金油了，什么事情都可以解决，真是大错特错。

我认为，做什么事情都有一个精与不精的区别，假如那句什么语言不重要，重要的是思想，一通百通的话我觉得真是没什么意义。我们都知道C和JAVA.NET的侧重点不一样，一个偏向底层，一个偏向应用，让一个做C做了10的人去做一个网站可能都做不好，为什么?因为他没有对网站应用根本就不了解，用户需要什么他都不知道，他脑袋想的只是如何使用户体验更加的绚，但是却不知道网页上能不能实现这个绚的效果，网页上上传做个进度条能不能实现，实现的难度大不大，他都不知道，这样的架构师能做好网站吗。同样让.NET程序员去做JAVA的事情也不一定做的好。闻道有先后，术业有专攻，这句话是有道理滴。

角色分配的问题还体现在我们不能越庖代厨，如果你是RD，你就不要过多的去摆弄需求，觉得需求不该这么做，因为这个问题不该你想，想这个问题只是浪费时间，如果你是PM，你就不要过问架构和技术细节，因为你始终不如开发了解实际的问题，如果你是一个做了十几年开发的PM，自己手下的技术不如自己，硬要按照自己的想法去做事，那么不要做PM，你可以做个SD。我以前就碰到过这样一个PM，让我去做一个图片处理的程序，他想让我把一张图变清晰，我觉得一张从100K压缩成了10K的图你还想让他变清晰仿佛是不可能的事情，用脚趾头想问题也知道那丢的90K是干什么的，PM要我多测试几次，经过测试确实是不可行的，但是PM不相信，因为他做了一年多的开发，于是中午不吃饭跑到我的机器上写代码，口中还念念有词的，等我吃完饭睡好午觉，他终于认输了，虽然如此，但是从这件事上我就觉得有点不痛快，多的就不想说了。

上面我对自己项目中的问题做出的一点总结，也算是一点牢骚吧，作为一个小小的RD只为了让自己把问题记录下来在以后的项目中尽量避免，可能想法有些偏激，希望各位网友多多指教，我会虚心学习。

原文链接：http://www.cnblogs.com/nero/archive/2011/07/04/2097030.html

【编辑推荐】

1. 新手软件项目经理该如何入门
2. 项目经理的力量应该从哪里来？
3. 软件项目管理总体流程设计
4. 新手软件项目经理之***期限的迷局
5. 软件项目经理该不该多一些人情味

本文题目：浅析软件项目管理中的小问题
路径分享：http://www.gawzjz.com/qtweb/news15/183665.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联