考虑价值的原则

任何产品都要有其价值（经济价值、情绪价值、精神价值、汇报价值等），其价值必须可以支付其成本。

同样的，每个带团队的人，都要去考虑一个问题。
这个季度，团队投入给公司带来了多少收益？能否覆盖团队成本？有没有把价值最高的事情，放到最高优先级？

解决问题根源的原则

一、当一个问题引起了多个问题后，不要花过多精力试图去解决那多个问题，而是要集中精力把问题的根源解决掉。
在我们的工作生活中，经常会有这样的问题：
1、问题A发生，引起了次生问题B、C、D；大家花了大把精力去弥补B、C、D，但对A确置之不理
3、下一次问题A发生，又会引起次生问题E、F、G；然后大家又去搞E、F、G，但仍对A置之不理
4、过了一段时间，问题弥补的差不多了，系统看起来正常了
5、极端情况发生，系统挂了，但由于系统中有一堆的补丁，没人再搞得清楚究竟为什么
6、系统无法维护

二、当一个问题发生后，不要花过多精力绕过问题，而是要集中精力把问题的根源解决掉。
在我们的工作生活中，经常会有这样的问题：
1、任务1中发生了问题A，大家不花时间考虑去解决问题A，而是通过另一个任务2去绕过问题A
2、结果任务2有产生了问题B，大家有要用任务3来绕过问题B
3、经过一堆蹩脚的操作，任务1完成了，同时完成了其他几个任务
4、极端情况发生，系统挂了，但由于系统中有一堆神操作，一堆诡异的代码，没人再搞得清楚究竟为什么
5、系统无法维护

三、避免X-Y问题
在我们的工作生活中，经常会有这样的问题：
1、甲对问题X一知半解，无法解决X问题，但认为Y问题可以帮助解决X问题
2、于是甲问乙，Y问题如何解决
3、乙从来没有遇到过Y问题，两个人激烈的讨论了一番，得出了一个蹩脚的方案
4、甲用了这个蹩脚的方案象解决了问题Y，征性的的解决了问题X
5、乙有一天看到了这个项目，很可能会告诉甲，问题X在业界有一堆的解决方案。
6、而甲的方案有n多场景没有考虑，系统无法维护

不乱用新技术原则

当技术用到了正确的地方，才会变成生产力。技术在转化为生产力之前，就是单纯的技术。

一个技术是否用到产品中，是要看其是否可以解决亟待解决的问题，是否不会引入更多新的问题，是否可以提高工作效率，学习曲线是否陡峭、人才招聘是否容易、是否有广泛的社区支持。

1、是否可以解决亟待解决的问题、是否不会引入更多新的问题
为了技术而技术在产品上是没有任何意义的，只有新技术可以解决产品的重要问题、并不会为产品引入更多新问题的时候，才具备了被选中的价值

2、是否可以提高工作效率
该技术引入后，是否可以提高编码、测试、实施的效率？

3、学习曲线是否陡峭、人才招聘是否容易
是本公司人员进行培训，还是社会人员招聘，要考虑清楚

技术够用就好，对于多数公司，并非越新的技术越好。记录几个能力够不到的例子吧：

2015年，一同行对公司某关键产品进行升级，从单体应用，切换到了微服务架构，并用了阿里的dubbo。大家没黑没白的干了近半年，最后微服务版本给到交付部门的时候，交付部门直接告知接不下来。

2018年，一同行应邀到一家公司做技术交流，发现该公司的Java程序员连maven都不会用，项目交付的时候，都是windows平台下部署tomcat交付的。
在这个时候，让他们切换到用docker交付就是要了这家公司的命。

2020年，某公司架构师，强制要求全公司的mq，从rabbitmq切换到kafka。切换后发现系统性能根本无法满足要求，该架构师就随着各个开发团队，不断去解决各种问题，最后该架构师只能走人。原因很简单，当时开发人员每天加班加到很晚才能回家，功能都来不及写，根本没人有时间去看kafka。连分区数与消费者的数量都配置不对，遇到慢消费问题，只有架构一个人。

结构要清晰，代码要整洁

项目越乱，代码越多，问题越多。

现场实施守则

1、一定要分清正式环境和测试环境，对正式环境修改一定要有充分的理由

2、不要在现场高峰期，做影响现场效率或稳定性工作

3、做批量操作或危险操作，一定要做好备份，并与项目经理沟通

4、如果要停止现场服务，一定要与现场人员沟通，否则现场人员会十分被动

5、普通实施人员，有时对整体流程和要达到的最终目标并不一定很了解，所以研发人员不可以与现场实施工程师沟通后直接修改方案，要经过产品经理或项目经理

6、如果流程变动，一定要与现场做好充分沟通；架构调整，一定要与产品经理做好沟通；

7、任务都有时效性，如果任务不能按计划完成，一定要提前沟通，不要等到一切都太迟了再沟通

8、紧急情况下，做的紧急处理，要将事件描述及处理情况及时通知到相关人员，并进行总结

9、多写一些防御性代码预防小概率事件，而不是做过多美好的假设，该发生的总会发生

10、遇到重复发生的随机性问题，要有刨根问底的精神

11、问题总会出现，不需要害怕并没有出现的问题，问题出现了以后要积极解决问题，并总结经验，尽量不再出现相同的问题

12、责任明晰，自己负责的事情要做好，其他相关人员应该做的事情，要积极推进。对于其他厂商应该做好但没有去做的问题，要与项目经理积极沟通

13、可以理解，但不可一味姑息纵容其他厂商，否则事情会越来越难处理。

14、研发人员与实施人员压力都很大，平时大家要相互体谅，相互帮助

15、欢迎补充