做企业系统开发时，我现在不太建议一上来就开功能清单会。
很多项目刚开始会列出一长串模块：客户管理、订单管理、库存管理、审批流、报表、消息通知、权限后台。看起来需求很完整，但真进入开发后才发现，最难的不是少了哪个页面，而是流程、角色、状态和边界一开始没拆清。
功能列表只能说明“想要什么”，不能说明“业务到底怎么跑”。如果这个问题没先回答，功能越多，系统反而越容易做乱。
先拆核心流程，而不是先拆页面
我一般会先问一条最关键的业务链路：这件事从谁开始，到谁结束，中间经过哪些节点？
比如一个内部订单系统，不应该先讨论要不要订单列表、订单详情、导出按钮，而应该先确认：订单是谁创建的，谁审核，谁分配，谁执行，谁确认完成，异常由谁处理。
流程拆清以后，页面和按钮自然会长出来。反过来，如果只按页面拆，前期原型可能很好看，但后面经常出现一种情况：每个页面都有了，业务却接不起来。
把角色和权限单独拿出来看
企业系统最容易低估的，是角色和权限。
很多需求文档里会写一句“管理员可管理全部数据，普通用户只看自己的数据”，但真实项目里远没有这么简单。部门负责人能不能看下属数据？销售离职后客户归谁？审批人能不能修改申请内容？财务能看金额但不能改状态吗？
这些不是上线后再补的小细节，而是系统结构的一部分。权限如果一开始没设计清楚，后面每加一个角色，就可能牵动列表、详情、操作按钮、通知、日志和报表。
我一般会至少拆三类边界：谁能看数据，谁能改数据，谁对关键状态负责。只要这三件事含糊，系统后面就很难维护。
状态流转要比字段更早确认
很多系统需求会花大量时间整理字段：名称、类型、备注、附件、金额、时间。但真正让系统跑起来的，往往是状态。
一条记录从新建到完成，中间有哪些状态？哪些状态可以退回？哪些状态不能再改？谁能把它推进到下一步？异常状态要不要单独留痕？
这些问题如果不提前确认，后面就会出现很多临时判断：这个按钮先放着、这个状态先让管理员改、这个异常先手动处理。短期能绕过去，长期就会变成系统里最难清理的历史包袱。
对企业系统来说，状态不是展示文案，而是业务规则。状态流转拆得越清楚，代码、权限和操作日志都会更稳定。
一期先跑通核心链路，不要把系统一次做满
企业系统还有一个常见风险：第一期就想把所有模块都做完。
这通常不是技术上完全做不了，而是验证成本太高。流程还没跑过，权限还没被真实用户检验，报表口径也没稳定，就先把配置、统计、消息、导出、审批、移动端全部铺开，后面很容易一起返工。
我更倾向于先选一条最核心、最影响协作效率的链路，把它做到能录入、能流转、能追踪、能查状态、能留记录。只要这条链路跑稳，再补报表、配置项和次级模块，系统会稳很多。
一期不是越小越好，而是边界要清楚。核心链路必须完整，外围能力可以分阶段补。
结尾
企业系统开发前，真正该先梳理的不是“要多少个功能”，而是流程怎么走、角色怎么分、状态怎么变、一期先解决哪条核心链路。
功能清单当然要有，但它应该建立在这些判断之后。否则项目很容易变成页面很多、按钮很多，但业务一跑就到处补丁。
我把这个判断整理成了一篇更完整的文章： sphrag.com/zh/blog/ent…
