从0开始做SAAS - 技术团队的日常规范（用方法和标准做事）

0: 协作：对方发出的问题，如果你正在解决，要注意给对方一个信：“稍=，预计10分钟”、“稍=，预计还需要10分钟”、“正在解决，稍后回复”等等。保持交互

1. 问题：有问题一要解决，二要究其根本，凡事根据自己经验多问为什么，经验除了“做”可以积累，“问”也是一种不错的方式

2. 矛盾：要正视矛盾，要寻求沟通解决矛盾，以解决问题为首要目标， 不做无畏的争执，不为短期利益或者是面子去做无意义的纠缠

3. 困难：有解决不了的问题会上升为“困难”，遇到“困难”先问自己这样几个问题：

> 如果要解决这个困难，我们要解决哪些问题？

> 是技术实现的问题，还是业务设计的问题？

> 是自己一个人的问题， 还是一个需要团队相互配合的？

> 如果需要帮助，谁可以帮助你？如果需要配合， 需要谁配合你？

4. 方法：不能快速用既有经验解决的问题，要寻求解决方法

5. 经验：经验只能做参考，不可做唯一标准

6. 沟通：沟通我多次提到“双向模型”：push + pull。push 就是别人告诉我们的信息， pull 是我们主动去问来的信息。（灵感来源于 TCP 协议， TCP作为绝大部分主流通信协议的爸爸一定是有他的价值的）

7. 质疑：当没有证据的时候，不应该质疑对方的判断，即使你是某个领域的专家， 在质疑前也可以先听完对方的非重复性发言，并认真评估和思考。

8. 被质疑：尽量避免使用“可能”、“有部分接口”（哪部分不知道）、“大概”等不确定字眼，要用确定性回答，不确定的宁愿不答

9. 态度：严谨、负责。对于不合理的要求要慎重：要么说服对方修改方案， 要么让不合理变成合理。

例如:

> 如果对方要求我们改接口，如果是为了业务需求我们应该认真思考是升级参数还是升接口版本，

> 如果仅仅是为了他写代码方便我们一定要保持谨慎：我们的接口设计是否合理？他为什么觉得这样方便？他的思路是不是还有待完善？

10. 测试：提测后就是测试的天下，测试有权对测试环境做任何操作，同时也要承担测试环境对应的义务，例如保持测试环境的稳定可用等

11. 开发：版本迭代多，开发前应先评估当前需求对原需求的影响程度，并且要求书面化例如：需要加个 updateById 方法，并且在相关的 xxx 、yyy 业务处都要加上这个方法；写详细设计再写代码，尤其是新同学这点务必执行。

12. 态度：忌心高气傲，放低姿态多去观察学习，凡事问清楚为什么，问了别人不说是别人的问题，不问就是你自己的问题