date: 2018-11-23 17:50:51
title: tech| 极客时间学习笔记 2

邱岳产品实战

和自己较劲, 是一个产品的实战历程; 法无定法, 然后知非法法也
坚韧的力量; 要建立更长的预期, 用对未来的信心支撑对现在的耐心; 我们去做产品, 不能只有理想思考和分析, 更要有策略迭代和实战, 既要胸怀远大也要心狠手辣

如何验证产品创意

• 大量收集信息: 创意vs执行; 上下(上下游, 来源渠道, 消费者)左右(广义竞品 行业环境)+古今中外
• 高效收集和获取信息: 体系化课程 跟行业专家深入交流 读书 财报/券商分析报告/行业分析报告 行业资讯/文章/论坛
  如何锤炼产品创意
• 行业未来会是什么样子: 数据+观察+理解+拆解/逻辑推演
• 行业痛点和机会在哪里: 大而化之的宏观判断+个人假设->赌
• 为什么你能做成, 你打算怎么做: 独特优势和路径->大而化之的策略vs详细解决方案/产品特性
• 给直觉一个机会vs冲动
  要不要相信调查问卷
• 之前 清单+计划; 保证用户可以流畅的回答问题; 中 尽量少提假设性问题; 不要套路你的用户; 跳出调查问卷
  用最少的资源给产品试水
• MVP, minimum viable product: 不断用尽可能少的投入创造尽可能多的价值
• 未完成的功能键
• 一个失败的案例: 询问使用者->客气导致误判->直到刚需产生
• MVP 商业化验证作用: 盖茨忽悠IBM然后修改DOS Dropbox纸片视频
  如何快速利用MVP思想
• 提前推演逻辑, 不要盲目验证(打点收集数据进行验证); 验证长板而非短板(第一版12306的长板->它有票); 创造性的低成本方案(人工 第三方 利用规则缩小场景)
• 另一面: 缺少规划 再次唤醒用户更难
  如何做好产品立项
• kickoff 项目立项阶段
• 识别相关方, 理解产品对业务的影响; 明确需求, 联合利益; 估算代价, 安排计划(谁做谁估 多估几次 留足余量); 时刻->锁定资源, 「卖」创意
  产品发布的坑
• 发布checklist: 该知道的人都知道了吗 脑子里排练过么 万一出意外有退路么
  产品增长
• 增长越来越难->红利期结束; 增长新趋势->跑马圈地 拉新->精细化+扩宽战场(三四线下沉 东南亚非洲 新平台新形态押注)
  产品增长核心
• 持续而有效的解决一方/多方利益相关者的问题, 为他们创造价值; 是爱创造了增长, 而不是增长创造了爱; 增长要回到产品本身
• 创造产品的啊哈时刻: 不同层面组合信息->帮助用户最大程度的提高资讯阅读效率
• 观察用户如何描述你的产品: 很可能你最终会做出一个跟初衷完全不同的产品形态
  增长团队
• 经典结构和搭建逻辑: 用户从进入产品直到最后离开->增长本身需要策略贯穿始终; 独立团队/产品团队增加增长岗位
• 增长实践: 角色->增长策略; 协调增长策略的规划和产品规划(功能增加/用户体验); 一定要有实权负责人全力支持/参与
• https://medium.com/swlh/how-do-you-choose-the-best-growth-team-model-632ad5a85be9
  产品增长业务公式和指标
• AARRR 漏斗, acquisition 获取, activation 激活, retention 留存, revenue 变现, referral 传播; 不要试图兼顾所有环节
• RARRA 留存-激活-传播-变现-获客: 先把东西做好, 然后扩大影响
• 留存是最重要的指标
• 选定目标: 选定一定时间段内相对稳定的目标, 能够从源头为各种策略的优先级做好划分; 选对方向vs选对时机
• 拆解业务公式: 收入=付费用户数*客单价 付费用户数=用户数*付费转化率 收入=新用户数(流量*注册转化)*新用户转化率*新购客单价+老用户述*复购率*复购客单价
• 选定支点: 给我一个支点 它能否有效的承前启后的拉动整个业务公式 宏观核心目标/云因策略落地->随业务/市场环境/团队变化调整
  产品增长过程中关键套路
• 不能关注具体操作层面的技巧, 而应多关注过程: 建立数据体系 → 分析 → 提出想法 → 排定优先级 → 测试 -> 周而复始
• 使用自有打点策略和日志工具进行复杂分析 > 使用第三方工具进行自定义打点与复杂分析 > 使用自有打点策略进行简单分析 > 使用第三方工具的基本功能进行简单分析。
• 优先从代价小的开始: 快速建立整个闭环 成功时更容易获得信心
  实战增长
• 每次开五枪中一枪->加快开火频率; 提高尝试的成功率/准确率/效率; 希望通过个人经验避开错误提高效率; 专业人士->可能并不在与快而在于准; 设计方案的时候要带着下线的准备->向最好的结果努力, 往最坏的情况打算
  增长执行
• 自愈力 动态完善策略的重要战术素养: 去寻找那些拥有自愈能力的人, 然后将资源向他倾斜并适当施加压力; 发布早, 迭代快, 脸皮厚, 能稳定节奏
• 决断力: 敢于拿主意 决策得快vs决策得好
• https://medium.com/@wooyi/7-lessons-from-jeff-bezos-annual-letters-to-shareholders-d2b795201c16
  钩子与用户留存
• 留存本质: 没把留存做好之前, 不应该着急做其他阶段的事情; 留存不是单纯的追求数值指标, 而是不断夯实它背后的驱动力; 钩子->拉回用户不知节制的怪圈->体面一点/个性化一点的由头
• 留存周期与分析: 不同产品应当有不同的时间框架不要一概而论; 对留存有足够长时间的观察; 分析原则是尽可能细分分析
• 方法: 会员特权吸引留存; 直接利益吸引(游戏类似设计); 产品本身包含留存特性(功能本身 数据沉淀 网络效应); 有节奏的持续迭代
  传播获客的正确姿势
• 产品本身缺乏生命力, 那无论是病毒传播还是分销裂变, 都难以保持长久
• 传播与获客的关系 获客的原则 流量品类/利润品类 吸引的效率
• 传播类型: 直接推荐 潜移默化推荐
• 动机与设计: 核心功能是否对用户有价值, 能够成功向用户植入品牌印象; 向领域专家求助(使用障碍); 成就用户而不是凸显自己
  增长黑客阴暗面
• 保持克制: 产品中的黑暗模式 剧场效应 热力学第二定律
• 朝着用户利益努力: 不蒙骗不恐吓不嘲笑
• 我们应当对那些病毒传播和爆炸式增长保持警惕, 对以刷屏增粉为目标的神奇增长手段保持冷静. 而关注那些真正能够给用户带来价值, 让他们心甘情愿变现和传播的特性
  突发性流量数据暴跌:
• 分析: 有没有业务变化/发布; 排除技术故障可能性(系统故障 环境故障); 流量降低的案发现场; 数据变化的渠道特征(web流量->直接流量/SE/引荐)
• 拆解: 新老用户 不同行为模式的用户(流量而非用户量) 业务有关数据因果 其他不可抗因素
• 处理: 分析邮件(发生了什么事/结论/原因, 数据分析过程, 思考和建议); 数据分析要形成结论; 进行必要的有效沟通; 要有应对策略
  具体数据辅助决策
• 通过数据了解用户是谁; 通过数据了解用户需求(搜索记录 假设反对意见 抽样用户轨迹); 提供什么解决方案(竞争现状 触达效率); 做出决定, 开工干活
  尽信数不如无数
• 数据的骗局(别拿相关当因果) 不要去预设你的期望 数据不是唯一驱动力 数据不是终点
  基本商业概念
• 利润=收入-支出(成本/费用 固定支出/浮动支出) 单元交易 毛利=收入(单次收入*交易次数)-浮动成本
  提高商业产品收入
• 定价空间 定价和成本无关 定价时尽可能留出一定空间 定价vs直觉拍脑袋; 扩展空间 TAM, total addressable market
• 大部分扩展情况下, 只能在速度/扩张成本/获客质量之间选两个 扩展成本的线性和非线性 寻找扩张中的机会
  烧钱获客
• critical mass临界质量; BEP 盈亏平衡点; 尝试观察/分析别人的商业产品->创造机会和负责人聊天->在自己产品中多尝试, 并追踪和积累数据
• 获客成本和流量 CAC TAC; 获客收益 LTV, 让更多人付钱, 并且持续的付钱->付款安全感, 功能支持免费试用, 足够吸引力, 支付和体验捆绑足够紧密 首充/复购
  赚钱意识和能力
• 逻辑与计算: 任何一个决定的来龙去脉, 受到的限制和带来的影响; 降价促销->盈亏点
• 不确定性与意志: 手上的资源是筹码->赌, 判断和取舍->最终盈利; 战略上谨慎细致深入的思考, 战术上尽可能凶狠执行到位
• 微妙的时机 平衡的艺术
  小程序
• 现状: 超级app+小程序模式 降低多段开发成本; 价值: 体验/用户归属不同
• 传播: 分布式入口 怎样让传播自然而然
• 设计原则: 碎片化/场景化/简单化 从传播出去设计功能; 风险与边界: 坚决和黄赌毒划清界限 尽量杜绝诱导分享 虚拟商品支付政策限制 被抄袭; 期待: 用完即走 当喧闹过去, 任何一个渠道, 最终都会回归理性, 回归用户价值

千万级用户产品如何打造

• 真正的难点其实并不在于想到, 而是选择(特性/时机); 每天和各种限制打交道(改变不了的, 只能接受, 与之共存)
• 极客时间: 通识教育vs职场教育; 招聘->闭环
  时刻时间产品规划
• 领域垂直用户群少->github官方数据, 编程教育普及->假设30%年增长
• 优势: 积累大量专题资源; 积累大量高端技术人员和KOL(key option leader); 线上+线下运营能力
• 用户量和收入更多取决于内容质量: 口语化 场景化 交付
• 产品验证: 打造IT知识技能图谱->技能树+学习路径
  推动团队
• 不要让你的队友失败
  需求评审
• 产品逻辑不一致: UI vs 后端业务逻辑 -> 真正需要平衡的是产品的实现效果/交互的优化/功能改进等与技术实现难度上的平衡
• 产品成败: 各种环境变量 掌舵人的价值选择与世界观
• 技术问题最优解 vs 现实问题当前解
• 强需求/弱需求/伪需求 用户需求/产品创造需求
• 件件有着落, 事事有回音
  一次简洁并有效的产品分析
• 产品分析->理解学习和启发 竞品分析->对抗/共存
• 主流程走一遍, 形成产品信息架构->解决谁的什么问题, 切中哪些场景->会有什么方案来解决, 会有什么差异->哪里自己没想到的, 哪些策略和设计可以记录下来->竞品的定位和资源差距->竞品用户/客户的流入流出及口碑, 各条产品线, 运营成本->坚持自己
  分享有赏->关键决策
• 找到需要重点关注的用户; MVP 快速试错; 内容为王; 一切就绪, 全力以赴
  数据分析验证新功能效果
• 内力->强动力高效的自传播; 外力->持续有节奏的推广; 分享返现+限时优惠
  新用户转化为忠实长期用户
• 蹦失: 了解 行动(精简 门槛后移 设计好新用户引导) 打动
  产品面试
• 答案都不重要, 重要的是你的思路和表达; 一定不要试图伪装自己; 面试答得好vs成为优秀的产品经理; 见识/思路清楚
  职业发展阶段
• 交付特性, 把交代的功能点做好-> 交付业务目标 -> 交付战略
  基本数据能力和意识
• 数据是PM最忠实的伙伴: 养成数据走查习惯(第三方工具->宏观指标, 日活/用户新增/留存等 收入/总收入/总订单数); 建立数据体系(咬牙坚持过前期); 数据仪表盘
  极客时间获客与传播
• 持续增强产品的核心功能, 为用户创造更多价值: 丰富内容, 构建IT知识图谱; 强调知识交付, 提升产品价值(交付感 品控手册); 重心促活提升粘性
  流量平台->资源匮乏平台
• 规模不同->质量要求/谨慎程度差异->产品的流量结构也完全不同; 客观业务差异vs主管感受落差; 职业素养
  收集数据前后
• 开始前: 用数据论证和预演目标; 开始埋头产品的时候很容易陷入细节, 可以随时回头来看看这些数据
• 开始后: 纵向(产品内部)横向(竞品/渠道)的标杆数据
• http://iamsujie.com/8000/8018/
  大众通用型vs受众小垂直领域
• 如果BAT也做和你一样的事情: 不屑做 不擅长 等不及; 希望->大公司做平台型, 小公司做更垂直和更具体的事情
• 具体的力量 算法的力量(数据量适中/数据非标/动态性强) 渠道的力量 创业团队/巨头/巨头里的小团队
  未来产品发展趋势
• 用户品味上升 为版权付费 知识教育付费
  上手体验app
• 用例: 用户+动作+流程->价值; 信息架构: 概念实体+结构关系+设计; 交互/UI: 内容生产消费; 运营增长: 获客/激活/留存/传播+网络效应+团建/运营成本
• 商业策略: 收费模式+成本/利润+定价+市场规模; 其他: 风险+多端+团队+竞品; 应该深度长期地试着去体验一些应用
  app信息架构
• 文字专栏 视频课程 社群 音频 个人中心
  专栏销量过万

邱岳产品手记

产品经理的世界没有对错只有成败
产品才是唯一名片
专栏: 交谈的窗口 求知的窗口 vs 教程 知识
产品经理的基本功 实战素养 产品观点和思考 产品案例分析

验证码:

• 不要把责任推卸给用户 方案选择的平衡 验证码的进化
  工具指南:
• 纸笔+scanner; 原型工具 axure/keynote/omniGraffle/sketch/墨刀/POP; 思维导图 mindmannager/mindnode/xmind; UML startUML/Visio/LucidChart/ProcessOn
  关于需求变更:
• 唯一不变的, 就是变化本身; 拥抱变化
• 需求不会变更, 变更的是实现; 挖掘需求背后的需求; 给需求分析留出时间; 需求评审
• 「具体」的力量; 变更时机的选择; 让团队能消化需求变更;
  产品被人抄了:
• 世界上只有2种产品, 一种没人用, 一种被人抄
• 摆正心态, 泰然处之 -> 别担心, 抄不走的是气质 -> 不要将产品的护城河建在脸上 -> 做有积累效应的事情 -> 有条不紊, 不要情绪化处理
  如何借鉴灵魂:
• the early bird catches the worm, but the second mouse gets the cheese.
• 不要像素级抄袭; 脑子里带着自己的问题; 追本溯源, 知其所以然; 跨领域跨行业借鉴; 致敬与付费
  产品规划:
• in preparing for battle i have always found that plans are useless, but planning is indispensable; no battle plan ever survives contact with the enemy
• 自下而上vs自上而下; 产品规划<>功能发布计划; 更宏观的视角和判断vs具体的项目和特性列表; 很难给出准确的时间点
• 留白; 定期回顾和更新产品规划; 产品规划到项目交付的节奏感;
  AI时代的产品经理:
• 唯一能持久的竞争优势是胜过竞争对手的学习能力; 纸上得来终觉浅
• 需要学算法 -> 从视频开始 -> 从网上文章抓出关键领域 -> 写写程序找找感觉
• 产品和算法的结合粒度要小 -> 要重视工程的力量 -> 利用产品最大化算法和工程产出结果 -> 做好数据规划 -> 去完美主义理解算法的不确定性
  在内部产品中找到产品经理的价值:
• 心事浩茫连广宇, 于无声处听惊雷
• 内部产品: CRM ERP CMS
• 用户离你很近: 资源显性化 项目流程化 用户研究的最佳试验场
• 不要成为功能经理, 化被动为主动: 跳过方案, 寻找背后的动机和诉求; 统一战线, 成本收益一致; 发挥强项, 用技术帮助业务
  产品经理获取非权力性影响力:
• 何况异形体, 信任为股肱
• 建立信任是个长期的过程; 如何试错; 要重视承诺, 不要找借口
  与开发打交道:
• 横看成岭侧成峰; 兄弟睨于墙, 外御其务
• 为什么vs怎么做; 甲方乙方(邮件签字画押 开小会); 加强沟通互通有无; 专程交代业务规划和产品价值; 掌握技术概念和技术语言
• 合作共赢: 全流程参与; 多听工程师的意见; 不要强迫工程师做评估; 背黑锅与争取利益; 互背KPI, 同仇敌忾; 建立良好个人关系
  基本功: 图文
• 没有内容的形式和没有形式的内容, 都是不能存在的; 即使存在的话, 那么, 前者有如奇形怪状的空洞的器皿, 后者则是虽然大家看得见但不认为是实体的空中楼阁
• BDR 商业需求文档 MRD 市场需求文档 PRD 产品需求文档 UC 用例文档 FSD 详细功能说明 产品原型/交互稿
• 如何写一份交互说明文档: http://heidixie.lofter.com/post/b8226_168d4b5
  基本功: 产品用例
• 世间无限丹青手, 一片伤心画不成
• 概念模型图 流程图/泳道图/时序图 状态图 用例图
  产品世界的暗黑模式: 操纵的诱惑
• 卑鄙是卑鄙者的通行证
• https://darkpatterns.org/: 操纵来自于基因 尊重和磊落的用户感知价值低 不成熟的劣币驱逐良币
  写好产品文档的诀窍:
• 产品文档是产品经理交出的第一个产品
• 明确受众/目的/形式; 知其所以然, 然后知其然; 打造良好的阅读体验->金字塔原理/逻辑/格式; 厚->薄
  产品分析的套路
• 自小秦楼望巧, 吴机回锦, 歌舞为谁; 能帮助我们完成进步的, 恰恰是人类的天性本身; 知到蓬莱难再访, 问何方法得长生; 不是在测试你, 而是你在测试我们
• 谁是利益相关者: 利益相关者, 不只用户;toB toC 的不同决策方式; 上下游特点和平台价值
• 解决什么问题: 重视解决的问题而不是解决方案; 把自己放进场景吃自己的狗粮; 转益多师, 加深对场景的理解
• 如何出解决方案: 解决方案是一个产品设计者最终输出的东西; 大量把玩各种互联网产品和服务; 方案和手段上的创新并不多, 真正困难的是挑选和平衡; 利用其他手段, 比如财务(闪电退款); 游戏把很多人性的东西利用得很好
  排定需求优先级:
• 一朝需求不称意, 口里驱蛩心上蚝; 民为贵, 社稷次之, 君为轻, 是故得乎丘民而为天子, 得乎天子为诸侯, 得乎诸侯为大夫;
• 避免毫无价值的正确; 规模(Total Addressable market, 趋势, 地域)/频率/强度->排定优先级
• 价值曲线分析: 罗列利益相关者和他们的感知价值; 对问题进行优先级排序; 将问题指标化并拆解; 整体权衡和排序; 综合考虑解决方案
  需求评审:
• 问渠那得清如许; 预则立, 不预则废
• 讨论什么: 需求收集和分析; 不同利益方博弈; 项目落地实施的计划管理
• 受众/目的: 需求方利益方->对需求的理解和分析; 研发团队->需求背景; 需求方->产品解决方案; 哪些人->业务->方案
• 控场: 当心知识诅咒(知道一个知识后很难想象不知道这种知识的情况) 不要强迫要吸引 用自己的态度感染别人 不要为了赢而争吵 小公司->频繁沟通
  关于产品经理的12个问题:
• 有AI背景的PM: 有过产品成果; 分析别人做过的产品; 介绍学到的知识与方法
  鸡汤:
• 取一利生一弊深思熟虑抗住诋毁; 没有任何一个抉择是生死抉择; 什么都不做, 或许已经跑赢了大盘; 平淡无奇, 十之八九; 坚持执行, 不要绣花; 多喝热水
  项目管理心得:
• 将者, 智信仁勇严也.
• 影响力>权利; 管人>管事; 交付>计划; 正确看待项目管理工具; 稳住才是赢
  从游戏中学习产品设计:
• 玩游戏, 就是自愿尝试克服种种不必要的障碍; 要保持淡定, 就算输掉了比赛, 还有人生
• 游戏设计手段: 持续实时的反馈; 人性的开关; 与社群建立联系; 构建意义
• 游戏机制为核心的启发: 那些精巧的处心积虑的功能性设计, 远不如关键性的机制设计来得重要有效
  你的快乐是哪一种:
• 外在奖励vs内在奖励; 不吝给予克制索取

案例分析 Trigraphy

• 利用设计, 来管理用户对于进度的认知; 如何将2个不同的页面更顺滑的连接起来; 通过一个随机效果设计去区分不同级别的用户
  案例分析 Guardian
• 卡片设计 文章中的扩展阅读 手势导航设计
  案例分析 hopper:
• 产品是需求的灵魂, 我们需要让产品和功能贴着需求与场景长出来
  案例分析 labRdr:
• 从用户场景出发, 贴着场景设计产品; 用户收集数据的透明化处理; 产品和用户的每一次互动, 其实都是一次交易
  Mimo & learn py
• mimo: 题目设置->简单编程基础; 答题反馈设置; 成就体系
• learn py: 利用社交的方式增加用户粘性
  WWF together: 情怀设计
• 用动效传递暗示; 望向镜头的眼睛; 沉浸式交互; 引入深思的传播和分享
  Fabulous:
• Material Design; 藏在姓名中的细节; 循序渐进的引导; 替用户负责人
  PathSource:
• 导航的迷茫; 视频的直观渲染
  Quartz:
• 聊天式界面的黏着力; 模拟人类的对话感; 建立在对话模式上的小说阅读; 对话式交互使用->在一些需要跟用户循序渐进交互的过程中使用这种方式
  Google Primer:
• 自然接收的暗示; 独特的信息展示; 类似的卡片应用
  Google arts&culture
• 首页feeds流; 知识图谱+标签+搜索->撑起内容体系结构; 快速定位到一个主题; 浏览作品的几种观赏方式
  知识星球:
• 手机版的论坛: 从哪里看都像是论坛+细节差异->另一个物种; 蒸发式降温; 微信推送->拽人机制; 发现机制
  SeatGeek:
• 门票的快速浏览; 票价的直观筛选; 位置的真实视角; 卡片的流畅转场
  unread:
• 设计美学->咋见之欢vs久处不厌; 字体差异->英文vs中文; 信息架构的逻辑->解决问题vs制造问题
  chartistic:
• 「假数据」的靠谱->假数据填充, 直接可以看效果; 被放大的屏幕; 自由度的取舍; 从场景出发

左耳听风

洞悉技术本质, 享受科技乐趣: 程序员技术练级攻略 成长 管理
业精于勤行成于思

• 技术变现: 打工vs在公司工作提高自己的技能->更多时间研究技术; 最好的seo就是独一份; 出书vs培训; 25-35是每个人最宝贵的时光, 要用在刀刃上; 技术和技能领先/对技术本质和趋势的敏感度; 只要你能帮上大忙就一定会赢得别人的尊重; 同样的for循环, 你写在这里一钱不值, 而我那里就值2k
• 如何技术变现: 积跬步; 关注有价值的东西->市场需求/技术趋势; 能体现价值的地方->高速发展的公司; 动手能力很重要; 关注技术付费点->帮别人省钱/挣钱; 找到有价值的信息源; 输出观点和价值观; 朋友圈很重要; 会赚钱 会投资 时间比钱重要

渴望 热情 选择:

• 加班没时间学: 对学习是有渴望的
• 写这么多东西: 学习阶段->利益驱使阶段->记录自己观点打脸阶段->与他人交互阶段
• 职业发展: 20-30打基础, 30-40发展; 客观审视自己->激进冒险vs按部就班; 确定自己想要什么->「极端」, 不随波逐流; 长期可能性vs短期功利; 关注得到vs失去; 不要和大众的思维方式一样
  时间管理: 同扭曲时间的事情做斗争
• 主动管理: 不是管理自己, 而是同事+自己的信息
• 学会说不: 提供可选方案vs回绝 部分满足 共同抗压->有条件的说是
• 加班: 两害相权->bug
• 开会: 讨论问题vs讨论方案 有议题vs有议案
  利用好自己的时间:
• 投资自己: 基础+文档(系统的学习) 解放生产力(解放自己) 自己成长 建立高效环境
• 规划: 优先级 短作业 想清楚再做 长期利益
• 用好时间: 将军赶路不追小兔 形成习惯 形成正反馈 反思+举一反三
  识别表象和本质:
• 兴趣和投入: 需要保持 可以培养->正反馈/成就感
• 学习和工作: 解决实际问题/和他人讨论/高手帮助->学习/成长; 学习方法->对新事物的学习能力
• 技术和价值: 规模化/高效解决问题
• 趋势和未来: 被人控制的->有权有是有钱的公司和国家->成长到加入第一梯队

技术领导力 解决问题:

• 技术是否重要->野蛮开采->资源整合->精耕细作->发明创造; 长期->差距
• 是什么: 尊重技术, 追求核心基础技术; 自动化+组织效率; 解放生产力->提高人效; 可重用的技术组件; 坚持高于社会主流
• 如何拥有: 所有工程师都有机会; 能够发现问题->解决问题的思路和方案并对比->正确的技术决定->更优雅/简单容易的方式解决问题->扩展性/重用性/可维护性->正确的方式管理团队->创新能力
• 4个方面: 扎实的基础技术 非同一般的学习能力 坚持做正确的事 不断提高对自己的要求标准
• 如何拥有: 基础技术->编程(c/编程范式/算法/数据结构)+系统(计算机系统原理/操作系统原理和基础/网络基础/数据库原理/分布式技术架构)->不可速成; 提高学习能力->信息源/与高手交流/举一反三/不怕困难; 坚持做正确的事->提高效率/自动化/前沿技术/知识密集型/技术驱动; 高标准要求自己->Google评分卡/技术嗅觉/实践,学以致用/lead by example
  大家愿意追随的leader:
• leader vs boss: 指导vs驱动; 制造热情vs制造畏惧; 面对错误->解决问题的技术或管理方法vs人事惩罚; 展示怎么做vs只是知道怎么做; 发展人vs用人; 给予团队成绩vs从团队收割成绩; 沟通+写作vs命令+控制; 跟我上vs给我上
• 帮人解决问题; 被人依赖(甚至敏感话题, 比如猎头, 吐槽公司); 赢得他人信任(相信你能做成事->能打开心扉说事); 开放的心态+倾向性的价值观; lead by example(ABC, always be coding); 保持热情和冲动; 抓住重点看透事物本质; 描绘令人激动的方向, 提供令人向往的环境; 铺路->给他人创造机会
  故障处理:
• 快速恢复: 重启+限流 回滚 降级 紧急更新
• 准备: 服务地图: 以用户功能为索引的服务和资源的全视图->导航仪: 为各个服务制定关键指标/一套运维流程和工具/应急方案->故障等级/故障演练/灰度发布
• 最佳实践: 复盘(整个处理过程 原因分析 5why 整改计划) 故障责任人(对事不对人) 整改方法->技术手段 根除问题的本质(举一反三 简化技术架构/流程/组织 全面改善优化整个系统/组织)

程序员应该知道的知识:

• 要读的书: https://stackoverflow.com/questions/1711/what-is-the-single-most-influential-book-every-programmer-should-read
• 应有的知识: http://matt.might.net/articles/what-cs-majors-should-know/
• LinkedIn 代码复查: https://thenewstack.io/linkedin-code-review/
• 代码质量研究报告: https://cacm.acm.org/magazines/2017/10/221326-a-large-scale-study-of-programming-languages-and-code-quality-in-github/
• c++软件性能优化: http://agner.org/optimize/optimizing_cpp.pdf

程序错误处理 error code & exception:

• c: errno()+errstr()
• go: 多返回值(err, res) 资源清理(defer)
• c++: 资源清理(构造函数+析构函数)
• 异常 exception: 不期望发生vs可能会发生
• 场景: 资源错误 程序错误(log/监控/报警) 用户错误(通知用户端)
• 异步编程: onSuccess() onFail()
• 最佳实践: 统一分类错误字典 同类错误的定义最好可扩展 同类错误处理同样模式 定义错误严重程度 错误信息vs错误码 忽略错误最好有日志 注意不停报错 错误处理逻辑vs业务处理逻辑 尽可能在错误处理的地方处理错误 尽可能返回原始错误 处理错误+清理资源

数据安全:

• equifax信息泄露 + apache struts 漏洞
• 数据泄露攻击: 框架或库已知漏洞/暴利破解密码/代码注入(sql/xss/csrf)/程序日志/社会工程学
• 数据管理: 只有一层安全; 弱密码; 向公网暴露内部系统; 系统安全补丁; 安全日志被暴露; 保存了不必要的用户数据; 密码散列
• 安全建议: 追踪依赖的安全性声明; 建立快速发布带安全补丁产品的流程; 所有复杂软件都有漏洞; 建立多个安全层; 针对公网资源建立对异常访问的监控机制
• 技术上的安全做法: 区分敏感数据->隔离/加密->api交互而不是直接使用数据->关键信息传到外部系统需要做通知(用户/管理员)

go/docker:

• 语言简单上手快; 并行+异步几乎无痛点; lib库小而全; 社区; 工业化标准; 杀手级应用; 提高开发效率的框架; 巨型技术公司做后盾; 软件开发中的痛点
• PaaS: 软件生产线devops; 分布式服务化; SLA; 软件能力的复用
• 技术的发展过程很重要->技术变迁和行业发展; 关键新技术->抢占先机

分布式架构:

• Amazon: 分布式团队(two pizza team) 分布式服务查错 开发all(eat your own dog food) devops(运维优先->简化/自动化) 内部服务/外部服务一致
• 需要注意的问题: 异构系统的不标准问题 系统架构中的服务依赖性问题 故障发生的概率更大 多层架构的运维复杂度更大 分工->协作统一和规范ch
  技术栈:
• 目标: 大流量处理 关键业务保护
• 提高架构性能: 缓存 负载均衡 异步调用 数据镜像 数据分区
• 提高架构稳定性: 服务拆分 服务冗余 限流降级 高可用架构 高可用运维
• 关键技术: 服务治理 架构软件管理 devops 自动化运维 资源调度管理 整体架构监控 流量控制
• 大纲: 应用整体监控 资源/服务调度 状态/数据调度 流量调度 开发/运维自动化
  全栈监控:
• 多层体系: 基础层(cpu等) 中间层(nginx等中间件) 应用层(http访问/调用链路等)
• 好的监控系统: 监控数据可以辅助到业务而非隔离 监控关键数据项而非非常多(信息太多等于没有信息) 关注应用整体SLA 关联指标聚合 快速定位故障
• 场景: 体检->容量管理/性能管理 急诊->定位问题/性能分析
• 如何做: 服务调用链跟踪 服务调用时长分析 服务topN视图 数据库操作关联 服务资源跟踪
  服务调度:
• 服务关键程度和服务的依赖关系: 微服务是服务依赖最优解的上限, 而服务依赖的下限是千万不能有衣懒环 依赖反转->container/pub-sub
• 服务状态和生命周期管理: Provision ready run update rollback scale destroy failed
• 整个架构的版本管理: 服务版本 运行环境 实例数范围
• 资源/服务调度: 服务状态的维持和拟合 服务的弹性伸缩和故障迁移 作业和应用调度 作业工作流编排 服务编排
  流量和数据调度:
• 功能: 服务控制(发现 路由 降级 熔断 保护) 流量控制(LB 流量分配 流量控制 异地灾备/多活) 流量管理(协议转换 请求校验 数据缓存 数据计算)
• 关键技术: 高性能 抗流量 业务逻辑 服务化
• 状态数据调度
• 分布式事物一致性
  PaaS:
• 软件工程能力: 提高服务SLA(高可用系统 自动化运维) 能力/资源重用/复用(软件模块复用 软件运行环境/资源重用) 过程自动化(生产流水线 自动化运维)
• 本质: 服务化 分布式 自动化 分层开放 高可用 devops
  设计模式:
• 弹力设计: 认识故障和弹力设计 隔离设计 异步通讯设计 幂等性设计 服务的状态 补偿事务 重试设计 熔断设计 限流设计 降级设计
• 管理设计: 分布式锁 配置中心 边车模式 服务网格 网关模式 部署升级策略
• 性能设计: 缓存 异步处理 数据库扩展 秒杀 边缘计算
  经典资料: https://time.geekbang.org/column/article/2080
  分布式数据调度相关论文: https://time.geekbang.org/column/article/2421

编程范式: 泛型编程 类型系统和泛型本质 函数式编程 修饰器模式 OOP 基于原型的编程范式 go语言的委托模式 编程的本质 逻辑编程范式 程序世界的编程范式
区块链技术: 革命性和技术概要 哈希算法 加密和挖矿 去中心化的共识机制 智能合约 传统金融和虚拟货币
程序员练级攻略2018: 技术资料
程序员面试攻略: 面试前准备 面试中技巧 面试风格 实力才是王中王

高效学习 端正学习态度

• 主动学习vs被动学习
• 低水平勤奋 努力读更多书 满目追求阅读速度和数量 使蛮力 -> 要思辨 要践行 要总结和归纳
• 浅度学习 -> 深度学习 高质量信息源和第一手知识 知识连成图 不断反思思辨 举一反三并践行 -> 知识采集/知识缝合/技能转换
• 学习是为了找到方法 学习是为了找到原理 学习是为了了解自己 学习是为了改变自己
  高效沟通 talk和code一样重要
• 沟通 -> 通讯协议

魔数 0x5f3759df: 平方根倒数速算 浮点数
机器学习: https://time.geekbang.org/column/article/862
git协同工作流: gitflow/githubflow/gitlabflow -> 微服务/soa/devops -> 软件架构/软件开发流程