业务价值与技术价值

如何衡量业务价值

经常在嘴边说的就是，高杠杆率，投入产出比高，但这产出如何衡量高低有很大一部分就是业务价值。

找到业务价值高的部分自己理解可以下面几点考虑

• 不忘初心，要明确产品的目标和受众，是为了满足大多数人的一般需求，还是为了少部分高质量的用户？
• 然后找到产品的核心流程，与写代码一样，优化核心流程带来的收益远远高于优化一般的边缘的流程。

核心业务流程上的，与产品目标更相近的需求，价值应该比较大。然后如果公司有OKR，可以下产品团队的OKR中的使命与愿景，对产品的目标了解有一定帮助。

主题是什么

• 小米手机出厂预装的app，能够实现手机的图标、桌面的背景图片、锁屏方式的个性化的配置。
• 做的项目以主题内容为核心，从设计师主题的制作、主题的审核、主题的内容分发、订单结算，给三方设计师一个完整的业务流程。需求来源有财务、运营、设计师、审核人员，需求相对比较杂。
• 工作内容主要是做重构、新需求、线上问题维护。

重构

背景

• 审核业务为效率宽表+贫血模型方式，维护时间长，人员变更，导致很多字段意义不明确，很多流程分散表意义不清。
• 部分流程耦合紧，不利于多人并行开发。
• 业务目标是体验，为提高覆盖率，业务品类的扩展

方式

• 整体方式：对审核域进行领域驱动设计（审核业务状态流转比较多），其他域还是三层架构
• 战略层：依据领域特点，重新梳理子域划分，为审核，内容分发，订单结算。还有团队人数，业务领域复杂程度（尽可能少但又不太复杂）

战术

• 封装变化，核心业务流程如审核状态变化，封装到领域层，隔离变化，后续的应用层变化尽量少影响领域层。
• 转移职责，解耦合：审核通过领域事件方式，上线操作转移到内容分发管理的领域内。
• sku扩展，整包下的模块。与重新上传的方案比，是对原有业务领域的演化，而不是增加新品类，增加的业务流程少。

技术价值

• 领域边界划分清楚，规范内在约束。新员工上手快，防止一些伪需求
• 后续增加一种品类很快，一周时间就能完成

服务拆分

• 按照吞吐量（打点）
• 按照业务（基础服务（产品）、领域服务）
• 按照架构（业务网关、日志）
• 是否稳定，修改频率（活动）
• 按照技术栈是否异构
• 是否有动态扩容的需求

详情页优化

• 需要取很多种类数据，异步类协程的方式查询
• 对实时性不敏感的数据如评论评分，进行长时间缓存，对于评论进行相对短时间缓存
• 数据异构，把设计师信息在产品库中进行冗余