【51CTO.com原创稿件】常言道：人们真正需要的不是“钻头”，而是由它钻出的“孔”。同理，我们在工作中需要管理的不是IT项目本身，而是由它交付出的产品服务。在上一期中，我们讨论了IT项目的需求和评估管理，给出了各种可选用的“钻头”，以及可参考的“钻孔”方法。下面，我们从项目的设计阶段开始，继续探讨有关项目开展与治理的各项实践。
本系列文章如下：
【廉环话】不要让数据安全成为“盲盒”里的那只猫 -- 浅谈咨询业数据安全体系建设
【廉环话】防疫一周年后的IT治理思考 --可用性、关系与财务管理
【廉环话】防疫一周年后的IT治理思考 --能力、知识、问题与请求管理
【廉环话】防疫一周年后的IT项目管理思考 -- 设计、开发、安全
服务设计
首先，在着手设计之前，我们有必要综合考虑整体环境、现有资源、规定时间、内外风险、以及维护成本等因素。在此基础上，针对业务功能、容量性能、安全与可用性、参数指标、技术实现、模型架构、冗余排障、以及维护升级等方面，进行详尽的服务设计。而且，为了保证能够交付出用户满意的服务，我们应当在设计中重点关注：
- 设定不同用户角色在使用过程中，对服务进行的各项操作步骤(或称故事线，playbook)，以及业务数据在后台不同模块之间的流转过程。
- 只有好用，才会被多用。客户体验(Customer Experience，CX)和用户体验(User Experience，UX)是不可忽略的方面。应充分考虑到各种使用场景中可能出现的错误。
- 为待设计的产品和服务定义好相应的服务级别，以引起相关方的足够重视，而不是在事后再进行添加或调整。
- 避免出现“项目未半，已花光预算”，以及逾期交付等项目失败的风险。
- 减少项目进行中和交付的服务使用中，各方可能出现的责任界定不清、甚至是摩擦推诿等现象。
其次，我们需要对IT项目按照如下两个维度进行分类：
- 对近期、乃至中长期的业务需求设计新的服务。如：新增云端业务，启用安全管控措施，转型为DevOps交付模式等。
- 对现有的服务进行调整与改进。如：更新现有的技术实现方式，替换某个应用或模块，以及打造内网在线提交与派单系统等。
据此，我们在实际设计中，可以将待开发的新服务划分为如下三个层面：
- 基本功能。即：某个产品或系统向用户提供的最基本、最低的服务。例如：应用服务的相关页面是否能被打开，以及业务申请按钮是否在点击后提供响应等。这类主要是一些“必点”的功能。也就是说，每个用户只要访问该系统、或使用该服务，就会与此类基本功能互动，因此这也是新产品或服务推出的根本所在。
- 特定功能。即：区别于其他或现有产品或系统，满足特定需求的服务。例如：IT支持服务的在线派单系统，以及业务组件的秒级切换与容灾功能等。也就是说，这类主要是通过“人无我有”的途径，来满足差异化需求。
- 增值功能。即：让用户更流畅、更满意地使用某项功能。例如：通过双活数据库保障业务数据的实时可用，以及根据错误代码与关键信息，自动生成问题解决方案等。也就是说，此类主要是通过“人有我优”的方式，增加用户的粘性与满意度。
显然，上述三个层面的参考标准主要是针对新建服务的。而对于现有服务的调整与改进，我们则需要全面考虑到：与其他当前产品或服务、与相关方、与既有架构、与可用技术、与现有管理实践之间的各种关系。
在设计的过程中，我们应当通过采用：绘制模块关联图、创建用户接口原型、分析可行性、确定实现优先级、编写数据字典等方法，来对项目在时间、成本、资源、以及风险等维度予以管控。
常言道：有项目就会有风险。而设计环节的风险主要来源于：对需求解读的缺乏，架构与定义的不清，实现方式与技术的误用，以及干系人与需求方的参与不足、或过多的干扰。因此，为了避免在项目的后期，以及在产品服务的交付与发布之时，面临被动的整改，甚至是重大的调整，我们可以采用如下流程，来提高设计的质量：
- 确定各个组件的优先级->定义实体与属性->绘制逻辑关系图->梳理输入/输出流向->设计服务模型或产品原型等。
反过来，为了考核服务设计的绩效，我们也可以增加后续跟踪环节，从交付使用后的成本、效果、用户使用率、以及变更请求次数等维度，进行全面衡量。
需要注意的是，不只是新增的产品服务需要设计，那些针对现有服务的变更、迭代与退出，也需要通过流程的设计，以避免产生任何意外或负面影响。
设计阶段的最终成果交付包括：
- 用户级：采用需求方容易理解的语言和图表，描述所需提供的服务，以及操作的规范，并最终获得需求方的确认。如果即将交付的是软件，这有时也被称为软件需求规范(Software Requirement Specification，SRS)。
- 系统级：概要/详细设计说明(具体解释如下)、数据库设计说明、代码设计说明。
- 概要设计：有时也称高级设计(High-Level Design，HLD)，交付的是产品服务的体系结构。
- 详细设计：有时也称低级设计(Low-Level Design，LLD)，描述的是产品服务的每一项功能。
服务开发
总体而言，待开发的产品服务既可以是单个程序(如：程序套件、进程或工作流程)，又可以是较大的系统(如：操作系统、环境或数据库)，甚至不限于桌面应用程序、移动应用、嵌入式软件、以及各类网站。
目前，业界有两种普遍接受的软件开发方法，即：瀑布式和敏捷方法。而一直以来，大多数企业都持续运用传统的瀑布式开发模型。他们通过可预测的静态工作流，来确保开发团队能够根据预估的成本和截止日期，交付出高质量的软件。也就是说，此类开发模式通常会遵循如下软件开发生命周期(Software Development Life Cycle，SDLC)：
- 设计：包括用户界面、客户体验、服务设计等。前文已有讨论，此处不再赘述。
- 开发：开发人员着手编写并构建软件的相关代码。
- 测试：对可能出现的缺陷进行全面测试。测试人员通常会根据对于被测项目内部结构、以及实现原理的掌握情况，开展黑盒(完全不知)、白盒(全面知晓)、灰盒(部分了解)三种测试方法。测试内容包括：单元测试、集成测试、回归测试、信息安全测试、以及用户验收测试等。
- 部署：将产品服务部署并发布到生产环境中，以供最终用户使用。
- 运营：在使用产品服务的过程中，持续及时地解决用户碰到的任何实际问题;有效地管理代码存储库，并维护其完整性;执行版本控制，持续迭代并管理各个代码块。
在上述流程中，每一个阶段的输出都是下一个阶段的输入，显然，这样的线性固定模型，不但给可能出现的变更带来了巨大风险与成本，而且使得最终用户无法参与到开发的过程中，只能被动地等到最终“见证奇迹”。此外，由于测试人员只有在开发阶段结束后才能接触到代码，进而开展测试工作，因此该开发模型会使得开发人员与测试人员、需求方都缺乏协作。因此，近年来，不少企业都采用了一种新的、非固定线性路径式的敏捷方法(Agile method)。作为遵循迭代式开发的方法，它并不会为项目的全部过程创建各种固定任务，而是将开发分为多个迭代周期(Sprint)阶段。相比瀑布式开发，该方法具有如下的优点：
- 由于将单个大项目切割成了多个小任务，因此具有较短的开发周期，能够使得项目具有较强的适应性。项目组能够随时响应需求方提出的任何重大或微小的变更。
- 由于每个Sprint都有一个测试阶段，因此在开发人员每次发布新的功能后，测试人员都能立即开展回归测试(regression testing)。而且，需求方也能够及时做出接受或要求变更的决定。可见，三方都能够持续交流，并通力协同。
当然，文档是敏捷开发方法的短板。由于开发过程中的频繁变更和持续迭代，因此文档往往无法及时跟进和到位。这给复杂的大型项目带来了一定的不确定因素。因此，项目团队应当及时更新和完善相关文档。
开发安全
如今，随着信息安全人员已经成为了企业IT团队里的标配角色，他们该如何在IT项目的推进过程中发挥作用呢?这就要提到由敏捷开发模式所发展而来的DevSecOps了。
DevSecOps旨在将安全性尽量“左移”到各个开发子周期的初始阶段，以协助研发人员尽早获悉应用代码中可能存在的威胁与漏洞。对此，我们可以采用如下四种实践模式：
- 未雨绸缪式：分割应用程序之间依赖性，以便隔离各个组件，将来漏洞和威胁限制在单个组件中，进而保证其他组件持续运行。该模式的典型场景是微服务应用。
- 一票否定式：通过代码逻辑和用户场景的构建，在用户出现恶意行为时，中断其所有进程。例如：如果有用户在访问某个网站时，试图进行跨站点脚本注入攻击，那么其任何操作行为与会话就应当被直接阻止。
- 他山之石式：在缺乏安全专家的团队中，可以通过业界常用的威胁模型与管控模型，来提前识别应用组件可能面临的潜在风险，并选取最佳防护措施;同时，也能够保证安全人员与研发部门的沟通，更加顺畅，更有说服力，更容易达成共识。
- 川流不息式：利用自动化监控手段和提供多种输入参数，将对于运行环境与用例的风险评估，集成到产品服务的设计、直至实施环节中，涵括整个项目的生命周期。
此外，在项目实践中，我们也会重点实施如下方面：
- 针对不同的应用服务，设置不同的用户职能组别。
- 防止在应用数据的传输过程中，泄漏任何密码、口令、证书或私钥信息。
- 将多种应用程序的登录方式统一为单点登录(SSO)，以实现用户账号权限的自动匹配。
- 使用成熟的产品来检查证书并管理密钥，及时发现过期与注销等情况。
- 检查程序代码，及时发现无效或过时的依赖项与代码库，潜在的内存泄漏、无限循环、以及程序漏洞。
小结
综上所述，我们从设计、开发、以及开发中的安全，三个方面讨论了在IT项目推进与实施过程中的各项要点。值得一提的是，由于项目组的团队成员既可能是其他职能部门临时借调过来，又可能按需从外部引进和组建而成，因此为了保证大家“比较能打”的战斗力，项目组内成员之间的沟通与协作是必不可少的。为此，我们需要通过完善的规划、委派、协作和协调流程，既激发人员的积极性，又能够实现产品服务的成功交付。
P.S.，给大家的系列“思想汇报”进行至此，我突然想到了著名的坎宁安定律(Cunningham's Law)，也意识到在前面的各类治理思考中可能存在着不少不成熟、不完善、甚至不尽正确的地方。希望读者您能够不吝留言，及时帮我指出。本人在此谢过。
【51CTO原创稿件，合作站点转载请注明原文作者和出处为51CTO.com】
