作者 | Dan Slamowitz
译者 | 弯月，责编 | 郭芮
头图 | CSDN 下载自视觉中国
出品 | CSDN（ID：CSDNnews）
以下为译文：
曾经的我十分喜欢软件工程师的工作。在作为工程师的最后一个项目中，周末我都会加班写代码，看着分给我的用户故事一个个完成，我的心里特别高兴。我提前完成了很多工作，甚至比团队同事领先了好几个冲刺。于是，我开始利用空闲时间尽可能参加应用程序需求收集会议。我与设计团队合作的机会越来越多，还与客户商谈产品。我逐渐地发展成了工程团队的指导角色。后来，我发现自己常常给人解释某个功能设计决策背后的原理，并在谈话中反复提出构架方法的想法。我花费了一番心思终于实现了转行的想法。我对产品更加感兴趣。
从软件工程师过渡到产品主管以来，已经快两年了。在本文中，我想谈一谈转行之后我学到的一些新知识。
不要低估产品领导的重要性
曾经有一段时间，作为软件工程师，我以为产品经理和Scrum管理的工作很简单，真正负责打造产品的实际上是工程团队。毕竟，组织开会、编写用户故事、执行敏捷流程乃至与客户交谈之类的工作能有什么难度？
后来，我发现我错了。即使从最基本的职责出发，这些岗位也有很多我从未想到的困难。
我们以站立会议为例。作为产品负责人，我的工作可不仅仅是站起来清醒一下，然后回想一下昨天我做了哪些工作。大多数时候，在上午10点站立会议开始之前，我就已经与利益相关者进行了交谈，检查了产品的各项指标，还喝完了第二杯咖啡。我从一个被动的参加者完全转变成了主动的领导者。现在，我的工作重点是鼓舞士气。我需要积极地鼓励大家给出简短的报告，处理尴尬的沉默，提醒大家在子任务中添加注释或审核PR。我想了很多办法，通过改变场所或讲笑话的方式让大家对这个简短的会议保持新鲜感。我曾经错误地以为，组织Scrum不需要特殊的技巧。然而，即使是性格外向的人（虽然我不是），组织站立会议也需要一定的技巧，这需要大量反复的练习。
我通过工作学习到的新想法和新技能让我感到惊讶。在刚开始担任产品负责人的头几天里，我曾尝试编写python程序来代替复杂的Excel函数。结果却不尽如人意。这个新奇的世界让我大开眼界，这个世界里充斥着产品预算和财务预测、状态报告、人员和利益相关者管理、沟通与便利、销售、市场营销、设计、客户同理心以及选择正确的工具等等。
优秀的产品绝不仅仅是优秀的代码
在思考什么才是优秀的代码时，我做工程师的时候总是坚持认为代码是否遵循行业最佳实践才是判断基准。例如，我的代码必须使用TDD编写，具有较高的测试覆盖率，并符合SOLID和DRY等原则。这些概念就像我的生命和呼吸一样，比什么都重要。我一直坚持编程的高标准。在将代码提交给同时审核之前，我都会再三审查我的代码逻辑，并尽可能优化。我认为，如果我尽我所能完成分配给我的用户案例，那么我们团队就能完成目标。
现在，我将重点放在并非完美但经过测试且符合规范的代码上。如果新的团队成员能够理解代码，并在有限的指导下贡献新代码，我就认为这段代码很优秀。我明白有太多可变因素会导致产品失败，而这些可变因素与代码并没有任何关系。例如，可能是因为用户体验太复杂，可能是因为没有足够的预算，可能是因为架构无法扩展到可以满足需求的规模，或者可能是因为客户对产品不感兴趣，甚至没有意识到产品的存在。如今的我学会了审视大局，我知道代码写得再好也不能保证产品一定会成功。
话虽如此，由于我的技术背景，有时仍然会不自觉掉入陷阱。在刚开始转行的时候，我很难走出舒适区。我花了很多时间检查代码和PR，本来我可以利用这些时间更好地从客户那里获得产品决策上的支持。与我们的利益相关者保持一致，为我们的产品建立共同的愿景，可以更好地减轻团队的某些压力。可能我写的一些用户故事与我设想的解决方案存在一定的偏差。我很惭愧地承认，有时我会根据团队成员对技术的理解和交付速度来评价他们。我甚至想插手自己编写代码。
很快我就意识到，要想成为一名高效的领导者，我需要转变思想观念。我强迫自己不要从工程师的角度思考问题。能够帮助我改变心态的最好方法就是以其他产品负责人为榜样，并向周围的人寻求建议。我学到的一个最重要的技巧就是，一旦我踏入工程师的领域，就让他们的负责人把我撵出来。我甚至开始将这个策略应用到生活的其他领域，而且我还想向所有人推荐这种方法。
经过大量的实践后，我学会了利用自己的专业知识与我的团队建立良好的关系。我可以一边鼓励工程师对他们的工作负责，一边在与客户或利益相关者的互动中成为他们的最大盟友。当我们在计划冲刺或有待完成的工作时，我不会回避技术实现上的难题。这种方法提高了我们对用户故事的接受标准，并让工程团队对他们构建的功能以及背后的原因更有信心。
我是第一个勇敢承认我仍在学习如何保持技术知识与产品领导业务深度之间的适当平衡的人。但是，我明白一个道理：一个产品的成功绝不仅仅局限于一个优秀的工程师团队。
工程与产品一家亲
回顾我作为工程师的日子，我希望我能够更加体谅管理Scrum流程的同事。有时候整理有待完成的工作就像打仗一样。我们经常需要花时间让产品经理逐个介绍用户案例，并消灭每一种假设。我曾听到一群业务利益相关者争论不休，争论的焦点不过是更改应用的配色方案需要花费多长时间，以及是否值得将这项任务排在其他功能增强的前面。当他们还在吵个没完没了的时候，我默默地回到办公桌前，将所有内容都改成了他们想要的颜色。不过是一个小小的代码变更就能解决的问题。
我们的利益相关者在没有真正掌握底层技术的情况下，做出的承诺很容易让人感到懊恼。即使是出席大多数功能范围讨论会上的总体架构师，他们也很难采取任何措施来解决可行性方面的难题。我知道有些功能只需很少工作就能让我们的客户受益，而有些功能则吃力不讨好。
与其以轻率的态度来对待局势，还不如寻找机会让团队团结起来，这样才更有影响力。举办简短的概述会议非常有益，因为我们可以回顾技术栈，还可以比较功能的复杂度。我们只需要请一位熟悉代码库的首席工程师出席会议，就可以提高会议的效率。虽然在sprint计划会议上做其他工作感觉很有效率，但团队凝聚力的价值不可低估。保持开放的胸襟，并采取切实的行动，才可以弥补业务团队与工程团队之间的鸿沟。
我很幸运，每一个有机会与我合作的团队都对他们开发的产品充满热情。他们始终牢记我们的团队和客户的最大利益。人们很容易在日常工作中忘记这一点。我很感谢我的种种经历，正是这些过往塑造我的观点。我也认识到，平衡更多的责任感和更少的控制可能会带来压力。我曾经非常努力地工作并解决问题。作为产品负责人，我知道产品的成功离不开团队中每位成员的贡献。
归纳起来说，工程与产品都在朝一个方向努力：努力打造能够令客户满意并实现我们的业务目标的产品。
如果你也是团队中的产品负责人，那么请尽量让工程师参与决策的制定。你需要耐心地说明工作的优先级以及背后的原因。鼓励工程师与利益相关者互动，并让他们了解你所面临的业务问题。
如果你是一名工程师，那么请不要学我以前那样。请尊重同事和流程，因为说不定有一天你也会站在他们的位置上。
原文：https://hackernoon.com/3-things-i-wish-i-knew-when-i-was-still-an-engineer-qs2l3y3l
本文为 CSDN 翻译。
1.第二期“嵌入式与物联网开发技术”线上分享——RISC-V处理器嵌入式开发与应用
2.数字货币水到渠成，第三方支付功不可没，媒体不必过度解读！
6.Imagination支持Google的Android GPU Inspector
免责声明：本文系网络转载，版权归原作者所有。如涉及作品版权问题，请与我们联系，我们将根据您提供的版权证明材料确认版权并支付稿酬或者删除内容。