开源管理项目管理
我们的数字生活由选择开发开放代码的编程哲学家提供动力。
所有程序都以指令线开头。 准备执行时,这些指令行将转换为计算机可以执行的二进制格式。 开源程序是任何人都可以访问人类可读代码的程序。 这种开放和自由的哲学使这些项目能够影响每个人的生活。
Linux内核是所有Android设备的核心,几乎所有互联网流量的三分之一都来自一个开放开发的项目Netflix。 (有关此问题,请阅读《 时代》杂志上的出色文章 。)将开源软件用作项目计划的选择如何影响组织中项目的风险量和风险类型?
风险既是感知又是现实。 工具可以帮助我们从感知变为现实,就像优质温度计可以帮助我们从非常普遍地使用热和冷到更具体的可量化温度( 请参阅Google中的示例 )一样。 随着时间的流逝,我们采用了不同的标准和技术来讨论特定的温度,具体取决于受众和标准的局限性。 开尔文,摄氏温度,华氏度,甚至RealFeel现已成为测量温度的标准。
![天气图 Weather graph](https://i-blog.csdnimg.cn/blog_migrate/c2da255914966cd4c72e015cad43527e.png)
插图1:量化温度
每个项目都有风险,每个项目经理(项目经理)都会以不同的准确性水平来感知和阐明风险。 对风险的理解可能像对术语“热”和“冷”的简单描述一样好。 PMBOK (项目管理知识体系)指出,讨论风险管理的过程应从定性评估转变为定量评估(如项目管理协会出版物“项目管理知识体系指南/ PMBOK指南中所述”)。 ”(第5版))。 像温度一样,项目管理学科也有不同的量化标准来衡量项目风险。 这些风险评估标准中至少有一个可以说明为什么在项目计划过程中经常拒绝开源软件作为项目可能的考虑因素。
Tom Kendrick在《 识别和管理项目风险》 (Kendrick,2015年)一书中讨论的风险复杂度指数是我们的基础。 复杂性指标在项目风险管理中并不罕见。 大卫·比尔登(David Bearden)使用复杂性指数来说明美国宇航局采用FBC(更快,更好,更便宜)的哲学是如何影响项目风险的。 尽管他的指数基于近来的数据点,但肯德里克著作中的风险复杂度指数试图更具预测性。 肯德里克将指数的公式表述为:
指数=(技术+建筑+系统)X规模
根据项目经理的经验和能力,技术,架构师和系统的评分为0到5。 肯德里克说:“架构指的是高级功能组件和任何外部接口,而系统是指将在产品中使用的内部软件和硬件。技术维度被定义为项目所用开发的基础。”书。 他解释说,可以使用以下键对索引进行评分:
0.仅需要现有技术
1.在一些领域对现有技术进行少量扩展
2.在某些领域需要对现有技术进行重大扩展
3.几乎可以肯定,但是在某些领域需要创新
4.可能可行,但在许多领域都需要创新
5.全新的,技术可行性尚不确定
根据项目预期人数为比例分配一个值:
- 0.8最多12人
- 2.4最多40人
- 4.3最多100人
- 6.6 100多人
在该指数中,0到20的结果被认为是低风险,20到40的结果被认为是中风险,而40到100的结果被认为是高风险。 正如价格标签是杂货店货架上给定项目的生产要素成本的摘要一样,该索引也是对项目风险有影响的项目的摘要。 在风险管理的这一点上,已经确定并量化了风险。 最初,整个风险指数是指实施该项目的组织内部的项目风险。 在制定缓解措施后,可以使用矩阵对项目进行评分。
![项目管理风险评估 Project management risk evaluation](https://i-blog.csdnimg.cn/blog_migrate/15d9fb52db454e7496e4cbdb7ee8d2b7.png)
计分风险
在Adrienne Watt在“ 风险管理 ”一书中有关风险管理计划的章节中,她讨论了减轻风险的四种策略。 这些是规避风险,分担风险,降低风险和转移风险。 在应用了这些策略的某种组合之后,项目经理团队可以重新设计风险复杂度指数,以确定他们是否将项目的总体风险降低到可接受的水平。
开源的关键问题是,使用开源时,风险由组织承担。 诸如BSD的非常简短的许可证之类的开放源代码许可证包括明确地将责任从代码创建者转移到代码用户的语言。 它通过声明“此软件按“原样”提供,没有任何明示或暗示的担保”的声明来做到这一点。 对于Linux, GPL 3.0的序言指出:“为了保护开发人员和作者,GPL清楚地说明了此免费软件没有任何保证”(Free Software Foundation,2007)。
这破坏了前面列出的缓解措施的几个关键方面。 如果组织对代码承担技术责任,则他们规避,分担,减少或转移风险的能力就会降低。 开源代码仍然可以成为风险管理策略解决方案的一部分,在某些情况下,开源代码是缓解风险的重要因素。
来自主要供应商的软件为该供应商增加了策略税的风险。 流行游戏发行平台Steam的创建者Valve(Valve)与Microsoft Windows相关的战略税达到了临界点。 Valve选择减轻风险的增加,并开发了SteamOS ,将其分发软件移植到开源代码上运行(Dingman,2013年)。 他们为自己的基金会选择的代码的战略税要低得多,从而大大降低了风险。
Valve的程序员人才库意味着他们拥有审核和理解相关源代码的技术知识,但并不是每个企业都有足够的资源。 确实有大量程序员的企业倾向于将开源应用程序纳入其项目计划。 在2010年, Google将大量计算机从Windows 切换到Linux。 Netflix运行FreeBSD以利用ZFS内置的技术。
品牌价值在业务资产组合中扮演着重要角色,而可能损害品牌的项目可以被视为使公司面临更高的风险。 较敏感的品牌部门之一是为每个客户工作项目的IT安全公司。 通过与该部门员工的私人交谈,我了解到他们转移风险的一种方法是通过公司沟通渠道上的政策。 确切地说,它们的通信渠道都不是内部的。 相反,要求每个员工使用多种外部通信技术。 该组织的现实情况是,如果他们的品牌成为成功攻击的受害者,并且新闻周期的任何部分包含该组织的名称,都会对品牌造成严重损害,因此对于使用Gmail的电子邮件和使用Slack进行聊天的用户(笔测试, 2016)。 他们依靠大量其他应用程序和服务来减少攻击面,并将风险转移给尽可能多的组织。
项目的真正风险成本不会在项目完成时结束,而是在产品整个生命周期中让客户满意。 为了准确地说明来自开源项目的品牌风险,最近的例子非常生动。 趋势科技的团队进行了一个项目来构建其组织的网站时,他们选择了流行的开源WordPress套件。 最近, WordPress有一个漏洞已被黑客利用,并因其对修补此漏洞的评估而受到了广泛的关注。 相比之下,趋势科技的网站受到早期项目经理的决定的类似负面报道( McCaskill,2017年和JupiterBroadcasting,2017年 )。
在围绕开源的这种负面新闻中,难怪为什么许多PM会忽略开源在实际降低项目的复杂性指标方面可能具有的优势。 KDE的网站最近发布了对托马斯·魏塞尔 ( Thomas Weissel)的采访,托马斯·魏塞尔 ( Thomas Weissel )是奥地利学校系统的开发人员,他完成了一个将KDE纳入他工作的奥地利学校的项目。 在采访中,他描述了开源的一项关键优势,即团队解决问题的可访问性。 用他的话说:
“这是我选择Plasmashell:KIOSK系统的另一个原因。我报告了KIOSK系统的很多问题,Plasma开发人员在发现和修复5.8中发现的所有错误方面做得非常出色。我们现在有了一个台式机已完全锁定,以确保不会有人意外删除或重新配置用户界面的重要部分。” Weissel说( Riddell ,2017年)。
长期开放源代码评论员克里斯·费希尔(Chris Fisher)口口声问项目经理 ,他们认为封闭源代码供应商需要花多长时间来响应项目执行过程中发现的错误。 这是一个架构成本从组织转移到开发人员的绝妙例子。 对于企业规模的项目,大型,封闭源代码的供应商可能愿意与他们的客户合作。 对于规模较小的项目,项目团队的响应能力可能是他们根据特定需求使用软件的唯一途径。
开源解决方案已被市场的各个部门采用,以适应我们技术基础架构中的关键角色。 由汤姆·肯德里克(Tom Kendrick)开发的风险复杂度指数可帮助我们了解在市场的各个方面采用开源解决方案的困难。
通常,开源解决方案将风险从软件供应商转移到组织。 在当今品牌建设既昂贵又至关重要的环境中,开源解决方案对使用它们的品牌构成直接风险。 尽管存在这种风险,许多大型和小型项目仍在为那些通过实施降低了复杂性指数的项目选择开源解决方案。 KDE开发团队与奥地利的一个小型项目经理合作开发尽可能好的代码的例子清楚地表明了在开源领域中的巨大优势。 虽然规范的作者可能不承担法律责任,但他们对自己产品的自豪感通常是促使他们发挥最大作用的绝佳动力。
参考资料
肯德里克(T.)(2015)。 识别和管理项目风险:防止项目失败的基本工具。 纽约:美国管理协会。
笔测试[个人面试]。 (2016年12月)。
项目管理研究所(PMI,2013)。 项目管理知识体系指南/ PMBOK指南(第5版)。 宾夕法尼亚州牛顿广场:项目管理研究所
翻译自: https://opensource.com/article/17/3/risks-open-source-project-management
开源管理项目管理