项目总监的方法论总结——点评

  1. 云栖社区>
  2. 博客>
  3. 正文

项目总监的方法论总结——点评

技术小美 2017-11-17 16:44:00 浏览688
展开阅读全文
项目总监的方法论总结——点评
在MSN项目管理群里,一位很资深的IT工作人员推荐她的博客,我粗看了一下确实不错,准备每篇阅读一下,当然也希望通过点评一下来提高一下自己
原文地址:http://blog.csai.cn/user2/50754/archives/2009/37097.html
公司最近一下签了好几个软件项目的单子,销售额得上千万了吧?本是好事,可是公司以前从没有同时做这么多项目,这种信息化项目,周期较长,客户都是大型国有企业,不好伺候。作为项目总监,管理着所有的项目和产品线,每天堆积到我这里的问题层出不穷,搞得焦头烂额。蓦然回顾,才发觉自己和以前做CMMI顾问(做了4年半啊)时宣讲的那些好的做法相距甚远,自我反省并用通俗的语言提炼了一下,以期提高工作效率。
--上千万的单子
--首先需要需要对单子进行分类,大单还是小单;单子复杂难易程度如何?是新技术新业务还是基于已有的项目;单子的优先级如何
--上千万的单子如果单纯安装人月/人收入去评估,需要多少研发人员,是否能够交叉平行,研发人员是否能够相互渗透到不同项目中。
--给每个项目制定相关人力、时间、成本计划。
1.做事首先要建立一个明确的指导思想;原则不确定,无法谈下面的。唉,这个“生产管理的项目”为什么一开始不说好可以不以现有的产品为基础呢,白白各个部门扯皮了那么久!
--同意,但这个指导思想是建立在之前的分析基础上的,基于产品看似很简单,但也会面临很多问题,以部分为基础能否兼容?是否面临集成问题?
2.做事要有计划;计划,计划,项目组自成立以来,似乎天天做计划,可是到现在团队没有团队的计划,个人没有个人的计划。
--作为项目经理要有项目计划,作为研发人员也要有周计划,但是作为项目总监需要对每个项目的进展、问题、过程、风险有所评估,项目总监只需要看到项目经理的计划即可。
3.为要做的事配备合适的资源;是“合适”的而不是“足够”的。为什么项目经理都认为公司一定要给你配备最强的人呢,给你配最强的了,别的项目咋办呢?
--这个非常赞同。但前提是项目总监得了解自己的项目经理,他的业务水平、技术水平、管理水平、性格等等,把人放到合适的位置上,发挥和挖掘他的潜力。
4.给参与做事的人分配责任和权限;本公司的组织结构很特别,项目经理和产品经理都集中在一个部门-项目管理部,然后是软件设计部,开发部和测试部,最后还有个实施部,1个项目从头到尾,至少要经过销售、咨询、项目管理、软件设计部、开发部、测试部和实施部7个部门,责任和权限难免有定义不清楚的地方。
--总的感觉,分工过于细致了,不清楚公司规模公司状况,无法下定论;部门越多,相关利害关系就越大,对于小公司建议以项目组方式存在,但必要的监管部门是必要的。
5.培训人员;说来惭愧,我这个项目总监就没对项目经理做必要的培训,尤其是新来的项目经理,注意事项等等,项目经理管理着不是他下属的项目成员,经常整的鸡飞狗跳,我倒成了大保姆了,老要给人做思想工作。
--培训人员,个人认为应该上升到公司制度层面和绩效考核层面,但很遗憾,没有公司愿意去投入或是不能持续下去;这一点外企做的很出色,让你能够感受到自身能够提高,而不是单纯的coding和工作。
6.对产出物进行配置管理,简单得说,就是保存工作成果并版本控制,保证需要时能找到、找对成果物。
--配置管理是CMM2的基本要求,也是公司应该加以重视的一块。配置管理在项目中通常只是给别人看的,实际上没多少人去重视。
--配置管理对于大型系统的研发管理和多版本的研发管理是很有益的!
--配置管理对于形成公司级的组织研发能力和知识库是很有帮助的!
7.识别谁是共利益者并拉其“下水”,一起做事。注意,首先就是“识别”,而不是恨不得把每个人都拖下水。有个咨询项目,10几万的小单,两个人做足矣,一遇到困难,就拖着别人一起干,最后拖下水的共有7人之多,整成了个烂摊子。
--区分相关利益者,关键的和非关键的,核心的和非核心的,参与的和公司领导。
8.确定了以上的原则和方法,要有人度量过程,即使是1个人的工作,也要做度量。只有度量了,才好监控。现在谁都爱说事情难做,凭什么呢?举例说,本人8个月内跟绩效考核相关的工作,仅方案就写了5稿,跟老板汇报了3次,跟CTO讨论了3次,跟HR总监讨论了4次,跟人事专员讨论了1次,跟各部门经理讨论了6次,跟项目经理/产品经理讨论了3次,每次讨论平均2小时/次,中间附带还做了2次培训....而且至今还没成果,有了这些数据,我说难做。大概不会有人反对。喜欢记录数据,这是至今为止我仍然还保持的以往的好习惯。
--度量是软件过程管理中一个比较高阶的阶段了,这个的确很难做,但是又不能不去做的事情
--我的看法是从简单入手,从代码的审核、质量着手对开发人员进行度量;从代码的测试bug数量、重要程度对测试人员进行度量;从项目的实施过程和计划相比对pm进行度量。
--首先度量,有了数据基础,才能做其他事情。
9.要找人来客观评价所做的效果;目前好像只有靠客户来检验成果,公司的QA形同虚设。
--多数情况下,QA也是不被重视的,测试作为QA中的重要环节,应该独立出来,但也会根据公司规模而定。
10.要让你的上级及时了解进展和存在的问题;这个“上级”如果在比较复杂的管理模式下,应该在一开始确定清楚,现在存在两种现象,或者只跟部门领导报告,项目经理不清楚,或者只跟项目领导汇报,部门领导不清楚。在压力巨大,貌似人人都完不成任务的情况下,只有求助以前的经验,去探讨一些“方法论”,“磨刀不误砍柴工”嘛。
--项目总监需要根据项目经理的汇报并了解情况下向上级汇报进展和问题的,只有当压力和问题存在的情况下,才需要求助于上级寻找相应的人力资源、技术资源和其他帮助。
 




本文转自baoqiangwang51CTO博客,原文链接:http://blog.51cto.com/baoqiangwang/312826,如需转载请自行联系原作者

网友评论

登录后评论
0/500
评论
技术小美
+ 关注