守株阁

透过结构看世界，洞悉事物本质思维的结构是重要的。透过结构看思考表达。 透过结构看思考表达-最最核心的底层应用。 透过结构看演讲呈现。 透过结构看问题解决。 透过结构看项目管理。 透过结构看商业创新。 透过结构看商业论证。 结构思考力不但是一种洞悉本质是思考艺术，更是一种透过结构看世界的生活态度。 三层次模型，结构思考力的核心理念结构思考力的三个层次： 理解（隐性思维显性化） 重构（显性思维结构化） 呈现（结构思维形象化） 金字塔结构，结构思考力的训练工具麦肯锡的三十秒电梯原理：无论面临多么复杂的项目，必须用三十秒在电梯里讲清楚。 以事实为基础 以假设为导向 严格的结构化 芭芭拉明托：哈佛商学院第一位女学员，麦肯锡第一位女性咨询顾问。《金字塔原理》是提高写作力至关重要的东西。 子结构：横向结构、纵向结构。先总后分：不要直奔细节，先把问题看清、看全，然后挑重点来说，要有路径。直奔细节意味着自己是急性子。别人没有和说话的人一样的，在思考路径上高速的移动速度，所以可能表达的效果一定会打折。 改学员 ppt 的例子：把结论表达清楚，主标题应该是结论。能够把工具类的问题讲清楚，是...

决定总是会消耗心力。不能做决定也是一种做决定。【先做一些不能有确定结果的行动，然后观察它，至关重要】。用行动代替思考，用手分担眼和脑的工作，可以缓解内心的焦虑。 三个关键原则养成收集的习惯确定“下一步行动”学会关注结果

你能几步做成一件事？瑞达里奥认为，通常有 5 步。 警惕邪教：独立思考，形成原则。 Professional Mistake maker：和其他放过自己错误的人不同，形成自己的错题集，反复思考。

Lambda 的好处 按使用付费（云计算都有这个特点）。 把资源（ CPU 或内存分配）的 quota 封装得很好。 无需关心监控和运维。 自动扩展（无需关心物理 nodes。node 既意味着系统可拆解，也意味着系统可联结）。 Lambda 的坏处 多步执行环节很慢 特定 function 的执行隔离不好，可能多个用户相互踩踏 ECSECS 云基础设施在架构上更易扩展，只要稍加改造就能和系统集成。 参考：《我们为什么从 Lambda 迁移到了 ECS？》

主流程 填写投保材料-健康告知、健康状况和意外状况很详细。 投保、缴费。 签名，回访。 数据结构： 1、投保材料。2、电子保单：包含主险和附加险，以及份数。

断·舍·离断 = 不买、不收取不需要的东西；舍 = 处理掉堆放在家里没用的东西；离 = 舍弃对物质的迷恋，让自己处于宽敞舒适，自由自在的空间。

基本方法论 识别风险 构建相应的应对模块 识别风险 业务风险：不可避免的意外、业务的荣枯和服务体验的优劣导致的某些指标的起落。 欺诈风险：恶意用户恶意骗取保险金。 系统性风险：自然业务发展过程中出现的意料之外的灾害。 建立事中监视模块建立特定的风控监控模块，应用策略。 要搞清楚如何评价用户在此场景下的风险指数，有可能需要借助其他场景的数据。

http://arthurchiao.art/blog/short-history-of-okr-zh/ OKR 的历史ORK 是目标管理领域的新工具。诞生于 Intel，帮助 google 取得成功。在国内主要是美团和字节在使用。 上世纪 50 年代，管理科学（management science）兴起，主要用意是提高公司效率。Peter Drucker 发明了 MBO（Management By Objectives，目标管理制度）。MBO 是一个过程，在该过程中，管理者和员工共同设定一个目标，然后定义各自需要做什么才能完成这一目标。 MBOs 显然是 Objectives and Key Results (OKRs) 的前辈。在 OKR 模型中，经理 设定一个目标之后，不再插手细节管理（micromanaging），而是信任自己的团队能够完成 这一目标 —— 和工业时代的管理方式相比，这是一种巨大和高效的转变。从很多方面 来说，这是第一种真正与新的信息时代相匹配的管理哲学。所以计件式的微管理意味着管理者还不能信任下属能够达成这一目的，但 OKR 就意味着简单高效了。 到了 ...

团队是执行力的基础产品的差异来自于执行力的差异，执行力的差异来团队的差异。人口红利的消失，呼唤精细化管理。 软件开发是一个富有创造性的职业，产品的质量、产品的迭代速度有很大程度上依赖于架构师和工程师的水平。如何让人更高效的发挥自己的价值，并且让个人价值更好的服务于整个团队需要，绝对是一项很重要也很体现个人水平的技能。 两种团队过分务虚过分务虚的团队对于业务和技术都比较缺乏深入的见解，运用了许多组织模型但却缺乏明确的解决问题的方向，我相信这些团队长期一定难以做出应有的影响力。 过分务实过于务实的团队指的是更关注于底层技术细节的准确性，但是缺乏更深层次更高维度的对业务整合的理解、对解决什么问题的解构、对团队协作和团队文化的建设；这种类型很容易很吃力但没什么真正的影响力、或者人心涣散。 系统设计从团队设计开始这是根据康威定律很自然的一个延伸，当年决定团队架构的时候，你就已经在决定系统架构了。 管理者是不是需要懂技术？根据这条原则管理者是需要懂她负责的业务的，而且需要非常懂。当然业务在这里很多情况下指的就是技术，但不仅限于技术本身，还包括技术和产业的结合，需要解决什么样的问题，技术、...

需求分析的三重境界第一层次：用户的观点和行为第二层次：用户的目标和动机第三层次：用户的人性价值观 用户场景分析 谁遇到了问题[WHO] 什么环节遇到了问题[WHEN] 在哪里遇到了问题 [WHERE] 问题是什么[WHAT] 问题产生原因[WHY] 如何解决[HOW] 解决成本[HOW MUCH] 商户 售后 因为 xxx，不得不退款 造成经营损失 平台出于成本考量，不能对此进行赔付 通过 新建 xxx 产品能力，提供补充能力 待思考，也许是中 需求背景要讲场景，讲数字，有定性 项目评估 项目收益：某项指标会上升、某项指标会下降。 项目目标：上线时间。 涉及资源：涉及几个部门和团队？ 具体产品设计方案产品到底有几个维度的细节，要建设的细节分别是什么。