高效工作

技术方案沟通： 一个经验之谈，讲ppt方案时，不要暴露太多的实现方案，要把听的人的注意力放在思路和架构上面。因为实现方案千变万化，每个人有自己的偏好，容易被pk。

基本上，if u can't do something right now, u can't do it tmr or on weekends.

#离职#如果换个地方，问题能解决，那就换，否则要想一想。

技术方案ppt涵盖内容：背景、问题、具体方案包括（思路，问题回顾，实施设计）、作出哪些变更，时间资源预估。评估的会议要拉上相关方，会前要达成一致，会中具体的时间和投入资源的确认、排期，会后要有沟通。

对比/PK技术方案，一个要点是资源，一样的方案，都能实现，但是所使用资源未必一样，资源包括人力、时间、机器成本。前两个和复杂度有关联，关键在于提出者对方案很熟悉，能够说服大家，最后一个是比较客观的理由。

用结果来客观评价

依赖人而不是流程

软件开发的鬼故事:https://www.infoq.cn/article/c20etwzh3qhtidmr9idc

人和交互重于流程和工具

推动项目需求落地：分析各方成本收益，争取，打击

团队外，对接其他团队，尤其第三方，沟通方式要正式，对接前要明确，过程中要沟通及时，出现问题主动去解决。

技术方案讲演：

要有具体的 要有设计，设计的思路 可以预期的一个结果 可以实行的方案

会议：消除背后不确定的东西

例如：QA的case review能够消除开发和PM对QA阶段的不确定性

重点是把问题的解决办法提出来。

开会讲话要清晰，如果没讲清楚，大家都很迷茫

开会目的要清晰

汇报

做了哪些事，归纳，具体能带来什么提升 要做的事归纳，具体做什么

https://www.infoq.cn/article/AM44HRkGjr3aZh0PMaci

#leader# 明确方向，使团队往一个目标发力

#推动#事情有转机，就马上推动

工作中真正耗时的地方：

环境，开发环境和测试环境的搭建部署，这里面涉及很多，例如配置管理，分支管理，环境资源管理，例如多个feature穿插交给测试（QA在测A时，需要切换到一个更紧急的B）。 设计，无论是小的不能再小的改动，还是牵一发动全身的，都需要想想清楚之后，思路明确再动手。这里的耗时很难估计，对项目的熟悉程度，个人的技术局限，甚至个人做事的节奏，都会影响到。

团队沟通，一定需要有耐心，自己认为好的想法和点子，需要传达、消化、转化为计划、付诸行动这个过程。

工作效率

工作的需求：业务需求，技术需求，个人的想法 衡量效率：内在的条理，时间线、逻辑线清晰

如何全面和体系化思考问题：

多举例子，思考对应情况怎么处理，这个过程也同时会加深对问题的认识 讨论，不同人的角度未必一样，不同人的认识深度也不一样，未必能讨论出结果，但一定会加深认知 抽象建模，总结问题，提取出模型的部分，模型是相对不变的，有了靠谱的模型做参考，就能避免舍本逐末（或者叫过早优化） 我去，怎么感觉和DDD的方法论有点像啊，难不成潜意识是搬过来了？

不严肃地回答不严肃的问题

系统分析/系统设计，最重要的是流程图，交互图，类/模块设计

沉下心做事，也要有应变能力 一些应变的预案，提前的充分沟通

#软件工程团队# 和分布式一致性算法一样，变更的目标要提前拥有多数投票（不一定是多数人），为什么这么做？

明确和团队方向一致 团队知识的保留 减少沟通成本