01 用执行者的勤奋掩盖战略者的懒惰
前年Q4规划会上，我信心满满地给CEO汇报技术规划。
微服务拆分里程碑、容器化改造排期、自动化测试覆盖率提升计划...每一页都有明确的时间节点和责任人。
CEO看了三页，打断我：所以，这些东西能让下个月的GMV提升多少？如果砍掉两个模块，业务会不会死？
我当场僵住。那些我引以为傲的技术先进性，在老板眼里只是一堆昂贵的自嗨。
后来我意识到：技术经理做规划，最怕的不是没规划，而是用执行者的勤奋掩盖战略者的懒惰。
后来我用三年时间，摸索出一套上看下看左看右看的四维规划法。它让我从需求翻译机变成了真正的技术操盘手。
下次面试时，hr问你如何做规划也可以先把上看下看左看右看讲给他听。
02 上看：别做战略聋子，要做战略解码器
初级技术经理最大的误区：把老板说的直接等同于战略。
老板说要搭建中台能力，你就开始拆服务；
老板说要提升研发效能，你就上DevOps工具链；
老板说要拥抱AI，你就组织团队学Python...
你这是战略执行吗？不，这是战略盲从。
上看的核心是战略解码，不是战略搬运。 我总结了一个灵魂三问工具，每次接受到上层战略时强制也问问自己下面三个问题：
战略指令：搭建中台
技术翻译：业务线快速复用能力，降低试错成本 ，领域模型标准化+核心服务抽象
不做会怎样：各业务重复造轮子，迭代速度越来越慢
成功标准：新业务接入成本从2周降到2天
关键认知： 老板通常只关注业务结果，技术经理要把业务语言翻译成技术语言，还要反向验证：如果技术不做这个，业务到底能不能跑？ 这个不做的选项，是你技术谈判的筹码。
03 下看：别做PPT架构师，要做团队地平线
我见过太多PPT：方案高大上，落地火葬场。
下看的本质是认知团队的真实地平线。 不是我想做什么，而是我们能做什么。
实操工具：技术团队能力矩阵图（建议直接抄）
画一个四象限：
● 横轴：技术栈熟练度（0-100分）
● 纵轴：业务理解深度（0-100分）
把每个成员填进去，你会看到三个危险信号：
1. 扎堆区：所有人挤在某个象限（比如只懂CRUD，不懂业务）→ 说明技术债风险集中
2. 真空区：某个关键领域无人覆盖 → 规划时不能激进投入
3. 过载区：某个人在多个象限都是高分 → 这是你的单点故障，规划要考虑他的带宽
血泪教训： 去年我规划了一个前端全栈化项目，理论上能提效30%。但没看团队能力矩阵，发现3个前端里2个对Node层性能优化没经验。强行推进的结果就是线上事故频发，最后回滚。
规划必须符合团队的能力坡度，否则就是变相裁员。
04 左看：别做功能缝纫机，要做债务清算者
技术经理最容易陷入的跑步机陷阱：永远在新功能上奔跑，却忽略脚下的地板正在腐烂。
左看就是回头看历史债务。 我要求团队每个季度必须做技术资产负债表：
资产端（我们拥有的）：
● 稳定的CI/CD流水线
● 核心支付模块的单元测试覆盖率90%+
● 完善的监控告警体系
负债端（欠下的债）：
● 订单模块有3个临时写的SQL慢查询，随着数据量增长即将爆炸
● 前端代码里嵌死了5个硬编码的第三方接口地址
● 技术文档缺失，关键逻辑只有离职的小王知道
规划时，新功能投入与债务偿还的黄金比例是 7:3 或 6:4。 如果你每个季度都在100%做新需求，你不是技术经理，你是技术透支经理。
一个实操技巧： 在规划会上，专门留一项叫技术债务。列出：如果Q1不重构支付模块，预计Q2会出现X次P0事故，影响X万订单。
用业务语言讲技术债务，老板才会批资源。
05 右看：别做当下奴隶，要做时间的朋友
初级管理者做规划只看现在有什么需求，高级管理者看未来需要什么能力。
右看包含两个时间维度：
短期（3-6个月）：业务增长预判
● 业务方说现在日活10万，你要问年底预计多少？
● 如果答案是100万，你现在规划的架构能否支撑10倍流量？
● 不要为当前流量设计架构，要为6个月后的流量设计。
长期（1-2年）：技术趋势卡位
● 团队现在用Vue2，Vue3的生态已经成熟，是否在规划中安排迁移？
● AI辅助编程已经不可逆转，是否在规划中留出工具链升级时间？
关键工具：技术雷达规划法
把技术选型分为四个环：
● adopt（采用）：当前主力技术，规划中重点投入
● trial（试验）：在边缘项目试点，规划中加入20%探索性任务
● assess（评估）：保持关注，规划中留出学习时间
● hold（暂停）：明确不再投入，规划中安排下线或替换
右看的本质是技术判断力。
你要在规划里体现：我不仅解决今天的问题，还在预防明天的问题。
06 四维整合：如何把上下左右拧成一股绳？
单独看任何一个维度都会失衡：
● 只看上：变成老板的传声筒，团队累死在KPI里
● 只看下：变成团队的保姆，业务骂你不懂变通
● 只看左：变成守旧派，阻碍业务创新
● 只看右：变成技术极客，过度设计吓跑业务
整合工具：技术规划全景图（建议收藏）
画一个坐标轴：
● 纵向：价值高度（上看=战略价值，下看=执行价值）
● 横向：时间维度（左看=历史存量，右看=未来增量）
你的每个规划项目都应该在这个坐标系里找到位置：
● 第一象限（右上）：面向未来的战略项目（如：新一代架构升级）→ 需要争取资源，重点攻坚
● 第二象限（左上）：偿还历史技术债以支撑战略（如：中台化改造旧系统）→ 必须做，但要用业务语言包装
● 第三象限（左下）：团队维护性工作（如：日常重构、文档补全）→ 作为基线保障，不占用主力工时
● 第四象限（右下）：面向未来的团队能力建设（如：新技术培训、工具链升级）→ 分散到日常，不冲刺
每次规划评审时，检查四个象限是否都有项目分布。 如果某个象限为空，你的规划就是瘸腿的。
07 写在最后：规划是技术经理的战略产品
很多技术经理觉得做规划是杂活，这是对角色的误解。
代码是你作为工程师的产品，规划是你作为管理者的产品。 它体现了你的技术判断力、业务理解力和组织协同力。
用上下左右四维法做规划，不是为了把文档写厚，而是为了在老板质疑时，你能说：
● 这个需求我上看过了，不符合Q3战略重点，建议暂缓
● 这个方案我下看过了，团队现有能力3周能交付，不需要外部支援
● 这个模块我左看过了，债务太重，现在加功能会炸，建议先重构
● 这个技术我右看过了，明年会成为主流，现在投入ROI最高
当你能用四个维度解释每一个技术决策时，你就不再是排期工具人，而是真正的技术合伙人。
【自查清单】
年初规划季，保存这张图，做规划时对照检查：
[ ] 我是否用灵魂三问翻译了老板的战略？
[ ] 我是否对照团队能力矩阵调整了项目难度？
[ ] 我是否预留了30%时间偿还技术债务？
[ ] 我是否考虑了6个月后的业务增长和技术趋势？
你在做技术规划时，最难搞定的是上看（说服老板）还是下看（说服团队）？评论区说出你的血泪史。
我是无涯，这里记录技术管理者的真实踩坑与成长，既关注技术管理，也关注技术架构，致力于技术和管理双线发展。不装专家，只写实战。WeChat公众号：无涯聊技术管理，关注我阅读更多技术管理和架构设计的相关文章，也欢迎私信沟通职场困惑。
