【《IT项目管理难点剖析概述》4400字】

IT项目管理难点剖析概述IT项目的特点对广义项目的目标定义为，在一定的时间范围，以及有限的资源内开展一系列活动以达到某些特定要求。相对于日常运营类工作，项目最明显的特点即为一次性，其次具有明确目标的特性。而IT项目则是一个和informationknowledge(IT)技术如基础架构、信息系统或计算机相关的项目。例如软件开发，网页开发，手机应用开发，网络配置，软件安装，数据库管理等。在广义定义的基础上又具有一下几个特殊特征。1.不可见性。区别于传统意义的项目，不像基础建设项目等有形物品的项目过程，IT项目的进展情况是肉眼不可见的。除了进展的不可见性，IT项目的成本也具有这个特点，除了人力资源成本之外，还有难以精确分配到各个项目上的一些运营管理成本。将这些不可见的进展通过一定的项目管理手段转变为可视化的过程是IT项目管理特有的。3.灵活性。IT项目相对于工程类项目具有更大的灵活性。拿施工项目作比，开工之后整体，一旦开工，工程内容一般很难做变更，或者说变更需要付出巨大的代价。而IT项目，基于可不断迭代的特性，将大大增加项目的灵活性。在项目计划时，可将百分百确认的需求先排期完成，不能完全确认的需求在项目推进的过程中慢慢再完善。4.需求变更频繁。项目灵活性的增加反之带来的就是更频繁的变更可能性。在互联网与大数据时代下，要求IT项目的输出时刻顺应市场的需求，而市场的需求因为通过数据快速反馈到产品方，导致对需求变更频率和可能性的增加。5.业务经验难以复制。同为IT项目，针对不同行业的业务需求，有其不可复制的特点。在数字化转型的大趋势下，无论哪个行业都已经离不开IT项目，包括传统行业。而不同行业的本身独立的业务特性使得跨行业的IT项目经验基本无效的效果。且随着IT技术的迅速发展，应用方法的不断突破创新，即使在同行业内，过往解决方案的可参考性依然不强。6.技术领域宽，迭代更新快。IT技术领域宽广，从基础架构、前端、中间件到数据库、核心编程，每个领域内的技术分支还异常繁杂。导致针对同一个需求可以有无数个组合方案，很难说谁优谁劣。拿编程语言为例，根据TIOBE，Python在短短10年间从5%左右的打分上升到了12%左右，而Java则是在这段时间内从23%跌到了12%。而根据DB-E的统计，自2015年以来数据库领域MongoDB、PostgreSQL也在不断冲击行业三巨头(Oracle、MySQL和MicrosoftSQLServer)的地位。同样，10年内仍在活跃webserver的市场占有率中，Apache从接近过60%跌到25%，nginx则为崛起的新星直逼20%（数据来源：Netcraft）。图2-SEQ图2-\*ARABIC1Top10编程语言走势图Picture2-SEQPicture_2_-\*ARABIC1Top10programminglanguagetrendbyyear这些都表明在IT领域内，主流技术是瞬息万变的，在不同的分支领域更有不同的技术方向，造成了各种排列组合的可能性，增加了IT项目技术方面的难度。IT项目管理面临的挑战直接用数据说话显得更加直观，根据2017年PMI’s(ProjectManagementInstitute)PULSEofthePROFESSIONPMIPMI’sPULSEofthePROFESSION:自2006年来定期组织的全球范围内项目管理相关调查，列出现在和将来在项目管理领域的主要发展趋势。图2-SEQ图2-\*ARABIC2问卷：公司过去12个月内所完成的项目占选项的百分比NOTEREF_Ref73902496\f\h3NOTEREF_Ref73902496\f\h3PMI’sPULSEofthePROFESSION:自2006年来定期组织的全球范围内项目管理相关调查，列出现在和将来在项目管理领域的主要发展趋势。Picture2-SEQPicture_2_-\*ARABIC2Survey:Whatpercentageoftheprojectscompletedwithinyourorganizationinthepast12months?该调查报告中，再进一步对于项目失败归因的调查分析结果显示，39%的项目是由于项目需求不清晰而导致的。图2-SEQ图2-\*ARABIC3问卷：在过去12月内，贵公司失败的项目中有哪些被列为主要原因？Picture2-SEQPicture_2_-\*ARABIC3Oftheprojectsstartedinyourorganizationinthepast12monthsthatweredeemedfailures,whatweretheprimarycausesofthosefailures?再多看几组不同机构在不同时间调研数据：33%的IT项目由于高层管理不够重视或需求/项目范围变更导致项目失败KhaledEIEmam，对IT软件项目的调研，2008KhaledEIEmam，对IT软件项目的调研，2008规划阶段的错误估计仍然是IT项目失败的最大原因，占比32%普华永道第15次CEO年度调查，2012普华永道第15次CEO年度调查，201240%的CIO认为，项目失败是因为对项目过于乐观而没有清晰明确的目标而导致的哈维纳什毕马威联合CIO调查，2017哈维纳什毕马威联合CIO调查，2017从不同维度的各种数据不难看出，排除客观因素和项目管理本身不可控的因素外，在项目管理经验中，需求管理的优劣和最终的项目输出结果的成绩有着重要联系，当需求没有准确收集的情况下会直接导致项目过程中，项目范围因需求变化而造成的不断变更，从而增加项目失败的风险。另外项目计划估算的准确程度也是导致项目失败的主要归因。需求变化快单独先从需求管理出发来看，需求管理其实在项目管理的整个过程当中占用到项目前期很大一部分时间的内容，没有一个项目管理人员会不重视需求管理，为什么这依然是造成项目失败的最大原因呢？2005年，联邦调查局致力于开发的虚拟案件档案系统在花了五年时间和1.7亿美元之后被宣告失败，项目软件负责团队任务，这是需求不断变更和项目范围频繁扩展导致的结果。在IT领域，需求的变更为非常普遍和常见，可以称之为常态。需求本身存在变更，尤其在高速发展的互联网时代，信息的传递速度变快了，相应对于企业响应市场变化的效率也高了，谁能更快的调整对的方向才能更快的在业务领域中抢占一席之地，以至于需求变更的速度也越来越快，这是一个客观事实。但这些客观存在的需求变更其实是属于被积极响应和欢迎的。从企业敏捷的角度看，需要适应几个月前设定的目标被完全颠覆重新寻找方向的场景，当然大多数时候更多的是会在细节部分做调整。转而从产品交付执行层面，任何一个项目成员都不愿意只是因为几个月前设定目标的时候是如此的，在明知已经被市场验证为错误的方向上持续前进。唯一需要做到的就是将为什么做这样的调整横向和纵向的沟通清晰，那么在执行层面也会更好的被接受。利用敏捷方法论加速了产品开发的速度和质量，对于随时调整的需求，开发团队可以在很大程度上更好的支持此类的变化。需求理解偏差大个人认为更大的痛点在于由于非有效沟通造成的需求模糊或需求认知不一致而造成的需求管理失败。PMI指出，判断一个项目成功需要判断是否满足6个事实。1.按时交付项目。2.项目支出控制在预算内。3.实现需要交付的功能和产品。4.用户持续使用产品。5.项目发起人感到满意。6.完成项目立项指定的目标。从时间和成本角度来说，团队比与其时间晚交付了一个月，导致业务方错失了占领市场的最佳时机而导致企业在可能获得的利润上的有所损失，是一种失败。从产品角度来说，团队按时按点在预算内交付了最终的解决方案，可是却没有一个用户愿意为这个成品买单，是另外一种失败。哪一种更令人感到沮丧呢？我要的是一辆自行车，你为我造了一辆跑车，简直超出预期，极具性价比，可我没有任何可以用到这个产品的场景，这种才是最尴尬的境地。A公司前不久有一个迁移项目，将系统对接的第三方平台由供应商A变为供应商B，该项目都没有牵扯到项目经理，直接由产品经理负责，可见是比较小的一次任务。业务部门提出的需求非常简单，供应商A现在可以用的功能，B也要做到就可以了，在上线前，没有看到任何关于这个项目存在风险的提示。供应商B顺利在3个月内对接完成上线了。问题出现在上线之后，“同样功能”的两套产品返回出的业绩数据一下子由原先的90分将为了20分。这下把业务部门急坏了，马上开始职责开发团队交付的产品有问题，导致业务部门业绩不达标，紧急拉上高级项目经理来解决问题。经过讨论发现，有意思的是，没有人，包括业务部门和产品经理，清楚A供应商为我们提供了什么，却在过去的3个月内信心满满的将开发任务完成并交付了，造成了后面出现的遗憾场景。从业务角度、产品角度、设计角度和开发人员角度，看同一个问题都能看到不同的一面，有时候同一个词放到不同的场景和角度中就会有不同的理解。我们都已经非常熟悉利用需求说明Spec来管理需求的模式，尤其是在甲方和乙方合作的时候，需要一纸合同作为保障，而这条条款款也必将由这需求文档转化而成。然而，仅仅是这样的需求文档能确保项目各个参与方对需求的认识达到几分这是存疑的。需求挖掘错误2008年，澳大利亚航空取消了4000万美元的捷运项目。该项目是一个为澳航的机修工们建立零部件管理系统的项目，不幸的是，这个解决方案设计的太过于复杂以至于飞机机修工们都拒绝使用它。澳航后来官方对外表示，他们并没有问机修工们需要什么，而只是建造了他们认为合适机修工的东西。由于没有让合适的人，即，最终用户，参与项目，结果澳航不得不终止了这个昂贵的IT项目，而后又花了三年时间去开发一个替代的产品。这是一个典型的潜在需求挖掘错误的案例。为了避免类似澳航这种情况，需要让所有项目干系人，包括技术领域的专家，业务代表，甚至最为重要的，在条件允许的情况下把最终用户也邀请进来，参与项目需求确认。业务方和用户一起传达需要什么，而IT这边在技术上权衡如何实现，构建所需要的最佳解决方案。当多方同时参与时，将显著降低由于需求不对版而造成项目失败的风险。要求业务方的参与是基本前提，除此之外，项目需求需和业务目标一致。由于IT项目的不可见性的特点，从产品管理（业务）角度和项目管理（技术）角度看同一个需求，可能会在理解上有不同程度的偏差，就如同鸡同鸭讲。这也是项目管理上需要避免和解决的问题之一。估算偏差控制难在软件开发领域存在这样一个真理，想要开发的功能总是比你能投入开发的资源多。而每个功能需要占用的资源一定程度上影响了该项开发的优先级。由于IT项目本身的特点，对于项目交付时间的估算，是一个很微妙的存在。不像基建工程，我铺设一段100米的马路，有固定的工序和经验积累下的已知时间，有经验的老师傅和新手之间的偏差也不会特别大。根据图2-3数据表明，项目目标的变更是导致36%项目失败的罪魁祸首，26%项目失败的导火线是时间估算的不准确。在灵活多变的IT项目中，需求范围的变更是常态，想要控制不断变化的项目目标是不太可能也不切实际的，但是可以通过建立合适的工作模型将项目变更造成的影响降低。计划和目标的改变并不一定会导致失败，通过缩短计划的时间框架，确保更高优先级的工作被执行被交付将失败的风险降至最低。估算不准确可能有几个原因。第一，缺乏实践经验。经验薄弱的开发团队通常在估算时过于乐观，假设一切都会顺利进行，低估了时间和成本。第二，在计划阶段，项目经理要求估算的时间点过早，往后也没有再次回顾对于早期的估算做修正。另一种，是对需求理解不准确造成的估算偏差。图2-SEQ图2-\*ARABIC4不确定性锥形图ConeofUncertaintyfromAgileInaNutshellConeofUncertaintyfromAgileInaNutshellPicture2-SEQPicture_2_-\*ARABIC4TheConeofUncertainty（Source：AigleInaNutshell）绝对不会有两个一模一样的项目，一样的需