需求不靠谱，求各位大佬支招

辞职 解决一切

试想如果你时老板，你的手下遇到一点困难就想辞职而不是迎难而上，你是什么感觉。。

时 -> 是

@gw1992225 走不了啊

目前能想到的是切几个迭代，拉着业务方一边做一边验收，请问有什么技术或其他管理上的建议吗

这是天坑阿
在项目长期运营中，落地文档远比决策靠谱本身更重要。。
没有记录，谁也无法知道这个项目的经办人当时是怎么想的- -

我想到的是先按模块整理功能形成文档，整理完成后跟老板过一遍，通过后再实施

从业务回溯到业务代码，然后再切块，慢慢糊一些业务文档。

“从以前的代码梳理业务逻辑”，运气好能碰上代码可读性比较好的还能试试，不过都要“从以前的代码梳理业务逻辑”了，说明连文档都没有？那么代码的可读性也很难保证了。

自求多福吧，先整理一下现阶段能够收集到的任何资料，再把业务代码按模块划分，后面就看你运气了。

我做业务，我觉得你应该直接看现有代码，然后梳理出代码各模块的功能。
看以前的代码，那以前的业务到现在更迭了多少个版本都不知道，业务逻辑有没有删改增也不知道，
那不是浪费时间吗？
认同 2 楼，遇到点问题就说辞职的不要逗了，开这种玩笑也不合适

项目不大的话还不如直接推倒重写需求

一般都直接重写吧。。。

@hehongrong 关键业务都没人知道，重写也不合适了

小修小补可以解决问题的，修修补补又一年。。。不能的话，根据业务需求重新设计重新实现会比较好一些吧。

没任何需求 /设计 /测试文档吗?

@cscomic 很难想象，都没人知道业务了，公司还能运转吗

静下心来，对着业务去理解代码。比如页面上点击登陆按钮，触发了哪些代码和方法，再研究内部的实现都做了什么事情，一个个列出来形成文档。

如果长时间干这种活，会压力很大。
亲身经历。