|
历尽千辛万苦，终于签署合同，IT供应商拿到了用户提供的几页“需求书”;然后就凭借自己的理解立即投入开发，等生米熬成粥才发现满足不了用户需求，接下来就是艰难、反复地修改，最后开发人员厌倦了，用户也厌倦了，当然项目款也遥遥无期。这样的案例可谓比比皆是!项目管理者联盟
比起不成功的项目，一个成功的项目在开发者和客户之间往往采取了更多交流方式;IT供应商不仅与终端用户或潜在用户群交流，而且对用户感性、朴素的认识进行抽象，提取出潜在逻辑关系，准确把握客户的真正需求，然后才进行软件开发。作为项目开发者和最终用户之间的“桥梁”，CIO如何推进开发人员和终端用户的“对接”?如何从用户笼统、感性的描述中抽象出潜在逻辑关系?项目管理者联盟
拨开需求“迷雾”项目管理者联盟
业务部门的主管甚至CIO经常试图代替终端用户说话，但通常又无法准确说明“用户需求”。用户需求来自产品的真正使用者，必须让实际用户参与到收集需求的过程中;否则，产品很可能会因缺乏足够的信息而遗留不少隐患。项目管理者联盟
需求分析是软件开发和项目管理的基础，但业务部门经常三言五语就把开发人员“打发”了，业务人员笼统、感性的描述对开发人员来说就像“雾里看花”，一些开发人员只好按照自己的理解去写CODE。要拨开需求分析的“迷雾”，就要先了解需求分析的“程序”。项目管理者联盟
需求分析包括业务需求、用户需求、功能需求、非功能性需求和需求分析报告等。业务需求反映了组织机构或客户对系统、产品高层次的目标要求，通常在项目定
义与范围文档中予以说明;用户需求描述了用户使用产品必须要完成的任务，应在使用实例或方案脚本中予以说明;功能需求定义了开发人员必须实现的软件功能，
使用户利用系统能够完成他们的任务，从而满足业务需求;非功能性的需求描述了系统展现给用户的行为和执行的操作等，它包括产品必须遵从的标准、规范和约
束，操作界面的具体细节和构造上的限制等;需求分析报告所说明的功能需求充分描述了软件系统所应具有的外部行为，在开发、测试、质量保证、项目管理以及相
关项目功能中起着重要作用。talent.mypm.net
业务部门的主管通常阐明“业务需求”，即产品的高层次概念和主要业务内容，为后继工作建立指导性框架;但“业务需求”并不能为开发人员提供开发所需的许多细节说明。“用户需求”必须找系统的最终使用者，他们最清楚要使用该产品完成什么任务和一些非功能性的特性需求，如程序的易用性、健壮性和可靠性等，而这些特性将会使用户很好地接受具有该特点的软件产品。业务部门的主管甚至CIO经常试图代替终端用户说话，但通常又无法准确说明“用户需求”。用户需求来自产品的真正使用者，必须让实际用户参与到收集需求的过程中;否则，产品很可能会因缺乏足够的信息而遗留不少隐患。项目管理者联盟
在实际需求分析过程中，由于业务部门工作很忙，经常没有时间或者觉得没有必要与IT人员讨论需求分析，有时甚至希望IT人员无须讨论和编写需求说明就能说出用户的需求。除非遇到的需求极为简单;否则千万不能这样做。项目管理者联盟
优秀的软件产品建立在优秀的需求分析基础上，而优秀的需求分析又源于客户与开发人员之间有效的交流和合作。只有双方参与者都明白自己需要什么、成功的合作需要什么时，才能建立起一种良好的合作关系。项目管理者联盟
十项基本法则项目管理者联盟
如果CIO尝试着问一些愚蠢问题，例如：“以我的理解，你们收到订单后，会……”。业务人员立刻就会指出你的错误，并开始滔滔不绝谈论业务，这一招就叫“抛砖引玉”。项目管理者联盟
开发人员与业务部门的交流需要好的方法。下面建议10条法则，开发人员和业务部门可以通过评审以下内容并达成共识;如果遇到分歧，可通过协商达成对各自义务的相互了解，以便减少日后的摩擦。bbs.mypm.net
①先导入管理思想，再梳理业务流程。项目管理者联盟
“百闻不如一见，百见不如一尝。”没有亲历过信息化建设的人，对信息化的理解总是比较肤浅，甚至包括一些管理层成员。如上ERP系统时，如果一开始就让业务部门谈需求，业务人员谈得通常是当前工作中的困难或者希望实现的功能等;CIO必须从转变观念入手，先给业务部门导入信息系统所包含的管理思想，然后协助业务部门梳理业务流程。项目经理博客
②表达要符合业务部门语言习惯pmp.mypm.net
需求讨论集中于业务需求和任务，必然使用各种业务术语。如果开发人员是IT厂商，CIO应将有关业务术语教给开发人员，同时还要把IT人员常用的一些术语“翻译”给业务人员，做到交流畅通无阻。项目管理者联盟
③了解业务部门的业务及目标training.mypm.net
只有充分了解业务部门的具体业务，才能开发出满足其需求的软件。为充分了解业务人员的具体需求，CIO要和开发人员一起到业务部门去观察他们的实际工作流程，甚至与业务部门一起工作一段时间。如果是旧系统切换到新系统，CIO还要亲自用一下目前的旧系统，明白目前系统是怎样工作的，了解其流程情况以及可供改进之处等。项目管理者联盟
④掌握各种沟通技巧项目管理者联盟文章
需求分析的过程实际上是个沟通的过程，CIO要想方设法吸引业务人员说出其需求。有时候，尝试着问一些“愚蠢”的问题也有助于用户打开话匣子。如果CIO直接要求业务人员写出业务是如何实现的，十有八九无法完成;但如果尝试着问一些实际的问题，例如：“以我的理解，你们收到订单后，会...”。业务人员立刻就会指出你的错误，并滔滔不绝的开始谈论业务，这一招就叫“抛砖引玉”。项目管理者联盟
⑤对业务需求进行逻辑分析项目管理者联盟
业务人员对需求的表达通常是笼统、感性、琐碎的，CIO要尽量理解业务人员用于表述他们需求的思维过程，充分研究用户执行任务时决策的过程，并抽象出潜在逻辑关系，把一些“常识”性东西用逻辑来实现。例如，当IT人员与护士交流医嘱处理过程时，护士会告诉IT人
员，护理级别有特级护理、一级护理、二级护理、三级护理以等;饮食又分流食、半流食、禁食等种类。如果仅仅把护士的要求用计算机语言表达出来，就可能出现
同一个病人既是一级护理又是二级护理，既吃流食又吃半流食的可笑情况;这些矛盾的避免原来是靠护士的大脑来判断的常识性问题，而用计算机来判断“常识”是最难的，也是最容易忽视的。经过反复探索，协和医院信息中心主任李包罗抽象出了一个互斥组的概念。特级、一级、二级、三级护理组成一个互斥组，当护士选择特级护理的时候，自然排斥了一级、二级和三级护理。李包罗说：“在与医生、护士沟通的过程中，IT人员不是要成为临床专家或者护理专家，而是要用IT知识去梳理医生护士的要求，变成一种计算机可以实现的概念，超越了手工的功能才会受到业务部门的欢迎。”项目管理者联盟
⑥以通俗的语言编写软件需求报告项目管理者联盟
IT人员应将从业务人员那里获得的所有信息进行整理，以区分业务需求及规范、功能需求、质量目标、解决方法等，然后编写软件需求报告。“需求分析报告”是IT人员和业务人员之间针对要开发的产品内容达成的协议。报告应以一种业务人员认为易于翻阅和理解的方式组织编写;报告中可以大量使用图表，但必须向业务人员解释清楚每个图表的作用、符号的意义和需求开发工作的结果，以及怎样检查图表有无错误及不一致等。talent.mypm.net
⑦描述产品的使用特性项目管理者联盟
|
