产品 #

愿景
    定义产品的目的和原因，将到达的地点
ux
    微交互                  # 细节决定成败

RoadMap #

介绍
    到达愿景的策略路径，提供一系列与产品战略相一致的战术步骤
为什么
    简单、清晰的通讯文档
        少的多的会议
        健康的团队辩论：交付成果与目标联系起来
        做出每个人都理解的产品决定，不再打击创意
    高维度的概述
    动态演变
要素
    时间周期
        时间区间，只定时间范围
            big-view(product)
                全局理解产品的未来,  交付顺序
                统一视野(vision), 范围(scope)，时间期限(time line)
            pre-view(release)
                release中的产品功能, 和前几个迭代从backlog中要交付的工作项(item)
            now-view(iteration)
                团队在一次迭代中要交付的需求(requirements)
        优先级，留空间适应变化
    项目事件
        完成产品总体计划必要的工作项, 详尽且切合目的
        分解目的，制定步骤
    路标
        关键工作项完成的时间节点(里程碑)
        结果反馈：审视是否偏离，试验中改进
        确定在每个时间范围内实现可衡量的结果。定义为目标关键结果(OKR)、关键性能指标(KPI)
种类
    基于目标
        current
        near term
        future
    基于功能
        5000新用户
步骤
    确定目标
    分解目标，穷尽事项，组织，优先级排序
    使用优化框架
        effort / impact
        impact / goal
        卡洛斯模型?
注意
    定义战略主题(名词)，抓住核心用户行为的本质、产品能力、竞争优势、技术改进
    保持路线图战略，避免战术
    每个计划阶段都考虑优先级, 每个目标、动作、发布、特性的价值可见性
    始终在试验(ABE), 为了正确定义目标和后续特征
        先做出有根据的猜测
        测试
        基于反馈迭代

业务 #

目标
    降低人才素质需求
    减少开发时间
分类
    创造虚拟空间
    自动化
    辅助决策
思路
    逻辑: 因果(演绎), 时间, 空间, 优先
    方法: 5w2h(who, when, where, why, what, how, how much)
    建模:
        中心                                # 调整抽象领域和层次(视问题决定)
            自上而下                        # 问题明确，展开
            自下而上                        # 内容分类、剪枝、归纳
        分解
            MECE(mutually exclusive collectively exhaustive)
                正交
                穷尽
    经验
        优秀的产品都有全局把控感(confluence, jira)
        设计思想多源自: 操作系统、编译器、函数式
        深入一线(面对客户)
        思考全面, 全局
        考虑需求本质，考虑上下游全局
        想清楚再行动
过程
    发掘(discovery)
        价值定位(价值驱动)
        客户体验梳理和设计
        愿景
        干系人
        电梯演讲收敛
    定义(define)
        用户旅程，业务流程
        事件风暴 -> 映射技术 -> 架构
    设计(design)
        总体
            识别问题域, 归纳服务, 上下游关系
            架构图, api, 技术栈
            提升方向, 改进
        迭代
            价值/成本分布图
            milestone演进
            业务技术/需求拆解全景图(白板贴标)
            mvp(minimum viable product最小可行计划)迭代计划
    开发(develop)
        度量, 质量指标
        工具选择, 规范
        架构守护，治理
    实施策略
    交付
    产品生命周期管理
        目标, 资本
        机会点->需求
角度决定设计
    找到不动点
    如对cache的设计
        业务角度
            选择简单易用的缓存框架
            有人会用，学习成本别太高
            关注数据模型结构设计
            缓存更新真麻烦
        paas角度
            声明式使用，配置文件设置
            缓存对比，选择强大且稳定的
            存取接口设计，方便易用
            数据变动监听，自动刷新缓存
        平台角度
            缓存服务器集群方式
            存储空间监控
            命中率监控
            避免缓存集中失效引起雪崩
不过度设计      # 不超出需求，不用复杂方式实现
                # 少就是多，应一减再减。简单才能强大，也会提高性能和扩展性
    范围减少    # 28原则，最小可行产品
    设计减少    # 易理解，低成本，可扩展
    实施减少    # 找开源->找内部已实现->找方案描述->自己解决
    二八定律
墨菲定律
    事情不是表面看起来那么简单
    事情都会比预计时间长
    可能出错总会出错
    如果你担心发生，它更可能发生
维护
    设计时考虑扩展性
        DID(design, implement, deploy)(设计20倍, 实现3-20倍, 部署1.5-3倍)
    设计能够监控的应用
    版本升降      # 代码仓库
业务
    防重          # 重复提交，重复扣减，重复支付(异构系统无法防重，用退款处理)
        防重key, 防重表
    幂等          # 消息处理，第三方支付回调
    流程要抽象     # 如工作流
    状态与状态机
        订单系统
            # 状态多时用状态机驱动
            正向状态(待付款、待发货、已发货、完成)
            逆向状态(取消、退款)
            状态轨迹    # 跟踪和记日志，可回溯
            并发修改，状态变更有序，状态变更消息有序
前端
    减少dns查找     # dns可能查多个域
    减少对象        # 页面布局少，图片合并。对象不要过大，减少到浏览器并发连接数
    后台系统操作可反馈   # 便于确认效果
文档和注释
    设计架构
    设计思想
    数据字典/业务流程
    现有问题

设计 #

分层做维度扩展

DDD #

DODAF2.0 #

介绍
    美国国防部（DOD）
    项目立项和顶层架构间，建立跟踪机制
八种视图
    全视图
    数据与信息视图
    标准视图
    能力视图
    作战视图
    服务视图
    系统视图
    项目视图
业务组件化
    基本的、唯一的、不重复的，可单独运行

项目 #

分层 #

mv*
    mvc
        # view controller model, 单向循环
    mvp
        # view presenter model, presenter双向交互
    mvvm
        # view view-model model, view-model双向绑定

验证
异常层
    # 封装每层异常为不同异常类
过滤层
监听器
日志
测试