很多需求不是在会议室里被提出来的。
工厂报工项目开始前，没有人说“我们需要一套系统”。一两百名工人每天照常在微信群里报工，两名文员照常逐条统计、核对、汇总。事情每天都能做完，所以它很容易被当成正常流程。
我看到的不是“缺一个报工页面”，而是同一批生产数据每天都要靠人重新整理，管理、生产和财务还不能直接看到同一套结果。
我先看三件事
这件事是不是一直在重复
偶尔多做一次不一定值得开发。每天重复、多人重复、还要反复核对，才说明问题已经进入日常成本。
整理完的数据有没有下一步用途
如果数据只为交一张表，系统价值可能有限。这个项目里的同一套数据口径后来继续延伸到日报、机台产能、每日异常和财务所需统计，所以前面的整理一旦稳定，后面的重复工作也能一起减少。
改法会不会让一线更麻烦
一套技术上漂亮、现场不愿意用的方案，最后还是没用。工人已经习惯微信报工，我没有先要求他们更换入口。当前版本由操作人员在 Codex 中触发，再完成消息抓取、拆分、清洗、复核和汇总。
沟通不是开会多，而是让每一方知道自己要确认什么
生产关心报工规则和异常怎么认，财务关心统计口径，开发需要明确输入、处理和输出。我的工作是分别问清，再把分工和待确认项落下来。
很多事情不是方案一提，别人就会配合。要先让对方知道为什么值得改、原来的工作会少掉什么、自己需要配合哪一步。阻力小了，项目才推得动。
FDE 的价值，往往发生在需求文档之前
我理解的 FDE，不只是拿到需求后快速开发。更重要的是进入现场，看到没人明确提出的问题，把业务目标、使用习惯和技术边界放到一起判断，再组织相关的人往前走。
查看百人级工厂报工案例；如果你也有一条长期靠人重复整理的流程，可以从一次具体问题梳理开始。