《产品研发过程实践》(23) 高层管理者
作者:asky 日期:2007-04-29
高层管理者,这里之所以要提起,是因为,事实上,使得项目成功,在很大程度上也需要取决于高层管理者对于项目的一些做法和态度。那么做为一个项目经理的角度出发,我们期待于高层管理者如何呢?
首先,我们希望能够保证资源的供给,保证时间、人力和资金的保证。当然每个人都希望从投入中得到足够多的反馈,但是我希望高管们能够理解项目、工程的一般性原则,有时候,我们的确无法答应一些时间条件,不要和我过多地谈起我给你1倍的人,你是否可以少用一半的时间完成这种怪问题,我真的很难回答(当然,现在这种什么都不懂的高层管理者不多了,倒是看见不少底层管理者敢于对上面这个问题,回答“是!”)。如果我真的如此答应你,那么对于你来说,恐怕也是一场灾难。因为,我可能仅仅是因为希望扩大一些沉没成本而已,来使得这个项目更难以取消。
其次,我希望高管们,在一定时间中,维持一个相对来说比较稳定的环境,而不是变化多端的环境给研发团队,人的想法变化很快,但是一个项目目标老是改变,就很难受了。不是吗?至少有一定的定力来维持一个至少短期的一个稳定。我们能够拥抱变化,但是不是说,去拥抱无节制的变化。比如,原先一个产品是为了解决项目中的实际问题而做的引擎,后期变成了为了演示而开发的引擎等等;这就多少让我惊讶万分了。
再次,做好你的事情,其他的事情,让兄弟们干好了。我不喜欢伸手得太长的高管。比如在有的合作中,做为产品和市场方面的高管,每天和我一起讨论技术问题和一些界面安排问题。我觉得多少有点离谱,对于一个新开始做的行业来说,在这段非常重要的时间中,我希望你能够提供更多的市场信心,找到合作者,找到我们产品的试用者,找到我们的合作伙伴,而不是一天又一天得和我讨论,项目何时开始编码比较合适。直到某一天,我的一个同仁对对方说:“某某,还是让周海峰负责研发方面的决定就可以了,毕竟他好歹也算做得比较长时间的研发经理了,我觉得我可以和你一起来谈谈一些其他问题,比如做一些BD的工作”。但是一切都没有改变。于是,大家的工作似乎都纠缠在一起,我们非要有一个全面超越竞争对手的产品,然后才能找到客户(如果真的如此,那么还不如不做算了,没有客户的直接接触,我如何知道我的产品是真的在正确的道路上行走,而不是闭门造车?),然后我希望能够在第一阶段版本出来以后,能够找到2-3个试用者来使用这个产品,我可以提供前向兼容的功能,使得用户能够使用这个产品等等。如果这种问题纠缠在一起,什么东西都做不出来。请首先解决这种问题!
最后,高管们,拿出一些个人魅力来,多多少少让手下人能够从你身上看见多一些的传统美德,比如排队尽量不要插队啊,如果说一个公司的文化,并不取决于你老板如何想,而是看你老板现实中如何做,那么请注意,有时候小小的几件事情,会使得你的下属对你将来的话表示一些不信任的。
另外,几个做法,我认为对于项目或者团队来说,是比较有效的,做为一点建议提出:
首先,有期望的奖励会远远超过无期望的奖励,后者更大程度上被团队认为是意外的,不可重复的。所以,如果推出项目奖金制度,尽量事先确立项目奖金的标准,并且在其后落实这样的项目奖金;不要在最后发放的时候,大家还不知道因为什么而发放的;
其次,给一个团队固定的一定费用做为Team Building费用,这一点和部门经理或者项目经理明确交待,并且可以由项目经理或部门经理直接使用,而不用打招呼。不然,这笔费用会类似一种优秀的奖励,或者项目结束的庆祝,但是在其他的一些情况下,可能需要Team Building的时候,就难以使用了。一般的做法是每人每个季度100-200元,大致如此。
再次,给一个项目管理者以一定的考核权(如果他没有的话),我们都很期待自己能够达到无职权管理的境界,但是对于一个初开始做管理的人来说,这一点很难达到。同时,为了平衡这个人员的管理水平等等,你可以由更上面一层的人(部门经理是一个好的选择)来综合考虑,并且把这个人员的考核表都附在后面。这样对于一个项目管理者来说,是相对有一些作用的。
就象项目经理善待团队成员一样,高管们,善待你的下级。
首先,我们希望能够保证资源的供给,保证时间、人力和资金的保证。当然每个人都希望从投入中得到足够多的反馈,但是我希望高管们能够理解项目、工程的一般性原则,有时候,我们的确无法答应一些时间条件,不要和我过多地谈起我给你1倍的人,你是否可以少用一半的时间完成这种怪问题,我真的很难回答(当然,现在这种什么都不懂的高层管理者不多了,倒是看见不少底层管理者敢于对上面这个问题,回答“是!”)。如果我真的如此答应你,那么对于你来说,恐怕也是一场灾难。因为,我可能仅仅是因为希望扩大一些沉没成本而已,来使得这个项目更难以取消。
其次,我希望高管们,在一定时间中,维持一个相对来说比较稳定的环境,而不是变化多端的环境给研发团队,人的想法变化很快,但是一个项目目标老是改变,就很难受了。不是吗?至少有一定的定力来维持一个至少短期的一个稳定。我们能够拥抱变化,但是不是说,去拥抱无节制的变化。比如,原先一个产品是为了解决项目中的实际问题而做的引擎,后期变成了为了演示而开发的引擎等等;这就多少让我惊讶万分了。
再次,做好你的事情,其他的事情,让兄弟们干好了。我不喜欢伸手得太长的高管。比如在有的合作中,做为产品和市场方面的高管,每天和我一起讨论技术问题和一些界面安排问题。我觉得多少有点离谱,对于一个新开始做的行业来说,在这段非常重要的时间中,我希望你能够提供更多的市场信心,找到合作者,找到我们产品的试用者,找到我们的合作伙伴,而不是一天又一天得和我讨论,项目何时开始编码比较合适。直到某一天,我的一个同仁对对方说:“某某,还是让周海峰负责研发方面的决定就可以了,毕竟他好歹也算做得比较长时间的研发经理了,我觉得我可以和你一起来谈谈一些其他问题,比如做一些BD的工作”。但是一切都没有改变。于是,大家的工作似乎都纠缠在一起,我们非要有一个全面超越竞争对手的产品,然后才能找到客户(如果真的如此,那么还不如不做算了,没有客户的直接接触,我如何知道我的产品是真的在正确的道路上行走,而不是闭门造车?),然后我希望能够在第一阶段版本出来以后,能够找到2-3个试用者来使用这个产品,我可以提供前向兼容的功能,使得用户能够使用这个产品等等。如果这种问题纠缠在一起,什么东西都做不出来。请首先解决这种问题!
最后,高管们,拿出一些个人魅力来,多多少少让手下人能够从你身上看见多一些的传统美德,比如排队尽量不要插队啊,如果说一个公司的文化,并不取决于你老板如何想,而是看你老板现实中如何做,那么请注意,有时候小小的几件事情,会使得你的下属对你将来的话表示一些不信任的。
另外,几个做法,我认为对于项目或者团队来说,是比较有效的,做为一点建议提出:
首先,有期望的奖励会远远超过无期望的奖励,后者更大程度上被团队认为是意外的,不可重复的。所以,如果推出项目奖金制度,尽量事先确立项目奖金的标准,并且在其后落实这样的项目奖金;不要在最后发放的时候,大家还不知道因为什么而发放的;
其次,给一个团队固定的一定费用做为Team Building费用,这一点和部门经理或者项目经理明确交待,并且可以由项目经理或部门经理直接使用,而不用打招呼。不然,这笔费用会类似一种优秀的奖励,或者项目结束的庆祝,但是在其他的一些情况下,可能需要Team Building的时候,就难以使用了。一般的做法是每人每个季度100-200元,大致如此。
再次,给一个项目管理者以一定的考核权(如果他没有的话),我们都很期待自己能够达到无职权管理的境界,但是对于一个初开始做管理的人来说,这一点很难达到。同时,为了平衡这个人员的管理水平等等,你可以由更上面一层的人(部门经理是一个好的选择)来综合考虑,并且把这个人员的考核表都附在后面。这样对于一个项目管理者来说,是相对有一些作用的。
就象项目经理善待团队成员一样,高管们,善待你的下级。
评论: 0 | 引用: 0 | 查看次数: 4283
发表评论
你没有权限发表评论!