客户分析

随着国内利率市场化加快推进、经济增速放缓、国民收入和财富逐步上升，零售业务对银行收入及利润的贡献日益见长，科学有效地引领零售业务持续增长已成为国内领先银行的首要任务。然而，零售客户的需求日趋复杂和个性化，市场竞争愈加激烈。在此背景下，应该有效利用大数据技术将决策方从“业务经验驱动”向“数据量化驱动”转型，决策模式的变化将成为各家银行互争雄长的制胜关键。 最近几年银行零售业务受到了多方面环境变化和监管调整带来的挑战，同时也带来了大量的发展机遇。 在利率市场化过程中，我国的商业银行零售业务面临着盈利能力的挑战。利率市场化使得银行利差收窄，盈利能力下降。各家银行业绩均面临着盈利增速放缓的局面。金融市场化改革的推进要求零售银行改变依靠存款利差的传统经营模式，进一步提升产品创新和风险定价能力。另一方面，利率市场化也为零售银行提升内部经营管理能力、促进差异化竞争、提升服务和创新水平带来了前所未有的机遇。 当下，我国商业银行对零售业务投入了较高的热情，有着多重原因：一是我国经济环境进入到高质量发展阶段，消费成为经济增长第一驱动力，推动银行零售业务发展；二是随着金融严监管的持续推进，银行公司业务和同业业务的监管要求不断提升，部分业务萎缩，零售业务成为新的增长点；三是利差收窄、金融脱媒使得银行经营压力加大，银行零售业务发展成为必然趋势。此外，互联网金融业务的爆发重构了银行零售市场

三年前给客户做的一个物料采购系统，客户因为价格问题搁置，今天把它拿出来分享，以分析改善方法。 项目名称: Item Purchasing System /Item Purchasing Request 系统功能: 1) 配置 Configruation 公司和组织架构管理 Organization Manitenance： 目前的例子 三个公司(暂定命名为Shenzhen, Singpore, Vietnam, 中文：深圳，新加坡，越南)，三个公司下面各有多个职能部门， 申请采购物料的就是这些部门，要知道物料是由拿个公司的哪个部门申请的，所以，需要管理公司和部门，可以自定义增加公司和部门 用户管理 User Maintenance: 管理物料采购申请的用户，及权限 物料管理 Material Entry 为规范申请的物料，也为了数据报表分析，需要在这里先建立物料，然后申请采购时，从这里选择物料。 这个功能为会以后的维护和分析报表提供很大的方便。 财务: Cost Center ,Ledger Account 与财务的接口，成本计算，货币 设置 Page Setup 一些页面的风格设定，显示参数 2) 采购 Purchase 流程：采购申请=》采购申请审批=》采购定单=》采购定单审批 在今天来看，采购定单审批这一步骤是多余的，已经形成采购订单，不需要批核。

对大多数人来说，若要建一幢数百万元的房子，他一定会与建房者详细讨论各种细节，他们都明白完工以后的修改会造成损失，以及变更细节的危害性。然而，涉及到软件开发，人们却变得“大大咧咧”起来。软件项目中百分之四十至百分之六十的问题都是在需求分析阶段埋下的“祸根” (Leffingwell 1997) 。可许多组织仍在那些基本的项目功能上采用一些不合规范的方法，这样导致的后果便是一条鸿沟 ( 期望差异 ) —开发者开发的与用户所想得到的软件存在着巨大期望差异。 在软件工程中，所有的风险承担者 (stakeholder)( 这个词很有意思，原义是赌金保管者。我看过很多的翻译，有翻译成涉众的，也有的翻译成参与者的，但是我想他的主要意思就是和这个项目有密切相关利益的人 ) 都感兴趣的就是需求分析阶段。这些风险承担者包括客户、用户、业务或需求分析员 ( 负责收集客户需求并编写文档，以及负责客户与开发机构之间联系沟通的人 ) 、开发人员、测试人员、用户文档编写者、项目管理者和客户管理者。这部分工作若处理好了，能开发出很出色的产品，同时会使客户感到满意，开发者也倍感满足、充实。若处理不好，则会导致误解、挫折、障碍以及潜在质量和业务价值上的威胁。因为需求分析奠定了软件工程和项目管理的基础，所以所有风险承担者最好是采用有效的需求分析过程。软件需求的定义 IEEE 软件工程标准词汇表 (1997 年 )

读软件需求分析首先明确了软件需求包含的三个不同层次，业务需求即组织机构或客户的需求目标，用户需求即用户使用产品必须要完成的任务，功能需求即开发人员需要实现的软件功能。从需求的定义上我们可以知道需求关注的是究竟想开发什么与设计细节实现细节项目规划信息或者测试信息无关 不重视需求过程会给项目带来极大风险，所以在需求过程中我们要注意避免以下几种情况，无足够用户参与，用户需求不断扩展，用户需求不明确或者说模棱两可，不必要的特性即为软件画蛇添足，过于精简的规格说明，忽略了用户分类，不准确的计划，而高质量的需求过程要求产品开发过程中的通力合作同时充分了解其市场，因此要想完成一份优秀的需求就必须具备完整性（功能完整），正确性（准确陈述其功能），可行性，必要性（每项需求都硬把客户真正需要的和最终系统），划分优先级，无二义性（只能有一个明确统一的解释），可验证性等特性。同时需求规格说明也需具备完整性，一致性，可修改性，可跟踪性（即每项软件需求与它的根源和设计元素，源代码，测试用例之间建立起链接链） 再进行软件需求分析时要清楚谁是客户，谁是用户，分清楚业务需求和用户需求。客户有义务说明软件的业务需求，任何其他的说明都应该遵从业务需求的规定，而用户需求则必须从试用产品的用户处收集，业务需求来自风险承担者，用户需求则来自产品的真正使用操作者。对于客户而言客户有权利要求分析人员使用符合客户语言习惯的表达

先说项目开发过程中团队人员的分工协作。 　　 一、人员安排 　　毕业至今的大部分项目都是独立完成，虽然也有和其他同事协作的时候，但自认为对团队协作的了解和认知都还有所欠缺。很清楚团队协作的重要性，但尚未有很好的机会在相对成熟的团队中锻炼实践。 　　先抛开 软件开发 团队中人员的具体安排不讲，单纯的看软件开发工作的分工。在上面设想的开发架构中，宏观上可将一个项目划分为前端、程序、 数据库 三个模块。由此可推导出团队中需要的成员：美工、程序员和项目经理。 　　认为理想的软件开发团队由四个专业技能过硬的成员组成：一个美工，熟悉UI的设计并具备将效果图转换成前端页面的能力，也就是得同时精通PhotoShop、HTML、CSS、jQuery等前端知识；一个程序员，熟练掌握代码的编写重构；一个项目经理，具备 需求分析 的能力、数据库设计维护的能力、架构设计的能力、程序编写的能力、前端样式脚本编写的能力，最重要的是对业务流程有精准的把握；一个部门经理，和前三位不一样，部门经理只具备领导能力即可，他是兼职，不需要把全部时间投入到团队中。 　　大部分中小型项目可以由这样的四人团队完成，可如果项目较大，已经大大超出了四个人可完成的工作量，可以再加一个前端开发人员。也就是说两个前端开发者，一个负责UI设计，做出完整的效果图，这个人的设计功底应该比较强；一个负责将效果图转换成页面，并完成样式、脚本等的编写

说明： 《火球——UML大战需求分析》是我撰写的一本关于需求分析及UML方面的书，我将会在CSDN上为大家分享前面几章的内容，总字数在几万以上，图片有数十张。欢迎你按文章的序号顺序阅读，谢谢！本书已经在各大网上书城及书店销售，欢迎你的关注。 ------------------------------------------------------------------------------------------------------------------------------ 第2章 耗尽脑汁的需求分析工作 摘要 ：怎么又变了？当初就应该让客户书面签字 确认 ！你可能会经常发这样的牢骚，可是就算客户书面确认，客户还是会“赖账”的！ 软件 项目 的其中一项不变真理：人是会死的， 需求 是会变的！本章将会和你一起来体验软件 需求分析 工作的风风雨雨，找出需求分析工作的根本之道，了解 UML 如何帮助我们提升需求分析的水平。 2.2 持续进化的客户需求 你可能曾遇到过这样的情况：客户今天想要一个苹果，明天改变主意要一条香蕉，但后天突然又说还是苹果好，到最后他想要一个西瓜！遇到这样的情况，你会抱怨客户吗？你会后悔当初没有让客户签字 确认 吗？ 楚国有人坐船渡河时，不慎把剑掉入江中，他在舟上刻下记号，说：“这是我把剑掉下的地方。”当舟停驶时，他才沿着记号跳入河中找剑，遍寻不获

摘要 ：怎么又变了？当初就应该让客户书面签字 确认 ！你可能会经常发这样的牢骚，可是就算客户书面确认，客户还是会“赖账”的！ 软件 项目的其中一项不变真理：人是会死的，需求是会变的！本章将会和你一起来体验软件 需求分析 工作的风风雨雨，找出需求分析工作的根本之道，了解 UML 如何帮助我们提升需求分析的水平。 （本书已经发售） 作者： 张传波 网名：Fireball（火球） www.umlonline.org 2.1 需求分析面面观 客户需要的是一把梯子，系统分析员了解到的是一张凳子，开发人员做出来的是一张桌子，测试人员以为是一张椅子……很多角色参与项目工作，每种角色会从自身角色出发来理解需求，以致各种角色对需求的理解会不太一样。下表对各种角色的特点进行了分析： 表 2.1 各种角色的特点 另外要说明的是： 客户一方的总倾向是：自己少花钱，让软件公司多做事情。 而软件公司一方的总倾向是：多拿客户的钱，尽量少做事情。 影响各人对需求理解的主要因素有两方面：一方面是角色的思考倾向，上表反应了这点；另外一方面是人的需求分析能力，能力越强的人越能把握需求，本书重点讲解的内容就是如何 活用UML 来提升需求分析能力。 而更“离谱”的是：每个人嘴巴上说的需求和心目中的需求总是有差异的，所谓的“词不达意”，受表达能力所限，不是每个人都能完整准确地表达自己的想法；有时候客户今天想要这个

摘要 ：怎么又变了？当初就应该让客户书面签字 确认 ！你可能会经常发这样的牢骚，可是就算客户书面确认，客户还是会“赖账”的！ 软件 项目的其中一项不变真理：人是会死的，需求是会变的！本章将会和你一起来体验软件 需求分析 工作的风风雨雨，找出需求分析工作的根本之道，了解 UML 如何帮助我们提升需求分析的水平。 作者： 张传波 www.umlonline.org www.umlonline.org/school/ 本文来自新书《活用UML——需求分析高手》的第二章。 第一章已经在博客园发布，文章名字叫：UML一篇文章就学通 文章链接： http://www.cnblogs.com/umlonline/archive/2011/07/12/2104626.html 以下是正文： 2.1 需求分析面面观 客户需要的是一把梯子，系统分析员了解到的是一张凳子，开发人员做出来的是一张桌子，测试人员以为是一张椅子……很多角色参与项目工作，每种角色会从自身角色出发来理解需求，以致各种角色对需求的理解会不太一样。下表对各种角色的特点进行了分析： 表 2.1 各种角色的特点 另外要说明的是： 客户一方的总倾向是：自己少花钱，让软件公司多做事情。 而软件公司一方的总倾向是：多拿客户的钱，尽量少做事情。 影响各人对需求理解的主要因素有两方面：一方面是角色的思考倾向，上表反应了这点

商业智能 ，又称 商务智能 ，英文为 Business Intelligence ，简写为 BI 。 商业智能通常被理解为将企业中现有的数据转化为知识，帮助企业做出明智的业务经营决策的工具 。这里所谈的数据包括来自企业业务系统的订单、库存、交易账目、客户和供应商等来自企业所处行业和竞争对手的数据以及来自企业所处的其他外部环境中的各种数据。而 商业智能能够辅助的业务经营决策，既可以是操作层的，也可以是战术层和战略层的决策 。为了 将数据转化为知识 ，需要利用 数据仓库 、 联机分析处理（ OLAP ）工具 和 数据挖掘 等技术。因此，从技术层面上讲，商业智能不是什么新技术，它 只是数据仓库、 OLAP 和数据挖掘等技术的综合运用 。 商业智能的概念于 1996 年最早由加特纳集团（ Gartner Group ）提出，加特纳集团将商业智能定义为： 商业智能描述了一系列的概念和方法，通过应用基于事实的支持系统来辅助商业决策的制定 。 商业智能技术提供使企业迅速分析数据的技术和方法，包括收集、管理和分析数据，将这些数据转化为有用的信息，然后分发到企业各处 。 可以认为， 商业智能是对商业信息的搜集、管理和分析过程，目的是使企业的各级决策者获得知识或洞察力（ insight ），促使他们做出对企业更有利的决策 。商业智能一般由数据仓库、联机分析处理、数据挖掘、数据备份和恢复等部分组成

《软件需求分析》 阅读了主任推荐的csdn博客后，不能说是受益匪浅，但是还是有些许收获的，这次的阅读笔记就把自己的心得体会写出来，好让未来的自己不怎么迷茫。 首先，博主举出了四个比较差强人意的项目作为引子，第一个是东软的项目，由于项目结构不断的调整，要对几百处的程序进行调整，最后客户还是不满意，结果崩了的例子，失败的原因还是客户只知道他不满意，但怎样才能使他满意呢？他不知道，于是就在一点儿一点儿试，于是这种反复变更就这样发生了。于是作者知道了当客户提出业务变更的时候，我们一定不能被客户牵着走，客户说啥就是啥。我们要从业务角度深入的去分析，他为什么提出变更，提得合不合理，我有没有更合理的方案满足这个需求。当我们提出更加合理的方案时，客户是乐于接受的，变更也变得可控了。第二个是自己的项目，报表的不统一和设计上的不规范，导致很难弄用计算机来实现，最后作者又要得出结论：但我们作为技术人员，需求分析必须实事求是的、基于技术可以实现的角度去考虑。我们做需求就应当首先理解现有的管理模式，然后站在信息化管理的角度去审视他们的管理模式是否合理，最后一步一步地去引导他们按照更加合理的方式去操作与管理，其余的就不一一列出。 随后博主进行了细致的调研划分，从初识到到拜访再到研讨会，从而需求调研到迭代到需求捕获再到用例图和业务流程分析.......这一系列的步骤才能保障一个项目尽可能的可能成功。