IT行业：不懂技术，怎么做好项目管理？

IT项目开发人员普遍认为，要高质量并按时完成项目是难以实现的，项目经理们并非不想要高质量的项目成果，他们只是想在质量的基础之上，能够按时完工和低于或等于预算的情况下，实现这个项目。有些项目管理技巧虽然确实可以成功地在降低成本和开发时间的同时不会对质量造成影响，然而，必需注意的是，过度地利用这些技巧就有造成灾难性后果的潜在可能。

1、时间盒(Time boxing)

在破坏项目质量的事件列表上，时间盒的应用排在第一位，当您告诉某人在任务必须移交之前，他拥有多长时间来完成这项工作，我说“移交”而不是“完成”，因为在极端情况下，这经常意味着代码并不完善，仅仅是抓紧时间去完成这项工作。

在大多数情况下，时间盒是有效的，因为它可以做到四件事：

1 它迫使开发者能够富有创造性地在他们的预算之内发现解决方案。

2 它排除了经常添加在软件中不必要的虚饰，而这些虚饰往往并不能增加软件的价值。

3 它防止开发者过度测试。

4 目的只是要得到这件产品，在完整的质量评价(QA)阶段将会有详细的测试，希望在此阶段中能够发现代码中存在的问题。

当存在未知问题，或技术没有经受检验，或没有正确的方法来检验结果的时候，时间盒就无能为力了;当时间盒很小，而且在分配的时间之内并没有可能的办法来实现目标时，这种方法也是无效的。换句话说，时间盒可以很好地解决一些问题，比如充分理解、谨慎评估和执行类的任务;然而，也确实存在时间盒方法不能很好解决的问题，比如研究和发展，还有解决问题等等。

如果时间盒是正确使用的，那么不应当导致测试到很糟糕的代码，这些糟糕的代码可能会导致数百个小时的诊断和返工。时间盒应当适度使用来确保最低的成本、最快和最高质量的软件。

2、误期

所有人都要有奋斗的目标，里程碑是一种受到尊敬的方法，它用来激发人们向同一个目标前进，这种动力可以在很短的时间内得到重大成果。然而，每个人都必须承认里程碑所界定的时间并不是每次都能实现，这时就必须要做出新的决定。

项目经理们必须要在团队中树立里程碑的目标，以此来激励他们前进，但是，当里程碑确立的日期并不现实，而且队员们一再出错，那就应该重新评估这个计划了。如果因为某种特殊情况可以使这个日期不再重要，那么当这个重要日期真正来临的时候，整个团队就只有很小的动力来实现这个里程碑日期。当整个团队连续错过了10个日期，那么第11个日期还重要么这就像喊着“狼来了”的孩子一样。

如果在设定的时间线之后并没有任何处罚，那么当错过这个时间的时候就应该强制执行或者移动整个时间线。

长远来看，不断创造持续的压力和令人迷惑的环境并不能创造出好的软件，开发人员需要能够专心工作的环境。完成项目的日期和关于里程碑日期是否真实的混乱，经常会导致开发人员在开发过程中跳过关键步骤或者造成难以发现的问题。

3、忽视相关性

在软件开发中，我们有很多技巧可以用来延迟相关性，我们可以停用一些函数、移动相连的基本架构，或者绕开众多的错误处理，在正确使用的情况下，所有这些技巧都可以帮助推进一个项目，然而，当为了完成项目，而这些技巧的成本因素又没有被考虑到整个计划当中时，就埋下了烦恼的种子。

很多时候，在项目中排列软件开发的顺序是非常具有挑战的事情，相关性并不容易被发现，因此也就不可避免地有很多相关性因素没有被安排到计划当中。为这些不可预见的相关性安排日程表可以让人变得疯狂，因此，压制相关性的方法是经常使用的，但是，如果过度使用了这些技巧，这些费用可能经常会占据项目总成本中很重要的一部分，而且直到项目的最后才会被发现。

所以要确信您现在所做的对于管理相关性是必需的，不会添加过多的成本，而且是整个软件开发项目中必不可少的一部分。当项目经理不能在成本与降低相关性的便利中取得平衡，那么他们草率地组装的代码将会展示出质量问题。

4、假装没有错误

在项目管理中，忽视并不是一种幸福。为了成功地完成项目，除了不可阻挡的政治压力，向公司其他的员工介绍项目的风险也是必需的。几乎每个软件开发项目都有延期或超出预算或同时出现这两种情况的风险。

问题在于，当最终某一时间，这些风险真正变为现实的时候将会引起恐慌，每个人都在混乱中将项目其余的部分组装在一起，整个项目的质量将因为最终轻率的装配而遭受损失。

当然，当整个项目还没有落后于计划之前，这一问题还不会充分暴露出来，然而，大多数项目都有办法只让项目的某些部分落后一点点，而几乎每个项目都有过于仓促的风险，这是因为管理层在很长一段时间之内都在项目没有任何问题之后得知项目的真实状态。

项目管理是管理学的一个分支学科，对项目管理的定义是：指在项目活动中运用专门的知识、技能、工具和方法，使项目能够在有限资源限定条件下，实现或超过设定的需求和期望的过程。项目管理是对一些成功地达成一系列目标相关的活动（譬如任务）的整体监测和管控。这包括策划、进度计划和维护组成项目的活动的进展。

“项目是在限定的资源及限定的时间内需完成的一次性任务。具体可以是一项工程、服务、研究课题及活动等。”

“项目管理是运用管理的知识、工具、技术于项目活动上，来达成解决项目的问题或达成项目的需求。所谓管理包含领导（leading）、组织（organizing）、用人（staffing）、计划（planning）、控制（controlling）等五项主要工作。”

扩展资料：

项目管理工程包括：开发管理（DM）、项目管理（PM）、设施管理（FM）以及建筑信息模型（BIM）。

而项目管理则又分为三大类：信息项目管理、工程项目管理、投资项目管理。

1信息项目管理

是指在IT行业的项目管理。

2工程项目管理

主要是指项目管理在工程类项目中的应用，投资项目以及施工项目管理。其中，施工版块主要是做到成本和进度的把控。这一板块主要使用工程项目管理软件来把控。

3投资项目管理

主要是用于金融投资版块的把控，偏向于风险把控。

很多公司的项目都是临时组织的，因此管理起来会有点复杂。尤其是技术项目类的，很多时候项目经理本身就不懂技术，因此，很多项目成员习惯第一时间和自己部门上级沟通汇报，而不是项目经理。这样子不利于项目经理把控项目成员，也不能及时进行工作跟进。对于这种情况，不懂技术的项目经理该怎么行驶自己的权力呢

其实项目经理要做到的是资源为我所用，顺利达成目标。不懂技术就要善用团队中懂技术的人。具体怎么用，看个人能力了。

项目经理是协调资源，订制总体计划，把控总体进度，风险控制。至于开发计划，只是各种计划之中的一个子计划，当然也是关键的计划。如果专业性太强，自己又不擅长，那么用人就用之信之，交给开发经理去全权处理把。能做到垂拱而治，方显自己的才能！而不是事必躬亲！

1、不懂技术，但要懂一些基本逻辑和常用术语，起码做到自己心里有一个概念，可以多问、多学习，日常工作中多记录总结，每次沟通中不清楚的地方都去搞懂它，以后就会越来越好。

2、尽量少发言，尊重专业人士的意见，多采用询问的方式，忌“半瓶子晃荡”；

3、与相关岗位负责人沟通，由他们主导制定一些规范、规则，用来指导工作；

4、做好组织资产的管理，及时归档保存，多参与沟通，提倡在项目进行过程中多进行文字记录；

5、多开会沟通，进行项目总结、阶段性总结，鼓励每个人发言，多倾听，很多时候，从侧面可以反映出很多东西，可以弥补技术的不足。

最重要的一点还是要多学习，做到可以正常沟通

项目经理的最终目标是完成项目，主导项目和体现自己在项目上的领导地位其实没有那么重要，只是一种确保项目按计划按要求完成的一种手段。

所以引导项目顺利完成交付，并保证符合公司项目管理要求，然后在项目交付过程中能得到提升，做到这个程度已经基本上算是完成项目经理的本职工作了。当然，如果你要追求个人形象，那么争取发言权还是很有必要的，但忌讳不懂装懂。

其实项目业务的掌握往往重于技术实现，这不是说技术不重要，而是在于用户更关注的是业务。所以掌握业务分析，确实可以从另外一个角度掌控项目。这只是一种工作切入方式，但我觉得最爽的事，掌握项目进度，看着就能把项目完美交付。

这个问题的侧重点在于项目经理对项目成功与否认识的问题。

1、项目成功与否，不仅是项目经理自己的认识，还体现在项目经理从本项目中得到什么？

2、试问这个项目结束后，从没体现项目经理的价值，进度由开发经理跟进，需求和风险由甲方管控，那确实和项目经理没多大关系。

建议采取如下措施，提升项目经理在项目中的价值：

1、从需求端入手，与甲方详细沟通业务需求，最好有自己的认识，形成自己的系统需求，让甲方信服。

2、制定规范的沟通机制，利用周报及周例会等，充分了解项目进度及风险，并及时向甲方汇报。

3、逐步形成由项目经理统一对接甲方，掌握第一手信息。

项目经理的最终目标是完成项目，主导项目和体现自己在项目上的领导地位其实没有那么重要，只是一种确保项目按计划按要求完成的一种手段。

所以引导项目顺利完成交付，并保证符合公司项目管理要求，然后在项目交付过程中能得到提升，做到这个程度已经基本上算是完成项目经理的本职工作了。当然，如果你要追求个人形象，那么争取发言权还是很有必要的，但忌讳不懂装懂。

其实项目业务的掌握往往重于技术实现，这不是说技术不重要，而是在于用户更关注的是业务。所以掌握业务分析，确实可以从另外一个角度掌控项目。这只是一种工作切入方式，但我觉得最爽的事，掌握项目进度，看着就能把项目完美交付

从接触了各大行业领域的项目经验嗅觉，以及在项目组中担任了项目管理者（也就是项目经理）的角色经验来看，要做好一名项目管理者实在不容易，如果说要求再严苛点的话，要评上优秀标签，那么想要覆盖所需的能力点就是一种挑战。

在之前没接触项目管理之前，一直有个误区，那就是项目管理可能不需要太多的专业技术能力，懂点行政管理，有点领导力就可以轻轻松松，把一个团队管理地有模有样，把团队里的每个人管得服服帖帖。

后面转向项目管理这块，做个几个项目之后，越发觉得之前的想法设想就是天真得不行，以至于在很多时候项目管理实践上踩过很多“坑”，有过许多地无可奈何，均由于在当时缺乏项目管理者所需的能力，以至于项目管理得连自己都觉得狼狈。

这么说来，要做好一名IT项目管理者究竟需要拥有什么能力呢？在经历过我踩过一些项目管理上的“坑”以及吃过不少的苦头的反思总结下，我觉得需要具备以下的几种能力。

其实不管是哪一行业也好，特别是在IT领域，比如像我是从事IT领域的信息安全方向，在我看来，信息安全技术的能力就是自身能力框架的基石，就像你要盖成摩天大楼，就必须根基牢固，这样的话任何风雨飘摇都无法轻易撼动你，因为会由于基础的夯实而坚挺。

所以基础的能力是取决后面发展的长远，否则“跨越式”的跃进可能会忽略基础成长的机会，造成日后基础松垮，限制了向上堆积的能力。

还有如果你想你的项目团队成员都能心甘情愿听从你的领导和安排的话，你就得有一个让他们“服”你的前提，团队成员他们擅长的是实施的业务能力和专业技术，如果你的专业技术或者业务能力无法优异与他们，那他们又有什么理由一定要服你呢？

这一点其实在项目管理中体现地尤为常见。一位基层员工，由于某些管理的能力特质，被领导赏识，进而提拔为IT项目主管。但是当时被提拔为项目主管时，他的技术能力相对一般，但却面临着要去领导一群大部分技术能力比他好的技术工程师。

一开始他觉得很正常，也没什么压力挑战，因为他自己误以为做好一名管理者，不需要很强的技术能力，因为只需要有好的领导力就可以做好管理了。

后面等到项目实施时，他才发现其实如果本身技专业技术能力不过硬的话，比团队内的人还弱的话，就会面临一种管理的“痛苦”在里面，那他们会有一种心理想法那就是：我根本不会管你管理有多厉害，你的技术都没我厉害牛逼，我凭什么要听你的。

也许，你可能会很无奈：为什么我是作为一个管理者的角色，为什么非用跟你比技术能力呢？但是你也怪不了人家，因为在IT领域里搞技术实施的，人家认的就是第一基础能力，你要我听你的话，可以，只要你技术比我厉害我就承认你。

所以在IT项目管理中，管理能力的基础就是技术能力，技术的晋升拓展就是管理，这种主次之间的逻辑认定，你如果逆反执行，你就会遭遇举步维艰的困境。

其实这种能力在古代军营中的元帅与军将士兵之间的能力差别中体现到很到位。比如大唐薛仁贵，起初作为一个不起眼的火头军，如果没有身怀十八般武艺的能力和过人的胆识，怎么可能屡建丰功伟绩，最后晋升为元帅；在晋升为元帅这种“军营一哥”的角色之后，他同样是一个大的管理者角色，手底下均是武艺高强的武将下属（罗通、秦汉等），从他的武艺在历史电视剧里面的表现来看，更是超越了众人，所以同事及下属没有几个不钦佩赏识以及服从他的。

这也皆因有很大部分是因为极为出色的专业实力在推动了自身的管理，为管理顺水推舟，使得管理的可执行性有了一定的保障性。

估计很多的人都因缺乏良好的沟通表达能力而吃过亏。在论文答辩时，你做出来的论文水平比你的竞争者要高，但人家却因为沟通表达比你好，而得了高分；在求职面试时， 你的专业技术水平比你的竞争者强，但人家却因为回答表现比你好，而被录用了；在项目实施中， 你的其他综合能力都很全面，但如果没有良好的沟通协商能力，那么你的需求永远得不到满足。

所以说，要想成为管理的主导者，你必须学会如何去更好地沟通表达。一个人想做一件事情，这就是他内心的一个真实的需求，但是需求需要实现或者说被满足，它就必须被表达出来，那么如何更好将需求通过语言形式传递表现出来，这就是沟通表达。合适恰当的传递表现形式，就好比优秀良好的沟通表达，更直抵对方的内心，更容易让人听懂接收，以至于让对方去接受并响应你的需求。

在IT项目的实施管理更为重要，对于团队内部，有一件事情需要大家一起来协作共同完成的，这个时候，如果你没有把需求很好地表达出来的话，会有几种情况：第一，你根本表达不清楚，比如没说清这部分的功能要谁去实现，输出报告要谁去整理；人家就不会理解你的需求是什么；第二种是你既说明了事件是什么（事项）、为什么要去做（缘由背景）、谁去做（实施人员）、什么时间点要结果（Deadline）；到这里的话你的需求表达算比较明确了，但还不是最优。

沟通表达的效果差异，在于表达之后，需求如愿实现的差异。什么是好的表达？我觉得就是你把要表达的需求和东西说出来之后，人家不仅仅听懂了，而且按照你的需求反馈了最为积极正确的回应。接着上面的例子，为什么还不算是最优的表达，因为其实还缺少表达一个比较重要的点，那就是目标预期，因为有些时候你把目标预期定出来，对方就会更接近你的真实需求导向输出结果。

但如果没有说出目标预期的话，就有会像是大领导总有天马行空的空洞设想，底下的人听不到目标预期的界限，也许只能无奈地自由发挥，跟着天马行空，实施落地就是痴人说梦。

在将领导的目标预期落地执行方面的话，Google现任CEO皮查伊做得简直太好，这也是他的大boss——拉里·佩奇（Google创始人之一）为什么那么赏识他，最后愿意当一个“甩手掌柜”的原因之一。

因为拉里·佩奇是个不善言辞又喜欢脑洞大开的主，在开高管会议时，总是喜欢说些天马行空的概念，可能由于太过于宏观， 导致高管们一头雾水，不知所云。

但是皮查伊却懂得去主动与老板交谈，简短几分钟便能抓住老板的目标预期是什么，并准确无误地传达给团队成员，以至于可实现落地。

这就是高效沟通表达的艺术，巧妙的沟通不在于冗长而在于精准简洁。

然后对于项目团队外，也就是面对客户或者其他跨部门的沟通的话，除了会沟通，还要懂得协商。不懂得协商的话，自己就会身处被动，客户的配合主动性就会很低，项目开展实施，就难免会陷入“对方都是大爷，我一切都听大爷的安排”的低段位服务姿态。

一般客户方（甲方），服务方（乙方）项目开展合作形式就是：客户方配合服务方开展工作，很多时候会遵循一条原则：“你们主动做事，你们就应该主导，我们只是配合方”，所以谁做事，谁就要去占据做事主导权，因为配合方往往是不着急的。所以在这个时候，当我们是服务方时，我们去把握主动是正确合理的，因为你想把良好的结果导向自己这边的话，主动跟他们说需要怎么配合要比自己不知所措，等着问他们怎么配合；要是后者这种情况的话，会产生两种结果。

第一种，客户方会不满。“事情主要是你们来做，我们是配合的，你们自己都不知道怎么做，那我们怎么知道配合你们呢？”  也许你心里会说自己其实是知道怎么做的，只是咨询下你们的意见而已。但其实，只有当对方把自己代入配合角色， 就会自然而然喜欢别人来引导，而不是来反问他们。

第二种，客户方逆转局势，你陷入被动。当你同样不计划主动告诉对方怎么去做，而去问客户怎么开展工作的时候，而刚好遇到的是不厌其烦且很有想法的客户，那你可能就就要无奈地开启“苦逼模式”。

踏入“不能做主”的泥沼，什么事情，怎么去做，都要听人家的想法来做，自己就失去把握的主动权，这样的话，可能会把自己拉入一个一个隐形的“大坑”，到时候要么你就只能“入坑”或者放弃脱离。

所以，面对近乎苛刻的要求和选择时，必须懂得从自身立场出发，通过与对方的协商，将结果主动导向自身有力的一面，而不是任由使唤，被动去接受本不应该接受的诸般要求。

《驱动力》里面讲到：“企业管理最让人头疼的问题是什么？员工的主动性和创造性。”   其实大到企业管理层面，这是个问题，小到基层项目实施， 驱动力简直关系到每个项目成员能否发挥最大的积极性来推动整个项目的实施，这是个根本性的关键问题；同时，这也决定了项目管理者是否是一名激励人心的驱动者。

也许普遍项目管理者会认为：调动成员积极去帮项目做事情，不外乎就是在多点付出而获得成效后，通过多分几张钞票或者说几番激励赞美的话，这两种方式就可以解决了吗？ 这只是通常的驱动力激励手段，应该是属于“治标不治本”的方法，即使这两种在一定的程度驱动了他们的积极，而无法深层通过在项目过程中，激励出他们应该有的“成就感” ，那只是一种短暂的驱动，时间一久就会疲乏，驱动就会变得迟缓。

所以管理者在通过物质需求和言语激励的方式之外，还应该懂得将员工的“成就感”当成创造力和执行力的源泉，并费些心思，将驱动力的力量从自身散发出来，感染到每个人，使得获得成就感，而成为自愿自觉去创造的“个体”。

在我看来有几个成长点是管理者具备后才能修成驱动力的，第一是自身的人格魅力，第二是本身的强大执行力，最后是拥有思考驱动力的思想。

管理者每时每刻都在产生决策，如果在决策时，无法赶跑“犹豫不决”这只怪物，那么你只能被吞噬。

对于决策迟疑，缺乏决断力，我深深吃过它的亏。有一次，一个比较重要的项目实施开展到重要里程碑阶段，只要完成这个里程碑阶段的工作，就可以进入项目验收阶段了。但是在完成里程碑阶段工作之前， 存在一个比较头疼棘手的问题。

那就是有个项目组核心成员，在那个时间点刚好赶上他自己另外负责的项目有项紧急的事情需要他去处理。但因为当时部门项目的现状是几乎大部分数人手里自己都带有项目，也就是自己既是项目经理，又要做项目实施人员，可谓是光杆司令；不但如此，在自己项目空窗期，还要“接济”帮忙下其他同事的项目。

刚好，那个核心项目成员他自己身上也是刚好有几个项目在跟的，只是当时我手上这个项目刚好在做，需要人手。在那个时候，我刚好是关键节点比较赶，而他那边又着急需要安排处理他自己的事情，我面临要去做出选择决策：究竟是让他去处理自己的项目，还是让领导去另外安排协调同事去处理呢？

如果他去，我这边项目搁置，不好交代；但是他那边不处理，我绑着人家好像又有点不合理，安排其他的同事又可能搞不定。不过领导是有提到一点：那就是我这个项目的重要程度会比较高，其他的项目可以灵活安排。

领导虽然没有说得很明白，但是也很明显传递给了我一个信息，那就是目前你负责的项目的优先级是比较高的，在遇到与其他优先级低的项目事项冲突时，必须做出合适的判断，优先执行优先级高的事项，其他事项通过外部资源协调解决处理。

但我当时还是缺乏全局观的意识，在遇到这样一个急需立马做出决策判断的时刻，陷入的却是迟疑和犹豫不决，前面的领悟总结只是事后“马后炮”才正确意识到的。

我还是在“浪费性的思考”后，做出了错误的决策，“老好人”般地放了那位同事去处理自己的棘手事去了。之后我被领导狠狠地批了一顿，因为我失了轻重， 项目里程碑阶段工作拖了进度“后腿”，结果耽误了项目的正常验收。

这是典型缺乏决策力的表现，作为一名项目管理者，在遇到关键决策时，综合评判出各个选择的优先级和重要程度后，就应该强有力地去执行重要程度高及优先级大的事项，摒弃“完美周全”的理想想法，因为现实总是难以做到百分百的兼顾所有；因为有些其他选择可以选择移交转移，让别人来帮你实现。

自己都想揽在身上，自己解决，那只会让自己陷入困顿、犹豫，最后所有的事情都成了“耽误综合体”，决策成为痛点；而当拥有睿智的决断力时，事情可能就会因为精准理智的快速处理而变得高效，进而推到整体事态的进展，映射到项目上的话，那就相当于项目进展会因为管理者的强有力坚定的决策，而衍生影响全局的强大执行力，促进了项目完成里程碑式的跨越。

所以，当一名IT项目管理者拥有了非常扎实的专业技术能力、出色的沟通表达能力、优秀的协商能力、振奋人心的驱动力以及睿智强大的决策力，这些必需的一项项能力后，在项目管理领域，那便意味有了开辟属于自己疆场领域的绝对资本以及自信。

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

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

2选择和招募正确的人

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

3为人员分配合适的工作

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

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

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

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

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

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

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

7冲突是不可避免的

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

在项目管理中，需求是为了成功完成项目而必须完成的一组任务或条件。它包括产品功能、行为、服务甚至是流程。这些需求的目的是确保资源和公司的长期目标在项目结束时保持一致。

一般情况下，需求可以分为以下几类：

业务需求：指业务的总体需求，旨在实现项目。属于这一类的需求是更基本的、与组织的长期目标相一致的长期需求。

解决方案需求：更多以产品为中心，并深入研究。它们可以是功能性的，也可以是非功能性的，确保产品的最终结果既满足产品需要做的事，也满足产品应该做的事。

利害关系人需求：描述了关键人员，他们在里程碑上签字，完成工作，最终确定可交付成果等等。有时他们可以是客户、团队成员、业务伙伴或关键领导。它需要一个坚韧的项目经理来确保所有利害关系人的需求在整个项目中得到很好的平衡。这对于良好的利害关系人管理必不可少。

你也可以定义适合项目的需求类别。

8Manage PM提供了一个用于项目需求管理的平台。系统自动侦查需求的变化，并把需求变化与项目的各个阶段关联，以此提醒用户，让用户更好地了解需求变化所带来的影响。系统也能自动追踪需求依赖及间接变化，让用户尽早了解其潜在影响。

该企业级工具拥有在整个项目过程中准确捕获和传达需求、目标、进度和相互依存关系的能力。团队可以使用该系统来缩短周期时间，提高质量，减少返工并最大程度地减少证明合规性的工作。

无效的需求管理流程，或更常见的是不采用任何需求流程，已被确定为项目失败的主要原因。从项目生命周期开始就实施的需求流程的投资最终会得到回报。

长沙理工大学IT项目管理硕士研究生专业是计算机与通信工程学院下设的在职研究生专业，计算机与通信工程学院现有“计算机科学与技术”、“通信工程”、“网络工程”、“软件工程”四个专业。拥有“计算机应用技术”、“计算机软件与理论”、“通信与信息系统”、“计算机技术(工程硕士)”四个硕士点、1省级重点专业、1个省级特色专业、1个省级优秀实习基地、4个工程研究中心。长沙理工大学IT项目管理硕士研究生专业简介如下：

IT项目管理是项目管理在职研究生领域的一个重要分支，近年来更超越传统的工程建筑项目管理，成为项目管理应用的一个重要领域。IT项目管理具有通用项目管理的特性，如也需要管理项目的进度、质量、成本，但IT项目管理也有其强烈的独特性，尤其是软件项目管理，与软件开发模型、软件工程技术(如需求分析、设计与开发、测试、版本与发布)有极为紧密的关系。

IT项目管理是为了满足IT领域项目管理的需要，针对 IT 项目决策、需求分析、可行性分析、咨询、评价实施的管理。为培养从事IT项目管理理论与方法，能在 IT 领域和信息化建设等领域从事项目管理、决策、咨询、评价的复合型高级工程技术人才。我校在IT项目管理领域拥有一支治学严谨、教学和学术水平较高的基本符合博士化、工程化、国际化要求的导师队伍，形成了多个以中青年学术带头人和学术骨干为主体的学术梯队，在计算机系统集成技术、IT项目风险控制技术、企业ERP管理技术和IT项目评估与决策方面具有较强的研究实力，学科与较多单位建立了良好校企合作关系;与交通、电力、水利等行业广泛开展信息化项目的合作开发研究。

一、培养目标

二、主要研究方向

IT项目管理。

三、培养方式和学习年限

实行双导师负责制。双导师制是指1个校内学术导师，1个校外社会实践部门的导师，以校内导师指导为主，校外导师参与指导工作。校内导师主要负责研究生的业务指导和思想政治教育，校外实践部门导师参与实践过程、项目研究、课程与论文等多个环节的指导工作。

学习年限为2年。

考研政策不清晰？同等学力在职申硕有困惑？院校专业不好选？点击底部官网，有专业老师为你答疑解惑，211/985名校研究生硕士/博士开放网申报名中：>

以上就是关于IT项目质量管理技巧应用的注意事项全部的内容，包括:IT项目质量管理技巧应用的注意事项、IT 项目管理 系统 描述、IT行业：不懂技术，怎么做好项目管理等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！