如何避免项目越来越乱

之前呆过某家互联网公司，需求总是拍脑门（没有经过思考和设计）+明天就要，日积月累，后台越来越乱。（ ps.不是产品设计人员的错。领导明天就要，产品能设计一周吗？）
导致后台动不动就炸，改点什么，异常困难。

最后公司不说死在这上面，但发展也深受拖累就是了。

后来渐渐发现，项目无法摆脱这种糟糕的情况。

基本上的死循环是：

1 、第一个项目往往是新团队。领导也没底，不放心给超长时间把第一版做好。都希望尽快先出点成果，好交代，也好考察员工能力，万一做不出来也好调整。（明明第一版是最重要的基础）
于是第一版总是混乱赶工。这种混乱不单是技术混乱，而是从需求，到开发，到测试的整体赶工混乱。

2 、混乱的第一版完成之后，基础已经歪了。但这时候，其实可能是获得表扬的。超出预期达到了 xx 目标。
这时候，需要大重构而不是修 bug 式的小重构。这时，“第一版+大重构”的时间，远远大于“好好做第一版”的时间。
显然不可能。

3 、迭代开始了.....

4 、项目质量越来越差.....

这个死循环不知道怎么破。

对于领导来说，新员工新团队，怎么可能放心给半年以上的时间去做一个东西呢？万一做不出来怎么办？

很无奈。

MaxFang

2020-12-10 20:31:33 +08:00

这种问题目前也遇到一些，也很困扰，暂时感觉无解。
暂时的做法是在自己可控的范围内，将相对稳定的模块单独维护或做系统，那些日常改动或临时急需求的模块，就写上去放在那吧。
实在是没有做详细设计和技术方案的精力了，因为第一版的需求，可能上线使用一段时间后，就会做大改版。可能和业务有关，目前是做供应链相关的，具体的一些操作模式无法直接复制，都是快速试错加迭代。
等一些大的模块相对固定了，再抽象模型来重构。

laminux29

2020-12-10 23:08:44 +08:00

这个问题本质上是工程管理问题，你可以去翻翻几百年以来的城市规划、大楼建设、地铁新建、航母潜艇建造等书籍，都会有关于这个问题的描述。

结论很一致：无解。

大家的办法是：

1.没钱时，对现有的东西，忍受混乱，修修补补，甚至容忍因此造成的事故。

2.有钱后，报废或爆破旧东西，砸钱造新的东西。