专业素养业务需求好好学习

《七步掌握业务分析》读书笔记

2017-05-22  本文已影响3356人  螃蟹

1.业务名词

业务分析：与干系人一起工作而采取的一系列任务和技术，其目的是为了理解一个机构的结构、策略和运营，并为帮助机构实现其目标推荐解决方案。
项目：一种临时性（具有确切的起止时间）的工作，它通过创造特殊的产品或服务带来收益变化或增加价值。
产品：产品是项目的结果。但不是所有项目都这样。一个业务流程改进项目可能以流程再造为结果，提升了效率但并没有开发什么新的产品。
解决方案：是任何可以“通过解决问题或允许一个机构利用机会来满足业务需要”的东西（BABOK）。它可能包括产品、现有系统、流程和组织结构的变化。
交付：在软件开发中被用来描述任何给别人的东西。交付需要交给或者展示给干系人，因为它对于干系人具有价值或者期待干系人据此采取行动。
机会：一系列使得做一些事情成为可能的事件。

2.业务分析内涵

3.业务分析师向谁汇报？

IT部门，独立的业务单元，独立的业务分析团队。

4.业务分析基础：

5.需求核心组件

人：可能包括机构内部和外部（称为代理或者参与者）的个人和部门；
信息：指数据；
流程：指实施业务的手册、自动执行的活动或者流程；
规则：指业务活动运行需要遵循的业务规定、指导原则、限制和策略。

QQ拼音截图未命名.png

6.与谁一起工作？

7.干系人分析

8.平衡干系人需求

在技术团队面前维护业务干系人的利益，并且确认业务需求得到满足。如果业务人员对于总结出来他们自己的需求不同意怎么办？这就需要业务分析师成为一个很强的协调人和共识建立者，甚至有时候是一个谈判专家。
为了企业利益整体最大化而平衡干系人的需求，首先，业务分析师必须理解企业的目标和战略，其次，业务分析师必须理解哪个干系人或团队在资助特定的项目，以及项目追求的特定目标。希望项目的目标与企业的目标是一致的，并且是支持企业的目标的。

9.会议

了解你的项目

1.商业论证开发（调研、逻辑推理和很强的沟通技能）

可行性分析和成本/收益分析
当你试图说服别人去采取行动时，就是在建立“用例”。
仔细考虑一个项目被批准之后会发生的积极结果，评估潜在的收益并对应可能花费的成本或努力来权衡收益，当收益超过成本，行动就将获得批准。展示各种想法和机会，并且评估相关的价值。

2.为什么决定投资一个项目？

战略规划

项目组合是指机构为了支持战略规划而确定，并进行优先排序之后的一组项目和项目集。
项目集是支持多个相关项目的持续的战略业务动因。项目集和项目组合是两种不同的项目逻辑编组方式。
项目组合管理和项目集管理是业务分析专业人士必须掌握的重要技能。

企业架构
战略规划过程中的工作之一就是建立企业架构。

沟通战略规划
大机构的小员工心态，是管理大型机构一个实实在在的挑战。

项目发起

项目经理和业务分析师一起，评估项目需求，同干系人一起交流理解项目目标，带领团队就要做的项目范围建立共识。

项目发起的要素：

确定业务范围（外部互动和高阶流程）

在项目发起阶段最重要的工作就是描述或者通过图示显示需要研究的业务范围（研究领域）。

QQ拼音截图未命名.png QQ拼音截图未命名.png

项目范围蔓延的合理理由：

总结

理解并解释项目重要性及为什么干系人会为项目的最终目标感到兴奋非常关键。了解一个项目的最终目标将明确分析工作的方向。当业务分析师了解了发起项目的原因，他们就会被要求去创建商业论证、成本/收益分析或者可行性研究。
无论是否在项目上，都要做到：

了解业务环境

了解企业

如何解读业务

什么是业务流程？

  很多机构使用“业务需求”来表示概要的业务目标。理解一项业务，必须理解它的工作，这个工作可以被定义为业务流程。
QQ拼音截图未命名.png

为什么召开促进会议？

解读业务的技巧

1. 了解公司的使命陈述？你的部门或业务单元的愿景是什么？
2. 看看公司网站传递了什么信息，是否容易理解和使用？
3. 看几个你的竞争对手的网站，你的公司和他们的有什么不同？
4. 如果是上市公司，找到最近的财务报告，熟悉下员工人数、总收入、利润率、市场份额等数据。注意阅读脚注。
5. 阅读项目涉及的业务领域的员工或系统流程手册。

第五章 了解你的技术环境

业务分析师要了解那些技术？

软件开发/编程术语

软件开发方法论

QQ拼音截图未命名.png

技术架构

操作系统

计算机网络

数据管理

业务分析师要经常问这些问题

软件可用性/人机界面设计

软件测试

支持测试专业人士验证他们的产品能否满足业务需求。
当一个项目的解决方案进入测试阶段时，业务分析师应该密切参与；当测试进行并发现缺陷时，业务分析师是找到缺陷根源并帮助找到方法纠正的最佳人选。
软件测试方法基于V模型。V模型中有很多变量，但是这个模型的基本概念是软件测试应该从项目开始就进行，越早越好。V模型推荐软件测试团队独立于开发团队，这种独立性将产生更加彻底和公正的产品质量评估。
在软件开发生命周期对应的测试阶段：单元测试、集成测试、系统测试和用户验收测试。

QQ拼音截图未命名.png

单元测试：通常由开发人员完成。

集成测试：首先要单独测试需要集成的单元，并对较大的单元或子系统进行测试。集成测试的目标是发现元件或者系统一起工作的问题，这些测试会验证软件架构设计。
通常来说，由于在开发过程中等待太久而没有进行足够的集成测试，是导致项目失败的一个主要原因。

系统测试：是项目团队把产品交给用户检查之前验证产品的最后一个机会。其目标是发现软件产品满足用户需求方面的问题，这些测试验证软件满足最初的需求。

QQ拼音截图未命名.png

回归测试：新的需求得到满足后，验证旧功能的完好，是重要的隐含需求。任何软件变更后，对于软件没有改变的功能重新测试，确定结果仍然正确。回归测试必须进行，软件非常复杂，一个微小的变化可能都会很容易破坏之前正常工作的部分。

用户验收测试（UAT）：通常当软件销售到开发机构以外时，用户验收测试被称为beta测试，并让用户在正式发布之前试验使用新的版本。

实施后的用户评估：是软件完全使用于业务领域之后对其效率的评估。实施后用户评估的目标是检验解决方案满足用户需求的程度，这项评估工作由业务分析师、项目经理或者质量保证分析师通过对用户的实际操作观察或者仔细设计的问题来实现。

敏捷项目的特性：

采用敏捷开发的好处：

业务分析必须先于软件分析完成


QQ拼音截图未命名.png

让IT架构师介入项目

第六章 了解你的分析技术

需求分析：从业务干系人那里引导需求、分析需求、把需求呈现给业务干系人评审、把需求呈现给方案团队执行。

分类和呈现需求

收集和管理需求

什么是需求？

需求是干系人为了解决某个问题或达到某个目的所需要的一个条件或能力。

为什么要需求分类？

为组织需求开发一个系统

推荐的分类系统

业务需求

业务需求是为了完成业务使命所需要的信息、业务活动、业务规则和外部交互的详细描述。
业务需求关注业务问题、业务需要和业务目标，不关心它们将被怎么解决和实现。
业务需求包括项目启动组件（目的陈述、目标、风险等）和数据、过程和业务规则等核心需求组件。它们共同组成了业务的全景图，或称为业务模型。

功能需求

功能需求描述了怎么完成工作。怎么实施业务规则？怎么与人、组织或系统沟通？当软件来支持业务需求时，功能需求描述了最终用户所看到的系统是“什么样子的”。
对于没有软件支持的业务需求，功能需求包括员工的流程、表格、工作流、策略文档和指南，这些描述了工作是怎么完成的。

非功能需求

方案需求一般被分为功能需求和非功能需求。某些方法论也把其称为补充需求、约束需求或服务质量需求。这些需求只在开发软件系统时创建，它们是软件的需求，不一定要和特定业务需要、功能或行为有直接关系。这些需求是系统为了满足用户需要必须满足的需求。例如：

技术需求

技术需求包括技术架构框架、数据库定义、业务规则引擎、编程逻辑、开发对象、应用系统接口、网络架构、安全组件和方案等许多技术规格说明书（技术需求）的详细描述。

核心需求组件

核心需求组件概述

数据（实体和属性）

数据时业务完成工作所使用的信息，它是构建系统的基本组件。

过程（用例）

过程是业务所完成的活动或工作。它们是构建系统的第二个基本组件。每个真正的过程都使用数据，每个重要数据都至少被一个过程所使用。

外部主体（角色）

外部主体是与所讨论的业务领域有交互的人、组织或系统。他们是客户、政府、厂家、供应商、其他部门或者外部软件硬件系统。

业务规则

业务规则是业务运转的约束或指南。
当你确认、命名并定义数据、过程和外部主体后，你可以使用相关的组件名来撰写业务规则。
核心需求的模板

QQ拼音截图未命名.png

核心需求组件：实体（数据）

实体关系图技术经常用于分析数据需求。该技术定义了三种数据组件：实体、属性和关系（业务规则）。
实体表的模板

QQ拼音截图未命名.png

核心需求组件：属性（数据）

属性的模板
属性是否具有唯一性：是否可用来查询、搜索并找出特定数据集合。客户号的唯一性。
属性是否强制：客户电子邮件是否是强制的？是否有多条业务规则来搜集数据。
属性是否重复：某个属性会多次出现吗？客户的多个电话号码？围绕重复属性引导需求。

QQ拼音截图未命名.png

核心需求组件：业务规则

   业务规则是主导工作完成形式的一个条件。分析师通过提问把规则明确地提炼出来并形成清晰的书面文字。

业务规则是一个关系需求组件，因为它们常常把其他需求组件联结到一起。当规则“超过50美元的订单可以免费送货”被提炼出来时，它就把几个其他需求组件联系起来了：数据（订单总量、送货费用）、过程（计算送货费用）和外部主体（客户、送货人）。
是否把业务规则看成“需求”并不重要，重要的是在业务分析中要引导、文档化并确认业务规则。它们必须包含在需求包或一个单独文档中。

找出业务规则：定义了业务的约束或规则，所以可把它们看成决策点。每条规则都帮业务干系人作出决策。规则要被清晰地表达出来，确保决策的一致性。（昨天那位售货员告诉我可以退回这个货品）
在需求研讨会中，常常出现两位业务干系人认识到他们对同一条规则有不同理解。把这些未知的差异展现出来时分析的价值，业务领域也因此随即改进了沟通并提高了一致性。
通常，业务规则实在围绕过程和数据的需求引导过程中暴露出来的。

分析技术和呈现格式

词汇表

强有力沟通的一个重要内容是一致地使用术语和惯用语。每次谈话都涉及对术语的共同理解。

工作流图（也称为流程图、UNL活动图和过程图）

工作流程把一个或多个业务过程的细节可视化地呈现出来，以澄清理解或提出过程改进建议。

工作流图

一种相对新颖的制作工作流图的方法叫做业务过程建模表示法（Business Process Modeling Notation）。
另一类工作流图是在过程改进六西格玛中出现的。六西格玛工作流图被称为SIPOC图：供应商（Supplier）、输入（Inputs）、过程（Process）、输出（Outputs）和客户（Customer）。用于表示体现整个业务交易的概要视图。SIPOC图中的过程可被分解成更详细的SIPOC图。六西格玛技术被用于找出并度量当前的业务活动，并进行根本原因分析，找出过程效率不高的部分。

Lean方法使用一种称为价值映射的方法来分析物资的流动和信息的流动，从而如何把产品或服务送到客户那里。它包括供应链的标准符号，关注过程改进和减小浪费。
工作流图也被用来表示实施和转换需求。
在员工流程手册、标准操作流程和上线计划中，除了文字描述外再增加可视化的图形表示，将有利于更好地沟通。

为什么使用工作流图？
工作流图非常灵活，可用不同标准和表示法来进行创建，所以在许多类型的项目中都是非常有用的。
业务改进项目非常依赖于于是和要是图。软件开发项目在业务需求层面（用户做什么）或功能需求层面（用户将怎么做）使用工作流图。这项技术在诸如并购和收购等企业级项目中也非常有用。当合并两个部门的时候，有必要分析两个部门的当前流程是什么，并做比较，这样才能描述共同活动并标志出差异。
项目团队也可以利用指标找出最佳实践，并建议合并后的未来流程（要是）。
此外，工作流图对于开发面向服务架构的组织也非常关键。

实体关系图
数据需求是用实体关系图(ERD)表示的，这种图及其附加的描述和细节共同组成了“数据模型”。这是业务领域或应用软件系统信息需求的一种可视化表达。这项技术使用了实体、属性和业务规则等核心需求组件，这项技术可帮助分析师涉及信息需求的提问。

实体关系图（Visio）

为什么要构建逻辑数据模型
最重要的原因是要确认用户和分析师对业务数据需求的理解，并确保软件开发满足业务需要。逻辑数据建模为分析师提供了一种做分析的结构化工具和技术。大多数领域专家可以把问题和可能的解决方案表达出来；但不幸的是，他们的问题和解决方案通常是基于目前系统的约束，而不是真正的业务需要。向业务人员询问以细致了解每项数据（属性）要求，理解并清晰地能表达业务的方方面面。这一过程使业务驱动系统设计。识别并细化出模型中的数据，就会进一步发现需求和问题，并且在软件设计之前的阶段就开始处理它们。
能帮助分析师从不同角度理解业务，帮助分析师发现重要的业务规则，并提取出能够发现更多隐含业务规则的详细问题。
当项目设计创建和修改数据库的时候，负责创建和维护IT数据的人更倾向于用ERD作为沟通工具。ERD更易于理解，它在分析师和数据库管理员之间建立沟通的共同语言。
逻辑数据模型还能促进数据复用和共享。

使用分解图进行业务过程建模
分解图在无需表现任何顺序和关系的情况下展示了核心业务流程。
分解分析把复杂系统分解成可管理的小块。因为这种图本身就遵循组织架构图的基本规则。被分解的原因在于，每个过程都可以被分解成为多个详细描述它的过程，把它们看成独立的任务将更有帮助。通过把各个组成部分独立开来，你就能洞见复杂业务流程和系统的核心组成。把这些组成内容看成独立的单元也有助于思考未来可以如何构造或者以不同方式实现这些过程。
确保在一张分解图（使用不同的标签）上只展示一种类型的组件。分解图常被用于战略规划，把公司的高层战略目标分解成低层的处室或部门目标。

分解图

用这种作图技术，以项目启动文档和对业务的基本理解作为依据做分解图，并给领域专家去修正。
分解图的每个过程都要继续用触发器、追踪器、相关业务规则和数据来描述。这些描述和图一起被称为“过程模型”或“业务模型”。
分解图技术有些关键规则可以保证其一致性和严谨性。

分解图的作图规则：

尽管有许多分解图制作规则，但对同一组需求来说，任何两位业务分析师都不可能做出同样的图来。每个分解图都可以表达不同观点并包含不同细节。
分解图有助于组织和结构化分析工作，它使团队以可视化方法在业务背景下观察每个过程，使小组一次只关注一个特定过程，它可帮助设定详细分析工作的边界。

为什么要构建分解图？
分解图是业务领域的一种图形化表示，它易于评审和修订。分解图可以是概要的也可以是详细的。它可用来设计任何类型的解决方案：软件、硬件、流程的或手工的。

用例图

用例是软件系统的一个目标。
用例图展示了主要用例以及所涉及的角色。用例图技术使用来展示功能需求的 - 软件系统是如何与它的用户（角色）交互的。它常用于表示系统的一个未来视图。这种图在显示项目或软件产品的范围时非常有用。
用例图是一种软件设计的工具，但它也可用于业务需求（非技术）层面。用例可以独立于技术命名和定义（商业论证）。用例图也可以用来表示需求和分析工作的范围。

用例图

用例描述
用例图中的每个用例都是用例子来描述的。每个用例描述都是一个功能需求交付物，包含特定软件功能的所有需求组件。用例描述还包括一系列顺序的步骤描述软件和角色应如何交互以实现业务目标。
在用例的步骤中，分析师通常会放一条主要路径（开心路径）和几条备用路径。备用路径显示了意外处理和错误条件。对每一步，分析师都描述角色将会采用的动作和系统的响应方式。这个描述包括详细数据需求以及适用的业务规则。

用例图

用例方法的主要缺点是：一个用例描述可能涉及几个需求组件（数据、过程、业务规则、外部实体），而不是分别描述它们。把组件写在一起很容易遗漏需求，而且需求组件很难被复用。信息系统中的大多数数据元素会被一个以上的过程使用。当一个数据元素出现在一个用例中时，它必须在所有用到它的用例中被重复定义。这既浪费时间，又可能出错。如果某个数据元素的特性发生改变，你必须在所有用到这个数据元素的用例中进行同样的修改。如果漏掉一个，你的需求就会不一致，而且软件开发就会出粗。

为什么使用用例图
用例图是UML（标准建模语言）的一部分。它是干系人评审的简单图，可以使业务干系人和技术干系人之间的沟通更加容易。
用例图的价值不像其在设计过程的讨论和决定那么重要。但可以与业务干系人，特别是决定者一起使用，因为它要求对人（角色）与系统合作方法作出决定。图中角色和用例之间简单的一根线可能会彻底改变业务人员的工作。它可能会使工作描述、职责发生变化，也可能会出现新的流程。

为什么要使用原型和仿真？
原型是一款出色的软件开发分析工具，因为它让业务干系人很容易能确定设计是否包括了所有必要的数据组件、标签和描述是否有意义，还能针对屏幕上各条目的位置及其美观方面给出特别建议。原型对于IT开发人员来说也是一种出色的需求呈现交互物，因为通过他们呢能够看出到底构建了什么样的系统。

事件建模

识别并分析事件是另外一个很有价值的需求角度。事件是指在业务领域外发生的二业务领域必须响应的事情。

用户故事

用户故事是一种相对较新的需求技术，源自用例技术。一个用户故事是对软件需要完成的某种事情的描述。敏捷软件开发和极限编程经常采用用户故事技术来快速获取需求。故事经常是非正式地写在索引卡上，在开发过程中也不去维护它们。它们不是用来获取详细需求的，只是提供对软件的优先级和估算上的整体需求，更详细的需求是由开发人员和用户在构建软件时讨论的。

可回溯性指标

该分析技术，通过找出各个需求组件之间的关系，以及该关系的所有特征，分析师能够找出遗漏或不一致的内容。几乎任何两个需求组件都可以联系起来，根据项目类型和风险决定什么样的链接是有用的。
当业务需求详细到功能和技术需求时，就要对它们进行回溯。当业务干系人描述了一个核心业务过程，比如“记录订单”，团队也设计出一个数据输入页面让客户输入订单信息的时候，业务需求“记录订单”就被连接到该页面。最终的解决方案的每个组件都可能被回溯到一个业务需求上。
考虑到可回溯性有助于开发出完整的需求。当你识别出一个新的需求时，可以针对可能的相关组件提出问题。


回溯矩阵

差距分析

差距分析用来发现在软件或手工流程中的特定差距。差距分析使用结构化的文档格式比较两个或多个系统。差距分析的常用方法包括：

差距分析

数据流图是最早的分析技术图，主要用于极其复杂的系统分析。现在用多个分解图，模块化代替。

业务分析可选择一种技术来分析和理解，选择另一种技术向业务干系人呈现需求。

项目矩阵的交付物 受众矩阵的交付物

业务当前状态与未来状态的分析

在引导、分析和记录需求的时候，业务分析师必须随时意识到当前业务环境的状态。
有两种状态：业务的当前状态，即“as is”； 还有一个是业务潜在的未来状态，即“to be”。
业务分析师对当前状态是否有一个清晰、完整的描述？没有。那需要提出更多问题：

打包需求

应该怎样正式地用文档记录需求？

许多组织不愿意在需求上花时间的主要原因，是在太多的项目分析师做了一大堆没人看的文档。敏捷开发方法就是对这种正式文档的强烈反击。
敏捷方法对于软件开发的吸引力源自一个错误概念，那就是认为无需用文档记录需求。
业务分析师常常要在理解复杂过程、清晰沟通和保证时间之间寻求平衡。

理解和沟通

什么是需求包？

在传统方法论中，需求包是一种组织并呈现所有需求信息的方式。在需求包被呈现给发起人和领域专家并获得批准后，开发团队才开始开发系统。

第七章 提升你的价值

业务分析职业最精彩的部分，就是能通过学习新技术和不断提升技能，为自己的组织带来更多价值。

打好基础

技能：开始
拼图：在不知从何处入手时，你能做的事情就是开始做点什么！

技能：记笔记
提问并准确记录下干系人的回答。

在需求引导阶段记笔记非常关键，有两个原因：
第一，高效的业务分析师能有效地利用他们干系人的时间，除非是出于澄清的目的，否则不恩能够让干系人重复他们的需求。
第二，在与干系人会谈时不记笔记显得很无礼。

技术：头脑风暴
该技术能帮助与会人跳出目前的工作流程而产生创新想法而被广泛采用。在需要对现有流程合理化、解决复杂问题或开拓新的商业机会时，人们往往会采用头脑风暴技术。鼓励小组成员贡献所有未经过滤的想法。

技能：与复杂细节共舞
业务分析师必须能够准确地引导并文档化这些细节。耐心地记录详细的需求是项目成功的关键。

时间管理

技能：理解项目的本质
对项任务进行优先级排序。

技能：要事第一
组织总是把最重要和最难做的工作分配给最有价值的员工和顾问。

技术：理解80/20规则
业务分析师用20%的时间引导80%的需求，其他80%的分析时间用来引导另外20%的需求。

技术：时间盒（Timeboxing）
时间盒技术认为，某些类型的任务是难以完成的，因为它们的最终交付物的状态是主观的。这项技术被用于时间有限而交付物可谈判的软件开发中。时间盒给开发人员一段时间来完成给定的任务，目标是在给定的时间内尽可能多地完成工作。
是一项比较难的技术，因为它强迫分析师把最重要的工作找出来。
该技术对理想主义和有过度承诺倾向的人非常有价值。

构建关系和提高沟通技能

技能：建立紧密的关系
建立关系是成功的业务分析师的一项重要技能。

技能：问正确的问题
一项重要的分析技能是设计出好问题。一位业务分析专业人士永远在设计寻求答案的问题。
开始在与干系人的访谈中，要提出宽泛的问题以引导能描绘整体概念的回答，然后再采用细节性、澄清概念性的问题。

业务分析大师会围绕每个流程、每项数据、每条业务规则提出详细的问题，有些问题可能略微超出范围，但业务分析师要确保没有遗漏。

这些问题包括：

-我怎么才能引导这个信息？

来自组织的不同部门、处于不同级别的干系人都会提供不同的信息，重要的是向正确的人问正确的问题，不要让干系人觉得自己无能或无知。
最好向高级干系人“为什么”的问题，高层管理者能看的更全面，他们知道组织决策的原因。中层能回答“谁在什么地方做什么”及“每项活动与其他工作的目标是什么”等问题。业务工作人员能够回到“怎么做”及“某项活动与其他工作的关系”等特定的细节问题。

技能：主动聆听
聆听是在对话中一项主动的、有意识的决定。业务分析师必须决定去聆听并且在聆听的过程中积极地参与。
优秀的聆听者能够帮助解决纷争和冲突，他们能在谈话中找到各方的共同点，并把各方的观点清晰地表达出来。
研究表明，一条信息55%的内容是通过非口头的方式传递的。要有意识地观察人们的身体语言和面部表情。
通过声音和身体的语言表达出你的兴趣和好奇。

聆听的障碍
有许多聆听的障碍。这些障碍使聆听者无法准确地理解对方所表达的信息。找出你的障碍并尝试克服。
有一种障碍使过滤器。每个人的大脑通过自童年开始形成的过滤器来处理所有新的信息。你可能不会意识到影响你聆听能力的过滤器。
过滤器来自偏见、信仰、价值观、态度、过去的经历、兴趣和恐惧。
了解自己的过滤器形成的原因。
聆听的另一个障碍是缺乏兴趣。
先入为主也是一种聆听的障碍。对于熟悉的话题或人，人们往往有先入为主的观念和想法，倾向于有选择地听到自己希望听到的内容，过滤掉那些不符合你预期的内容。

聆听需求

需求引导用词

技能：出色的呈现
经常要正式或非正式地向干系人呈现信息：

技能：促进协调和建立共识
业务分析师知道应该怎么提出问题、讨论答案、提出建议，他们在协调或在使用户更容易地解释他们的要求。

仔细聆听、诠释不明晰的话语、提出问题澄清、帮助人们达成共识
为了提高促进协调技能，要首先关注自己的主动聆听技能。其次，提高自己的口头演讲技能。准确而简洁地说话，直接而诚实。

技能：组织高效会议
业务分析师常常要计划和组织会议。
当确定会议是实现目标的恰当手段时，要花一点时间计划会议。选择合适的参会人、做一个会议日程、高效地开会，并在会后跟踪后续工作。

会议日程
应该在会议前准备会议日程并发给参会人。

组织成功会议的小贴士
会议领导者应该不断提醒并专注于会议的成功。

后续跟踪和会议纪要
以文字的方式记录了会议中所做额决策并对会议达成的协议确认达成一致的理解。尽快把这些内容发给参会人，从而验证每个人理解并同意会议的工作成果。

组织需求评审

技术：根本原因分析
人们往往在没有仔细研究问题时就提出不恰当的问题解决方案。
鱼骨图是一种结构化根本原因分析的可视化技术。
另一种根本原因分析的技术是5个为什么。为什么问题是工具箱中最有价值的工具了。它被用来帮助挖掘问题或机会的根本原因或底层原因。

鱼骨图-根本原因分析

技术：机智的违抗
是指能够在不影响个人职业或关系的情况下与组织的决定有不同意见。
机智违抗的三个组件：1.收集事实；2.毫无感情色彩地呈现事实；3.愿意接受决定并继续向前。
另一个非常有用的组件是有一个替代计划。

规划业务分析

一旦了解了项目发起和资金投入的原因后，你就要规划自己的那部分工作。
技术：映射项目
映射项目从两个维度帮助分析师决定所需要的分析工作：什么和怎么及现状和将来。

映射项目

第一维度（行）代表业务领域的什么和怎么。
什么指的是业务需求：

第二个维度（列）代表业务的当前和未来的状态。

项目映射

技能：计划你的工作
业务规划的第一步是了解项目。回顾所有现存项目文档，对工作有一个初步的理解。根据你的研究，询问项目经理和发起人一些问题来评估项目当前的状态。

业务规划框架

技术：评估业务影响
业务影响是一种衡量，它说明这个项目对业务干系人及其工作的关键程度。

决定业务影响的因素

技术：干系人分析
是业务分析规划框架的第二块工作

技能：设计业务分析任务清单

头脑风暴确定有关需要做的事：

上一篇 下一篇

猜你喜欢

热点阅读