程序员核心竞争力：怎么做需求才能有成长？

腾讯云开发者

于 2025-07-02 08:45:39 发布

阅读量330

点赞数 15

CC 4.0 BY-SA版权

本文链接：https://blog.youkuaiyun.com/QcloudCommunity/article/details/149085297

👉目录

1 背景

2 需求阶段

3 设计开发

4 发布

5 上线运营

6 总结

7 附图

在技术迭代与业务变革的快车道上，程序员如何跳出 “需求执行者” 的惯性？真正的成长藏在需求背后 —— 当代码开始理解业务逻辑，当技术方案能为商业目标造血，当需求对接成为驱动业务进化的支点，每一次踩坑都是突破认知边界的契机。这里凝结着腾讯资深工程师从 “完成任务” 到 “创造价值” 的转型心法。

关注腾讯云开发者，一手技术干货提前解锁👇

01

背景

团队最近补充了很多新鲜血液，在和小伙伴oneone了解的过程中能感受到有些同学的当下焦虑，有些同学的未来迷茫；是啊，面对多又急的需求，如果不清楚用户价值，不能定义好的技术挑战，在这个vuca的时代谁都会担心自己未来的发展。

过去十年在互联网有些自己的领悟，虽然每个人的路不一样，不一定对也不一定合适每个技术，但只要有些许启发就好。于是在周会上给大家做了一次关于技术人怎么做需求的分享，后来想想以后还会进不少新人，不如留份文章分享给更多人，最后附一张脑图和总结，没时间的同学可以拉到底快速浏览。

如果按产品的研发生命周期来看，可以简单地分为需求、设计开发、发布、上线运营4个阶段，下面就围绕4个阶段来介绍我眼中研发怎么做需求会更舒服，成长快。

02

需求阶段

以研发接收需求方式来分，可以分为主动需求和被动需求；被动需求一般指来自客户、业务、产品发起的需求，主动需求可以理解为技术发起的需求，对于这两类需求有以下2个建议：

多去自主挖掘有价值的需求（比如降低维护成本的技术债、能提效的基建，与伙伴聊后的启发点或者技术挖掘的业务价值点）。
与业务一起共创完善需求（站到业务及客户视角而非研发落地视角）。

当进行需求评审时候，技术该怎么参与到需求评审中？我们至少要问以下3个问题而非直接当人工翻译机：

为什么做？
怎么度量？
如何做的更好？

问为什么做是要我们清楚的了解需求背景，能和产品对等对话，只有对等对话时候你才能发现需求背后的本质，发现需求的本质后才能拒绝不合理需求，思考合理需求是否可以复用现有能力免开发或者少开发，才能和业务一起共创完善更全面的需求；最终我们还是要回到需求的价值点去看需求是否匹配我们业务的技术目标，是否能带来客户价值，平台价值甚至社会价值，现在投入ROI是否划算。

当问清楚为什么可以挡掉一些需求时，这个时间留下思考以及做更有价值的事一定成就感会更强。当我们确认该投入时候，下一步要思考的是怎么度量，拆解关键链路，找到核心指标和度量手段，一个好的目标要可量化、可衡量、有挑战，而非定性的目标。

如何做的更好关键是既要仰望星空，又要脚踏实地；首先站到业务和客户视角去完善需求价值，然后回到技术视角思考工程该如何落地，最后这个方案要有长远眼光而非只是眼前的苟且。

03

设计开发

设计开发阶段主要有3方面建议，总结为：1前提，3思考，3不为；首先要有共识所有开发动作大的前提是为了业务有好的结果，如果业务长期没结果或者效果甚微，相信皮之不存毛将焉附；然后设计时候我们要思考扩展性、维护成本、ROI；要注意不炫技，不过度设计，不为了技术而技术。过往见过一些技术和业务团队经历过一些伤害然后互相缺乏信任感和安全感，最后业务不靠技术竟然也能完成目标，技术花大精力做自己的技术沉淀，虽然大家绩效都达标，但是长期产品被竞品超越和拉远，伤害了公司和团队；所以当你学会心和力都和业务往一块使时候，相信合作伙伴也会看到和认可你这个搭档，技术和业务才能形成合力而非互相埋怨。

当链路上目标一致往前冲时，技术不能成为瓶颈，结合业务目标，合理进行容量评估规划，沉淀链路流量模型；然后从性能、成本、效率、质量、安全、稳定和资损7个方向考虑；比如性能上能考虑到吞吐、QPS、RT；成本上考虑到扩展、维护、复制成本；效率上去想想如何自动化，智能化，配置化，研发模式和链路有什么问题；质量上有匠心，去做标准，做规范，提升单测覆盖，重视CR文化，会省力的搭建辅助工具；安全上从业务、数据、网络到基础安全面面俱到；做稳定和资损可以从组织保障，平台工具，发现、预警、止血能力各方面去体系化建设（稳定和资损是非常有挑战的技术命题，一定要系统化的去思考和沉淀，有机会单开课题交流）

04

发布

发布阶段的核心目标是安全上线，这个阶段是很好的锻炼机会，因为如果有心，技术深度、广度、项目管理、协同沟通、应急能力等方面能得到快速成长。比如个人从一线开发成长为TL带团队，后来总结帮助最大的是对系统的问题和故障跟进，在当时分工颗粒度还不会那么精细还不流行微服务时，每有线上预警和故障都会主动应急，或主导或帮助别人处理或者没参与的事后找他们了解详细情况，差不多半年下来对团队所有系统都很了解，对业务逻辑非常清楚，对上下游的伙伴也很熟悉，也锻炼了飞速排查定位问题的能力和各种软技能。

支撑安全上线最重要的是要有清晰、完善的上线发布手册，拥有这个法宝安全上线至少成功了一大半。具体来说上线发布手册可以包含发布计划、发布观测、发布异常操作三个要素，满足可灰度、可监控、可回滚；首先发布计划要梳理出详细操作步骤，基于此明确上下游协同，操作人，操作时间，发布的依赖，以及业务的知会和验证；准备就绪后就可以通过蓝绿、滚动、金色雀等方式进行灰度发布将影响隔离到最小范围，逐步放量观察监控指标，异常情况，一旦发现问题随时执行预案或者回滚。

这里稍微提醒下经验较少的同学，发布后一定要盯屏看监控而不是去干其他事，一定记住出问题时关键手段是先止血(比如回滚变更)而不是去排查修复，一定及时上升到TL同步风险帮助快速决策和而不是自己默默处理。

05

上线运营

发布完成一般研发大都会长出一口气，认为上线就是终点，任务已经完成，非必要不再关注，其实上线是我们的产品面向用户的开始，是起点而非终点；我们一定要调整掉当要晋升或者要述职时候才会回头总结，才回头找数据，才看线上带来价值这种坏习惯，养成日常数据驱动和复盘意识，帮助自己功夫做到平时，让其他收获来得更水到渠成。

数据驱动是沉淀数据资产，提升业务理解能力，业务增长的关键；当有数据支撑时候我们才能把精力更聚焦，做更有价值的事，也能降低链路的沟通成本，同时反哺到开头提起的与业务对等对话。

再来说说复盘，复盘我们要抓住2点：

目标驱动。
沉淀总结。

先说目标驱动，是否达标是我们整个需求生命周期最重要的事，当达到预期目标时候，我们要给自己灵魂3问，成功的关键在哪？可复制吗？是否可以做的更好？当不达预期时候，我们更要进行问题的归因，看怎么改进或者是否该止损？

沉淀总结是个人成长、提升组织和团队能力的关键，项目上线后可以通过内外部分享、公众号和内网论坛来扩大业务技术团队个人影响力，有创新特性的可以沉淀专利和创新提案保证权益，还可以总结问题放入知识库反哺到主动需求，进一步沉淀为工具能力，平台能力。当你开始不满足仅仅完成任务，而是思考如何更有匠心的做事时，自然成长也不会辜负你。