【51CTO.com原创稿件】常言道:人们真正需要的不是“钻头”,而是由它钻出的“孔”。同理,我们在工作中需要管理的不是IT项目本身,而是由它交付出的产品服务。在上一期中,我们讨论了IT项目的需求和评估管理,给出了各种可选用的“钻头”,以及可参考的“钻孔”方法。下面,我们从项目的设计阶段开始,继续探讨有关项目开展与治理的各项实践。
本系列文章如下:
【廉环话】不要让数据安全成为“盲盒”里的那只猫 -- 浅谈咨询业数据安全体系建设
【廉环话】防疫一周年后的IT治理思考 --可用性、关系与财务管理
【廉环话】防疫一周年后的IT治理思考 --能力、知识、问题与请求管理
【廉环话】防疫一周年后的IT项目管理思考 -- 设计、开发、安全
首先,在着手设计之前,我们有必要综合考虑整体环境、现有资源、规定时间、内外风险、以及维护成本等因素。在此基础上,针对业务功能、容量性能、安全与可用性、参数指标、技术实现、模型架构、冗余排障、以及维护升级等方面,进行详尽的服务设计。而且,为了保证能够交付出用户满意的服务,我们应当在设计中重点关注:
其次,我们需要对IT项目按照如下两个维度进行分类:
据此,我们在实际设计中,可以将待开发的新服务划分为如下三个层面:
显然,上述三个层面的参考标准主要是针对新建服务的。而对于现有服务的调整与改进,我们则需要全面考虑到:与其他当前产品或服务、与相关方、与既有架构、与可用技术、与现有管理实践之间的各种关系。
在设计的过程中,我们应当通过采用:绘制模块关联图、创建用户接口原型、分析可行性、确定实现优先级、编写数据字典等方法,来对项目在时间、成本、资源、以及风险等维度予以管控。
常言道:有项目就会有风险。而设计环节的风险主要来源于:对需求解读的缺乏,架构与定义的不清,实现方式与技术的误用,以及干系人与需求方的参与不足、或过多的干扰。因此,为了避免在项目的后期,以及在产品服务的交付与发布之时,面临被动的整改,甚至是重大的调整,我们可以采用如下流程,来提高设计的质量:
反过来,为了考核服务设计的绩效,我们也可以增加后续跟踪环节,从交付使用后的成本、效果、用户使用率、以及变更请求次数等维度,进行全面衡量。
需要注意的是,不只是新增的产品服务需要设计,那些针对现有服务的变更、迭代与退出,也需要通过流程的设计,以避免产生任何意外或负面影响。
设计阶段的最终成果交付包括:
总体而言,待开发的产品服务既可以是单个程序(如:程序套件、进程或工作流程),又可以是较大的系统(如:操作系统、环境或数据库),甚至不限于桌面应用程序、移动应用、嵌入式软件、以及各类网站。
目前,业界有两种普遍接受的软件开发方法,即:瀑布式和敏捷方法。而一直以来,大多数企业都持续运用传统的瀑布式开发模型。他们通过可预测的静态工作流,来确保开发团队能够根据预估的成本和截止日期,交付出高质量的软件。也就是说,此类开发模式通常会遵循如下软件开发生命周期(Software Development Life Cycle,SDLC):
在上述流程中,每一个阶段的输出都是下一个阶段的输入,显然,这样的线性固定模型,不但给可能出现的变更带来了巨大风险与成本,而且使得最终用户无法参与到开发的过程中,只能被动地等到最终“见证奇迹”。此外,由于测试人员只有在开发阶段结束后才能接触到代码,进而开展测试工作,因此该开发模型会使得开发人员与测试人员、需求方都缺乏协作。因此,近年来,不少企业都采用了一种新的、非固定线性路径式的敏捷方法(Agile method)。作为遵循迭代式开发的方法,它并不会为项目的全部过程创建各种固定任务,而是将开发分为多个迭代周期(Sprint)阶段。相比瀑布式开发,该方法具有如下的优点:
当然,文档是敏捷开发方法的短板。由于开发过程中的频繁变更和持续迭代,因此文档往往无法及时跟进和到位。这给复杂的大型项目带来了一定的不确定因素。因此,项目团队应当及时更新和完善相关文档。
如今,随着信息安全人员已经成为了企业IT团队里的标配角色,他们该如何在IT项目的推进过程中发挥作用呢?这就要提到由敏捷开发模式所发展而来的DevSecOps了。
DevSecOps旨在将安全性尽量“左移”到各个开发子周期的初始阶段,以协助研发人员尽早获悉应用代码中可能存在的威胁与漏洞。对此,我们可以采用如下四种实践模式:
此外,在项目实践中,我们也会重点实施如下方面:
综上所述,我们从设计、开发、以及开发中的安全,三个方面讨论了在IT项目推进与实施过程中的各项要点。值得一提的是,由于项目组的团队成员既可能是其他职能部门临时借调过来,又可能按需从外部引进和组建而成,因此为了保证大家“比较能打”的战斗力,项目组内成员之间的沟通与协作是必不可少的。为此,我们需要通过完善的规划、委派、协作和协调流程,既激发人员的积极性,又能够实现产品服务的成功交付。
P.S.,给大家的系列“思想汇报”进行至此,我突然想到了著名的坎宁安定律(Cunningham's Law),也意识到在前面的各类治理思考中可能存在着不少不成熟、不完善、甚至不尽正确的地方。希望读者您能够不吝留言,及时帮我指出。本人在此谢过。
【51CTO原创稿件,合作站点转载请注明原文作者和出处为51CTO.com】
根据TrendForce的最新调查,自2020年初以来,COVID-19流感大流行加速了世界各地...
根据调查,随着用户对计算能力、存储和网络容量的需求增长,服务器需求比经济不...
人头马君度(Rmy Cointreau)的历史非常重要,这家酒业公司以将最好的酒陈化100年...
2020年以来,由疫情停工减产所导致的缺芯困局影响着全球汽车发展,而本以为2021...
在疫情的影响下,人们的工作和生活方式在过去的一年发生了前所未有的变化。为了...
在VMworld 2020,VMware宣布与NVIDIA进行全面合作,共同推出新一代的混合云架构...
时间真快呀!转眼又至周一。让我们卯足干劲继续前行,先来看看上周有哪些不容错...
2020年11月26日深圳潮数科技于石家庄成功召开数据安全 新时代新基建信息应用之基...
【51CTO.com快译】数字化转型使应用程序领导人必须找到有效的方法来更新改造遗留...
本文中的五个步骤有助于您掌握转型的总体需求,并有助于您处理一些真正重要的事...