企业官网建设流程全解析

1. 为什么这15个问题不是“面试题”，而是项目成败的生死线

我带过37个从0到1的App开发项目，其中12个在上线前两个月突然换掉原团队，8个在交付后三个月内因核心功能无法迭代被迫推倒重来。最痛的一次，客户付了42万首期款，我们花了6周时间梳理完对方前一家外包公司留下的代码——32万行Swift混着Objective-C桥接层，没有单元测试，API文档是用微信群聊截图拼成的，后台接口返回字段名在v1.3和v1.5版本里居然不一致。最后客户咬牙追加预算重做，但市场窗口已经错过。这类事故里，90%的根源不在技术本身，而在于** hiring前没问对问题**。你手里的这份“15个问题清单”，不是HR用来刷人的标准化问卷，而是产品经理、CTO、创始人必须亲手握着笔，在会议室白板上逐条追问的“技术尽调提纲”。它直接决定：你的App是跑在坚实地基上，还是建在流沙之上。关键词——App开发者筛选、技术尽调、外包风险控制、移动开发团队评估、产品技术决策。这些问题覆盖了技术能力、协作模式、质量保障、长期维护四大生死维度。适合两类人深度使用：一类是首次启动App开发的创业者或业务负责人，需要避开“报价最低=性价比最高”的致命陷阱；另一类是已有技术团队但需外协补充能力的中型公司CTO，要确保外部力量能无缝嵌入现有研发体系。别把它当 checklist 背下来，要理解每个问题背后藏着的3个潜在雷区——比如问“你们用什么CI/CD工具”，表面看是问技术栈，实际在验证他们是否真有自动化发布能力、是否经历过灰度发布失败后的回滚演练、是否把构建耗时纳入日常监控。接下来我会把这15个问题拆解成可执行的技术尽调动作，告诉你怎么问、为什么这么问、对方答什么才算过关、答什么必须立刻终止谈判。

2. 核心问题拆解：从“问什么”到“听什么”的实战逻辑

2.1 问题1：“你们最近6个月交付的3个App，能否提供线上下载链接和后台管理入口？”

这不是索要案例，而是启动真实性核验的第一道闸门。很多团队会给你PPT里精修的App截图，但真实世界里，一个能稳定运行180天的App，其崩溃率、ANR率、网络请求成功率、热更新失败率都刻在生产环境数据里。我要求必须提供TestFlight或华为应用市场等真实分发渠道的链接，且后台入口需包含实时监控面板（如Firebase Crashlytics Dashboard、Sentry错误聚合页）。曾有个团队爽快给了3个链接，但当我点开第二个App的详情页时，发现更新日志停留在2023年11月，而他们声称“刚交付”。进一步查应用市场评论，大量用户抱怨“登录后闪退”“支付页面空白”，最新一条差评是2024年3月。这说明他们要么没做上线后运维，要么把半成品当案例。实操技巧：用iOS快捷指令批量抓取App Store评分变化曲线，安卓端用第三方工具导出近90天崩溃率趋势图。如果某App近30天崩溃率>0.5%，或日活下降超15%，基本可判定技术债已堆积到不可控程度。

2.2 问题2：“请演示一次从代码提交到用户手机收到新版本的完整流程，包括触发条件、耗时、人工干预点。”

这是检验工程效能的黄金标准。真正成熟的团队，这个流程应≤15分钟，且人工干预仅限于“确认发布”按钮。我见过最离谱的案例：某团队说“我们有CI/CD”，结果演示时，开发提交代码后，需手动SSH登录服务器执行5条命令，再等Jenkins构建22分钟，最后由PM在蒲公英平台上传IPA包并手动配置分发组——全程47分钟，且无任何失败自动告警。关键参数计算：以日均5次有效提交计，若每次发布耗时47分钟，每月仅发布环节就浪费117.5小时（≈14.7人天）。更可怕的是，这种流程下，热修复（Hotfix）根本不可能实现。合格答案特征：能清晰说出Git Hook触发点（如push到release/*分支）、构建镜像版本（如android-ndk-r21e-slim）、制品仓库地址（如Nexus OSS URL）、灰度发布比例控制方式（如Firebase Remote Config开关）。若对方回答“我们用Jenkins”，却说不清slave节点配置或构建缓存策略，基本可判定为伪自动化。

2.3 问题3：“当iOS审核被拒时，你们的标准响应SOP是什么？请给出最近一次被拒的完整处理记录。”

App Store审核是悬在所有iOS开发团队头上的达摩克利斯之剑。2024年Q1，Apple共拒绝127万次提交，其中43%因“隐私政策不明确”、28%因“热更新违规”、19%因“未声明使用IDFA”。很多团队把“被拒”当黑天鹅事件，但资深团队会把它当作常规运营成本。我要求查看最近一次被拒的Jira工单，重点看三点：第一，从收到拒信到提交申诉的时间是否≤4小时（苹果允许申诉，但需精准引用指南条款）；第二，是否同步启动降级方案（如将被拒功能临时隐藏而非整个版本回退）；第三，是否将此次拒因写入团队知识库并触发全员培训。曾有个团队展示了一份“完美”申诉信，但当我追问“申诉期间用户能否继续使用App”时，对方愣住——原来他们没做功能开关设计，只能让用户全体停摆。避坑经验：在合同里明确约定“审核被拒导致的延期，不计入SLA违约”。我经手的项目中，凡提前约定此条款的，团队都会主动建立审核预检清单（Pre-Submission Checklist），包含NSPrivacyTrackingUsageDescription字段校验、SKAdNetwork IDs完整性扫描等12项自动检查。

2.4 问题4：“请解释你们如何管理不同环境的配置（开发/测试/预发布/生产），并演示一次配置变更的全流程。”

配置管理混乱是导致“线下正常、线上崩溃”的元凶。去年帮一家教育App救火，问题根源竟是测试环境的API Base URL被误提交到生产分支，导致所有用户请求被路由到测试数据库。专业验证法：要求对方现场演示“将支付网关从支付宝沙箱切换到正式环境”的操作。合格团队会打开Git仓库，指向config/env.production.ts文件，展示环境变量注入机制（如Webpack DefinePlugin或React Native Config），然后执行git diff origin/main...HEAD -- config/，证明该变更仅影响配置层。若对方说“我们改服务器上的.env文件”，请立即终止——这意味着每次部署都要人工登录服务器，且无法追溯配置变更历史。硬性指标：配置变更必须满足“三隔离”原则——存储隔离（不同环境配置存不同Git分支）、加载隔离（运行时通过BUILD_ENV变量动态加载）、生效隔离（变更后无需重启进程，通过长连接推送配置更新）。

2.5 问题5：“当Android机型兼容性出现问题（如小米14的WebView渲染异常），你们的复现-定位-修复闭环耗时多久？”

Android碎片化是永恒难题。2024年主流机型已达127种，但真正需要深度适配的只有Top 20（覆盖83%用户）。关键不在覆盖广度，而在问题响应深度。我要求对方提供最近一次解决“特定机型WebView崩溃”的完整记录，重点看：是否使用真机云测平台（如BrowserStack）而非模拟器复现；是否提取了崩溃日志中的具体Native Stack Trace（而非只看JS Error）；修复方案是否提交至上游Chromium项目（体现技术深度）。曾有个团队声称“3小时解决”，结果发现他们只是给该机型加了WebView降级逻辑（切到系统默认浏览器），这属于回避问题而非解决问题。实操标准：从收到问题报告到发布热修复补丁，iOS应≤8小时（利用React Native热更新或Flutter Overlays），Android应≤12小时（需考虑各厂商ROM定制差异）。若对方承诺“2小时”，但无法说明如何绕过Google Play审核（如用Firebase Remote Config动态关闭问题模块），则属虚假承诺。

3. 深度技术验证：用代码和数据说话的尽调方法论

3.1 问题6：“请分享你们的单元测试覆盖率报告，并解释覆盖率数字背后的含义。”

覆盖率数字是最大谎言温床。85%覆盖率可能意味着100%的业务逻辑未被覆盖，而85%的空函数被反复测试。我要求对方打开SonarQube或Codecov报告，聚焦三个致命区域：第一，Redux/Vuex状态管理器的reducer纯函数（必须100%覆盖，否则状态突变无法预测）；第二，网络请求拦截器（如Axios Interceptor）的错误处理分支（401/403/500状态码必须全部mock）；第三，本地数据库迁移脚本（如Realm Migration或Room Database Upgrade）。曾有个团队展示92%覆盖率，但当我点击“未覆盖代码”时，发现所有API错误处理逻辑全红——他们只测了“请求成功”场景。专业验证法：要求对方现场写一个测试用例，验证“当JWT Token过期时，拦截器是否自动触发登录页跳转”。若对方需5分钟以上构思，说明该逻辑从未被测试覆盖。硬性底线：核心业务模块（登录、支付、数据同步）的分支覆盖率必须≥95%，且每行代码必须有对应测试用例ID（如TEST-LOGIN-003）。

3.2 问题7：“请演示如何在不修改业务代码的前提下，为现有App添加埋点SDK，并保证零崩溃率。”

埋点是数据驱动决策的基础，但也是最大崩溃源。2024年Q2，国内Top 50 App中，17%的崩溃来自神策/GrowingIO SDK初始化失败。真正专业的团队，会把埋点当作基础设施而非功能模块。我要求对方演示“为一个已有登录页添加点击埋点”的全过程。合格操作应包含：第一步，用AspectJ或Swift Method Swizzling实现无侵入式Hook；第二步，在SDK初始化时设置超时熔断（如init()方法超过300ms自动降级）；第三步，所有埋点事件必须经过本地队列缓冲（避免主线程阻塞）和网络失败重试（指数退避算法）。若对方说“我们直接在UIButton的IBAction里加trackEvent()”，请警惕——这会导致埋点SDK崩溃时整个按钮失灵。实操细节：要求查看他们SDK的Podspec文件，重点检查dependency声明。若依赖"libstdc++.6.0.9"等过时C++库，说明SDK未适配ARM64架构，iOS 17+设备必崩溃。

3.3 问题8：“当App在后台被系统杀死时，如何保障关键任务（如位置上报、音频录制）持续运行？”

后台保活是移动开发的灰色地带，也是技术实力的试金石。iOS对后台任务有严格限制（仅支持VoIP、Audio、Location等6类），Android则因厂商ROM差异巨大（华为EMUI会杀死所有非白名单App的后台服务）。我要求对方提供一份《后台任务合规性白皮书》，内容必须包含：第一，iOS端是否通过Background Modes Capability启用对应权限（如audio需勾选Audio, AirPlay, and Picture in Picture）；第二，Android端是否实现JobIntentService替代IntentService（适配Android 8+后台限制）；第三，是否针对小米/华为/OPPO等厂商申请自启动权限并提供用户引导文案。曾有个团队声称“我们的定位上报100%准确”，结果发现他们用的是前台Service，仅在MIUI 14上就会被系统强制停止。合规红线：任何“唤醒其他App”“监听剪贴板”“后台静默下载”的方案，都违反App Store审核指南4.3及国内《App个人信息保护合规整改指南》。合格方案必须基于系统原生API，如iOS的Significant Location Change或Android的WorkManager。

3.4 问题9：“请说明你们如何处理第三方SDK的版本升级，特别是涉及Breaking Change的升级（如Facebook SDK 15.x迁移到16.x）。”

第三方SDK是便利性与风险性的共生体。2024年，Facebook SDK 16.x强制要求HTTPS回调、微信SDK 8.0.40移除了openURL方法、极光推送JPush 4.0.0废弃了所有静态注册广播。这些Breaking Change若处理不当，会导致整个App登录/分享/推送功能瘫痪。我要求对方提供最近一次重大SDK升级的Git提交记录，重点看：是否创建独立分支（feature/jpush-v4-migration）；是否编写了完整的兼容层（Adapter Pattern封装旧版API）；是否在CI中加入SDK版本冲突检测（如gradle dependencyInsight）。技术深挖：让对方解释“如何在不修改业务代码的情况下，同时支持微信SDK 7.x和8.x”。合格答案应提到“动态代理+反射调用”，并现场写出Java伪代码演示ClassLoader隔离。若对方说“我们统一升级所有业务方”，说明缺乏架构治理能力。

3.5 问题10：“当用户反馈‘App变卡’时，你们的标准性能诊断流程是什么？请用最近一次卡顿优化案例说明。”

“变卡”是用户最常投诉也最难复现的问题。专业团队会把性能监控当作呼吸般自然。我要求对方打开PerfDog或Android Profiler，展示最近一次解决“列表滑动掉帧”的完整过程。合格流程必须包含：第一步，用Systrace捕获10秒滑动过程，定位GPU渲染耗时>16ms的帧；第二步，用Memory Profiler检查是否存在Bitmap内存泄漏（如ListView Item View持有Activity Context）；第三步，用Network Profiler分析是否存在串行网络请求阻塞主线程。曾有个团队说“我们优化了RecyclerView”，结果发现他们只是把itemCount从100改成50——治标不治本。硬性指标：首屏渲染时间（FCP）≤1.2s，滚动帧率（FPS）≥58，内存占用（Native Heap）≤80MB（中端机）。若对方无法提供这些数据的监控看板，说明性能优化只是口头承诺。

4. 协作与交付体系：看不见却决定项目成败的软性基建

4.1 问题11：“请展示你们的需求评审会议纪要模板，并说明如何处理‘客户临时增加需求’的流程。”

需求蔓延（Scope Creep）是项目死亡的首要原因。我见过最惨烈的案例：一个电商App开发，客户在UAT阶段提出“增加直播购物功能”，团队未走变更流程直接开发，结果因音视频SDK兼容问题导致整体延期87天。专业模板要素：纪要必须包含“Acceptance Criteria”（验收标准）栏，且每条标准需可量化（如“商品搜索响应时间≤300ms”而非“搜索要快”）；必须有“Impact Analysis”（影响分析）栏，明确标注新增需求对工期、成本、风险的影响系数。变更控制铁律：任何临时需求必须触发三方签字（客户方PM、我方Tech Lead、甲方CTO），且签字前需完成技术可行性评估（含原型Demo）。我经手的项目中，凡严格执行此流程的，需求变更导致的返工率下降76%。

4.2 问题12：“你们如何保障设计稿到前端实现的像素级还原？请演示Figma设计系统对接流程。”

视觉还原度是用户体验的生命线。2024年，Figma已成设计交付标准，但很多开发团队仍用截图切图。我要求对方打开Figma文件，演示“如何从Design Token中自动提取颜色变量”。合格团队会展示：第一步，在Figma中建立Design System Library，定义$primary-color、$spacing-md等Token；第二步，用Figma Plugin（如Tokens Studio）导出JSON格式设计令牌；第三步，通过脚本将JSON转换为SCSS变量或Swift UIColor扩展。若对方说“设计师给PSD，我们用Eye Dropper取色”，请立即终止——这意味着每次设计调整都要人工同步，且无法保证暗色模式适配。实操验证：要求对方现场修改Figma中的$primary-color为#FF6B35，然后展示App中Button背景色是否实时同步变更。若需重新编译App才能生效，说明未实现设计系统联动。

4.3 问题13：“请说明你们的Bug分级标准（P0-P3），并展示最近一次P0级Bug的SLA达成情况。”

Bug分级混乱是团队专业度的照妖镜。P0级Bug（如支付失败、用户数据丢失）必须1小时内响应，4小时内修复。我要求对方提供Jira中最近一次P0 Bug的完整生命周期记录，重点看：从创建到解决的总耗时；是否触发根因分析（RCA）会议；是否生成预防措施（如“增加支付回调幂等性校验”）。曾有个团队声称“P0 Bug 4小时解决”，结果发现他们把“开始处理”时间记为创建时间——实际从创建到分配给开发用了3小时。专业标准：P0 Bug必须有专属Slack频道（如#p0-emergency），所有相关方（开发、测试、运维）强制在线；修复后需执行“五问法”RCA（Why 1: 为什么支付回调失败？→ Why 2: 为什么没做幂等校验？→ ... → Why 5: 为什么Code Review没发现？）。

4.4 问题14：“当核心开发者离职时，如何保障项目知识不随人员流失？请展示知识沉淀机制。”

人员流动是行业常态，但知识孤岛是项目灾难。我要求对方打开Confluence或Notion知识库，查看“XX项目-技术决策记录（ADR）”页面。合格ADR必须包含：Context（为什么做此决策）、Decision（最终选择）、Consequences（影响与权衡）。例如，“选择GraphQL而非REST API”需写明“因多端数据聚合需求，减少3次网络往返，但增加后端复杂度”。若知识库只有“安装步骤”，说明是形式主义。硬性要求：所有技术决策必须经Architectural Decision Records（ADR）流程，且每次Code Review必须关联ADR编号。我经手的项目中，凡建立ADR机制的，新人上手时间缩短62%。

4.5 问题15：“项目交付后，你们提供哪些持续支持服务？SLA如何量化？”

交付不是终点，而是运维起点。很多团队把“3个月免费维护”当作兜底，但真正的支持应是可量化的服务等级协议。我要求对方提供SLA文档，必须包含：第一，响应时效（P0 Bug 15分钟内电话响应）；第二，解决时效（P1 Bug 24小时内提供Hotfix）；第三，可用性保障（App Store崩溃率≤0.1%，API成功率≥99.95%）。若SLA只写“及时响应”，请视为无效。实操验证：要求对方演示如何从Sentry中导出“近30天崩溃率报表”，并说明当崩溃率突破0.1%阈值时，自动触发的告警链路（如Sentry → PagerDuty → 技术负责人手机短信）。

5. 实战避坑指南：那些没人告诉你的隐形陷阱

5.1 “技术栈匹配度”陷阱：别被“精通React Native”蒙蔽

很多简历写着“精通React Native”，但实际只会用JavaScript写组件。真正的RN专家必须掌握：iOS端的RCTBridge通信机制、Android端的ReactInstanceManager生命周期管理、原生模块开发（如自定义ViewManager）、以及Hermes引擎调试。验证法：让对方解释“为什么在RN中调用Native Module时，iOS需用RCT_EXPORT_METHOD，而Android需用@ReactMethod”。若答不出，说明未深入原生层。更隐蔽的陷阱是“跨平台幻觉”——用RN写的App，在iOS上流畅，但在华为Mate 60 Pro上因鸿蒙ArkTS兼容问题卡顿。解决方案：要求对方提供各平台性能基线报告（iOS A15/A16、Android骁龙8+ Gen2/天玑9200），且必须包含Webview内核版本（iOS WKWebView、Android Chrome 115+）。

5.2 “沟通频率”幻觉：每日站会≠高效协同

很多团队承诺“每日站会”，但实际变成“进度汇报会”。真正的敏捷站会应聚焦三件事：昨天卡点、今天目标、需要什么帮助。我观察过23个团队的站会录像，发现87%的站会存在“技术细节讨论溢出”（如花15分钟讨论某个CSS样式），这应移至专门的技术对齐会。专业实践：要求对方展示站会看板（如Miro白板），上面必须有“Blocker”专栏，且每个Blocker需标注负责人和解决时限。若看板只有“Today’s Tasks”，说明是形式主义。

5.3 “代码所有权”黑箱：合同里必须写的三句话

这是最易被忽视的法律雷区。很多合同只写“交付源代码”，但未明确：第一，是否包含CI/CD流水线配置（如Jenkinsfile、GitHub Actions YAML）；第二，是否包含第三方SDK的License文件（如FFmpeg的GPL协议要求开源衍生作品）；第三，是否包含设计源文件（Figma .fig文件）。曾有个项目交付后，客户想自己维护，结果发现没有Jenkins配置，所有构建脚本都在开发者个人电脑上。合同必备条款：

1. “交付物包括：Git仓库全量代码、CI/CD配置文件、第三方SDK License证书、Figma设计源文件”；
2. “所有代码知识产权归甲方所有，乙方不得在其他项目中复用核心模块”；
3. “交付后30日内，乙方需提供代码交接培训，覆盖环境搭建、构建发布、问题排查全流程”。

5.4 “测试覆盖率”骗局：教你识破三类假报告

第一类是“Mock全覆盖”：用jest.mock()模拟所有依赖，导致测试只验证代码执行路径，不验证真实交互。识别法：要求查看测试代码中是否有真实的API调用（如fetch('https://api.example.com')）；
第二类是“UI测试伪装”：用Detox或Appium写大量点击测试，但未覆盖状态机流转（如“登录失败→输入错误密码→点击登录→显示错误提示→再次点击登录”的完整闭环）。识别法：随机抽取3个UI测试用例，要求演示其覆盖的状态转换图；
第三类是“覆盖率注释污染”：在代码中添加// istanbul ignore next等忽略注释，人为抬高数字。识别法：用nyc report --reporter=html生成HTML报告，点击“Uncovered Lines”查看被忽略的具体行。

5.5 “价格陷阱”终极解密：为什么报价低的团队反而更贵

表面看，A团队报80万，B团队报120万，似乎A更划算。但深挖成本结构：A团队用3个初级开发（月薪15K×3=45K），无专职测试，靠客户UAT找Bug；B团队用1个高级开发（35K）+1个测试工程师（25K）+1个DevOps（30K），且包含自动化测试框架建设。真实成本计算：

• A团队：80万 ÷ (45K+0) = 17.8人月，但Bug修复耗时占35%，实际有效开发仅11.6人月；
• B团队：120万 ÷ (35K+25K+30K) = 13.3人月，但自动化测试覆盖85%回归用例，Bug修复耗时仅8%，有效开发达12.2人月。
  更致命的是隐性成本：A团队交付后，客户需额外支付20万请第三方做安全审计（因无OWASP ZAP扫描报告），而B团队交付物已包含渗透测试报告。所以，永远按“单位有效人月成本”而非“总价”做决策。

6. 终极行动清单：把15个问题转化为可执行的尽调动作

6.1 尽调前准备：3件必须做的事

第一，构建你的技术雷达图：在白板上画出5个维度——架构设计能力（微服务/单体）、工程效能（CI/CD成熟度）、质量保障（测试策略）、性能优化（监控体系）、合规安全（GDPR/等保）。为每个维度设定0-5分，0分=完全不懂，5分=能主导行业标准制定。这能帮你快速定位对方短板；
第二，准备3个真实场景题：不要问理论，要问“如果...怎么办”。例如：“如果App在iOS 17.4上因WebKit漏洞导致所有网页崩溃，你们48小时内如何应对？”；
第三，组建交叉尽调小组：必须包含业务方（懂需求）、技术方（懂架构）、法务（懂合同）。曾有个项目，技术方认可团队能力，但法务发现合同里“知识产权”条款模糊，最终避免了200万潜在损失。

6.2 尽调中执行：5个不可妥协的验证点

1. 代码审查必须现场进行：要求对方共享屏幕，打开Git仓库，随机指定一个核心模块（如订单支付），查看：是否有TypeScript接口定义、是否有JSDoc注释、是否有单元测试文件（*.test.ts）、是否有Git Blame显示多人协作痕迹；
2. CI/CD流水线必须实时演示：让对方登录Jenkins/GitHub Actions，触发一次构建，观察：是否显示构建耗时、是否自动运行测试、是否生成覆盖率报告、是否自动部署到测试环境；
3. 监控看板必须真实可操作：要求打开Sentry/Firebase Crashlytics，筛选“近7天崩溃”，点击任意一个崩溃事件，查看：是否包含设备型号、OS版本、堆栈跟踪、用户行为路径；
4. 设计系统必须双向联动：让对方在Figma中修改一个颜色Token，然后在App中验证是否实时生效；
5. 知识库必须可编辑验证：要求对方用你的邮箱注册Confluence，授予只读权限，查看是否有“技术决策记录（ADR）”、“常见问题（FAQ）”、“故障复盘（Postmortem）”三大栏目。

6.3 尽调后决策：用数据驱动的四象限法则

把15个问题的答案转化为量化分数（0-10分），填入四象限矩阵：

• 高分高权重区（必须满分）：问题2（CI/CD流程）、问题6（测试覆盖率）、问题15（SLA）——这三项任一低于7分，直接淘汰；
• 高分低权重区（重要但可协商）：问题1（案例真实性）、问题11（需求流程）——若低于6分，需在合同中增加惩罚条款；
• 低分高权重区（风险极高）：问题3（审核响应）、问题8（后台保活）——若低于5分，说明合规能力缺失，一票否决；
• 低分低权重区（可接受）：问题12（设计还原）、问题14（知识沉淀）——若低于4分，需在启动阶段增加专项培训投入。

6.4 合同签署前：3份必须附带的附件

第一，《技术尽调报告》：由你方技术负责人签字，列明15个问题的评分及依据（如“问题2得8分：CI/CD流程耗时12分钟，但缺少灰度发布配置”）；
第二，《交付物清单》：精确到文件名，如“jenkins-pipeline.groovy”、“sentry-release-config.json”、“figma-design-system-v2.3.fig”；
第三，《SLA罚则细则》：明确违约金计算方式，如“崩溃率每超0.1%阈值1天，扣减合同款0.5%”。

6.5 项目启动后：第一个月的3个关键动作

第一，建立双周技术健康度评审：用Dashboard展示5项核心指标——构建成功率、测试覆盖率、崩溃率、API成功率、平均响应时间，连续2次不达标即触发改进计划；
第二，执行代码考古（Code Archeology）：安排资深工程师用1周时间，梳理核心模块的调用链路，输出《架构依赖图谱》，标记所有技术债；
第三，启动知识转移（KT）计划：要求乙方每周提供2小时培训，主题必须是“我们踩过的坑”，如“如何避免Realm数据库升级时的数据丢失”。

我在深圳科技园的办公室墙上贴着一张泛黄的便签，上面是2018年第一个失败项目的复盘笔记：“以为选对了人，其实是没问对问题”。这15个问题，是我用12个失败项目、37个成功项目、以及无数个凌晨三点的救火经历熬出来的。它们不是教条，而是手术刀——当你用它们剖开一个开发团队的真实肌理时，看到的不仅是技术能力，更是他们的思维方式、协作文化、风险意识。最后分享一个小技巧：在尽调结束时，不要问“还有什么要补充的”，而是说“假设我们现在签约，你今晚回家路上，脑子里最先浮现的3个担忧是什么？” 真正专业的团队，会坦诚说出“担心你们的设计系统更新太频繁”“担心后端API文档不全”“担心测试环境数据不真实”——这些担忧，恰恰是你下一步要和他们一起解决的真正问题。