艾伟也谈项目管理,我的项目管理观点

   
公司要我给项目经理做一个培训,关于项目经理的做事情的方法和观点方面。我就采用了Workshop的方式,Workshop不是会议模式,而是侧重于交流会谈的一种模式,毕竟大家都是项目经理,并非说我的做法就是对的,所有的一切都是自己的经验之谈,所以我只是说大家彼此分享经验,交流心得。我把我所要分析的内容大概做了一个讲义,也希望更多人能够参与到这个Workshop中。
项目经理好做吗?
    
项目经理好做吗?好做!项目经理好做吗?不好做。不同的人、不同的态度、不同的方法,其结果也就存在有极大的差异。有些人做项目经理,任务来了,不管三七二十一,就像切蛋糕一样,平均切开,然后清点一下团队人员,每人都平均拿一块走,自己坐着等他们的结果,如果客户有问题过来了,他轻轻点击一下邮件转送,事情就算是安排好了。任务安排地多么轻松自如,自己闲暇之时品茗聊天,你说这样的项目经理能不好做吗?另外一种项目经理是大事小事事事关心,项目开发所有的内容也都熟记于心,任务也按照个人能力合理安排,可惜操心劳碌之命,总觉的底下的人做事不保险,恨不得天天拿着鞭子在他们后面抽赶他们,搞得全部人员人心惶惶,这样的项目经理,估计一个项目完了,头部就白掉一部分,用不了多少个项目,也就白发苍苍。
   
上面所列举的两个现象是乎有点极端,但是在实际的项目过程中却常常发生,当然他们的结果也不相同,前者项目估计失败的多成功的少,后者成功相应要多。但是作为项目经理来说,我们首要保证的是项目本身,如果说项目能够按时、高质完成,并且项目的盈利情况也能够达到预期设想,那么无论采用那种办法都是可取的。在实际中,项目经理所要完成的工作和承当的责任应该说是整个项目组中最关键的部分,所以也就很难有喝茶、转信如此好的日子可过,毕竟他们所要做的工作和承当的压力是和他们的工资成正比。
如何看待估算
   
不少的项目在项目总结的时候会发现,投入的人员和前期的工数估算存在有比较大的差异,有甚者达到3-4倍的差值。为什么会如此呢?可能过程中的原因很多,有前期估算不足、中途客户变更频繁、人员能力不够等等因素。这些因素中,前期的估算是一个比较严重的问题,一方面估算是在项目还启动阶段和客户确立的关于项目整体时间的预计,如果估算出问题,给客户留有的影响也就比较糟糕,相当于开了一个坏头,另外一方面估算还涉及到整个项目的成本问题,谈到钱的事情就不可大意。
   
那么该如何去做估算呢?有些人觉得少要一点,这样可以给客户留一个好印象,看我们的能力多好,这么快就可以做完;有些人就漫天要价,工数高的把客户都吓跑了。工数估算的时候有一个比较基本的原则,就是尽量接近实际的值,越接近实际就越能够体现你的专业。并不是说工数越少客户就会越高兴,就像买东西一样,假如现在有人说黄金一克50块卖给你,估计所有的人都会觉得这是假货。客户的心理都是一样,在工数估算上需要的是合理的数值,这样他们才安心,至于实际合同上签署多少工数,那是商务上的事情,可能客户的预算少了,但是我们工数总的是不能变动,不过可以给个折扣。这样项目至少在启动阶段就不是带着一个不实际的计划进行。
   
如何能够做好估算,这个问题的确很难,如果我们要做好估算,首先需要非常清楚地了解客户的需求,这也就要求项目经理要在前期投入相对要高。在前期的估算的时候需要考虑业务和技术上的各个细节问题,所以尽可能让项目经理和团队成员的投入参与。在估算阶段把问题都分析仔细,一方面能够确保估算合理,另外一方面能够在前期做好分析工作。
要会管账
     
工数算得合理,那么也要保证投入的人员合理。有些项目投入人员的比例失调的比较严重,估算中5人/月的项目,本来按照计划是2人两个月多一点,结果投入了5个人做,时间还是两个半月多。这样项目虽然完成了,但是由于投入的人员超额,也就造成成本的增加。对于这些帐,项目经理要学会管。
   
项目经理到底是否需要有成本意识,我个人的认为是需要的。毕竟作为企业来说,所有的项目都有成本核算存在,所以项目经理需要清除知道自己的团队是否在为公司盈利,这样也能够清除知道自己的团队对于公司的重要性和今后的发现机会。
    
不少人会反驳我现在团队的都是一些Junior的人员,如果都是大牛的话,我也就不需要那么多人了。确实,Junior和Senior的工作质量和结果不具有可比性,但是人员的冗余需要有个尺度,不能无限冗余,如果Junior的能力不行,可以添加一个备份人员,但是不能每个人都有一个备份,如果是这样,那么项目经理就需要思考一下工作安排上的问题。
不要苦劳、要功劳
    
有项目组天天加班,夜夜加班,到最后团队成员都快成木头人了。加班是软件开发过程中时常遇到的问题,很难避免。项目加班的原因也非常多,但是不管何种原因,项目经理都应该很清楚知道问题的根源。
    
如果你所做的项目是公司的战略性的项目,为了赢得客户,所以公司下来死命令一定要完成,不惜任何代价,那么这样的项目团队属于打头炮型的,辛苦攻坚,很难扭转的局面,那么这样的项目在启动的时候就应该和公司上层和团队成员都沟通到位,说明可能出现的加班局面,同时安抚好团队成员,替成员向公司申请该有的福利。
    
有些项目由于估算的失误或则客户的问题造成的大量加班,很多项目经理没有把问题即使反馈出来,只是强调团队需要完成任务,这种现象属于责任不到位,而对于团队的成员来说,很多情况属于吃力不讨好的局面。他们日以继夜的加班,但是最后公司核算成本的时候往往是效率最低的部分,所以这种苦劳还是需要项目经理小心处理。
     
我说过笨的人才加班?这句话多少有点偏激,但是加班主要分为三种情况,第一是工作量安排过多,已经超过你在正常时间内能够完成的量,而在确定工作的时候你并没有反馈说你有困难,默默承受,表明上你吃了哑巴亏,工作的心多好,但是你这样会影响到整个团队的工作安排和计划,从而给别人造成加班的因素,如果你提出了,但是工作还是按照这样安排,那不是你的问题,加班也是被迫无奈的做法。另外一种属于工作能力的问题,如果因为你的能力造成你的工作无法按时完成,那也就自己笨,感觉需要学习弥补不足。第三中属于自己希望把工作做好的,需要多了解一些项目的内容,或则学习各种不足,这种做法虽然不算笨,不过也算是有愚公移山的精神。
     
不要认为自己的团队天天加班就有人能够看得见,有人能够体谅你,如果不是你预先提出加班的问题,那么后期出现的突然性加班的话,从另外一个角度来看更多的目光会落在:项目管理有问题?人员有问题?所以团队成员累死累活,到头来往往会被扣上能力差的帽子。而且到了年底的,所有项目核算之后,加薪和奖金发放的时候,即便你再多地提你们一年到头多辛苦,那些最多的来一些同情的目光,但是实质性的东西往往没有。所以评价一个团队的好坏,效率是最关键的。能够给公司带来丰厚效率的团队,说话的底气也就不一样。通过做好项目,让客户能够满意,为公司获得最大的效益,为团队成员争取到最大的利益,达到三方获利的局面。所以我们的团队不要苦劳,我们要用最大的能力给公司创造最大的效率,获得功劳。
项目经理需要技术吗?
     
项目经理需要技术吗?这个主要看项目的规模,大规模的项目可以不需要项目经理有技术,可能更侧重于管理和协调。对于中小规模的项目,项目经理应该具备有相应的技术能力,特别是规模越小的项目,这种要求可能越高。
     
首先由于规模小,人员配备就存在有一人充当多个角色的情况,那么只有一个项目经理的外行带领几个所谓的内行工作,这样在管理上就存在有比较严重的问题,项目经理对项目的技术难点和风险就很难把控,所以工作安排上就很难做到避重就轻,让全部人员能够合理的进行,对于技术上的问题,很容易造成因为因为没有合理安排人员解决技术难道,出现整个团队都在等待的局面。
     
如何才能安排好工作,这需要安排的人理解工作的内容和问题,这样才能有比较合理的安排,如果对于大的团队可能有另外安排的人员协助处理,但是对于小的团队来说,可能就需要项目经理独立完成,不管如何,都要避免出现外行领导内行的局面。所以每个项目经理的定位在于自己所代理的团队,评估自己的能力,如果能力存在缺陷,则加紧时间补上。

时间: 2024-10-24 17:30:55

艾伟也谈项目管理,我的项目管理观点的相关文章

艾伟也谈项目管理,软件架构引言之项目管理的问题

软件架构引言之项目管理的问题   很多朋友都有过或者正在管理一个或者多个软件项目,那么我的文章就从这个问题开始:如果单纯从表象来说,软件项目管理过程中暴露的最大问题是什么?   不同的人的会有不同的答案,但是大致这样的答案我想大部分人都是会认可的,那就是"进度拖延".进度拖延当然是表象之一了,其他诸如质量不过关.功能不完整等等,我觉得都是和进度拖延密切相关的.很多项目经理都想去做那些认为是十分必要的事情,比如计划.测试等,但是"没有时间".为什么会没有时间?等到项目

艾伟也谈项目管理,我是如何带领团队开发项目的

最近有不少朋友写信问我一些关于团队开发的问题,由于这段时间有些忙,没有回复.今天写一篇这方面的文章向大家介绍一下我是如何带领团队开发工作流项目的 关于团队建设,项目管理的文章网上已经有很多了,在这里我就不谈这些理论了,直接给大家展示一个我在 项目开发方,后台服务开发方式,前台UI开发方式,后台服务与前台UI对接方式,代码文档,页面的开发文档,源码管理,单元测试,以及单元测试文档,实现思路设计文档,数据库文档,数据库设计规范,编码规范,操做数据的方法命名规则 方面的一些片断,这是一个为期6个月的工

艾伟也谈项目管理,编程习惯

文/Alexey Radul 译/程显峰 原文地址:http://web.mit.edu/~axch/www/programming_habits.html 近年来,我对编程艺术有很多体会.过后,我发现有些体会是错的:有些体会我遗忘了但又重新感受到:而另外有些则是必然会发现的.我还完善了一套项目管理的好习惯,这些习惯包括我自己的,或者小组的,抑或是更大的,公司内部的.一方面,这些习惯对软件的成功开发是至关重要的(太小或者纯粹巧合的不算),另一方面,这些习惯也不是什么高深莫测的东西,较小的篇幅就可

艾伟也谈项目管理,敏捷的坏态度

虽然所有软件开发的专业人士都会对这篇文章感兴趣,但是经理.CIO以及软件架构师会对它最感兴趣.这个话题可能会引起许多争议,但我写这篇文章是为了让你了解在敏捷运动中看起来正在日益增长的问题. 你为什么在这?敏捷不需要经理. 以前听过这种说法吗? 想象一下,如果你听到开发人员认为你这个职位根本就不应该存在,你会感到多么震惊,就好像是你特意为自己搞出经理这么个职位似的.这个话最常应用在项目经理第一次与将要和他一起工作的开发团队碰面的时候.的确,最初的敏捷宣言绝对没有提到项目管理,并且后来的敏捷理论家更

艾伟也谈项目管理,个人管理:写书之前应该回答的几个问题

我在06年和一个同事写过一本Delphi入门的示例书籍Delphi数据库通用模块及典型系统开发,当时体会到了写书不像想象中的简单,基本上业余时间都没了,所以我之后就不想出书了,其中更重要的一个原因是,我还没有找到一本真正想与大家分享并且自己能写出来的书籍. 博客是个好东东,只要你愿意与人分享交流,你的行为就可以赢得大家的认可,如果你的观点或者文章写的又好,那么就会有更多形式与大家分享,例如最近我们可以看到的很多人都由于blog而出书了.同样,我这两年对博客的投入也赢得了一些人的信任,也收到过好几

艾伟也谈项目管理,对项目管理的几点认识

自2007年参加工作以来,参与的项目也有好几个了,但都是以项目成员的角色参与,从来没有以项目经理的角色参与项目.中国有句古话叫"旁观者清",同一个问题站的角度不同,可能会形成不同的结论.下面我就以一个普通项目成员的角度谈一下对项目管理的几个看法,希望大家给予指正. 1. 团队成员选择 人员选择要谨慎,要尽量选择合适的人员,在选择团队成员时要重点考虑其团队合作能力.编码可读性.能力和项目的匹配度等因素. 2. 项目远景的确定 项目初期项目经理需要和高层以及客户协商,定下项目的远景目标(即

艾伟也谈项目管理,DevOps,不是一个传说!

DevOps最近成了热词,望文生义,你也能猜个八九不离十,它就是在说"研发团队"与"运维团队"之间的那点事儿.那么,到底什么是"DevOps"呢? WikiPedia上说:"DevOps是软件开发.运维和质量保证三个部门之间的沟通.协作和集成所采用的流程.方法和体系的一个集合.它是人们为了及时生产软件产品或服务,以满足某个业务目标,对开发与运维之间相互依存关系的一种新的理解."这恰好体现了精益管理中的客户价值原则,即:以客户的

艾伟也谈项目管理,ERP项目实施要未雨绸缪不要亡羊补牢

在ERP项目中,要做到在项目实施的未雨绸缪,不会出现亡羊补牢的情况就需要项目管理和实施人员在项目推进过程中队下面的阶段进行预测,把握好发展的趋势,掌握项目的主动权.下面就提出一些建议,供大家讨论.希望对大家有用. 一.要考虑每一个项目阶段普遍存在的问题 ERP项目可以根据项目进度,分为项目立项.需求调研.业务流程重组.模拟运行.并向运行.正式上线等几个阶段.其实不同的企业,虽然有各自的特性,但是也存在着一些普遍的问题.有经验的项目管理员,对各个阶段普遍存在的问题有深入的了解.此时他们就可以预先采

艾伟也谈项目管理,我也发软件开发团队的思考(侧重点是人员)

//上个月给我们老板的mail.洋洋洒洒6000多字. //为了方便公开,改了一下.以致可能有些地方前言不搭后语. //不管他同意不同意,先在我们组实行了再说. //请多大家多提提意见,日后看有没有机会找老板当面交流 经历的几个项目,项目的进度老是不尽如人意.更重要的是市场的开拓因为这些项目拖住了后退而无所作为. 我们现有的情况是:项目期限和最开始的保守估计都相去甚远,最后提交给客户的产品60%都是最后一个多月开发出来的,还有20%左右是以前就固有的固定模块.这几个项目我参与了编码,我对整个系统