程序员版「长安的荔枝」：别当职场软柿子，掌握核心竞争力

腾讯云开发者

于 2025-06-18 08:46:25 发布

阅读量341

点赞数 4

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

版权

👉目录

1 需求太多，怎么办？

2 会议、沟通太低效，怎么办？

3 上下文信息不清晰，怎么办？

4 没有架构思维，怎么办？

5 写在最后

唐天宝年间，长安城内，杨贵妃对岭南荔枝念念不忘。为了博得佳人一笑，唐玄宗下旨：要在三日之内，将新鲜的荔枝从千里之外的岭南运到长安。这个看似不可能的任务，最终落在了驿站小吏李善德的头上。

李善德面对的是一个必败的局面：荔枝娇嫩易坏，千里迢迢的运输路程，加上层层官僚的压力传递，每一个环节都可能导致任务失败。但是，他必须完成，因为完不成就是死路一条。

程序员也常常接到各种各样不可能的任务，完成了不一定有奖，失败了大概率背锅，怎么办？

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

鹅厂程序员面对面直播继续，每周将邀请鹅厂明星技术大咖讲解 AI 时代下的“程序员护城河”。更有蛇年公仔等精美周边等你来拿，记得提前预约直播～👇

马伯庸在《长安的荔枝》中为我们描绘了这样一个古代版"Mission Impossible"。李善德用他的智慧、韧性和对人性的洞察，最终完成了这个荡气回肠的传奇。

值得一提的是，这样的事件几乎每天都发生在程序员的身上：

“这个需求很简单，怎么实现我不管”

“只改两行代码，为什么要用两天”

“预算2w块，客户要开发一个类微信 IM工具”

时间、成本、质量的“不可能三角”，是程序员每天反复横跳的日常。

怎么破局，成为了制约一个程序员从新手到卓越的关键，掌握这些核心竞争力，或许对各位小吏成长为架构师大有裨益！

01

需求太多，怎么办？

1.1 并行过多，状态起伏大

编程需要集中大量精力和注意力。然而注意力是一种稀缺资源。我们可能会设定闹钟提醒自己的待办事项，然后因为太忙又忘记设置闹钟… …你是否有过忘记提代码就打包了？你是否发版本发了一半被打断后就忘了继续？

并行处理太多任务会迅速耗尽我们的注意力，注意力耗尽后，继续进行需要高度集中注意力的活动变得不再适宜。这个时候，我们需要通过一些不需太多专注的活动来恢复，比如休息、喝咖啡或听音乐，这类似于游戏中的行动点系统。番茄工作法？它可以提供了一个专注工作的理由，给自己勇气在一段时间内不接受打扰。

WIP 追踪（Work In Progress，进行中的任务）

个人的 WIP 上限值不尽相同，就像每个人的注意力点数不同，一旦超载，效率会迅速下降。当新任务来临，而我们的并行处理能力已达上限，我们只能在任务之间不断切换，影响效率。就如下图中，背包要去承载大小不一、形状各异的任务，超出任务要并行就只能不断地拿出来装进去，来回腾挪… …

为自己或团队设置 WIP 限制，通过开发视角的看板实时追踪 WIP，以便及时调整。

优先级混乱

无论什么原因，我们总能找到办法逃避真正的工作，就像写“暑假作业”，总能找到调整优先级的借口，而把真正紧急的工作滞后。并行过多时，合理评估优先级，排除个人喜好和需求，按照真实的紧急程度来执行。

1.2 工时评估的差异

正如上面提到的，实际开发工作中是并行着诸多流程和琐事的，所以开发不要以100%的完全时间来评估工时，可以尝试一下计划评审方法。

计划评审（PERT，program evaluation and review technology）：

O：乐观预估，这是个非常乐观的数字，一切顺利则可以在这个时间完成，事实上这个概率应当尽可能的小。预估因素：考虑历史上类似任务的最快完成时间。
考虑如果一切顺利（无延误、无问题）的情况下完成任务所需的时间。
可以询问有经验的团队成员或专家他们认为的最佳情况时间。

N：标准预估，也是概率最大的数字。预估因素：分析任务的常规流程和常见问题
参考过去类似任务的平均完成时间。
与项目团队成员讨论并达成共识，考虑正常的工作效率和可能的小延误。

P：悲观预估，这是最糟糕的时候，应当考虑到各种意外，比如第三方依赖的延期、个人事务处理等等，通常这个概率也应该尽可能小。根据以上可以得出一个预估的分布以及期望的时间，将这个结果反馈给项目管理人员，是一个避免了过度预估的合理方法。预估因素：考虑所有可能导致重大延误的因素，如资源短缺、技术难题、外部依赖等。
查看历史记录中类似任务遇到的最长延误情况。
咨询专家或团队成员预测在最坏情况下完成任务需要多久。

在实践中，开发人员经常需要提供精确的时间评估。因此我们应从多角度综合考虑，将各个预估的权重汇总，给出最切合实际的预期。同时把大任务尽可能拆小，然后再加总，会比单独预估大任务的准确度高很多。

通常我们不必对评估时间过度焦虑，在项目进行过程中，保持进度的透明度也极为关键。真正不能接受的是，表面上每日报告一切正常，而直到最后一天，突然宣布进度延迟。

估算精度

对于有些旷日持久的大项目时，当我们被要求给到工时评估的时候，通常出入也会比较大。这个时候要考虑提供多高的精度，大约125天、25周、6个月，你会发现这个单位会对结果的可信度产生影响。125天看上去很准确，是经过非常详尽的分解得到的，给人更可信的感觉。所以在做估算的时候，当你的数子足够大，不妨调整一下估算单位：

持续时间	估算单位
1-15天	天
3-6周	周
8-20周	月

1.3 说不

不要说试试看

不要轻易作出承诺，除非你确信能在某个确定时间点完成任务。面对要求你承诺不确定事项的情况，应立即表明立场拒绝。作为专业人士，学会说“不”，实际上是一种负责任的表现。如果完成某项任务的前提是需要连续加班牺牲休息，这种情况下应谨慎考虑并作出决策。

警惕排期陷阱

需求方的误解：“这个需求很简单，开发应该很快完成。”这种先入为主的观念可能会导致开发人员在评估时若给出较长的预估时间就被认为是“能力不足”。
模棱两可的需求评审：在需求评审阶段不明确需求，然后在开发过程中不断添加新的需求，这种做法将严重影响开发的进度和质量。
不断变动的截止日期：刻意压缩截止日期，然后再不断推迟，使开发工作长时间超负荷运转，这不仅会影响项目质量，还会严重损害开发团队的士气。

02

会议、沟通太低效，怎么办？

拒绝参加无效会议

会议是必需的，但同时又会消费大量注意力和时间。邀请参会的人不负责管理你的时间，为时间负责的人只有开发自己。确认你不需要参加的会议，可以礼貌的拒绝，不要勉强自己。

会议时间的建议，除了一些固定的宣讲日外，平时的会议尽可能不要打扰开发的黄金时间，别人可能刚刚进入深度开发状态，比如10-11点，14-16点等。

不要当快嘴王

经常在做业务分享、需求评审等会议中，都能遇到快嘴王，要知道听众可能没有你那么熟悉你所讲的内容。

快言快语的人表达问题时滔滔不绝、态度坚定且语速飞快，强行推进议程，使别人来不及评估检视或反对。快言快语在压制那些讲话慢且担心出丑的人时，显得尤为有效，但千万不要做这样的人。要认识到，你的责任是讲清楚事情，有一点没讲清楚都不要接着往下讲。

如果你对“快嘴王”感到有压力可以说一句“抱歉我比较迟钝，但是我希望你慢点说，好让我明白你的意思”，然后，该问问题就问问题，不要遗漏任何一点。

两分钟法则：你至少让人在两分钟内不受打扰的解释他的观点，不要急于插话表达自己的意见。

专心聆听

在每日站会或是周会上，很多人都不理会其他人，只是简单的等着汇报自己的更新情况，而且发言时能少说就少说，这让人觉得无聊。又或者有些人会在会上滔滔不绝，这需要明确杜绝，并在会下单独讨论。

目标明确、结论清晰

会议有明确的主持人，明确的目标，明确的议程，谨防跑题。所有会议讨论，都应该产出总结来结束讨论，如果达成一致应当明确指出，如果没有也应当说明。会议后的进一步行动、待办清单、任务分派、截止日期都应该清晰的进行记录和同步。

03

上下文信息不清晰，怎么办？

杜绝个人英雄主义

长期忽略文档建设和技术沉淀，导致很多业务过于依赖某些员工，个人英雄主义。这对于业务本身来说也会产生巨大的风险，而对于员工来讲也会容易出现自扫门前雪的现象，同时无法对产品技术更好的掌握。而文档的缺失对于员工之间信息分享、新员工接替以及业务本身的交接都会产生巨大的成本。核心技术、核心能力没有得到沉淀，这些智力资产任由其留在个别人的脑海中、少数人的硬盘里或者被淹没于无序的文档中。

扩大业务视野

随着业务的发展，业务信息也会大爆炸，每一个模块的改动都会有很多关联模块的影响，扩大业务视野，理解上下游链路，才能更好的进行方案设计、排查问题。像迷雾模式一样去探索业务边界，扩大覆盖面，警惕黑盒功能，不要排斥获得更多信息，当没有足够的渠道去了解时，请主动反馈。

互相分享、知识沉淀，模块互备都是很好的扩大业务面的好方法。

在合理范围内尽可能扩大信息辐射

信息通道狭窄，未辐射到所有团队成员。需求阶段产品内部讨论，不与研发测试等同学阐明需求来源，研发过程中各个需求负责的同学只关注自己的模块，不参与也不关注其它同学的功能，长期以往会造成业务模块的壁垒。发布上线后的真实数据往往产品同学会单独讨论，也不会反馈给相应的研发同学，导致后者参与度不高，缺少产品统一目标意识，长此以往形成习惯，往往只停留在完成自己相应模块功能，流水线般机械生产，缺乏思考。

实际上，功能的研发和上线之后，获得实际的现网反馈是非常重要的，这可以极大地激发员工对产品的投入感和责任意识。

04

没有架构思维，怎么办？

4.1 耦合与柔性策略

耦合是修改之敌，它将模块紧密联系在一起，要改就得一起改，这让修改起来非常困难。要么花上很多时间，弄清楚各个模块要修改的地方，要么就会因为修改不到位，把时间花在不断地问题排查过程中。

业务膨胀不可避免，每一个模块的增加都会增加耦合性，关联度越高，复杂度和迭代成本也越高。而且耦合有传递性，A 与 B 耦合，B 与 M/N 耦合，那么实际上A与 B/M/N 都存在耦合。当耦合发生，一个简单的修改会传播到其它不相关模块，开发害怕更改代码，因为不确定会造成什么影响。开会不知道拉谁，索性全部拉上，因为不确定会有多少关联模块。

当我们确保刚性，比如一座桥，就需要将组件耦合在一起，让结构得到刚性，不易变形。

当设计不断变化的应用时，我们希望他更灵活，更容易变化，就如下面这样。这样的结构没有了刚性，连接个体可以灵活变动，其它部分总能很快的适应。

4.2 ETC 设计（easy to change）

设计和编码的时候，考虑一下它是否易于变更，所谓的解耦、单一职责等原则，都只是为了让代码更易于变更。无论未来发生什么，这块代码都不会成为路障。ETC 只是一个观念，帮助思考和决策，当你保存文件时问一下自己，当你写测试的时候问一下自己，当你修复 BUG 的时候问一下自己。

很多时候与其在一开始浪费精力为不确定的未来做过度设计，不如把你的代码设计成最小成本可替换的，当有一天想要丢弃或更换时，可以非常容易和平滑进行。

4.3 不要超过前灯范围

开车的时候，前灯只能照射一定范围，并且只在直线投射。在软件开发者，我们无法看到很远的未来，越远越黑暗，保持小步前进，不要过度设计，步子迈得过大。比如：估计未来几个月后的完成时间，猜测未来有的技术，猜测未来不着边际的需求。每一次调整，都在得到足够的反馈后继续前进，好比给小孩喂辅食一样，每一种辅食单独添加并观察足够天数后再添加下一样，才能让孩子更好的接受和排敏。

4.4 轻量开发

敏捷开发作为一种“轻量型”开发方式，其简单要求体现在整个项目的各个方面，只要是当前不必需的就不必考虑。如果我们可以用图片表示当前设计方案，就没有必要把他总结为一定格式的文档；如果当前功能是不需要的，我们就不用把它更新到功能图中；当前完成的功能只需按照当前的要求来做，不需要过分考虑可能要增加的需求；无需大量的前期设计，重视最后的可用产品。

4.5 让复用变得容易

完成代码后发现早有相似实现，可能源于信息共享不足、团队交流缺失、不充分的调研，或认为既存代码是一坨，难以重用而倾向于重新编写。有效的团队沟通和紧密联系通常能够预防这类问题。鼓励开发人员经常性地进行交流，共享知识（包括专题分享和轻分享）、代码审核，建设团队论坛也是促进这种文化的好方式。

交流和分享是互惠的活动，认真研读他人的知识沉淀，是对他人的尊重。这不是偷窥别人的工作，而是在向他们学习，不要想太多。事实上，在系统内每一处知识和策略都应当是集中、单一、清晰并权威地表达，避免不必要的重复。

4.6 重构与松弛

何时重构