PMP项目管理师眼中之项目四要素
时间,质量,成本,范围
一直以来我做项目的目的就是两个
1.满足用户提出的需求
2.系统运行性能达到让客户满意的程度
对于一个开发者,或者说一个程序员来说在实现这两个目的的时候，经常会有两个附加要求，一个是在限定的时间之内，另一个是满足认可的质量标准。那么对于PMP项目管理师来说，又应该如何看待这四大要素呢？
首先这两个根本不能算要求,本来这也是属于我们可以自己控制的范畴。所以说对于时间,质量,开发者永远都比管理者更加注重。
当然管理者对时间关注的程度也很大,但我想与其让管理者对客户承诺我们一定会在某年某月某日之前完成项目,还不如多花点时间向客户仔细分析完成这些需求需要用到多少详细的技术,在这个过程中又要必须做哪几件事情。这样让客户也清楚时间是会有弹性的,也许能在某个时间段内完成项目,当然也可以象XP提倡的在相隔尽量短的时间内不停的提供版本那样做。这样客户心里有底,项目成员的压力也稍微小点。
做为PMP项目管理师,范围是一定要重视的,你不可能把客户提出的所有需求都在承诺时间实现,要分析这些需求,哪些是重要的,一定要首先完成的,哪些是次要的。要分成一期,二期做项目啊,范围太广,做的事情就多,思路就会不清晰,还不如一点一点消化。
做为PMP项目管理师，成本也是应该充分重视的。假设成本只是指什么钱啊,硬件设备啊这些东西,那这个应该是老板的事情,如果老板不短视,不是猪脑子,应该可以把这个以合理的方式去解决。
在管理者和开发者角度来看,所关注的成本也许只是技术,项目组各成员的工作默契度和交流程度。尤其是工作默契度和交流程度,不要以为人手不够再招一个或者几个程序员就能解决项目工作量,时间的问题。因为多了一个或者几个对于老成员陌生的新成员,其工作默契度和交流程度会受到很大的伤害。
所以PMP项目管理师若不具备优秀,高超的调节,调动资源的能力,几乎是不能使项目成功的,就算成功了。手下的那些小弟也会对这样的老大持BS态度的。
到时候跳槽的跳槽,要求换老大的换老大,管理者根本保证不了项目组协同作战的能力。
BTW,最近又重读了《亮剑》,发现李云龙真是个优秀的管理者啊。如果PMP项目管理师能把团队建设地有这么强的战斗力和高昂的士气,做项目会是很easy的一件事情。
PMP项目管理师眼中之项目四要素
时间,质量,成本,范围
一直以来我做项目的目的就是两个
1.满足用户提出的需求
2.系统运行性能达到让客户满意的程度
对于一个开发者,或者说一个程序员来说在实现这两个目的的时候，经常会有两个附加要求，一个是在限定的时间之内，另一个是满足认可的质量标准。那么对于PMP项目管理师来说，又应该如何看待这四大要素呢？
首先这两个根本不能算要求,本来这也是属于我们可以自己控制的范畴。所以说对于时间,质量,开发者永远都比管理者更加注重。
当然管理者对时间关注的程度也很大,但我想与其让管理者对客户承诺我们一定会在某年某月某日之前完成项目,还不如多花点时间向客户仔细分析完成这些需求需要用到多少详细的技术,在这个过程中又要必须做哪几件事情。这样让客户也清楚时间是会有弹性的,也许能在某个时间段内完成项目,当然也可以象XP提倡的在相隔尽量短的时间内不停的提供版本那样做。这样客户心里有底,项目成员的压力也稍微小点。
做为PMP项目管理师,范围是一定要重视的,你不可能把客户提出的所有需求都在承诺时间实现,要分析这些需求,哪些是重要的,一定要首先完成的,哪些是次要的。要分成一期,二期做项目啊,范围太广,做的事情就多,思路就会不清晰,还不如一点一点消化。
做为PMP项目管理师，成本也是应该充分重视的。假设成本只是指什么钱啊,硬件设备啊这些东西,那这个应该是老板的事情,如果老板不短视,不是猪脑子,应该可以把这个以合理的方式去解决。
在管理者和开发者角度来看,所关注的成本也许只是技术,项目组各成员的工作默契度和交流程度。尤其是工作默契度和交流程度,不要以为人手不够再招一个或者几个程序员就能解决项目工作量,时间的问题。因为多了一个或者几个对于老成员陌生的新成员,其工作默契度和交流程度会受到很大的伤害。
所以PMP项目管理师若不具备优秀,高超的调节,调动资源的能力,几乎是不能使项目成功的,就算成功了。手下的那些小弟也会对这样的老大持BS态度的。
到时候跳槽的跳槽,要求换老大的换老大,管理者根本保证不了项目组协同作战的能力。
BTW,最近又重读了《亮剑》,发现李云龙真是个优秀的管理者啊。如果PMP项目管理师能把团队建设地有这么强的战斗力和高昂的士气,做项目会是很easy的一件事情。