吉宁讲师观点 / 企业培训师观点 / 企业培训师观点:CIO进行需求分析的十项基本法则

企业培训师观点:CIO进行需求分析的十项基本法则

企业培训师吉宁 2015年12月11日 企业培训师观点

文章来源:世界经理人

如果CIO尝试着问一些愚蠢问题,例如:“以我的理解,你们收到订单后,会……”。业务人员立刻就会指出你的错误,并开始滔滔不绝谈论业务,这一招就叫“抛砖引玉”。开发人员与业务部门的交流需要好的方法。下面建议10条法则,开发人员和业务部门可以通过评审以下内容并达成共识;如果遇到分歧,可通过协商达成对各自义务的相互了解,以便减少日后的摩擦。
  
先导入管理思想,再梳理业务流程
  
“百闻不如一见,百见不如一尝。”没有亲历过信息化建设的人,对信息化的理解总是比较肤浅,甚至包括一些管理层成员。如上ERP系统时,如果一开始就让业务部门谈需求,业务人员谈得通常是当前工作中的困难或者希望实现的功能等;CIO必须从转变观念入手,先给业务部门导入信息系统所包含的管理思想,然后协助业务部门梳理业务流程。
  
表达要符合业务部门语言习惯
  
  需求讨论集中于业务需求和任务,必然使用各种业务术语。如果开发人员是IT厂商,CIO应将有关业务术语教给开发人员,同时还要把IT人员常用的一些术语“翻译”给业务人员,做到交流畅通无阻。
  
  了解业务部门的业务及目标
  
  只有充分了解业务部门的具体业务,才能开发出满足其需求的软件。为充分了解业务人员的具体需求,CIO要和开发人员一起到业务部门去观察他们的实际工作流程,甚至与业务部门一起工作一段时间。如果是旧系统切换到新系统,CIO还要亲自用一下目前的旧系统,明白目前系统是怎样工作的,了解其流程情况以及可供改进之处等。
  
  掌握各种沟通技巧
  
  需求分析的过程实际上是个沟通的过程,CIO要想方设法吸引业务人员说出其需求。有时候,尝试着问一些“愚蠢”的问题也有助于用户打开话匣子。如果CIO直接要求业务人员写出业务是如何实现的,十有八九无法完成;但如果尝试着问一些实际的问题,例如:“以我的理解,你们收到订单后,会…”。业务人员立刻就会指出你的错误,并滔滔不绝的开始谈论业务,这一招就叫“抛砖引玉”。
  
  对业务需求进行逻辑分析
  
  业务人员对需求的表达通常是笼统、感性、琐碎的,CIO要尽量理解业务人员用于表述他们需求的思维过程,充分研究用户执行任务时决策的过程,并抽象出潜在逻辑关系,把一些“常识”性东西用逻辑来实现。例如,当IT人员与护士交流医嘱处理过程时,护士会告诉IT人员,护理级别有特级护理、一级护理、二级护理、三级护理以等;饮食又分流食、半流食、禁食等种类。如果仅仅把护士的要求用计算机语言表达出来,就可能出现同一个病人既是一级护理又是二级护理,既吃流食又吃半流食的可笑情况;这些矛盾的避免原来是靠护士的大脑来判断的常识性问题,而用计算机来判断“常识”是最难的,也是最容易忽视的。经过反复探索,协和医院信息中心主任李包罗抽象出了一个互斥组的概念。特级、一级、二级、三级护理组成一个互斥组,当护士选择特级护理的时候,自然排斥了一级、二级和三级护理。李包罗说:“在与医生、护士沟通的过程中,IT人员不是要成为临床专家或者护理专家,而是要用IT知识去梳理医生护士的要求,变成一种计算机可以实现的概念,超越了手工的功能才会受到业务部门的欢迎。”
  
  以通俗的语言编写软件需求报告
  
  IT人员应将从业务人员那里获得的所有信息进行整理,以区分业务需求及规范、功能需求、质量目标、解决方法等,然后编写软件需求报告。“需求分析报告”是IT人员和业务人员之间针对要开发的产品内容达成的协议。报告应以一种业务人员认为易于翻阅和理解的方式组织编写;报告中可以大量使用图表,但必须向业务人员解释清楚每个图表的作用、符号的意义和需求开发工作的结果,以及怎样检查图表有无错误及不一致等。
  
  描述产品的使用特性
  
  业务人员可以要求IT人员在实现功能需求的同时还注意软件的易用性,因为易用性或质量属性能使客户更准确、高效地完成任务。例如业务人员有时要求产品要“界面友好”或“健壮”、“高效率”,但对IT人员来讲,太主观了并无实用价值。IT人员可以通过询问和调查了解客户所要的“友好、健壮、高效”所包含的具体特性,具体分析哪些特性对哪些特性有负面影响,在性能代价和所提出解决方案的预期利益之间做出权衡,以确保做出合理的取舍。
  
  业务人员和IT人员互相尊重
  
  如果业务人员与IT人员不能相互尊重,那关于需求的讨论将会遇到障碍。参与需求分析的业务人员有权要求IT人员尊重他们并珍惜他们为项目成功所付出的时间;但业务人员也要尊重IT人员的需求可行性及成本评估。所有软件功能都是有成本的,业务人员所希望的某些产品特性可能在技术上行不通,或者实现它要付出极高的代价,而某些需求试图达到在操作环境中不可能达到的性能,或试图得到一些根本得不到的数据。IT人员会拒绝或实现不了业务人员的一些要求,业务人员也应该尊重IT人员的意见。
  
  有需求变更要立即联系
  
  不断的需求变更,会给在预定计划内完成的产品质量带来严重的不利影响,但需求变更又是不可避免的。在开发周期内变更越在晚期出现,其影响越大;变更不仅会导致代价极高的返工,而且工期将可能被延误,特别是在主体架构已完成后又需要增加新特性时。所以,一旦客户发现需要变更需求时,请立即通知IT人员。
  
  需求确认仅仅是以后讨论的“基线”
  
  在“需求分析报告”上签字,通常被认为是业务部门同意需求分析报告的标志性行为,然而在实际操作中,业务人员往往把“签字”看作毫无意义的事情。有时这个领导同意了,那个领导却不同意;即使每个相关人员都签了字,也照样“翻供”,通常的理由是:“他们要我在需求文档的最后一行签名,于是我就签了,否则他们不开始编码!”同样的问题也发生在仅把“签字确认”看作是完成任务的IT人员身上,一旦有需求变更出现,便指着“需求分析报告”说:“您已经在需求分析报告上签字了,所以这都是按照您的要求开发的。”-这两种态度都是不对的,因为业务人员不可能在项目早期就能说清楚所有业务需求,变更需求是必然现象。在“需求分析报告”上签字确认,仅仅是需求分析过程结束的标志,它意味着“需求分析报告”是以后讨论的基线,进一步的变更可在此基线上通过项目定义的变更过程来进行。
  
  拨开需求分析的迷雾,将给初步的需求开发工作画上双方都明确的句号,将有助于形成一个持续良好的客户与开发人员的关系,为项目成功奠定坚实的基础。

About 企业培训师吉宁

真正的实战派企业培训师,长期致力于人力资本、公司行为、市场营销、企业战略及领导力发展等组织实践与研究,数十年来参与及主持过的管理咨询项目累计逾千次;受邀主讲过的各类企业培训课程累计逾万次。吉宁老师还主导编写了12Reads系列等知名管理培训教材。