《人月神话》读后感第一篇

Posted 2021-02-07 gont-il-evol-i

读完了前九章，可以说读不懂吧，书中把项目的年人改成了人月，以人和月为完成项目时间的单位，为什么呢？

例如：

2000人一年的工作量变成人月的话，就是12×6个月30人（换算成人年是2160人一年）的工作量。

我所说的工作量为工作的有效时间，不包括交流时间，只有制作组合的时间。

2000个人的团体和30个人的团体相比来说，有什么区别呢？

 

2000人团队与30人团队比较
2000人团队	30人团队
人数过多，需要更多的交流	30个人不多不少可以根据项目进行较少的交流
需要更多的项目经理来组合	可分为一个项目经理加几个员工的精简精干的团队
对于每个员工依赖性差	对于每个员工的依赖性强
应对人员上的突发事件强	应对项目上突发事件较强
我目前只能想出来这么多了！

 

 

 

 

 

 

 

 

 

 

 

二者各有各的优点吧，但是如果是精干的人组成的30人团队势必比由精干的2000人组成的团队强，因为一个软件的制作需要分工，调节，组合。人越多交流越多，问题也就越多，花在这方面的时间也就越来越多。

也就是工作量时间以外的时间加多，人数越多，这样的时间越多，离项目完成就会更难。（我觉得人与人之间的交流是多的，这也是阻碍人发展的一个问题所在。《三体》中三体人相对于人类发展的快，因为他们没有隐瞒，不需要交流）

人类社会的工作时间=有效时间（工作量）+交流沟通时间

30个人的小团队能有效地压缩交流沟通时间，把工作时间更少，有效时间最大化；而2000人的团队并不能做到这几点，他们需要更多的交流。

特别是出现突发事件的时候，表中突发事件有俩种：1.人员的不可向性的问题 2.项目的不可向性的问题

2000人的团队相对于第一种问题来说，很简单的，2000人，人数众多，突然某个人生病干不了或者不干了跳槽，更坏的情况便是出卖项目资料，能很快地调动人员来补充出现的突然人员事件，即使是出卖了项目本身这样的情况，1/2000跟1/30来比更好调整；

而30人的团队中30个人都缺一不可，他们掌握的项目资料是1/30，对于突然人员事件，损失必然是严重的。

2000人对于第二种问题来说，相对于30人团队来说，应对关于项目的突发事件花的时间要多得多。30人的团队在这方面灵活的多。

现在大多都是30个人的小团队，因为这样效率高。不过在我看来，只是因为好沟通吧，我就比较喜欢小团体的氛围，而且我比较擅长处理小团体各个人之间的关系。就像我曾经说过的那句话：如果只是在一个班上过课的人便可以称为同学的话那也太无趣了吧。

就像火影忍者里面，四人一小队，30人团队也会分为个个小队，因为小队人不能太少，有些事情做不了，但是人不能太多，人多了会有人偷懒不能发挥最高的效率。