[原创]项目管理渴望规范化

  作者:一孑
2008/12/23 10:13:47
本文关键字: 畅享原创

PM会经常遇到半路接手的项目,此类项目如果规模不大,还算好办,如果遇到一个比较复杂且周期较长的项目,可能就会比较头疼。很多问题不知从何着手予以解决,也不知解决了此问题是否还会引发其它的问题,手头资料一大堆,真正有帮助的又不知道有哪些?项目的进展完全依赖于项目组的“老”同志,老人员的流失对项目而言将是“灭顶之灾”,很多内容需要重新发现、整理、解决。再加之如果项目有压力,那PM主要的工作就是在补洞了,被项目所牵制,而无法真正的主动地规划项目、推进项目。最终,也只能马虎上线,遇到问题再说吧。

其实,类似这种不规范的项目管理行为,对自身的项目也会造成很多影响,多数情况下是项目进展到一半的时候,问题就开始暴露了,如果再不加以重视,实际上最终的结果也会和前面描述的差不多了,可谓苦不堪言啊。

需要与很多人沟通过这个问题,大部分人都认为是管理所造成的,如果说建立规范的管理制度,100%的人员都赞同,但真正你去建立并推行之时,却又发现实际并非如此,阻力极大,困难重重,当初赞同的人也开始有了反对意见,仔细分析无非以下几点:

1、  项目压力大,进度紧;

2、  规范永远是对下不对上,所以最终“下面”的人也不规范了;

3、  规范不合理,弊大于利,对正常工作造成了影响;

4、  规范是好,但不切实际,应用难度大;

规范制度是一把双刃剑,用的好,获益匪浅,用的不好,无疑是给自己准备的带刃的剑。实际上,规范也好,制度也罢,都是服务于管理者与被管理者的,而且是要有效组织生产关系,提高生产力的。那么,对PM而言如何去制定一个适合自己团队的规范呢,哪些是必要的,哪些是可要可不要的,哪些又是累赘呢,简而言之可以从几点来考虑:

首先:切记,规范不是拿来主义,别人用的好的,到了你这里未必适合,一定要分析自己的项目规模、团队大小、团队组织结构、团队素质能力等等,才可确定到底该如何去制定规范。这里要明确说的就是团队素质问题,团队素质并非是指其专业能力,也并非指其人的素质能力,而是指其工作背景,是否具备此方面的工作经验和工作习惯,毕竟程序员的随意性和自我意识都是比较强的,突然给出一个框框,员工会很不适应的,造成的抵触影响也会很大。

其次,规范是否真的有效,还是就是走一个形式,每一种规范到底的目的是什么,是否能真的为我们带来什么好处呢?是否在制定一种规范前,都认真考虑过它呢?并且是从管理者和被管理者两个角度来考虑呢?工作日志,有助于帮助管理者跟踪工作进展,发现问题,对于被管理者有助于提升自己的工作效率,总结自己的工作业绩,甚至在写自己的工作汇报时都可做为参考。那其它的规范呢?例会是很有必要的,那例会的议题和例会的周期确定了么?确定的合适么?曾经有个项目是以天为单位的例会,主要内容就是工作汇报,我个人觉得意义不大,因为划分工作任务的最小完成周期也是三天以上,基本上每天的例会都在重复昨天的内容,连说的都一样,浪费大家的时间。但为什么不去考虑改变呢?或者换种方式来进行。

再次,规范是帮助团队的,这个帮助主要是体现在:提高团队沟通有效性、增强团队协作性、规范团队工作行为、规范工作边界,杜绝隐患发生,提前暴露风险等等,但绝对不是增加团队工作量的,增加团队工作复杂度的,搞个工作流程出来要简单有效,划分责任边界,加强沟通,提升效率,不是搞个流程出来把大家搞晕了,如果用几句话都讲不明白的规范制度,不要也罢。

最后,也最为重要,规范推行一定要慎重,可行可不行的就应该放弃,既然规范制定了就一定要执行下去,不能半途而废,这样极不利于后期的工作。即使规范不多,但有效,大家都可以执行就是好的,要知道规范是双刃剑,毕竟是有弊处的。

在此总结了一些常见的内容,因为做了尽可能的拆解,所以彼此没有太多的关联,仅供参考,希望对大家有所帮助。

1) 、计划管理:可要可不要需要针对项目的具体情况来具体分析。但不需要计划管理,并不意味着不要计划了,明确这一点。如果采用工具,首推MS Project。

2) 、工作日志:必要。无论项目大小都很重要。并且一定要将工作日志的内容与工作任务进行结合,以实现进度跟踪。针对突发性、临时性的任务,也可由工作日志提交,PM汇总从而得到最终的项目进度。如果采用工具,则还是建议使用projectserver来完成。工作日志一定要看,发现其中的问题,很多时候程序员都会通过工作日志来反映问题及风险,认真对待,不要马虎,你马虎,就代表了团队也会马虎的,也不要让你自己的不经意行为打击了团队的积极性。

3) 、需求管理:必要,项目的质量就是需求来明确的。需求管理的方式很多,选择适合自己的,但一定要有,并且一定要考虑到后期需求维护占总工作任务的比重,不要因为后期的时间紧而放弃维护。如果采用工具,则建议使用RequisitePro,RequisitePro可以实现project的数据共享,但好像是单向的。

4) 、版本控制:必要。如果采用微软的技术体系,建议使用微软的VSS,如果是其它技术体系,自由选择吧,CVS很不错。不建议采用并行开发,然后在合并代码。版本控制有时会很复杂,尤其是针对上线项目进行的二次开发,宁可多做点工作,不要搞出一个太复杂的流程,还是那句话,不要把团队搞晕了。

5) 、变更控制:必要。不多说了,尤其项目到了后期,每次的变更都一定要做记录,且要认真分析。

6)、编码规范:必要。如果什么都没有,代码就是你的财富了,所以重视起来吧。

7) 、 风险控制:可要可不要,针对小且风险低的项目,建议变换方式,可以做一个技术问题风险清单,其它的可以放弃。如果觉得风险控制难度大,太抽象,则自己整理一个项目问题列表出来,包括项目中遇到的所有问题及解决方案。

8) 、验收制度:必要。可以根据实际情况控制验收单位的颗粒度。但一定要有,确保有效工作成果的提交,不要走回头路,这是最后的可控环节。其中包括了测试管理。针对测试如何来做,是要依据团队能力及项目其它要素来制定的,不过一定要有,要做为验收的依据使用。

9)、沟通管理:可要可不要,视项目团队而定。没有沟通管理并不意味着没有沟通,这方面要靠PM主动。古人有句话“前人栽树 后人乘凉”,项目管理亦是如此。PM不会跟着项目一直走下去,会交出项目的,同时你也会接受别人的项目,团队也是铁打的营盘流水的兵,所以,做好这些工作吧,于人于己都是有必要的,说的大一点,还可以为提升整个行业的规范性奉献自己的努力呢,何乐而不为呢?

责编:穆琳琳
vsharing微信扫一扫实时了解行业动态
portalart微信扫一扫分享本文给好友

畅享
首页
返回
顶部
×
    信息化规划
    IT总包
    供应商选型
    IT监理
    开发维护外包
    评估维权
客服电话
400-698-9918