1703950967
1703950968
JIRA是Atlassian公司出品的项目与事务跟踪工具,被广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域。JIRA中配置灵活、功能全面、部署简单、扩展丰富,其丰富的内置功能,得到了全球范围内数万企业用户的广泛使用。
1703950969
1703950970
Redmine是用Ruby开发的基于Web的项目管理软件,是用ROR框架开发的一套跨平台项目管理系统,据说是源于Basecamp的ROR版而来,支持多种数据库,有不少自己独特的功能,例如提供wiki、新闻台等,还可以集成其他版本管理系统和BUG跟踪系统,例如Perforce、SVN、CVS、TD等。这种Web形式的项目管理系统通过“项目(Project)”的形式把成员、任务(问题)、文档、讨论及各种形式的资源组织在一起,大家参与更新任务、文档等内容来推动项目的进度,同时系统利用时间线索和各种动态的报表形式来自动向成员汇报项目进度。
1703950971
1703950972
1703950973
1703950974
1703950976
技术管理之巅:如何从零打造高质效互联网技术团队? 4.3 开发需求堆积如山,怎么破
1703950977
1703950979
4.3.1 建立以价值为导向的需求管理机制
1703950980
1703950981
为什么要对需求进行管理?由于开发资源总是相对有限的,面对源源不断的业务需求,如果开发团队不分轻重缓急,全盘接受的话,技术团队很快就会陷入疲于应付需求的漩涡当中,导致技术团队做了一堆对生意毫无帮助的需求,而一些对生意促进比较大的需求没有被及时受理,技术人员变成了一个“为了开发而开发”的代码工人,缺乏对生意本身的思考,就很难发挥技术应有的价值。
1703950982
1703950983
为什么要以价值为导向?能不能以“老板”为导向?以“营收”为导向?以“效率”为导向?这些选项看起来都不够客观和全面。这里的价值指的是生意增长、运营效率提升、成本下降、用户体验改善等,凡是能使企业往好的方向发展的事情都是有价值的。
1703950984
1703950985
价值都是可以量化的,因此对于一个业务需求,必须有明确的价值,价值要有具体的度量指标,比如“提升搜索转化率5%”,就是一个很好的价值描述,如果通过优化了搜索的若干功能,能够提升搜索转化率5%,就是一个可以被接受的需求价值。相反,“极大提升搜索转化率”就是一个不能够被接受的需求价值,因为描述太笼统,不可量化。
1703950986
1703950987
需求的价值有两个用处:一是通过判断价值的大小来对若干个需求进行优先级排序,决定哪些需求先做,哪些需求后做;二是用来跟踪这个需求价值是否实际达成,如果没有达成,将会扣除需求提出部门的“信用分”,反之则增加其“信用分”。
1703950988
1703950990
4.3.2 价值有预估,达成有回顾
1703950991
1703950992
以价值为导向的需求管理机制,实际上就是建立一个游戏规则,让每一个需求提出部门有序、公平地提报需求,开发部有限的资源投入到对公司最有利的需求和项目上,而不是哪个业务部门强势就做哪个部门的需求,开发部也不能说“你们先吵完,告诉我结果”这种不把公司利益放在首位的话。
1703950993
1703950994
业务方提报需求的时候,为了在PK中胜出,获得更多开发资源,常常会虚报需求价值,如原本提升搜索转化率5%,被说成提升搜索转化率10%。对于这种行为,有效的对策是,在功能上线后,对需求的价值进行验证,看看实际的达成情况,来加减“信用分”。
1703950995
1703950996
“信用分”的用途,是用来衡量需求提出部门的“靠谱”程度,如果某个业务部门的“信用分”高,说明该部门的需求对生意的帮助大,在下一次的需求PK当中,同等条件下优先考虑这个部门的需求,反之则降低这个部门需求的优先级,减少开发资源的投入。各部门的“信用分”可以每季度做一次排行榜公布出来,这样可以促进各部门之间的良性竞争,营造一个以价值为导向的需求提报氛围。
1703950997
1703950998
这样就建立起了一个良性循环,各业务部门会提出更多有价值的需求,减少低价值的需求,使得需求得到有效的治理,业务部门对需求的提出会有更多的思考,不再是拍脑袋式的提需求。
1703950999
1703951001
4.3.3 建立需求管理闭环
1703951002
1703951003
如上所述,可以建立一个以价值为导向的需求管理闭环,如图4-6所示。
1703951004
1703951005
1703951006
1703951007
1703951008
图4-6 需求管理闭环
1703951009
1703951010
从需求受理的4个阶段:提交需求、排期开发、上线运营、需求调整。在提交需求时,业务人员需要预估这个需求所带来的价值,这个价值必须是可量化的;排期开发阶段,业务人员和技术人员一起对需求池里的需求进行价值PK,决定哪些需求先做,哪些需求后做;上线运营阶段,验证当初预估价值的达成情况;需求调整阶段,根据实际运营的结果调整需求和价值,然后整理成新的需求,加入到需求池中,不断地循环迭代开发。
1703951011
1703951012
通过这个需求管理闭环,业务和开发紧密配合,不断地完善产品,进行快速迭代,使得产品越来越接近用户的真实需求。
1703951013
1703951015
4.3.4 最佳实践案例:Jerry让技术不再成为业务发展的瓶颈
1703951016
[
上一页 ]
[ :1.703950967e+09 ]
[
下一页 ]