# 我的责任边界：什么该做，什么不能碰 > 背景：CTO 要我「为最终的 BD 负责」，但 BD 的业务权力不在技术线。 > 这份清单的唯一目的，是帮我在每一件事上分清：**这是我能掌控的主场，还是会把我拖进去的雷区。** > > **一句话原则**：我对「技术和系统侧能为 BD 做到的极致」负责；我**不**对「整个公司 BD 的业绩结果」负责——后者我既无权、也无力独自承担。 --- ## 一、判断任何一件事的总开关 遇到一件事，先问自己三个问题，任意一个答「否」，就要警惕它在边界外： 1. **这件事的成败，主要由我和我能调动的资源（技术、系统、亿木）决定吗？** 2. **如果做砸了，是因为我没做好，而不是因为别人不配合？** 3. **CTO 给我的授权，覆盖得了推动这件事所需的权力吗？** > 三个都「是」→ 边界内，全力做。 > 出现「否」→ 边界外，要么不碰，要么只做我那一份并把依赖如实上报。 --- ## 二、✅ 边界内：我该全力投入的主场 这些事的共同点是——**只依赖我自己的判断、执行和技术线的资源，不需要业务线点头就能做成。** 做出来的成果能直接写进述职、体现我的不可替代性。 ### 1. 技术与系统侧把 BD 支撑做到极致 - **具体**：CRM/BD 系统的设计、数据打通、稳定性、易用性，做到「技术这一侧没有短板」。 - **为什么在边界内**：这是我的本职，成败完全由我决定，没有任何外部依赖。 - **怎么做到位**：不追求功能堆砌，而追求「真的帮到 BD」——这要靠下面第 3 点的业务理解来校准。 ### 2. 用 AI 做不依赖全公司流程的「看得见的成果」 - **具体**：客户信息自动整理、商机意图识别、跟进 action 自动生成/提醒、对话式查数据。 - **为什么在边界内**：用现成大模型 API + 我的业务理解就能落地，**不需要销售团队改变工作习惯**就能先跑起来、出效果。 - **为什么尤其该做**：CTO 明说「意图识别和后续 action 非常关键」——他是技术出身，这八成指的就是系统层面的意图识别与自动化。这是我拿给他的最佳答卷。 ### 3. 主动「挖掘」业务需求，而不是「等」需求 - **具体**：扎到 BD/销售一线，搞懂他们怎么找客户、怎么判断商机值不值得追、成交卡点在哪、决策时最缺什么信息。 - **为什么在边界内**：去理解、去判断，是我自己能做的事，不需要任何人授权。 - **关键转变**：以后不问业务方「你要什么功能」，而是我自己判断「业务真正的问题是什么」，带着判断去对齐。这是从「执行者」变「定义问题的人」，也是 CTO 点我的核心短板。 ### 4. 补「商业理解与判断」这块短板 - **具体**：理解公司怎么赚钱、BD 的商业逻辑、一笔生意的关键变量。 - **为什么在边界内**：纯靠我自己学习和观察就能补，且这是 CTO 明确点名要我提升的——补上了，他对我的评价会直接改观。 - **目的要摆正**：懂商业是为了让我的**技术决策更准**，不是为了去当业务推动者。 ### 5. 基于业务判断，清晰地驱动亿木（基础设施） - **具体**：把对业务的理解转成清晰的需求和优先级，给亿木提要求。 - **为什么在边界内**：这是 CTO **实打实给我的技术线内部授权**，是我能真正调动的资源。 - **姿态**：用「想清楚的需求 + 优先级」去驱动，不是颐指气使地支使。我判断越清晰，他越愿意配合。 --- ## 三、⚠️ 边界外：碰了会把自己拖进去的雷区 这些事的共同点是——**成败主要由不归我管、也不归 CTO 管的业务线决定。** 我投入再多，也会被业务侧的混乱卡死，最后「成了功劳是别人的，砸了锅是我的」。 ### 1. 🚫 推动销售团队改变工作方式 / 强推 CRM 落地 - **为什么在边界外**：销售用不用系统，取决于销售 VP 的态度和团队习惯，我没有让他们服从的权力。 - **碰了的后果**：变成那个「逼大家填表的技术人」，吃力不讨好，还得罪销售线。 - **正确姿势**：我只负责把系统做到「好用到他们愿意用」，用不用是业务线的管理问题，不是我的执行问题。 ### 2. 🚫 替业务线定义销售流程、KPI、商机管理规则 - **为什么在边界外**：这些是业务决策和管理决策，本该销售 VP / 销售运营牵头。一年多没人做，是管理层缺位，不是我的责任。 - **碰了的后果**：我把乱的流程固化进系统，最后所有人怪「系统不好用」，我背锅。 - **正确姿势**：流程共识由业务线达成，我用工具去**支撑**已达成共识的流程，而不是去**替他们创造**共识。 ### 3. 🚫 独自去「撼动」销售 VP / 销售运营负责人 - **为什么在边界外**：他们是平级或更高的业务线，我没有权力撼动；CTO 的授权也覆盖不到业务线。 - **碰了的后果**：横向硬推注定撞墙，还可能被当成搅局者。 - **正确姿势**：能借力就借力（帮对方拿成绩、换他用权力推团队）；借不动就不强求，回到做我自己能掌控的事。 ### 4. 🚫 把「整个公司 BD 的业绩结果」全盘扛在自己身上 - **为什么在边界外**：BD 业绩由销售团队怎么干决定，这条最长、最不归我管。 - **碰了的后果**：背一个超出权限的 KPI，做到死也可能因为业务侧拉胯而「失败」。 - **正确姿势**：心里始终划清——我负责「技术/系统/数据侧的极致」，不负责「最终业绩数字」。 ### 5. 🚫 默默替业务线的缺位「填坑」而不上报 - **为什么在边界外**：业务线的流程、KPI、团队配合缺位，是公司管理问题，不是我该静默承担的。 - **碰了的后果**：我越填越深、越陷越被动，外部障碍还始终没被解决。 - **正确姿势**：把「业务侧依赖和障碍」如实、就事论事地反映给 CTO（讲事实和损失，不评价人），让他知道真实障碍在哪。 --- ## 四、最容易踩的一条灰色地带：先和 CTO 对齐边界 > 「为 BD 负责」这句话，是这份清单里所有风险的源头。**它必须先被澄清，否则我会默认背上整个 BD 的结果。** **我该做的第一件事**，是找 CTO 确认： - 我负责的是「**技术和系统侧把 BD 支撑到位**」，还是「**包含推动业务流程和团队**」？ - 如果是后者：坦诚说明业务侧流程、KPI、团队配合**不在我的权限内**，我需要他或公司在业务线上的对齐/支持，否则技术这边做到极致也会被业务侧卡住。 > 把这个依赖关系明确提出来 = 既保护自己，又让 CTO 看到真实障碍。**这比闷头硬扛聪明得多。** --- ## 五、贴在桌上的一句话 > **边界内**：技术、系统、数据、AI、对亿木的驱动、对业务的理解 —— 全力做，做出看得见的成果。 > **边界外**：销售团队怎么干、流程谁来定、VP 动不动、最终业绩数字 —— 不独扛，只上报依赖。 > > **把力气收回到我能完全掌控的范围，是这种环境里真正的进攻；把宝押在我撼不动的局上，是消耗。**