1. 关于take risk的谚语,附带汉语,谢谢

许多谚语不会直接带有take risk的字，而是用不同的方式来比喻~譬如说：“A ship is always safe at the shore - but that is NOT what it is built for.” ― Albert Einstein靠在岸边的船总是安全的，但这并不是建造她的使命。

-阿尔伯特·爱因斯坦You'll always miss 100% of the shots you don't take. ~Wayne Gretzky你将百分之百地失去你未作出射门的比分。 -韦恩·格雷茨基To eat an egg, you must break the shell. ~Jamaican Proverb要吃蛋，你得先剥壳。

-牙买加谚语The torment of precautions often exceeds the dangers to be avoided. It is sometimes better to abandon one's self to destiny. ~Napoleon Bonaparte采取预防措施所带来的折磨，往往超出规避掉的危险。有时候，最好就是将一切丢给命运吧~ -拿破仑最后给你一句有实际这两个字的：If you don't take risks, you'll have a wasted soul. ~Drew Barrymore如果你不去冒险，你将有个无用（徒劳）的灵魂。

-德鲁·巴里摩尔。

2. 当今企业面临的IT风险是什么

更重要的是，每个人都需要理解可能会影响IT企业全部业务的几乎所有的风险。

风险可以分为四类，需要不同的缓解工具： 商业运营风险。一个评估要判断解决还是忽略某个具有挑战的威胁的风险。

分析挑战性的威胁可以帮助企业决定是否投入必要的资源来战胜威胁。 判断如何对来自非传统的资源的挑战性威胁做出合理反映是非常困难的。

例如，许多高技术企业都认为微软只不过是一群哈佛的退学生而已。他们因为没有理解到这个风险而付出了沉痛的代价。

适当的缓解工具是一个可以评估所有相关风险的良好的商业情况。对于新的商业机会来说，一个彻底的风险评估对于成功来说，就像是精确投入资金一样重要。

计划风险。对于通过的或者现有的计划来说，管理的关键集中在计划或者项目是否会在预算之内，高质量的按时交货。

风险可以通过有效的项目管理和定期监控来降低。 业务中断风险。

这种类型的风险影响了公司在困难的环境下继续运营的能力。场景从崩溃的服务器到被毁灭的建筑物，范围极其广泛。

在大多数情况中，一个崩溃的服务器对于某些人来说只引起了微小的问题。相反，一个被毁灭的建筑物可能让所有的企业运行都停顿下来了。

风险可以通过持续的运行（COOP）计划来降低，这个计划描述了业务如何在各种困难中继续运转。大多数企业在开始的时候都会为数据中心准备了IT灾难恢复计划（DRP）。

最终，DRP需要被扩宽，以便将重点集中在重新存储业务处理和发展为一个成熟的COOP计划上。 市场风险。

这种类型的风险可以划分为地域和特定行业的风险。地域风险包括战争，恐怖行动和瘟疫，还有国家和进口限制。

这些风险根据不同的国家、社会供应链的复杂度，以及该行业对于政治领导人的重要意义而有所区别。特定行业的风险也是多种多样。

例如，金融服务必须通过信用挤压，债务抵押义务的彻底崩溃，以及结构化投资手段来进行竞争。消费产品制造商可能会因为“flash mobs”通过社会网络倾销他们的产品而感到苦恼。

场景计划可以通过制定应对各种不可能的事件的反应来降低风险。最重要的是，它尝试发现先前未知的风险，因为最危险的风险通常是你没有识别的风险。

采购行为——特别是离岸——增加了各个种类的风险。对这些风险的评估必须要解决类似通讯、逻辑困难、供应商变化，以及知识产权等特殊的关键点。

在着手开始任何风险评估之前，弄清楚哪个类型的风险对于你的执行管理来说最为紧要。然后选择合适的风险降低工具来解决潜在的困难。

根据财务结果，风险的保单才会被批准。 彻底的风险评估可以为解决潜在威胁的结构化准备带来创造性的思维，这些创造性的思维对于成功至关重要。

正如那句流传已久的格言所说，“预先警告就是预先武装。

3. 中小企业面临的IT风险有哪些

风险可以分为四类，需要不同的缓解工具： 商业运营风险

一个评估要判断解决还是忽略某个具有挑战的威胁的风险。分析挑战性的威胁可以帮助企业决定是否投入必要的资源来战胜威胁。

适当的缓解工具是一个可以评估所有相关风险的良好的商业情况。对于新的商业机会来说，一个彻底的风险评估对于成功来说，就像是精确投入资金一样重要。

计划风险

对于通过的或者现有的计划来说，管理的关键集中在计划或者项目是否会在预算之内，高质量的按时交货。风险可以通过有效的项目管理和定期监控来降低。

业务中断风险

这种类型的风险影响了公司在困难的环境下继续运营的能力。场景从崩溃的服务器到被毁灭的建筑物，范围极其广泛。在大多数情况中，一个崩溃的服务器对于某些人来说只引起了微小的问题。相反，一个被毁灭的建筑物可能让所有的企业运行都停顿下来了。

市场风险

这种类型的风险可以划分为地域和特定行业的风险。地域风险包括战争，恐怖行动和瘟疫，还有国家和进口限制。这些风险根据不同的国家、社会供应链的复杂度，以及该行业对于政治领导人的重要意义而有所区别。特定行业的风险也是多种多样。例如，金融服务必须通过信用挤压，债务抵押义务的彻底崩溃，以及结构化投资手段来进行竞争。消费产品制造商可能会因为“flash mobs”通过社会网络倾销他们的产品而感到苦恼。

场景计划可以通过制定应对各种不可能的事件的反应来降低风险。最重要的是，它尝试发现先前未知的风险，因为最危险的风险通常是你没有识别的风险。

采购行为——特别是离岸——增加了各个种类的风险。对这些风险的评估必须要解决类似通讯、逻辑困难、供应商变化，以及知识产权等特殊的关键点。

在着手开始任何风险评估之前，弄清楚哪个类型的风险对于你的执行管理来说最为紧要。然后选择合适的风险降低工具来解决潜在的困难。根据财务结果，风险的保单才会被批准。

4. IT风险管理内容

IT项目中的风险管理 软件项目的风险无非体现在以下四个方面：需求、技术、成本和进度。

IT项目开发中常见的风险有如下几类： 需求风险 ①需求已经成为项目基准，但需求还在继续变化；②需求定义欠佳，而进一步的定义会扩展项目范畴；③添加额外的需求；④产品定义含混的部分比预期需要更多的时间；⑤在做需求中客户参与不够；⑥缺少有效的需求变化管理过程。 计划编制风险 ①计划、资源和产品定义全凭客户或上层领导口头指令，并且不完全一致；②计划是优化的，是"最佳状态"，但计划不现实，只能算是"期望状态"；③计划基于使用特定的小组成员，而那个特定的小组成员其实指望不上；④产品规模（代码行数、功能点、与前一产品规模的百分比）比估计的要大；⑤完成目标日期提前，但没有相应地调整产品范围或可用资源；⑥涉足不熟悉的产品领域，花费在设计和实现上的时间比预期的要多。

组织和管理风险 ①仅由管理层或市场人员进行技术决策，导致计划进度缓慢，计划时间延长；②低效的项目组结构降低生产率；③管理层审查 决策的周期比预期的时间长；④预算削减，打乱项目计划；⑤管理层作出了打击项目组织积极性的决定；⑥缺乏必要的规范，导至工作失误与重复工作；⑦非技术的第三方的工作（预算批准、设备采购批准、法律方面的审查、安全保证等）时间比预期的延长。 人员风险 ①作为先决条件的任务（如培训及其他项目）不能按时完成；②开发人员和管理层之间关系不佳，导致决策缓慢，影响全局；③缺乏激励措施，士气低下，降低了生产能力；④某些人员需要更多的时间适应还不熟悉的软件工具和环境；⑤项目后期加入新的开发人员，需进行培训并逐渐与现有成员沟通，从而使现有成员的工作效率降低；⑥由于项目组成员之间发生冲突，导致沟通不畅、设计欠佳、接口出现错误和额外的重复工作；⑦不适应工作的成员没有调离项目组，影响了项目组其他成员的积极性；⑧没有找到项目急需的具有特定技能的人。

开发环境风险 ①设施未及时到位；②设施虽到位，但不配套，如没有电话、网线、办公用品等；③设施拥挤、杂乱或者破损；④开发工具未及时到位；⑤开发工具不如期望的那样有效，开发人员需要时间创建工作环境或者切换新的工具；⑥新的开发工具的学习期比预期的长，内容繁多。 客户风险 ①客户对于最后交付的产品不满意，要求重新设计和重做；②客户的意见未被采纳，造成产品最终无法满足用户要求，因而必须重做；③客户对规划、原型和规格的审核 决策周期比预期的要长；④客户没有或不能参与规划、原型和规格阶段的审核，导致需求不稳定和产品生产周期的变更；⑤客户答复的时间（如回答或澄清与需求相关问题的时间）比预期长；⑥客户提供的组件质量欠佳，导致额外的测试、设计和集成工作，以及额外的客户关系管理工作。

产品风险 ①矫正质量低下的不可接受的产品，需要比预期更多的测试、设计和实现工作；②开发额外的不需要的功能（镀金），延长了计划进度；③严格要求与现有系统兼容，需要进行比预期更多的测试、设计和实现工作；④要求与其他系统或不受本项目组控制的系统相连，导致无法预料的设计、实现和测试工作；⑤在不熟悉或未经检验的软件和硬件环境中运行所产生的未预料到的问题；⑥开发一种全新的模块将比预期花费更长的时间；⑦依赖正在开发中的技术将延长计划进度。 设计和实现风险 ①设计质量低下，导致重复设计；②一些必要的功能无法使用现有的代码和库实现，开发人员必须使用新的库或者自行开发新的功能；③代码和库质量低下，导致需要进行额外的测试，修正错误，或重新制作；④过高估计了增强型工具对计划进度的节省量；⑤分别开发的模块无法有效集成，需要重新设计或制作。

过程风险 ①大量的纸面工作导致进程比预期的慢；②前期的质量保证行为不真实，导致后期的重复工作；③太不正规（缺乏对软件开发策略和标准的遵循），导致沟通不足，质量欠佳，甚至需重新开发；④过于正规（教条地坚持软件开发策略和标准），导致过多耗时于无用的工作；⑤向管理层撰写进程报告占用开发人员的时间比预期的多；⑥风险管理粗心，导致未能发现重大的项目风险。 软件项目风险管理模型 针对软件项目中的风险管理问题，不少专家、组织提出了自己的风险管理模型。

主要的风险管理模型有：Boehm模型，CRM模型和SERIM模型。 Barry Boehm模型 模型：RE=P(UO)*L(UO) 其中RE表示风险或者风险所造成的影响，P(UO)表示令人不满意的结果所发生的概率，L(UO)表示糟糕的结果会产生的破坏性的程度。

Boehm思想的核心是10大风险因素列表。针对每个风险因素，都给出了一系列的风险管理策略。

在实际操作时，Boehm以10大风险列表为依据，总结当前项目具体的风险因素，评估后进行计划和实施，在下一次定期召开的会议上再对这10大风险因素的解决情况进行总结，产生新的10大风险因素表，依此类推。 SEI的CRM(Continuous Risk Management)模型 SEI CRM模型的风险管理原则是：不断地评估可能造成恶劣后果的因素；决定最迫切需要处。