锁定老帖子 主题:小公司如何做项目管理(下)
该帖已经被评为良好帖
|
|
---|---|
作者 | 正文 |
发表时间:2008-07-22
在上篇文章里,我简要谈了项目管理中的需求开发和管理,那么在这篇文章里就和各位以闲话家常的方式讨论下项目规划和项目监控。项目规划、项目监控其实也是项目管理中比较核心的工作,也是很多开发人员最敏感的话题,因为这两个东西与公司的领导和员工关系都非常的密切。 先从我以前的学校说起,以前我们学校有片荒地,当时的领导觉得学校应该搞绿化,于是组织在荒地上植树,不到一年换了一个校长,这位校长觉得学校应该抓体育运动,决定再造一个足球场,于是把树移走,造了一个足球场,再后来北京奥运会来了,学习为了迎合绿色奥运的理念又开始植树,这就是没有规划和监控的典型例子,结果是劳民又伤财。当然对于学校来说,有国家财政的支持,有资本这么折腾,可是对于小公司做项目来说,这么折腾几下估计很快就要牺牲了。 事实求是的说大多数小公司在这两个方面做得很少有令人的满意的,小公司的老板其实也会意识到公司在项目规划和监控方面做得不咋地,但很少能做到有效的改进,其实这个也是有很多方面的原因的,以我自作多情的猜测主要有以下两个原因,对于小公司,尽管盈利不是很多,但基本还是可以撑下去的,老板会觉得管他乱不乱,公司总之每个月还是有盈利的,少就少点吧,多干几年自己的下半辈子基本有别墅有车了,所以比较保守,要是改革吧,万一鸡飞蛋打怎么办?还是本分点好,小心使得万年船。其实是对项目规划和监控其实需要大量的成本,老板觉得钱应该花在刀刃上,搞这些东西就是在务虚。再者更恶劣的老板有病就乱烧香,就有想想借助CMMI这个洋玩意治病的,其实很多老板都蛮喜欢CMMI的,CMMI就是假定人就是一个机器的部件,可以替换可以不停的运转,总之管机器总比管人省心吧,结果是万分的矛盾,银子撒了一大把,收效却甚微,甚至比以前更乱,大家做的都不开心。与其听咨询师们拿什么高深的方法论来瞎掰,不如我们谈点实际的,想就以下议题来和各位消遣。 1 工作量估算 对于工作量估算很多项目经理(老板)喜欢用数学公式来计算,可能数学公式更加的客观和科学,ok,,看看市面流行的计算方法吧,最常见的是基于代码行的数学模型,那么这里存在不少问题,工作量估算主要是为了在项目进行中进行有效的项目监控,那么软件开发尚未结束,谁知道最后的代码行有多大?代码经常会被修改,那么修改的代码算不算?如果算,那么代码修改越多难道能说明工作量越大?代码效率的区别也是很大的,假如一个10行代码可以实现的东西被写成50行,难道能客观的反映工作量?还有2种比较高级点的方法是基于功能点和COCOMO的方法,那么我想问的是它们的公式中的系数该怎么定?那么不少咨询师忽悠我说,根据自己的实际情况来定呗,那么我想问的是,算命是迷信,电脑意味着科学,那么用电脑算命算不算迷信?所以我是主张这里还是要靠人的经验来估算,大家可以在项目周会上对工作量进行充分的估算,在估算时要同时考虑到项目执行的难度,根据经验给出合理的评估。 2 任务分配 大多数的做法是将整个项目划分成一个个可以独立执行的原子任务,这些任务要划分优先级和难度,至少心理有个数,并且每项任务要制定负责人。那么问题就出在这个任务分配上了,软件开发是一项智力创造的活动,如果按CMMI假设的那样,在分配任务时忽略人的因素是万万不可取的,我就有血的教训,不久之前做一个ruby的项目,然后开始在公司内部随便抓了几个有点ruby基础的人,也没太顾忌别人的想法。做着做着,觉得他们有点心在曹营心在汉,平时还是抱着本thinking in java看,做ruby也是在敷衍了事,结果是代码质量不行,需要大规模的修改。当然按理说员工应该服从公司的安排,做一样就要做好一样,但员工也有员工的规划,你去叫他做他压根就不喜欢的事只能说明管理有问题。 另外还有一个普遍性的问题是能者多劳,有个朋友刚进公司动手能力很强,也非常的积极,每次做项目都分给他最难最累的任务,做着做着也就厌倦了,这时老板会忽悠你说,你能力强,要挑起公司的大梁,以后公司壮大了给你个什么职位,我觉得这就是在扯淡,这就是我经常见到的忽悠式的管理,很多管理手段完全靠人情,很多人都是在这种环境中被忽悠长大,到最后怎么样?被忽悠了几年还不是另谋高就了,所以指望人情化管理的公司很难长大。我觉得该讲原则的地方就要讲原则,在任务分配上给能力强的分配少而精的任务,而且要考虑到员工自己的想法,有些人想做java架构师,你叫他做oracle dba就不合适,有些对ui设计感兴趣,你叫他做系统分析员也不合适,有些人就喜欢搞技术,你硬要叫他做管理也是不合适。 3 进度管理 在做进度之前,一项最重要的任务是识别关键任务,很多进度表进行任务安排时将各项任务平均分的特点为觉得极不合适,有些任务比较难处理,而且许多后续任务依赖于该项任务,那么这项任务就应该配备更精良的人手和充裕的时间,依我的经验80%的时间都是在处理这些20%的关键任务上。这里还有个比较重要的问题是时间安排,我听很多项目经理说时间安排要尽可能的紧,也就是比预计要靠前,这样员工才有紧迫感。我觉得这是不可取的,首先即使你按原计划进行,八成也是要要延期的,那么这就会导致项目严重延期,长此以往,项目延期成了家常便饭,不延期反而不正常,于是大家都成了老油条,那么进度表不就是废纸一张,毫无约束力而言吗!我觉得根据实际情况指定个合理的进度表是比较重要的,或许你会说项目还是在延期,那我觉得是你项目估算没有做好,项目延期在10%左右比较正常,否则就可以调查是什么原因导致进度滞后,如果是客观原因,以后完全可以延长项目时间,总之一个合理的进度表比较重要。 4 项目奖金 这里牵扯到一个钱的问题,据我了解国内大多小公司很少有项目奖金这么一说,年底给点路费就不错了!国内的大多数项目经理更像是一个技术负责人,根本没有用钱的权利,我就曾像公司申请项目奖金,结果计划全盘泡汤,给的理由很荒唐,说项目奖金不好分配,给张三多一点吧,李四不爽,反之亦然。我心理暗自想:“你丫不想给就直说呗!”,这里会导致一个问题,就是“项目经理”凭什么约束成员,大锅饭的道理我也不想再解释了,总之结果就是3个月的项目就得做个5个月,其实老板的小算盘看似很精明,其实未见得,虽然项目奖金能省就省了,那么工作效率的下降所带来的成本的提高,孰轻孰重?长远一点说,产品质量的下滑导致的项目维护的成本你计算过吗?依我的经验,3个月的有效工作时间其实也就是1个月,这已经不错了。不过项目奖金的分配确实是个难问题,但有没有项目奖金和分配合理与否是2码子事吧?由于我也没有能耐申请到项目奖金所以也就没有深入研究这个问题,只得望梅止渴,看看人家华为了,员工根据能力分等级,加上年限、加班、表现得出个权值来计算。总之现有鸡才能有蛋,这个问题需要更深入的讨论。 先写那么多,有时间继续……
声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2008-07-22
LZ真能说!
1.工作量估算 按多人经验估算再平均,经常根据实际情况调整经验! 2.任务分配: 先把人选好?(太理想化,有时人力是项目经理不能决定的!)对于不愿意从事工作的人员,安抚,使其保持在基本合格的水平上。 按组分配,组内由组长根据人员情况分配,适时调整任务。 3.进度管理: 结合任务分配,按组报进度,开发进度由开发人员自己先估计,适当调整。根据实际情况调整。 4.?? 5.项目奖金: 这一条我们没有,没办法,公司大环境如此。 |
|
返回顶楼 | |
发表时间:2008-07-22
1 工作量估算
====================================== 这个还是要量化,先找一个动作快的做,看他需要多少时间,然后按一定比例,给别人算时间 2.任务分配 ======================================== 对于公司来说事无大小,不大可能很考虑个人的想法,给钱就行啊,没办法 3.进度管理 ======================================== 计划做好了,一般变更都不大 4.项目奖金 ========================================= PM基本在我们这里就都可以定,但是说真的,牵扯到钱,真的太复杂了 |
|
返回顶楼 | |
发表时间:2008-07-22
xidaboy 写道 1 工作量估算
====================================== 这个还是要量化,先找一个动作快的做,看他需要多少时间,然后按一定比例,给别人算时间 能否介绍个好的度量方法?:) |
|
返回顶楼 | |
发表时间:2008-07-22
1.工作量的估算
从工作量的角度来看,虽然一些小的公司大部分的项目经理基本上都是根据自己以往的开发经验来估计工作量,这其实是不好的,首先他可能会把自己的开发能力可能强加到开发人员身上,这样可能会把工作量估算的过轻;其次就是在项目开发的过程中可能会遇到像人员的流失的问题,人员的请假、服务器故障等问题,严重的影响工作量的期限;所以估算工作量一定要客观,有一个定性的从不同的角度来估算工作量;本人认为估算工作量是在项目中度量的一部分,它的估算涉及到各个方面,要从项目的功能点模块数、预计要纳入到配置管理的文档个数、代码行数、生产效率、硬软件资源、人力资源的角度,还有项目过程中遇到风险的问题等等;工作的估算不仅仅是仅凭经验就可以了,同时也要定性的从刚刚那些因数来考虑工作量问题; |
|
返回顶楼 | |
发表时间:2008-07-22
xiepinghejun 写道 1.工作量的估算
从工作量的角度来看,虽然一些小的公司大部分的项目经理基本上都是根据自己以往的开发经验来估计工作量,这其实是不好的,首先他可能会把自己的开发能力可能强加到开发人员身上,这样可能会把工作量估算的过轻;其次就是在项目开发的过程中可能会遇到像人员的流失的问题,人员的请假、服务器故障等问题,严重的影响工作量的期限;所以估算工作量一定要客观,有一个定性的从不同的角度来估算工作量;本人认为估算工作量是在项目中度量的一部分,它的估算涉及到各个方面,要从项目的功能点模块数、预计要纳入到配置管理的文档个数、代码行数、生产效率、硬软件资源、人力资源的角度,还有项目过程中遇到风险的问题等等;工作的估算不仅仅是仅凭经验就可以了,同时也要定性的从刚刚那些因数来考虑工作量问题; 到底怎么算? |
|
返回顶楼 | |
发表时间:2008-07-22
tuti 写道 xiepinghejun 写道 1.工作量的估算
从工作量的角度来看,虽然一些小的公司大部分的项目经理基本上都是根据自己以往的开发经验来估计工作量,这其实是不好的,首先他可能会把自己的开发能力可能强加到开发人员身上,这样可能会把工作量估算的过轻;其次就是在项目开发的过程中可能会遇到像人员的流失的问题,人员的请假、服务器故障等问题,严重的影响工作量的期限;所以估算工作量一定要客观,有一个定性的从不同的角度来估算工作量;本人认为估算工作量是在项目中度量的一部分,它的估算涉及到各个方面,要从项目的功能点模块数、预计要纳入到配置管理的文档个数、代码行数、生产效率、硬软件资源、人力资源的角度,还有项目过程中遇到风险的问题等等;工作的估算不仅仅是仅凭经验就可以了,同时也要定性的从刚刚那些因数来考虑工作量问题; 到底怎么算? 按照xiepinghejun MM的说法,基本是按CMMI的一套,如果按照这个方法去做,我首先关心的不是度量结果,而是质疑这个过程是否合理。市面上的度量方法大都有个系数这个概念,系数从哪来?还不是靠经验和实际情况,只不过是用电脑算的命罢了。我还是相信经验这个王道,即使不是很精确,至少比较靠谱。那靠经验具体怎么算呢,采用民主评审和资深开发人员的评估相结合的办法或许效果会好一点。 |
|
返回顶楼 | |
发表时间:2008-07-22
具体怎么估算吗?这个要取决于你前期的做的项目计划的数据充不充分了;像功能模块数,首先你要统计一下项目所要实现的模块数;文档数要统计项目开发各阶段文档资料的总页数;源代码数要大致估计下实现这些功能的代码行数;以上三个因数估算出你目前项目的规模;生产率取决与项目规模测算出平均生产率,人力资源和软硬件资源的方面,最好要采用一些备用的人员,以防有不必要的问题出现;风险的估计是根据你目前公司所建立的风险库中的风险,进行阶段性的识别和跟踪风险;
|
|
返回顶楼 | |
发表时间:2008-07-22
嘿嘿,xiepinghejun 就说你们自己这套流程执行下来效果怎么样吧
|
|
返回顶楼 | |
发表时间:2008-07-22
tuti 写道 嘿嘿,xiepinghejun 就说你们自己这套流程执行下来效果怎么样吧
正在进行中,不过还行吧 呵呵 |
|
返回顶楼 | |