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

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

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

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

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

 

 

评论

60 楼 lixigua 2008-09-26  

引用

4 项目奖金

    这里牵扯到一个钱的问题，据我了解国内大多小公司很少有项目奖金这么一说，年底给点路费就不错了！国内的大多数项目经理更像是一个技术负责人，根本没有用钱的权利，我就曾像公司申请项目奖金，结果计划全盘泡汤，给的理由很荒唐，说项目奖金不好分配，给张三多一点吧，李四不爽，反之亦然。我心理暗自想：“你丫不想给就直说呗！”，这里会导致一个问题，就是“项目经理”凭什么约束成员，大锅饭的道理我也不想再解释了，总之结果就是3个月的项目就得做个5个月，其实老板的小算盘看似很精明，其实未见得，虽然项目奖金能省就省了，那么工作效率的下降所带来的成本的提高，孰轻孰重？长远一点说，产品质量的下滑导致的项目维护的成本你计算过吗？依我的经验，3个月的有效工作时间其实也就是1个月，这已经不错了。不过项目奖金的分配确实是个难问题，但有没有项目奖金和分配合理与否是2码子事吧？由于我也没有能耐申请到项目奖金所以也就没有深入研究这个问题，只得望梅止渴，看看人家华为了，员工根据能力分等级，加上年限、加班、表现得出个权值来计算。总之现有鸡才能有蛋，这个问题需要更深入的讨论。

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

我以前也这样想。现在倒过来考虑，给你奖金了，你照样5个月干完怎么办？

所以我们公司的奖金只是逃税的一个手段。平均奖金，大家也就不把他当奖金了。老板也没考虑把它单奖金。-----后来公司改革，抽取了其中10%的奖金做活动奖金，但是其实质只是不给刚毕业的了，给带他的人。其他人照样拿平均奖金 。

分配奖金是高技术活，我们公司改革来改革去，那个领导来搞，年终奖最后还是工资的系数关系。

59 楼 liano 2008-09-25  

工作量估算的直接目的是保证工作可以按时完成，保证计划的顺利执行。
那让干活的人做估算是最保险的事情，如果是8个人左右的team，那就一块估算加讨论，这样的结果是最真实的，能反映出团队的平均水平。
如果是由某个人来做这件事，未免会比较片面。

58 楼 LinuxFans 2008-08-20  

学习了，各位说的都有道理。

57 楼 ozzzzzz 2008-08-11  

tuti 写道

“拍脑袋”，“直觉”这样的词，都容易引起情绪化的误解。
温伯格的“中文版”的书中，用的词是“常识”。
大致意思是，推导式的分析很快会在现实问题面前变得不堪重负，
而造成分析瘫痪。这需要通过“常识”来大大降低问题的复杂度。
这种情况大家可以想想如何来下围棋。



o6z的句子，如果改写一下是这样：
O6Z所说的拍脑袋是建立在人类常识基础上，并可以通过其他手段进行辅助，但是中心是人类常识。  

我觉得还是直觉比较好。
因为常识里面包括了直觉和一些已经从直觉固化为知识的东西，从而容易叫某些别有用心的人夸大知识的作用，而隐藏直觉的作用。其实任何一种专业化强的职业，直觉方面的作用都是关键性的，比如医生和法律工作者，其关键要求并不是你知识是不是已经具备（具备是必要条件），而是否在经验和直觉方面具备才是充要条件。这也就是为什么这两个职业的入门要求是必须要有数年的从业经验的缘故。
而美国的两个所谓的权威机构，为了自身的经济利益在这两个方面做得事情，恰恰说明了人类意识中卑鄙和龌龊的一面（一个是IEEE，一个是SEI）。

56 楼 tuti 2008-08-11  

“拍脑袋”，“直觉”这样的词，都容易引起情绪化的误解。
温伯格的“中文版”的书中，用的词是“常识”。
大致意思是，推导式的分析很快会在现实问题面前变得不堪重负，
而造成分析瘫痪。这需要通过“常识”来大大降低问题的复杂度。
这种情况大家可以想想如何来下围棋。



o6z的句子，如果改写一下是这样：
O6Z所说的拍脑袋是建立在人类常识基础上，并可以通过其他手段进行辅助，但是中心是人类常识。  

55 楼 ozzzzzz 2008-08-11  

gurudk 写道

ozzzzzz 写道

gurudk 写道

ozzzzzz 写道

to gurudk 以及前面那个苏州的mm
其实拍脑袋并非我自己独创，实际上cmmi的官方方法psp/tsp就是建立在拍脑袋的估算基础上的。当然我这里强调的是拍脑袋并不是啥坏事情，只不过要看你如何拍。
如果你去研究psp的过程，会发现其预估是建立在一个对于开发过程的数据和流量进行记录和回顾，以及对产出进行统计和对比的基础上的。这其实是一个强力的经验养成和积累的过程，是一种提供快速提高拍脑袋结果的准确性的好方法。可以说任何想提高拍脑袋水平的人，大概的路子也都是这个。当然我并不是说psp的做法在实施层面就很好了，其中还是有很大的欠缺，特别是公式和统计方法和统计数据选择方面还有很多问题。但是这个方法的框架和组成形式是好的，是值得我们仔细认真虚心的学习领会的。

在后期确实很多精确性的估算方法，但是，在很多固定期限的合同中，是在需求不是很明确下的情况下估计的。但是这些估计也很必要，因为要确定报价。这个阶段是很难进行估计的，但不估计，纯粹拍脑袋更不合适。拍脑袋可能误差200%，正式的估算方法可能把误差缩小到60%-70%。

我没有看到过所谓正规的估算方法不是基于拍脑袋的（不是拍脑袋就算不上是估算了），这一点不需要争论了。同时确定报价也并非是必须准确的知道项目规模的，只要在一定限度之内就可以了。而拍脑袋的能力高下，决定于经验积累的能力。这也就是为什么我比较欣赏psp在这个方面努力的最根本理由。
但是我们必须要明确，不存在（不仅仅是实际上不存在，而且是理论上不存在，并且是经过数学严密计算证明过的）一种方法可以不依靠人的这种拍脑袋能力，对未发生的事情进行合理的预期，更加谈不上什么能够把它的误差同另外一个什么东西对比了。这个是一个科学的问题，没有什么商量的余地。

看来我们对拍挠脑袋的理解不一样，呵呵。我所说的拍脑袋是未使用任何的预先定义的估算方法。当然最终都是人在做决定，什么都可以说是拍脑袋，但讨论这个就没有意义了。

我所说的拍脑袋是建立在人类直觉基础上，并可以通过其他手段进行辅助，但是中心是人类直觉。
实际上人类直觉的可靠和高预测能力，特别是面对高复杂和多头绪的场景是大大高于现有其他方式的。这一点你可以去学习学习实验心理学。而人类的这个直觉能力，还可以通过不断的总结和回顾进行加强，这也就是我多次强调psp的那个方式价值的原因。
而采用预先定义的估算方法的根本问题，在于数学的理论证明未来不可预测，从而证明这样的方法理论上站不住脚。第二，由于这种预测涉及的要素太多，那么这个预定义的方式所耗费的代价也必然会十分巨大；而同时如果这个耗费不大，也恰恰可能说明，你考虑的要素太少。
第三，由于预定义形式往往给人造成是基于客观的错觉（而其推演方式和最初的书籍启动点往往又是直觉的），从而造成其预测的观点对最终结果的影响力国强，也就是为了证明其预测的正确往往会为了预测结果而结果的后果。当然基于直觉的方式也存在这个问题，但是由于直觉的随意性比较强，而且使用直觉的时候往往是集体直觉而不是单体直觉，从而冗余性会抑制这种对结果的自我校正。

54 楼 gurudk 2008-08-11  

ozzzzzz 写道

gurudk 写道

ozzzzzz 写道

to gurudk 以及前面那个苏州的mm
其实拍脑袋并非我自己独创，实际上cmmi的官方方法psp/tsp就是建立在拍脑袋的估算基础上的。当然我这里强调的是拍脑袋并不是啥坏事情，只不过要看你如何拍。
如果你去研究psp的过程，会发现其预估是建立在一个对于开发过程的数据和流量进行记录和回顾，以及对产出进行统计和对比的基础上的。这其实是一个强力的经验养成和积累的过程，是一种提供快速提高拍脑袋结果的准确性的好方法。可以说任何想提高拍脑袋水平的人，大概的路子也都是这个。当然我并不是说psp的做法在实施层面就很好了，其中还是有很大的欠缺，特别是公式和统计方法和统计数据选择方面还有很多问题。但是这个方法的框架和组成形式是好的，是值得我们仔细认真虚心的学习领会的。

在后期确实很多精确性的估算方法，但是，在很多固定期限的合同中，是在需求不是很明确下的情况下估计的。但是这些估计也很必要，因为要确定报价。这个阶段是很难进行估计的，但不估计，纯粹拍脑袋更不合适。拍脑袋可能误差200%，正式的估算方法可能把误差缩小到60%-70%。

我没有看到过所谓正规的估算方法不是基于拍脑袋的（不是拍脑袋就算不上是估算了），这一点不需要争论了。同时确定报价也并非是必须准确的知道项目规模的，只要在一定限度之内就可以了。而拍脑袋的能力高下，决定于经验积累的能力。这也就是为什么我比较欣赏psp在这个方面努力的最根本理由。
但是我们必须要明确，不存在（不仅仅是实际上不存在，而且是理论上不存在，并且是经过数学严密计算证明过的）一种方法可以不依靠人的这种拍脑袋能力，对未发生的事情进行合理的预期，更加谈不上什么能够把它的误差同另外一个什么东西对比了。这个是一个科学的问题，没有什么商量的余地。

看来我们对拍挠脑袋的理解不一样，呵呵。我所说的拍脑袋是未使用任何的预先定义的估算方法。当然最终都是人在做决定，什么都可以说是拍脑袋，但讨论这个就没有意义了。

53 楼 ozzzzzz 2008-08-08  

gurudk 写道

ozzzzzz 写道

to gurudk 以及前面那个苏州的mm
其实拍脑袋并非我自己独创，实际上cmmi的官方方法psp/tsp就是建立在拍脑袋的估算基础上的。当然我这里强调的是拍脑袋并不是啥坏事情，只不过要看你如何拍。
如果你去研究psp的过程，会发现其预估是建立在一个对于开发过程的数据和流量进行记录和回顾，以及对产出进行统计和对比的基础上的。这其实是一个强力的经验养成和积累的过程，是一种提供快速提高拍脑袋结果的准确性的好方法。可以说任何想提高拍脑袋水平的人，大概的路子也都是这个。当然我并不是说psp的做法在实施层面就很好了，其中还是有很大的欠缺，特别是公式和统计方法和统计数据选择方面还有很多问题。但是这个方法的框架和组成形式是好的，是值得我们仔细认真虚心的学习领会的。

在后期确实很多精确性的估算方法，但是，在很多固定期限的合同中，是在需求不是很明确下的情况下估计的。但是这些估计也很必要，因为要确定报价。这个阶段是很难进行估计的，但不估计，纯粹拍脑袋更不合适。拍脑袋可能误差200%，正式的估算方法可能把误差缩小到60%-70%。

我没有看到过所谓正规的估算方法不是基于拍脑袋的（不是拍脑袋就算不上是估算了），这一点不需要争论了。同时确定报价也并非是必须准确的知道项目规模的，只要在一定限度之内就可以了。而拍脑袋的能力高下，决定于经验积累的能力。这也就是为什么我比较欣赏psp在这个方面努力的最根本理由。
但是我们必须要明确，不存在（不仅仅是实际上不存在，而且是理论上不存在，并且是经过数学严密计算证明过的）一种方法可以不依靠人的这种拍脑袋能力，对未发生的事情进行合理的预期，更加谈不上什么能够把它的误差同另外一个什么东西对比了。这个是一个科学的问题，没有什么商量的余地。

52 楼 gurudk 2008-08-08  

ozzzzzz 写道

to gurudk 以及前面那个苏州的mm
其实拍脑袋并非我自己独创，实际上cmmi的官方方法psp/tsp就是建立在拍脑袋的估算基础上的。当然我这里强调的是拍脑袋并不是啥坏事情，只不过要看你如何拍。
如果你去研究psp的过程，会发现其预估是建立在一个对于开发过程的数据和流量进行记录和回顾，以及对产出进行统计和对比的基础上的。这其实是一个强力的经验养成和积累的过程，是一种提供快速提高拍脑袋结果的准确性的好方法。可以说任何想提高拍脑袋水平的人，大概的路子也都是这个。当然我并不是说psp的做法在实施层面就很好了，其中还是有很大的欠缺，特别是公式和统计方法和统计数据选择方面还有很多问题。但是这个方法的框架和组成形式是好的，是值得我们仔细认真虚心的学习领会的。

在后期确实很多精确性的估算方法，但是，在很多固定期限的合同中，是在需求不是很明确下的情况下估计的。但是这些估计也很必要，因为要确定报价。这个阶段是很难进行估计的，但不估计，纯粹拍脑袋更不合适。拍脑袋可能误差200%，正式的估算方法可能把误差缩小到60%-70%。

51 楼 ozzzzzz 2008-08-07  

to gurudk 以及前面那个苏州的mm
其实拍脑袋并非我自己独创，实际上cmmi的官方方法psp/tsp就是建立在拍脑袋的估算基础上的。当然我这里强调的是拍脑袋并不是啥坏事情，只不过要看你如何拍。
如果你去研究psp的过程，会发现其预估是建立在一个对于开发过程的数据和流量进行记录和回顾，以及对产出进行统计和对比的基础上的。这其实是一个强力的经验养成和积累的过程，是一种提供快速提高拍脑袋结果的准确性的好方法。可以说任何想提高拍脑袋水平的人，大概的路子也都是这个。当然我并不是说psp的做法在实施层面就很好了，其中还是有很大的欠缺，特别是公式和统计方法和统计数据选择方面还有很多问题。但是这个方法的框架和组成形式是好的，是值得我们仔细认真虚心的学习领会的。

50 楼 Julian 2008-08-01  

ltian 写道

liuqiang 写道

ltian 写道

小公司需要管理吗？小公司需要的是干劲。

哼，小公司尤其需要干劲，但经常是干着干着就没劲了，靠一时的激情和干劲撑的住一年我就佩服你的毅力。
所以需要管理这种干劲，使之细水长流……

小公司的干劲是靠市场和金钱来刺激的，不是靠条条框框的规章制度，小公司的管理完全靠人，靠领导的人格魅力，干的没劲是觉得没有希望，如果有希望 ，会继续充满激情的。

不同意唯金钱论，金钱激励很重要，但不是全部，小公司经常公用许多新人，相比之下融入感，成长机会，相互尊重等有时候比金钱更有激励作用！小日本这方面就有独到的地方！不是发钱就能解决所有问题，不是所有公司都有那么多钱

49 楼 Julian 2008-08-01  

楼主写了很多关于“理性管理”的内容，只有“项目奖金”与“感性管理”有关，其实我认为感性管理也非常的重要，楼主能否就如何进行“感性管理”说说看法。
我曾在一个公司干了三年，多次被项目经理气的要辞职，体会到了“逼走员工的是中层管理者”的看法。还有架构师，CTO，甚至人际资源经历和销售部人员的关系都非常重要。如果割裂的把管理仅仅考虑成极其理性的事情我认为还是有些表面化，不够适合中国国情和人性

48 楼 gurudk 2008-07-31  

javaeyename 写道

  再声明一下，我非常讨厌代码行数这个东西，虽然有时候不得不统计这个东西，不同的人代码行数差异太大了。喜欢copy的人代码行数非常大，技术好的行数小。我印象中一个家伙写个登陆，这么简单的页面就用了3000行代码，你说说项目都这样做，那规模好大呀，一个人一天都能完成几千行的代码。呵呵，吓死人。

缺乏代码评审

47 楼 gurudk 2008-07-31  

ozzzzzz 写道

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

可能我还停留在见山是山，见水是水的境界，我觉得：

   觉得拍脑袋是最好的方法，本来就是一种悲观的做法，我不知道你是不是试过所有方法，认真思考过才这么说的。
   首先要有一个估算的意识，任何工作都可以用科学的眼光来看待它。就像以前很多迷信现象都被现在的科学验证了，可以说是从现象看本质的过程。
   只能说估算这门学科还停留在不成熟的阶段，我比较相信功能点和代码行。至于调整因子，我觉得不要用的太多。
至于代码行，在同一种技术框架下，代码行还是非常准的。
   拍脑袋（delphi法）适用于售前，功能点适用于需求规格说明书完成，代码行适用于代码稳定之后。后两种可以用于实际的生产率度量。每个企业都应该定义自己的估算方法和模型，基于自己的历史数据。
   另外，一般拍脑袋都是人天，人月，规模是很难拍脑袋拍出来的，是客观的。像你自己说的，和时间打上关系就不准确，不客观了。
   总之，拍脑袋过于依赖个人经验，无客观的度量基准，无法利用统计过程方法进行分析，无法利用行业数据。
当然，有时候也是很准的，因为这是“人工智能”。

46 楼 guooo 2008-07-29  

LZ有精力啊.写的不错.看过

45 楼 king2ksu 2008-07-29  

楼主说的，有些同感，以前的公司就是比较能忽悠，活干的不少，就是不加薪，一提加薪就开始扯别的东西，什么能力提高啊，团队管理啊，比唱的都好听。项目一直没有项目奖，干到第三年可算有了项目奖了，就一点点，而且分赃不均，严重打击积极性。管理混乱更不用说了，销售为了签单，什么功能都敢承诺，也没有明确的需求分析，都是一笔带过，搞的最后要开发的人员跟客户沟通怎么做，沟通的过程中，有些功能又不能实现，反而还被客户骂。项目经理就是协调，对既有系统也不熟，对技术也不熟，有和没有都一样。

44 楼 poprlz 2008-07-27  

小公司讲什么都没有用阿！只要大家有钱，大家有共同的理念才能做的长久的。项目管理如何做，本来就有很多方法。基本上就是如何在有限的条件下做得最好的才是真正的管理。利益主导一切。

43 楼 tuti 2008-07-25  

ltian 写道

liuqiang 写道

ltian 写道

小公司需要管理吗？小公司需要的是干劲。

哼，小公司尤其需要干劲，但经常是干着干着就没劲了，靠一时的激情和干劲撑的住一年我就佩服你的毅力。
所以需要管理这种干劲，使之细水长流……

小公司的干劲是靠市场和金钱来刺激的，不是靠条条框框的规章制度，小公司的管理完全靠人，靠领导的人格魅力，干的没劲是觉得没有希望，如果有希望 ，会继续充满激情的。

管理是什么？指条条框框的规章制度？

42 楼 city_moon 2008-07-25  

小公司真的需要管理，只是，看什么样的管理更适合小公司，再就是，要看小公司的老板怎么认识这个问题，我现在就接手了一个公司的项目，感觉很是郁闷：这个项目公司竞然不让我们调研，只是给了两个EXCEL的电子表格，每一个电子表格中有大概100张表，公司就让我们分析这两个EXCEL的电子表格来做这个系统，我开始跟公司说了，对现有资料的分析是有必要的，但是，只分析这些很难做出来满足用户需求的系统，而且，全是数字的报表，这些都是很敏感的信息，如果不把业务搞清楚，怎么可能做出来用户想要的东西，再说，用户想要什么东西我都不知道，怎么做呀!!结果，被公司还说了一通“要你们分析的人员干什么”，对类似于这样的项目，又该怎么管理？？象我们公司老板对软件开发的这种认识，又该如何管理呢？？

41 楼 liuqiang 2008-07-24  

ltian 写道

小公司需要管理吗？小公司需要的是干劲。

哼，小公司尤其需要干劲，但经常是干着干着就没劲了，靠一时的激情和干劲撑的住一年我就佩服你的毅力。
所以需要管理这种干劲，使之细水长流……