软件需求案例分析及阅读资料

软件需求是软件开发的最重要的一个输入，需求风险也常常是软件开发过程中最大的一个风险，降低需求风险的一个重要手段就是需求评审，但是需求评审是所有的评审活动中最难的一个，也是最容易被忽视的一个评审。笔者曾经历过以下的几种失败的需求评审： 案例一 某领域专家A先生就某企业的成本管理系统做用户需求报告的评审工作，在评审会开始时间不长，就被在场的某企业的一位副总B先生打断，认为A先生提出的方案不适合本企业，A先生提出的管理改进方案在企业中无法实施。该副总提完意见后，与会的用户方人员纷纷跟随B先生的提出了他们的反对意见，致使评审会无法再进行下去，最终该报告被用户否决。 案例二 某软件公司内部举行产品的需求评审会，主要是公司内部的相关领域的专家参加，在评审会开始后不久，某领域专家就对需求报告中的某个具体问题提出了自己的不同意见，于是，与会人员纷纷就该问题发表自己的意见，大家争执不下，结果，致使会议出现了混乱状况，主持人无法控制局面，会议大大超出了计划评审时间。 案例三 某软件公司为某公司A做业务流程管理系统的需求评审会，当项目组人员在会议上宣读多达上百页的需求报告时，用户明确提出听不懂，致使会议不得不改日进行。 案例四 某软件公司在用户处开完物资管理系统的需求评审会后，与会人员在离开会议室时纷纷摇头，认为本次会议没有多少实际效果，完全是在走过场。 案例五 某软件公司在公司内部举行产品的需求评审会时，需求报告的执笔人与产品策划的主要策划人员的想法差别很大，致使需求评审会没有必要继续进行下去。 以上的现象可以在很多项目中都可以看到。概括起来，在需求评审中常见的问题是： 需求报告很长，短时间内评审者根本就不能把需求报告读懂、想清楚； 没有作好前期准备工作，需求评审的效率很低； 需求评审的节奏无法控制； 找不到合格的评审员，与会的评审员无法提出深入的问题； 那么究竟如何做好需求评审呢？建议一：分层次评审 我们知道用户的需求是可以分层次的，一般而言可以分成如下的层次： 目标性需求：定义了整个系统需要达到的目标； 功能性需求：定义了整个系统必须完成的任务； 操作性需求：定义了完成每个任务的具体的人机交互； 目标性需求是企业的高层管理人员所关注的，功能性需求是企业的中层管理人员所关注的，操作性需求是企业的具体操作人员所关注的。对不同层次的需求，其描述形式是有区别的，参与评审的人员也是不同的。如果让具体的操作人员去评审目标性需求，可能会很容易地导致“捡了芝麻，丢了西瓜”的现象，如果让高层的管理人员也去评审那些操作性需求，无疑是一种资源的浪费或者就会出现案例三的情形。 建议二：正式评审与非正式评审结合 正式评审是指通过开评审会的形式，组织多个专家，将需求涉及到的人员集合在一起，并定义好参与评审人员的角色和职责，对需求进行正规的会议评审。而非正式的评审并没有这种严格的组织形式，一般也不需要将人员集合在一起评审，而是通过电子邮件、文件汇签甚至是网络聊天等多种形式对需求进行评审。两种形式各有利弊，但往往非正式的评审比正式的评审效率更高，更容易发现问题。因此在评审时，应该更灵活地利用这两种方式。 建议三：分阶段评审 应该在需求形成的过程中进行分阶段的评审，而不是在需求最终形成后再进行评审。分阶段评审可以将原本需要进行的大规模评审拆分成各个小规模的评审，降低了需求返工的风险，提高了评审的质量。比如可以在形成目标性需求后进行一次评审，在形成系统的初次概要需求后进行一次评审，当对概要需求细分成几个部分，对每个部分进行各个评审，最终再对整体的需求进行评审。 建议四：精心挑选评审员 需求评审可能涉及的人员包括：需方的高层管理人员、中层管理人员、具体操作人员、IT主管、采购主管；供方的市场人员、需求分析人员、设计人员、测试人员、质量保证人员、实施人员、项目经理以及第三方的领域专家等等。在这些人员中由于大家所处的立场不同，对同一个问题的看法是不相同的，有些观点是和系统的目标有关系的，有些是关系不大的，不同的观点可能形成互补的关系。为了保证评审的质量和效率，需要精心挑选评审员。首先要保证使不同类型的人员的都要参与进来，否则很可能会漏掉了很重要的需求。其次在不同类型的人员中要选择那些真正和系统相关的，对系统有足够了解的人员参与进来，否则很可能使评审的效率降低或者最终不切实际的修改了系统的范围。 建议五：对评审员进行培训 在很多情况下，评审员是领域专家而不是进行评审活动的专家，他们没有掌握进行评审的方法、技巧、过程等，因此需要对评审员进行培训，同样对于主持评审的管理者也需要进行培训，以便于参与评审的人员能够紧紧围绕评审的目标来进行，能够控制评审活动的节奏，提高评审效率，避免发生案例一和案例二中出现的现象。对评审员的培训也可以区分为简单培训与详细培训两种。简单培训可能需要十几分钟或者几十分钟，需要将在评审过程中的需要把握的基本原则，需要注意的常见问题说清楚。详细培训则可能要需要对评审的方法、技巧、过程进行正式的培训，需要花费较长的时间，是一个独立的活动。需要注意的是被评审人员也要被培训。 建议六：充分利用需求评审检查单 需求检查单是很好的评审工具，需求检查单可以分成两类：需求形式的检查单和需求内容的检查单。需求形式的检查可以由QA人员负责，主要是针对需求文挡的格式是否符合质量标准来提出的，需求内容的检查是由评审员负责的，主要是检查需求内容是否达到了系统目标、是否有遗漏、是否有错误等等，这是需求评审的重点。检查单可以帮助评审员系统全面地发现需求中的问题，检查单也是随着工程财富的积累逐渐丰富和优化的。 建议七：建立标准的评审流程 对正规的需求评审会需要建立正规的需求评审流程，按照流程中定义的活动进行规范的评审过程。比如在评审流程定义中可能规定评审的进入条件、评审需要提交的资料、每次评审会议的人员职责分配、评审的具体步骤、评审通过的条件等等。通过评审流程执行可能会避免出现案例五之类的问题。 建议八：做好评审后的跟踪工作 在需求评审后，需要根据评审人员提出的问题进行评价，以确定哪些问题是必须纠正的，哪些可以不纠正，并给出充分的客观的理由与证据。当确定需要纠正的问题后，要形成书面的需求变更的申请，进入需求变更的管理流程，并确保变更的执行，在变更完成后，要进行复审。切忌评审完毕后，没有对问题进行跟踪，而无法保证评审结果的落实，使前期的评审努力付之东流。 建议九：充分准备评审 评审质量的好坏很大程度上取决于在评审会议前的准备活动。常出现的问题是，需求文档在评审会议前并没有提前下发给参与评审会议的人员，没有留出更多更充分的时间让参与评审的人员阅读需求文档。更有甚者，没有执行需求评审的进入条件，在评审文档中存在大量的低级的错误或者没有在评审前进行沟通，文档中存在方向性的错误，从而导致评审的效率很低，质量很差。对评审的准备工作，也应当定义一个检查单，在评审之前对照检查单落实每项准备工作。 在实践中细心体会、实施上述的9个建议，相信您定会受益非浅。案例正文：一个项目经理在开发一个为期10个月的项目的三个星期后得到客户通知，项目要在不增加成本，不影响范围和质量的情况下，需要在8个月内完成，项目经理应该怎么做？分析：一、了解客户计划改变的真实原因在做项目的很多时候，客户方会要求项目在不增加成本，不影响范围和质量的情况下，提前完成，但是一定有他的理由，也许是你的竞争对手采取的措施，也许是我们在做项目的时候有哪些不对的地方，或者是客户遇到新的其他情况不等，但是在客户提出之后，不能明确的答应也不能以强势的态度拒绝，等了解真正的原因后再做打算。二、向客户沟通假如必须提前完成任务，要向客户说明其困难，假如公司真的有实力，那就答应他，并适当的拿出合同进行说明，是否在其他方面给予公司补偿。如果公司的把握不是很大，那就站在客户的立场为他考虑，本来十天完成的任务现在8天完成，困难时什么，结果会怎么样，是否采取，按照客户的要求完成部分功能，比如为了迎接上级领导检查，那就把系统的表面工作都做好，要是真正的使用的话，那就把不影响工作进行的部分往后推迟等等，一个项目实施后，所有功能在一定的时间都能使用上的几率不是很大，另外也可以采用在主要功能方面做好，次要方面稍往后放等等方法。三、从公司本身出发在不影响范围和质量的情况下，提前完成，我们只有在加班或加人中选择，但是一定要谨慎，因为加人是存在一定的风险的，毕竟项目已经进行了3个月。假如公司实在没有办法的话，那就把部分较独立的功能模块外包出去，当然这是下下策了。四、团队的管理在这个时候，一定要在团队的管理方面做好工作，无论从人员的到位，还是人员的情绪，或者其他方面等等做到恰到好处。Clearnet公司是国外一家知名的IP电话设备厂商。它在国内拥用许多电信运营商客户。Clearnet主要通过分销的方式发展中国的业务，由国内的合作伙伴和电信公司签约并提供具有增值内容的集成服务。 2000年，国内一家省级电信公司（H公司）打算上某项目， 经过发布RFP（需求建议书）以及谈判和评估，最终选定Clearent公司为其提供IP电话设备。立达公司作为Clearent公司的代理商，成为了该 项目的系统集成商。立达公司是第一次参与此类工程。H公司和立达公司签订了总金额近1000万元的合同。李先生是该项目的项目经理。 该项目的施工周期是三个月。由Clearnet负责提供主要设备，立达公司负责全面的项目管理和系统集成工作，包括提供一些主机的附属设备和支 持设备，并且负责项目的整个运作和管理。Clearnet和立达公司之间的关系是外商通常采用的方式：一次性付账。这就意味着Clearnet不承担任何风险，而立达公司虽然有很大的利润，但是也承担了全部的风险。合同是固定总价的分期付款合同，按照电信业界惯例，10%的尾款要等到系统通过最终验收一年后才能支付。 3个月后，整套系统安装完成。但自系统试运行之日起，不断有问题暴露出来。H公司要求立达公司负责解决，可其中很多问题涉及Clearent的设备问题。因而，立达公司要求Clearent公司予以配合。Clearent也一直积极参与此项目的工作。 然而，李先生发现，立达对H公司的承诺和技术建议书远远超过了系统的实际技术指标，这与Clearent与立达的代理合同有不少出入。立达公司 也承认，为了竞争的需要，做了一些额外的承诺。这是国内公司的常见做法，有的公司甚至干脆将尾款不考虑成利润，而收尾款也成了一种专职的公关工作。这种做 法实质上增加了项目的额外成本，同时对整个的商业行为构成潜在的诚信危机。 对于H公司来说，他们认为，按照RFP的要求，立达公司实施的项目没有达到合同的要求。因此直至2002年，H公司还拖欠立达公司10%的验收款和10%的尾款。立达公司多次召开项目会议，要求Clearent公司给予支持。但由于开发周期的原因，Clearent公司无法马上达到新的技术指标并满足新的功能。于是，项目持续延期。为完成此项目，立达公司只好不断将Clearenet公司的最新升级系统（软件升级）提供给H公司，甚至派人常驻在H公司（外地）。 又经过了3个月，H公司终于通过了最初验收。在立达公司同意承担系统升级工作直到完全满足RFP的基础上，H公司支付了10%的验收款。然 而，2002年底，Clearent公司由于内部原因暂时中断了在中国的业务，其产品的支持力度大幅下降，结果致使该项目的收尾工作至今无法完成。 据了解，立达公司在此项目上原本可以有250万元左右的毛利，可是考虑到增加的项目成本（差旅费、沟通费用、公关费用和贴现率）和尾款，实际上的毛利不到70万元。如果再考虑机会成本，实际利润可能是负值。 导致项目失败，尤其是项目预期的经济指标没有完成，这是非常遗憾的事情。项目失败或没有达到预期的经济指标的因素有很多，其中风险管理是一个极为重要的因素。 在上面的案例中，项目的利润值最后可能是负值就是这样的情况。而该项目最终失败的原因主要在于风险控制和风险处理机制。 在很多IT项目中，由于竞争和其他原因造成了风险过度集中在某一个相对弱势的角色身上。在本案例中，立达公司就处于这样的境地：一方面它需要依赖代理Clearent公司的产品生存，另一方面要它还必须要满足用户的具体需求。 我们知道，项目经理有识别和处理风险的责任。通常，项目经理在运作这样的项目时，要充分考虑到自己公司所处的地位，充分发挥自己的作用，平衡各方的利益。 事实上，项目管理知识体系中关于风险管理方面有非常详细的论述。不过，在实际工作中，如果完全照搬国外项目管理的风险识别和控制理论，是很难达到较好的效果。 一般来说，对于国内公司的项目经理来说，除了理解项目管理知识体系中的理论外，还需要在实践中进行总结。在这里，介绍一些容易被忽视的地方。 签合同前的“需知” 一般情况下，如果项目经理在项目合同签订以前加入项目，可以充分利用项目采购管理一章的知识，了解自己公司在项目中的位置，对买方提出的RFP 认真回答，规避潜在的风险，这是非常重要的。对于RFP中过高的要求不能完全满足时，应充分说明，并在以下几个方面有充分的准备和考虑： 1合同的类型。 通常，在IT项目中，代理商与最终用户的合同类型是很难改变的固定价格合同，但对代理商和设备商之间的合同是有很多讲究的。代理商和国外供货商一般是通过信用证付款，但很多时候，为了拿到订单，供货商通常给予代理商一定的信用额度和付款方式的优惠。代理商应充分利用这一利害关系，在合同签订以前决不能轻易让步。 2项目实施方对项目的熟悉程度。 通常情况下，做一个成熟项目的风险小，而做新项目的风险高。在本案例中，立达公司是第一次进行类似的项目，并不完全了解其中的风险，更无可利用的历史数 据。因此，在这种情况下，最好采用“让利于人，风险共担”的策略。具体做法是，将已经识别的具有风险的部分外包(即风险转移)，或者单独与供货商签订补充 合同。这样做可能损失了部分利益，但降低了风险，并且减少了很多额外投入。 3具有明确的规范（Specification），包括设计规范（Design）、功能性规范（Functional）、性能规范（Performance）。 明确的规范是识别风险和规避风险的前提条件。如果已经具有一定的历史数据，可以采用头脑风暴的方式对规范加以确认和识别，这项工作可与风险识别同时进行。 风险的预警和量化 在项目的进行过程中，项目经理和项目的拥有人要将风险管理纳入日常工作的重要步骤。要明确成本与风险、成本与时间的关系。在制定完善的风险管理计划的基础上，从以下几个方面入手。 1建立管理风险预警机制。 对于风险集中的一方，建立管理风险预警是风险管理计划的重要补充。这里的预警是指对有可能超出项目经理管理范围的风险事件的预警。预警机制可由低到高，并 由定期的项目联席管理（多方）会议讨论处理。这样可以减少处理风险事件的响应时间；同时，使高层管理者能够及时介入，处理可能产生的风险。 2风险的量化。 之所以单独将风险的量化加以论述，是因为很多情况下，项目经理的确已经对风险进行了识别，并采取了应对措施，但并未对此风险带来的影响进行量化（通常可以 以货币或者时间损失加以估算）。量化过的风险是项目经理采用相应对策的前提。像在本例中，立达公司了解Clearent公司升级软件不能按时提供，这本身 就需要量化。这个风险带来的就是10%的验收款和10%尾款的不能按时支付。如果一开始，立达公司能够将付款和风险对应起来，就知道该风险是管理风险，并 且是不能够接受的。 总之，风险集中的项目管理起来是极为复杂的。要尽量在第一时间把事情考虑好，不能指望风险小的一方替风险大的一方承担很多责任。尤其是目前进入中国市场的国外企业很多，情况复杂，IT市场的变化有时很难预测，更应该注意风险带来的影响。 如何启动项目? 本文向大家介绍，在项目启动时应该做哪些准备工作。 赵晓东的烦恼某公司的赵晓东最近心里挺烦。公司前一段签了一个100多万的单子，由于双方老板很熟，且都希望项目尽快启动，在签合同时也没有举行正式的签字仪式。合同签完，公司老总很快指定赵晓东及其他8名员工组成项目组，由赵晓东任项目经理。老总把赵晓东引见给客户老总，客户老总在业务部给他们安排了一间办公室。 项目进展开始很顺利，赵晓东有什么事都与客户老总及时沟通。可客户老总很忙，经常不在公司。赵晓东想找其他部门的负责人，可他们不是推托说做不了主，就是说此事与他无关，有的甚至说根本就不知道这事儿。问题得不到及时解决不说，很多手续也没人签字。 项目组内部问题也不少，有的程序员多 次越过赵晓东直接向老板请示问题；几个程序员编的软件界面不统一；项目支出的每笔费用，财务部都要求赵晓东找老板签字。赵晓东频繁打电话给老板，其他人心 里想，赵晓东怎么老是拿老板来压人。由此，赵晓东与项目组其他人员和财务部的人员产生了不少摩擦，老板也开始怀疑赵晓东的能力。 赵晓东的遭遇相信很多项目经理都亲身经历过，尤其是刚刚开始做行业客户的公司，往往是公司的老板和客户单位的某个主管关系不错或业务人员关系做 得很到位，公司老板希望赶紧做完项目，因此，常常跳过项目启动环节，直接指令项目经理进入实施阶段。结果项目刚开始就麻烦不断。正所谓“好的开始是成功的 一半”。做项目启动是为了形成一个良好的沟通体系，让所有与项目相关的人都理解项目的重要性，同时形成一个由双方老总、项目负责人和项目组成员所构成的三 级沟通体系，确保项目管理的畅通。 造势：创造良好的施工环境 现在很多项目都涉及到用户业务应用的软件开发，在实施中要跟用户的各个层面打交道，但现实往往是用户单位的员工根本不了解IT公司在给自己的企业做什么，因此，签合同时有必要召开一个正式的仪式，向双方员工传递项目的信息，激发公司全体员工对项目的热情。IT公司老板、项目负责人、开发人员、施工人员和用户方的领导、项目协调人、相关部门人员聚在一起，让大家知道双方的合作正式开始。仪式上，双方领导要讲话，特别是用户方的领导要强调项目的意义。据说联想上ERP项 目时就专门召开了全体员工誓师大会，柳传志亲自到会讲话，把ERP项目摆到关乎企业生死存亡的高度，并亲手将一面大旗授予ERP项目的负责人。柳传志还 说，有人说现在上ERP是找死，但现在不上那就是等死，我们与其在这里等死，为什么不去拼搏一把呢？事实证明，这不仅极大地鼓舞了项目组成员的斗志，同时 也使全体员工明白这不仅仅是信息部门的事，而是公司从上到下都要关心的事。 通过这个仪式，双方要组成指导小组或项目管理委员会，由双方总经理牵头，项目负责人为执行人，日常联系由双方指定人员。在签合同时，利用双方人 员到齐的机会，IT公司要把软件功能用通用、专业的语言和用户方的领导、技术人员、业务负责人进行最后确认，因为此时有分歧改正的成本不大。同时，还可使 双方人员彼此认识，清楚各个层次的接口，大家混个脸熟，以后打交道就会更通畅。 项目签字仪式可以在用户单位举行（可以节约用户方时间），也可以在酒店举行。要注意：签字仪式要精心组织，场地要大一些，为双方沟通营造一个好 的环境。会前，每个模块负责人要明确自己的客户接口，要找机会和对方单独聊，拉近彼此间的关系。另外，会场上双方老板的融洽气氛会对项目的实施具有一种震 慑作用。 尚方宝剑：明确责权利 项目签字仪式是造外势。在公司也要造内势，让各个部门都知道这个项目能为公司创造哪些经济效益，明确项目组人员和项目负责人，确定项目负责人的 权限。公司财务、采购、人事、技术、销售等部门都要参加，这样才能创造一个良好的内部服务体系，让项目组把主要精力放在为用户服务上。公司内部要召开项目组成立会，会上最重要的就是颁布一个“项目宪章”，包括项目的内容、项目负责人权限、项目团队成员、项目时间周期、项目需要的设备、 资金等，在宪章规定的范围内，项目经理比总经理大，与此相关的事情，由项目经理负责。这样，人事部在项目实施期间，就可以按照宪章规定，由项目经理来调动 项目人员，而设备采购（往往不是一次性采购，而是根据项目进度购买，这样可以省钱）也就不需要一次次找总经理，只要是宪章规定范围内的，由项目经理签字就 可以了。尤其是在软件开发上，项目组成员一定要清楚用户的需求，不能擅自答应用户增加功能，因为这会带来很大的风险（后面几节我们会具体探讨）。 项目宪章必须由总经理和项目经理签字，并在会上宣读。为了增强团队凝聚力，可以在会上举行项目组宣誓或誓师宣言，形成“成则举杯相庆，败则拼死相救”的团队精神。内部造势不仅可以让各个部门了解项目，创造条件服务项目组，而且可以给项目组成员以压力和动力，意识到项目的意义和团队精神的重要性。项目宪章对项目经理来说就是一把尚方宝剑，联想ERP项目组的幸运就在于一开始就拿到了这把尚方宝剑，而这正是海正公司的赵晓东没有拿到的东西。 在项目宪章的基础上，公司应该形成具体的项目任务书，细分到各部门、个人，发到总经理、专家小组、开发部、财务部、市场部销售部、行政人力资源部等。 营造了内外两个良好的环境，项目启动就是水到渠成的事，项目组成员就可以集中精力投入到实施中去，项目的成功也有了更大的保证。 最后，要提醒项目经理特别注意：在项目合同确定的最后一刻，还要对合同进行最后的审定，合同审定一定要聘请一位专业律师，对合同的一些关键细节进行“咬文嚼字”的审定。 专家 点评 一个项目的成功启动绝不是靠项目组或项目经理就可以的，必须具备内部和外部两个条件，所以，双方的一把手都要高度重视，尤其是在目前中国的公司文化环境下，项目经理需要“项目宪章”作为尚方宝剑，而用户方的信息主管同样需要自己领导的讲话精神作为尚方宝剑。 案例背景：某CRM项目，已经到了试运行阶段，原计划下周二验收。这时PM得知对方主管领导下周三要出国考察，想到对方可能没有心思准备验收的工作，便与对方沟通后把验收时间改到领导回国以后。却不料领导考察了国外的先进管理思想以后，回来决定大幅修改自己的业务管理模式，原有的CRM内容因此有大半失去作用。项目几乎等于要重头再来一次。 请问：遇到这种情况该如何处理？相关分析：重视计划永远是正确的，甚至要想办法让条件成熟的后续工作提前开始。这个案例中的PM就犯了错误。领导要出国，没心思召开验收会是正常的。但是PM应该有很多办法来促成项目的及时验收。 例如说找各业务主管对各模块分别书面签字验收，然后只需要领导最后签字确认即可。或者找公司领导汇报，争取一笔资金，找个名目通过SALES交给领导（通常情况下项目都有回扣点数），同时谈谈马上验收的事宜。反正是在计划安排的时间内，这种顺水人情领导当然乐意。 而且，对于领导去做业务考察这件事，PM居然没有联想到跟自己项目业务的关联，敏感度太低。项目团队如何拥有高的协调性案例正文：徐家龙最近被公司任命为项目经理，负责一个重要但不紧急的项目实施。公司项目管理部为其配备了7位项目成员。这些项目成员来自不同部门，大家都不太熟悉。徐家龙召集大家开启动会时，说了很多谦虚的话，也请大家一起为做好项目出主意，一起来承担责任。会议开 的比较沉闷。项目开始以后，项目成员一有问题就去找项目经理，请徐家龙给出意见。徐家龙为了树立自己的权威，表现自己的能力，总是身体力行。其实有些问题 项目成员之间就可以相互帮助，但是他们怕自己的弱点被别人发现，作为以后攻击的借口。所以他们一有问题就找经理，其实徐家龙的做法也不全对，成员发现了也 不吭声，因为他们认为我是按你说的做的，有问题你经理负责。 团队成 员之间一团和气，“找徐经理去”、“我们听你的”成为了该项目团队的口头禅。但随着时间的推移，这个貌似祥和和团结的团队在进度上很快出现了问题。该项目 由“重要但不紧急的项目”变成了“重要而且紧急的项目”。项目管理部意识到问题的严重性，派高级项目经理张凤指导该项目的实施。 请问： 该项目问题出在哪里？ 徐家龙应该怎么做？ 分析：1.项目经理的定位我们先澄清一个概念：什么是项目经理。项目经理就是项目中的总经理，总经理的职责是决策，领导。而不是关注所有的事情。本案例中的项目经理犯的错误在我们身边屡见不鲜，其根源最主要在于：1)项目经理定位不准2）团队无明确的沟通计划2.只竖向沟通不横向沟通显然不行作为项目经理,你应该要引导成员相互横向沟通后，无法解决的再竖向沟通或开会协商；这就好比民主集中制，要民主，也要有人说了算，案例中项目经理都是自己拿主意，但他不可能在每方面都是长处，长此以往，团队形成一种风气，压力全转移到项目经理处，项目风险也会越来越大。3.职责、团队、方法论一个成功的团队是指由不同技能,才华,工作风格和知识的成员组成的士气高涨的团队.项目经理的职责就是将这些人组成团队并激励他们. 项目经理的技能应包括技术技能和管理技能,坚实的技术基础能够在技术方面对团队起指导作用,管理技能有助于沟通和解决问题.管理技能不仅限于技术方面,还 包括解决问题的能力,估算能力,编制计划的能力,人际和沟通能力.所以本案例出现的问题本质是项目经理对自己的职责没有很好的认识，因此在管理团队的方法 上也就走了偏路。问题从项目组成员形成了一个习惯（有事找徐.)，失去了团队的协做意义，使团队的实际能力得不到体现；到最后使得项目进度出现严重延 迟。在某公司的项目管理课堂上，小李，小王等人正在七嘴八舌地议论纷纷。原来，大家正在讨论小王的公司最近遇到的两个颇为有趣的项目。据小王介绍，这两个项目分别由两个项目经理来担任。其中，项目经理A属于“谦虚”型，对于客户提出的问题，无论大小都给与解决，客户对此非常满意，然而，项目进度却拖得比较长，而且，客户总想把所有的问题都改完再说，项目已经一再延期。相比之下，项目经理B显得稍有些“盛气凌人”，对于客户提出的问题，大多都不予理睬，客户对此不是很满意，不过，该项目的进度控制得比较好，基本能够按期完成项目。话刚一说完，小李就抢着说：“A比较像我，一般在和我的一些战略客户打交道的时候，我基本是有求必应，与客户的关系处得如鱼得水，这样做肯定不会错。就像前天我连合同都写错了，找到客户，人家二话没说就同意改了。你说如果是B的话可能吗？”小王对此不以为然，“对项目经理来说，成本、质量和时间是最为重要的三要素。与客户的关系当然很重要，但也要全盘考虑项目的各要素。对于用户的要求，应该在有限的范围内给与解决，但不可以做出太大的牺牲。一味的迁就用户将会使整个项目失败。”小林接着小王的话说：“当前，国内的项目一般情况下是由销售处面签单，再由项目经理接手后续的工作，因此客户关系多在事前已经搞定。发生新的情 况后，可以由公司的公关部出面与客户进行协调，项目经理可以在此过程中坚持一下原则，与公司的公关部一个红脸，一个白脸，唱出一出好戏。”小赵反驳道：“不管怎样，客户才是第一位的。客户可以给你带来收入，也可以给你带来更多的客户和工作，有什么道理不多配合一下他们呢？说实话我对B的做法蛮欣赏的，可惜行不通。因为客户是上帝，如果照B的做法，后果会造成做一次项目丢掉一个客户，太不划算了。” 问题：1、如果你的项目遇到需求变更问题，你会采用哪种方式去应对？ 2、分析这两种应对需求变更方式的优缺点。如果纯粹说顾客就是上帝，客户是我们的衣食父母，那么A的就是这种。尊重客户并不意味着迁就客户，毕竟我们比客户要专业，那么我们就必须拿出我 们专业的一面，如果客户有需求变更我们就答应，那么也许这个项目永远也做不完。但是如果我们采取对客户不理不睬的态度，客户一个电话打给公司高层领导，那 么我们肯定也是吃不了兜着走了，必须要用合理的心态来看待需求变更。避免问题发生的人永远都比解决问题的人来得可贵。那么对待需求变更，我们也应该从避免变更做起。这样项目初期的需求范围说明书的确认签字及需求变更流程的确定就显得无比的重要的。需求变更应该纳入合同的体系中，明确规定项目允许需求变更的次数和范围，如果发生重大变更在商务上如何处理，明确权责。做好充分的需求调研、分析工作。面对需求变更，平静的面对，仔细的分析，能拒绝则拒绝，不能拒绝则积极的接受，和客户明确此次变更将产生的影响，让客户自己来权衡利弊。案例正文：一个项目经理在开发一个为期10个月的项目的三个星期后得到客户通知，项目要在不增加成本，不影响范围和质量的情况下，需要在8个月内完成，项目经理应该怎么做？分析：一、了解客户计划改变的真实原因在做项目的很多时候，客户方会要求项目在不增加成本，不影响范围和质量的情况下，提前完成，但是一定有他的理由，也许是你的竞争对手采取的措 施，也许是我们在做项目的时候有哪些不对的地方，或者是客户遇到新的其他情况不等，但是在客户提出之后，不能明确的答应也不能以强势的态度拒绝，等了解真 正的原因后再做打算。二、向客户沟通假如必须提前完成任务，要向客户说明其困难，假如公司真的有实力，那就答应他，并适当的拿出合同进行说明，是否在其他方面给予公司补偿。如果公司的把握不是很大，那就站在客户的立场为他考虑，本来十天完成的任务现在8天完成，困难时什么，结果会怎么样，是否采取，按照客户的要求 完成部分功能，比如为了迎接上级领导检查，那就把系统的表面工作都做好，要是真正的使用的话，那就把不影响工作进行的部分往后推迟等等，一个项目实施后， 所有功能在一定的时间都能使用上的几率不是很大，另外也可以采用在主要功能方面做好，次要方面稍往后放等等方法。三、从公司本身出发在不影响范围和质量的情况下，提前完成，我们只有在加班或加人中选择，但是一定要谨慎，因为加人是存在一定的风险的，毕竟项目已经进行了3个月。假如公司实在没有办法的话，那就把部分较独立的功能模块外包出去，当然这是下下策了。四、团队的管理在这个时候，一定要在团队的管理方面做好工作，无论从人员的到位，还是人员的情绪，或者其他方面等等做到恰到好处。某高科技芯片制造企业，研发项目负责人跳槽，辞职几天前报告过一次项目进度完成50%，预算花费50%，而接手人上任后，报告项目进度完成30%,预算花费50%，还有一个关键技术问题无法突破。 1，他们为什么会有不同说法; 2, 你对该企业有什么建议。 他们为什么有不同说法： 1，客观因素上考虑： a,从进度角度来看：高科技研发项目风险高，进度影响因素大，不可控性较强，造成项目进度无法完全按照主观计划量化,对进度看法可能会有不同； b,从预算投入角度来看：研发经费投入非线性，可能前期经费投入较大，后期减少. 2，从利益因素上考虑： a,从跳槽者利益出发： 因利益影响存在道德风险： -谎报进度，为与新东家的谈判争取时间和筹码 -把重要研发成果拿走，带入新东家 b,从接替者利益出发： 因利益影响存在误报可能： -希望能够压报进度，争取经费和时间； 能够在“危机”情况下出成果，升职加薪的谈判筹码c,从项目团队其他人的利益出发; 因利益影响存在欺蛮可能: -有意隐瞒项目成果进度，为自己在公司争取地位提供筹码 -跳槽者安排在原东家的“针”，等待重要技术攻关成果； 对该公司的建议 短期危机处理应对： 成立专项小组评估项目真实进度/费用情况，应注意： 1，小组成员应该同时包括该项目项目组内外人员，建议提议接替者为小组执行组长，分管研发的领导任组长； 2，小组的主要职能还应该包括针对项目组留下人员的思想工作； 3，小组工作目标是评估内外部环境，提出继续/中止该项目的具体建议； 4，对于创新型研发项目技术攻关，评估能否引入外部(政府，学校，企业联合研发)资源完成攻关。 长期来看，应建立下述体制： 1，建立完善的研发管理标准和机制，约束项目经理权力和信息独占权，建议成立跨部门的研发进度里程碑汇报制度； 2，对于研发涉及人员，需要签订保密协议，竞业协议，必要的时候诉诸法律手段； 3，建立危机应急管理体系，明确同类事件重遇时的处理流程； 4，建立人才梯队，可实验双项目经理负责制度 5，争取国家创新基金支持，高校/企业合作，使得夭折的项目技术攻关能够继续；1 项目描述某年，B计算机公司(以下简称B公司)了解到A企业要建设一个客户服务中心，向客户提供有关本企业产品的咨询、查询、委托、投诉等服务，并希望能够尽可能采用各种计算机和通信技术，为客户提供快速、准确和渠道多样(包括电话、传真、WEB、邮件等)的服务。1.1 背景客户服务中心在国内至多属于萌芽状态。A企业的原有业务运作只有一小部分采用计算机处理，而且原来并不存在客户服务中心这样的机构。B公司擅长的领域是典型的基于UNIX与TCP/IP的交易处理系统，对于建立客户服务中心所需要的CTI知识知之甚少，WEB开发也从来没有尝试过。总而言之，这是个新领域，在机会存在的同时，风险也非常大。1.2 结果B公司在项目中采用多种从未使用过的技术和产品：Browser/Web Server/Database Server结构、CTI技术、排队机，并独立开发语音传真服务器，最后按时完成项目。该项目的完成为后续合作奠定基础，在第二年很快就签署二期合同。无论是客户还是公司，都对项目的结果表示满意;项目成员也对能参与这个项目表示高兴。2 项目过程那么，B公司是如何成功完成这个充满风险的项目呢?项目完成后，公司及客户都认为，因为有一个合格的项目经理。接下来，我们就看看在项目实施过程中项目经理做了哪些事?2.1 起始阶段在项目意向明晰后，项目经理首先做的事情是：查阅资料，确定助手，制定下一步计划。查阅资料主要分两方面：一方面是客户服务中心的技术实现，一方面是A企业的业务运作。助手的主要工作内容是在技术和业务方面与项目经理有互补作用。下一步的计划就是：和客户面对面的沟通，了解客户的期望以及对项目的认知情况，了解客户的业务;进一步了解相关技术;编写方案建议书。这三方面的工作都是非常重要的，查阅资料表明项目经理意识到项目的难关和风险在哪里，并开始采取措施去规避风险;确定助手为组建项目实施团队奠 定基础;下一步计划的目的就是要定义项目，其用途是尽可能使A企业和B公司的各自期望能够吻合，这会为项目的成功奠定基础。需要注意的是，项目定义对任何 一个项目来说都是第一位的，是否以书面形式出现倒在其次，但是作为项目经理，一定要清楚客户认为的项目成功标志是什么?也要清楚项目团队到底能够为客户提 供什么样的产品或服务?如果不能吻合，那么至少有一方在这个项目中要尝到失败的滋味。在和A企业沟通的过程中，项目成 员本着“三人行必有我师”的态度，向客户学习业务知识，掌握相应的业务术语，同时也和主要人员保持良好的关系。这些，都为随后项目实施中和客户的流畅沟通 奠定基础。其实，很多项目的失败就在于IT人员只是从IT出发去看项目，这是非常狭隘的，IT说到底，只是业务运作所应用的工具而已，要发挥作用，必须找 到与业务流程的结合点，否则各是各的，即使项目在技术实现上非常完美，也是废物一堆。业务和IT本身并没有很多矛盾，矛盾更多的存在于业务人员和IT人员 的相互沟通和理解上。在这个阶段，项目经理还 有两件事做得非常好，一个是让公司高层领导重视这个项目，从而获得公司高层的支持，这对随后项目实施过程中得到其它部门的配合是非常重要的;一个是和销售 经理形成良好的分工合作关系，各自完成份内工作，并注意时刻分享项目信息。在许多项目中，项目人员和销售人员往往是隔离的，甚至是对立的，最后往往只能走 向失败。2.2 执行阶段在合同签署后，项目经理和助手留任并组建实施团队。这样做的好处是项目信息不会损耗。当然，在很多公司中，售前的项目经理和售后的项目经理是分开的，那么很重要的一个工作就是公司要有规范的文档管理，以保证项目信息的最大保留。项目经理在经过分析之后，从各部门抽调人员组成项目团队，然后召开第一次项目会议，根据公司现实情况做了鼓励和动员，通报项目的目标和时间，分派相应的职责给每一个人。由于项目中采用很多新技术，每个成员又都有具体的任务，新鲜感和责任感使得这个团队的氛围远好于公司同期其它项目。同时，项目经理也注意到把销售经理吸收到项目组中，事实证明，有销售经理的积极配合，与客户的沟通工作就变得容易多了。具体的项目组织结构和角色如下。 鉴于项目成员的经验并不丰富，项目经理发挥自己对技术的总体把握能力，随时了解项目成员的技术熟悉进展，并给予必要的指导和帮助，最终成功规避新技术带来的风险。在项目组织结构和角色确定后，项目经理组织“系统架构设计师”成员共同工作，在基于先前提交的计划基础上，进一步细化WBS(工作细分结构)和项目的实施计划。此据使得项目组的骨干人员的积极性得到最大的调动，同时也帮他们树立权威，使项目工作得以齐头并进。这个项目的WBS(工作细分结构)如下：在计划制定之后，项目的成功与否就要看计划的执行，以及针对实际情况进行应变的能力。相对于技术人员，项目经理的工作重点是调度资源、监督和控制进度、指导工作。项目经理和各方面人员的沟通是确保项目顺利进行的有效手段。俗话说：兵马未动，粮草先行。在项目实施中，除了人员到位，项目经理对各项资源的及时到位给予高度重视，注意和行政部门、商务部门配合，准备开发机房和各种设备软件;在需要到A企业开发软件和安装设备时，也事先通知和确认相应条件。碰到有的设备不能到位，就寻找变通办法。有的项目失败就在于项目经理只是从技术观点看项目管理，甚至认为这些内容应该是销售或者别的部门要事先准备好，殊不知最清楚的还是项目团队本身，最后往往会因为这些事情而影响项目的工作氛围，甚至是导致项目的延期。根据项目的情况，项目经理确定应用软件的开发分两阶段：第一阶段是完成功能开发，第二阶段是界面确认和性能优化。确保软件开发更容易控制。由于第一阶段是在B公司内部开发，因此各项进度还比较顺利，但是到了第二阶段，因为在现场开发，客户的参与程度有很大的提高，虽然对项目实施的人力资源有 一定补充，但也带来明显的弊病(最初项目成员都没有意识到)，因为参与的客户人员会随时向项目组成员提出些修改要求，开始时项目成员有求必应，后来发现有 的要求很有必要的，但有的要求则是很不成熟，来回变了好几次，尤其是随着项目的进展，对项目的不利影响越来越大。项目经理在和项目成员仔细沟通后，和销售 人员商量对策，最后向客户“晓之以理，动之以情”，说服客户：以合同为前提，如果确有必要修改，客户应尽量考虑成熟，但所有变动要以书面的正式形式通知项 目经理。这样，问题很快就得到控制。当然，能够达到这样的效果有一个很重要的前提是：项目组的工作一直是有成效的，得到A企业的信任。许多项目做着做着，作为承担项目实施的一方往往就失去客户的信任，从而在碰到问题时很难取得客户的理解和支持，最后就只能埋怨客户故意刁难。在项目实施的过程中，内部成员之间也出现过一些问题，比如彼此工作习惯的不同，甚至一些纯属个人范畴的事情也会被引入到项目中，从而对项目的工 作气氛产生不良影响。项目经理在一开始就注意和所有项目成员有非正式的沟通渠道，注意倾听他们的述说，使各自的情绪能够有排遣的空间;定期召开正式的会议，通报项目的进度、问题、新的计划等，确保项目运行在统一的方向上;不定期聚餐，活跃项目气氛;树立公正客观的工作环境，求异存同，使每个成员都有被尊重的感觉。有的项目往往只关注技术实现，而不关注成员的心理感受，使得工作效率降低，最后导致项目不能按时保质完成。鉴于项目涉及的无论是业务领域还是技术领域都是新鲜的，因此项目经理倡导有原则的让客户积极参与项目实施工作，其好处是：对于客户，项目实施是透明的，提高了客户对B公司的信任度最终用户的积极介入，使得软件更适合业务需要，也更容易获得客户满意度通过和最终用户的密切配合，B公司更好的了解业务需要，为以后拓展其它类似企业的市场储备有关知识和人力资源。2.3 结束阶段在项目的执行阶段，项目经理主要关注的工作内容包括：总结和移交存档各种资源(如设备、文档等)，其目的是使得公司能够不断积累有关的知识。对软件产品的发展提出建议，供公司领导决策，其目的是为继续拓展市场做准备。项目成员工作的表彰和最后聚会，一方面是对成员工作的认可，另一方面是提高成员对实施项目的认同感，“高兴而来，满载而归”。3 总结分析其实，任何一个项目在执行过程中都会碰到问题的，评价一个项目是否成功并不能以碰到问题的多少作为标准，其标准应是按时、保质实现预先确定的各项指标，比如说系统的功能、系统的性能等等。在这个项目中，也碰到很多问题，比如：客户的需求变化资源的到位成员的冲突等这些问题是大部分项目都会碰到的，解决起来其实很简单，请看：客户需求变化。理解客户业务，使用客户的语言，站在客户的角度思考问题，取得客户的信任;这样最后客户也会站在你的角度替你思考问题的。其实，大部分客户都是通情达理的，问题在于我们实施项目时迈出的每一步。资源的到位。理解尊重相关部门或合作伙伴的工作，从而让他们也理解尊重我们的工作并配合我们;获得领导的支持;原定资源不能到位时，不要一条路走到黑，一定可以找到替换办法的。成员冲突。还是那个原则理解和尊重，在项目中倡导互相的理解尊重，求异存同。求异有两方面含义：一是纯属个人空间，这样会使项目色彩更丰 富;一是项目工作中，每个成员的职责都是不同的。类似的，存同也有两方面含义：一是发掘共同的爱好和话题，缩短彼此距离;一是工作中的共享部分，一定要有 严格的相同标准。对于项目经理，除了掌握必备的项目基本方法和管理工具(如计划制定、预算编制等)，对项目背景和目标有清楚的理解和认识外，很重要的一点就是与 人交往的技巧了。成功项目经理和失败项目经理的最大差别，可能就在于如何和人打交道，如何和客户打交道，如何和公司领导打交道，如何和项目成员打交道。信息化建设中的甲方项目启动管理 案例：A公司是国内领先的IT设备制造厂商，经过多年的企业信息化实践，网络基础建设和办公自动化建设已经具备相当的规模，并取得了良好的应用效果。同时，以ERP/SCM/CRM为主体的信息化应用架构也初步建成，此外作为提高产品创 新能力的产品数据管理系统（PDM）也在建设当中。随着公司研发业务管理的不断深化，对产品研发的项目管理提出了更高的要求。虽然公司整体的研发项目管理 体系尚未形成，但研发管理部门仍然希望将部分研发项目的核算用信息化手段来实现，以提高核算准确度。紧迫的需求提到了公司信息化项目部门 的面前。过去的几年，公司在信息化建设方面的投入巨大，难免有一些急于上马的项目投入与产出并不十分理想。而且由于市场环境的迅速变化，相应的业务模式也 在不断的改变，从而给信息化系统的适应性提出了相当高的要求。过去的有些项目启动时期没有很好地考虑到这些问题，造成一些项目盲目启动、盲目建设，建成后 才发现已经不适应业务的变化。因此，公司对于项目上马的决策已经趋于理性，严格要求做好项目启动前的论证工作。在满足当前紧迫的业务需求和长远的战略需求 之间作好平衡。确保项目建设的成功。小W作为信息化项目部任命的项目启动管理的负责人，着手处理该项目启动前的论证工作。小W发现，这个需求在年初规划时 并没有提出项目意向，属于规划外的项目。在与业务部门的沟通中，他发现业务部门对于整体项目管理的模式并不十分清晰，目前需要解决的项目核算问题仅仅是项目管理中非常具体的一个需求，至于项目其它方面的管理，以及如何与产品开发过程结合起来，如何利用产品数据管理系统等等，都没有考虑。项目建设的系统只是一个项目管理的临时解决方案。对方案的风险也没有进行详细的分析。而业务部门认为需求已经十分清晰，项目的价值也是毋庸置疑的，至于以后怎样与研发平台的 产品数据管理系统结合起来，那要等立项后，做出了详细的方案才会有答案。此外，业务部门还推荐了几个产品供应商，希望能尽快选定产品，开展实施。如果在立 项环节出现延误，影响了业务的开展，信息化项目部要承担责任。小W认为业务的要求十分无理，需求、方案、投入产出、风险，以及业界的产品情况等很多问题都 还没有清楚，根本谈不上选型。沟通过程中，业务对小W的工作极为不满，向信息化项目部经理进行了投诉。 在这个案例中，反映了目前企业信 息化项目启动管理中的普遍问题。业务一旦产生信息化需求，总是非常急迫地希望能立刻上马。而从信息化项目管理的角度，如果盲目、仓促地上马信息化项目，往 往导致项目的投入产出分析不清，项目重复建设，组织混乱，给后期的项目实施，项目维护，项目使用带来极大的风险，甚至导致系统建成后被用户弃用。最终使业 务遭受损失。 本案例中，作为企业的信息化部门，在项目启动管理的重要性方面已经有了较为理性的认识，但是在应用中不被业务部门理解，从而导致矛盾的激化。这是双方对项目启动管理的过程没有达成统一的认识。 相对产品供应商而言，企业在项目建设中处于合同意义上的甲方，其项目的启动过程与乙方的项目管理有很大的不同，是一个较为复杂的过程。它往往需要考虑一系 列的问题，如：需求是否合理？是否有必要启动项目？项目可能带来的影响是什么？可能的投入有多大？取得的效益有多大？当前的管理模式是否能支撑？如果不 能，可能要在哪些方面做好变革的准备？业界相关的产品有哪些？哪些是真正适合需求的？ 因此，对项目启动管理形成统一的认知，对于实施信息化项目的企业有着非常重要的意义。 一般来说，项目的启动管理可以划分为以下几个阶段： 一、意向提出阶段 在意向提出阶段，业务部门发现需要由信息化手段来实现的业务需求，并提出建设信息化系统的期望。由于信息化项目的意向伴随着业务发展的全过程，因此，对于意向的统筹管理与规划对企业的信息化部门始终是一个难题。对于有集中业务规划期间的企业，意向的产生经常集中在业务规划期间，比如：财年末，业务对自身的模式进行盘点期间，往往产生业务模式的改进或改革的需求，从而对信息化工具产生需求。在这一时间产生的想法或需求，往往不是很成熟，不确定性很大，后期变化的风险也很高。但这一时期，也是意向最集中，最易于统筹规划的时期。信息化部门通常在这一时期，对所有的意向进行收集，分类整理，初步形成项目建设清单。并考虑公司战略重点与资源投入的约束，对项目进行排序，以确定建设重点。 对于不在集中规划时期提出的项目意向，正如案例中出现的一样，往往会影响到原有的整体规划与计划，各方面的论证更应谨慎，比如，项目的必要性、投入的合理性、资源到位的可能性，对已建和在建系统的影响等等。