事倍功半：我学写工程准则的教训

原文地址

我曾在一家做得不错的初创公司工作。它看起来很成功，因为我们的工程师人数、工作范围和团队数量都在稳步增加。这个过程中我意识到，要想在初创科技公司这个混乱的战场游刃有余，我们需要一套工程原则和进展框架来引导团队。

我决定撰写一份指南，帮助团队工作得出色，且不断进步。这是个艰巨的任务，但能带来巨大的回报。我怀着极大的热情接手了这个项目，在文件中倾注我的知识。它涵盖了我能想到的每一个角落：从处理边缘案例，到解决问题和协作的最佳实践。我希望这些文档一统天下，成为开发者的一站式资源，这样无论他们遇到什么情况，都可以翻阅到所需的答案。

几周后，我写出了一篇全面、透彻......但完全无法阅读的文字墙。值得警惕的是，连我自己都难以理解。你看了之后最多会在 Confluence 页面上点个赞，然后就再也不会打开了。

摩西用几块石板和一把凿子就写下了整个社会的规则——我本该从中吸取教训，当时就把它废掉，但我没有。我为此付出的努力让我忽略了一个事实：这些文件更像耐力测试，而不是有用的指南。问题就出在，我把细节误认为是有效性。

这些文件被团队忽视一年之后，我终于意识到这一点，并重新思考我的方法。少即是多。将对团队的期望简化为最基本的原则，让十二岁的孩子也能遵守；再多就是徒劳。

因此我再次开始尝试，并用写作前的时间来确立这些基本原则。我不再试图规定每一个步骤或结果，而是重点鼓励正确的行为和态度。我希望我的团队能够共同学习，成为好伙伴，分担责任，互相提供反馈，自始至终对自己的工作负责，实现自动化，以及最重要地，要有商业意识。

最大的启示——少即是多。我一度追求面面俱到，忘记了人们更容易遵循一套适应性强的指导方针，而不是百科全书。规则必须简单可执行，这样人们才能在面对任何情况时，实时做出决定。应该引导，而不是控制。

---

💡 更多资讯，请关注 Bytebase 公号：Bytebase