灵活性与一致性的平衡之道

作者 | BRIAN BAILEY       译者 | 明明如月

责编 | 夏萌

出品 | CSDN（ID：CSDNnews）

你是更倾向于追求项目的一致性还是灵活性？

我们许多人都被模式和流程所吸引。当一件事情进展顺利，我们会试图找出如何复制这种成功。我们会说，“这个项目进行得非常顺利。下次我们还要这样做。”

当事情进展不顺时，我们会寻找哪些因素导致了这种不良结果。然后，我们会引入检查点以提供一种安全感。我们总会在某个时刻听到这样的规定——“从现在起...”。从现在起，每次部署都需要由高级程序员签字批准，我们不能在 QA 审核通过之前发布，每个团队都要进行每日站会以防错过任何细节，等等...

从经验中学习是我们改进的方式，但新的流程并不能保证我们想要的结果。我们想要的是安全和保证，但工作总是混乱的，也总会是如此。

过度追求流程化也会带来负面影响。它限制了你的灵活性，并拖慢了进度。

通常，你经常执行的流程可能是最佳流程，但并非总是如此。要给自己留下一些空间去尝试不同的方式。

在 37signals 公司，有时我们会花费几天的时间进行质量保证测试，这是由于工作涉及的风险较高或者影响面较大。然而，如果团队对自己充满信心，且某些疏漏的后果不大，他们也可以在无需质量保证测试的情况下直接发布产品。

我们有些功能会先在公司内部进行为期一周的测试，然后再将它们推向市场，而有些功能则直接发布。

新产品的开发过程有时需要一到两周的时间，其中包括大量的客户研究、技术反馈、讨论和修改。然而，有时一项提案可能只需要几个小时就能成型，原因是问题显而易见，解决方案也直截了当。

我们在管理项目时，通常会使用 Basecamp。在宏观层面，每个项目的所有工作都在一个对所有人开放的特定空间中进行追踪和讨论，同时，各个双人团队会定期分享他们各自的进展情况。

然而，实际操作中的运行方式却因团队而异。有些团队会频繁利用每日更新的 hill charts (山坡图) 进行任务跟踪，有些团队则选择每周发布一次项目进展的消息，而其他团队则可能仅在聊天中分享持续的反馈和评论。

如果强制每个项目都按照同一种方式运行，并逐一跨越同样的难关，那就可能会导致流程化程度过高，形同走秀。这种情况下，团队成员可能会坚持执行一些并不适应当前实际情况的任务，进而导致工作效率降低，并减少团队的自主权。显然，这并不是实现优质工作结果的有效方法。

当某个项目没有按照原计划进展，例如项目实际规模比最初预设的要大时，我们通常会有重审流程的冲动。你可能会思考：我们如何才能保证不再出现这种情况呢？

我们可能需要在项目前期投入更多的时间去深入理解工作内容，并预估所需的时间。或者，我们也可以确保每个方案都能得到多位开发者的审查。

然而，在急切地追求新流程和制定检查清单之前，有必要问自己，这种情况是个例还是常态？对可能只是一次性的特殊情况，我们无需进行过度修正。可以先将其记录下来，然后在发现类似模式时，再对其进行深入研究。

接下来，我们需要考虑的是整个系统的运作方式以及这个系统所追求的优化目标。每一部分都会对其他部分产生影响。如果每个项目都需要经过漫长的审查过程，那么在项目的后期阶段，很难为新的有前途的想法留出空间。如果我们放弃了追求机会和灵活性的能力，是否值得为了减少项目中的意外情况而降低了一些灵活性?

也许是吧。这是关于优先级和权衡的问题。改变某一方面，必然会对其他方面产生影响。

我们应该将流程视为最佳实践，然后将其与高度的信任和灵活性相结合。明确你想要实现的目标，然后执行任务的人自由决定如何实现目标。

你认为一致性和灵活性哪个更重要？