为什么技术人员要理解业务？
问：术业有专攻，分工合作才是团队的本质，让产品人员和运营人员讲清楚就可以了呀，那为何技术人员要理解业务？？
答：理想与现实总是有差距的。
问：如果说多懂一些更好，为何不要求产品和运营来学技术？
答：技术的门槛要远高于业务的门槛。
问：我现在还不是架构师，等我成为架构师了再去提升就可以了吧？
答：不单是架构师要理解业务，所有技术人员都要理解业务，区别只是业务的理解层级和程度不同。
理解业务的好处
防止错误的需求和逻辑输入，导致后面无论做的多好都拿不到好的结果。
识别业务的复杂度具体体现在哪些地方，需要根据业务来建模（高性能）、取舍（高可用）、预判（可扩展）等
结合业务的发展趋势来做技术规划、架构重构、架构演进等。
一个需求的诞生之路
图片
1. 客户遇到了一个问题，或者老板等认为客户/用户会遇到某个问题；
2. 客户或者老板自己想了一个解决方案，然后把解决方案作为需求提给产品人员；
3. 产品人员将客户的需求描述出来，作为项目需求。
一个坑需求的诞生之路
需求踩坑案例 - 我要一只羊
图片
如何准确理解需求 - 5W1H8C1D
5W1H
【定义】
1. Who：需求涉及的利益干系人；
2. Where：需求发生的地点；
3. When：需求发生的时间；
4. Why：需求要解决的问题；
5. What：需求的输出是什么。
6.How，需求的处理逻辑，注意这里的 How 不是设计方案。
8C1D
1. 性能；5. 可靠性；
2. 成本；6. 安全性；
3. 时间；7. 合规性；
4. 技术；8. 兼容性。
Data：需求实际上线后的效果
5W1H8C1D 案例
【地铁扫码过闸】
1. Who：谁用扫码过闸？-> 用户行为建模
2. Where：地铁站内有什么特点？-> 系统设计约束
3. When：什么时间用到扫码过闸？-> 系统峰值需求估算
4. Why：为什么要扫码过闸？-> 扫码过闸的优缺点
5. What：需要输出什么？-> 用户期望的效果
6. 8C：环境要求？性能要求？大陆地铁相关要求和香港的一样么？-> 系统设计约束
AARRR 模型 - 端到端 ToC 业务
图片
AA：获取 + 激活
获取：
1. 触达用户：让用户知道产品，触达路径就是“渠道”，比如广告、社交推广、老用户推荐、主播推荐等手段。
2. 吸引用户：让用户进入产品，比如设计有创意的海报、红包现金奖励和送礼品等。
激活：
把获取的用户转化为产品的真实用户。
例如，用户下载购物 App 后，可以通过送红包、满10减9、送10张现金券这种方式，引导用户完成一次购物。
RRR：留存 + 收入 + 推荐
留存 ：
把激活的用户转换为产品的长期用户，不同用户的核心诉求不同。电商业务为例：拼多多，淘宝，京东，各自用户留存的关键是什么？
收益：
将留存的用户转换为收益。例如：用户直接购买产品、购买VIP服务、广告商按照用户点击付费、平台收取交易佣金等。
推荐：
通过“以老带新”的方式来实现用户增长。例如：拼多多的拼单，提现。
如何应用 AARRR 理解 ToC 业务？
1.业务手段：
获取渠道：1. 统计分析平台；2. 跟产品运营等交流。
2.漏斗数据：
获取渠道：1. 统计分析平台；2. 内部业务总结规划会议。
3.竞品漏斗
获取渠道：1. 公司内的行业分析；2. 第三方的行业分析；3. 上市公司的财报。
