51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 2270|回复: 2
打印 上一主题 下一主题

[原创] 项目管理十大TION法

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2010-6-11 15:46:24 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
强子从事测试管理工作多年,对于项目管理有一些自己的理解,除了几年前的一篇“治大国如烹小鲜”后(http://bbs.51testing.com/thread-178859-1-1.html ),就没有再写过很多关于项目管理的东西了。在给学员做培训的过程中总结了一些项目管理的法则,姑且标题党一回,称作十大TION(心法)

1. Organization
组织,角色:要确保一个项目能够成功,首先必须定义好项目级架构,各角色分工必须明确,这样使项目组成员能够专注于各自的领域,而不是学会推卸责任打太极。同时,项目经理要做的另一件非常重要的事情就是从老板那里获得充分的授权,因为项目经理不是一个行政职务,不像部门经理一样有很多实权,所以项目经理权利的大小直接决定了项目经理能否有效地控制项目组,对后续工作的开展起着决定性作用。

2. Communication
沟通,交流:项目经理处在一个中间位置,要沟通的对象成分极其复杂,得跟老板沟通,跟项目组成员沟通,跟客户沟通,跟相关辅助部门沟通,跟供应商沟通。同样,项目组成员也需要很多沟通。所以,我们要确保沟通渠道的畅通,要鼓励沟通而不是害怕沟通,另外,项目经理应该努力使项目组内部成员对于项目相关事宜达成一致,任何时候保持统一口径。
另一方面,一些既定的沟通方式也很重要,比如沟通工具:面对面,电话,即时通讯,邮件等,我们应该合理地利用起来,但是不能乱套。比如沟通计划,如周会,日会,异常处理会议,阶段会议等。作为项目经理,对这些方面的事情都应该有一个全局的把握。

3. Presentation
表达,陈述:一个好的项目经理一定是可以有能力把复杂的事情简单化,至少他应该可以把复杂的问题表达得简单易懂。同时,我们也需要清晰地传递信息,安排任务。但是在这方面似乎有些人并不这样认为,有些人的风格就是把事情说得复杂,故意表达得不清不楚,让别人去猜。对于没有自信的人来说,或许只能通过这种方式来提升自己那一丝脆弱的威信吧。

4. Investigation
调查,研究:四川有句老话,大谈特谈自己根本不知情的事情,叫“开黄枪”,并且还配上了一句优美的英文“Open Yellow Gun”。对于项目管理来说,这可是大忌,项目经理要认真调研客户需求,不可想当然;要做好计划,评估时间;要估计好可能的风险,做好预算等。项目成员也同样需要评估项目实施过程中的难度,不可完全凭经理办事,必须有效估计到可能的技术难度等。
项目管理一个最重要的理念就是:“目标导向”,如果一开始我们连自己要去向哪里都没弄明白,那么后面走得越多,错得越多,离目标就越远。这也是为什么我们一直强调Do Right ThingsDo Things Right更重要,因为如果一开始做的就是一件不正确的事,那么用越正确的方法去做就错得越远。

5. Documentation
文档,资料:项目实施过程中会产生很多文档,搜集很多资料,并最后形成组织的知识库。笔者很推崇敏捷开发理念,推崇简化一些繁琐的流程和文档,但是有些很重要的文档不能没有,该细还得细,否则会是一盘散沙。如需求文档,设计文档,测试用例,缺陷管理等几类重要的文档,当然形式不限,但是这些文档不但是为整个项目提供参考,并且在项目完成后,我们总得留下点什么吧。

6. Preparation
计划,准备:日程安排,里程碑计划,人员安排,软硬件资源的购买,准备等。实践证明,一个再牛的项目经理,也无法预知明天可能发生的事情,就像平常人一样,谁也无法预测下一秒钟会发生什么。所以在做项目计划时,也千万别指望着一次搞定,后面必须严格按照计划实施,谁不按照我的计划来我跟谁急。不论再大再小的项目,将项目分成一个一个的里程碑总是好的,每一阶段完成既定的目标,我们便可以认真安排这一阶段的事情而不是整个项目,毫无疑问,我们计划一个月的事情总比计划半年的事情来靠谱吧。最好是在每一个阶段中定义好要完成的事情,最好能细分到周,第一周要达到什么目标,第二周要完成什么事情,这样的计划才有意义(如果我们的计划不是为了应付谁的话)

7. Implementation
实施,执行:随时跟踪项目进展,解决遇到的困难,与客户保持紧密沟通,防止一些大的变更拖累项目进展。这个过程没太多好说的,一个字足可以表达“干”,如果换成英文的话会比较长“Just Do It”。

8. Evaluation
评估,评价:实施过程及实施完成后需要做的事情,包括对项目本身的评价,对各类异常及缺陷的评估,对项目团队的绩效评估,最好每个组织有一套自己的评估体系,相应的评估标准最好可以量化。但是切记不可为了评估而评估,评估的目的应该明确,为什么要评估某一项指标,其意义何在,并且应该再问一次,真的能实现这个意义吗?如果评估的目的不明确,那么我们就是在浪费时间和生命(如果我们的评估不是为了应付谁的话)。大家可以参考CMMI关于MA过程域相关细节,只要不照搬就成。这世界上没有任何最佳实践的东西是可以照搬的,辩证接受,仅供参考,就像本文一样。

9. Appreciation
激励,感谢:项目完了就完了?该干嘛还干嘛?我想这是大多数像我一样拿着老板薪水的员工在辛辛苦苦加班后最不愿意看到的结果,而且也是最不想用这个问题去问老板的。我们期望老板能自觉一点,别那么小气,多少给点儿是吧。作为项目经理,你不能完了就完了,是谁成就了项目经理,不是他们自己,也不是他的老板,而是一帮干活的人(此话同样适用于任何其它中层管理者)。即使我们手头没有预算,也可以尝试着为兄弟们申请点儿吧。
当然,这只是一方面,我们还可以在激励上做很多事情,如在老板面前对某人大加赞赏,在任何时候对任何表现不错的人进行肯定,甚至自己掏腰包请吃个饭,打个球什么的。这不是是在例行公事,而是人与人之前再正常不过的交往了。

10. Introspection
反省,总结:项目过程中的错与对,是与非,得与失,爱与恨,都是值得并且应该总结一下的。一个项目经验,甚至一个组织,经验往往来自于这一步。并且这一工作是随时可以而且应该进行的,而不是某一阶段的结束或整个项目的结束,当然,某一阶段或整个项目的结束后应该有一个更正式的反省和总结,并且最好是全员参与的大讨论,并且这种讨论如果能以茶话会的方式在一个相对轻松的环境下进行会比一个个板着脸说三道四要来得有效。

项目经理说:我本不想应付,可是我必须这样做,项目经理泪流满面。
项目成员说:我本不想应付,可我实在太辛苦了,项目成员泪流满面。
强子问:既然大家都不想应付,都想踏踏实实把事情做好,为何还要应付,而且把应付当成家常便饭,难道我们做计划是为了应付,写文档是为了应付,写代码是为了应付,报缺陷是为了应付?情何以堪?情何以堪?忍不住泪流满面。

不管如何,有一个原则我们一定要去实践:每一个项目,我都能结交到一位很好的朋友。

(声明: 本文版权归作者个人所有, 如需转载, 请注明出处, 如有需要, 请联系QQ: 15903523 (强子))
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

2#
发表于 2010-6-12 13:43:37 | 只看该作者
好高深啊~~呵呵,顶
回复 支持 反对

使用道具 举报

该用户从未签到

3#
发表于 2010-6-12 14:47:41 | 只看该作者
很犀利、、  贊!
回复 支持 反对

使用道具 举报

本版积分规则

关闭

站长推荐上一条 /1 下一条

小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

GMT+8, 2024-11-8 16:35 , Processed in 0.067926 second(s), 27 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

快速回复 返回顶部 返回列表