功能到底要做成什么样子

背景

本来昨天很开心，比较优雅的解决了一个困扰我半个月的问题（springmvc, 变更请求地址与mapping的对应关系）。解决技术问题还是挺有成就感的。

晚上临睡前被人埋怨有一个模块的功能不好用，用不来，来来回回跟我说了一个小时, 然后我就有点小沮丧，搞得我一夜未眠(估计是年纪大了, 心里越来越装不下事)。随后就开始在群里跟pm和研发讨论了一下针对这个问题的解决方案，特定问题解决了，不过怎样避免同类事件发生, 朋友劝我, "功能再被使用以后吐槽不好用很正常". 话虽如此, 能不被吐还是不被吐的好.

功能的产生

接下来梳理一下功能诞生的过程, 一般来讲，一个功能产生应该有下面的步骤:

• 需求人员负责收集，写初始需求文档
• 组织需求会议进行论证可行性以及合理性，修正需求文档
• 与研发负责人, 设计人员或相关人员讨论方案可行性以及界面方案
• 由PM排开发计划, 由开发实现, 过程中PM与需求人员进行跟踪和调整
• 开发人员进行必要测试, 需求人员确认界面及流程
• 测试人员进行测试同时需求人员准备相关文档
• 发布

实际操作过程中, 我去掉了测试人员(有兄弟说我太激进了, 其实还好), 由研发和需求人员共同承担产品质量, 合并了需求与PM人员. 当然我们也有专职测试, 不过只会参与很少的模块.

后期需求变更或者流程修改则

• 需求人员收集需求
• PM排计划, 交由研发人员开发测试
• 需求人员变更相应文档

问题往往出现在最后一步, 缺少必要的追踪.

方案

目前我们使用的方案是:

• 使用Confluence, 即需求都要写Confluence, 保证Confluence描述与功能现状必须一致
• 将Confluence中关键任务点拆出建相应Jira
• 后续变更, 直接修改或删除Confluence中的内容, 研发人员依据Jira查找相应的Confluence, 然后查看历史版本进行比对, 进而找出需要完成的修改(这也要求Jira中需要明确指出文章的版本信息).

至于体验以及使用效果就只能靠定期组织会议来解决了, 定期组织会议让不同角色的人进行核查当前功能模块, 找出不合理的地方以及需要改进的地方.

最后

望研发速度越来越快, 功能越来越好用, 牢骚和埋怨也越来越少.