每天站会不是走过场
项目刚启动那会儿，团队里有人做前端，有人搞后端，还有人在对接第三方接口。刚开始大家各干各的，结果两周后一碰头，发现前端等接口字段，后端说还没定好结构，两边都卡着。后来我们定了个规矩：每天早上10点，站着开15分钟会。谁今天做什么、昨天卡在哪，一句话讲清楚。不拖沓，也不开会中会。架构师就站在白板前听，顺手把阻塞问题记下来，当天跟进解决。
用接口文档当“共同语言”
光靠嘴说容易扯皮，我们干脆把接口文档当成开发进度的锚点。比如用户登录这个功能，架构师先在 Swagger 里把 /api/login 的请求参数和返回结构写死，标注哪些字段必填、类型是什么。前后端同时开工，前端按文档做模拟数据，后端照着实现逻辑。谁先改了接口，必须第一时间更新文档并通知对方。这样一来，两边哪怕不同步编码，也能保持节奏一致。
关键节点埋“检查点”
一个大功能拆成小任务之后，架构师会在关键路径上设几个硬性检查点。比如支付模块，我们会定：周三下午5点前必须完成订单状态机设计评审，周五下班前跑通沙箱环境调用链路。这些节点不设模糊描述，要么“通过”，要么“阻塞”。一旦某个点没按时过，立刻拉人排查，是资源不足还是技术方案有问题，当场拍板调整。
有次数据库迁移卡住了，原计划两天搞定，结果第三天还在处理历史数据清洗。架构师直接介入，看日志发现是索引没建对，当场让DBA上线优化，同时把后续测试安排往后顺延一天，并同步给产品经理。进度没崩，沟通成本也降了。
可视化进度比口头汇报管用
我们不用Excel传进度表，而是把所有任务挂在Jira上看板上。架构师每周五花半小时梳理一次状态流转：待办、开发中、联调、已验证。每个卡片背后关联代码提交记录和CI构建结果。谁的任务卡在“联调”超过三天，系统自动标红，架构师就会找人聊。有时候不是技术难，就是开发者不好意思说依赖方没给反馈，这时候推一把就行。
<project name="user-service" status="in-progress">
<task id="001" owner="chen" deadline="2024-06-10" status="done">API design</task>
<task id="002" owner="liu" deadline="2024-06-12" status="blocked">Token validation</task>
</project>这种轻量级的项目描述文件，我们放在Git仓库根目录，每次晨会前更新一次。谁都能看，也避免了信息层层传递失真。
技术债不能堆到上线前
有段时间大家只顾赶功能，日志格式乱七八糟，错误码也不统一。架构师就在每次迭代留出10%时间处理这类问题。比如规定这轮必须把所有4xx响应体结构标准化，谁负责哪块就顺手改掉。小步快走，不积压。这样后期联调时少扯皮，查问题也快。进度看着慢了一点，实际上省下了大量调试时间。