该如何应对IT实施项目中的问题

        需求来源可以来自市场、用户调研、运营、测试、开发、用户反馈、产品经理等等，平时工作过程中他们会经常向你提需求，在一定程度上会经常打断你的工作，正确的做法是明确收集需求周期，可以是半个月或者一个月进行一次汇总的需求收集。

        正常流程是周期性的去收集，但存在一种情况就是业务方从来不提需求，这时候你需要主动去跟业务方聊，去了解业务方的规划，参与对方业务规划中，这会让你对整个大产品有更高的认知，从而会挖更多掘潜在的需求。

        收到业务方的建议需要进行一个初步梳理，剔除一些无效的需求，将有效记录到需求池当中。如何剔除无效需求：需求方只会告诉你一个解决方案，需要你向需求方不断去问为什么，去了解背后真正需求，发现本质需求后看是否现有方案已经解决或者存在线下更优途径解决，如果可以就不用放到需求池中。

        过滤无效需求后，将剩下需求记录到需求管理工具中（管理工具可以是各种在线工具或者excel，我个人比较喜欢excel）。需求需要记录信息需要包含：需求、需求描述、目的与价值、需求来源、需求分类、需求标签。 需求分类分为需讨论需求、待开发功能。待讨论需求为不明确是不是需要做，不知道怎么做的需求。这类需求可以跟其他产品同事或与业务方一起讨论得到结论。待开发需求：需求比较明确，可以开发的需求。需求标签：根据产品规划划分几个业务域，每个业务域都有明确目标，然后将这些需求划分到业务域中。 这样有一个好处就是将零散的需求进行了归类，有了总的大目标，而不是单点需求了。拿在线教育前端业务为案例可以划分为如下：

        实际工作中的需求排期可能是产品自己的感觉进行排期，这非常的不科学。在互联网行业比较流行的一种方式是用kano模型去进行排优先级。

将需求划分为兴奋性需求，期望性需求，基本需求。优先解决：基本需求>期望性需求>兴奋性需求。具体某个功能是属于哪个类型，网上有很多关于kano模型的介绍，在知乎上的一个马大乐的文章供大家参考 ： 卡诺KANO模型-功能优先级排序模型   。

具体排期：个人的做法是满足优先级高的需求为主，但中间也需要适当插入部分稍低优先级需求，不然兴奋性需求可能永远排不上了。

下面主要针对需求开发及需求管理两个方面对需求进行分析。1 需求开发，从目前我们的实际工作情况来看按顺序主要分成如下几个部分：· 请教行业专家行业客户对信息化的需求越来越细化，对专业性以及行业能力的全面性要求越来越高，惟有深入行业，洞察其需求，研发出更适合客户需求的产品，才能成功。因此有必要先请这方面的行业专家对于客户的业务需求进行从流程上的梳理。为什么请行业专家，而不是直接请客户进行交谈，得到其实需求，个人认为主要是因为目前各政府部门、企事业单位对于信息化与业需求的整合这一块缺少经验，大部分情况还不能完全整理出完善、清晰的系统需求来。只有通过行业专家对其实业务流程进行梳理，一方面更容易与客户产生共鸣，另一方面也可以大大减少因为知识方面的差异导致错识需求的产生。· 和客户交谈你要面对正确的客户区分不同层次的客户需求，要面对不同层级，不同部门的客户，把客户分类，区分需求的优先级别。如果你做的项目业务是你熟悉的，那还好，如果是你不熟悉的，一定要花点精力学习一下这个行业业务的背景资料，这也是我上面谈到的先请行业专家的原因。毕竟，客户是不可能给你系统地介绍业务的。只有你通晓了行业业务，才能和用户交流，并正确而有效地引导客户，做好需求分析，你不能指望客户能明确地说出需求。当然，这也是系统分析人员的职责所在。在开始做需求的时候，你最后花一点时间搞清楚你接触的客户是不是做实际业务的客户，如果你面对的客户不是将来的系统的实际使用者。你就有点麻烦了。可能他是客户公司派过来的IT部的人，他会提一大堆东西，而这些东西可能根本不是实际业务需要的功能，而他一般还会兴致勃勃地给你一些技术实现的建议。这个时候你就要小心了，如果你听了他的话，你可能在最后才发现，你花了大量精力解决的问题，其实并不是客户真正需要的。而你真正需要关注的，却做得远远不够。· 参考其他类似软件和系统在经过与客户的沟通，并形成初步的需求之后，不要急成正式的需求，请先参考一下以前的一些系统，去理解一下了解到的需求与原先系统的差异，并去发现是否有些需求会产生错识需求。· 业务建模为需求建立模型，需求的图形分析模型是软件需求规格说明极好的补充说明。它们能提供不同的信息与关系以有助于找到不正确的、不一致的、遗漏的和冗余的需求。这样的模型包括数据流图、实体关系图、状态变换图、对话框图、对象类及交互作用图。· 需求整理并形成需求规格说明书需求规格说明书的模板我想每家公司都是不一样的，也没有必要都一样，但我认为每个需求规格说明书至少应包括软件需求一旦通过了评审，就应该基线化，纳入配置管理库。而在配置管理库中的文档或代码不能再轻易进行修改。当有需求要进行变更的时候，就必须提出申请，写需求变更计划，审核通过，才有权限进行需求变更。然后配置管理员一定要做好需求的跟踪。，凡是跟变更需求有牵连的开发人员和测试人员都要同步的通知到和及时让他们做好相应部分的各类文档的修改。· 需求变更管理需求的变更管理我个人认为是最容易出问题，一般项目做不完也主要是由此产生。需求变更的出现主要是因为在项目的需求确定阶段，用户往往不能确切地定义自己需要什么。用户常常以为自己清楚，但实际上他们提出的需求只是依据当前的工作所需，而采用的新设备、新技术通常会改变他们的工作方式；或者要开发的系统对用户来说也是个未知数，他们以前没有过相关的使用经验。随着开发工作的不断进展，系统开始展现功能的雏形，用户对系统的了解也逐步深入。于是，他们可能会想到各种新的功能和特色，或对以前提出的要求进行改动。他们了解得越多，新的要求也就越多，需求变更因此不可避免地一次又一次出现。如何有效的管理需求变更，下面是我公司目前的做法。公司采用Test Director作为需求管理工具，需求人员每次与客户沟通后形成需求调查表，统一录入Test Director，并进行综合及整理后形成需求规格说明书， 之后由研发部、产品部、及销售代表（如果有客户参加就更好了）进行需求评审，建立需求基线。制订简单、有效的变更控制流程，并形成文档。在建立了需求基线后提出的所有变更都必须遵循变更控制流程进行控制，同时每一笔重要的需求变更都需要客户签字确认才认为需求变更生效。需求变更后，受影响的软件计划、产品、活动都要进行相应的变更，以保持和更新的需求一致。

以我多年参与、主导IT实施/开发项目的经验，我觉得项目实施过程中没有任何问题几乎是不可能的事儿，因此出现问题本身没什么值得大惊小怪的，而如何对待问题、如何处理问题却是一个最值得关注的问题。这就是我所信奉的“问题本身不是问题，对待问题的态度是个大问题”。1、合同签署前要充分了解未来客户方项目负责人的实施方法论有些客户自己不懂该如何实施项目，也谈不上方法论，那么项目过程中可能要以实施人员引导、制订实施方案及项目计划并且征得客户方关键干系人的认可。如果客户自己在实施方面就有自己成熟的一套想法，而且客户反复在沟通过程中强调自己对于项目的要求，那么前期负责和客户接洽的人员就必须对这些信息敏感并且尝试着挖掘一下，客户可能对实施有哪些要求，我们自己是否熟悉这套东西，应该提早准备哪些应对措施。前期与客户接洽的人员切不可不加思索地就来一句“肯定没有问题。。。”之类的承诺。2、要多琢磨客户在项目过程中反复强调的东西一个成熟的客户会在项目启动早期把一些他特别在意的东西反复强调，这些东西很有可能就是客户所预见的项目风险或者项目的方向。实施方项目组成员一定要仔细琢磨客户的意图，琢磨不清楚就多找客户沟通、多提问题以帮助自己理解他的意图。倾听和提问是一个实施顾问特别应该具备的一个素质。3、出了问题要及时回应是人都害怕不确定的东西，客户也一样。如果出了问题，实施方项目组成员或高层没有及时回应对于客户来说是一个非常大为光火的事情。这就跟我们到商场买东西发现所购买商品存在某些问题或者某些疑问时向导购人员提出来，导购人员置之不理是同类的问题。及时做出反应不是要求马上拿出解决方案，而是让客户知道我们已经在采取措施，并且明确给出客户提出解决方案的时间。尤其是获悉相关信息的公司高层更应该及时响应，一个理性的客户肯定不会把芝麻小事也让实施方高层知道，既然知会了高层想必会有客户的道理，比如问题升级了或者遇到了严重的问题。4、针对问题的解决方案切忌含糊、托辞作为客户，项目出现了问题还心情超好的可能性不大。所以，实施方在针对问题给出解决方案一定要慎重：首先仔细分析问题是否真正存在，是否超出了项目的范围，如果存在也不超出范围那么问题的根源可能是什么，现实情况下能否有解决方案，解决方案所需要耗费的成本是否可以承受（是否存在客户承担部分成本的可能？），是否会给客户方带来任何风险，解决方案估计什么时间可以完成等等都需要经过内部专家团队反复推敲、论证、模拟。然后把有完整分析、明确解决方案、完成时间及接口人的信息发给客户，征求客户意见。如果有些东西超出项目范围或者超出实施方的能力，那么也建议诚恳地和客户沟通，看如何通过其他方式来弥补因为这些问题存在所造成的遗憾。提供解决方案时有五个大忌：1)、忌含糊其辞，没有多少人喜欢这些看不明白的东西，可千万别在客户的坏心情上面火上加油；3)、忌没有解决问题的时间表；4)、忌为自己方辩护；5)、忌信口开河似的承诺5、出现问题后要及时展开沟通，丰富沟通的渠道和层次上面谈到了及时回应，算是及时沟通的一种，但还不全面，那只能在问题出现以后稍稍缓和客户的情绪。在提出解决方案、和客户确认以及方案实施的过程中，建议实施方负责人要在自己公司内部(尤其与高层之间)、以及客户方项目干系人之间及时、定期展开沟通。如果问题的确比较严重，对项目有较大影响，项目负责人还应该考虑丰富沟通渠道、提高双方沟通的层次，以便于可以有效地把处理的进度、遇到的问题传递给双方项目组、管理层，及时调动优质资源配合问题的及时管控、处理。我觉得做到了以上五点，再配合以专业技术层面的努力，大部分客户应该都会满意，而不至于项目合作双方的不愉快从此成为项目的一个噩梦烦扰着彼此。其实我们不需要也无法苛求彻头彻尾的专业，但我们一定要有一个专业的态度和精神，这是我看待项目合作的一个基本态度。

IT资产管理和传统的资产管理从逻辑上是一样的，但是IT资产和传统的企业资产管理最重要的区别是它的实时性。所以在管理方式上可以采用非常先进的技术，而且这些变化可以自动触发。企业的资产管理通常是由财务部门管理的，而业务需求决定了IT资产管理必须由IT部门进行管理。两者的着眼点是不同的，造成许多管理上问题，通过实施IT资产管理，可以降低开支，提高IT生产率和服务水平，同时能降低风险，提高IT透明度。

随着政府信息化和电子政务建设，政府部门的IT资产管理已经显得非常重要，管好和用好原用的设备和软件，提高IT管理人员的工作效率，做好库存管理、节省能源，是决定政府采购多少新IT设备等的依据。

金融行业对信息化系统的安全和稳定性要求很高，需要对所有信息化资产的型号、控制面板、连接及运行情况等进行全面的监控，实现IT资产的自动化、科学化管理，让IT资产创造最大使用价值。

电信行业是高技术含量的行业，由于电信IT资产的“巨大”，因此，精确的资产知识和问责制对于确保优化IT支出至关重要。需要了解有哪些资产、资产现在在哪里、如何使用它、以及如不再使用这一资产，如何从账目中勾销以健全成本控制等这些是非常必要的。与这些成本相关的是软件许可和续订，如果系统已被整合或已部署虚拟化技术，那么软件许可证也应该合并，提供另一种成本节约。

如何做好IT资产管理，是摆在信息主管CIO面前必须要解决的难题。IT资产管理跨越政府或企业的若干个部门，需要政府或企业高层领导的支持，无论是资金、还是高素质的工作人员、以及相关部门之间的协调等，都需要花费CIO大量的时间和精力。通过大量的实践摸索和调研讨论，提出政府或企业IT资产管理解决方案，该方案能够全面、实时收集到政府或企业IT设备的数据，而且能够提供多种形式的报告，确保领导和IT管理人员能够从不同的角度了解资产状况，及时响应上级和其他部门各种各样的报告要求，实现资产管理流程自动化，有效提高控制和投资回报，同时确保法规遵从。

IT资产管理是从资产生命周期管理来实施的，包括现有的网络设备、服务器、PC机、笔记本和打印机等，IT设备的库存情况，设备维修、借租、设备的折旧年限、报废等等；已经使用的正版软件，升级、维保等，摸清设备库存情况和软件的使用情况，在购买新设备和软件时，能更好地做出适当的决定，帮助政府或企业减少浪费。

因此，做好IT资产管理，我们首先必须要使用各种软件管理工具，随时掌握政府或企业目前使用的软硬件等情况，形成一个完整的IT资产库。IT资产管理工具可以帮助政府或企业从成本、合约、支持以及库存等多个角度，管理整个IT资产库。它为资产管理提供了强有力的技术平台，利用工具软件的信息获取功能，IT资产管理员可以清楚地知道，安装在服务器或客户端PC上的硬件信息、软件类型和版本，包括手动安装的软件。跟踪与用户名、部门、资产清单等有关的许可信息，依据用户的信息进行管理。

其次“管理＋IT”：实现IT资产管理变革，政府或企业IT管理部门可以“总体规划，结合流程，分步实施”，借助IT技术实现IT资产管理。对所有类型的IT资产进行跟踪。记录IT资产的需求、配置、调换、分级以及最终报废的历史情况，提供IT资产的生命周期管理，为成本管理提供完整的IT资产数据。

随着ITIL等最佳实践框架被广泛地运用到IT服务质量控制体系，资产管理已经成为支撑IT运营的一个关键组件。同时，IT架构的调整又给资产管理带来新一轮利好。在CMDB（配置管理数据库）IT管理新核心的地位得以确立后，资产管理与服务管理、配置管理、策略管理一起，成为紧紧包裹CMDB内核的关键模块。

目前看来，政府、电信、金融、教育等行业的IT服务管理应用较为广泛，其相应的解决方案、运维工具也最为成熟，成为国内标志性的IT服务管理成功行业。广通信达目前在政府、电信、金融等行业都投入了大量的精力，其主要客户也来自于这些行业。广通是通过做政府行业的IT运维服务起家的，因此在政府行业的成功经验也帮助广通在发展过程中赢得了更多的政府用户，同时广通也开始涉足电信、金融都高技术含量的领域，凭借广通BroadviewIT运维方案的深厚技术底蕴，不断开拓进取，赢得了电信、金融用户。

广通对于不同行业会制定不同的解决方案，选择产品和实施方案也会根据具体用户的需求和IT架构来进行，实现政府或企业的IT资产管理。根据资源管理核心需求，广通Broadview资产管理功能对设备资产、网络布线、组织结构、IP资源、设备上网和撒网等进行有效管控，管理人员可轻松提高日常运维的有序性。网络管理系统的资产管理功能，从设备的采购，入网，到维护直至最后的报废都有完整的记录过程，是全生命周期的IT资产管理，能充分保证IT投资的利用最大化。

广通自主研发的IT运维管理平台，以网络资源监控、资源管理、服务流程管理为三大业务方向的IT运维管理，将会为一如既往地服务好各行业用户，提供最佳的资源监控、服务管理实践，做国产IT运维管理的第一品牌。

什么是项目管理？

经过人们长期探索总结，项目管理在发达国家中已经逐步发展成为独立的学科体系，成为现代管理学的重要分支，并广泛应用于IT、金融、服务、航空航天以及工程等诸多行业。由于其诱人的高额年薪以及广泛的就业前景，项目管理目前已经成为超越MBA的最炙手可热的“黄金职业”。 项目管理无疑将会是未来二十年中最热门的行业。那么到底什么是项目管理？

项目管理的定义有很多，按照教科书的理解是：项目管理是在运作方式和管理思维模式上最大限度地利用了内外，去完成项目目标。项目管理包含很多层面：团队管理、风险管理、采购管理、流程管理、时间管理、成本管理和质量管理资源等。

笔者的理解是：项目管理，就是通过合理地组织，利用的一切可以利用的资源，按照计划的成本和计划的进度，完成一个计划的目标。在项目实施过程中，目标很可能会发生变更，那么成本和进度都需要做相应的调整。

项目主管如何解决问题？

按照白猫黑猫理论，评价项目管理是否成功的唯一标准就是项目是否保质保量按时完成。现在的项目实施一般都是主管负责制，项目主管重任在肩，要达到项目成功这一目标谈何容易。

在项目管理过程中，笔者就要经常思索以下问题：

如何在选择余地不多的情况下，组建一支得力的项目组？

项目组成员的挑选非常重要，假如在一个关键的岗位安排了一个不合适的人选，这个项目很可能会出师不利。当然在现有的人力资源中，不一定能顺利选到优秀的人才并组建成一只能战斗的队伍。笔者就碰到这种最恶劣的情况：项目组只有主管有经验，别的成员都是刚刚毕业的大学生，那么主管的任务就不仅仅是管理，而且需要花费大量时间精力来培养这些新手，让他们能尽快进入预定的角色。

如何界定项目成员工作的范围和定义他们之间的工作接口？

这个问题就是俗语说的"派活"。要把活分出去可不是一件简单的事情。项目主管首先需要对项目组成员非常了解和熟悉，知道他们的知识结构和能力水平；其次要对项目情况非常清楚，并能对项目实施过程进行划分和功能模块的细化，并结合每个人员的特点指派具体的任务；最后要重点注意的是，尽量让组员之间的工作接口简单和接口定义详尽，避免将来产生互相推诿和扯皮。

如何准确衡量项目成员的工作量？

做过主管的人都碰到过这种问题：分配给甲的工作，要求一周完成，但是一个月过去了，他还没干完；分给乙的工作，要求一周干完，但是他一天就干好了。实际上现在的项目管理中，工作量的衡量往往靠主管的经验来加以主观判断，而且这种判断也不是因人而异的。主观判断会造成较大的误差，这些误差的积累最终导致不可控制的因素增加和项目风险扩大。

如何在不打扰项目组成员工作的情况下，及时进行沟通？

现在很少有单q匹马就能把项目全部搞定，往往需要团队来完成，那么团队的合作精神就显得尤为重要。在一般人的眼里，技术人员都普遍比较孤傲，不好管理。主管不仅仅要掌握良好的沟通技巧，还要擅于感情交流，帮助解决项目组成员工作上和生活上的实际困难，使他们集中精力干好本职工作。良好的上下级和同级关系创造了融洽的工作气氛，项目成功的可能性大大增加。

如何评估项目执行状况，随时掌握项目进展？

在项目运作过程中，如果靠员工的报告来掌握项目进展是不够的。事实上，员工都愿意报喜不报忧，在项目初期就出现的问题苗头，如果不能传递上来，将在后续阶段造成大的纰漏。笔者认为除了要定期听取项目组成员的报告，还要专门有一个品保组来监督项目的执行情况。品保组就像廉政公署一样，不参与项目的具体实施，专门给别人"挑刺"，或者写一些测试程序来发现问题。

如何与客户单位沟通与协作？

有时候，项目都已经执行到最后阶段，客户单位突然提出了新的要求，这会让主管非常为难。一方面要尽量满足客户的需求，另一方面又不能对系统做太大的改动，影响进度计划。这种情况往往是与客户的沟通出现了问题，说明在需求阶段做的不够好，同时在实施过程中没有与客户有密切的联系。

如何在诸多不确定因素和限制条件下，按时完成项目任务？

项目成功与否受太多的风险因素影响。所谓“风险”，是损失的不确定性；是给定情况下，一定时期内可能发生的各种结果间的差异。它的两个基本特征是不确定性和损失。项目开发是一项可能损失的活动，不管开发过程如何进行，都有可能超出预算或时间延迟。很少有人能保证开发工作一定成功，都要冒一定的风险，也就需要进行项目风险分析。在进行项目风险分析时，重要的是要量化不确定的程度和每个风险的损失程度。潜在的问题都可能会对项目的计划、成本、技术、产品的质量及团队的士气产生负面的影响。风险管理就是在这些潜在的问题对项目造成破坏之前识别、处理和排除。

如何在完成项目任务同时，保证甚至提高交付结果的质量？

笔者的同事曾经做过一个项目，按计划按预算完成了，但是系统不稳定，某些关键技术指标不能满足国标。造成这种情况的原因有：没有划分清晰功能模块和接口关系，成员相互指责，最终难以定位不稳定的根源，；没有成立质保组，没能很好地实施项目过程控制；过分注重项目的时间进度，忽略或隐瞒了前期的小问题。

如何成为优秀的项目主管？

笔者认为：一个优秀的项目主管首先是一个乐观而自信的人。他凡事都从正面考虑，不把失败当失败，反而将其看作成功之母，吸取经验教训，在那里跌倒又在哪里爬起。优秀的项目主管不一定要很有经验，但是要有强烈的进取心和明确的目标，并能够与他人良好沟通，鼓舞他人为共同的目标一起努力。

IT项目管理的特征探讨

IT项目具有非常明显的特点：紧迫性、独特性和不确定性。下面分别讨论一下这些特点含义和项目管理的相应对策。

紧迫性

IT项目的紧迫性决定了项目的历时有限，具有明确的起点或终点，当实现了目标或被迫终止时，项目即结束。随着信息技术的飞速发展，IT项目的生命周期越来越短。有的项目时间甚至是决定性因素，因为市场时机稍纵即逝，如果项目的实施阶段耗时过长，市场份额将被竞争对手抢走。

在开始一个项目前，主管就必须明白项目的时间约束。具体到每个人、执行项目中的每一个任务都必须明确时间要求。一旦没有按照进度完成，必须要有充分的客观理由，否则就要追究相关人员的责任。

独特性

IT项目的独特性在IT服务领域表现得非常突出，厂商不仅向客户提供产品，更重要是根据其要求提供不同的解决方案。即使有现成的解决方案，也需要根据客户的特殊要求进行一定的客户化工作，因此可以说每个项目都有区别。

项目的这种独特性对实际项目管理有非常重要的指导意义。项目主管必须在项目开始前通过合同（或等同文件）明确地描述或定义最终的产品是什么。如果刚开始要提供什么没能定义清楚，或未达成一致，则最终交付产品或服务时将很容易发生纠纷，造成不必要的商务和名誉损失。即便是定义清楚了项目的目标，但是客户单位仍然会经常调整实现指标，这种变更很难控制，这就需要项目组与客户单位有良好的沟通渠道，否则改来改去，永远改不完。

不确定性

IT项目的不确定性是指项目不可能完全在规定的时间内、按规定的预算由规定的人员完成。这是因为项目计划和预算本质上是一种预测，在执行过程中与实际情况可定会有差异。另外，在执行过程中还会遇到各种始料未及的“风险”，使得项目不能按原有的预测来运行。

针对不确定性，在项目管理中就要注意制定切实可行的计划。笔者在工作中就发现科研工作，特别是国家级的项目，往往有一个“后墙不倒”原则。也就是说，设定一个项目的最终完成时间，具体的实施过程中，时间进度的安排就没有计划。在具体实施中，这种方法的最终结果是要么后墙倒了，要么后墙勉强没倒，做出来的产品满足不了质量要求。

还有一种不好的做法是过度计划，即将项目中非常微小的事情都考虑清楚才动手，但如此“详细的计划”其实是在试图精确地预测未来，也是不切实际的，在执行中会发现难以与实际一致，而不得不频繁地进行调整。具体问题具体分析。尽管有项目计划，执行过程中仍会碰到各种各样意想不到的问题，且往往没有现成的处理方法，这就要求项目经理必须掌握必要的工具方法，掌握整体过程和关键要素，灵活面对，妥善解决。

几个迫切需要重视的问题

项目管理有一些规律，但是还要具体问题具体分析，如果照搬硬套肯定会事倍功半。下面三个案例就是笔者在管理中遇到过的，现在拿出来一起探讨。

管理新手的重要性

一个项目组除了主管，全是新手！其实能有几个项目主管会如此幸运，项目组成员全都身经百战经验丰富。很多人认为，新手加入在短时间内对项目毫无益处，不仅帮不上忙，还需要别人来传帮带。笔者认为恰好相反：新人的加入是将会给整个项目组带来一些新鲜的想法，挖掘和引导这种的想法对新人的培训和很快的上手工作是非常关键的。公司花了钱招来的新人往往经过了人事部门的过滤，都具备了一些基本知识，主管可以先给他们分配一些具体的工作，调动他们的积极性非常关键。

在培训新人时就应该注意：

项目内容培训，让他尽快了解项目组的工作内容，项目的方向、目的，用到的知识、技能；

给他在项目组中的角色做个定位，明确他的职责，并提供必要的支持；

告诉他项目组管理方面须注意的问题，让他尽快融入到项目组里来；

尽量与目前项目组的工作结合起来培训，如让他尽快熟悉项目已经完成的工作，告诉他以后的计划，以及他马上要做的工作等等；

保持良好的沟通，了解他的进展，根据实际情况调整培训计划。

管理文档的重要性

让项目主管最痛苦的事情莫过于：当一个重要成员半途离开项目组时，才发现他根本就没有留下任何可用的文档。天下没有不散的宴席，项目组的成员也是在动态调整中，文档就是成员之间交接的重要工具。很多主管很容易陷quot;重技术实现，轻文档"的误区。他们总是认为项目实施时间紧迫，为了节省时间，可以在项目收尾阶段突击写文档。要是项目周期稍长，到了最后，成员还会记得清清楚楚每个实现细节吗？没有文档的项目铁定是一个失败的项目。

从过程控制的角度看，项目的实施质量控制，最重要的就是文档的管理控制。通过文档来显示表明每个基线，每个成员的工作量和完成质量，达到项目的风险最小化。

管理平台的重要性

笔者最初的几个项目都没有管理平台，所以没有量化的概念，管理手段非常落后。去年笔者在公司率先引入了微软PROJECT2000作为核心的项目管理软件，并根据项目的需求，以现有的计算机网络系统（Network）为基础，建立了内部的INTRANET项目管理平台。经过一年多的使用达到了以下效果：

使用PROJECT2000建立项目计划信息共享门户，使技术人员、主管随时看到与自己相关的任务信息，并通过建立状态报告，达到了解技术人员各自工作完成情况；

利用研发内部网站、电子公告板等共享信息系统，提供有效的信息沟通途径；

根据项目计划，建立动态提醒机制；

建立项目数据管理系统(Data)：对与项目有关的数据和与数据有关的过程，进行有效地管理；

电子文档管理系统(Document)，对图纸、文件、资料等文档，采用集中管理的方式，进行有序地组织，实现充分的共享和重复使用，实现了通过IE浏览器访问项目文档功能；

建立数据记录体现变更控制记录，项目文档记录。

结束语

就中国现状而言，项目管理还是一个全新的尚待开发的领域，很多项目管理人员和笔者一样都是在实践中不断摸索和思考。

从现实来看，只有那些跨国公司和国内的大型企业才对项目管理提出要求；从教育来看，项目管理的系统教育基本上就是空白，甚至目前中国还没有项目管理这一学科设置。同时，在中国，你所能够获得的有关项目管理的出版物以及资料都极其有限。

好在国内的教育部门已经发现了这个问题，各种PMP的培训班广告也开始出现在各类媒体中。那么我们是否都需要这个一个证书呢？

曾记得庄子在《庄子·养生主》中谈到的解牛的庖丁，在外人看来，技艺高超的庖丁解牛时，一招一式，轻松自如，姿势优美，其节奏如美妙音乐的旋律。而庖丁自己在历经多年的实践后，解释他的高超技艺的境界是："以神遇而不以目视，官欲止而神欲行，依乎天理，批大隙，导大，因其固然quot;

项目管理还是有"天理"可循，假如有机会还是应该带着实践中的问题多看书多学习，最终会达到所谓的管理艺术。(IT工程技术网)

背景由于最近几年公司业务的不断发展和壮大，业务部门对IT技术和自动化系统的依赖越来越大，他们需要IT来支持处理大量业务数据和交易。然而，由于公司缺少一支有组织且结构化的一线IT支持服务团队，雇员们在面对时而发生的IT故障和问题时变得越来越沮丧：他们不知道向谁寻求帮助，在四处求救时浪费了大量的宝贵时间；另外，对于那些重复发生的问题和服务故障，没有一个现成的经验和知识帮他们直接解决问题，使得IT服务人员陷入一遍遍解决同类问题的僵局。当他们处理外汇买卖业务或其他相关业务时，客户的需求和业务的特性使时间和准确率对他们来说至关重要。他们迫切需要一种最快，最准确的方法来协助完成所有交易。然而，他们却搞不清一旦发生技术故障，他们应该打电话找谁来寻求帮助。甚至即使打了电话，问题也不能得到很好解决，影响业务的进行。这直接导致了这些业务部门的IT最终用户产生如此错觉：IT服务与我们业务部门不是同路人，他并不是一个值得信任的，拥有共同业务目标的好的合作伙伴。这种对IT技术支持团队的错误认识，直接影响了各营业网点及分公司向客户提供服务的能力，降低了客户的满意度。业务需求与业务部门的误解形成鲜明对比的是，IT部副总裁感到自己身上的压力越来越大：一方面，在面对各业务部门的不理解和抱怨时，他和他的团队要负责向全北美洲的所有企业客户以及几百个分支机构提供IT支持服务；另一方面，为了提供更符合业务需求的IT服务，他还要向整个IT团队灌输一种以业务为中心的文化：即IT是为了业务服务，更好的服务于各种业务的需求。该公司的CIO认为，他的最终目的是建成一个提供IT服务的“一站式店铺”——以一种单点联系的方式解决所有与IT相关的问题。这一服务方式有以下几个方面的好处：·由于只有一个联系点，发生服务故障时，业务人员可以直接与IT技术服务人员联系，避免了不知找谁来解决问题的情况发生，从而缩短了“遗失时间”。·通过配置管理中的配置管理数据库，处于单一联系点的IT服务人员可以掌握所有配置向信息，使其可以更有效果且更有效率的使用各种配置项资源。·服务台人员对所有IT用户提交的服务请求，故障和问题等进行记录，这些记录提供了一种发现IT基础设施问题的机制。·为IT管理提供一种可量化的评价机制来评估业务·位于服务台的服务人员可直接接触用户，解决用户的问题。他们的服务以及对用户的态度将直接决定了业务用户对IT的认识，有效的IT服务台将彻底促进IT与业务的沟通，改善业务对IT的认识·当面对同时发生的大量突发事件时，服务台提供了一种结构化的流程来安排工作优先级，影响度大且紧急的问题优先解决；同时，服务台选择最快的方式来恢复发生故障的IT服务。

与业务部门的误解形成鲜明对比的是，IT部副总裁感到自己身上的压力越来越大：一方面，在面对各业务部门的不理解和抱怨时，他和他的团队要负责向全北美洲的所有企业客户以及几百个分支机构提供IT支持服务；另一方面，为了提供更符合业务需求的IT服务，他还要向整个IT团队灌输一种以业务为中心的文化：即IT是为了业务服务，更好的服务于各种业务的需求。

该公司的CIO认为，他的最终目的是建成一个提供IT服务的“一站式店铺”——以一种单点联系的方式解决所有与IT相关的问题。这一服务方式有以下几个方面的好处：

·由于只有一个联系点，发生服务故障时，业务人员可以直接与IT技术服务人员联系，避免了不知找谁来解决问题的情况发生，从而缩短了“遗失时间”。

·通过配置管理中的配置管理数据库，处于单一联系点的IT服务人员可以掌握所有配置向信息，使其可以更有效果且更有效率的使用各种配置项资源。

·服务台人员对所有IT用户提交的服务请求，故障和问题等进行记录，这些记录提供了一种发现IT基础设施问题的机制。

·为IT管理提供一种可量化的评价机制来评估业务

·位于服务台的服务人员可直接接触用户，解决用户的问题。他们的服务以及对用户的态度将直接决定了业务用户对IT的认识，有效的IT服务台将彻底促进IT与业务的沟通，改善业务对IT的认识

·当面对同时发生的大量突发事件时，服务台提供了一种结构化的流程来安排工作优先级，影响度大且紧急的问题优先解决；同时，服务台选择最快的方式来恢复发生故障的IT服务。

以上就是关于如何进行有效的需求管理全部的内容，包括:如何进行有效的需求管理、如何进行需求管理、该如何应对IT实施项目中的问题等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！