|
1、需求是零散的，不全面的项目管理者联盟
在大多数企业里面，需求信息基本都是在ERP管理系统中各管各的。研发部门搜集和管理技术方面的需求，进行技术/产品规划和开发，市场部门根据自己收集的市场信息做产品规划，销售部门把一线客户信息反馈到研发，做与不做研发自己决定，售后技术服务部门只负责把用户的反馈、期望信息反馈到研发。项目管理者联盟
需求信息经过ERP管理系统从各种途径反馈到研发、反馈到市场，更多还是一个被动式的非例行化的反馈机制，没有形成一个统一的需求“集散中心”来对收集到的信息进行归类、汇总、分发，需求信息还是保存在各自部门、各自人员那里。项目管理者联盟
同时需求的不全面，首先是需求的内容重功能、轻性能，不重视非功能需求，如产品的易用性、可维护性等方面的需求。其次是需求收集渠道的单一，不少企业需求的来源主要是高管的指示、销售的订单和研发内部的技术分析，缺乏对市场、对客户的主动出击。项目管理者联盟
2、需求缺乏过滤、缺乏分析项目管理者联盟
需求信息通过各种渠道、各种方式收集汇总后，会形成一个庞大的需求数据库，但是否所有的需求信息都是需求或者说是真实的需求呢?需求的过滤和需求分析就是一个需求瘦身以及需求提炼的过程。在IEEE对需求的定义中，需求是指满足用户解决问题或达到目标所需的条件或能力。因此对收集到的需求，首先就是过滤掉一些非需求，比如类似于“必须解决**设备异常重启”的信息就可以过滤掉，以免混淆真正的需求。talent.mypm.net
同样，对于客户/市场的需求反馈信息，需要通过ERP管理系统需求分析还原、解析出真正的需求。最近在一家企业调研和总经理交流时他就重点提及了这个问题：“需求失真的事情经常发生，前面把关不严，业务不懂需求和技术，不把关不分析，客户需要做猫，业务要求做老虎，再丢给技术就完全做错了，不符合客户需求，做出来客户也不要。”项目管理者联盟
3、需求传递过程缺乏有效的沟通和确认项目管理者联盟
需求的传递要有正式的需求分析文档，需要相关干系人面对面地沟通，这样才能保证需求的真实传递。项目管理者联盟
在电视节目上有这么一个词语传递游戏，每次选四位选手，站在一排隔成四个小单间(面向摄像机的一侧是敞开)的隔断里面，每个人都带上大声播放音乐的耳机。游戏开始后，第一位选手摘下耳机看主持人给出的词语，10秒后第一位和第二位选手之间的隔板收起，第一位选手要用肢体语言向第二位选手表达并让其了解他刚才看到的词语，不能使用语言，词语信息传递完成后，第一位和第二位选手间的隔板伸出，然后第一位选手带上耳机，第二位选手摘下耳机，第二位选手重复前述词语信息传递活动，第三位选手也如此。可以看到，99%以上的词语信息传递是失败的，甚至在第一棒就已经失真。游戏的重点是词语传递过程中双方不能使用语言，这样的沟通不顺畅造成了信息的传递缺乏有效的沟通和确认。项目管理者联盟
类似的情况在企业中是不是也是经常出现?在市场和客户、市场和研发、研发主管/项目经理和研发人员、研发和生产等环节的需求信息传递的过程中是不是也会出现这种情况?由于无形的“部门墙”的存在，部门间沟通困难，前面的环节把需求传递后，后续环节一般不愿意去和前序环节做太多沟通和确认，习惯自己想当然的去理解和实现，加之需求的传递因为各种原因而缺少的需求分析文档，哑巴式的需求传递结果就和上述游戏所表现的结果一样。项目管理者联盟
4、研发过程缺乏有效的产品需求变更控制bbs.mypm.net
产品需求是新产品设计和开发、以及后续活动的依据和源头，产品需求的稳定性和可控性直接关系到新产品开发的进度和质量，产品需求的变更需要严格有效地进行的控制。但是在实际的执行过程中，ERP管理系统需求的变更控制比较粗放，需求的变更评估更多地集中在技术领域的决策，对需求变更给工艺、财务、制造、采购、售后服务等方面的影响评估不足，结果就是需求变更造成了产品物料成本超支、采购周期难以保证、生产困难、售后服务繁琐等问题。项目管理者联盟
5、需求管理缺乏IT工具的支持项目经理博客
无论是需求收集，需求分析，需求跟踪、需求变更控制等，需求各个过程涉及环节和部门都比较复杂，如果只是使用办公软件进行管理难免捉襟见肘，专业的需求ERP管理工具的引入将有助于产品需求管理的高效运作。pmp.mypm.net 项目管理者联盟
|
