近期发生了挺多傻逼事情的：
- 事件一：某某团队上线某某系统，三次上线三次回滚(后经老大指正，其中一次是另一个团队所为)。
- 事件二：针对某某系统的一些逻辑，都是X问A，A说问问B，问了B说大概C知道，绕很大圈才能大概凑齐一个逻辑。
- 事件三：接手了一个架构复杂功能单一却没有任何研发测试相关文档的垃圾搜索引擎系统。要啥没啥，和第二点提到的系统还真是一个套路，啥逻辑的确认都要问一圈儿人。还真是一个团队生出来的垃圾系统，有样学样。
吐槽完了，对这些设计架构的人都不知是死是活的系统，几经转手，无人了解细致的系统，也没必要浪费过多口水了。
最近在读《任正非语录》，发现任正非的一些思想很尖锐，看待问题非常善于抓核心。想起曾经参加的阿里敏捷研发培训，结合工作，有了一些感悟。
对照着开头吐槽的事情，一一对应着说吧。
事件一
愚蠢的事件，发生了三次。《安娜卡列尼娜》中说到：“幸福的人都是相似的,不幸的人各有各的不幸”。对这个事件的描述还真是精准。
升级失败，每次原因不同，还真是玩儿出花了。某某团队的研发，对自己负责的整体系统，没有一个全局的把握，每个模块每个流程逻辑都迷迷糊糊。研发都说不清楚的系统，到了测试，如何能保障的了？加上现网和测试环境有所差异（这点测试和研发都有责任，这种大型系统就应当确保测试环境和现网几乎一致），问题频出。
重大事故出现一次，就应当予以足够的重视并确保不再发生。结果倒好，类似问题反复发生了三次，团队良知何在？团队尊严何在？
事件二
一个负责系统的团队，被人问到基本运行逻辑问题都要绕一大圈，等个大半天才能拼凑出一个看起来还算靠谱的解释，还真是丢脸到家了。
系统负责人不是应该至少从宏观层面了解清楚系统吗？就算架构复杂，就没个相关文档查阅翻看的么？
事件三
系统转手前的负责团队，已经维护系统一年多了，但他们拿不出一份像样的测试用例和程序逻辑流程图或者相关说明文档。做人呐吗，不负责也要有个限度吧。事实证明，自然也是没有的，毕竟交接项目时，对方没有没有丝毫惭愧。还真是天生骄傲的团队，可惜做的事情烂透了。
通常写到这里，我会这样反问自己：“吐槽谁不会，你有什么资格呢”？
资格就是，我负责的系统，哪怕是中途接手的，只要碰到复杂逻辑实现，都会画出执行逻辑的流程图，不仅帮自己理解系统逻辑，也能帮测试同学了解系统运行逻辑。如果缺乏基础文档，那我会根据代码整理编写足够准确的接口文档、使用手册、部署文档以及运维手册等等。
我的系统，会尽量用最简单可靠的方式实现功能，我不觉得高大上的复杂的设计架构，除了显的自己牛逼，增加系统复杂度以外有其他价值。合理的使用技术并设计尽可能简单的架构实现目的，解决问题，并最终构建稳定靠谱的系统，是每一个架构应当具备的基本素养。架构，不是用来看起来牛逼的。
《任正非语录》中提到：“考核的核心指标是人均效益”。如果按这个标准衡量的话，那么事件一二三中相关团队的效益恐怕不会高到哪里，正效益没多少，反倒可能因为一个个垃圾系统给各个相关部门（测试、运维、驻地）造成各种拖累的负效益。
之前参加的阿里敏捷研发培训中提到，研发是要背业务目标的，系统好坏也是会影响研发绩效的。事件一二三，就是因为很多不负责的没有底线的研发，本身开发的系统结果不影响自己绩效，系统给公司带来的正面或负面的效益，对这些人没有任何直接影响。所以，相关产品和研发，才会糊弄糊弄做个自己都不曾仔细使用过的垃圾系统交差了事。
有这种团队，是一家公司的悲哀。
在能力范畴内，做靠谱的人、靠谱的事和靠谱的系统。研发骨子里应当具备：“我，天生优秀”的傲慢，并谦卑的做好每一件事情。
如您从本文得到了有价值的信息或帮助，请考虑扫描文末二维码捐赠和鼓励。
如本文对您有用，捐赠和留言 将是对我最好的支持~（捐赠可转为站内积分）
如愿意，请向朋友推荐本站，谢谢。
尊重他人劳动成果。转载请务必附上原文链接，我将感激不尽。