项目进度控制与员工激励技巧探讨

并不是很多企业认识不到这一点,而是做到一点太难.
也许团队中每个人的年龄,素质,扮演的角色,个人个性,人生观等等,之间的不同会给团队造成不同程度的影响.所以有人认为在大学找一个志同道合的朋友比较容易,而真正进入社会则不是易事.
还有很多说法都趋于理想化,理论化,实践是关键!
不如好好做下来想想自己是否在团队中做的不够好,一个团队的人都要这么想,问题就好解决了!--又理想化了--人不为已,天诛地灭!

是这个意思：
通过封装，对开发人员提供简单接口。
因为接口固化了，所以开发流程以及代码也就固化了。
不会产生完成同样的功能，10个人有10种实现方法的现象。
也就是说，通过系统接口的限制，完成一个功能，只能有一种方法。
那么工作量就很好确定了。
通过大量的提供这种接口，覆盖完所有的功能点。
那么一个项目的工作量通过功能点的数目以及难易级别，就可以算得出来。
也就是用框架强制性的固定开发人员的实现方法以及步骤，来达到量化的目的。
就如同生产线上，完成一个操作，是使用标准的步骤，当然工时也就是可量化的。

支持。

目前我们都在做这样的量化代码工作，只需要安排一定的接口和标准程序员只需要填鸭即可实现代码。

而恰好免xml配置的speedframework可以实现填鸭式开发，实现工作量量化，并且是很简单易于理解使用。

http://sourceforge.net/projects/speedframework/

从"项目进度控制与员工激励技巧探讨" 逐步讨论到" speedframework可以实现填鸭式开发，实现工作量量化，并且是很简单易于理解使用"

做开发的同志们,再一次成功的把大家不太擅长的"人与人之间的问题"成功的转换为一个大家比较擅长的技术问题.

如果出现某种技术,可以填鸭来工作,那么进度就是可控的,
人员是可以被严格控制的,激励是不需要的, OK问题解决了.

楼上解释得极是

如果一项工作可以遵循一定的规律，机械地完成，那么这项工作早晚是会有机器代替人来完成的。

    哈哈，这种技术有人在研究吧，不过一旦这个类似计算机领域的“永动机”玩意研究出来，人人都躺家里睡大觉了， 机械公敌里面的问题就成了现实问题了。
    
     即使是智能编译器出来，那么也总要有智能编译器的作者吧。即生产软件的软件的作者。还是程序员嘛。

     软件开发出来本质是要解决人的问题，如果解决人的问题能够用机器去解决，那么至少人的问题完全可以不是人的问题了。

其实真的很简单，不做。你知道为什么有些项目经理的成功率总是很高，reputation总是很好？因为他不做必死的项目，接手一个项目之前先做风险分析，回报不够抵偿风险的项目就不做。
打工和做老板是不同的。做老板，公司是你的，项目是你的，硬着头皮也得上。打工赚的是reputation，为一个成功了也就普普通通的项目，赌上自己的时间和reputation，不划算。

不是所有人都能这么洒脱吧，当风险和机会并存，没点手段是搞不定的，
我觉得当项目利益和个人利益可以相互结合这样通常会有一个好的效果，
团队共同来分享项目的成功，当然也共同承担项目的风险，要赚一起赚 要死一起死，呵呵

千万不要误会。我不是在说“有困难就不做”，正如我不鼓励“有项目就做”一样。应该做至少比较周全的风险回报分析，考虑清楚再做。