谈谈对项目管理的认识与理解

即使在最完美的条件下，管理一个软件项目也是很困难的。不幸的是，许多新项目经理实质上没有受到任何就职培训。这里有20个成功的管理经验供项目经理参考。不过，只依靠某一两条“妙计”，是无法顺利完成项目的。

1定义项目成功的标准

在项目的开始，要保证各方对于判断项目是否成功有统一的认识。通常，跟紧预定的进度是明显的成功要素，但是肯定还有其他的因素存在，比如，增加市场占有率、获得指定的销售量或销售额、取得特定用户满意程度、淘汰一个高维护需求的遗留系统等。

2把握各种要求之间的平衡

每个项目都需要平衡它的功能、人员、预算、进度和质量目标。我们把以上五个项目方面中的每一个方面，综合成一个约束条件，你必须在这个约束中进行 *** 作;你也可以定义成与项目成功对应的驱动力，或者定义成通向成功的自由程度。可以在一个规定的范围内调整。

3定义产品发布标准

在项目早期，要决定用什么标准来确定产品是否准备好发布了。你可以将发布标准基于：还存在有多少个高优先级的缺陷，性能度量，特定功能完全可 *** 作，或其他方面表明项目已经达到了它的目的。不管你选择了什么标准，都应该是可实现的、可测量的、文档化的，并且与客户所指的“质量”一致。

4沟通

尽管可能无意中了不可能的事件，但不要做一个明知不能保证的。坦诚地和客户和管理人员沟通那些实际成果。任何以前项目的数据会帮助你做说服他们的论据，虽然这对于不讲道理的人来说没有真正的作用。

5写一个计划

有些人认为，花时间写计划还不如花时间写代码，但是我不这么认为。困难的部分不是写计划，困难的部分是做这个计划——思考，沟通，权衡，交流，提问并且倾听。你用来分析解决问题需要花费的时间，会减少项目以后会带给你的意外。

6把任务分解成“英寸大小的小圆石”

“英寸大小的小圆石”是缩小了的里程碑。把大任务分解成多个小任务，帮助你更加精确地估计它们，暴露出在其他情况下你可能没有想到的工作活动，并且保证更加精确、细密的状态跟踪。

7为大任务制定计划工作表

如果你的组经常承担某种特定的通用任务，你需要为这些任务开发一个活动检查列表和计划工作表。每个检查列表应该包括这个大任务可能需要的所有步骤。这些检查列表和工作表将帮助小组成员确定和评估与他必须处理的大任务相关的工作量。

8计划中，在质量控制活动后应该有修改工作

几乎所有的质量控制活动，如测试和技术评审，都会发现缺陷或其他提高的可能。你的项目进度或工作细分结构，应该把每次质量控制活动后的修改，作为一个单独的任务包括进去。如果你事实上不用做任何的修改，很好，你已经走在了计划的前面。

9为“过程改进”安排时间

你的小组成员已经淹没在他们当前的项目中，但是如果你想把你的组提升到一个更高的软件工程能力水平，你就必须投一些时间在“过程改进”上。从你的项目进度中留出一些时间，因为软件项目活动应该包括做能够帮助你下一个项目更加成功的过程改进。不要把你项目成员可以利用的时间100%的投入到项目任务中，然后惊讶于为什么他们在主动提高方面没有任何进展。

10管理项目的风险

如果你不去识别和控制风险，那么它们会控制你。在项目计划时花一些时间集体讨论可能的风险因素，评估它们的潜在危害，并且决定你如何减轻或预防它们。

11根据工作计划而不是日历来估计

人们通常以日历时间做估计，但是我倾向于估计与任务相关联的工作计划(以“人时”为单位)的数量，然后把工作计划转换为日历时间的估计。这个转换基于每天我有多少有效的小时花费在项目任务上，我可能碰到的任何打断或突发调整请求、会议，和所有其他会让耗费时间的地方。

12不要为人员安排超过工作时间80%的任务量

跟踪你的组员每周实际花费在项目指定工作上的平均小时数，实在会让人吃惊。与我们被要求做的许多活动相关的任务切换的开销，显著地降低了我们的工作效率。一个员工一周理论上工作40小时，但不要只是因为有人在一项特定工作上每周花费10小时，就去假设他或她可以马上做4个这种任务，如果他或她能够处理完3个任务，你就很幸运了。

13将培训时间放到计划中

确定你的组员每年在培训上花费多少时间，并把它从组员工作在指定项目任务上的可用时间中减去。你可能在平均值中早已经减去了休假时间、生病时间和其他的时间，对于培训时间也要同样的处理。

14记录你的估算和你是如何达到估算的

当你准备估算你的工作时，把它们记录下来，并且记录你是如何完成每个任务的。理解创建估算所用的假设和方法，能够使它们在必要的时候更容易防护和调整，而且它将帮助你改善你的估算过程。

15记录估算并且使用估算工具

有很多商业工具可以帮助你估算整个项目。根据它们真实项目经验的巨大数据库，这些工具可以给你一个可能的进度和人员分配安排选择。它们同样能够帮助你避免进入“不可能区域”，即将任务量、小组劳动力和进度安排组合起来一看，根本不可能成功。

16遵守学习曲线

如果你在项目中第一次尝试新的过程、工具或技术，你必须承受短期内生产力降低的代价。不要期望在新软件工程方法的第一次尝试中就获得惊人的效益，在进度安排中考虑不可避免的学习曲线。

17考虑意外缓冲

事情不会像你项目计划的一样准确地进行，所以你的预算和进度安排应该在主要阶段后面包括一些意外的缓冲，以适应无法预料的事件。不幸的是，你的管理者或客户可能把这些缓冲作为你的托辞，而不是明智地承认事实确实如此。向他们指明一些以前项目不愉快的意外，来说明你的深谋远虑。

18记录实际情况与估算情况

如果你不记录花费在每项任务上的实际工作时间，并和你的估算做比较，你将永远不能提高你的估算能力，你的估算将永远是猜测。

19只有当任务100%完成时，才认为该任务完成

使用英寸大小的小圆石的一个好处是：你可以区分每个小任务要么完成了，要么没有完成。这比估计一个大任务在某个时候完成了多少百分比要实在得多。使用明确的标准来判断一个步骤是否真正的完成了。

20公开、公正地跟踪项目状态

创建一个良好的风气，让项目成员对准确地报告项目的状态感到安全。努力让项目在准确的、基于数据的事实基础上运行，而不是从因为害怕报告坏消息而产生的令人误解的乐观主义。使用项目状态信息在必要的时候进行纠正 *** 作，并且在条件允许时进行表扬。

从普遍角度上说，一个有效的项目管理要从几方面入手。

1 项目范围

明确定义好项目管理范围，才能有效配置相应资源。

2 项目计划

根据项目要求，制定切实可行的项目计划。国内大部分项目经理都是根据上级指示做事，没有仔细做过项目评估，这就导致在项目执行过程中，经常出现不可控因素，影响了项目的执行结果。

3 项目资源

包括设备，材料，资金，人力资源等。关键是资金和人力资源，一个是保持适当的现金流，一个是保证有足够的人去做该做的事。

4 风险预估

包括对用户及对自身评估两部分。对用户主要涉及其信用度，财务状况，技术能力/经验等方面；对自身主要包括足够的项目管理人员，技术人员配置是否足够，经验是否丰富，有否做过同类项目，用户的付款条件对项目管理造成的风险是否可控？

以上是针对工程类项目，针对软件开发项目，在项目范围/风险中，还需要特别关注用户对项目的具体及特殊要求。

内容来源于ITSS符合性评估落地工具-云雀运维！！！

对项目管理的理解和认识

项目管理是一个很大学科，yjbys小编下面为大家整理了关于项目管理的理解和认识的文章，希望对你有所帮助!

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 责任的担当

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

1充分肯定人员在IT项目中的作用和价值

IT项目管理最大的一个复杂性就是人员的管理，对于IT项目中的项目成员都是从事有创造性的劳动，虽然CMMI更多的强调了过程的重要性，但一些通用的GP仍然强调了人对项目的重要性。没有规矩不成方圆，过程和规范固然重要，但不能因为过程和规范抹杀和项目成员的能动性和创造力，同时要肯定项目成员对项目成败的重要价值。

2选择和招募正确的人

首先是要选择或招募到正确的人，承认招聘是有成本的，也应该在招聘上做充分的准备。对人员考察的重点不仅仅是具备的知识技能，而更多应该是针对其个人性格，价值观，协作和沟通能力，自我学习能力方法的考察。个人的工作习惯不是一朝一夕形成的，而习惯形成又依赖平时的工作和生活的态度，态度决定一切；其次才是理解和自我学习能力，然后才是现有的知识和技能。

3为人员分配合适的工作

每个项目成员都有的各自的特长和性格特点，必须要充分考虑项目成员的技能情况和性格特点为他们分配正确的工作，同时还需要考虑项目成员的工作兴趣和爱好。尽量发挥项目成员特长，让每个人从事自己喜爱的工作岗位是项目经理进行工作分配要考虑的问题。各项目成员的知识技能评估，个性特点分析，优点和缺点是要事先分析和考虑的内容。

4考核要真正体现个人绩效

做的事情越多往往犯错的可能也越多，从事预研和创造性的工作往往没有结果，是不是完全根据产出物质量进行考核？这些是经常遇到的问题，因此推荐的仍然是根据工作成果即难易度，个人的协作精神和价值观两方面综合进行考核。只有两个方面都表现不错的人才是项目真正的骨干成员，并且应在工作岗位和薪酬上得到体现，使其成为项目长期稳定的优秀员工。

5更多的是培养人而不是管理人

IT项目经理除了在项目前期依据个人经验充当领导和管理角色外，项目的执行过程中更多的应该充当教练的角色。只有真正的从培养项目成员出发才能够将被动的管理转变为自发和主动的管理。我们认为管理难很多时候进行的是强制性的管理，而这种管理是每个项目成员都反感的。你不是去指责项目成员当前犯的错误而是协助他分析为何会犯这样的错误，你不是帮助项目成员解决当前的问题而是教会他们如何解决以后类似的问题，转变态度使每个项目成员形成一种良好的工作习惯，希望习惯和学习方法是培养的重点内容。

6经常和项目成员进行单独的沟通

项目经理花在沟通上的时间在70-90%左右可见沟通在项目管理中的重要性。沟通体现了项目经理对每个项目成员的重视，项目经理应该定期和项目成员进行单独的沟通，了解项目成员的工作和生活情况，个人的职业规划和工作想法，单独指出项目成员工作中的不出和需要改进的地方。很多时候沟通达不到效果往往是项目成员并不会说出自己很多真实想法，因此沟通双方应该是完全平等的，开诚布公的进行沟通。

7冲突是不可避免的

在项目进行过程中，项目内部，项目成员和外部接口或干系人之间出现各种冲突往往是不可避免的。PMBOK的观点认为冲突往往对项目是有益的，对于项目成员间自己可以解决的冲突项目经理尽量不要越徂代疱，同时也要尽量不让冲突升级。项目经理作用就是让冲突在项目可控的范围内，并在冲突过后促进项目成员反思和学习。

IT项目管理是项目管理在IT领域的应用，结合IT行业特点运用项目管理技术、理念和方法，包括9大知识领域（项目综合、范围、时间、成本、质量、人力资源、沟通、风险和采购管理）以及启动、计划、实施、控制和收尾等过程组成。

软件项目开发管理过程中，不仅要努力实现项目的范围、时间、成本和质量等目标，还必须协调整个项目过程，以满足项目参与者及其他利益相关者的需要和期望；随着软件规模和所涉及的领域不断地扩大，软件项目的管理越来越困难。纵观所有失败的软件项目，基本原因是不能管理其软件过程，在无纪律的、混乱的项目状态下，组织不可能从较好的方法和工具中获益。严谨的软件过程控制与管理不仅可以在每个阶段回顾和纠正项目的偏差，识别软件项目的风险甚至果断中止项目，而且可以将人才流动所带来的不利影响减少到最小。要进行有效的过程控制，必须明确软件项目管理流程。

1、流程第一阶段：项目的启动

在项目管理过程中，启动阶段是开始一个新项目的过程。启动信息技术（IT）的项目，必须了解企业组织内部在目前和未来主要业务发展方向，这些主要业务将使用什么技术及相应的使用环境是什么。启动信息技术（IT）的项目的理由很多，但能够使项目成功的最合理的理由一定是为企业现有业务提供更好的运行平台，而不是展示先进的IT技术。

2、流程第二阶段：项目的计划

在项目管理过程中，计划的编制是最复杂的阶段，项目计划工作涉及九个项目管理知识领域。在计划编制的过程中，可看到后面各阶段的输出文件。计划的编制人员要有一定的工程经验，在计划制定出来后，项目的实施阶段将严格按照计划进行控制。今后的所有变更都将是因与计划不同而产生的。也就是说项目的变更控制将是参考计划阶段的文件而产生的。

3、流程第三阶段：项目的实施及控制

在项目实施阶段是占用大量资源的阶段，此阶段必须按照上一阶段定制的计划采取必要的活动，来完成计划阶段定制的任务。在实施阶段中，项目经理应将项目按技术类别或按各部分完成的功能分成不同的子项目，由项目团队中的不同的成员来完成各个子项目的工作。在项目开始之前，项目经理向参加项目的成员发送《任务书》。

4、流程第四阶段：项目的收尾

在项目管理过程中，计划的编制是最复杂的阶段，项目计划工作涉及九个项目管理知识领域。在计划编制的过程中，可看到后面各阶段的输出文件。计划的编制人员要有一定的工程经验，在计划制定出来后，项目的实施阶段将严格按照计划进行控制。今后的所有变更都将是因与计划不同而产生的。也就是说项目的变更控制将是参考计划阶段的文件而产生的。

5、流程第五阶段：项目的维护期

在项目收尾阶段结束后，项目将进入到后续的维护期。项目的后续维护期的工作，将是保证信息技术能够为企业中的重要业务提供服务的基础，也是使项目产生效益的阶段。在项目的维护期内，整个项目的产品都在运转，特别是时间较长后，系统中的软件或硬件有可能出现损坏，这时需要维护期的工程师对系统进行正常的日常维护。维护期的工作是长久的，将一直持续到整个这个信息技术（IT）项目的结束。

以上就是关于IT项目管理的20条锦囊妙计全部的内容，包括:IT项目管理的20条锦囊妙计、如何进行有效的IT项目管理、谈谈对项目管理的认识与理解等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！