软件项个目开发之需求管理困境.docxVIP

软件项目开发之需求管理困境声明本文内容主要来自网上资料的整理和个人感悟，因参考的网上资料较多和网络资料的零散、多方转载，所以，本人仅统一对所有资料的贡献者表示感谢和敬意，且本文无任何商业利益，故不属于侵权范畴，此外，任何人可根据自身需要任意修改和选取本文内容。本文写作的目的是希望与所有同业者一起净化行业知识。软件项目的开发困境公司觉得项目不挣钱，项目交付质量低、尾款难回收；员工觉得付出与回报不匹配，是领导们任务安排不合理；工期短：单个项目周期一般为3到5月，且多为新业务项目；任务多：同一时间一般有3到5各项目在进行，任务排期矛盾；资源不足：优秀项目经理少，开发人员单人做多项技术，如即做前台又做后台，甚至编写需求，有些是之前从未做过的技术，却被要求按成手的工作进度工作；数据传递滞后、混乱：极端的如项目都结束了，需求文档还在整理中；用户要求随时间多变：客户表现苛刻，使用免费劳动力；在客户与领导面前争宠与推脱责任成为潜在环境；需求困境需求过程不清：对需求的层次和各阶段的工作仅有粗略理解，需求收集、需求整理、需求分析、需求变更管理、建立需求跟踪矩阵；需求工具选取与使用错误：如：用word一遍遍刷新需求，用visio画页面原型，用mindjet描述页面逻辑等。工作任务的描述不清：没有指定清晰连贯的任务表，口头表述较多，任务优先级成摆设，任务接受者自己对任务排序。需求描述不清楚，没有挖掘深入的需求，无法展开工作需求反复变更，没有统一管理。工作协同效率低：处于零散的点消息沟通（如电话、邮件、QQ等），不能实现全过程数据系统化梳理。需求沟通不明确，老板是A，产品是B，UI做成C，开发做成D，造成设计、开发的返工。知识数据不能的清晰传递和有效积累：整个项目期间需求数据的不能有效追溯和维护，需要在很多版本间查找、复制、粘贴，一个月下来，可能需求人员自己都会需求混乱（事情一多，人的思维会默认走捷径，记忆会自动忽略很多信息）。换个需求人员相当于重新做需求。与客户沟通障碍：需求人员对客户的业务专业知识积累少，客户不愿进行无报酬的业务讲解；需求管理需求开发的通用流程如下。图1 需求开发通用流程需求工作流举例图2 需求分析工作流举例工作任务分配需求总负责人应能根据项目任务和需求工作流程细分需求工作任务，确定任务内容、时间、重要紧急度排序（优先级）、工作量预估、执行人、进度跟踪等，一般的项目管理软件如project、oKit等都支持以列表和甘特图的方式对工作任务的进行分配。图3 工作任务分配举例需求工具选择前期的简单逻辑说明可用mindjet，快速画原型就要用AXURE，数据库设计用powerdesigner，专门的包括需求管理的项目管理工具：rational(doors)、ALM(QC)、techexcel、oKit等。需求分类功能需求、性能需求，可选取对应工作流程、文档模板和任务模板。需求收集 需求来源通常需求来自于这几个方面：市场需求、高层、用户需求、运营需求、非功能需求，具体可细分为下面的几个方面：用户需求： 安全、信任市场需求： 交易流程、业务目标整合 投资回报率；（适用互联网项目）技术需求： 稳定、扩展、智能、安全、优越；运营需求：营销、浏览页面数 用户购买率、回访数、自定义、使用、维护；（适用互联网项目）商务需求：给客户什么、品牌 转化率；（适用互联网项目）需求采集方法图4 需求采集方法需求分析需求分析原则现总体上，从商业价值（投资回报）、预算评估、工作量、功能范围、质量保证、实现难度、风险等科目综合评估一下性价比，排出优先级。某需求分析卡举例图5 需求分析卡举例图6 需求条目属性举例图7 需求条目的关联关系举例需求提炼业务需求提炼包括：业务Backlog、业务流程说明（图）、用例说明（图）Backlog：描述业务的实际要求，需与客户讨论确定范围并排序；业务流程说明（图）：通常采用泳道图描述客户业务的流程，包含角色和阶段，要清晰明了；用例说明：从角色角度描述业务用例（场景），通过visio、rational等工具，使用uml画用例图。功能细化：针对某一具体功能，精细描述功能，最好以条目的方式，便于条目间做关联，带变更关联提醒。界面原型：一共需要几页面、页面的整体风格、各种css类（axure中的类与前端开发可使用的类会有不同）、每个页面的开发工作量、使用一键截图工具将页面原型放入需求库。关联模块：描述功能模块及支撑模块间的关联关系（图文），如工作流模块、权限设置模块等。信息支撑：系统公用的消息支撑模块，如即时通信、内部邮箱、个人中心等。需求开发需求变更迭代确认是否为需求的变更或疑似变更。来源、工作量、用户需求、优先级，图8 需求变更迭代举例需求跟踪矩阵UI、开发、测试，功能验收关联测试用例和缺陷跟踪：建立需求跟踪矩阵，让需求条目直接关联之后由测