@CarryOnHxy #6 把人安全送上月球，然后安全地送回来

@syubo2810 赞成，这种就得看产品经理 和 客户的实力了。。产品有时候真的。。哎

我评估的标准是： 能说一个完成时间出来，并在那个时间节点完成，就是简单的 完成时间不确定，就复杂的

让我想起我们老板,把 ai 集成到系统里,1 星期就够了吧,下下周我给客户演示

-> 我们要盖一栋三层小别墅 -> 我们需要再加盖两层 -> 加个电梯 -> 把别墅复制粘贴一套到隔壁 -> 现在我们需要把这两栋别墅改成双子塔

1. 一句话需求 2. 替业务背锅的需求，这种需求一定要把能实现的效果的边界广而告之

涉及的模块越少，需要的沟通对接的资源越少的需求就越简单。 涉及的模块甚至业务线越多，需要沟通的对接越多，甚至需求稍微变动一下就得开个会来整理变动范围的就越复杂。

在补丁糊的比本体还厚的系统上做需求复杂 在新系统上做需求简单

一种是需求说不清的，这里的复杂是指开发后反复修改的复杂，主要是心累。一种是系统经过相当多需求的迭代后，各种前后业务关系导致新来的需求牵一发而动全身，这时候的复杂就需要开发者通过模块或者架构的设计来降低业务复杂带来的影响。这里就会存在悖论，业务还没起来的时候无法预知后续的发展，怎么设计架构，那就需要开发者有一定的经验，或者在业务成熟的时候干脆来一场轰轰烈烈的重构

我来定，我看得透的就简单，看不透的就复杂