银行的业务系统如何适应市场需求的变化以及需要哪些IT系统的支持，需具体

2012-9-24 如何编写ＩＴ项目方案 通过学习如何编写方案，让大家进一步体会管理线索在实际工作（项目）中的应用。 帮助大家更容易地理解ＩＴ项目管理的理论体系：九大知识领域和五个过程组。 帮助大家学习掌握ＩＴ项目方案编写方法。 目录 什么是方案 如何编写需求分析 如何编写方案设计原则 如何编写解决方案 如何编写实施方案 如何编写维护服务方案 如何编写培训方案 如何编写典型案例 典型设计方案分析 方案就是解决问题的方案。 方案有：用户解决方案、项目申报方案、可行性报告等等。 写方案的目的就是让别人知道，你有能力高效、低耗、低风险地完成特定的任务目标。 方案中要解决： 为什么做 做什么 达到什么效果 谁来做 怎么做 花费多大代价 有何风险、怎么控制 质量如何保证 你是否有相应的能力 什么是方案 方案的背景，讲述当前与方案相关的社会、需求、技术等背景情况，国内外同类解决方案的情况等。一般出现在申报方案。 需求分析，即问题所在或方案的目的，讲明这个方案要解决的问题是什么，方案都是有目的的，在这里就是要阐明目的，并树立起要解决问题的目标。给读者阐明为什么做。 方案的意义，高度概括，这个方案能解决什么问题，方案的实现能带来什么好处。一般出现在申报方案。 方案设计原则，就是在设计解决方案时，必须要遵循的原则。所谓原则，就是不能突破并必须严格遵循的尺度。在每个具体的解决方案中，都要体现预先确定的原则。 遵循的标准，包括国标、行标、地方标等，也是在设计方案是不能突破的尺度。 方案的目标，总体概述解决问题的方案，高度概括。一般出现在申报方案。 解决方案，给读者阐明怎么做，来解决问题。是解决方案的主体。 方案有以下要点或组成部分 组织架构 实施方案（进度计划），给读者阐叙做的具体步骤，工作路线。 服务方案（服务计划），给读者阐明你有服好务的具体措施。 培训方案（培训计划），给读者阐明你有做好培训的具体措施。 沟通计划 质量控制计划 风险识别和风险控制计划 设备采购计划 工作量估算和人力资源成本预算 典型案例介绍，给读者证明，你已经具备了实现这个方案的能力。 工作基础、工作成果积累，进一步论证你具备实现这个方案的能力。 满足用户的需求、满足招标文件中提出的所有要求是编写方案的基本原则，要对用户和招标文件的每一项要求都有明确的响应，要清晰准确地领会用户的意愿，不能随意抵触或反对用户的意愿。 要努力在方案中体现我们的特点（特别是主要竞争对手所不具备的特点），要在方案中发挥我们有利的资源，厂商产品选择是要考虑利润最大化和商务可控性。 需求分析即问题所在或方案的目的，讲明这个方案要解决的问题是什么，方案都是有目的的，在这里就是要阐明目的，并树立起要解决问题的目标。给读者阐明为什么做。 用户需求分析总会是用户解决方案的第一部分，这部分主要是分析用户项目的需求、用户的关注点和兴趣点、用户当前的资源情况和存在的问题等等。 用户需求分析是整个方案定基调的部分，是为我们为什么提供后面所描述的方案设定论点并为提供论据奠定基础。 同时，到位的需求分析，也是为我们制定方案的设计目标提供依据。 作为方案的开篇部分，如果分析到位，特别是用户的关注点和兴趣点分析到位，会立即引起用户的共鸣，迅速把用户吸引住，也更容易让用户理解我们后面的内容。 一个到位的需求分析，是一个好方案的一半。反过来讲，如果你都不能全面地把握用户的需求，你拿出来的方案也不会有什么针对性，用户不会感兴趣。 要做好需求分析，需要进行耐心细致的用户调研工作，而且根据用户项目的特点，制定明确的需求调研线索和方案。 需求分析 用户立项的宏观背景 用户立项的目的和意义 用户的组织架构 用户当前it建设的情况 采用的技术需求 软件功能需求 软件性能需求（质量需求） 平台环境需求 安全方面需求 项目风险识别 用户关注点和兴趣点详细分析等 每一部分根据需要，可以做进一步分类描述。 对于一个综合性IT应用解决方案，如金保工程方 案，需求分析应包含以下几个方面的内容 大家要注意，用户需求是多角度的 在进行需求分析描述时，各部分分类要清晰 多用条理性描述少做长篇论述 各部分内容分量要均衡 要点要清晰准确 要体现全面、到位和重点突出。 大家记住，这里每一部分的描述都将是后面相应内容的线索和论据。 用户需求分析往往是方案编写者最容易忽视的部分，好多人都是随便凑点内容，甚至凑一些根本无关的内容。 这样的后果是，因为自己不重视，也就不能真正地掌握用户的需求和期望，写出的方案针对性不强。 方案设计原则是每个方案必须的部分，也是很多方案编写者最轻视的部分，好多人的办法是随便抄一个其他方案的原则部分，应付了事。 这反映出他们根本不知道原则是什么、原则的作用是什么。 方案的设计原则是设计者对设计思想的纲领性的描述，是对需求的高度抽象和概括，是进行方案设计的最基本的指导方针。 就是在设计解决方案时，必须要遵循的原则。所谓原则，就是不能突破并必须严格遵循的尺度。在每个具体的解决方案中，都要体现预先确定的原则。 在方案设计原则中，要表明在方案设计时重点要考虑哪些问题，要突出对用户关注点和兴趣点的对策，这些内容要与需求分析的相关内容紧密呼应。 方案设计原则的编写可以分为两大类，一类是基础性原则，一类是响应用户特殊需求的原则。 方案设计原则 基础性原则在每个方案中基本都会有，如： 先进性与成熟性的原则 先进性与保护投资的原则 安全性原则 功能完备性原则 灵活性原则 可维护性原则 可扩展性原则等等。 基础性设计原则 我们拿可维护性原则作为例子分析一下“原则”的含义 可维护性的意思是，根据我们提供的方案开发出的系统，具有方便进行维护的特点。 换句话讲，我们进行方案设计和开发时，要充分考虑今后维护的方便可行。 即便这些基本性原则可能在很多方案中都有，但也要充分理解用户的期望。 如用户项目资金充裕，那可能就要突出先进性的原则 反之，可能就需要充分考虑原有设备的复用，保护原有投资。 用户特殊需求的原则要认真下一番功夫 直接体现我们是不是重视用户的想法 是不是真正理解他们的需求 要想做好这方面的文章，就必须对用户的需求、用户的关注点和兴趣点非常清晰。 一般情况下，在介绍方案时，原则部分会有比较强的冲击效果，特别是那些很到位的响应用户特殊需求的原则。 说白了，就是告诉用户，你关心什么，那么我们就将在方案中注意、解决和实现什么。 解决方案这部分是方案的主体部分，也是分量最重的部分。需求分析部分是讲为什么设计这样一个方案、这个方案要解决什么问题、有什么意义。 方案设计原则部分讲的是我们在进行这个方案设计时应该遵循的原则，或者说是应该重点关注和考虑的问题。 标准规范部分讲的是方案设计的应遵循的标准规范。 这部分是介绍我们设计出来的结果。 是不是满足需求、是不是能够解决用户的问题、是不是遵循了原则、是不是符合相应的标准规范，全要在这部分中体现出来。 解决方案 为了让大家容易理解，我在这里用一个大家比较熟悉、比较容易联想的方案设计例子进行介绍，这个例子就是一座大楼的设计方案。 设计一座大楼是一件很复杂的工作，要考虑大楼的功能需求、外观、空间、每个楼层的房间布局、强电线路、弱电线路、供水线路、供暖线路、排污管线、各种材料等等，要进行力学分析、结构分析等，可以说设计一座大楼是一项庞大系统的方案设计工作。 后面将给大家介绍一下编写这部分内容的注意事项。 首先请大家记住，我们这里讲的设计方案，是我们与用户沟通交流的方案。 目的是让用户知道我们有能力、有措施、有保障地去实现他们的需求，是让用户树立起与我们合作的信心，但并非是一个具体的开发方案。 因此需要重点突出而不需面面俱到，不需要或者千万不要落到具体的细节上，要尽可能保证各部分内容的均衡。 设计方案编写要点之一 在方案描述部分的最前面，要有一个方案的总体描述，可以称为总体设计方案。 或成为方案蓝图 也就是项目的总体目标 这部分是对你的设计方案的高度概括性介绍。 设计方案编写要点之二 为了能让用户了解你的方案的全貌 对于比较复杂的设计项目来讲，不是几句话几段文字可以表述清楚的 需要站在不同的角度、针对于不同的层面进行介绍 譬如说大楼的外观，从正面看，你是看不到全貌的，即便你把外貌全介绍清楚了，如果不介绍其他的话，别人也很难明白这个大楼。 因此要学会角度、层次的分解 可以从类别上分，也可以从功能上分，分的目的是为了更全面、更清晰、更容易地给大家介绍你的方案。 一般一个ＩＴ项目方案包括： 技术架构 网络架构 安全架构 功能架构 性能指标 。。。 设计方案编写要点之三 对你的方案进行分解描述时，要充分考虑前面需求分析的内容。 需求分析中提到的需求和问题，在方案描述部分都要有相应的解决方案，前后呼应，前面讲为什么要做，这里讲怎么实现。 与需求分析呼应，也是方案分解描述时进行分解的参考依据。 方案是否与需求相呼应，意味着方案是否扣题。 有很多这方面做得不到位的方案，对在这个项目上行，按在另外一个项目上也行，就成大笑话了。目的性强！ 设计方案编写要点之四 对于一些用户关注的问题和需求，以及通过分析具有比较高复杂度的问题，也要分解出来进行单独讲解 一是表明我们对用户的需求的充分响应 二是表明对需求理解的深刻，尽管有些问题很复杂，但我们有可行的解决方案。 借此增强用户的信心。 设计方案编写要点之五 要与前面设计原则部分相呼应 在方案的描述中，要体现出我们是严格遵从前面制定的原则的。 同样，也要对所遵循的标准规范有呼应。 设计方案编写要点之六 多采用图示的方法 大家都知道，无论文笔怎么好，文字的东西总是比较抽象的 读者必须通过联想才能理解你描述的含义。 如大楼的外观情况，如果文字描述，很可能长篇累牍地写了一大堆，别人还是搞不明白。 而用图的形式，可能只需三两张图，就把大楼的外观展现的清清楚楚了。 图示的作用是直观。 图是对方案的高度概括和抽象。 做一张好图，要基于你对方案完全了解和掌握，也要基于你的知识和经验的积累。 真正好的方案描述都是图文并茂，用文字辅助解释图中关键的部分。 设计方案编写要点之七 要学会使用表格进行描述 与图示一样，表格也是一种非常好的方案描述的方法。 表格的作用是简练、调理、清晰，更容易让读者理解你所表述的内容。 对于一些包含大量数字，或者描述形式重复的内容，都可以采用表格的形式描述。 设计方案编写要点之八 对于一些重要的指标或用户关心的指标 需要基于你的方案进行分析 用合理的分析模型和数据 证明你的方案能够达到用户所期望的指标 例如设备配臵选型设计，用分析的指标作为依据 设计方案编写要点之九 对于一些需要利用其他厂商产品进行集成的项目 要讲明你所选择的原因和这些产品的作用 要对你所选择的主要产品从功能和性能角度进行介绍。 设计方案编写要点之十 为了突出我们期望让用户产生深刻印象的内容。 可以在方案描述的最后一部分做一个总结，可以用方案特点介绍的说法。 在特点介绍中，要突出我们独有的特点（在一定程度上会让用户去找我们竞争对手相关的内容）。 要突出用户关心的问题（与需求分析呼应）等， 大家需要注意，特点一定要“特”。 方案特点组织的好，也会对用户产生比较强的冲击力。 设计方案编写要点之十一 编写方案的时候，特别是编写这部分方案的时候 切记千万不要凑材料，这个地方抄点那个地方摘点进行拼凑，这是编写方案的大忌 如果需要摘抄一些资料，必须自己完全掌握这些资料的内容 并且确认对解决特定的问题有帮助。 设计方案编写要点之十二 开发实施计划，也称总体进度计划，是对全部相关计划的有机整合，也叫整体计划。 整体计划涵盖了开发计划、实施计划、采购计划、质量控制计划、风险控制计划、项目团队建设计划、验收计划、服务计划、培训计划等等。 项目开发实施方案（计划或工作路线） 我们常说，要完成一件事情，需要有计划、有组织、有措施、有保障地进行。 我们的设计方案完成后，接着就要给用户介绍我们怎么实施完成，这就是实施方案。 实施方案的编写需要按照有计划、有组织、有措施、有保障的线索，基于项目管理的思想进行阐述。 在这里对大家有一个要求，就是你在写出来这个实施方案之前，你已经真正明白了这个项目到底怎么干才能干好。 如果你都不知道怎么干的话，写出来的所谓的实施方案是不是可行就需要打个问号了。 这个问题在很多人在写实施方案时常犯的错误。 我们需要基于项目管理的思想来描述开发实施方案。 首先需要明确项目的目标。其实方案确定好了，总目标是非常清晰的，那就是按照用户的需求开发出系统，按照用户的时间约定部署实施完成。 但如果仅仅这样讲，那只落在了总目标的口号上了。 为了拿出真正可行的方案，需要把目标进行分解，分解成一个个阶段性目标或历程碑性目标，这项分解要尽可能的准确和详细，目标越清晰具体，越容易找到实施方案。 要反思，如果这一个个的阶段性目标都实现了，是不是就能很好地完成和实现总目标，如果是，说明你的分解基本就是合理的。 当目标分解工作完成后，各个子目标之间可能存在时序关系，也可能存在其他关联关系，为了完成每一子目标都有相应的工作内容、也需要一定时间和人力资源的支持，有一些比较复杂的工作可能需要一些方法的指导（工作预案）。 对应于每个子目标，把这些相关的东西搞清楚描述出来，然后按照时序关系排列起来，项目的实施计划就出来了。 实施计划描述需要调理，一般可以采用表格的形式。 目标分解一般是采用自上而下的方式进行 具体做法是，先围绕总目标的实现分解成几个大的阶段 然后对每个阶段进一步分解成更小的阶段 最后落实到每一项工作任务的目标上。 在实施计划中，还有一点非常重要，就是必须满足用户工期的时间要求。 项目组织架构 不管目标怎么定，方案怎么做的，有一点是确定的，就是必须要有人去按照计划 去干，去实现一个个的目标。 作为一个好的实施方案，需要对承担这项工作的队伍、人员进行组织和分工。 描述这部分内容的线索可以这样。 定义项目实施过程中的角色，根据实施计划的需要，对参与项目的人按角色进行分类，定义角色的责任。 分析一下这个项目每一个子目标实现过程中，都需要涉及到哪些类型的人，这些人与我们的那些部门有关。 设计项目组的管理架构，与实施计划相关，与工作分类和角色分工有关，要有责任明确的项目负责人角色。 如果队伍比较大涉及的部门比较多的话，项目负责人就需要具有比较强的资源协调能力，明确项目总负责人和不同类型工作的负责人。 根据计划的需要，选择明确项目成员。 一个好的实施方案，除了给用户讲清楚怎么干以外，还要介绍你的这种干法是可行的而且是风险小的，这就是实施方案的保障措施。 一般情况下，应该包含这样一些内容： 沟通协调措施，要有明确的沟通协调机制保障，项目是需要我们与用户、厂商、监理等一起配合完成的，因此必须要有良好的沟通。 质量要求和质量控制措施。 风险分析以及规避风险的措施。 预算（成本计划），包括设备采购计划和人力资源成本预算。 一些复杂工作的工作预案，要让用户知道我们是有办法有能力完成这些工作的，增强用户的信心。 验收计划 这是对双方都负责任的约定，验收方案要科学合理，要具有可 *** 作性。 对于一些特定的项目，需要对我们投入的人力和工作量进行统计。 首先，你要对用户参加培训的人员进行分类 不同类型的人员需要接受不同的培训 大体可以从系统管理角度和系统使用角度进行分类。 如系统管理员（进一步也可细分为应用系统管理人员、系统环境管理人员等）、系统使用人员（或者称用户业务人员，包括各个层面使用系统的人员）等。 培训方案要点之一培训对象分类 从管好和用好的角度，设计培训的课程 在每一门培训课程中，要对一下项目进行定义 培训课程名称 培训目的和期望达到的目标（培训完了，受训人能够达到什么水平或能力） 受训人技术基础要求 培训形式（集中上课、上机实习） 培训课时数 培训教材（必需要有明确的培训教材，除了编写或购买的教材以外，可以多选用项目交付时提供的资料，如设计方案、用户手册等） 培训内容概要（要介绍这门课程的主要内容）。 培训方案要点之二培训课程设计 根据项目总体的实施计划安排，设计课程表 课程表中要明确时间、地点、培训对象、课程 因为这里面要考虑总体进度，要考虑参训对象所受的时间、地点的制约 课程表的编排一定要合理可行。 培训方案要点之三培训课程表 最后可以介绍一下承担培训工作教师的情况 对几个主要培训教师的简历进行介绍 另外，对于一些需要比较特殊条件的培训，介绍一下我们的保障措施。 培训方案要点之四培训教师介绍 用户对维护服务的期望是： 平时通过有效的管理和监控，尽可能地减少故障概率 系统发生故障时，出现的问题能够得到最高效率的解决 这也是我们设计维护服务方案时的基本原则和目标。 维护服务方案 服务需求分析，对用户的服务需求，从主要服务项目和特点、响应时间、期望等进行比较详细的分析。 维护服务方案要点之一服务需求分析 组织管理体系，告诉用户我们公司有哪些部门、哪些人员以什么样的角色参与维护服务工作，每个角色的职责是什么。对服务组织中的核心成员进行介绍。 维护服务方案要点之二组织管理体系 服务项目定义，对于用户的服务需求进行应对，告诉用户我们围绕这个项目，能够提供什么样的服务工作，每项服务工作的含义是什么。如，我们有什么服务是对应于减少故障的，有什么服务是对应于解决问题的。 维护服务方案要点之三服务项目定义 这部分介绍的是为了完成我们提供的服务项目，我们有什么样的措施进行保证。 如，对于我们所提供的减少故障的服务，我们采取什么样的措施来实现。 服务项目和服务措施是紧密关联的，共同来表述我们能给用户什么服务和怎么给用户这些服务。 响应时间定义，这是对双方都有益的一个约定，介绍在不同情况下我们的时间响应措施。 维护服务方案要点之四服务措施手段定义 介绍从服务请求到服务结束我们的工作和管理流程。 进一步让用户明白我们拥有一个严密的服务体系，能够满足用户的服务需求。 需要的话，可以对服务流程所需的管理工具进行介绍。 维护服务方案要点之五服务流程介绍 前面把我们服务体系的服务组织、服务措施、服务流程介绍完后。 最后要针对于用户对本项目特定的服务需求进行响应。 设计满足于用户服务需有的服务方案。 这部分要对用户或招标文件中的服务要求进行点对点的应答，必须明确承诺是正满足。

IT是信息技术的简称，Information Technology,指与信息相关的技术。不同的人和不同的书上对此有不同解释。但一个基本上大家都同意的观点是，IT有以下三部分组成：

-----传感技术 这是人的感觉器官的延伸与拓展，最明显的例子是条码阅读器；

-----通信技术 这是人的神经系统的延伸与拓展，承担传递信息的功能；

-----计算机技术 这是人的大脑功能延伸与拓展，承担对信息进行处理的功能。

IT基础技术的提供 IC研发、软件编写 如INTEL、MS等

IT技术产品化 元器件、部件、组件制造 如精英、大众等

IT产品集成化 计算机及外设制造商 如联想、IBM

IT产品系统化 解决方案、信息系统 如华为、HP

IT产品流通 渠道、销售 如神州数码

IT产品服务 咨询服务和售后服务 如蓝色快车

IT产业舆论支持 IT类媒体 如CCW、CCID

IT产业第三方服务 各种需要配套的服务 如法律咨询、PR服务

IT后备人员培养 各种院校 如计算机专业

在整合过程中，建设核心业务系统成为一个新热点。此时，国内银行建设核心业务系统面临两种选择：一是自主开发，二是整体引进。承载着打造“后发优势”及快速与国际接轨的梦想与希望，国内一些银行纷纷走上整体引进之路。 然而，在具体实施过程中，“引进一套国外系统，复制一家一流银行”似乎只是一种理想化的设想。实施国外核心业务系统项目后，国内银行往往投入大量资源，花费大量时间，项目实施计划一改再改，上线时间一推再推，系统却还是不能投入生产。有些银行经过一到两年的探索和尝试，最终还是放弃了国外产品，掉过头来转向国内IT厂商提供的软件。 将国外系统移植到我国银行现有的生产关系环境中，“空气、阳光、土壤、水份”等都大为不同，如果系统的灵活性和适应性不强，结出的果子自然亦非当初所设想的样子。是南橘北枳，中国的银行完全不适于采用国外的系统？或仅仅是水土不服，只要经过本地化、客户化的改造后，国外系统还是能发挥其应有的效应？业内外人士都在密切关注———国外银行核心业务系统在中国实施本地化和客户化的难点究竟在哪里？ 引进国外银行核心业务系统产品，购买只是简单的第一步，如果不经过大量的本地化和客户化工作，系统根本无法发挥其功效。不同类型的国外软件在本地化和客户化过程中会遇到不同的问题。纯技术类软件主要面临技术问题，管理类软件除了技术问题外，更大的困难是文化、体制的差异。整体引进国外银行核心业务系统，虽然遇到很多技术问题，但根本原因还是在于国内外监管环境和体制流程方面的巨大差异。 国外核心业务系统本地化和客户化是一项复杂的系统工程 很多人存在这样一个认识误区，认为软件本地化就是软件翻译，软件客户化就是按照客户需求加以修改。实际上，软件本地化是将一个软件产品按特定国家、地区或语言市场的需要进行加工，使之满足特定市场上的用户对语言和文化的特殊要求的软件生产活动；软件客户化是指在分析用户需求与产品差异的基础上，在满足客户需求和保证系统结构稳定的前提下，对软件进行的一系列开发、测试活动。因此，国外软件本地化是一项复杂的系统工程，不是一个简单的从外语到中文的翻译过程；客户化也不单单是按照客户需求去修改系统，否则就失去了购买成型产品的意义。 国外银行核心业务系统在中国的本地化，主要包括本地化界面、国内环境接口、本地化报表、本地化文档及培训等方面。界面本地化包括：语言的汉化，将系统界面中的画面、菜单、 *** 作符、提示信息等要素用中文进行表示；界面的易使用性，针对国外产品 *** 作界面与国内风格的不同，通过适当修改、简化或进一步细化成一个容易使用的 *** 作界面；用户 *** 作习惯的满足，根据用户在旧系统上形成的较好的 *** 作习惯，实现系统对应内容的差异最小化。 与国内外环境的接口：包括人民银行现化支付系统、中央国债登记结算公司接口、上海证券登记结算公司接口、外管局国际收支申报系统、人民币大额和可疑支付交易监测系统、人民币交易系统、结售汇系统、进口品报关单检查和进口单位名录系统、各种本地数据交换信息接口等。 本地化报表：国外核心业务系统报表功能高度参数化，因此报表本地化与报表的具体形式关联性并不十分紧密，工作量主要集中在内部数据的采集。 本地化文档及培训：本地化文档包括用户手册， *** 作手册、技术手册等；本地化培训，包括详细客户培训、详细设计培训、技术标准培训等。 国外银行核心业务系统在中国的客户化，主要包括需求差异分析、与内部系统的对接、第三方提供功能的集成等三个方面。需求差异分析是以国内银行现有业务或预期目标为基础，对照国外金融IT产品进行功能性分析，找出差异以及应对策略的过程；与银行内部系统对接要分析清楚现有系统与即将开发的新系统之间的详细关联关系，保证新旧系统平稳衔接；第三方提供功能的集成，是指在保证第三方提供的系统运行正常的基础之上，考虑与核心系统进行集成。这一般是由国外厂商在当地IT公司中选中的一家总集成商来完成。 国内外银行监管环境的巨大差异增加本地化难度 国外银行核心业务系统模块多、规模大，业务范围涵盖银行业务的方方面面，其本地化和客户化过程对任何国家的任何银行而言，都不亚于一场革命。把它放到我国银行的背景环境之中，矛盾就会更加突出。我国金融市场化程度不高，监管框架、相关法规制度与国际标准还存在较大差异，银行治理结构的缺损、内部经营管理体制的僵化， *** 作方式落后，这些都加大了核心业务系统本地化和客户化的工作量。 监管环境和相关法规是硬约束，为适应国内的财会准则以及人民银行、银监会等监管机构的监管要求，国外的核心业务系统必须做出适当修改。此类差异主要体现在以下几方面： 国内外利率管制程度不同，系统在国内本地化和客户化时，某种程度上要牺牲系统的先进性。在国外核心业务系统中，利率就象一个魔方，其多维、立体的参数设置和组合，在打通银行及相关混业领域、联贯各产品方面发挥着灵活的作用。 在国外发达的金融市场环境中，利率作为最核心、最重要的交易要素主要体现在价格功能。国内现阶段金融市场尚未完全放开，利率很大程度上是金融监管当局的管理工具。按照人民银行的利率管理办法，对于各种类型的存款或贷款，利率要求都不尽一致，特别是针对部分种类的存款和贷款更有特殊的规定。国内监管部门利率规定繁多，利息计算方法复杂，因此产生很多差异。这些差异应该按监管规定进行修改，但考虑到修改量太大会影响其稳定性，需要采取折衷作法。 国内外对外汇管制程度的不同，造成核心业务系统本地化和客户化时，系统修改的难度和工作量加大。在外汇管制的背景下，结售汇是我国监管框架下的特殊业务。根据外汇局外汇管理的有关规定，每笔结售汇业务都涉及到：对客户是否在其“名录”中进行真实性的审核；需要对其贸易必备条件进行逐笔、逐级进行审批；还要进行询价、头寸申报、买卖外汇、结算、售汇报表等。国外由于外汇自由兑换，没有哪个模块有类似功能。如果走定制开发模式，可以考虑单独设置结售汇模块。但对国外核心业务系统而言，修改需求介于 *** 作与报表之间，开发起来有一定难度。另外，根据外汇局要求，结售汇报表、大额可疑报表、经常账户报表要直接从业务系统中生成并报送，类似需求对国外系统的改动也很大。 国外系统要与国内支付系统直联，需要对整个模块做彻底的修改。为实现资金清算的STP(直通式处理)，核心业务系统应与现代化支付系统相连接。由于国外系统没有通过国内大额支付系统汇划处理业务的界面，需要按照人行的《中国现代化支付系统与商业银行行内系统接口方案》中规定的报文格式要求，包括支付报文、非支付报文、对账报文等，对系统做大量的改动和测试工作。从稳妥角度考虑，国内银行在建设核心业务系统过程中，一期可以先实现交易驱动账务核算，待系统稳定后再推进清算的直联工作。 国内外会计管理理念和制度的差异，需要重新构架会计体制，实现会计管理的全面转型。国外核心业务系统的会计核算功能，靠交易驱动来实现系统自动化处理。这既是国外系统直通式处理和参数化灵活配置的优势体现，也是实施过程的难点所在。会计核算不仅要跨越管理理念的差距，而且要把大量的制度创新和方案设计的工作想在前头和做在前头。具体来说，就是对所有业务模块驱动会计核算的核算结果通过制度规范想在前面，对上万个会计参数通过严格的确认和配置做在前面，否则会直接影响系统自动化输出的会计核算的结果。这既要求业务归口部门及早改变传统的会计管理模式，又要组织起银行内部技术资源，扎扎实实地做好系统上线前后的各项准备工作。如果会计核算结果的准确性、效率性及安全性缺乏保障或受到置疑，就会动摇整个核心业务系统的根基。 考虑到国内金融改革与银行开放的速度和进程，对上述重大差异要有前瞻性的态度和解决方案。对于接近国际标准、具备中国特色、预计不会成为改革对象、当前必须遵守的法律、法规，要认真对待，研究解决方案。对于事过境迁、含义模糊、明显属于过渡安排、不涉及法律诉讼的制度和规定，可以不予考虑或暂时放一放。另外，在解决方案的方式方法上，要优先考虑适当变通，尽可能地少改产品。按照这样的大原则，才能把修改系统的工作量降到最低。 国内外银行管理体制流程的巨大差异增加客户化复杂度 此外，国内银行经过多年改革与发展也形成了自己独特的管理体制和 *** 作流程。这些管理体制和 *** 作习惯中，大部分来自于经验积累和成绩总结，也有一部分属于不规范的范畴，与国外同业相比存在着一定的差异。有些差异我们已经司空见惯，甚至变成了日常管理 *** 作的一部分。引进国外核心业务系统，要从多个角度思考对这些差异的系统处理方案。 内部核算、清算体制的差异。与国内银行实行的总分行多级核算体制不同，国外银行一般实行一级核算体系，对总分行清算资金往来系统只设一个过渡账户--总分行往来，总分行共用该账户，相互占用资金不计息。因此，国外核心业务系统中没有系统内资金清算功能，总分行不能对开清算资金往来账户。按国内银行的资金管理体制，分行作为一级经营单位，与总行资金往来需要相互计算利息。因而需要开立清算资金账户，用于系统内资金往来。 虽然目前以“集中”和“集权”为主要特征的改革已经成为国内银行的趋势，但这种权利上收和层次减少还限于支行层权力及核算单位的取消，效果尚不十分明显。由于账务层次过多，一些分行内部账交易的数量甚至超过了往来账户，潜在风险加大。不仅占用大量计算机资源，造成系统处理速度慢，批量处理时间长，月终、年终处理压力大，而且也增加了国外核心业务系统本地化和客户化的工作量。 资金管理体制的差异。国外银行由于实行总行一级核算，分行被看作总行的营销前台，客户是银行共同的资源，因此，贷款发放可以简化为银行与客户之间的借贷关系。银行向客户发放贷款属于财务会计核算范畴，由核心业务系统处理；总分行之间的资金占用和利益分配，属于银行内部利益再分配范畴，可以通过外挂的管理会计模块进行核算。而国内银行核算层次多，系统内各层次之间资金关系复杂。有些银行为了加强系统内资金管理，实行了系统内借款的作法。具体执行中要求贷款的发放、回收、计息等均与总、分行间的系统内借款处理绑定关联。此类需求若要在核心业务系统中实现，需要系统做出重大改动。 后督的作法问题。为加强事后监督，国内有些银行实行了后督制度。在手工方式下，后督一般于业务发生次日对原始凭证、会计凭证、审批单和交易流水进行逐笔检查，以此达到对本、外币结算清算和会计核算业务进行逐笔事后监督的目的。国外系统中没有类似我们理解所说的后督功能，如果要实现国内银行现行后督的作法和要求，系统修改的工作量非常大。 “双敲复核”问题。根据会计制度有关规定和风险控制要求，存款、支付、清算所有模块均需增加录入复核功能。即录入员输入交易要素后，由另外的复核员重新录入关键的交易要素，两次录入相符才提交该笔交易。出于降低风险的考虑，国内银行希望能够实现这一功能。但对于国外系统而言，增加双敲复核的功能需要对系统做较大改动，增加处理界面近一倍。国外产品供应商建议采取主管授权和降低录入人员 *** 作权限的方法的方式替代复核功能。由于该项变通处理涉及面广，影响深远，需要分时、分步才能解决。 “倒起息”需求问题。倒起息有时被称作“利率晚到”，指由于某种原因，利率的实际生效日需要提前到系统当前日期之前。国外也有倒起息 *** 作，只不过频率没有我们这么高。目前国外核心业务系统还不能处理好这个问题，完全按照国内银行的自动处理要求对系统进行改造也有一定难度。最后往往选择的是折中的方式：即倒起息在同一结息期内的情况下，系统可以自动计算利差并进行计息；倒起息跨一个结息期时，系统只能提供利息调整数的计算功能，但要手工调整；跨多个结息期时，系统完全要手工 *** 作。还有一种方案建议将利差的计算放在系统之外，通过两个系统自动衔接，实现利息调整批量完成。 重要空白凭证管理问题。国外核心业务系统有支票、汇票、本票的管理功能，但管理层次少，管理内容简单。国内银行要求对银行汇票、银行承兑汇票、银行本票(定额、不定额)、定期存单、来账报单实行总分行多级集中管理，可随时增添票据种类，保留系统对客户的管理，同时需要记表外账(单式记账)。这是国外核心业务系统需要向国内靠拢的地方。 跨分行访问控制问题。国外银行机构设置扁平化，分行只是按业务纵向销售总行产品的前端，因此国外系统一般没有跨分行访问控制的概念，各分支机构间可以随意访问，很多模块无需对跨分行权限进行限制，一家分行可以改动另外一家分行的业务。由于国内银行管理模式与国外不同，因此很容易发生分行错记总行账的问题。即使产品供应商不愿意修改，从风险控制的角度看，类似差异需要按照国内银行现有模式进行修改。 综上所述，由于国内外市场发育程度不同，银行的外部监管环境和法规制度相差较大，银行内部的管理体制、业务流程和 *** 作习惯也有很大的区别。差异是客观存在的，但却是可以靠银行、国外核心系统提供商及国内总集成商共同努力，找到一个彼此接受、合理可行的解决方案。由于差异的解决程度，直接影响到项目的成功与否和风险大小，因此需要各参与方正视差异，共同面对和分担项目风险。这些差异解决好了，就能够实现国外技术与中国实践的良好“嫁接”；解决不好，就会成为“夹生饭”，煮不熟也吃不下。(此文为作者博士论文节选

IT 的管理者很清楚的知道，在不远的未来信息化将成为业务的运营中心，问题是信息化自身又该如何运营管理。

IT 团队需要了解业务部门的需求，然后设计并开发一个个的信息系统。这些信息系统就像工厂里的生产线一样，将生产出真正对业务有所帮助的数据和信息。

IT 的管理者就像是这个工厂的厂长，需要能够敏锐的 发现 业务需求，经过系统化的 设计 并且有效的 协调 人员去实施。此外，还需要高效率的运维 保障 已上线的信息系统稳定运行。

这些要求可不少，IT管理工作看起来就像是在运营一个工厂，并且在这个信息化正在逐步走向成熟的年代，可以说每一个IT管理者都是一个创业者。

管理IT，就像管理一家企业或医院一样，没有什么本质的区别。需要面对的都是那些像幽灵一样，隐藏在各个环节中的问题。我们不太可能真的去一个一个的解决这些看起来千头万绪的问题，因为这些问题很有可能是环环相扣的。

但很快会发现，肯定有那么几个问题是元凶，是导致这千头万绪的根源，只要解决这几个问题，剩下的症状就会自然的全部消失。而问题的关键是，你怎么找到这些根源。

即使问题再难缠，只要能够摆在面前，相信总有办法解决。但是这些问题总是像丛林中的幽灵一样，若隐若现，躲闪在丛林之间。

这些问题似乎就在那里，又若隐若现，有时还会投鼠忌器，所以请允许我用幽灵来形容这些管理上的问题。但是这个世界上肯定不存在幽灵，其实是我们对整体工作的认知不够系统化，所以才给了幽灵们能够躲藏，能够隐蔽的角落。为了找到这些“幽灵”，IT管理者们需要一个系统化的方式。需要一个系统化的方式去认知IT管理工作，否则幽灵们就会出现。

曾经信息化技术有着一些神秘 的技术色彩，甚至对很多人来说还有一些魔法般的神奇。但是，现在这些都不重要了，因为人们不再关心是你怎么实现的，而是关心你究竟能给我带来了什么。

之所以没有像吉普赛人的巫术一样消失，是因为信息化技术真的能够给人们带来价值，要么是提高了业务的效率，要么是减少了浪费。所以，IT为什么存在？答案只有一个，就是为业务创造价值。

IT 的运营是一个为业务创造价值的过程，这个增值的过程是IT团队一系列的输入、转换和输出的行动集合。每个行动都对业务客户产生增值行为，从而最终为业务客户创造价值。

让我们用这样一个脉络去认知IT的运营过程，方向是：首先得了解为谁创造价值。输出是：价值是承载在输出上。过程是：输出是被怎样一个过程创造出来的。输入是：需要输入什么样的原料才能满足过程。所需要的资源是：像生产过程一样，IT的运营过程同样需要投入资源。要遵守的规则是：在这个过程中，需要遵守的规则有哪些。

                           

方向：IT的运营是一个为业务创造价值的过程，重复一下，是 为业务创造价值 。所以，现在创造价值的方向就非常清晰了，要以业务客户为核心。有两点具体的体现：第一是增值的过程是以业务的需求为源头，进行设计和规划。第二是对IT工作的测量指标有很多，但是最高级别测量是客户的满意度。

价值和输出：所谓“输出”指的是增值过程最终输出的产品或服务，而价值一定是被输出承载的。价值一定是摸得着，看得见的，就像人们认宝马的汽车 *** 控性很好的时候，宝马公司的价值是依托于该公司最终提供给你的宝马汽车之上。信息化的价值是通过为业务部门提供了一个一个的信息系统以及服务而体现的。

过程： 为客户创造最终价值的，不是一个活动，也不是一个流程，而是由各个流程组合在一起的整体价值链。 例如、需求分析、审批、设计、开发、测试、部署。又如、申告记录、分派、处理、满意度调查。

输入：根据输出和价值的要求，IT团队需要外部提供什么样的资源输入。

资源：IT的增值过程需要投入直接的资源，包括：人、资金、软件、硬件、数据。当这些资源不足的时候，则直接体现为增值活动的产能不足。

规则：在很多行业中都有相应的规则要求，例如、银监会对商业银行的IT管理要求、保监会对保险公司的IT管理要求。对于这些政策性的管理规则，等于是给IT管理工作圈定了一个范围，任何设计和规划不能超越这个范围。

需求就像原材料一样，不断的被分析、被加工，直到最后形成服务提供给业务客户为止。IT团队可根据价值链，对各项作业进行计划和管控，同时价值链也是生命周期的档案链，是信息传递及追溯的基本逻辑。此外，IT管理者可根据价值链，分析引起交付质量波动的各项作业，并分析其上下环节的原因。

我为什么要在这里特别放一个章节来描述价值，因为我们后续谈的所有内容都是围绕价值创造来开展的。最怕的是过于专注于方法和过程，而忘记了最根本的核心问题--为业务创造价值。IT团队是以流程的方式利用资源，为客户提供服务，从而创造价值。因此流程只是创造价值的方式，但是在不清晰价值的时候，设计流程等于是一种盲目行为。

从客户的角度看，IT服务的价值有两部分组成：效用（Utility）和保障（Warranty）。任意一个都可以增加客户获得的价值，但两个都是必要条件，两个都不能单独构成充分条件。

价值的源泉：效用

效用（Utility）是一个经济学名词，任何产品和服务的价值首先取决于满足用户的期望程度，而用户的期望往往是模糊的，无法直接度量，所以只能间接的衡量由欲望产生的现象。在经济学中以一个人为了实现或满足他的愿望而愿意付出的价格来衡量效用（Utility），所以效用是价值的源泉。

如果把效用简单的进行叙述就是，某个服务或产品使得业务客户在使用后，能够减少多少以前的负面状况，或增加多少正面的状况。

我们可以用这样的逻辑尝试去叙述：利用了……功 能，解除了……谁的，……什么，使得…谁节省了，或增加了……什么。例如、利用数据化的管理，解除了文档无法统计的限制，使客户得到了有效的统计信息，也节省了得到信息的时间。

这就像我们后面要说到的需求管理中“用户故事”一样，用户故事是力求通过简短的语言是从用户的角度来来解读和描述用户渴望得到一些功能。所遵循的逻辑是：As a, Iwant to, so that也就是作为一个<角色>, 我想要<活动>, 以便于<商业价值>。

价值的基础：保障

信息系统发挥效益是建立在其稳定运行的基础上，需要其五个方面的保障： 可用性的保障 、 容量和性能的保障 、安全性的保障、连续性的保障、服务响应时间的保障。

根据最终交付的价值，IT团队的主要工作有两个方面，一是对信息系统的运维保障，二是通过建设和优化信息系统，为业务创造效用。

如果说这两个工作是有着根本的区别，那就是在对外界变化的影响上。运维保障工作受到外界的变化影响小，而为业务创造效用的工作相对受到外界的变化影响大。

运维保障工作的目标不会总是发生变化，也不需要频繁的去和客户讨论目标的变化。IT团队不会天天跑去问客户，你看今天咱们这个信息系统要保障到什么程度？消防队不需要天天问市民，如果今天你家发生火灾我们几分钟到场合适。对信息系统的保障要求对于各个行业来说虽然不一样，成本也不一样。但是，有一点是一样的，就是一旦确定了保障的目标以后，该目标不会频繁的发生变化。那么，我们可以确定为运维保障的目标是基本稳定的。既然目标已经确定，那么重要的是两点，一是如何达到目标，二是如何更加合理的利用资源，更加高效的达到目标。精益的运维管理，也就是一套以达到目标为基本要求，如何更加合理的利用软硬件资源，利用人力资源，利用时间的管理机制。 为业务创造效用的工作则是需要更加敏捷的方式，这是因为业务本身需要更加敏捷的响应市场，所以IT也需要更加敏捷的支持业务。这要考验IT的运作能力，虽然从字面上看敏捷有快速的意思，但是仅仅是速度并不等于敏捷。速度再快，最后的输出不满足业务需求，也是白搭。所以首先是把事做对，也就是满足业务需求的高质量交付，然后是把事做快，因为需求也有保鲜期，我们交付的服务如果过于缓慢，可能需求已经发生了变化。

精益思想和敏捷思想，在IT团队的工作中需要有效的结合， 一个成功的组合策略基于将需求模式分为基础需求和波动需求两种需求，也就是“基础需求和波动需求的分离”，一般来说，基础需求是相对稳定的，如业务对可用性和容量的需求或者对服务请求的响应时间，换句话说都是IT团队预先承诺在日常服务范围以内的支持性工作；而波动需求则和新建系统和创新应用联系在一起，这种需求一般不能预测，具有很大的灵活性。 以客户需求作为切入点，在切入点之前交付的是无个性特征的保障性目标，采用精益思想，也就是推动式的精益运维。在切入点以后，要依据客户需求的实际情况而定（未见得是被需求，可能是引领需求），采用敏捷思想。

项目管理工作中遇到棘手问题？个人职业发展遭遇瓶颈？也许你需要一个导师为你答疑解惑。

老邱百问板块就是为此而设，主要关注项目管理和职业发展领域，给大家一个提问的平台，并有机会得到老邱的亲自解答，同时将问答分享，以供大家交流借鉴。

老邱百问，答你所问

question

提问者：卓君

提问：互联网偏技术的职位，做的较多的是公司内部的需求或项目，学了pmp后如何转到真正的项目经理

老邱解答

如果你已经是PMP，那么你一定对PMBOK的过程有所了解，很想把PMBOK所学到的知识运用与日常工作和日常项目中。项目管理人都是有项目管理思维的，比方项目立项管理、项目规划管理、项目执行管理、项目收尾管理，其实在我们日常工作中，还有很多PMBOK中都会提到非常实用的三大工具，今天我在这一篇文章里就给大家介绍项目经理的三大神器！我们也运用场景给大家介绍这三大神器的使用方法。

神器一、mindmanager

项目立项了，我们的章程已经发布，所有人都知道你已经被任命为项目经理了，当你摸不清头脑应该如何往下做的时候，PMBOK被打开了。原来，制定项目章程之后，你必须要完成项目管理计划了，但是该计划中这么多子计划让你无从下手。。。

不急，听我慢慢道来！

项目是由一个商业机会触发，而这些商业机会早已写在商业论证中，也在立项之前明确，在你的项目章程中也应该有高层级的目标和范围。作为项目经理的你，应该继续触发需求管理，项目管理的交付五花八门，有的是实现一个新产品，有的是为客户部署一个产品功能，有的是做企业内部交付，有的甚至只是单单一个流程优化。此时的你，大可不必惊慌，因为我们项目管理的方法是一样的，我们收集需求的工具和方法其实大多相同。

1、产品类项目。

这类项目的项目经理需要有敏锐的用户视角，你很清楚，你的产品设计的好坏会直接影响到用户的购买。所以，获得需求的样本量越大，对你的产品设计和研发越是有帮助。而这时的你要知道，产品设计数据是王道，所以需要大量问卷调查进行统计分析，跟团队进行头脑风暴，抽取样本开焦点小组及引导式研讨会等，甚至还需要考虑到发起人可能会有私人想法，然后对其运用访谈技术。

2、部署类产品。

部署类产品相对来说比较成熟，客户和用户的定位比较明确，他们的购买或者使用思路比较清晰，如上线一个ERP，又如部署一个基站做5G的升级。那么作为部署类项目的项目经理来说，建议使用的一些需求工具如：跟客户一起头脑风暴，开焦点小组会议，或者是引导式研讨会，然后对一些部门主管进行访谈等。

3、内部交付类、流程优化类项目。

你的用户群可能就是公司的某一些业务部门，需求样本量相对较少，你也不一定需要类似问卷这种大样本工具，我们建议使用：头脑风暴、焦点小组、引导式研讨会等，去触发用户对于需求的表明。

无论在哪种模式下，这时候的项目经理一个开始头大了，需求越来越多，也越来越搞，早知道不跟这些用户开会了，他们又不懂，个个考虑自己的私利以自己为中心，而不是项目产品为中心了。PMBOK 又教我们我们可以用亲和图、名义小组、引导等方式给需求进行排序和分类，这样不至于使用户们提出的各种需求都纳入到我的项目范围。项目资金是有限的，项目经理不可能在有限的资源做出无限的功能。

这种类型的需求工作会议，开多了就样样蔓延，开少了呢又怕遗漏需求。这时候，你完全可以使用这个神器，mindmanager。它集成了头脑风暴、亲和图、名义小组等各个工具的优势，当大家在谈每一个需求的时候，如果你用白板写出来还是不够装逼，此时的你可以用一台投影仪，连接着你的电脑，把大家谈到的各个散乱需求写在软件中，这个其实是头脑风暴的功能，边开会边合并需求，这其实是亲和图的功能，最后把各种类型的需求合并到一个总的脑图，这才是真正的需求树。这时候，我们该用名义小组或引导技术了，这么多需求画在一个图上的，也让用户们感到压力，因为他们自己一看这么复杂也打了不少退堂鼓。

原来项目将来做出来是这么复杂的鸭，引导他们，还有走名义小组路线啊，不是不让大家畅所欲言，让他们先刷一遍存在感，让他们畅所欲言谈需求好了，当他们自己眼中看到是这么复杂的时候，就不太再会蔓延了。不蔓延了之后，我们就开始砍需求，让大家用名义小组投票每一个需求的重要程度，甚至我们可以用决策的投票技术让大家砍掉不需要的需求。这样的你，既跟用户们互动比较好，也体现了项目管理精神，需求让他们谈，需求也让他们自己去砍，砍完的就是你想要的东西了。

这个需求会议建议从原先的头脑风暴汇总到思维导图，到现在的大家最终定下要做和不要做的需求，两个小时已经过去了。

现在社会，头脑风暴软件已经非常普及，你的装逼程度也就一般，所以应该考虑我们的神器二。

神器二、axure

你让这么多用户参与需求会议，也通过访谈了解了老板们的私密信息，这时候你需要提升的是大家心中你的专业度了，把他们的需求迅速用原型法画出来。如果刚才在需求会议的2小时我们定下需求后，你趁热打铁马上能够画出原型，这会让无数人仰视你，他们心中无数个666。这个软件使用起来并不难，难的是你是否真的有艺术灵感和审美，你并不用把项目交付物全部画出，你只要能够画出基本框架就好。因为这时候的用户，虽然谈了需求，但其实他们脑子里空空无物。只有当你拿出一个雏形出来的时候，他们才会真的联想到是否那就是他们想要的，甚至会触发新的需求。

在需求会的10分钟休息后，你马上画出了他们想要东西的草图，这个图不需要非常逼真，只要有功能和框架即可。之后我们的探讨才真正高效，而你的专业也将赢得用户的信任。你相信么，从这里开始，在他们心中，你已经是一个非常专业和优秀的项目经理了。

此时的项目经理也心累，想想以前做了这么多年技术现在开始要能够画原型图，没办法，因为你越来越贴近用户，没有一技防身咋办呢？

接下来就要搞定团队的人了，我们建议使用神器三。

神器三、wbs chart pro

这款软件我曾经用过，但是貌似近几年在国内并无销售，所以大家可能要花点心思才能找到。对外通过思维导图、exure可以搞定，但是对内就要考虑如何做出这些产品和功能，而我们众所周知项目经理的分工作包的工具叫做WBS，如果你再像以前一样靠手绘或者用PPT绘制，已经不再装逼。另外，我们在能够自伤而下分解到工作包的同时，我们也可以考虑如何把进度自上而下的粗略分解，把成本也自上而下的粗略分解了。

对于一些小型项目来说，是否要画出甘特图其实并不是那么重要，可以用这样子的分解，也可以对每个工作包进行自上而下的估算，其实我们已经可以开工和准备做了。如果大家问我，让项目能够快速的运作起来，还缺少什么，其实就少了任务分配这个维度。

因为wbs chart pro把任务也分解到了工作包，每个工作包也有它自己的开始时间和结束时间，我们接下来可以用EXCEL作一个RACI模型把分工这个功能给加上去，这样，整个项目的前期规划已经是非常完美了。我们已经有了工作包，每个工作包的开始和结束时间，再做一个表，注明谁负责完成这些工作包即可。

本期呢，我没写那么多的心理治愈类的话，也没写项目经理职业观点，我实在一些，教大家项目管理里非常有用的三大神器，不知道你们用过哪一个呢？

欢迎回复和点评，也欢迎大家的指正。

我们下一期见哦~~

如何提问

老邱百问，答你所问。

IT运维管理系统中，信息化管理体系建设包含哪些内容？

IT运维管理体系要真正发挥效益，避免“为技术而技术”，需要融合人、流程、技术。根据信息化的发展要求，配套的管理措施应包括组织模式、管理制度、管理流程、绩效考核、运维费用、技术支撑等内容。

组织模式：中心从全局的角度定位IT运行维护和服务工作，将中心目前分散进行的各项IT运行维护和服务的工作职能逐渐整合，进行集中统一管理，统一调度IT运行维护和服务的技术力量，并结合中心实际情况和管理需要进行配套的组织机构的设置和逐步完善。第一，成立IT运维管理领导小组。初期可以成立由中心领导和各处（室）负责人组成的IT运维管理协调小组，从总体上负责IT运行维护和运维管理的统一组织协调，监督检查各处室服务质量；将来根据IT运维管理发展，可以成立由部领导、中心领导和业务司局领导组成的信息化治理领导小组。第二，建立面向用户的服务接口。初期以服务台为统一服务接口，不断扩充与完善服务台的功能，统一受理客户的IT服务请求，记录事件和一线解决，对解决不了的较为专业的事件派发给专业的二线技术人员，各相关处室提供二线技术支持，并明确相关技术支持人员及职责；将来逐步建立独立的IT运行维护和服务机构（运维中心），专门负责IT运维和服务工作，合理划分建设与运维的边界，实现建设与运维的分离。第三，设置合理的组织机构。初期保持目前组织机构和职责不变，进一步理顺关系；将来随着信息化发展和管理成熟度的不断提升，逐步建立起完全适应体系运行的IT治理组织机构；

管理制度：管理制度是指IT运行维护和服务工作必须遵循的内部管理规定，用于提高工作的协调性和管理的有效性。借鉴IT运维管理体系国际标准标准ISO20000要求，管理制度分为 “总办法”、“分办法”、 “实施细则或 *** 作指南”和“配套表单”四个层次，见图13－6。

资料来源：中国IT治理研究中心（ITGov），网址：>

项目管理工作中遇到棘手问题？个人职业发展遭遇瓶颈？也许你需要一个导师为你答疑解惑。

老邱百问板块就是为此而设，主要关注项目管理和职业发展领域，给大家一个提问的平台，并有机会得到老邱的亲自解答，同时将问答分享，以供大家交流借鉴。

老邱百问，答你所问

question

提问者：卓君

提问：互联网偏技术的职位，做的较多的是公司内部的需求或项目，学了pmp后如何转到真正的项目经理

老邱解答

如果你已经是PMP，那么你一定对PMBOK的过程有所了解，很想把PMBOK所学到的知识运用与日常工作和日常项目中。项目管理人都是有项目管理思维的，比方项目立项管理、项目规划管理、项目执行管理、项目收尾管理，其实在我们日常工作中，还有很多PMBOK中都会提到非常实用的三大工具，今天我在这一篇文章里就给大家介绍项目经理的三大神器！我们也运用场景给大家介绍这三大神器的使用方法。

神器一、mindmanager

项目立项了，我们的章程已经发布，所有人都知道你已经被任命为项目经理了，当你摸不清头脑应该如何往下做的时候，PMBOK被打开了。原来，制定项目章程之后，你必须要完成项目管理计划了，但是该计划中这么多子计划让你无从下手。。。

不急，听我慢慢道来！

项目是由一个商业机会触发，而这些商业机会早已写在商业论证中，也在立项之前明确，在你的项目章程中也应该有高层级的目标和范围。作为项目经理的你，应该继续触发需求管理，项目管理的交付五花八门，有的是实现一个新产品，有的是为客户部署一个产品功能，有的是做企业内部交付，有的甚至只是单单一个流程优化。此时的你，大可不必惊慌，因为我们项目管理的方法是一样的，我们收集需求的工具和方法其实大多相同。

1、产品类项目。

这类项目的项目经理需要有敏锐的用户视角，你很清楚，你的产品设计的好坏会直接影响到用户的购买。所以，获得需求的样本量越大，对你的产品设计和研发越是有帮助。而这时的你要知道，产品设计数据是王道，所以需要大量问卷调查进行统计分析，跟团队进行头脑风暴，抽取样本开焦点小组及引导式研讨会等，甚至还需要考虑到发起人可能会有私人想法，然后对其运用访谈技术。

2、部署类产品。

部署类产品相对来说比较成熟，客户和用户的定位比较明确，他们的购买或者使用思路比较清晰，如上线一个ERP，又如部署一个基站做5G的升级。那么作为部署类项目的项目经理来说，建议使用的一些需求工具如：跟客户一起头脑风暴，开焦点小组会议，或者是引导式研讨会，然后对一些部门主管进行访谈等。

3、内部交付类、流程优化类项目。

你的用户群可能就是公司的某一些业务部门，需求样本量相对较少，你也不一定需要类似问卷这种大样本工具，我们建议使用：头脑风暴、焦点小组、引导式研讨会等，去触发用户对于需求的表明。

无论在哪种模式下，这时候的项目经理一个开始头大了，需求越来越多，也越来越搞，早知道不跟这些用户开会了，他们又不懂，个个考虑自己的私利以自己为中心，而不是项目产品为中心了。PMBOK 又教我们我们可以用亲和图、名义小组、引导等方式给需求进行排序和分类，这样不至于使用户们提出的各种需求都纳入到我的项目范围。项目资金是有限的，项目经理不可能在有限的资源做出无限的功能。

这种类型的需求工作会议，开多了就样样蔓延，开少了呢又怕遗漏需求。这时候，你完全可以使用这个神器，mindmanager。它集成了头脑风暴、亲和图、名义小组等各个工具的优势，当大家在谈每一个需求的时候，如果你用白板写出来还是不够装逼，此时的你可以用一台投影仪，连接着你的电脑，把大家谈到的各个散乱需求写在软件中，这个其实是头脑风暴的功能，边开会边合并需求，这其实是亲和图的功能，最后把各种类型的需求合并到一个总的脑图，这才是真正的需求树。这时候，我们该用名义小组或引导技术了，这么多需求画在一个图上的，也让用户们感到压力，因为他们自己一看这么复杂也打了不少退堂鼓。

原来项目将来做出来是这么复杂的鸭，引导他们，还有走名义小组路线啊，不是不让大家畅所欲言，让他们先刷一遍存在感，让他们畅所欲言谈需求好了，当他们自己眼中看到是这么复杂的时候，就不太再会蔓延了。不蔓延了之后，我们就开始砍需求，让大家用名义小组投票每一个需求的重要程度，甚至我们可以用决策的投票技术让大家砍掉不需要的需求。这样的你，既跟用户们互动比较好，也体现了项目管理精神，需求让他们谈，需求也让他们自己去砍，砍完的就是你想要的东西了。

这个需求会议建议从原先的头脑风暴汇总到思维导图，到现在的大家最终定下要做和不要做的需求，两个小时已经过去了。

现在社会，头脑风暴软件已经非常普及，你的装逼程度也就一般，所以应该考虑我们的神器二。

神器二、axure

你让这么多用户参与需求会议，也通过访谈了解了老板们的私密信息，这时候你需要提升的是大家心中你的专业度了，把他们的需求迅速用原型法画出来。如果刚才在需求会议的2小时我们定下需求后，你趁热打铁马上能够画出原型，这会让无数人仰视你，他们心中无数个666。这个软件使用起来并不难，难的是你是否真的有艺术灵感和审美，你并不用把项目交付物全部画出，你只要能够画出基本框架就好。因为这时候的用户，虽然谈了需求，但其实他们脑子里空空无物。只有当你拿出一个雏形出来的时候，他们才会真的联想到是否那就是他们想要的，甚至会触发新的需求。

在需求会的10分钟休息后，你马上画出了他们想要东西的草图，这个图不需要非常逼真，只要有功能和框架即可。之后我们的探讨才真正高效，而你的专业也将赢得用户的信任。你相信么，从这里开始，在他们心中，你已经是一个非常专业和优秀的项目经理了。

此时的项目经理也心累，想想以前做了这么多年技术现在开始要能够画原型图，没办法，因为你越来越贴近用户，没有一技防身咋办呢？

接下来就要搞定团队的人了，我们建议使用神器三。

神器三、wbs chart pro

这款软件我曾经用过，但是貌似近几年在国内并无销售，所以大家可能要花点心思才能找到。对外通过思维导图、exure可以搞定，但是对内就要考虑如何做出这些产品和功能，而我们众所周知项目经理的分工作包的工具叫做WBS，如果你再像以前一样靠手绘或者用PPT绘制，已经不再装逼。另外，我们在能够自伤而下分解到工作包的同时，我们也可以考虑如何把进度自上而下的粗略分解，把成本也自上而下的粗略分解了。

对于一些小型项目来说，是否要画出甘特图其实并不是那么重要，可以用这样子的分解，也可以对每个工作包进行自上而下的估算，其实我们已经可以开工和准备做了。如果大家问我，让项目能够快速的运作起来，还缺少什么，其实就少了任务分配这个维度。

因为wbs chart pro把任务也分解到了工作包，每个工作包也有它自己的开始时间和结束时间，我们接下来可以用EXCEL作一个RACI模型把分工这个功能给加上去，这样，整个项目的前期规划已经是非常完美了。我们已经有了工作包，每个工作包的开始和结束时间，再做一个表，注明谁负责完成这些工作包即可。

本期呢，我没写那么多的心理治愈类的话，也没写项目经理职业观点，我实在一些，教大家项目管理里非常有用的三大神器，不知道你们用过哪一个呢？

欢迎回复和点评，也欢迎大家的指正。

我们下一期见哦~~

如何提问

老邱百问，答你所问。

it行业产品经理（尤其是创业的）需要懂技术吗

产品经理是一个产品的灵魂缔造者；一个产品从无到有，再到上线的整个过程涵盖调研、需求、设计、 开发、测试、策划和市场等环节，在这所有环节中产品经理对这个产品有着主导地位。所以还是要懂一些技术问题的。

希望可以帮到您，谢谢！

产品经理（尤其是创业的）需要懂技术吗？懂到什么程度？

产品经理当然要懂技术，不能因为不需要敲程式码就不去了解技术，

所以产品经理的懂技术需要技巧：

1、先知道你的产品需要哪些技术

2、弄清楚几种技术之间的关系

3、了解每种技术的基本逻辑

4、遇到不懂得问题积极和技术工程师探讨，不要不懂装懂

5、先从产品逻辑理解技术，然后用技术逻辑进行反推

产品经理也要忌讳对技术的深入钻研，因为那样的话容易导致从技术工程师的角度出发，产品经理也很吃亏往往就是什么都懂什么都不精，但是这也是产品经理的特色。

做产品这几年，和开发工程师打交道最多，和他们交流通常有两大忌： 一忌不懂技术 有常识，当然不一定就能做出好产品，但没常识，就很象在村里呆了半辈子的人乍到城市，一举一动即使小心翼翼，也没法儿不透著突兀和不和谐。 很多公司都有完全不懂技术的产品人，大多年龄较长，也许是网际网路出现的时候，他们已经过了充满好奇和渴望未知的年龄，不愿意放低身段去学习新东西，喜欢只凭着想象和自己的生活经验就开喷，间或以若干近期热门关键词作为点缀，以示自己尚蹲在潮流尖端。 二忌懂技术 我遇到不少工程师喜欢说：“只要产品需求明确，技术上一切都能实现。” 这句话听起来相当豪迈，也让产品经理大为放心，觉得技术真是产品的坚强后盾。但其实传递了一个特别糟糕的讯号。 当工程师这么说的时候，潜台词是：“你弄好你自己的事儿就行了，别来管我！”而且这种说法隐含着一个乐观但显然并不现实的假设：技术是无所不能的，他（掌握技术的人）也象灯神一样，可以实现你的任何愿望，只要你能明确的描述它。 我不知道阿拉丁说完愿望之后，假如胆敢继续追问灯神将具体采用何种技术方案来实现的话，会不会被塞到灯里，但我知道很多工程师在发现你关注技术层面过深的时候，都会有种领地被侵犯的感觉。 这就是工程师维护自己专业槽的本能，与行业中其它角色相比，工程师地位不是最高，待遇也不是最好，还经常加班加的要死要活的，唯一得天独厚的优势，就是专业槽比任何角色都深。关于产品、关于UI、甚至关于商业模式每个从业人员都能喷上几句，要是说到使用者体验，那更是连业外人士都敢大喷特喷而没有任何心理负担：反正我就是使用者嘛，越傻越光荣。而一旦涉及到程式码，大多数人就直接晕菜了。想想那些UI设计师的苦逼段子，工作时没有喷子们指手划脚的干扰，真是上帝赋予工程师独有的恩赐。 所以当他们认为有外人正试图跨越这条槽时，自然会有所警惕，甚至体现出抵制和敌意。当一个产品经理发现工程师开始比较密集的使用术语或拼命把简单问题往复杂了说，你应该知道，他们在槽边开始向你射箭了。 从整个产品乃至公司的角度来说，各个专业角色之间的专业槽都是应该被填平的，产品经理不该对工程师玩挟天子以令诸侯，不要总假装自己是使用者的三个代表，动不动就拿想象中的“使用者需求”当“奉天承运”来用；工程师也不必总装灯神，假装无所不能很累的，工程师之间必有能力高下之分，其实有时候功能做不了或做不好，纯粹只是因为工程师能力所限。如果彼此坦诚一些，大可以提前有效沟通，尽可能避开那些投入产出比过低的部分，有不少工程师不愿意拿出来讨论的技术实现上的细节，都是值得产品经理参与进来的，在这些细节上如何取舍与抉择，会对产品的开发进度、效能甚至功能带来极大的影响，如果沟通到位，往往可以让开发工程师少做大量无用功。在我开始自己动手写程式码之后，对这一点有了越来越深的体会。

IT行业产品经理都需要掌握哪些技能呢？需要学习些什么呢？

去市场多转转吧 你会收获的不只是书上能看到的

网际网路产品经理需要懂得哪些技术

首先 敏锐洞察力，

产品经理的技术；

网际网路行业分析能力

网际网路营销，策划能力

……

产品经理需要懂哪些知识？

产品经理的分类：

1、从行业的角度来分有：智慧硬体、移动医疗、sass、O2O、社交、电商、视讯等等

2、从终端的角度来分有：移动端、WEB端、PC客户端、TV端等

3、从职能的角度来分有：功能型产品经理、创新型产品经理、互动体验型产品经理、专案管理型产品经理、技术型产品经理、商业产品经理

4、从前后台来分有：前台产品经理、后台产品经理、平台产品经理

每个型别的产品经理，对应的要求其实都是不一样的，做产品经理的人，其实还是很有必要了解，并且想清楚未来的发展方向。

产品经理的基本能力要求：

1、对网际网路行业有一定发现趋势与预测能力：

作为一个产品经理第一项能力就要求对行业有一定发现趋势和预测的能力，这样的能力主要要有对行业很有一定深度的了解，能对网际网路产品做出有效判断，才能发现一些行业趋势，做出有效的判断，主要通过，使用者，资讯，互动，产生了网际网路新产品。

2、分析管理使用者的需求能力：

在做了大量市场调研后，就要对使用者的需求经行一个分析，分类，将其基本划分为个体需求和群体需求，把表现需求提炼出本质需求，把各个需求分门别类，做好评估优先，例如打井是为了水，如果有好的办法解决能够简单的得到水的这个需求就是通过了分析做出了本质的展示

3、能够判断市场的需求价值：

做了需求统计和分析后，那些需求是有价值，这个价值就是商业的价值，那些需求是有使用者数量，这就要对需求的市场价值做出评估和判断，从而在得出一个很好的市场价值需求，然后通过研发产品解决这个问题满足使用者。

4、超强沟通能：

对于产品经理来说多数说的最多的就是沟通能力了，市场调研中对使用者需求的沟通，怎么沟通交流才能得到使用者的需求本质，从中很快的知道哪些需求是有商业价值的需求，在产品出现的时候要对团队的沟通，对设计团队的沟通，对研发团队的沟通等等的沟通，对领导的沟通，总之要面对很多的环境下的交流与能达到一个很好的结果才是一个优秀的产品经理所要具备的沟通能力。

5、有一定团队管理能力：

在公司企业内部要对每一个团队能有一定管理方针与制度才能达到一个产品的目标，团队的计划，工作的安排，专案的跟进，分工的明确，最终的目标达成，人员的管控，都是在衡量著产品经理的成功因素。

6、综合知识分析能力：

在上述中基本就能看出产品经理基本就是个大杂烩，要具备的能力太多了，但这还远远不够，他还要求对多个知识领域都要一定的了解，作为一个综合知识人才。

7、对周边资源整合能力：

做出一个好产品不光要有对使用者的了解，对团队的管理，还要有对周边的资源能够整合，有没有一个影响力圈子，在行业，使用者，程式，测试，运营，推广，销售，管理，都有一个小圈子作为后盾形成力量，做一个有多数资源人脉的产品经理。

网际网路行业产品经理的月薪一般是多少

看入职年限和工作经验,

刚入职的10k左右,

工作经验丰富业绩好的30-50k的较多

这个问题问得太泛，5k到50k都有

一看具体的产品，二看公司，二看个人能力

每个行业的产品经理定义不同，薪水自然也就不同。

比如软体行业产品经理是负责与客户沟通需求，月薪在15k左右（听说，请指正）；

网站产品经理主要是产品设计，月薪从10k到几十k不等（也是听说）；

游戏研发产品经理还可以理解为游戏制作人，月薪在15k到几十k不等(这个我知道)；

游戏运营的产品经理有负责专案的整体运营，月薪同上

综述，每个职位、每个行业都有产品经理，工作职责、工作范围和技能要求都不同。不能一概而论。

以上就是关于如何编写IT项目方案.ppt全部的内容，包括:如何编写IT项目方案.ppt、it包含的产品线有什么、银行的业务系统如何适应市场需求的变化以及需要哪些IT系统的支持，需具体等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！