理解,构思,构建:高效解决问题,你需要这样一个思维框架

Avatar 6月前 ⋅ 632 阅读

概要:  导读:新手工程师想进阶为合格的,优秀的高级工程师,不是不断的去编程。而是首先学会构建和形成一个科学有效的思维框架。这个神奇的思维框架将避免你少入坑,取得平顺的项目推进。 There’s a common misconception...

 

导读:新手工程师想进阶为合格的,优秀的高级工程师,不是不断的去编程。而是首先学会构建和形成一个科学有效的思维框架。这个神奇的思维框架将避免你少入坑,取得平顺的项目推进。

There’s a common misconception among new software professionals that the best engineers are the best at writing code. In other words, if we get really, really good at writing code, we’ll become really, really good software engineers. Accolades, equity, and glamorous talks at big conferences ensue.

在新进软件专业人士中,有一种常见的误解,认为最好的工程师也最会写代码。换句话说,如果我们真的非常擅长编写代码,那么我们将成为真正优秀的软件工程师,那随之而来的便会是荣誉、机会、和在大型会议上的夸夸其谈。

But our job isn’t to write code. Our job is to find and solve problems that move the business forward. Writing great code is a necessary but insufficient skill for doing that job.

但我们的工作不是编写代码,我们的工作是发现并解决推动业务向前发展的问题。要想成为好的工程师,会写代码只是必须但并不是充分的技能。

When software projects fail, or take 2x to 10x as long as they should to get done, it’s almost always because the implementer diligently built something that either didn’t solve the problem or didn’t function well, and they had to throw their code away and start over.

当软件项目失败时、或者需要2倍到10倍的时间才能完成,这很可能是因为执行者很勤奋地构建了一些,要么不能解决问题,要么不能很好起到作用的东西,然后他们不得不扔掉他们的代码并且重新开始。

At Lob, we coach engineers to become great problem solvers by decomposing the process into three steps: Understand, Design, Build. Projects led by engineers who follow this framework involve less backtracking, are less prone to interruptions, are simpler, incur less toil and operational burden, and are more likely to succeed.

Loblob.com一家提供互联网工具服务的网站),我们通过将过程分解为三个步骤来训练工程师成为伟大的问题解决者:理解,构思,构建。遵循这一框架的工程师所领导的项目涉及更少的回溯,更不容易被打断,更简单,承担较少的劳动和操作负担,而且更有可能成功。

 

Understand

理解

  • What’s the business outcome we want?

        我们想要的商业结果是什么?

  • What’s preventing us from achieving that outcome today?

        是什么阻碍了我们今天取得这样的结果?

  • What already exists today in our codebase or infrastructure that helps or hinders change?

        在我们的代码库和架构中,帮助和阻碍我们取得进展的因素是什么?

 

Starting implementation without a solid understanding of the business problem commonly results in two outcomes:

在对业务问题缺乏深入了解的情况下就开始去做执行通常会产生两种结果:

1、We frequently need to stop what you’re doing to ask others for more information. Frequent interrupts are costly; they introduce context changes, usually for more than one individual. Nathan Yergler writes about the cost of interrupts here

我们不得不经常停下来,向其他人询问更多的信息。这种频繁的中断代价高昂;会导致上下文更改,而  且通常涉及不只一个人。内森·耶格勒在这里提到过中断的代价。

2、We end up building something that doesn’t solve the problem.

我们最终会造出解决不了问题的东西。

 

When PMs or project leads circulate design docs or hold project kickoff meetings, they are trying to jam as much understanding of the business problem as possible into the heads of everyone involved. The more context we can cache locally, the fewer retrievals we’re forced to make.

PM或项目主管分发设计文档或举行项目启动会议时,他们试图将对业务问题的尽可能多的理解塞进每个参与者的头脑中。如果我们脑子里对项目问题缓存的越多,之后我们被迫进行的检索就越少。

Engineers also need to understand the existing technical landscape to gauge how easy or hard the problem will be to solve. Have similar problems been solved before? Can existing infrastructure be reused to solve the problem? Our estimations will be orders of magnitude off without some familiarity with what’s there already.

工程师还需要了解现有的技术状况,以判断解决问题的难易程度。类似的问题以前解决过吗?现有的基础设施能够被复用来解决这个问题吗?我们对已经存在的事物越不熟悉,我们判断的准确性也将会逐级下降。

 

Design

构思

  • What are some different approaches we could use to solve the problem?

       我们可以用哪些不同的方法来解决这个问题?

  • What are the benefits, risks, and mitigations of those approaches?

       这些方法的好处、风险和缓解措施是什么?

 

I’ve got some bad news and some good news. The bad news is that as companies mature, fewer and fewer problems have an obvious solution; the easy ones have been solved already! The good news is that we enjoy a tremendous amount of freedom and choice in our approach to problem-solving, and for most of us, this elevates our craft from pure implementation to fulfilling, creative work.

我有一些坏消息和一些好消息。坏消息是,随着公司的成熟,越来越少的问题会有明显的解决方案;容易的问题已经得到了解决。好消息是,我们在解决问题的方法上享有极大的自由和选择,对我们大多数人来说,这将会促使我们的技艺从纯粹的执行,提升到充实的、有创造性的工作。

Since there are usually several design options, it’s not super likely that the first one that comes to mind is the best one. By spending the time to research more than one option, we get a better sense of the trade-offs we’d be making by committing to each.

由于通常有几个设计构思,第一个出现在我们大脑中的可能并不是最好的。通过花时间研究多个选择,我们可以更好的权衡这几个方案中的利弊。

In practice, this could take the form of a white boarding exercise, a design doc or one-pager, or a full-blown technical design review. The latter is just an institutionalized way to ensure that reasonable alternatives are considered and the implications of each are thoroughly explored.

在实践中,我们可以用白板练习、设计文档、一张纸、或做一场全面的技术构思评审。后者(技术评审)只是一种制度化的方式,以确保合理的替代设计方案被考虑到了,每一个方案的内涵也被彻底探讨过了。

 

Build

构建

Remember when your high school English teacher made you outline your essay before writing it? After the heavy lift of figuring out what you’re actually trying to say, the rest is just connecting the dots.

还记得你的高中英语老师让你在写作文前先写提纲吗? 在你彻底想好要说什么之后,剩下的工作就是把一些节点连接起来。

Writing code is the easiest part when we’ve already made the hard design decisions. It’s faster, more educational, and more fun when we’re pretty sure that what we’re trying to do is going to work. We have the headspace to think about crafting excellent domain logic, handling edge cases, and writing tests when we’re not winging difficult design decisions along the way.

当我们已经做出了艰难的方案构思决定时,编写代码是最容易的部分。当确信要做的东西是可行的,我们会做的更快,更有教育性,也更有趣。我们会有足够的头脑去思考如何打磨优秀的区域逻辑,处理边缘状况,以及在我们不用再去想该采用哪种构思方案的时候编写测试。

 

Putting UDB in action

使用UDB理解,构思,构建

 

I’ve found this framework to be most useful in three situations:

我发现这个框架在三种情况下都非常有用:

1.   When mentoring interns and entry-level engineers

在指导实习生和初级工程师时

2.   When approaching gnarly problems that we don’t know how to solve right away

当我们不知道如何立即解决的棘手的问题时

3.   When diagnosing why a project isn’t going well

当诊断为什么一个项目进展不顺利时

 

UDB is a really simple tool for helping less experienced engineers slow down and think about the work they’re doing. Because it’s so easy to teach, we offer this framework to intern mentors and first-time engineering managers so they can help their mentees think rigorously about problem-solving. Checking in after each step of this framework gives you x-ray vision into new engineers’ reasoning. It makes it really easy to help illuminate blind spots, suggest new directions, and avoid rabbit holes early on.

UDB是一个非常简单的工具,可以帮助缺乏经验的工程师缓和下来并思考他们正在做的工作。因为它很容易教,我们提供这个框架给实习期的教员和初级工程管理者。以便他们可以帮助他们的学员积极思考如何解决问题。在这个框架的每个步骤之后开展检查,您就可以深入了解到新工程师他们到底是怎么去推理的。这种方法可以帮助很容易得排查出盲点,建议新的方向,并避免在早期掉入陷阱。

Most senior engineers intuitively converge on something more or less like this framework through practice. But it’s still a useful way to break down super hairy problems into components. Open-ended projects for which there is no solution known to the engineering team are good candidates for applying UDB—especially when the proposed designs change our architecture or are otherwise hard to reverse. Being really clear about which part of the process we’re in also gives us some structure for staying on topic while collaborating with other engineers and stakeholders.

大多数高级工程师在实践中会多多少少将这个思维框架进行整合。但这个UBD框架仍旧是可以分解棘手的问题的有效方法。UDB框架更适用于那些工程师们不知道解决方案的开放式结尾项目,——特别是当已经被提议的构思方案要改变我们的架构,如果不改就很难逆转的时候。真正弄清楚我们在这个过程中的哪个环节,也会让我们在跟同事和该项目的利益相关者聊项目,讨论的时候可以做到有的放矢。

Finally, UDB comes in handy as a diagnostic when projects don’t seem to be going well. When projects are taking radically longer than expected, or when there’s significant backtracking, it’s a pretty good sign that either the core business problem isn’t well-understood by the implementing team, or that the design isn’t fully baked. Knowing how to pinpoint what’s going wrong gives managers, mentors, and technical leaders an entry point to provide help.

最后,当项目似乎进展得不顺利时,UDB作为一种方便的诊断工具。当项目的时间远远超过预期,或者有显着的反复,这是一个很好的信号,要么说明核心业务问题没有被实现团队很好的理解,要么意味着整体构思没有完全考虑好。知道如何准确定位出问题,可以给管理者、导师和技术领导人提供一个如何帮助解决问题的切入点。

Lob’s engineering and data teams are poised to double in size in 2019. Making mental frameworks like UDB available to everybody helps us decentralize decision-making as we scale up, keeping it where it belongs: in the hands of the engineers who are solving problems autonomously, and the teams that support them in getting good work done.

Lob的工程和数据团队在2019年将扩大两倍的规模。普及UDB这样的思维框架,可以帮助我们大家在做决策的时候做到去中心化。自主解决问题的工程师们,以及支持这些工程师能更有效得完成工作的团队们,都需要用这个思维框架。

 


全部评论: 0

    我有话说: