了解你的技术环境
这个系列是我对《七步掌握业务分析》的读书笔记，作者本人是极为资深的专家，也是IIBA协会的创立者之一。对业务分析领域感兴趣的人，如果不急着去考IIBA认证的话，强烈推荐大家先阅读本书。
第5章 了解你的技术环境
1. 为什么业务分析师要了解业务环境？
2. 业务分析师要了解哪些技术？
3. 如何与技术部门一起工作？
撇开互联网行业的产品经理不谈，在传统行业中，IT部门与业务部门总是隔着一堵技术沟通的墙。业务干系人无法理解技术和实现需求的原理，IT部门的技术专家也无法理解业务方的需求为什么都是紧急重要又经常变更。而业务分析师如果要扮演好这两方的桥梁工作，那么除了第4章作者所讲的——要理解业务环境意外，同样的，业务分析师也需要理解技术环境。
1. 为什么业务分析师要了解业务环境？
- 就像开头所说，业务分析师懂业务的同时也懂技术，如此能够提升需求到实现的速度。但要注意的是：业务分析师虽然理解技术，但是不要像技术人员一样讲话。这样的要求，在业务分析师与业务干系人沟通时，尤为重要。
2. 业务分析师要了解哪些技术？
业务分析师不需要对所有的技术都有了解或运用。但有些技术是每个业务分析专业人士都必须理解的：
- 软件开发/编程术语：了解你的开发人员的编程语言，学习目标导向的术语，如封装、继承和抽取。弄清楚大部分技术术语的定义和编程标准，因为这会影响项目时间的估算；
-
软件开发方法论：了解方法论和软件开发生命周期，如瀑布方法：
软件开发瀑布方法
如信息工程；
如IDEF：一种基于瀑布方法论，将信息（数据）作为关键需求元件，并使用模型展现需求的开发方法。IDEF中，IDEF0（功能建模），IDEF1（信息建模），IDEF1X（数据库建模）和IDEF3（流程描述捕获）被业务分析经常使用；
如联合应用设计：JAD，Joint Applicaiton Design，强调软件开发中的用户介入，不同的业务部门为了分享对信息的共同理解而聚集在一起，使用JAD引导需求的内容；
如快速应用开发：RAD，Rapid Application Development，增加了原型和加速开发的概念，是敏捷开发方法论的先驱；
如迭代和补充开发方法：认识回顾阶段的价值来补充缺失的需求，将项目划分成可以更快实施的更小的交付阶段；
如面向对象的设计和分析：在编程中引入可以重复使用的元件，使用封装概念，让软件元件更加独立；使用UML，统一建模语言作为需求沟通模板。而SOA，Service-oriented Architecture是另一种增加软件元件可复用性和可维护性的尝试；
如RUP：太过著名，不再赘述；
如敏捷开发方法；
或者一个机构的正式方法论，大多都是基于以上这些行业方法论在机构中调整适应后的开发方法。
下图描述了多数方法论没有详细解释业务分析方法的原因：
业务分析必须走在软件开发前面
大多数应用开发只专注于如何开发软件，这很正常，但前提是业务需求已经存在并得到了很好的理解。而这个前提往往没有实现就进入了软件开发阶段。这就是业务分析师需要完成的工作； - 技术架构：了解你的机构的标准和基本架构。如硬件、网络软件、操作系统、通信系统和软件包等；
- 操作系统：参与基础设施的变革以评估其对用户的影响；
- 计算机网络： 业务分析师必须能够欣赏网络技术的复杂性；计算机网络是由硬件、操作系统、网络软件和通信协议共同精密的组合而成；
-
数据管理： 熟悉数据管理和数据库的概念；知道数据管理方法和一些基本概念，如数据集成、概要/逻辑/物理数据建模、关系型数据库、数据字典、数据集市、数据库存取方法和数据安全等问题；业务分析师需要常问这些问题：
有关数据库的问题
- 软件可用性/人机接口设计：可用性设计应该包含在解决方案中；需要遵循以下原则：
- 任务的适宜性：软件功能根据特定任务而设计；
- 自我描述性：界面直观提示下一步用户做什么；
- 可控制性；
- 遵从用户期望：软件如用户期望并表现一致。
-
软件测试： 软件测试阶段的V模型：
软件测试的V模型
- 单元测试：开发人员完成；
- 集成测试：首先要单独测试需要集成的单元，并对较大的单元或者子系统进行测试；测试目标是发现系统一起工作的问题；
-
系统测试：系统测试是项目团队把产品交付给用户前验证产品的最后一个机会。目的是发现软件产品是否满足了用户的小于求。
系统级别的几种测试
- 回归测试：回归测试在过程中一直需要进行和改进，只要初步测试完成后有任何变化；
- 用户验收测试：即UAT；
- 实施后的用户评估
3. 如何与技术部门一起工作？
- 与开发人员沟通：有些开发人员富有创造力并愿意提出建议，业务分析师可以与这样的开发人员在一定范围内多征询对方意见。有些开发人员则只是对建立这个功能而感到满足，那么就不用给太多信息，只需要告诉对方准确的需求执行内容即可。
网友评论