运维咖啡吧

追求技术的道路上,我从不曾停下脚步

面向老板的需求管理系统

一个服务对象为各种不同品牌、产品、业务的基础技术支持部门,同时在进行的项目就有十几个甚至几十个,对于开发资源的争抢就成了不可避免的问题,每当A产品提出需求,而项目经理告诉他开发资源不足时,他们都会有疑惑,我们只提了3个项目为啥会资源不足?这个时候项目经理就会解释一通B产品在做啥项目,同时也在支持C产品D产品balabala的,这个时候一个包含所有项目的看板就显得非常有用了

于是便有了今天这个项目,需求管理系统

项目需求

需求管理系统比较简单,重点只有两个,其一是有一个看板面向公司所有人能够查看我们所有开发的项目,其二就是一个需求申请审批流程

需求比较简单,实现起来也不难,需要提前想清楚的是有哪些用户会用这个系统,他们有什么差异的使用需求,我把使用需求系统的用户角色分为两类,普通用户和项目经理

普通用户: 所有人都算普通用户,普通用户可以查看需求看板,可以提交新需求,可以查看自己提交的需求,在需求确认前也可以修改或删除自己提交的需求

项目经理: 也叫PM,比普通用户多了需求确认的权限,同时也可以对需求进行产品归属、定级、排期等管理

项目展示

开发完成之后的最终效果如下,分普通用户和项目经理分别展示,先看普通用户看到的界面

项目看板:所有经过PM确认的项目都会展示在项目看板上,排序规则是先展示进行中或未开始的项目,已完成的项目展示在底部,按照产品依次排列,为了方便分享还加了保存为图片的功能,点击之后可以将整个看板保存为一张图片,当然为了安全图片也加了水印

看板主要使用了jQuery.Gantt插件,在此基础上进行了魔改,例如给任务条添加图标、颜色,当前周深色显示,工具栏固定在底部,头部固定等等,比原生的要好用很多

我的需求列表:我的需求列表页面展示了我所有提交的需求,若需求提交后有要修改的地方或是需求取消,可以在这个页面进行修改或删除

提交新需求:如果有新的需求可以在提交新需求页面进行提交,我们的项目分为普通项目和增长类项目,两者在后期开发过程中资源安排会区别对待,所以当用户选择增长项目时,需要额外填写项目的KPI/OKR指标,项目维度里也可以根据重要紧急四个象限进行选择,如果是重要项目也需要填写重要原因,当然如果有项目的详细说明等也可以通过附件的形式附加

普通用户基本上就使用这三个页面,如果是PM的话会多一个"进入管理后台"的菜单,点击可以进入管理后台

待我确认:在用户提交需求后我们会有邮件和IM的消息通知发给PM,PM在收到消息通知后可以进行需求确认,所有待确认的需求都会显示在这个页面

点击确认按钮,需要选择需求所属产品、为项目定级、确定开发周期等,由于看盘是面向全公司的,所有人都可以查看,而有些项目是保密的,所以需要确认当前项目是否保密,如果保密的话看板中会用项目代号来展示,项目详情也会同时隐藏

项目列表:所有需求都会展示在项目列表里,在这里也可以通过产品、状态、等级等分类检索

产品列表:在这里可以定义产品,所有需求都需要归属到产品,产品有中文名称、英文名称,以及在看板里展示的图标和颜色

项目比较简单,剩下的用户管理相关页面不多介绍,需求管理系统原本是给我们自己部门使用的,但上线后有其他部门觉得也不错想使用,于是我在原本的基础上添加了多部门的支持,还请设计师设计了一个首页,在这个页面上可以展示所有纳入看板管理的部门,点击相应的部门查看对应部门的工作,方便且透明

写在最后

我们项目管理用的是Jira,为什么没有直接使用Jira做需求管理呢?主要是第一Jira不太好做流程审批,第二Jira有一定的学习使用成本,我们需求系统面向的是公司所有人,用起来一定要简单,不需要额外的学习

需求系统与Jira这种项目管理软件是相辅相成相互协作的关系,需求系统更注重的是需求的承接与集中展示,粒度较粗,而Jira这种偏向于项目开发过程中的管理,粒度更细

这个项目的开发原本跟运维没有任何关系,但由于开发团队比较忙,领导就把这个事情交给了我们来做,之前开发过许多的DevOps系统,这么个需求系统对我来说自然不在话下,上线之后其他部门同事找过来也要接入这算是额外的收获吧

系统本身并不能解决任何问题,用好系统才能更好的去处理问题