我在 SpaceX 工作了 5.5 年，管理层决定改变我们开发软件的方式，将创建产品愿景的工作移交给工程团队。他们认为让产品管理负责产品路线图的传统方式是创建一个抽象层。因此，他们着手消除在制造火箭的工厂车间和实际为火箭构建软件的人们之间进行的电话游戏。
虽然这种变化具有挑战性，但让工程师负责产品愿景最终会设计出更好的产品。这就是为什么这种做事方式影响了无数由前 SpaceX 工程师创立的初创公司构建其工程部门的方式——包括我们的工程部门。
以这种方式设置软件开发是否存在挑战？有时。是否每个软件工程师都想负责产品愿景？可能不会。产品愿景掌握在工程师手中非常重要，行业和软件开发工具本身的变化迫使工程师提高技能，从而开发出更好的产品，在我看来，这也是更好的职业生涯。
从抢票者到极端所有权
在 Sift，我们没有产品经理，因此我们希望吸引的软件工程师类型是那些希望对我们的软件如何设计以及其中包含哪些功能拥有完全所有权的人。 SpaceX 有一种极端的主人翁文化，人们被赋予更多的责任，并期望成长为这个角色，而不是被给予一个小盒子来工作。当你把人们放在盒子里时，你就不允许他们充分发挥潜力。我认为这就是 SpaceX 取得一些惊人成就的原因。在我们努力创造同样令人惊叹的技术的同时，我们还试图灌输一种极端主人翁文化。我们该怎么做呢？
许多工程师的动机是想要解决客户的问题 - 问题是，通过抽象需求文档与实际观察客户使用软件相比，他们的感受有多大？我们相信是后者，这就是为什么我们让我们的工程师尽可能直接与客户合作。
这种工作方式实际上是对我们产品的原始 DNA 负责。当我们创办 Sift 时，我们的小团队从我们网络中的一家公司转租了空间，我们知道这家公司可以从我们试图开发的产品中受益。他们分享了他们的数据，我们开始开发软件，我们知道这些软件可以帮助他们和无数其他初创公司在不断增长的数据海洋中努力开发尖端硬件。我们在他们的空间里呆了三个月，迭代我们的产品。我们将两个工程团队聚集在一起，向他们展示我们工具中的数据，并让他们使用他们现有的解决方案和我们正在并行开发的解决方案。在那段时期结束时，我们开发了一种他们愿意付费的产品，并且现在正在帮助许多其他初创公司解决类似的问题。
虽然我们不在客户办公室设立办事处，但我们确实让我们的工程师直接参与新客户入职会议 - 面对面会面，了解客户如何在他们现有的工具中工作，并观看他们在我们的工具中工作。这有助于确保我们的解决方案以最有利于他们的方式设置，并为我们产品的下一次迭代提供重要的产品开发决策。工程师在他们正在开发的工具上花费了大量时间，因此他们并不总是容易识别产品中缺少的东西或产品比应有的笨拙的区域 - 花费一两天的时间来研究新的或现有的工具客户实际观看他们使用它是解决这个问题的完美方法。在初始入职会议之后，我们的客户和工程师之间的这种直接沟通渠道仍然通过我们建立的直接 Slack 渠道以及与工程团队成员的季度会议持续很长时间。
聊天后 GPT 世界中的工程
虽然这一切听起来像是“很高兴拥有”，但我相信在一个越来越多的软件将由低代码应用程序和人工智能副驾驶编写的世界中，工程师需要升级。人工智能将接管更多的软件开发，并且首先会处理简单的事情。工程师可以做以下两件事之一：专注于技术性很强的工作，或者真正深入了解工具的使用方式、开发的行业以及试图解决的问题。
我们希望我们的工程师成为未来的一部分，而不是陷入无休止的取票循环。尽管关于工程师的旧说法是这样说的，但我们发现大批工程师兴奋地欢迎新的做事方式 - 这将同时使客户和工程行业受益。
您可能还喜欢……
开发人员和领导者在生产力和满意度方面脱节
优先考虑您的开发者体验路线图
