工作量估算

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

举个具体的例子

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

 

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

 

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

 

这里我确实需要解释解释。我说什么什么是核心，并不是说只要有了核心就行了，还需要有外围的辅助。
比如你拿到一个项目，最佳的方案是找到一个合适的人，全权委托给他去做。然而往往我们找不到这样一个人，我们只能找到一些可以完成这个事情一部分比较合适的人。这个时候，你就需要把这个事情划分为适应于这些人各自不同情况的组合，并将这些组合委派给他们去完成。而由于是组合，很可能他们之间的工作还有所联系。因此你就需要做协调。当然由于你要协调，对他们各自的工作情况就需要有一个监控，以使你可以在合适的时间采取相应的措施。这个任务的划分就是计划，这个监控就是项目的过程控制。由此我们就可以明白，所谓的计划面向的是人，服务的是人；所谓的过程控制，面向的也是人，服务的还是人。
而进一步看这个问题，我们可以说，设计也是应该面向人的，交流还是面向人的，一切的一切都是面向人的。