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