IT项目管理的一些心得

简介:

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

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

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

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

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











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



相关文章
|
7月前
|
前端开发 项目管理 数据库
项目管理初识
介绍了下软件项目管理方面的一些做法
70 3
|
24天前
|
项目管理
项目管理
项目管理
29 2
|
2月前
|
敏捷开发 监控 数据可视化
项目经理必看:竞争性项目怎么管理?项目管理知识领域有哪些
在现代企业中,项目管理不仅是技能,更是战略。特别是在竞争性项目中,高效管理时间、资源和团队成为企业成功的关键。本文介绍了竞争性项目的特点、管理步骤及十大知识领域,并推荐了板栗看板企业版作为高效的管理工具。
30 0
|
7月前
|
项目管理
项目管理-需求管理
项目的本质是使用最少的成本完成项目需求。
|
7月前
|
项目管理
项目管理与软件维护部分
项目管理与软件维护部分
75 0
|
缓存 安全 中间件
【项目管理】
【项目管理】
109 0
|
资源调度 项目管理 开发工具
|
项目管理
艾伟也谈项目管理,项目管理实战之团队管理
  一个系统不仅需要优秀的分析和设计,更需要一个良好的过程将其从蓝图转化为实现。这个过程中最重要的是对团队的管理,也就是人的管理。一个优秀的团队和一个糟糕的团队的效能是天壤之别,她们之间的比例不是1:100或1:1000这样量化的数字能够表示的。
942 0
|
项目管理
艾伟也谈项目管理,项目管理有感之需求调研
  一个项目中需求调研的充分与否是项目日后成败的关键要素之一,这一点我想没有哪位项目经理不认同吧?不过咱说的需求调研可不只是拿张纸记记客户说什么就完了,调研顾名思义就是调查和研究客户的想法,我感觉应从以下几个步骤入手:   1、客户想要什么?   2、要这干什么?   3、为什么这么想?   4、会不会有别的想法?   这里也说一个最最最最基本的,只谈项目别谈钱,我们可以说,价钱嘛需要我们回去详细的分析过您的需求后再给您提供一个整体的解决方案,您放心价钱一 定合理,不会超出您的预算(真超了再说)。
1042 0
|
项目管理
13.项目管理
脑图如下所示:
869 0