艾伟也谈项目管理,对项目管理的几点认识

自2007年参加工作以来,参与的项目也有好几个了,但都是以项目成员的角色参与,从来没有以项目经理的角色参与项目。中国有句古话叫“旁观者清”,同一个问题站的角度不同,可能会形成不同的结论。下面我就以一个普通项目成员的角度谈一下对项目管理的几个看法,希望大家给予指正。

1. 团队成员选择 人员选择要谨慎,要尽量选择合适的人员,在选择团队成员时要重点考虑其团队合作能力、编码可读性、能力和项目的匹配度等因素。

2. 项目远景的确定 项目初期项目经理需要和高层以及客户协商,定下项目的远景目标(即项目的目的,要实现的整体功能等),远景目标不用太长太细,但一定要有,好的远景目标犹如大海中的灯塔一样,可以让项目组不会在项目过程中迷失方向。

3. 项目计划 项目计划是项目最重要的文档之一,需要由项目经理根据实际情况进行制定,需要注意的是项目计划不是一次确定永远不变的,项目计划是一个从粗到细、从大到小的逐步过程,需要在项目的整个周期不断细化,调整。

4. 需求阶段 按照公司的方向需求由专门负责需求的人员来收集,需求人员将需求定义好形成文档后,再由项目组人员进行设计。身为项目经理一定要尽早参与这一过程,介入越早越好,需求收集过程可以以需求人员为主,项目经理为辅的模式进行,由需求人员负责收集需求并以需求用例的方式编写文档,由项目经理审阅并组织需求评审,只有需求评审通过后,需求收集过程才能阶段性结束。

5. 项目框架选型和搭建 需求确定后,如果客户没有明确要求,项目经理需要为项目确定框架和采用的技术。有时这一过程可以由项目经理和项目组中的技术骨干一起来完成。

6. 设计阶段 由项目经理和技术骨干一起完成项目的总体设计并经过设计评审,然后各个分模块的设计可以分给具体的成员来设计、由项目经理和技术骨干审核;也可以不分统一由项目经理和技术骨干完成,但设计文档一定要由惟一的一个人来完成(项目经理通常是最佳人选),一则可以保持文档编写风格的一致性,二则可以保证项目组有人可以通晓整个项目的详细设计,从整体上把关,三则可以节省项目成员的时间,让其将精力放在实现上。

7. 实现阶段 进入实现阶段后,项目经理需要控制的方面主要有代码质量控制、进度控制控制等,代码质量可以通过代码抽查、复查、制定代码签入规则等手段控制,进度可以通过检查进度表来控制,需要注意的是项目经理要随时准备好帮助项目成员解决遇到的难题,包括技术和非技术方面的。

8. 测试阶段 需求文档确定后,就需要和测试组进行协商,由测试组准备测试用例并提交大概需要的测试时间。随后的各个评审(如设计审核)要保证测试组必须有人参与,因为测试人员和QA人员更能发现评审问题。

9. 实施 进入实施阶段后,项目遇到的问题会比较多,其中很多并不是技术方面的,而是客户管理制度方面的、客户现场环境方面的。由于经过长期的开发阶段项目成员都比较疲惫并且在实施阶段出现的问题比较多,所以项目成员在士气和心情方面容易不稳定,这时就需要项目经理来掌控,要稳定项目成员的心情、提升士气,并多和客户沟通解决发现的问题。

10. 技术测试 如果项目是以前没有做过的类型,则需要通过技术测试来验证选定的技术是否具有可行性,技术测试需要注意的问题有技术测试一定要模拟最终用户的实际环境,不能在开发环境中进行测试。

11. 签入控制和进度控制 项目经理一定要保证每天有合适的时间段用来检查项目成员签入的代码的质量(包括功能正确性和规范性等)和任务的完成情况,发现问题要及时解决。

12. 任务分配 任务分配宜小不宜大,一般来说分配周期可以以一周为一个周期,在给成员分配任务时需要得到成员肯定,不能硬性的分配任务。可以参考XP的任务分配法。

13. 定位问题 项目经理首先要明白自己所处的位置,明白自己是一个枢纽,要起到润滑油的作用,处理好项目各关联方的关系。项目经理不一定是项目组中技术能力和管理能力最强的人,但一定要是项目组中最会处理人际关系的人,所有的管理问题归根结底都是人的问题,把人的关系处理好了,项目管理就成功了一大半,“会做的人让他做,不会做的人教他做,不愿做的人催他做”。

14. 项目规范的制定 身为项目经理就是项目的总负责人,有些项目的基础规范需要项目经理来制定,比如项目代码规范(可以在公司代码规范基础上进行修改)、项目沟通机制(项目例会多少时间召开一次?以什么样的形式召开?项目进行过程中如果遇到了问题怎么反馈?)等。

15. 权利的应用 身为项目经理,在项目中所拥有的权利肯定比其它团队成员要多,行使权利的机会也较多,但项目经理一定要合理的使用自己的权利,权利行使不当容易伤害团队的氛围,影响团队的战斗力。在行使权利时有两点要注意,
1)要多使用影响力,少使用组织赋予型权利,影响力是指自己通过平常的为人处事、通过自己的工作资历和解决问题的能力挣得的,有时可能一个普通的团队成员其影响力会大过项目经理;而组织赋予型权利是公司章程中赋予的,在项目团队中肯定是项目经理的组织赋予型权利最大。多使用影响力少使用组织赋予型权利可以比较柔性的管理项目团队、不会让人感到盛气凌人,不会引起反感,对凝聚团队成员比较有好处。但如果遇到非应用组织赋予型权利不可的时候也不要犹豫,一定要明白组织赋予型权利是解决问题的一种方式,只不过其优先级低于影响力。
2)切莫看低自己,有些项目经理以为自己只是干活的,和普通项目成员的惟一区别只是自己要干的活多一些,这是很错误的认识,如果有这样的认识就不能合理的行使自己的权利,就不能起到枢纽的作用。

16. 月考评的应用 公司规定项目经理给项目成员进行考评以决定项目成员每个月的绩效工资,这等于是交给了项目经理一把双刃剑,应用的好可以提高团队士气,应用的不好不仅会损害团队士气也会增加项目成本。在月考评时需要注意下面的几点:
1) 考评规则提前声明,在项目开始的时候就需要和团队成员一起制定一个考评的简单规则,规则制定时不要一人独断,要多听团队成员的意见。规则制定可以考虑出勤率、代码质量、代码规范、任务完成情况、是否提供了节省团队时间的工具等因素。
2) 考评要合理公正。不能依个人喜好打分,也不能全部打高分,要依据考评规则合理的打分。

17. 加班情况的处理 加班是不得已为之的行为, 要谨慎使用,如果逼不得已非要加班不可也要做好安排,要先将加班申请通过、要协调加班日期、要确定加班需要完成的任务并检查任务完成的情况。另外关于加班有一个说法是如果项目的某一个里程碑是通过大量加班完成的,那么下一个里程碑肯定会延后,我个人觉得这是很有道理的。

18. 出差情况的处理 公司开发人员大部分在济南而项目多是东营的,这就要求项目成员经常出差,这是无法改变的事实,但长时间的出差会影响团队士气和效率、也会增加项目的成本。这就要求项目经理多注意出差对项目的影响,要合理的安排出差的人员和周期,如果某些团队成员出差时间较长了,需要注意长时间的出差是否使其“后院不稳”,若有必要,可以出面帮忙解决。

19. 项目组杂事的处理 项目经理是项目的总负责,也是项目的总管。项目经理要为项目团队做好服务工作,不要让日常的琐事来骚扰团队,该为团队成员挡的琐事一定要挡在团队之外。

20. 责任的担当 项目经理是项目的总负责,所以一定要对项目负起责来,当项目能够顺利完成时,要明白这是项目团队合作的结果并不是自己独立完成的,要和项目团队分享功劳。当项目不能顺利成功时,要明白自己肯定是最大的责任人。另外要学会为项目成员承担责任,当某个项目成员犯错后,作为项目经理需要学会接受来自外部的批评并适度的保护项目成员。

时间: 2024-09-20 04:08:27

艾伟也谈项目管理,对项目管理的几点认识的相关文章

艾伟也谈项目管理,我是如何带领团队开发项目的

最近有不少朋友写信问我一些关于团队开发的问题,由于这段时间有些忙,没有回复.今天写一篇这方面的文章向大家介绍一下我是如何带领团队开发工作流项目的 关于团队建设,项目管理的文章网上已经有很多了,在这里我就不谈这些理论了,直接给大家展示一个我在 项目开发方,后台服务开发方式,前台UI开发方式,后台服务与前台UI对接方式,代码文档,页面的开发文档,源码管理,单元测试,以及单元测试文档,实现思路设计文档,数据库文档,数据库设计规范,编码规范,操做数据的方法命名规则 方面的一些片断,这是一个为期6个月的工

艾伟也谈项目管理,编程习惯

文/Alexey Radul 译/程显峰 原文地址:http://web.mit.edu/~axch/www/programming_habits.html 近年来,我对编程艺术有很多体会.过后,我发现有些体会是错的:有些体会我遗忘了但又重新感受到:而另外有些则是必然会发现的.我还完善了一套项目管理的好习惯,这些习惯包括我自己的,或者小组的,抑或是更大的,公司内部的.一方面,这些习惯对软件的成功开发是至关重要的(太小或者纯粹巧合的不算),另一方面,这些习惯也不是什么高深莫测的东西,较小的篇幅就可

艾伟也谈项目管理,ERP项目实施要未雨绸缪不要亡羊补牢

在ERP项目中,要做到在项目实施的未雨绸缪,不会出现亡羊补牢的情况就需要项目管理和实施人员在项目推进过程中队下面的阶段进行预测,把握好发展的趋势,掌握项目的主动权.下面就提出一些建议,供大家讨论.希望对大家有用. 一.要考虑每一个项目阶段普遍存在的问题 ERP项目可以根据项目进度,分为项目立项.需求调研.业务流程重组.模拟运行.并向运行.正式上线等几个阶段.其实不同的企业,虽然有各自的特性,但是也存在着一些普遍的问题.有经验的项目管理员,对各个阶段普遍存在的问题有深入的了解.此时他们就可以预先采

艾伟也谈项目管理,我也发软件开发团队的思考(侧重点是人员)

//上个月给我们老板的mail.洋洋洒洒6000多字. //为了方便公开,改了一下.以致可能有些地方前言不搭后语. //不管他同意不同意,先在我们组实行了再说. //请多大家多提提意见,日后看有没有机会找老板当面交流 经历的几个项目,项目的进度老是不尽如人意.更重要的是市场的开拓因为这些项目拖住了后退而无所作为. 我们现有的情况是:项目期限和最开始的保守估计都相去甚远,最后提交给客户的产品60%都是最后一个多月开发出来的,还有20%左右是以前就固有的固定模块.这几个项目我参与了编码,我对整个系统

艾伟也谈项目管理,我的项目管理观点

    公司要我给项目经理做一个培训,关于项目经理的做事情的方法和观点方面.我就采用了Workshop的方式,Workshop不是会议模式,而是侧重于交流会谈的一种模式,毕竟大家都是项目经理,并非说我的做法就是对的,所有的一切都是自己的经验之谈,所以我只是说大家彼此分享经验,交流心得.我把我所要分析的内容大概做了一个讲义,也希望更多人能够参与到这个Workshop中.项目经理好做吗?      项目经理好做吗?好做!项目经理好做吗?不好做.不同的人.不同的态度.不同的方法,其结果也就存在有极大的

艾伟也谈项目管理,软件架构引言之项目管理的问题

软件架构引言之项目管理的问题   很多朋友都有过或者正在管理一个或者多个软件项目,那么我的文章就从这个问题开始:如果单纯从表象来说,软件项目管理过程中暴露的最大问题是什么?   不同的人的会有不同的答案,但是大致这样的答案我想大部分人都是会认可的,那就是"进度拖延".进度拖延当然是表象之一了,其他诸如质量不过关.功能不完整等等,我觉得都是和进度拖延密切相关的.很多项目经理都想去做那些认为是十分必要的事情,比如计划.测试等,但是"没有时间".为什么会没有时间?等到项目

艾伟也谈项目管理,项目管理 – 人员外购利弊谈(续)

      接上一篇文章"项目管理 – 人员外购利弊谈". 以上方案只是初步分析,其缺点都是有相应解决办法的. 该公司对以上情况并没有使用DAR(决策分析解决方案)方法进行正式和认真的分析,仅仅从能快速启动和项目利润两个方面考虑来选择了最终的解决方案:项目经理由公司的技术和业务都掌握的人员担当:各小组的组长和测试组长采用人员外购的方式:项目组成员1/3由公司员工组成,1/3由实习人员组成,1/3采用外购方式.      公司如此考虑:      i.成本方面可以通过实习人员省出来的成本

艾伟也谈项目管理,动起来再调整 - 向项目经理推荐敏捷

要成为一个好的项目经理需要学会逆水行舟.虽然顺水推舟有时也能到达目的地,但学会逆水行舟,你才能到达任何地方. "虽然很有道理,但我认为现实不允许,很多项目都有规定的期限.中途还有给客户演示效果,往往实际项目中都是按最后上线日期来进行项目规划管理的." "写得不错,但是有些建议过于理想化了.毕竟说得很有道理,但实际中具体做起来又不是那么一回事了." 这是两位网友对<软件项目经理新手上路>的评论.这话很有道理,也是在现实生活中碰钉子碰出来的.在项目中确实存在

艾伟也谈项目管理,需求管理成熟度的五个级别

需求管理是软件开发全生命周期重要的一个环节,我们每个人都知道它的重要性,但是要真做做好并不简单,我也写了一本在线电子书业务分析与需求.pdf来讲解需求相关内容.对于每种技术和方法,就像以前我写过的企业架构成熟度模型(EAMM)的一样,我们都不可能一下子就精通,而是按照一种学习的曲线进展,本篇本篇主要介绍一下需求管理成熟度的六个级别. 级别0:没有需求(no requirements) 没有任何明确的需求被记录下来,他们假定知道要构建什么,希望节省需求的时间来做开发,但这势必会给开发工作带来混乱,