小公司如何做项目管理(下)

    在上篇文章里，我简要谈了项目管理中的需求开发和管理，那么在这篇文章里就和各位以闲话家常的方式讨论下项目规划和项目监控。项目规划、项目监控其实也是项目管理中比较核心的工作，也是很多开发人员最敏感的话题，因为这两个东西与公司的领导和员工关系都非常的密切。

    先从我以前的学校说起，以前我们学校有片荒地，当时的领导觉得学校应该搞绿化，于是组织在荒地上植树，不到一年换了一个校长，这位校长觉得学校应该抓体育运动，决定再造一个足球场，于是把树移走，造了一个足球场，再后来北京奥运会来了，学习为了迎合绿色奥运的理念又开始植树，这就是没有规划和监控的典型例子，结果是劳民又伤财。当然对于学校来说，有国家财政的支持，有资本这么折腾，可是对于小公司做项目来说，这么折腾几下估计很快就要牺牲了。

    事实求是的说大多数小公司在这两个方面做得很少有令人的满意的，小公司的老板其实也会意识到公司在项目规划和监控方面做得不咋地，但很少能做到有效的改进，其实这个也是有很多方面的原因的，以我自作多情的猜测主要有以下两个原因，对于小公司，尽管盈利不是很多，但基本还是可以撑下去的，老板会觉得管他乱不乱，公司总之每个月还是有盈利的，少就少点吧，多干几年自己的下半辈子基本有别墅有车了，所以比较保守，要是改革吧，万一鸡飞蛋打怎么办？还是本分点好，小心使得万年船。其实是对项目规划和监控其实需要大量的成本，老板觉得钱应该花在刀刃上，搞这些东西就是在务虚。再者更恶劣的老板有病就乱烧香，就有想想借助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码子事吧？由于我也没有能耐申请到项目奖金所以也就没有深入研究这个问题，只得望梅止渴，看看人家华为了，员工根据能力分等级，加上年限、加班、表现得出个权值来计算。总之现有鸡才能有蛋，这个问题需要更深入的讨论。

    先写那么多，有时间继续……

 

 

评论

20 楼 ozzzzzz 2008-07-22  

tuti 写道

ozzzzzz 写道

而真正合格的估算，应该是拍脑门想出来的——也就是应该仅仅建立在主观的直觉基础上的。所谓的估算方法，到最后你会发现，其实仅仅是一种给自己结论找的理由。而要完成你的设想，唯一的方法就是完成他们。也就是说，想看书或者参加什么培训提高估算的水平，几乎是不可能。不断的总结和积累，才是王道。

ozzzzzz大叔就是彪悍，除了他估计没别人敢这么说

哈哈，等我明天忽然想整一个估算与计划培训班的时候，我可能就会改口了。当然这是一个玩笑。不过我确实看过很多估算方面的资料，也参加过很多培训和讨论，自己也给别人介绍和辅导过很多这个方面的内容。然而最终我自己发现，往往是我在项目最初的直觉，最终都是最准确的。并且我做过调查，基本上当一个开发者在保持复习项目的习惯半年之后，对于项目规模的直接就很准了。而这也使我对估算这个问题有了新的视角，我现在更愿意教大家如何回顾和复习自己的工作，并不断对自己的直觉估算能力做训练。
当然同时我们必须还认识到，至少对于我来说同样的需求，所带来的任务和完成的工作量并不是很恒定的，它会由于开发者的选择有十分大的伸缩性。比如同样是做一个网站，即使你使用同样的技术和高层设计，并且是同样的人员，最终的代码规模和完成的时间长短以及工程的质量都可能差别很大。并且很多时候，开发者自己也知道这一点，并且是有意的利用了这一点。当然如果把项目放在极限状态下考虑，这一点就该被强烈的重视起来。
而我也发现当项目处于极限状态下，在混乱与秩序的边界，其收益和实施的过程往往是最具有活性的。当然人与组织之间的区别很大，这个交界点的差异就更大。这也需要大家不断的对自己的工作进行回顾和复习。

19 楼 tuti 2008-07-22  

ozzzzzz 写道

而真正合格的估算，应该是拍脑门想出来的——也就是应该仅仅建立在主观的直觉基础上的。所谓的估算方法，到最后你会发现，其实仅仅是一种给自己结论找的理由。而要完成你的设想，唯一的方法就是完成他们。也就是说，想看书或者参加什么培训提高估算的水平，几乎是不可能。不断的总结和积累，才是王道。

ozzzzzz大叔就是彪悍，除了他估计没别人敢这么说

18 楼 hyhongyong 2008-07-22  

ＬＺ理解错我的意思了
我说又主观了，是针对xidaboy所说的：

引用

先做SAMPLE再算预期CASE数,再除预期日完成数.回过头来说,比如8个人,7个人都可以按时完成,第8个不能顺利结束,一般就要换人了

就靠一个sample做的慢把人就换了，过于主观了（有的时候人力不是你能决定的）。除非是简单一点的功能。否则有的人DB强，有的人逻辑好，一个sample能把所有人的能力都测试出来吗？

我觉得一个项目，不必所有的人员都要是合格的。

工作量的估算我也是提倡用经验（综合每层人员）的，对于所谓的算法感觉不实用。

17 楼 ozzzzzz 2008-07-22  

这篇文章写的不好，上来就出了原则性的错误。
项目管理的核心是找的合适的人做合适的事情，其他一切都不能称之为核心。你可以称其他要素为关键的，重要的，但是绝对不能说是核心的。计划和计划实施过程的监控自然是重要的，但是绝对是最重要的。
估算和计划，我在这个论坛已经说过很多次了。基本上说，最靠谱的估算就是基于经验的拍脑袋的做法。当然培养这个估算的能力，是有一个过程的，并且我推荐可以将PSP的做法加以改进，以加强自己的复习工作，从而可以很快的提高自己的估算的能力。当然这个地方有很多的策略和各种策略的优缺点，以后专门讨论的时候再展开。
至于任务的分配和进度的确定，这个方面我以前也说过很多了。这里我需要强调的是，任务和需求的粒度化其实才是解决这些问题的核心基础实践，没有这个基础，基本上这些事情仅仅就是一种纸上谈兵。
至于说绩效考核以及分配，这个话题太大，而且专业性太强，我建议大家不要着急讨论。
总的来说，我觉得楼主可能看PMP之类的东西太多了，中毒了。

16 楼 liuqiang 2008-07-22  

<div class='quote_title'>
<div class='quote_title'/>
 hyhongyong 写道</div>
<div class='quote_div'>Ｌｓ的，这么个试用法，要花费多少时间？ <br/>再说有的工作复杂度不同，这么做又主观了。 <br/></div>
<p><br/>怎么就不能主观了？那如何能用一个客观的方法去衡量人这个主观的东西呢？如果答不上来还是看看o6z的想法吧 </p>
<div class='quote_title'>ozzzzzz 写道</div>
<div class='quote_div'>项目规模的估算和项目管理其实没啥关系，而工作量的估算倒是和项目管理关系密切。 <br/>而根据我的经验，使用何种方法同估算的准确性没啥大的关联，而同项目结束后的总结和积累关系密切。 <br/>同时估算应该是一个过程，而不是一个短时间的行为。同时估算应该同计划严格区分，不应该为了计划而估算，也不能为了估算而计划。 <br/>再次强调gigix说的，估算的单位不要与时间有任何关系。但是请记住，在实际的操作中时间会对估算有巨大的影响。而只有将时间同估算单位完全的隔离，才是保证。 <br/>同时估算有几种粒度，适应不同的场景。 <br/><br/>而真正合格的估算，应该是拍脑门想出来的——也就是应该仅仅建立在主观的直觉基础上的。所谓的估算方法，到最后你会发现，其实仅仅是一种给自己结论找的理由。而要完成你的设想，唯一的方法就是完成他们。也就是说，想看书或者参加什么培训提高估算的水平，几乎是不可能。不断的总结和积累，才是王道。<br/></div>
<p> </p>

15 楼 xidaboy 2008-07-22  

hyhongyong 写道

Ｌｓ的，这么个试用法，要花费多少时间？
再说有的工作复杂度不同，这么做又主观了。

====================================================
花费不了多少时间

做几个画面能化多少时间呢,都是有过程的,LEADER肯定要快一步,大家学习框架,你应该写好详细设计的SAMPLE,大家写详细设计,你该把代码的SAMPLE做出来.总是快一步,这样就不会花多少时间


工作的复杂度是否严重的影响到工作量的评估,那当然要在合理调整一下,东西是死的,人是活的 

14 楼 hyhongyong 2008-07-22  

Ｌｓ的，这么个试用法，要花费多少时间？
再说有的工作复杂度不同，这么做又主观了。

13 楼 xidaboy 2008-07-22  

liuqiang 写道

xidaboy 写道

1 工作量估算
======================================

这个还是要量化,先找一个动作快的做,看他需要多少时间,然后按一定比例,给别人算时间

能否介绍个好的度量方法？：）

我们的方法还是比较实用的

举个具体的例子

我们做任何一个工作,都先做SAMPLE,比如写详细设计,LEADER必须先写,定SAMPLE,然后看LEADER做需要多少时间,然后按一定比例,比如PERT方法就可以,然后按画面去分,画面数/预期每日完成数,测试也一样,先做SAMPLE再算预期CASE数,再除预期日完成数.回过头来说,比如8个人,7个人都可以按时完成,第8个不能顺利结束,一般就要换人了

12 楼 tuti 2008-07-22  

其实我以前刚干这行的时候，也象楼主那样，想这个问题想得很郁闷。
当时有还发了个帖子。 http://tuti.iteye.com/blog/210611 。

后来看到XP，发现一切问题的答案都尽在其中。

11 楼 liuqiang 2008-07-22  

tuti 写道

xiepinghejun 写道

tuti 写道

嘿嘿，xiepinghejun 就说你们自己这套流程执行下来效果怎么样吧

正在进行中，不过还行吧  呵呵

就知道贵司正在进行中 嘿嘿

正解！用电脑看命不仅要会看命，还要会电脑，如果是瞎子用电脑看命的话可就让人觉得扯淡了

10 楼 tuti 2008-07-22  

xiepinghejun 写道

tuti 写道

嘿嘿，xiepinghejun 就说你们自己这套流程执行下来效果怎么样吧

正在进行中，不过还行吧  呵呵

就知道贵司正在进行中 嘿嘿

9 楼 xiepinghejun 2008-07-22  

tuti 写道

嘿嘿，xiepinghejun 就说你们自己这套流程执行下来效果怎么样吧

正在进行中，不过还行吧  呵呵

8 楼 tuti 2008-07-22  

嘿嘿，xiepinghejun 就说你们自己这套流程执行下来效果怎么样吧

7 楼 xiepinghejun 2008-07-22  

具体怎么估算吗?这个要取决于你前期的做的项目计划的数据充不充分了；像功能模块数,首先你要统计一下项目所要实现的模块数；文档数要统计项目开发各阶段文档资料的总页数；源代码数要大致估计下实现这些功能的代码行数；以上三个因数估算出你目前项目的规模；生产率取决与项目规模测算出平均生产率，人力资源和软硬件资源的方面，最好要采用一些备用的人员，以防有不必要的问题出现；风险的估计是根据你目前公司所建立的风险库中的风险，进行阶段性的识别和跟踪风险；

6 楼 liuqiang 2008-07-22  

tuti 写道

xiepinghejun 写道

1.工作量的估算
从工作量的角度来看,虽然一些小的公司大部分的项目经理基本上都是根据自己以往的开发经验来估计工作量,这其实是不好的,首先他可能会把自己的开发能力可能强加到开发人员身上,这样可能会把工作量估算的过轻;其次就是在项目开发的过程中可能会遇到像人员的流失的问题,人员的请假、服务器故障等问题，严重的影响工作量的期限；所以估算工作量一定要客观，有一个定性的从不同的角度来估算工作量；本人认为估算工作量是在项目中度量的一部分，它的估算涉及到各个方面，要从项目的功能点模块数、预计要纳入到配置管理的文档个数、代码行数、生产效率、硬软件资源、人力资源的角度，还有项目过程中遇到风险的问题等等；工作的估算不仅仅是仅凭经验就可以了，同时也要定性的从刚刚那些因数来考虑工作量问题；

到底怎么算？

按照xiepinghejun MM的说法，基本是按CMMI的一套，如果按照这个方法去做，我首先关心的不是度量结果，而是质疑这个过程是否合理。市面上的度量方法大都有个系数这个概念，系数从哪来？还不是靠经验和实际情况，只不过是用电脑算的命罢了。我还是相信经验这个王道，即使不是很精确，至少比较靠谱。那靠经验具体怎么算呢，采用民主评审和资深开发人员的评估相结合的办法或许效果会好一点。

5 楼 tuti 2008-07-22  

xiepinghejun 写道

1.工作量的估算
从工作量的角度来看,虽然一些小的公司大部分的项目经理基本上都是根据自己以往的开发经验来估计工作量,这其实是不好的,首先他可能会把自己的开发能力可能强加到开发人员身上,这样可能会把工作量估算的过轻;其次就是在项目开发的过程中可能会遇到像人员的流失的问题,人员的请假、服务器故障等问题，严重的影响工作量的期限；所以估算工作量一定要客观，有一个定性的从不同的角度来估算工作量；本人认为估算工作量是在项目中度量的一部分，它的估算涉及到各个方面，要从项目的功能点模块数、预计要纳入到配置管理的文档个数、代码行数、生产效率、硬软件资源、人力资源的角度，还有项目过程中遇到风险的问题等等；工作的估算不仅仅是仅凭经验就可以了，同时也要定性的从刚刚那些因数来考虑工作量问题；

到底怎么算？

4 楼 xiepinghejun 2008-07-22  

1.工作量的估算
从工作量的角度来看,虽然一些小的公司大部分的项目经理基本上都是根据自己以往的开发经验来估计工作量,这其实是不好的,首先他可能会把自己的开发能力可能强加到开发人员身上,这样可能会把工作量估算的过轻;其次就是在项目开发的过程中可能会遇到像人员的流失的问题,人员的请假、服务器故障等问题，严重的影响工作量的期限；所以估算工作量一定要客观，有一个定性的从不同的角度来估算工作量；本人认为估算工作量是在项目中度量的一部分，它的估算涉及到各个方面，要从项目的功能点模块数、预计要纳入到配置管理的文档个数、代码行数、生产效率、硬软件资源、人力资源的角度，还有项目过程中遇到风险的问题等等；工作的估算不仅仅是仅凭经验就可以了，同时也要定性的从刚刚那些因数来考虑工作量问题；

3 楼 liuqiang 2008-07-22  

xidaboy 写道

1 工作量估算
======================================

这个还是要量化,先找一个动作快的做,看他需要多少时间,然后按一定比例,给别人算时间

能否介绍个好的度量方法？：）

2 楼 xidaboy 2008-07-22  

1 工作量估算
======================================

这个还是要量化,先找一个动作快的做,看他需要多少时间,然后按一定比例,给别人算时间

2.任务分配
========================================
对于公司来说事无大小,不大可能很考虑个人的想法,给钱就行啊,没办法

3.进度管理
========================================
计划做好了,一般变更都不大

4.项目奖金
=========================================
PM基本在我们这里就都可以定,但是说真的,牵扯到钱,真的太复杂了

1 楼 hyhongyong 2008-07-22  

ＬＺ真能说！
1.工作量估算
   按多人经验估算再平均，经常根据实际情况调整经验！
2.任务分配：
   先把人选好？（太理想化，有时人力是项目经理不能决定的！）对于不愿意从事工作的人员，安抚，使其保持在基本合格的水平上。
   按组分配，组内由组长根据人员情况分配，适时调整任务。
3.进度管理：
   结合任务分配，按组报进度，开发进度由开发人员自己先估计，适当调整。根据实际情况调整。
4.？？
5.项目奖金：
    这一条我们没有，没办法，公司大环境如此。