|
锁定老帖子 主题：软件项目管理实践之日计划
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2009-08-03
klyuan 写道 （首先这种方法没有问题，在我的项目组执行得非常好） 他项目组有一个工作年限比较长的程序员K，这个程序员的工作年限比项目经理Q的工作年限长。 项目经理Q在检查工作时，几乎是一种命令的方式和责骂的方式。结果程序员K要不就是不理他，要不就是直接顶撞。 一段时间后，程序员K离职走人。 后来，我们聊起这个问题。他说为什么会这样？是不是这个方法不行。 我跟他说，不是方法的问题。而是在执行的时候出了问题。 第一、尊重。（管理人员的责任之一就是要让员工获得尊重） 第二、找出问题的原因 第三、不要上升到人格问题，不追究历史旧帐 第四、给予指导，一起制定解决方法 具体实践的执行效果，是和执行者的价值观（Values）相联系在一起的。 问题出在Q的价值观上。 |
| 返回顶楼 | |
|
发表时间：2009-08-08
lovejuan1314 写道 记得以前的公司,曾经实施过一种工单制,项目经理把每项任务量化成一张张的工单.在填写工单前,会和开发人员进行详细的沟通,以确认工单派发的合理.然后签字画押...
每张工单的完成情况会由技术总监派发给测试组进行考核,然后综合评定. 每月工资 = 基本工资+(实际完成工单数*日工资*老总定的一个百分比的基数) (该公式在后来本公司的OA中进行了更详细的算法,也会根据员工最近的表现以及工作态度等等指标进行综合评定) 想实现多劳多得,而且如果能在10-15天时间完成本月工作量,你可以选择继续完成工单多拿钱,或者选择休假. PS:该制度最后由于大量人员因为工资拖欠的问题的流失而最终流产.. 感悟: 一个好的制度需要有一个良好的环境和boss的全力支持! 有点像功能点的计算工作量的方法。只是功能点是按照功能的难易赋予不同的分数，而不仅仅是计算完成功能的数量。 但感觉功能点这种方法比较难实施，原因如下： 一，不一定是完成功能多，所付出的劳动就越多，因为有些功能是很难的，而且这个功能到底怎么算功能点，也就是完成一个功能可以拿到多少积分，很难有一个公允的估算。如果像书上所说，大家开会决定某个功能所应该占用的分数的话，这样的成本也太大了吧。 二，即使可以做到合理的定义每个功能的分数，会不会造成程序员挑功能做的问题呢(就像项目经理有时为了自己的业绩好看而挑项目做一样)。即使不让程序员挑，而是通过经理分配任务，那如何保证任务分配的公平呢，毕竟涉及到自己的薪酬，如果某些程序员老被分配到项目低的任务，肯定会有不满。 三，有一些功能一开始定义的分数很低，但后来做了之后发觉很难，于是又要重新定义分数。这样会不会花了太多时间在定义功能的分数上了。 四，如果一些功能一开始定义的分数很高，但后来做了之后发觉其实很简单，那么负责哪个功能的程序员有可能就不会反映实情，毕竟大部分人都是希望花少力气，拿多分数的。 这些既涉及到绩效考核的问题，也涉及到做计划时公平(不是平均哦)分配任务的问题， 不知道大家是如何解决的呢 |
| 返回顶楼 | |
|
发表时间：2009-08-10
忍不住点了个精华。
|
| 返回顶楼 | |
|
发表时间：2009-08-16
butterluo 写道 lovejuan1314 写道 记得以前的公司,曾经实施过一种工单制,项目经理把每项任务量化成一张张的工单.在填写工单前,会和开发人员进行详细的沟通,以确认工单派发的合理.然后签字画押...
每张工单的完成情况会由技术总监派发给测试组进行考核,然后综合评定. 每月工资 = 基本工资+(实际完成工单数*日工资*老总定的一个百分比的基数) (该公式在后来本公司的OA中进行了更详细的算法,也会根据员工最近的表现以及工作态度等等指标进行综合评定) 想实现多劳多得,而且如果能在10-15天时间完成本月工作量,你可以选择继续完成工单多拿钱,或者选择休假. PS:该制度最后由于大量人员因为工资拖欠的问题的流失而最终流产.. 感悟: 一个好的制度需要有一个良好的环境和boss的全力支持! 有点像功能点的计算工作量的方法。只是功能点是按照功能的难易赋予不同的分数，而不仅仅是计算完成功能的数量。 但感觉功能点这种方法比较难实施，原因如下： 一，不一定是完成功能多，所付出的劳动就越多，因为有些功能是很难的，而且这个功能到底怎么算功能点，也就是完成一个功能可以拿到多少积分，很难有一个公允的估算。如果像书上所说，大家开会决定某个功能所应该占用的分数的话，这样的成本也太大了吧。 二，即使可以做到合理的定义每个功能的分数，会不会造成程序员挑功能做的问题呢(就像项目经理有时为了自己的业绩好看而挑项目做一样)。即使不让程序员挑，而是通过经理分配任务，那如何保证任务分配的公平呢，毕竟涉及到自己的薪酬，如果某些程序员老被分配到项目低的任务，肯定会有不满。 三，有一些功能一开始定义的分数很低，但后来做了之后发觉很难，于是又要重新定义分数。这样会不会花了太多时间在定义功能的分数上了。 四，如果一些功能一开始定义的分数很高，但后来做了之后发觉其实很简单，那么负责哪个功能的程序员有可能就不会反映实情，毕竟大部分人都是希望花少力气，拿多分数的。 这些既涉及到绩效考核的问题，也涉及到做计划时公平(不是平均哦)分配任务的问题， 不知道大家是如何解决的呢 1.事先估算，及时发现问题，及时调整 |
| 返回顶楼 | |
|
发表时间：2009-08-16
zhanglubing927 写道 忍不住点了个精华。
呵呵，谢谢啊 |
| 返回顶楼 | |
