【51CTO.com原创稿件】在本系列的前面三期中，我和大家一起讨论了去年防疫期间，本企业在IT服务方面的治理思考与实践。不过，说到底，这些都可以毫不客气地用时下流行词语—“内卷”来形容。而细心的读者一定会在心里想到：在企业IT人员的日常工作中，除了现有的各项系统与服务，其实还有一部分是即将上马和手头正在开展的各种IT项目。
【廉环话】防疫一周年后的IT治理思考 --可用性、关系与财务管理
【廉环话】防疫一周年后的IT治理思考 --能力、知识、问题与请求管理
确实，按照学界的“熵增”理论，IT服务系统有着趋于无序的惯性。因此，我们除了持续对其进行管理和治理之外，还需要通过新的IT项目，来实现更新换代和注入能量。下面，我将继续和您分享那些我们在过去的一年中，如何通过借鉴ITIL 4的相关理论，对IT项目生命周期的各个环节，所进行的管控实践与总结。
项目阶段
既然要涵括到整个生命周期，那么我们首先来梳理一下，常规IT项目的各个推进阶段和相关特征。如上图所示，无论是内部服务项目，还是外部技术项目，通常都会遵循“需求(Demand)、评估(Evaluate)、设计(Design)、构建(Build)、交付(Deliver)、改进(Improve)”六个发展阶段，并逐步推进。而我们的目标就是要打造出一个可控、灵活、完备的项目管理框架。具体而言：
• 需求阶段：需求方会针对当前IT服务的短板，提出新的业务需求。例如，他们希望获得一个“云端在线交流与协作平台”，以方便与客户及合作商开展业务往来，并提升随时随地访问与处理事务的效率。
• 评估阶段：IT管理层协同企业里的利益相关方(Stakeholder，或称资方)，根据企业整体的需求方向和资源能力，进行讨论、分析与评估，重点包括：
- 新需求与当前IT架构是否存在着逻辑上和业务上的重合或冲突。
- 当前的IT团队是否拥有技术储备，是否具备支持能力。如果缺少，则应考虑添置。
- 估算整体成本，包括新建、购置、运维等方面。
- 参照现有法规，是否存在合规方面的风险。
最终给出是否可行的结论。
• 设计阶段：成立项目组并启动项目。技术团队进行需求分析和概要设计，与需求方共同定义项目交付的目标。
• 构建阶段：项目组通过获取相关资源，持续与需求方沟通，着手开发、构建并完善平台服务。
• 交付阶段：项目组向需求方提交试运行的平台服务，并提供后续部署与发布等方面的支持。
• 改进阶段：在试运行期间，项目组会根据收集到的平台缺陷与反馈，持续进行改进与迭代。该阶段可以长期循环进行下去。
上述项目阶段的划分具有一定的通用性，或者说过于停留在宏观层面上了。下面，我将和您一起结合本企业的IT项目实际管理经验，进行深入分解和细化。我们首先从IT项目的需求评估阶段进行切入，具体分为需求识别、需求分析、资源配给，三个方面开展讨论：
需求识别
从理论上说，在分析和解读需求之前，我们需要了解本企业所处的行业、正在开展的业务、甚至是经营模式的盈利点。在此基础上，我们再从技术的角度，进一步理解业务的核心架构、执行与开展的流程、以及支持业务的职能分工与团队。简言之：“先知己，再知彼”。所有针对新需求的分析，都应当建立在充分了解当前业务的基础上。只有掌握了这些信息，我们才能与需求方深入进行交流与沟通。
当然，在我们所碰到的实际场景中，需求方往往习惯于采用“业务化”的语言，来描述和提出新的系统与服务需求。例如，他们会要求“在秘书录入了当月本部门销售数据之后，需要系统能够自动显示业绩最好的签单信息”。而IT技术人员则需要通过聆听和翻译，将其转换为“系统化”的表述形式，即：“以某个输入项作为关键字段，在对应的数据表中，按照数值大小进行排序，进而显示‘金额’列的最大值”。此处的“翻译”就是指：将业务需求整理并转化成为“业务需求说明书”，以便双方进一步沟通与确认。
在沟通需求的过程中，技术人员千万不可以专家自居，闭门造车。就算无法与需求方面对面地开恳谈会，也要通过电话/视频会议、或收发问卷调查等形式，协同相关部门做好需求调研的工作;以及根据需求的可行性，划定可实现的边界，并做好必要的引导工作。
需求分析
如前文所述，在明确了需求的目的后，IT决策层应当协同相关部门的代表、以及管理层，对需求的可行性进行分析与评估，并重点关注如下方面：
• 合理性：显然，任何新的IT服务需求，都需要顺应企业管理层的意识、体现对于业务价值的提升。您别觉得这些过于空泛，它们确实是IT项目能够向前推进的根基。我们可以毫不夸张地说：所有与业务主线脱钩、自弹自唱的项目开启方式，都将以失败而告终。例如，前面提到的“云端在线交流与协作平台”，如果一味地强调信息交流和文件交换的便捷性，而在规划与设计中，忽略了对于企业与客户敏感信息的保护，那么此类项目于情于理都无法顺利落地。
• 前瞻性：IT技术日新月异，千万不可禁锢发展的空间。许多新系统的内部固有缺陷，很可能会滞后体现。例如：某项最新的开发技术，虽然在功能与效果上异常优秀，但是自身带有一定的安全漏洞，或是隐私合规问题。那么无论它将来需要额外添加补丁，还是被另一种实现方式所取代，都是对当前项目投入的浪费。因此，我们不应盲从最新的技术，否则IT运维人员可能在会后期长期处于“布朗运动”的状态。
• 通用性：不是所有的需求都能被满足，也不是所有的需求都要新开项目。我们应当对现有技术能力、甚至是“潜力”有所了解。如果能够通过对当前的服务进行简单整改、升级、甚至是部分替换，便可实现需求，则无需上马新的IT项目。毕竟，新的系统往往意味着风险点的新增，以及运维成本的增加。当然，对于那些仅需微调即可实现的小项目，我们应划定好需要改进的范围。
在实际操作中，为了能很好地分析和评估新需求，我们企业的IT团队经常以头脑风暴的方式，从如下思维维度展开思考与讨论：
• 应该达到何种效果?
• 需要哪些配套资源?
• 会有哪些限制条件与困难?
• 除了该需求方是否还有其他类型的用户?
此外，我们也会适当地运用建模和映射工具，借用经典的沙盘演练方式，开展业务影响分析(BIA)和风险分析(RA)，最终得出针对可行性与紧迫性的分析结果。
值得一提的是，我们不应长时间地处于需求分析状态，而未能及时给予答复。哪怕暂时无法定论，我们也应当及时向提出方以邮件或电话的形式告知处理的状态与进展。当然，我们也不应抱有通过单个大型项目，便可快速满足需求的想法，毕竟我们还需要考虑能够获取到的资源。
资源配给
在通常情况下，企业中不同的角色对于系统与服务的新增需求，有着不同的关注点：
• 最终用户和运维支持人员往往关注的是易用性、易实现性、以及容易排障。这是一种是自下而上的使用需求。
• 而资方和管理层则更关注的是投资的必要性、总价、以及投资回报率(ROI)。这是一种自上而下的添置判断。
可见，为了既实现“手中有粮，心里不慌”，又能为决策层提供现有预算和资源等方面的参考，我们可以从如下方面来管理和配给资源：
• 可视化：引入“池”的概念，从资源的购置开始，进行整个生命周期的跟踪，并及时回收闲置的资源，以提高复用率。同时，请将相关信息更新到数据库中，并开放给不同的角色，实现直观的定制化查询。
• 定制化：所谓“适合才是最好”，我们可以参考如下维度来定向配给与投入：
- 合规要求：网络安全、用户隐私、以及行业标准，往往是新业务开展的基本条件，因此我们需要给足资源，以保证业务的健康运行。
- 成本效益：对于以盈利为目的的企业而言，投入的总成本不应大于新服务能产生的效益与价值。
• 模块化：根据“有多大能耐办多大事”的原则，综合考虑已开展的项目、可获取的资金、以及目标客户的分类，按照分阶段、分步骤的方式，为新需求逐步添置与配给资源，进而降低一次性投入的风险。
• 可控性：在有限的项目与资金范围内，排定需求的优先级，及时评估、跟踪、审查可追加的资源，提出调整建议，并能把控预期的效果。
值得注意的是，这里涉及的资源不仅限于IT系统的软、硬件，还涵括了人力、物力、财力、以及服务管理能力等方面，我们应按需预先为企业购置或规划。
小结
上面我们重点讨论了在需求和评估的阶段，如何为IT项目积极准备，并让其能够步入正轨。可见，我们千万不用以“熊掌拍清波”的架势，大干快上某个IT项目，而应当通过全面、透彻的分析，让合理的需求得到合理的资源，并转换为合理的项目。
常言道：磨刀不误砍柴工。作为IT项目的深度参与者，我们有必要采取“服务 + 业务”的思维，为每个新建项目筹备好开局。在后面几期中，我将继续和您进一步讨论如何管理IT项目的若干后续阶段--设计、构建、交付、改进。咱们下期见!
【51CTO原创稿件，合作站点转载请注明原文作者和出处为51CTO.com】
