HN Weekly 中文
← #807

作为 Staff 工程师，我是怎么找到值得解决的问题的

查看原文 HN 讨论

文章摘要

作者 Lalit Maganti 是 Google 的 Senior Staff 工程师，做的是 Perfetto（性能调试工具）。这篇文章起因于他带的一位资深工程师的提问：「你是怎么找到值得做的问题的？」那位工程师正想往 Staff 迈，意识到这个岗位不只是把分配下来的活干好，还得参与决定团队和组织该建什么。有人建议他在日历上专门划出时间「思考大局」，他试了，觉得没什么效果。

作者的回答是：他几乎从不靠盯着白纸「战略性思考」找到好问题。他的做法是当一块海绵——听日常的噪音流，吸收别人正在遇到的问题，让它们沉在脑子后面。时间一长，有些自己淡去了，另一些之间开始浮现出联系，最终他就看清了到底是什么在拖慢大家、以及他或他的团队能做什么。他见过很多工程师从没试过这条路：他们等经理或 lead 来指出机会，然后靠解决最难的被分配问题来证明价值——这条路确实也能升职，但他职业生涯里印象最深的项目，全都是他找到并解决了一个领导们还没意识到存在的重要问题。他明确加了一个前提：他的经验主要来自大公司的基础设施和开发者工具团队，工程师对路线图有很强的自下而上的自主权；在更自上而下的环境里，这种做法的空间可能小得多。

文章分四步。第一步是「吸收问题，而不是需求」。 人们爱聊自己面临的困难——在会议、聊天串、演示和邮件里解释工作为什么难、抱怨什么拖慢了他们、描述他们希望能做到什么。只要跟他的领域有交集，他就顺着线头往下拉，比如问「如果有 X，能解决你的问题吗」，或者指向自己负责的产品里的某个已有功能问覆盖了多少场景。用户经常直接要一个特定方案而不是解释根本问题，他不会照单全收，而是一直挖到明白对方到底想达成什么、以及现有产品为什么不行。作为一个天生的内向者，这种「环境式聆听」特别适合他——他不需要为了找点子把日历塞满投机性的会议，正常的一周里流经身边的有用信息本来就极多。但当某个问题值得深挖时，他会转为主动：坐到那个团队旁边看他们走一遍工作流和正在查的 bug，可能的话自己上手查几个，「亲眼看到问题，更容易把团队真正需要的东西和他们嘴上要的方案区分开」。他还会专门去找那些视野比他更广的人——负责关键系统的、跨多个团队的、对下游有深刻洞察的——约 1:1 或喝咖啡，问他们最近碰到什么有意思的问题；这些人往往已经在好几个地方见过同一个现象并开始连线，能让他在模式识别上抢先一大步。

第二步是「让问题堆积」。 他被「动作太快」坑过好几次：被某个声音大的团队的需求打动，建好了功能，然后看着他们几乎不用——他们的优先级变了，或者那个需求本来就来自一次已经不重要的一次性调查。一个团队当下多热切，跟这个功能相对于产品其他需求有多重要，是两回事。这教会他让潜在问题堆着：按他这种听法，攒下的问题远多于他能解决的，而且不是所有都值得行动。等待可以是一种超能力——等待意味着同一个问题可能在不同团队独立冒出来（说明优先级更高），或者表面看起来不同的问题其实形状相同（一次能覆盖多个场景），又或者，正如他痛苦学到的，提需求的团队其实压根没那么在乎。他自己是记在脑子里、下次再听到就重新审视；他认识的另一些工程师会更系统地写下来。机制是个人选择，关键是让未解决的问题留存足够久，好让更多证据积累起来。

第三步是「找到共同的形状」。 等待只帮他收集证据，还得判断这些问题是否真的相关、有没有什么能一并解决。Perfetto 是个好例子：它在时间线上用一行行「轨道」显示系统活动记录，两年里不断有团队要一些很小很具体的 UI 改动——一个想要命令把自己偏好的轨道钉在顶部，下一个团队想要同样的功能但针对完全不同的一组轨道；还有的想让 Perfetto 打开时就缩放到记录的某一段，或者显示自定义聚合；有几个团队等不及，用 bookmarklet 调 Perfetto 内部 UI API 搭了复杂的变通方案。攒够之后他脑子里照例是一团乱麻：需求本身、各自的约束、一堆半成形的方案。他学会了不在书桌前硬憋方案，而是在伦敦漫无目的地长时间散步——不刻意去逼的时候，联系反而更容易出现。最后他意识到的是：这些团队真正想要的都不是他们要的那个功能，每个团队想要的是按自己的工作流个性化 Perfetto，同时不把自己的选择强加给所有人；底层需求不是某一个功能，而是扩展 UI 的能力。他形容这种连接终于「咔哒」一声接上时是这份工作里最好的感觉之一：几个别扭的需求塌缩成一个想法，而且打开了任何单个需求都没暗示过的可能性。但他紧接着警告：正是这种时刻最需要小心，因为共同形状只是一个假设，优雅不等于证据。他举了自己近期的一次翻车：他曾坚信给 Perfetto 的 trace 查询做一套透明缓存能同时解决大 trace 分享和重复查询两个问题，直到写 RFC 和做原型时才发现优雅是个谎言——两个问题需要的其实是完全不同的方案；他不情愿地把设计一分为二，两半后来都各自上线了（重复查询靠内存里保温的会话解决，重新打开靠导出成快速加载格式解决）。

第四步是「先压力测试再开建」。 走多远取决于他有多确信这个想法可行、以及人们是否真的想要。如果足够有用且风险足够低，他就直接动手，发改动、顺便知会经理；如果不确定能不能成或要花多少力气，就做一个用完即扔的原型，它能暴露失败点，也给别人一个具体的东西来反应；如果想法很大但他被说服了，就投入全部——数周或数月的工作，加上在其他工程师和团队之间建立支持这件苦差事。整个过程中他不只是在说服别人，也在说服自己：如果别人看不到他看到的价值，或者撞上重大技术墙，他宁愿现在放弃，也不要建一个没人用或者变成维护噩梦的东西；有时候想法站得住但时机不对，他就先搁着，等它成为组织优先级的那天再出手。而当一个想法立住了，他也不一定非得是那个实现它的人——可能他做、可能团队里别人做、也可能它改变的是整个组织的关注点；找到并塑造正确的问题，即便不拥有实现，也能产生影响。Perfetto 的扩展性想法值得全力投入：他们本来就在做插件来模块化 UI，但插件不够——团队必须把插件代码全部开源，这对很多内部场景行不通。所以在动手建任何东西之前，他先把问题和提案带给了经理、队友和客户团队，最终写了两份 RFC、开了若干次 1:1、做了几次分享，边收反馈边打磨。最后他设计并实现了 macros 作为「轻量级扩展」——不写插件就能自动化 UI 操作，而 extension servers 让团队可以分享自己的 macros。与其自己实现每一个被要求的功能，他们把「让团队自行适配 Perfetto」的能力给了出去；如今 Google 内部有几十个团队在用 macros 和 extension servers，另有几家公司也在内部使用 extension servers。

最后一节讲这个循环怎么自我强化：他每走一遍这个流程就更容易一次。当他对别人的问题表现出真正的兴趣、问出有用的问题或帮忙解决了，对方会记住，于是开始更早来找他、把他拉进与其他遇到相关问题的人的对话里。这给了他更宽的组织视野，更容易发现模式、造出人们真正需要的东西，而解决其中一个问题又把他带进更多对话——循环继续。这些成功积累出的是来自长期守护的那种信任：早期他必须亲手把很多想法变成现实，来证明自己的判断可靠；久而久之，经理和组织开始更看重他对「什么重要」的评估，让他不必拥有每个项目也能影响路线图。他特意指出这与「成为 Staff 工程师意味着用会议和协调取代技术工作」的说法不同：对他来说，对话是他所建之物的输入，而不是最终产物。结论回到那位被辅导的工程师：找到值得解决的问题并不与这份工作的其余部分割裂，它来自足够长久地参与别人的工作，久到看见任何单个需求都无法呈现的东西。

HN 评论精华

这条帖子拿到 589 分。讨论并没有停留在文章方法论本身，而是几乎立刻分岔成两条更大的辩论：一是「找不到问题」这件事本身是不是大厂特有的奢侈问题，二是工程师自主权在整个行业是否正在系统性萎缩。