[项目管理征文]我的项目管理之路--Randoming

我的项目管理之路

历程
我的职业生涯可以说基本上是一帆风顺的、也许这个和我的外语能力有关。


2000年的2月份进了当时在大连还是比较有名气的一家软件公司做对日项目，用PB来开发一些C/S系统。因为可以写程序日文也不错、很快就受到重用、本以为愉快的生活可以就这样一天天的过去、却3个月后公司就宣告日本业务继续不下去而解散。

经过和公司的洽谈、同意转到总公司做国内的银行软件、使用UNIX C。
没有了外语的支持就是一个普通的不能再普通的程序员了、没有了往日的优越、好在同事之间相处的到还融洽。只是作为一个新人、总是被安排做一些比较琐碎的工作而已。就这样过了2年…

上面因为是我的第一份工作 所以稍微写的多了点、之后就展转到日资企业里做一些JAVA和.NET 的项目、逐渐觉察到自己的日文还是比较有基础的、就这样做一些详细设计、
呵呵 现在想起来虽然没什么技术含量 也积累了自己对很多业务系统的了解。
之间过的很快、转眼已经2004年下半年、在一家大概300多人规模的外包公司做项目经理、
做的很偶然、也许只是因为我对公司的业务流程、部门的考核体制、项目开发与管理方面提出了一些见解、让部门老大觉得我比较有做管理的天赋。大概也有我日文不错的缘故吧。
不过不管怎么说、项目经理还真是个偶然性非常强的职位呢、也许你是技术骨干、也许你为公司做出了什么比较大的贡献、也许只是客户向领导跨了你几句、都有可能成就这个职位。

于是在这个职位上开始了不断的挣扎与努力、承受了很多、也分享了很多、满足了很多。
06年也考下了PMI的 PMP。

经验分享-杂谈
一、总括
要做好一个项目一定要有好的思维…这个是我一直以来始终信奉的有一句话。
是什么意思呢、就是说作为一个项目经理也好、一个程序员也好、你必须要思考：“我如何能做好这个项目”。具备了这一点后、才有了做好一个项目基础。否则如果单纯的为了完成一个项目而去做项目、说的不好听了，做的痴痴呆呆的、墨守成规的、那么我认为这个项目不可能被做好。

当然了只是想做好是不够的、一方面巧妇难为无米之炊、你要有资源、有启动并且开展这个项目的资源支持。同时还要讲求方法、只是想做好但是蛮干、那也是绝对行不通的。
在这里我可以给一些想进入项目管理行业的朋友推荐PMP体系、CMMI、等。这些知识体系只可以给你提供一种方法的导引、而不能硬性的照搬。只能用他们来开发自己的思维、为项目成功增添一些砝码而已。

所以想要成为一名好的项目经理就要有正确的理念、思维和态度。
有很多人说、这个项目经理的技术很差、我想很多人也都经常听或说这句话吧。
其实项目管理者不一定要技术强、技术太强反而容易陷入技术细节、而忽略全局。
此外成为一名优秀的项目管理者一定要有综合处理事件的能力、良好的沟通技巧、已经有条不紊的文档话能力和提案能力。

二、关于项目的定义：
这里我引用PMP关于项目的定义、为提供某种独特的产品或服务所做的临时性的努力
说的通俗一点、日常生活中的很多事情都可以当作一个项目、比如：
在一个孩子5岁前让他能够背诵下来一整本宋词。
1年内存够10万块钱。 我觉得都是可以当做一个项目来做。

那么项目的特点如下：
临时性 （不是永久不变的）
为了完成某种特定的产品或服务而做。

项目管理的过程
启动、计划、执行、控制、收尾

三、对日项目的特点
我前面几年都是做对日项目的、所以在这里我主要和大家分享对日项目管理的心得。

日本企业一般注重细节、注重软件工程、注重里程碑管理、必须在每个阶段提交每个阶段应有的成果物或称为 纳品物。 比如：概要设计、详细设计、测试式样（一般写些TEST CASE）、源代码、测试结果报告（一般沿袭测试式样、包括很多阶段、单体测试、功能测试、系统测试等）。 他们重视项目管理的数据性证据 也就是量化的结果



特点一：开发阶段的划分、里程碑的管理
    在项目启动之前、会把一个大的项目切分成几个小项目、从而明确每个时间段我们应该完成的目标 比如把概要设计阶段当成一个项目来做、那么这个项目完成的标志就是给客户提供让他们基本满意的概要设计书。 概要设计阶段提交相应的成果物后、客户验收合格、我们可以顺利的进入到详细设计阶段、之后代码阶段…
不过也不是完全固定的、有的时候为了缩短项目开发的整体周期、我们可以把几个项目阶段重合进行、比如在概要设计阶段完成50%后就开始进入到详细设计阶段。 这样做要注意的就是、要把成果物的验收细分到每一本设计书上去。
关于里程碑最直观的划分就是按照项目阶段来划分了、每个阶段完成后按照该里程碑完成要求进行验收、并提交相应的成果物、比如1本设计书、10本设计书、5本测试式样书等



特点二：项目管理的量化、与证据化

做任何事情都要讲求证据、特别是对日的项目、做为一个项目经理我们去和客户沟通 和老板沟通都是需要一定的证据、从而才能有效的获得支持。

◆
项目的估算、有很多估算的方法、我一般采用功能点估算。不过这个需要前期的数据积累、个人觉得比较适用于成熟的团队、成熟的业务系统。 估算过后、会有一个项目分解的表格、详细记述项目的整体规模（人月） 项目被分解后的单位规模：比如一本详细设计书 0.2人月（4天左右）

◆
项目成员的能力估算 做任何一个项目前、都必须要组建起一支队伍、也许这只队伍是你平时所熟悉、也许是你不熟悉的、如果你没有选择的余地、那么你只有接受。 一般情况下要先整理出一份团队的列表、不一定要有联系方式、根据自己的项目规模来判断是否需要、因为联系方式太全了、资料容易造成外泄、造成项目中成员流失从而带来风险。 在这份表格里、必须要有的就是团队的核定、什么叫核定呢、从字面上的意思来说就是一个人对比他的能力是否可以当成完整的一个人来使用。当然什么叫完整的人、需要在事前定下一个标准。 举个例子来说吧、有一个标准化的 增删改查的程序、A成员可以比较有效率的、低BUG的 用5小时来完成、我们把这个人当作是标准、做我们的参照物。 而B成员同样的BUG率要用10小时来完成的话、我一般把B员工的能力系数定为0.5。 一般来说我称呼这个为逻辑能力=0.5 物理能力=1 一个团队的核定一般我就如上面这样通过一些途径来大致的判断一下、至于有哪些途径来判断、就不再细说。我们重要的是要知道要做什么、目标明确了只要努力、相信总归会做到。 之后要做的就是核定整个团队的整体逻辑能力、比如我的团队有30人、可能经过我的核定、逻辑能力只能有20。 这个时候我需要参照项目的周期、和估算的规模、进行判断、是否能完成。 如果差距实在太大的话、我会起草正式文件、MAIL到各位老大手里、他们怎么决定是他们的事情、至少作为项目经理、我们有职责提出这样的风险、同时记录到风险识别的列表。 如果被授权招聘了那么就去招聘、或者从其他部门借调、途径很多。但是要强调的就是我认为逻辑能力的核定是肯定要做的。 团队组建了之后、我们还要了解他们每个人的专长、如果是被迫接受这个团队的话、每个人我都会拿出至少30分钟的时间和他们去聊天、也许我不会去问他们具体的技术、也许只是和他们聊一些工作的琐碎事情、或是他们是日常生活、但是通过这些我就大致可以知道哪些人有什么样的特点、性格如何等、看待工作的态度等、对哪些技术有兴趣以及造诣等。

◆
成员工作量的统计、 依据上述的量化结果、在项目过程中、严格监控成员的工作量一览。从而为以后的项目估算提供历史数据。也作为项目奖金的分配依据、能者多得。
◆
QA一览表的完整备案

这个东西、一直贯穿整个项目的进程、需要严格的分析、整理、共享 项目进展的过程中不可避免的会有非常多的困惑、这些基本都可以通过这张表格来完成和客户的探讨。
同时、项目组成员根据QA表的分类、主题等、可以查看到是否其他人问的问题也正是自己不懂的、从而提高效率。 另外QA表也作为和客户沟通的证据而需要重点保护、因为很多变更可能都是依据QA表来先期变更的。
◆BUG管理的量化 对于BUG的管理、分类也是很重要的、通过对BUG的分类 你可以了解到你的项目中BUG的大致类型、是哪些人犯的错误、什么原因会出现这样的BUG、从而及时准确的抓到关键点避免重复。
对于BUG数的分析、如果太多了、肯定要分析BUG类型 及时对应、及时调整、是追加培训还是通过其他途径。 如果BUG过少、反思一下自己的测试是否充分、到了客户那边再测试出比较多的问题就不是只丢面子的问题了。


特点三：安全管理
注重数据的备份、病毒防范、数据加密、成员出入考勤等

四、项目成功的支柱-开发的团队
※打造团队精神


※培养下属的自我激励意识、基于一种成功、成就、成长的意愿而自我激励与提升。在开发过程中不仅是做好自己的本职工作、还要积极的参与、从而为项目的成功添砖加瓦。


※培养下属的换位思考能力 我做项目经理的时候、也碰到过不少人对我的技术与管理方式不认同的人、我想这个也是很多项目经理都曾经碰到过的问题。
       所以我们要持之以恒的培养下属换位思考的能力、避免团队成员之间产生误解、创造和谐的作业范围。也可以避免因为自己的问题而给其他同事带来困扰。
项目开发团队是伙伴的关系、需要基于共同成功的目标而互相支持与帮助。


※
项目团队的阶梯打造
我不会在一个项目中放一堆的牛人、这个也是不现实的、资源毕竟是有限的。
另外一个方面、牛人与菜鸟的搭配我认为才可以激发战斗力、牛人有自豪感、菜鸟有奋
斗的目标。

五、沟通对项目的成功起到非常重要的作用
影响到沟通的有很多因素：比如管理的问题、团队成员不信任的问题、项目成员的个性问题等。作为一个项目管理者、不解决沟通问题是不可能做好一个项目的。
不定时的调整座位一方面也是为了成员之间更好的沟通。 项目启动之前要明确定义出来该项目的沟通途径等。MSN、IP Messenger、MAIL、PHONE都是可选的。 什么样的事情向谁去报告、都在这份沟通定义文件里指定。 根据项目的需要、看看是否每天必须有会议、可以灵活的进行。作为项目经理、是一个中心的环节、弄的不好客户 老板 上司 下属都会对你不满意、所以时刻要记住沟通的重要性。有时间的话多和上司去聊聊、听听他的想法、至少你和他多沟通会增加他对你的支持。多和下属聊聊、搞好关系、天热了请他们吃吃冰棍儿.. 下班了请他们出去唱唱歌放松一下、预算多的可以和老大去申请、也可以记入项目经费。其实人的本质中、最渴望得到的就是被肯定吧、所以多去肯定他们、启发他们的思维。 不过这些都要把握好尺度、过尤不及..我们中国人讲究人情、喜欢称兄道弟、但是太熟悉了他们就不在乎你了。出了问题也不好处理、所以要把握好尺度。 所有给客户发的邮件一般来说 我都CC给我的上司、碰到有的客户不讲理的、我就直接CC给客户的上司。邮件是一种证据、需要严格的保存好。碰到什么事情说不清楚了、 能拿出证据就是王道…


六、关于项目的变更
       我做对日项目、碰到最多的问题就是变更、也许这个机能都快做好了、客户突然说他要变更、很让人头疼的事情。 一般有这样的变更出现的时候、我都会自己先理解一下客户想要做什么、为什么他要变更、条件允许的话直接电话和客户交流确认一下、因为我以前发现过、他们想要实现的功能不要如此麻烦的变更就可以实现。所以大家碰到这样的问题一定要先理解客户想要什么。

不管怎么说、只要他们有变更来我都会记录到一份变更管理的文件里、我会把他们分类处理。
那么如何分类呢、我一般分成
流程变更       是客户废弃原来的流程而改用新的流程、肯定需要追加工数
BUG
因为我们的BUG而提出的程序修正            不需要追加工数
性能优化       根据具体情况来决定是否需要追加工数
机能追加       追加新的机能                                                 肯定需要追加工数

每个人的着眼点不同可能分类也不同、这样要强调的就是一定要非类、至于你怎么分、至少可以体现出责任在谁 工数大概多少就成。

七、总结
时间比较仓促、单纯的为了一篇征文而写、所以不能写的非常全面、总体上作为一个项目管理者来说下面的列表可能比较有用。
建立工作结构分解-WBS
文档化管理
项目估算-包括工作量的估算、成本的估算、
管理风险-定义和确立风险的影响和处理
管理进度-建立进度表以及关键里程碑
跟踪项目的过程-监控项目团队的执行力、使用定义好的量化标准监督控制项目的进展
头脑风暴的使用
分布在所有过程中的团队绩效管理
管理变更
培养自己的领导力、同时强化沟通技巧



[ 本帖最后由 randoming 于 2008-5-31 14:22 编辑 ]

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/10732849/viewspace-324627/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/10732849/viewspace-324627/