读数据架构知识体系指南19人员和流程(下)

1. 项目失败的原因

1.1. 让高管认为BI很容易

• 1.1.1. 一些高管有非常不切实际的想法

• 1.1.2. 经常迫使项目经理采用不切实际的时间表和关键点，这会导致项目失败

• 1.1.3. 必须培训高管

• 1.1.3.1. 帮助他们理解流程，正确构建和测试解决方案所需的时

1.2. 使用错误的技术

• 1.2.1. 当公司未能了解所有可用的数据解决方案产品及其案例时，可能会导致其最终使用了错误的产品

• 1.2.2. 决策者必须投入时间了解所有可能的工具，然后再为项目选择正确的工具

• 1.2.3. 建议成立几个委员会，每个委员会专注于研究特定的产品组，如ETL、分析或报告工具

1.3. 收集过多的业务需求

• 1.3.1. 应只花几周时间收集需求，收集足够让开发人员开始编码的内容，然后在编码的同时继续收集需求

1.4. 收集的业务需求太少

• 1.4.1. 一些项目团队几乎在最终用户需求收集上不花时间，有些则让开发人员猜测最终用户想要什么

• 1.4.2. 采用迭代方法进行项目开发，就可以避免这个问题

• 1.4.2.1. 构建解决方案的部分，然后重新审视设计和规划阶段，根据反馈和不断发展的需求在持续循环中进行调整

1.5. 在验证内容之前就展示报告

• 1.5.1. 向最终用户展示正在构建新的解决方案的报告，而其中包含不正确的数字，用户的第一印象就会很差

• 1.5.2. 当用户对报告失去信心时，很难重新赢得他们的信任

• 1.5.3. 公司并不能总是花时间来确保报告中的一切都是正确的，所以结果可能是一个重大的挫折

• 1.5.4. 要有一个严格的QA流程，包括将新的解决方案中的报告总数与已知有效的生产报告进行比较

1.6. 雇用经验不足的咨询公司

• 1.6.1. 大多数公司没有时间或专业知识自己构建数据仓库解决方案，所以他们雇用顾问来构建

• 1.6.2. 要选择正确的咨询公司

• 1.6.2.1. 可能是专家，但却是在完全不同类型的项目中

• 1.6.2.2. 在试图赢得用户业务情况下，咨询公司有时会让有相关经验的专家参与，但一旦项目开始就换成经验较少的人员

1.7. 雇用将开发外包给离岸工作者的咨询公司

• 1.7.1. 使用离岸开发人员来节省成本，但这可能导致出现问题

• 1.7.2. 时差可能使会议难以进行，语言障碍可能使正确传达需求变得困难，而且工作质量可能较低

• 1.7.3. 提出问题以确保咨询公司不会将用户的项目转交给离岸团队，避免此类事情发生

1.8. 将项目所有权移交给顾问

• 1.8.1. 将项目全权交给咨询公司很常见，让他们不仅开发项目，而且完全管理项目

• 1.8.1.1. 项目可能成为一个“黑盒”

• 1.8.2. 确保用户得到项目进展的完整、真实情况。状态报告是不够的，要安排项目经理来密切关注项目进展

1.9. 忽视将知识传递回组织的需求

• 1.9.1. 使用了咨询公司，但却不希望他们进驻做项目，离开时也不讲清给用户所构建的内容，那么则不必再次雇用咨询公司，但自身需要有完成修复错误和完成升级的能力

• 1.9.2. 让员工在顾问构建解决方案时就与顾问专家们一起工作，即使只是几周，也要熟悉项目和流程

1.10. 项目中途削减预算

• 1.10.1. 规划不良的项目有时会用提前花完预算，在接近项目结束时就耗尽经费

• 1.10.2. 不要在这些领域削减预算

• 1.10.2.1. 解雇开发人员、测试人员、程序经理或DBA

• 1.10.2.2. 削减解决方案的硬件

• 1.10.2.3. 减少最终用户对新系统的培训等

• 1.10.3. 要么增加预算，要么在不太关键的领域削减预算，以避免这个隐患

1.11. 先确定截止日期，项目倒推进行

• 1.11.1. 严格的关注截止日期可能会损害项目质量

• 1.11.2. 匆忙完成项目复杂阶段的工作可能会导致出错和效率低下

• 1.11.3. 严格的时间表也可能限制项目的基本开发和探索阶段，可能导致系统不能满足组织的实际需求

• 1.11.4. 僵化的结束日期使得项目难以适应进展中出现的意外变化或新要求，这可能会导致延迟或交付不完整

• 1.11.5. 不灵活的结束日期可能限制与必要的利益相关者的合作，导致产品不能充分服务于所有用户

• 1.11.6. 让截止日期和时间表变得灵活

• 1.11.6.1. 接受随着新情况出现可能需要改变时间表的情况

1.12. 构建数据仓库来反映源数据而不是业务需求

• 1.12.1. 源数据来自业务系统，这些系统通常不是为综合数据分析或商业智能任务而设计的，这可能限制MDW的可用性

1.13. 向终端用户展示的解决方案存在响应慢或其他性能问题

• 1.13.1. 给终端用户展示一个生成报告缓慢、商业智能仪表盘或查询需求响应迟钝的解决方案，一定会被投诉—尤其是如果之前的解决方案做得较快

• 1.13.2. 不要等到投诉才进行性能改进

• 1.13.3. 评估迁移报告的响应时间，并调整新报告至少达到相同水平

1.14. 过度设计（或设计不足）的数据架构

• 1.14.1. 如果在设计解决方案的数据架构上花费太少时间，就冒着构建一个无法处理特定大小、类型或速度的数据源的风险：缺乏可扩展性、性能差，或带来安全风险

• 1.14.2. 过多的架构设计可能导致过度复杂、缺乏灵活性、分析瘫痪和成本增加

1.15. IT和业务领域之间的沟通不畅

• 1.15.1. 两个关键群体经常使用不同的语言，有不同的优先事项，从不同的角度看问题，所以他们经常存在分歧

• 1.15.2. IT人员通常关注技术方面和系统实施，而业务专业人员则专注于战略目标和盈利能力

• 1.15.3. 沟通不畅可能导致关键问题

• 1.15.4. 依赖于这两个群体的协作

• 1.15.4.1. IT必须理解业务需求，而业务团队必须理解IT基础设施的潜力和局限性

• 1.15.4.2. 培养开放对话和相互尊重的文化至关重要

• 1.15.4.3. 业务分析师等角色可以通过将业务需求转化为技术规范来弥合这个差距

• 1.15.5. 两个群体应该定期会面，进行透明的讨论，并清晰地记录需求

• 1.15.6. 有效的协作可以对项目的成功与否产生重大影响

2. 成功的技巧

2.1. 不要吝啬投资

• 2.1.1. 有时花两倍的时间和两倍的钱来构建一个能提供50倍于旧解决方案价值的解决方案会更好

• 2.1.2. 强调投入时间和资源来构建支持高级分析能力的高质量、强大、可扩展数据解决方案的长期价值

• 2.1.3. 对于培养鼓励创新和运营效率的数据驱动文化至关重要

• 2.1.4. 匆忙的项目或节省资源可能导致系统缺陷、不准确的结果和合规问题

• 2.1.5. 处理持续的维护或彻底改造有缺陷的系统可能比一开始就投资最好的工具更昂贵

• 2.1.6. 前期投入更多的时间和资源、更好的规划、更好的人员和更好的工具，所有这些都有助于创建可靠、准确和可扩展的系统

• 2.1.7. 在团队中获得正确的专业知识和技术知识可能意味着要支付更多的工资

• 2.1.8. 需要项目中至少有一个精通数据架构的人

• 2.1.9. 如果把它留给非专业人士进行，最终的解决方案很可能会偏离目标，导致性能不佳、无法从某些源摄取数据、结果不正确和其他问题

• 2.1.10. 让了解自己在做什么的人参与项目

• 2.1.11. 适用于生成报告工具和所使用的任何其他工具；确保有了解其功能和特性的人员，这样就能充分利用投资

• 2.1.12. 初始成本和时间投资将被可观的长期投资回报所抵消，这包括降低长期运营成本以及战略优势和有价值的见解

2.2. 让用户参与

• 2.2.1. 尽早让终端用户参与，这样他们就会与开发者是合作关系而不是对

• 2.2.2. 解决方案需要用户使用不熟悉的新技术（如报告工具）​，培训用户

• 2.2.3. 参加培训是用户为新解决方案做准备甚至学习更快、更好地完成工作的好方法

• 2.2.4. 要快速和频繁地显示成果

• 2.2.4.1. 不要让几个月的项目工作过去而不向用户和利益相关者展示任何成果

• 2.2.4.2. 使用交互式、敏捷的方法进行项目交付，频繁发布

• 2.2.4.3. 将项目分成几个阶段，争取快速获胜，展示可以推广的大量好处

2.3. 为新报告和仪表盘增加价值

• 2.3.1. 创建带有KPI的用户以前没见过的仪表盘，向他们展示可能的艺术和获得数据洞察的新方法

2.4. 要求终端用户构建原型

• 2.4.1. 大多数终端用户看到和使用数据解决方案的唯一途径是报告工具

• 2.4.2. 确保用户熟悉大部分的功能

• 2.4.3. 让终端用户参与原型创建在这其中起着关键作用

• 2.4.4. 在确定项目的业务需求并培训人员使用报告工具时，让终端用户构建原型

• 2.4.5. 通过亲自动手制作这种原型，用户可以更好地理解新报告和仪表板的增强功能

• 2.4.6. 拥有一个可运行的原型是终端用户亲身体验新解决方案的好方法，同时这还可以提供附加值并带来新提升

2.5. 寻找项目支持者/赞助商

• 2.5.1. 项目支持者是赞同和倡导项目的高级管理人员或有影响力的人员

• 2.5.2. 作为内部倡导者，保证了传达构建良好的数据架构的长期利益，包括增强决策、提高运营效率和战略规划

• 2.5.3. 在获取必要资源和资金方面发挥着重要作用

• 2.5.3.1. 鉴于数据项目需要在技术、人力资源和时间等方面进行大量投资，所以能够调动这些资源的项目支持者可能至关重要

• 2.5.4. 项目支持者在促进不同利益部门之间的跨职能协作方面发挥着重要作用，使每个人的优先事项与共同的项目目标保持一致

• 2.5.4.1. 协助员工参与新系统和流程，并缓解此过程中员工的担忧，从而来降低变革的阻力

• 2.5.4.2. 有助于确保更顺利的过渡并增加项目成功的可能性

2.6. 制订一个旨在实现80%效率的项目计划

• 2.6.1. 确保每个人都能以最佳状态参与其中

• 2.6.2. 分工不同于项目支持者或赞助商，后者从更高层面提供战略支持和倡导，项目经理更多地“在战壕里”​，协调任务、时间表和资源

• 2.6.3. 每个团队成员应该将大约80%的工作时间用于项目

• 2.6.4. 保留其他20%用于休假或病假、非项目会议、学习等

• 2.6.5. 意味着确保合适的人执行合适的任务，并且每个人在项目开始前都接受了培训

• 2.6.6. 效率低于80%可能导致错过最后期限和成本超支