Neil66

@super452 行吧，你是真觉得需求 sb 想不做就可以不做呀，干的不高兴就能离职呀，也就新人有这资本。而且我也是在跟讨论他的工作方式有没有问题，也没人身攻击谁呀

@super452 带产品和研发一块讨论这已经是需求评审阶段了，不是需求了解阶段，我说的是需求前期了解阶段，懂吗。你从他原文中，哪里看到研发有选择的权利了，研发说实现不了，就让项目延期交付，研发团队压力有多大，而且最后有问题都是研发团队背锅。

@super452 就是需求调研、验证做完了，但是到研发评审需求环节过不了呗。一直觉得讨论需求环节要带着研发的人（发邮件抄送一下研发的 leader 也行），研发开工前要考虑团队技术背景、能力之类的问题。否则就容易导致，需求阶段考虑的特别好，一到研发就被浇凉水

@super452 啥前提呀？我没看到他的这条微博有其他内容

@muzuiget 是的，仔细看看他博客的文章就知道了。参考外文文章，就是翻译后复制粘贴，而且翻译的还跟原作者意思出入很大，有时候观点都完全不一样。

@registerrr 单单需求这一个东西，就掌握了团队的灵魂。产品需求出了问题，项目经理、UI 设计、开发、测试统统背锅，引发一连串流程、技术、管理等问题。懂行业、业务、技术的好产品经理真是金钵钵、究极体，一起工作不要太爽

@WillShin 现在可以办共同卡吗？如果卡只能登记一个人的名字，那就不能绑定到两个人的手机上

感觉跟使用消息队列一样。

1. 前端调用接口，接口把这个任务放到消息队列中并返回状态码 202Accepted 和监控的 url 地址（无需监控任务状态，可省略监控 url 地址），表示任务已经添加到队列。
2. 另一个程序轮训消息队列里的任务，处理符合条件的队列任务
3. 任务处理成功后，反写最终状态（一般在第 1 步创建任务的时候会往数据库任务表里新建一条任务数据，待处理完任务后根据消息 id 反写任务最终状态）
4. 如果需要获取任务的最终状态，前端通过另一个接口（监控的 url 地址）查询任务状态就可以。不需要获取监控任务状态这步可省略

至于楼上说的延迟队列，可能跟消息队列差不多吧，只是可以将延迟时间作为条件筛选符合条件的队列任务，供 op 参考。

对于延迟队列不了解，如有错误请各位指正。

我也有位置 哈哈哈 官方价格平摊 冲啊
https://www.v2ex.com/t/853662