程序开发过程中如何避免“水多加面，面多加水”的问题

[MRG0]

年前年后一直在做一个首页改版功能。开发前产品给的文档很简单，只有几幅示意图和简短的说明。

可是做着做着想要的功能点就越来越多，这感觉不好就改一下，那感觉不合理就改一下。

我是也是前端菜鸡，开发节奏完全跟着产品走，这个改版需求从 12 月底到 2 月中旬还是有些问题，今天险些改了整体的数据结构

[jingcheng1108]

定版本，一个版本一个版本迭代

[murmur]

没法避免，到最后都是要么加资源，要么重构

[snimstice]

程序员没办法避免，毕竟只是干活儿的，踏实干活儿赚工资就行了

[emSaVya]

需求变更很正常 但是产品需求要落地 邮件+产品文档。每次变更 开发要给出对应工作量+排期。

[standchan]

没法避免，尽量不要太完美主义吧

[MRG0]

@emSaVya #4 这得是大公司标准化流程，我这虽然“大”，但是纯纯草台班子，大部分变更靠口头交流

[1zh3n]

从你描述来看就是产品不专业，需求不明确。只要需求随意变动，就没办法解决你说的问题。

最好让产品出需求文档和原型图。不行的话至少把每次把要实现的需求留档，让产品确认后再改。

开发迭代按照产品目标做里程碑，一个里程碑算一个阶段目标。

[emSaVya]

@MRG0 为了你自己的利益 你也得工作留痕啊。不然年底领导一看 一个项目磨磨蹭蹭改了半天 中间过程都没了。那绩效要背大锅。

[MRG0]

@1zh3n @emSaVya
完犊子了，毛线档没有，就年前加了一些功能点详细描述

[coderluan]

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

[liu731]

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

[MRG0]

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

[killva4624]

如果 PM 管理不好功能的预期，就试着去做 PM 的预期管理：
- 这个需求需要做 X 天；
- 这个增加的需求如果加进来，需要增加 X 天；
- 现在开发工作已经饱和了，需要完成 A 后才能做 B ；

PM 其实权力很大，如果他把握不好节奏，就会把项目弄垮。
可以去看一些项目管理或者迭代管理的书，掌握基本的概念会对你回绝他的不合理需求很有帮助。

[jadehare]

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

[7gugu]

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

[weidaizi]

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

[BeautifulSoap]

这和程序员有什么关系？就国内这种牵条狗来都能当产品经理的环境，这就是纯粹产品经理或者负责需求设计的人的锅

对业务不熟悉，对业务各种约束条件和复杂的业务没一丁点认识，考虑不到任何复杂点的业务逻辑
原本这些工作都应该是产品的责任，结果到最后都是程序员在那写代码了，才发现一些代码上的判定条件根本没考虑到（表现出来是程序判定条件没考虑到，但本质上就是业务设计出了纰漏）

[leejinhong]

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

[MRG0]

@BeautifulSoap #17 🐎的，还真是，后边就是各种打补丁

[AdminZ]

我这个月都在重构，还好留了比较多时间，优化无底洞