IT项目管理的一些心得

简介:

工作多年,也有一些项目管理经验,在此总结一些自己对于项目管理的看法。 
开始阶段
项目启动的时候,个人认为最重要的是要弄清楚项目的目标和项目的范围,包括需求范围和时间范围。 
通常,我最怕听到领导说:“把这个工作做一下,需求大概是balabala”,“啥时要?”,“不知道,你先做着,尽快吧。”这种场景经常会出现,由于没有明确的需求和时间约束,有时候就会无法分解工作包,导致无法安排人去做。 
这种情况相信在大多数人身上都有发生,这时候只能根据个人的经验从有限的需求说明中推算出大致的需求,还要估算一个合理的时间,因为虽然领导没指定具体的时间,但不意味着无限期的时间,总是得有个大概的范围。 
关于项目需求的收集,有时候急于心切想一下子获取全部的需求,但是大多数情况下,这是难以做到的。因此我总是确定一些大的需求方向,通过滚动规划,渐进明细的方针,逐步细化这些需求。使得需求的细节尽量在大方向之内。如果时间允许的话,可以先构造一个原型,通过原型能更好的把握项目的需求以及面临的风险。

关于技术框架架构的选择
通常情况,总是选择成熟好用的框架作为首选。事实上,我工作过的公司,都有自己的一套框架,大多项目都遵循这套框架,这些框架都经受了生产环境的考验,因此所面临的风险是最小的。有时候,会觉得这个框架真土,或者太烂,而花太多的时间在修改框架上,但是这在我看来不是最重要的。框架的目的是把程序员拉到流水线上,提高生产力,越复杂的框架对性能的影响也越大,理论上说,不使用框架的代码性能最好,但是可读性差,不易于管理,因此不得不使用一个良好的框架来组织代码。 
举个例子,本人曾经历过的一个项目,觉得是过度设计了框架,有点为设计而设计的味道,框架设计者为了实现解耦,将系统拆分的极度松散,以至于调用某些类库的时候还得依靠反射等方式,而为了完成一个功能业务,常常要在十几个项目中修改许多不同的文件。且不说对系统性能的影响,单单对开发人员的开发体验就很糟糕,疲于在各个工程项中查找要修改的文件。通俗的说,解耦的主要目的之一是实现代码复用,诚然,框架解耦的目的确实达到了,但是又怎样呢?从来没有后期的项目会使用这些解耦的子项目,因为系统业务一旦复杂后,虽然竭尽全力的避免,但是还是会有功能模块相互交织,根本不能独立出来作为一个DLL供给其他项目使用。事实上每到新项目开始的时候,多数情况下还是采用原始的复制代码的方式,而不是直接采用某个dll。解耦的另一个目的是减少系统的关联度,使得修改程序的时候能更简单,这是书上读到的。但是事实上,我觉得跟本不是这么回事,任何更改,如果是简单的代码更改,即使耦合度高的系统,也是很快能改进,而如果出现了较为复杂的业务更改,低耦合度也降低不了改动的规模。当然在此并不是否定解耦不好,只是说明一下,系统设计的时候,要综合考虑,而不是书上说什么就是什么,在我看来,保持KISS原则会让我省心不少。

团队建设
项目经理的主要工作之一就是将任务分解成工作包,然后分配给个人。本人喜欢的方法是开个会,大家一起商量,评估工作时间,认领任务。个人比较喜欢自下而上的方式,即项目成员各自确定各自的任务和时间后,汇总给我,然如有必要,稍做一下微调。自下而上的方式比较民主,大家也乐意接受。相对而言,自上而下的分配工作,有点“闭门造车”的感觉,不清楚团队成员的情况。关于开发模式,本人也经历过多种方式,比如瀑布模式,迭代式等等,个人觉得比较死板,尤其是当年做日本项目的时候,瀑布式开发使得我写了一堆没有实际价值的文档。 
个人喜欢目前流行的方式——敏捷开发。因为其快速响应,随时应对变化,注重实用性而不是文档,选择敏捷开发模式,最好是在团队成员个个都水平较高的时候采用,如果团队成员一堆应届生,一问三不知,那么怎么也敏捷不起来的。因此,对于这种情况下,我通常会采用结对编程的方式。实践出真知,个人感觉结对编程的效率是非常的高,而且可以互相学习技术,互相了解业务,个人非常推荐这种做法。选择怎样的开发模式和管理方法,就会建设出怎样的团队。

风险和变更范围
通常情况下,在做准备工作的时候,尽量的预估一下风险,风险包括技术上可实现性,人力资源的可用性和项目变更的预判。这点是经常会忽略,技术不是万能,面对有些苛刻的场合不一定能实现,这个风险要尽早的发现,考虑生成一份备选方案,最好做出原型来证明方案的可用性。而项目的变更对于开发者来说是家常便饭,但是最好把变更权控制在自己的手中,领导的旨意常常是不能拒绝的,但是也要以理力争,尽量通过邮件,IM聊天记录等确认变更,因为这可以作为变更证据,而不用通过口头叙述,尽量避免范围蔓延和“项目镀金”,不然到时时间来不及背黑锅的就是你了。

最后,对每一个项目都总结一下经验校训,无论是技术上的和非技术上的,对于以后的项目也是大有裨益的。以上是本人的一些经验分享。











本文转自cnn23711151CTO博客,原文链接:http://blog.51cto.com/cnn237111/1317922 ,如需转载请自行联系原作者



相关文章
|
17天前
|
前端开发 项目管理 数据库
项目管理初识
介绍了下软件项目管理方面的一些做法
28 3
|
5天前
|
项目管理
项目管理-需求管理
项目的本质是使用最少的成本完成项目需求。
|
3月前
|
项目管理
项目管理与软件维护部分
项目管理与软件维护部分
32 0
|
11月前
|
缓存 安全 中间件
【项目管理】
【项目管理】
YU0
|
测试技术 项目管理 开发工具
项目管理-软件配置管理
学习笔记、记录分享
YU0
260 0
|
敏捷开发 项目管理
项目管理
项目管理
173 0
项目管理
|
项目管理
漫谈项目管理之:什么样的项目才是成功的?
什么样的项目才是成功的? 这个问题和项目“验收”没有关系,在天朝这个市场里,如果你的项目连验收都无法通过,那么笔者建议你还是改行吧!但是,当项目做完的时候,并且做到了什么程度,你完全可以在心里对自己说“哇塞,这个项目真的很成功啊!” 那笔者会问你,成功的标准是什么?盈利?客户满意?实现了既定的目标?完成了一次别人觉得不可完成的项目?...... 我们先看一个“理论上的”成功标准,也就是项目管理中常用到的“铁三角”理论,一个项目做完了,只要完成了既定的目标,又没有超出预算,并且按照进度要求做完了,项目就算是成功的,至少你不用担心你的老板或者客户骂你了。
2171 0
|
项目管理
13.项目管理
脑图如下所示:
844 0
|
项目管理 开发框架