前言

说实话，这个事情真的太常见了。在项目开发过程中，时间紧、任务重，大家都想赶紧把功能做出来，这种时候往往就容易出现一些临时方案。

但是呢，临时方案这个东西，用好了是救急，用不好就是埋雷。

今天就给大家分享一个真实发生的案例，看看在项目紧急情况下，我们到底应该怎么处理。

事情是这样的

李四最近在赶一个项目的进度。说实话，时间真的太紧了，按照正常的开发流程，根本来不及完成所有功能。于是呢，李四就动了个心思，用了一些临时的解决方案。

比如说，有些条件判断、有些循环逻辑，本来应该是根据接口返回的数值来动态设置的，但是为了赶时间，李四直接把这些值硬编码写死了。这样做的好处是，功能马上就能跑起来，测试也能顺利通过。

但是呢，这种做法在功能、代码规范上面肯定是有问题的。就像你盖房子，本来应该用钢筋混凝土浇筑的柱子，你用了几根木头临时支撑一下，虽然看起来也能立起来，但是，随着楼面东西越来越多，顶不住是时间问题。

矛盾爆发

项目负责人张三在重构代码的时候，就发现了这个问题。说实话，张三当时就火了，在项目进度例会上直接就和李四争论起来了。

从张三的角度来说，这种低级错误真的无法理解。代码规范这种约定俗成的东西，难道还需要一遍一遍地强调吗？如果每个人都这样随意修改代码，那项目质量怎么保证？

从李四的角度来说，他觉得很委屈。当时项目时间那么紧张，我想出了临时方案，至少保证了功能按时上线，自己不但没被表扬，反而被批评，心里真的很不好受。

双方都觉得自己有道理，看起来这个问题真的很无解。

张三的问题

说实话，张三作为项目负责人，也有他的责任。

首先，代码审核没有做到位。这种明显的硬编码问题，应该在第一时间就发现，而不是等到项目上线后才提出来。

其次，在李四解释了原因之后，张三不应该过多指责，而是应该给出建设性的建议，帮助李四改进工作方式，避免下次再出现类似的问题。

李四的问题

李四的临时方案本身并没有太大问题，毕竟在紧急情况下，有时候确实需要一些特殊手段。

但是呢，他的处理方式有问题。在使用临时方案之后，他应该有更好的选择：

方案一：主动告知

在群里或者邮件中告知团队成员，说明自己使用了临时方案，并且承诺在时间节点过后会进行完善。这样既能保证项目进度，又能让团队成员了解情况。

方案二：默默完善

如果不想让太多人知道，至少在时间节点过后，自己要记得把这些临时方案替换成正式的解决方案。

但是很遗憾，李四两个选择都没有做。所以才导致了后来的争执。

总结

说实话，这个案例虽然看起来很简单，但背后反映的是项目管理中的一个普遍问题。

在项目开发中，我们经常会遇到各种紧急情况，这时候就需要我们有灵活的应变能力。

但是，灵活不等于随意，我们需要在保证项目进度的同时，也要保证项目质量。

最重要的是，遇到问题不要互相指责，而是要互相理解，共同寻找解决方案。

只有这样，才能让团队变得更强大，项目变得更成功。

记住，临时方案可以用，但一定要使用正确的方法，想出一个好点子，并不等于就解决了问题，要在执行层面也做到位，那才是真正的解决了问题，而不是出现新的问题。