摘要：一个服务对象为各种不同品牌、产品、业务的基础
技术支持部门，同时在进行的项目就有十几个甚至几十个，对于开发资源的争抢就成了不可避免的问题，每当A产品提出需求，而项目经理告诉他开发资源不足时，他们都会有疑惑，我们只提了3个项目为啥会资源不足？这个时候项目经理就会解释一通B产品在做啥项目，同时也在支持C产品D产品balabala的，这个时候一个包含所有项目的看板就显得非常有用了。 于是便有了今天这个项目，
需求管理系统。
项目需求 需求管理系统比较简单，重点只有两个，其一是有一个看板面向公司所有人能够查看我们所有开发的项目，其二就是一个需求申请审批流程。 需求比较简单，实现起来也不难，需要提前想清楚的是有哪些用户会用这个系统，他们有什么差异的使用需求，我把使用需求系统的用户角色分为两类，普通用户和项目经理。 普通用户： 所有人都算普通用户，普通用户可以查看需求看板，可以提交新需求，可以查看自己提交的需求，在需求确认前也可以修改或删除自己提交的需求。 项目经理： 也叫PM，比普通用户多了需求确认的权限，同时也可以对需求进行产品归属、定级、排期等管理。
项目展示 开发完成之后的最终效果如下，分普通用户和项目经理分别展示，先看普通用户看到的界面。 项目看板：所有经过PM确认的项目都会展示在项目看板上，排序规则是先展示进行中或未开始的项目，已完成的项目展示在底部，按照产品依次排列，为了方便分享还加了保存为图片的功能，点击之后可以将整个看板保存为一张图片，当然为了安全图片也加了水印。
看板主要使用了jQuery.Gantt插件，在此基础上进行了魔改，例如给任务条添加图标、颜色，当前周深色显示，工具栏固定在底部，头部固定等等，比原生的要好用很多。 我的需求列表：我的需求列表页面展示了我所有提交的需求，若需求提交后有要修改的地方或是需求取消，可以在这个页面进行修改或删除。 
提交新需求：如果有新的需求可以在提交新需求页面进行提交，我们的项目分为普通项目和增长类项目，两者在后期开发过程中资源安排会区别对待，所以当用户选择增长项目时，需要额外填写项目的KPI/OKR指标，项目维度里也可以根据重要紧急四个象限进行选择，如果是重要项目也需要填写重要原因，当然如果有项目的详细说明等也可以通过附件的形式附加。 
普通用户基本上就使用这三个页面，如果是PM的话会多一个"进入管理后台"的菜单，点击可以进入管理后台。 
待我确认：在用户提交需求后我们会有邮件和IM的消息通知发给PM，PM在收到消息通知后可以进行需求确认，所有待确认的需求都会显示在这个页面。 
点击确认按钮，需要选择需求所属产品、为项目定级、确定开发周期等，由于看盘是面向全公司的，所有人都可以查看，而有些项目是保密的，所以需要确认当前项目是否保密，如果保密的话看板中会用项目代号来展示，项目详情也会同时隐藏。 
项目列表：所有需求都会展示在项目列表里，在这里也可以通过产品、状态、等级等分类检索。 
产品列表：在这里可以定义产品，所有需求都需要归属到产品，产品有中文名称、英文名称，以及在看板里展示的图标和颜色。 
项目比较简单，剩下的用户管理相关页面不多介绍，需求管理系统原本是给我们自己部门使用的，但上线后有其他部门觉得也不错想使用，于是我在原本的基础上添加了多部门的支持，还请设计师设计了一个首页，在这个页面上可以展示所有纳入看板管理的部门，点击相应的部门查看对应部门的工作，方便且透明。 
写在最后 我们
项目管理用的是Jira，为什么没有直接使用Jira做需求管理呢？主要是第一Jira不太好做流程审批，第二Jira有一定的学习使用成本，我们需求系统面向的是公司所有人，用起来一定要简单，不需要额外的学习。 需求系统与Jira这种项目管理软件是相辅相成相互协作的关系，需求系统更注重的是需求的承接与集中展示，粒度较粗，而Jira这种偏向于项目开发过程中的管理，粒度更细。 这个项目的开发原本跟运维没有任何关系，但由于开发团队比较忙，领导就把这个事情交给了我们来做，之前开发过许多的DevOps系统，这么个需求系统对我来说自然不在话下，上线之后其他部门同事找过来也要接入这算是额外的收获吧。 系统本身并不能解决任何问题，用好系统才能更好的去处理问题。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
权威发布，测试选择不纠结！第15届软件测试行业报告，直击行业发展，把握未来方向！
