说起打破陈规，变通，这事儿我最近可算是有了点心得了。不是说生肖的事儿哈，那些玄乎的玩意儿，我纯粹是当个乐子听听，要说真打破陈规，还得看自己怎么干。
以前干啥都喜欢按部就班，一步一步来，生怕走错。尤其是做项目的时候，流程图画得比谁都细致，中间只要一出岔子，就觉得天要塌下来了。结果就是效率特别低，一旦遇到点新情况，立马抓瞎。
有一次，我们接了个小项目，甲方要求挺多的，但预算给得贼紧。按我们原来的流程，光是需求分析和架构设计就得花掉将近一半的时间。我当时就犯嘀咕了，这么搞下去，时间根本不够用，而且人力成本也压不下去。
我当时就琢磨着，能不能把一些流程给简化掉。比如，以前我们非得把所有的文档都写得像教科书一样，这回我就想着，干脆做个“最小可行性产品”出来，先跑起来再说，文档就同步简单记录关键点。我跟团队一说，大家都有点懵，觉得太冒险了。
结果？前期是快了不少，但因为文档记录不全，中期的时候有个新来的同事一接手，立马出了岔子。他看代码实现和我们口头说的设计有点出入，结果把一个核心模块给改错了，差点导致整个系统数据混乱。当时真是急得我直冒汗。
那次教训之后，我才知道，打破陈规不是瞎搞，得有度。你不能把所有的规矩都扔了，有些规矩是用来保证底线和稳定性的。
我开始调整我的“变通”策略。我把流程分成两部分：核心流程和弹性流程。
核心流程，比如数据安全、权限管理、关键接口设计，这些东西我绝对不敢随便动，还是得按照严格的规范来，保证项目的基础不会崩。就像是地基，你不能偷工减料。
弹性流程，就是那些不影响项目核心功能的步骤，比如文档的详细程度、会议的频率、内部测试的流程等等。这些就可以根据实际情况来调整，达到效率和质量的平衡。
第一，针对需求变更频繁的项目，我们不再坚持“瀑布式”的完整需求冻结，而是直接拉着甲方的人进我们的项目群，需求一变动，立刻拉个线上小会，现场决定实现方案。这比以前走邮件、走正式文档审批快了不知道多少倍。
第二，代码评审，以前非得等到整个模块都写完才审，一审就发现大问题，返工量巨大。现在我要求，关键函数写完就小范围拉人来看，哪怕只有几行代码，也要确保设计思路是对的。这样小步快跑，比推倒重来省事儿多了。
第三，工具链的变通。我们以前一直用一套很重的测试框架，每次跑全流程耗时很久。后来我发现，很多功能我们根本用不上，就自己写了个轻量级的脚本，只跑最关键的单元测试和集成测试。虽然不够“规范”，但能快速定位问题，提高了迭代速度。
我们团队的效率比以前高了至少三成。大家都觉得工作起来没那么僵硬了，遇到问题也不怕了，因为我们知道哪些东西是可以灵活处理的，哪些是必须守住的底线。
所以说，要问打破陈规最喜欢变通的是哪个“生肖”，我觉得是“实践”。只有通过实践，才知道哪些规矩是束缚，哪些规矩是保护。
