**—— 2026-03-08 **
项目背景： 公司拥有智能家居硬件，第三期希望自建团队进行App开发和维护
一、历史背景
第一期：涂鸦模组方案
- 购买涂鸦的WiFi模组
- 外包给涂鸦定制App
- 使用涂鸦公版产品，稍作定制后打包
第二期：外包定制方案
- 自己购买芯片制作模组
- 外包给其他公司开发App
- 实现了对App的控制权，但代码和技术栈仍在外包方
第三期：自建团队(当前阶段)
第一期涂鸦的处理不及时性。
第二期外包的处理质量问题。
所以，打算进行第三期：自建团队。在维护现有外包app的基础上，打算重做一个新的app。
二、战略思考
1、为什么自己做一个app？
一般自建App的情况如下：
品牌差异化 - 想建立自己的品牌认知和用户关系
数据控制 - 想拥有用户数据控制权
自定义体验 - 需要深度定制化的用户体验和功能
长期成本 - 长期来看可能比付平台费更划算
生态锁定 - 想建立自己的生态圈
1、目前公司对该app的产品和用户定位是怎么样的，是为购买了公司智能家居的用户，提供一个可控制的app。还是有其他更长远的考虑？
2、做一个自己的app是公司的战略定位，打算长期投入，还是只是一个尝试，即未来可能又不做了，换回用第三方？
2、为什么是成立自己的团队？
之前提到”外包服务不及时，且费用也高。所以打算自己组件开发团队，长期做”。
1、之前的外包投入大概是多少，人员规模如何？新团队预期的投入又是多少范围？
2、是否已衡量过”外包的短期“与”自建团队的长期“在投入上的短期回报和长远收益性，并坚持自建的值得？
3、团队的工作/存在模式是怎样的？是类似在厦门远程办公之类？
三、应用现状
1、app交接问题
1.1、问题
app经过两次不同形式的外包，分别为历史背景中的第一期和第二期。
1.2、剖析
第一期，外包涂鸦那边可交接的产物有哪些，如果只有一个编译后打包出来的app，那之前如何保证所交付的app中是安全的，不存在后门的？所以是否还有可能会有其他可交接的？
第二期，外包团队不依赖公司环境，而是全全交给外包。
1.3、步骤
1、外包涂鸦那边，确认交接产物范围
2、外包团队那边，除常规的交接外，还应包括基础设施等的交接。
1.3.1、交接清单简表
| 序号 | 类别 | 核心交接项 |
|---|---|---|
| 1 | 基础设施 | 服务器、域名、DNS、SSL证书、数据库 |
| 2 | 第三方服务 | 涂鸦IoT、推送、统计、短信、地图 |
| 3 | 部署运维 | CI/CD、部署脚本、监控、日志 |
| 4 | 代码层面 | 源码、API文档、协议文档、数据库Schema |
| 5 | 账号与权限 | 代码仓库、应用市场、邮箱、微信公众平台 |
| 6 | 特别注意 | 域名/SSL/服务器续费、涂鸦商务关系 |
更详细的外包团队交接表见附一
1.3.2、特别注意
- 域名续费：确认域名何时到期，谁负责续费
- SSL证书：证书何时到期，谁负责续期
- 服务器续费：确认服务器续费周期和费用承担
- 涂鸦平台：确认与涂鸦的商务关系是否还在
2、app使用问题
2.1、问题
电话沟通时候，提到有好些用户购买产品后反应在app中操作，硬件响应有问题，影响到了产品的售后。
2.2、剖析
目前有三个app，分别为涂鸦换logo的两款 BN-LINK Smart、HBN Smart和自己开发的一款BN-HUB。
目前有两种模组，分别为涂鸦模组和自己购买芯片制作的模组。
目前的智能家居有非常多款，其可能仅可能是任一模组，以及通过某一或某几款app操作。
2.3、处理步骤
2.3.1、智能家居硬件与app关联梳理
①了解有多少智能家居的硬件，其分别使用什么模组，以及其目前分别可通过哪些app控制。
②了解目前各个智能家居存在的问题，为后续对历史问题做归类以及优先级处理做好基础。
| 序号 | 硬件 | 主要功能 | 模组类别 | 已接入的app | 存在的问题 | 问题等级 | 其他备注 |
|---|---|---|---|---|---|---|---|
| 重要且紧急 | |||||||
2.3.2、定位问题的可能方
在上述整理的基础上，通过问题描述及历史排查记录，初步定位问题根源的概率性。可能的方向有客户端、后台云端、硬件端，以及网络传输等。
例如：
①出现问题的是涂鸦的模组，还是自己购买芯片制作的模组？出现问题的模组是在哪个环节，生产、研发等？
②出现问题的是在客户端、还是服务端，还是其他路径上。
2.3.3、纵向与横向处理
在1中通过重要紧急等优先级处理了垂直度上的问题，保证了当下的需要；然后通过2中的根源从横向展开上了解其他类似问题，以此对该性质类问题做更好的维护，保证了未来的扩展和稳定性。
2.3.4、自研与迭代
在完成上述基础上，进行公司长远战略的智能家居SDK开发。沉淀核心技术，让其能够更好的符合公司的发展。
四、团队方案选型对比
方案A：快速接手型
| 维度 | 内容 |
|---|---|
| 团队规模 | 3-4人 |
| 技术策略 | 先接手外包代码，维持现状 |
| 交接重点 | 代码、文档、API协议 |
| 风险 | 技术债较多 |
| 适合场景 | 快速产出、预算有限 |
方案B：逐步自建型（推荐）
| 维度 | 内容 |
|---|---|
| 团队规模 | 5-7人 |
| 技术策略 | 接手后逐步替换核心模块 |
| 交接重点 | 代码交接 + 知识转移 |
| 风险 | 中等 |
| 适合场景 | 平衡控制权和效率 |
方案C：全新重构型
| 维度 | 内容 |
|---|---|
| 团队规模 | 8-12人 |
| 技术策略 | 全新技术选型重做 |
| 交接重点 | 需求文档交接 |
| 风险 | 周期长、投入大 |
| 适合场景 | 长期自主可控 |
选型结论
推荐方案B：逐步自建型
理由：
- 团队规模适中，5-7人可覆盖iOS/Android/后端
- 先从外包方完整接手现有代码，保证业务连续性
- 逐步用自研模块替换核心控制逻辑
- 最终实现对核心代码的完全掌控
五、团队配置建议
推荐配置：5-7人
| 角色 | 人数 | 职责 |
|---|---|---|
| 技术负责人(TL) | 1人 | 技术决策、架构设计、团队管理 |
| iOS开发 | 1-2人 | iOS端开发维护 |
| Android开发 | 1-2人 | Android端开发维护 |
| 后端开发 | 1-2人 | API服务、IoT平台对接 |
| UI/UE设计 | 0-1人 | 可兼职或外包 |
说明：产品经理、测试工程师、运维工程师可根据后续业务发展灵活补充。
六、时间与里程碑
1、开发人员维度（个人）
| 阶段 | 时间 | 核心目标 | 交付物 |
|---|---|---|---|
| 交接期 | 第1周 | 代码、账号、文档、设备交接，环境搭建 | 可编译代码 |
| 熟悉期 | 第1-2周 | 修复简单bug | 能处理简单问题 |
| 掌握期 | 第3周起 | 掌握核心逻辑 | 能处理复杂问题 |
2、团队维度
| 阶段 | 时间 | 核心目标 | 交付物 |
|---|---|---|---|
| 交接期 | 第1周 | 代码、账号、文档、设备交接，环境搭建 | 代码仓库、文档清单、账号权限 |
| 熟悉期 | 第1-2周 | 修复简单bug、理解架构 | 能处理简单问题 |
| 基础设施交接期 | 第2-4周 | 服务器、数据库、云服务等资产接收 | 服务器、数据库、域名SSL等 |
| 掌握期 | 第3-5周 | 掌握核心逻辑 | 能处理复杂问题 |
| 独立运维期 | 第5-6周 | 独立运维、建立CI/CD | 独立运维能力 |
| 迭代期 | 第5周起 | 核心模块自研 | 自研模块 |
七、技术演进路径
1 | 阶段1(第1-2周): 接手维护 |
八、预期收益
1、响应速度
- 需求响应从”周”缩短到”天”
- 线上bug可第一时间处理
2、成本可控
- 避免类似问题，外包重复付费
- 长期来看比付平台费更划算
3、数据掌控
- 用户数据完全自主
- 可进行数据分析和运营
4、产品体验
- 深度定制用户体验
- 建立自有品牌形象
5、技术积累
- 沉淀核心技术能力
- 具备持续迭代能力
九、关键风险与应对
| 风险 | 应对措施 |
|---|---|
| 外包代码质量差 | 投入1-2周做代码审计，识别技术债 |
| 协议文档不完整 | 从代码中提取通信协议逻辑 |
| 人员流动 | 要求外包方提供1-3个月答疑期 |
| 涂鸦平台锁定 | 规划自研IoT接入层，逐步解耦 |
| 技术栈不明 | 联系外包方确认技术栈 |
附一：外包团队交接表
1.1、基础设施（核心重点）
| 序号 | 交接项 | 优先级 | 说明 |
|---|---|---|---|
| 1 | 服务器/云服务器 | 必须 | 阿里云/腾讯云/AWS等账号、服务器IP、SSH密钥 |
| 2 | 域名及DNS解析 | 必须 | 域名账号、DNS配置、SSL证书 |
| 3 | 云数据库 | 必须 | MySQL/PostgreSQL/MongoDB 等账号、连接信息 |
| 4 | Redis/MQ等缓存 | 高 | 账号、连接信息 |
| 5 | 对象存储 | 高 | OSS/MinIO等，账号和bucket配置 |
1.2、第三方服务
| 序号 | 交接项 | 说明 |
|---|---|---|
| 1 | 涂鸦IoT平台账号 | AppID、API Key、Project ID、设备ID等 |
| 2 | 推送服务 | 极光/Firebase等推送账号 |
| 3 | 统计/埋点 | Firebase/友盟等账号 |
| 4 | 短信/验证码 | 阿里云短信等账号 |
| 5 | 地图服务 | 高德/Google Maps API Key |
1.3、部署运维
| 序号 | 交接项 | 说明 |
|---|---|---|
| 1 | CI/CD配置 | Jenkins/GitLab CI/GitHub Actions 等配置文件 |
| 2 | 部署脚本 | 部署脚本、启动停止脚本 |
| 3 | 监控告警 | 监控平台账号（如果有） |
| 4 | 日志系统 | 日志收集配置（ELK等） |
| 5 | 防火墙/安全组 | 端口开放配置 |
1.4、代码层面
| 序号 | 交接项 | 优先级 |
|---|---|---|
| 1 | 完整源代码 | 必须 |
| 2 | API文档 | 必须 |
| 3 | 设备通信协议 | 必须 |
| 4 | 数据库Schema | 高 |
| 5 | 架构设计文档 | 中 |
1.5、账号与权限
| 序号 | 交接项 |
|---|---|
| 1 | 代码仓库地址及权限（GitLab/GitHub） |
| 2 | 应用市场开发者账号（App Store/华为/小米） |
| 3 | 所有相关邮箱账号 |
| 4 | 微信小程序/公众平台账号（如有） |
End
本文档仅作为初步分析，具体实施方案需根据实际情况进一步细化。
如有疑问，欢迎随时沟通。
感谢您的阅读。