TIMELINE一路走来的几个节点
年份只是坐标，真正变化的是我们判断一件事值不值得做的方式。
-
2022起点
先把复杂的技术讲清楚
三个人凑在一起，接的第一批项目都不大。我们给自己定了一条不太聪明的规矩：方案里出现的每个技术名词，都要能用一句普通话解释给业务方听懂。这条规矩一直留到现在。
-
2023第一套方案
制造企业的数据协同项目上线
第一个完整交付的项目来自制造业。我们把生产、库存与订单三条数据线打通，交付周期比原计划短了三周。缩短的原因不复杂：前期把口径对齐花了更多时间。
-
2024扩展
服务范围延伸到零售、物流与教育
不同行业的业务语言差别很大，但梳理问题的方法可以复用。这一年我们把项目里反复出现的场景整理成实施手册，新项目的准备时间明显下降。
-
2025沉淀
建立内容与经验的记录机制
每个项目结项后要写一份复盘，包括做对的、做错的、下次怎么改。这些材料最后变成了站内的方案文档与洞察文章，也让新同事更快上手。
-
2026当下
把交付质量放在规模之前
我们仍然控制同时进行的项目数量，宁可排期往后，也不压缩前期沟通与测试的时间。这条限制短期看是慢的，长期看省下了大量返工。
PRINCIPLES我们怎么做判断
下面三条不是墙上的标语，是项目里反复被拿出来用的尺子。
先把问题问清楚
我们不做没弄清需求的方案。每个项目开头，团队会和业务方一起把现状、限制条件和真正想达成的目标写成一段谁都能看懂的话，再谈技术选型。这段文字后面会贴在项目文档首页，中途有分歧时回到它来判断。
写清楚这件事本身花不了多少时间，但能挡掉很多返工。
需求梳理 · 口径对齐让技术退到合理的位置
技术是手段，不是目的。选型时我们优先考虑三件事：客户团队能不能长期维护、三年内的总成本是否可控、出问题时能不能快速定位。纸面参数好看的方案，如果没人接手，最后都是负担。
有时候我们会主动建议客户砍掉一部分需求，先做能稳定运行的那一块，再按节奏往上加。
选型 · 可维护性交付之后仍然在场
上线不是终点。每个项目都留有明确的响应窗口和复盘节点，问题和处理过程要记录下来，写进实施手册，下次不再重复。这套机制听起来朴素，但确实是让我们少走弯路的做法。
如果项目结束后一切归零，那说明交付方式还有改进空间。
交付 · 复盘机制我们不追求把每件事都做得很大，只想把答应下来的事做完、做稳。
SCENES工作方式的几个片段
复盘会、现场勘察、方案评审与文档整理，这些场景构成了星空(中国)官方网站的日常。
