产品和研发的关系

今天突然会思考这个问题，是因为我得到了一个反馈：希望JIRA的Task工作流能把‘已结束’的任务‘重新打开’。这个在Bug工作流，我有考虑过；放在Task的工作流的话，只能再去细问一下这个场景故事。

故事是这样的：

　　背景：产品有个报表功能加载太慢，研发内部提了优化任务并完成了，让业务调用方验证也通过了；这边负责人觉得优化还不够满意，需要进一步优化，于是想把任务重新在JIRA上打开（细致到jira流程是否开二期任务的问题，我们就不在这里当做话题讨论了）。

我：为什么不通过？

小哥哥：平均加载时长还是>=3s,有明显的加载和等待时间

我：优化前的加载状态是什么？

小哥哥：会超时，甚至无法加载

我：技术上还有优化空间吗？

小哥哥：界面上单个接口的请求和响应没问题，基本上无优化空间。但是多个接口并发请求的时候，性能瓶颈撑不住，可能需要加机器，做负载均衡。

我：既然要一步优化到位，架构上性能已经是瓶颈，为什么不从业务上提更快的方案？比如，减少不必要的报表，留住用户体验？

小哥哥：现在的报表确实是太多了，性能实在是撑不住；但是，以后业务量上来了，性能优化也是研发要做的。需求推动技术进步~

好嘛!!PEACE AND LOVE ~

这和我知道的那些旁边放着菜刀和支付宝付款码的码农小哥哥形象不太一样啊。换句话说，没有任何争议的产品功能堆砌，真的能开发出我们想要的那个产品吗？

我们都知道每次的争论，必然是大家都有各自的观点和坚持的道理。最后还能达成一致的就是因为有了一个最小风险的可行性方案，这应该才是团队最想要的健康关系吧？

如果研发认可了‘需求推动技术进步’，产品任何了‘都看技术实现能力’，都把对方的决策作为可行性方案，这会是怎样的后果？换个思路理解，我是不是可以认为大家都不敢，甚至不想对这个产品负责？

可想而知，项目管理工作开展任重而道远了~