小谈项目管理中的问题_项目管理_非技术区_程序员俱乐部

中国优秀的程序员网站程序员频道CXYCLUB技术地图
热搜:
更多>>
 
您所在的位置: 程序员俱乐部 > 非技术区 > 项目管理 > 小谈项目管理中的问题

小谈项目管理中的问题

 2011/10/5 10:50:25  强盗罗吉  程序员俱乐部  我要评论(0)
  • 摘要:在现在这个项目做了有半年的时间了,发现进度远没有想象中的快,什么原因呢?我归纳了一下,主要有下面两点:1.使用敏捷开发2.角色分配敏捷开发,这是现在非常时兴的一个词,听起来挺牛逼的,敏捷,让我们感觉用了它就会快。在被这种开发模式折磨了1年多的我想说,其实它跟其他所有的事情都一样,它有自己适用的领域,假如错误的以为任何项目用敏捷开发都能敏捷,那就是自找苦吃。为什么?敏捷开发的特点就是根据用户的需求迭代,一个迭代解决一个迭代的问题,对于一个对于架构清晰的项目来说,这样每一个迭代都会有一些成果
  • 标签:问题 项目管理 项目

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

  我归纳了一下,主要有下面两点:

  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只为了让自己把问题记录下来在以后的项目中尽量避免,可能想法有些偏激,希望各位网友多多指教,我会虚心学习。

发表评论
用户名: 匿名