IT项目质量管理技巧应用的注意事项

距离上一次写文章应该一年半有余，由于工作的繁忙，加上家庭、生活的琐事，一直没有太多的精力持续更新，经过这么长时间的总结和积累，也有一些心得可以分享。

项目管理的本质是管理人和协调资源，首先要明确项目的目标、价值。当然目标和价值往往不是那么很精确地能掌握或者达成一致。

举个例子，互联网公司和传统的IT公司，非IT公司的技术团队，对于项目的目标和价值往往是不同或者侧重点不同。很多时候我们讲，软件要以客户为中心，但是以客户为中心在实施过程中却不尽如人意。互联网公司更加贴近用户，而一些非IT公司的技术部门，往往IT项目的最终目标一方面是为了满足业务的需求，另一方面可能也是为了满足领导的需求。因此，不同类型公司，对于项目管理的定位不一定是通用的。

通常情况下，项目经理在项目前期准备的工作包括对于项目组织架构的制定，项目干系人的圈定。但是在一些组织架构并非十分明确的公司，可能项目经理还需要承担前期的商务沟通，内部流程的协调跟进等等。

识别出项目干系人之后，通常在项目启动会上各团队的主要负责人都要参加，明确项目涉及各个团队的边界以及需要配合的工作，各个团队之间往往存在依赖关系，需要明确阶段性的里程碑节点。

项目计划尽量不要在项目启动会上，因为项目启动会之前如果没有充分的团队沟通，有可能会造成边界不清晰或者评估不充分。项目经理的角色就是要协调各团队，用最少的资源达到最佳的项目交付水平。因此项目计划尽可能在线下各个团队充分评估汇总后，在后续的会议中将项目计划明确出来，同时各个团队的负责人和成员应当尽量参与，目标和进度达成一致。

不同的公司，需求讨论和分析的维度不同，产品经理的角色不一定都具备。对于面向客户和面向内部使用的产品，往往内部使用的产品场景相对较少，要求也相对较低，有的团队简单粗暴画几个流程就开始下一步。但是我认为每一个软件产品都应该做竞品分析，以做产品的思维模式去开展，一方面便于以后的扩展，另一方面让团队成员也能学到更多的东西。

技术出身的项目经理与非技术出身的项目经理在项目实施与监控上会存在很大的差异。 技术出身的项目经理往往会从系统和技术角度把控项目进度，比如安全性、扩展性 ，而非技术出身的项目经理更多的是依赖于成员的日报、周报，很难在技术维度有更加精细的监控。

复盘在业界有一套标准的方法论，但是并不一定严格按照标准去做。每一个小的里程碑或者迭代都可以做复盘，总结经验，优秀的东西发扬，有教训的东西尽量避免，而不是讲复盘作为一种事后批判的手段。

2021年5月28日，某会议中提到 “各类应景性、应酬性活动少一点科技人员参加，不会带来什么损失！决不能让科技人员把大量时间花在一些无谓的迎来送往活动上，花在不必要的评审评价活动上，花在形式主义、官僚主义的种种活动上” 。

IT人员管理应当以技术、能力为先导，当前社会，IT从业人员很多，但是人才往往是少数，尊重人才，善用人才，“专业的人做专业的事“一直以来是我对IT人员管理的原则 。

很多时候，IT项目建设过程中，脱离不了领导的主观判断，尤其对于中小规模的企业，往往即便有产品经理的角色，也不能发挥其应有的岗位能力。因此，项目管理人员应该根据团队内不同人的专业技能，充分给大家发言权、发挥权，让专业的人发挥自己更大的价值。

IT项目管理最大的一个复杂性就是人员的管理，项目管理的过程和规范固然重要，但不能因为过程和规范抹杀和项目成员的能动性和创造力，一定要肯定项目成员对项目成败的重要价值。

一个优秀的项目经理，一定是能让团队成员信服，与团队成员共同成长进步的。每个人不管职位的高低，都是企业的打工者，打工者的核心诉求无非是赚钱养家糊口，实现自我价值。因此，每个成员希望的是能从领导者身上学到东西，并且相处融洽，在项目的实施过程中增长技能。就像生养孩子一样，项目经理和团队成员应当是彼此默契配合，共同成长持续进步的一种状态。

经历过不同的企业，不同的团队，不同的组织架构，我认为一个团队的稳定很大程度强依赖于管理者。项目管理很重要的一点在于人员的管理，但是此处的管理不是“把人管住”，而在于培养人。培养的过程中制定一些规范，但最终的目的应该是培养团队成员的技术能力、沟通能力、协调能力、业务能力，让团队成员随着项目的建设和投产，积累经验，收获成果，实现自我价值。

IT项目管理和人员管理是一门学问，没有统一的标准，不同的组织架构下，不同的管理者，最终呈现的结果差异很大。 但我认为，核心还是以人为本，尊重科技人员，尊重每个人的特长，让每一个岗位都能发挥自己的价值 。

IT企业多项目管理的实施难点与对策

导语：IT企业因其在经营过程中比一般企业面临着更多的不确定性和环境的动态性，给多项目管理的实施带来更大的难度，现针对多项目管理的实施要点展开讨论。以下是我为大家精心整理的IT企业多项目管理的实施难点与对策，欢迎大家参考！

1、多项目管理理论回顾

多项目管理是站在企业层面对现行组织中所有的项目进行筛选、评估、计划、执行与控制的项目管理方式。它是在假定存在多个项目的前提下，如何协调和分配现有项目资源、获取最佳项目实施组合的管理过程。未来多项目管理发展趋势主要有：领域范畴不断扩展;未来项目与企业战略需求更加紧密相连;多学科知识的交融;多项目管理信息技术支撑平台的建立。对IT企业来说，多个项目的实施和良好的多项目管理可以降低项目成本，优化企业资源配置，从而提高企业的利润率。

2、多项目管理实施的难点

IT企业在应对单个客户需求时，可能具有较好的d性及其应变优势，企业领导者也可以对资源进行有效协调指挥，但当项目增加到一定程度时，势必又要增加管理层次来保证有效的领导，这就与其精干、扁平化的组织结构相违背。另外IT项目还涉及信息系统应用单位的组织、管理的调整与经营过程、业务流程的重构，单靠信息技术是无能为力的，这些促使企业之间的依存关系日渐加强，往往需要根据企业的环境变化进行适应性调整或重新安排。

3、多项目管理实施对策

当面临多项目并行管理的时候，我们不可能象管理一个项目一样进行从头盯到尾，并且关注其中出现的任何问题，这从精力上来说是不现实的，而且如果你确实企图如此做，唯一的结果就是把自己弄得很忙碌，而且会突然发现，你不断处于救火的过程中。那么基于此，应该如何进行管理呢(1)判断轻重缓急，确立优先次序;(2)建立多项目管理机制;(3)利用时间差，尽量避免资源争夺;(4)清楚各项目团队能力，适当授权解放自我;(5)建立信息共享机制;(6)建立良好的绩效考核机制。

4、多项目管理实施的难点

多项目管理的产生和需求原因来自多方面，既是企业内部环境转变的结果，也是企业外部因素所致。这些因素将集中表现在企业分工与组织的变化、开发技术的变化、技术和管理的创新等方面。这种方法要求从参与项目活动的所有人那里收集到工作绩效方面的反馈意见，包括职能经理、同事和下级甚至客户。一方面这在结构层次简单的IT企业中较易实现，另一方面能全面发现个人的长处和短处，为提高绩效水平制定行动计划。关于这方面的讨论读者可以参考相关书籍。

注意事项

总之，随着更多的IT企业参与到国际竞争当中，跨国界、跨文化的项目日渐增多，多项目管理体系将更加多样化、复杂化。针对多项目管理实施过程中的难点，各种各样的对策方法将在实践中得到检验。当然本文探讨的对象也可由IT企业扩大到一般企业，因而企业在吸取项目管理理论精华的同时，更应该结合企业自身特点，有选择、有步骤地将最新成果应用到实际项目当中去，这样才能不断获得项目管理带来的喜悦。

;

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

1、时间盒(Time boxing)

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

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

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

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

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

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

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

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

2、误期

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

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

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

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

3、忽视相关性

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

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

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

4、假装没有错误

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

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

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

项目开发方面

项目应以需求为核心。一个项目是否能够成功，对需求的准确把握在成功因素中要占上60%的比例。不管系统的架构设计、团队管理有多么的成功，如果需求出现偏差，仍然是南辕北辙。由于eas项目的特殊性，项目开发过程中能够与客户建立有效快速的沟通渠道，是项目成功的关键。

需求必须获得客户的确认。通过需求调研与分析后获得的用户需求说明书，以及软件需求规格说明书都必须得到客户的签字确认。确认的内容包括项目的目标、范围以及项目需求功能点（用例）。eas项目在前期对需求不够重视，导致在需求理解上出现了一些偏差，从而影响了项目的进度。幸而得到了及时的纠正，在项目管理部的协助下，所有需求都得了客户或客户代表的签字确认。从而使得项目在客户验收时，有了充分的保证。

项目应确立专门的需求分析师。公司没有专门的需求分析师，不能不说是人员配备上的一大弊端。（软件开放工作细分的第一步就是要有专门的系统分析员或需求分析师）从eas项目的开发过程中，我们就充分地认识到这一问题的严重性。需求的不断更改，客户迟迟未签字确认，原因正是在于我们没有专门的具有丰富经验的需求分析师。普通开发人员在调研需求以及撰写需求规格说明书时，总是会出现偏差或理解错误的地方。软件需求分析是一项重要且负责的技术，没有经过专门训练的需求分析师，通常会给项目带来隐患。

项目应指定各个模块的需求接口人。只有这样，才能有效地保证项目组与客户的及时沟通，快速响应客户的请求与反馈。eas项目在开发早期及时地确立了需求接口人，在一定程度上规避了需求变更给项目带来的风险。但是，确立的需求接口人未经过系统培训，在需求调研以及与客户沟通的过程中，工作表现只能说是差强人意。

注意维护需求调研记录以及需求跟踪表。这一工作做得不够好。由于需求调研人不够专业，而项目经理以及需求分析负责人对这一过程还欠缺足够的重视，同时没有好的工具或流程来监控这一过程，使得需求调研记录没有发挥更大的作用。此外，需求跟踪也非常重要，毕竟，任何项目的需求都不是固定不变的，需求随时会发生变更，而开发人员实现的需求也可能会与客户的要求偏差。

注意维护需求矩阵。项目经理对这一内容缺乏足够的重视与理解，项目开发过程体系中也缺乏好的需求矩阵文档模板。但是在项目中后期，项目及时撰写了eas项目需求功能列表，并结合交付版本与客户进行了沟通和协商，从而规避了需求偏差的风险。(需求追踪，任何原始需求来有头就有尾。原始需求->用户需求->产品需求->软件需求->设计->测试等一系列的追踪。需求追踪的目的一方面是检查需求是否都已经实现有无遗漏，更多的是为了做变更影响分析使用)

控制需求变更。重视ccb的作用，同时应建立需求变更的响应机制。eas项目组对于需求变更的响应还不够及时，这一点项目经理与项目管理小组要担负一定的责任。（范围管理中范围控制的内容，变更管理是配置管理的一个重要内容。需求必须要受到控制，否则容易引起计划的频繁调整而发生混乱)

设计

重视架构设计。eas项目的成功，一定程度是源于我们有个优秀的框架开发小组，我们在项目立项之初就基本确定了整个系统的架构。其中虽然发生了一些变化，但核心架构仍然没有发生大的变化。由于，我们建立了稳定、简单的系统框架，可以极大地提高开发效率，规避了对框架的重复编码。(软件开发的第二个重要分工就是最好有专门的架构设计人员，架构设计和总体设计要由1-2个人来完成，以保证高度的概念完整性和设计统一)[1][2][3][4]

善于对设计作出取舍。项目开发的三要素是成本、质量与进度。在保证质量的前提下，为了项目进度不出现大的偏差，eas项目组并没有过分强调技术，特别是在考虑进度的情况下，牺牲了系统的部分可扩展性。虽然这为系统的后期维护带来一定隐患，但却能够有效地保证项目的进度。从eas最初的架构设计来看，我们引入了 castle与aop，试图简化orm以及横切关注点例如日志、异常、权限、事务等功能的实现。同时，希望采用wcf，利用soa思想建立松散耦合的面向服务应用程序。但随着客户需求的变化，我们果断地放弃了采用wcf的构想，同时又克服了技术困难，坚持了对castle与aop的使用，并为此成立了框架开发小组。事实证明，在技术的抉择上我们作出了正确的决定。

重视ui原型设计。系统的原型设计与需求分析相辅相成。如果有好的原型版本交付给客户，则客户更能够理解系统的实现，促进沟通的有效性与准确性。在eas项目中，我们从一开始就确立了原型设计小组，并在分析需求阶段，就开始了原型设计。这一做法无疑在客户沟通、需求确认、ui设计等方面都发挥了很大的作用。但是，我们在这一点上，由于缺乏专门的ui设计人员，因此，这一工作还存在很大的缺陷，甚至于ui的设计为迭代版本的交付带来了很大的障碍。在项目后期，关于ui的bug是最多。因此，我们认为在开发类似的web应用程序时，应尽早确立ui设计规范，以约束所有的ui设计。同时，必须培养专门的ui设计师，在开始原型设计时，就尽快完成ui交互的设计。并且，必须成立专门的ui 设计小组，在需求阶段与需求分析师合作，在编码阶段与开发人员合作。(原型设计是加强前期用户需求挖掘和减少后期需求变更的重要手段，不一定需要专门的ui设计人员，原型设计可以由需求分析师来完成)

测试

测试成员应了解需求。如果不了解需求，测试人员无法编写正确的测试用例，同时在测试过程中，也可能因为错误地理解需求，从而导致报告错误的bug，影响开发人员效率。加强开发人员与测试人员的合作。开发人员必须及时响应测试人员提交的bug。而测试人员也应跟踪开发人员对bug的修复情况。(测试人员应该要意识到自己和需求分析人员的区别，测试人员不用想需求分析人员一样分析和开发业务，但是他们必须和需求分析人员一样对已经分析出来的需求和业务高度熟悉)

测试之初必须确定测试原则，对bug的严重程度进行分级。同时，必须确定修复bug的优先级别。

进度管理

保证项目进度不出现大的偏差的前提是制定一个好的项目计划。必须根据项目规模，成员情况，技术难度等多方面考虑整个项目计划。如果项目的deadline已经确定，则必须采用一些方法来保障项目计划的完成。首先是选择符合项目的软件开发生命周期。通常情况下，并不建议采用瀑布开发方式。最佳的办法，应该是 rup或者敏捷开发，然后结合原型法制订项目计划。这样可以规避因为需求变更产生的风险。

其次，要每日跟踪项目的进展情况。可以通过晨会、周会以及项目日报、项目周报了解项目进展情况。同时，需要为各个小组指定进度跟踪人，根据各个小组长的日报，判断实际的进度是否与计划出现偏差。

要制定项目进度偏差的应对方法。一旦项目进度出现了偏差，必须采取相应错误解决问题。或者通过加班、增加人手、申请项目进度等方法及时作出响应。

及时向项目成员汇报项目进度情况。只有让各个项目成员了解到项目现状，才能够给每个成员增加压力，不至于松懈。同时，也能够使得每个成员能有一个目标，而不至于茫然失措。

制定项目计划时，必须考虑阶段评审与同行评审的时间。这一点在eas项目中做得不够好。其中原因也是由于项目进度本身较紧的缘故。注意维护项目进度跟踪表与项目进度偏差跟踪表。让项目管理部以及qa及时掌握项目进度，有利于对项目进度的管理。

变更管理

变更包括需求变更、人员变更。如果不控制好，两者对项目的进展都会带来灾难性的后果。需求变更在前面已经叙述，而eas项目中发现人员变更的情况也非常严重，因此这里重点介绍关于人员变更的管理。

如果发生人员进入的情况，那么对项目带来的通常都会是好的影响。但我们也必须注意如何让新成员更快地融入团队。整体上讲，如果需要新成员加入，发生变更的最佳时机是项目前期。如果在项目中后期加入新成员，无疑则意味着项目出现了灾难性的后果。而新增加的成员，由于不熟悉项目，所能带来好的影响也是有限的。如果不处理好新成员与老成员之间的合作关系，反而会带来负面影响。

人员的退出很多时候是不可控的，同时对项目带来的影响也是不可估计的。为了将这些影响降到最低，就必须在项目开始之初就要确立编码规范。同时，还应该重视对文档的维护与更新。而在人员退出时，必须做好交接工作。同时，还应对这种变更进行合理的评估，并及时报告项目管理部，并与客户及时沟通。如果对项目进度有严重影响，应争取最大的努力取得客户的理解，提出项目延期的申请。

风险管理

要在项目开始之初就考虑到项目过程中可能出现的所有风险，是不现实的。但是，我们必须考虑对风险的管理，尤其是在制订项目计划以及创建团队的时候，考虑这一因素。风险有很多，包括需求的风险、进度的风险、质量的风险以及技术风险等。必须制定一套完整的风险管理计划，而一旦发生了风险，则必须及时响应，组织相关人员解决风险。不能忽略任何一个小的风险，否则一个小的风险到最后会造成大的灾难。风险的把握必须要有项目经理与系统架构师把关。

成员管理

不团结的项目组是无法保证项目的成功地。项目经理与项目组长在管理团队成员时，必须时刻注意成员状况，即使处理工作出现的矛盾与摩擦，随时保证团队合作精神得到最大程度的执行。

持续地保证项目成员的士气非常重要。项目每取得一个阶段性的进展，必须告知全体成员，如此才能收获成功的信心。项目开发过程需要注意劳逸结合。一味地强制性加班，只能降低项目成员的工作效率。项目过程中，如能适当地开展一些活动，无疑能够让团队成员感受到项目组的集体气氛。在阶段实现的重要时刻，项目经理必须注意通过文字、语言等激励项目组成员。而项目经理的自信也是保证成员士气的一个关键。

必须注意了解团队成员的心理状态与工作状态。项目成员的战斗力除了是个人的能力发挥之外，一个好的领导也是至关重要的。因此，必须选择合适的项目组长，通过他们掌握整个项目团队成员的工作进展。同时，还要了解每个成员的能力，以安排合适的角色与岗位。

重视开发组与测试组以及项目管理小组的合作。项目组是一个整体，每个成员的角色不同，但大家都是团队的重要一员。

作者:张逸具有多年的软件开发与设计经验，他是两届微软最有价值专家（mvp），著作/译作包括《软件设计精要与模式》、《wcf服务编程》。张逸熟悉c#，asp，wcf等技术，同时深谙面向对象领域的相关技术。目前，他主要从事 soa企业信息解决方案的设计与研究，以及敏捷方法的推广与实践。张逸是捷道·敏捷堂的创始人。

以上就是关于解读IT项目管理和人员管理全部的内容，包括:解读IT项目管理和人员管理、IT企业多项目管理的实施难点与对策、IT项目质量管理技巧应用的注意事项等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！