如何让努力不白费？<br>eg:实现登录功能？
反直觉的思维方式；<br>程序员的终是否和用户的终一致嘛？
想象的共同体：<br>集体想象
头脑中的创造，也就是智力上或者第一次创造
付诸实践，也就是实际的构建或第二次创造
在第一次创造多下些功夫，统一集体想象
给用户看产品样子，原型工具
模拟服务接口，呈现服务接口
要让程序员知道要开发产品的细节，<br>可以在任务上描述软件各种场景给出的各种行为。
践行’已终未始‘
逆向思维，先考虑结果
根据结果来确定要做的事情
总结
<h5>如果今天的内容你只能记住一件事，那请记住：<font color="#c41230" style=""><b><u><i>遇到事情，倒着想</i></u></b></font></h5>
Dod价值：你完成了工作，为什么他们不满意？<br>eg：小李和小张；---功能完成理解不一致<br>Definnition of Done(完成定义)
理解鸿沟
对完成的定义理解不一致
开发前，就定义好团队Dod概念
Dod的定义
清单列表
清单由一个个的检查项组成，用来检查我们工作完成情况
Dod的检查项是实际可检查的
Dod是一种思维模式，是一种可能消除不确定性，达成共识的方式。
接到需求任务，你需要先做那件事？
问题
功能列表的需求描述方式，将一个完整需求敲成碎片？对应开发看不到终
开发抽象用户故事。通过故事和产品达成一致？
验收标准，自测冒烟测试用例
验收标准，业务标准
开发需要考虑技术实现方案
事前需求分析，和需求方达成一致。减低理解鸿沟
总结
<font color="#c41230" style=""><u style=""><i style=""><b>在做任何事之前，先定义完成的标准</b></i></u></font>
持续集成：集成本身就是写代码环节？
持续集成
每日构建
尽早提交代码去集成
思考
<h3><b><font color="#f15a23"><i>我们公司持续集成工具链路很完善，方便。作为开发人员有必要去了解持续集成</i></font></b></h3>
精益创业：产品经理不靠谱，你该咋办？
产品评审之前，可以多问问题向产品经理
<b><i><font color="#c41230">我们必须要有自己的独立思考，多问为什么，尽可能减少掉到坑里之后的次数</font></i></b>
精益创业：面向不确定性创造新事物
尽可能少浪费的前提下，面向不确定性创造新事物。
提供我们产品思考开框架
总结
<h3><b><font color="#c41230"><i>默认所以需求都不做，直到弄清楚为什么要做这件事</i></font></b></h3>
解决了很多技术问题，为什么还在坑里？
独善其身不是好事，需要对外沟通
角色差异
不同角色工作上的差异是上下文差异
需要跳出程序员角色思维，扩大自己工作上下文
手里有了锤子，眼里都是钉子。
需要可以了解现在各个业务团队前后端合作模式，后端工作模式
工作上下文
扩大思考上下文
上下文context-管理模式
产品化BD,应该要扩大决策层的上下文，思考他们可能看到痛点 或问题
总结
程序员喜欢用程序解决问题
<h3><font color="#c41230"><b><i>扩大工作上下文，别把自己局限在一个程序员的角色上</i></b></font></h3>
为什么说做事之前要，推演？
接到任务，要做的不是立即埋头苦干，而是要学会思考，找出真正的目标
思考交流方式。如何独立承担任务，问问题，帮他梳理任务列表。
学会推演。一起都是以上线标准。来倒退到现在开发任务
上线计划
负责人要站到’最后一公里‘ 推演所有因素。梳理任务列表
问题解决方案
先从结果的局角度入手，看最终上线要考虑的因素
推演出一个可以一步一步执行的上线计划和方案。
根据推演出来的方案，总结要做什么任务？
应用场景
做产品的时候，先来推演一个产品如何推广，推广方案，通过什么途径推广给什么样的人
在做技术改造前，先来考虑上线是什么样的过程，以次来推演
案例：产品经理设计产品的时候只是考虑用户界面交互，全然不考虑数据来源，造成的结果：累死累活做出来的东西，完成跑不通，没数据源。
总结
动手做一件事之前，先推演一番。已结果来推演任务
你的工作是否可以用数字衡量嘛？
数字是诠释’终’的最好方式
熟悉又陌生的数字
从进化角度，人做事更多依赖直觉。
一些人说的，靠自己直接能把事情做好，那其实是洞见。
数据思维模式
做事之前应该要先思考如何测量这个事情的价值。测量一定要与数字挂钩
总结
要习惯用数字思考，基于数据做技术决策，预先设置系统指标
我们工作是不是可以用数字衡量
