你们产品出的需求是长啥样的？

每个需求都是要评审的，都要输出技术方案，产品文档的，这个感觉跟公司开发流程有关，上一家需求几乎口述，有的图都没有

其实不管前后端，有需求说明文档+原型图还好，其中一个没有都是要靠前后端反推业务逻辑然后找产品确认需求

口述,实现全靠灵性

建议从产品经理思维去完整的思考这些体系化的事情，你在了解业务的基础上，慢慢会变成多面性高手-懂业务的实践者，你需要：

1. 总结要解决的问题，确认这个需求是否真的合理，是否遵循第一性原理真正的帮助客户解决问题？ 是否是一个伪需求？是否是普遍性的？ ROI 如何？
2. 表达设计出需求：
a. 把你脑海里面的思路用草图画出来形成一个清晰的业务流，就跟电影一样可以在黑白上贴纸片、画草图等。
b. 在 a 的基础上按照准确的逻辑和产品整体性原则表达出最优的方案，文字和图形都只是表达的工具，需要写一个需求设计文档。不在于格式形式，目的是你要把你想要实现的方法和最终结果形态讲清楚。

3. 跟研发沟通开会，落地技术细节、工期（人天数）、风险、项目甘特图，按照项目管理标准手法管理进展。

[重点关键] ：前面三步你参与了，你就初步了解了业务了，你就会跟前端去沟通后端配合工作项，梳理出来就是你的需求了。

4. 关注质量：通过测试环境验证方案落地的一致性，并在初期寻找缺陷不足，在上预发快速修复它们。

5. 稳定后，上线前最后一次预发环境 UAT 测试，发现修复问题。

6. 灰度发布

7. 数据化运营：等待客户反馈+埋点数据观测点击率、使用率和用户排行、相关问题。

8. 复盘改进。

以上从业务了解、需求输出、质量管理你都面面俱到了，业务各方想不喜欢你都难。

老板：做一个这个

@c3de3f21 老板： 先做假的。过两天：这个得用，加一下后台。中间穿插：“做一下这个”，“之前（两三年前）的那个还需要改改”

@michael2016 现实情况大概率会是，产品扔过来一张图加几句话，然后说着急上线，后天能不能上。

我一般都是产品讲需求前先说一句“要抄哪个 app ，截个图，别浪费大家时间”，然后产品一笑，掏出手机，“就这个”

@systemGuest 没有需求评审，对产品也没有明确的考核指标是这样的

需求：你去把唐僧抓过来。