程序员不要把自己当厨子，做一个无情的压面机就可以了，不加班。

无解，架构设计之初没有时间空间留给后面无限的需求

@liu731 #11 哪有架构，只有俺寻思

如果 PM 管理不好功能的预期，就试着去做 PM 的预期管理： - 这个需求需要做 X 天； - 这个增加的需求如果加进来，需要增加 X 天； - 现在开发工作已经饱和了，需要完成 A 后才能做 B ； PM 其实权力很大，如果他把握不好节奏，就会把项目弄垮。 可以去看一些项目管理或者迭代管理的书，掌握基本的概念会对你回绝他的不合理需求很有帮助。

开发文档肯定要有的，不是公司大小的问题，只要有开发需求，就得有需求文档。做开发要有自己的态度啊，对需求文档就是你不写我随缘做，我没做或者做的不对那不是我的问题，是你没写。

这种是产品问题，不是开发能解决的。因为根本问题是，产品没有提供一个稳定的需求文档，导致需求反复变更，开发跟着反复变更。一般这种情况下，应该是让 PM 去把握节奏，如果 PM 能接受发布时间延期，你也就只能跟着一块做变更了。

不就应该是这样的吗？无论是代码、产品还是战斗机，都是一代一代迭代升级出来的，一开始做个初始的东西，发现不完美的东西，慢慢更新往上堆，然后过了很久意识到需要进行大的改动的时候，重构就开始了，接着又是更新，修修剪剪，再次重复以前的步骤；只不过比较强的选手，可以更快的到达一个当下更接近满意且方便日后升级的阶段

这和程序员有什么关系？就国内这种牵条狗来都能当产品经理的环境，这就是纯粹产品经理或者负责需求设计的人的锅 对业务不熟悉，对业务各种约束条件和复杂的业务没一丁点认识，考虑不到任何复杂点的业务逻辑 原本这些工作都应该是产品的责任，结果到最后都是程序员在那写代码了，才发现一些代码上的判定条件根本没考虑到（表现出来是程序判定条件没考虑到，但本质上就是业务设计出了纰漏）

本质上就是产品的业务水平问题。真正厉害的产品对需求的理解应该是要比开发还要深刻的 https://i.imgur.com/NIvxivj.png 还有一个问题就是产品本身对开发是一点也不了解，以为代码就跟文字一样可以随便改动，或者是一开始没考虑到的需求，到后期不就是补一下而已。就会导致产品在设置需求的时候，想不通的一些链路就先跳过 https://i.imgur.com/agAJ0Rd.png 不要问我为什么！兄弟感同身受