如何与工程师沟通
为什么与工程团队的沟通至关重要
这位工程师说，“我们需要在接下来的几周内花时间重构代码”。
产品经理说，“在地狱中燃烧”。
为什么与工程团队的沟通至关重要
如果你想成为一个非常糟糕的产品经理，最好的办法就是与你的工程团队建立非常糟糕的关系。没有什么比 PM 和工程师之间的糟糕关系更能保证产品质量不好了。
与一个没有动力的工程师团队一起工作，他们讨厌他们正在构建的东西，讨厌产品经理，并且一直在看时钟，直到他们可以回家观看《权力的游戏》，这是一种非常不愉快的经历。
沟通是与您的工程团队建立牢固而富有成效的关系的关键部分。
与工程师沟通的规则
1. 消除障碍
“产品”和“工程”之间的划分会适得其反。相反，将自己视为 1 个团队。你不是一个向工程师分配工作并告诉他们做什么的特殊产品雪花。你并不“高于”工程师——或团队中的任何其他人——因为你可以在 Powerpoint 中将商业模型画布和一些图表放在一起。你们都是产品团队。
你们都在构建产品来取悦用户并实现业务目标。您的产品的用户不会有任何概念，您的产品是由工程师团队和产品经理以敏捷的方式通过看板和 Slack 渠道构建的。他们将把它作为一个整体来体验，你们都必须将自己视为一个团队。
如果可能的话，一起坐在同一排桌子上。
如果您的工程师开始谈论“产品”，就好像它是一个单独的实体或公司的一部分，请提醒团队中的每个人，您都在构建产品。代码行不仅仅是代码行；屏幕另一侧有真人与产品互动。
如果您是远程设置中的 PM，请定期访问您的团队。确保您坚持每天的站立并在视频通话中使用视频，以便您的团队每天都能看到您和您的脸。你的脸很重要——所以用它。将您的脸放在 Trello、Slack、Jira 和您使用的任何其他工具上的头像中。并确保团队的其他成员也这样做。没有面孔，远程团队将无法工作。
毫无疑问，与远程团队建立统一感更难，但通过定期的日常互动，至少可以消除一些障碍。
使用能反映你的单一实体这一概念的语言。使用“我们”、“我们”、“我们的目标”、“我们的成就”和“产品团队”来描述你自己以及你想要实现的目标。给自己一个团队名称并使用它。不要支持产品团队以某种方式与技术团队分开的观点。使用支持您是一个团队的想法的语言，共同构建产品。
带领
作为产品经理，在团队乃至组织中展示领导力至关重要。但领导力甚至意味着什么？
领导力通常是一个流行词，有许多不同的定义。没有一种明确的方式来描述强大的领导力，所以我不会费心用一句话来定义它。
对我个人而言，产品领导力通过态度、行为和个人原则来体现：
- 采取极端所有权——极端所有权的概念取自一位美国海军人员的一本书，他写了一本同名的书。这是他对如何成为极端领导者的看法。
领导的二分法 一个好的领导必须是：自信但不自大；勇敢而不鲁莽；有竞争力但很优雅的失败者；注重细节但不为之着迷；强壮但有耐力；领导者和追随者；谦虚不被动；进取而不是霸道；静不静；冷静但不机械，逻辑但不缺乏情感；与部队关系密切，但不能靠得太近，以至于一个人比另一个人更重要，或者比团队的利益更重要；不会太近，以至于他们忘记了谁负责。能够在行使分散指挥权的同时执行极端所有权。一个好的领导者不需要证明什么，而是需要证明一切。
- 有自律——如果你说你要做某事，就去做（工程师永远不会忘记）。这可能就像在回顾之后发送笔记或在下一次计划会议之前整理积压一样简单。如果您不遵守承诺做的事情，您的团队会注意到。结果他们会质疑你的权威和正直。如果你无意做某事，不要说你会做。
- 代表团队发言——赞美团队。谈论你的成功。当利益相关者抱怨他们永远得不到他们想要的东西时，为团队辩护。当其他人破坏你的工作时，坐在尴尬的沉默中是虚弱的。当然，听听批评，但如果你认为它没有根据，那就挑战它。为你自己和你的团队挺身而出。
- 听——这样的陈词滥调，但令人难以置信的是我们花在等待说话而不是倾听的时间。如果您的团队正在与您谈论技术债务、功能的复杂性或对产品策略的担忧，请倾听他们的意见，并以积极的回答来解决他们的担忧。但是，如果讨论陷入不重要的胡言乱语和辩论的黑洞，就像您在小组中发言时有时会发生的那样，请缩短对话并将团队的注意力重新吸引到手头的事情上。
- 做出决定——通常作为产品经理，我们被迫用很少的数据来帮助我们做出决定。自然，我们需要尽可能多的数据，以确保我们不会找错树。但事实是，有时即使有大量数据来支持特定的决定，你也不会知道你的想法是否会成功，直到你冒险去做。优柔寡断是产品管理的杀手锏。尽你所能降低风险，但有勇气做出决定。优柔寡断意味着你正在阻止自己比今天知道的更多。
- 不可预测– 展示领导力的最有力方式之一就是不可预测。可预测的行为让别人在你面前感觉太舒服，有时会给别人一种控制你的感觉。特定的不可预测的行为可能会让其他人更加关注您，并迫使他们将您视为领导者。例如，如果你总是在回顾中表扬团队，那么在下一次回顾中，只关注负面因素。或者，如果您通常不在站立会议上发言，请强调谈论特定的故事或在更广泛的业务环境中正在发生的事情。如果你是一个快乐、快乐的人，一个简单的策略就是几个小时内根本不笑。像往常一样与您的团队互动，但不要嘲笑任何笑话或自己开任何玩笑。去坐在另一排桌子上，让自己一整天都没有时间。这些突然的、不可预测的、令人震惊的行为转变可以解除人们的武装，让你看起来像一个更强大的领导者。不要经常这样做，否则你会出现人格障碍，但时不时地进行一些不可预测的行为会帮助你建立强烈的领导感。
创建 BS 自由区
工程师有很多才能。除了他们在解决问题和编写漂亮的代码行来为您的产品提供动力方面的惊人技能之外，所有工程师都天生具有嗅出废话的超人能力。
将一些花哨的数字放在一起，并使用诸如“授权”、“杠杆”和“解决方案”之类的短语可能会在会议室为你赢得布朗尼积分，但当你与工程师交谈时，你正在处理的是另一锅鱼.
他们会用最轻微的 BS 气息来召唤你，所以如果你正在考虑使用流行语来激励或从你的团队中获得支持，那就别管它了。
相反，用简单、简单、诚实的语言说话。解释你想要达到的目标以及原因。尽可能坦诚相待，把陈词滥调留在与销售和营销团队的会议上。
每次您使用 BS 短语时，请让您的团队呼叫您。最终，当您与团队交谈时，您将学会从词汇表中删除它们。
激励
我的一个朋友曾经将工程师描述为猫，我认为猫类比可能是我在整篇文章中用来描述工程师的所有冒犯性术语中最准确的。
但是将某人描述为猫并不冒犯。
猫很聪明。
如果你想让狗做某事，你告诉它该做什么。猫不会。他们不会像狗一样“坐”或“取”。不，不。他们太聪明了。
如果你想让一只猫做某事，你必须给它一些强有力的、切实的激励。您必须明确说明猫将如何从做某事中受益。你必须激励猫做某事。
铺设猫薄荷对于让开发人员参与进来至关重要。作为产品经理，激励你的团队意味着放下猫薄荷并解释更广泛的背景，以确保你的团队想要完成所需的工作。
激励团队是困难的。你怎么做呢？
以下是我发现的一些特别有用的方法。
- 明确地将日常工作与总体愿景和目标联系起来
陷入特别具有挑战性的错误修复或功能可能会令人沮丧。一个对工作特别乏味的工作感到厌烦的消极工程师可能会对团队的其他成员产生连锁反应。1 名士气低落的工程师会告诉其他 3 人，他们的情绪也会受到负面影响。在不知不觉中，整个团队都不高兴了，因为 1 个故事似乎不太清楚，或者一个错误修复似乎无关紧要。为避免这种情况，请确保明确说明特定错误修复或故事与大局相关的原因。
例如，如果您优先考虑修复错误，请解释为什么修复它如此重要。解释此错误对当今业务的影响；损失的收入金额，因此不满意的客户数量，您的客户服务必须做的额外工作量。修复错误意味着额外的收入、NPS 的提高和更快乐的客户。
如果某个特定的故事或错误修复与您的整体愿景并不完全一致，请问问自己为什么要优先考虑它。如果它与您的目标不一致，您的团队就不应该为此而努力。
- 促进与真实人类用户的互动
激励团队最有效的方法之一是确保他们知道有真实的人在使用您的产品。产品团队经常陷入自己的内部流程、工具和争吵，忘记了团队存在的唯一原因是为使用产品的人增加价值。
特别是对于工程师来说，这可能很困难。虽然产品人员经常与业务的其他部分进行交互，从而提供有关业务的背景和见解，但如果您不让您的工程师参与这些会议，那么工程师可能很难理解您的产品的用户。
以下是有关如何解决此问题的一些想法：
- 认识真正的用户——让你的工程师站在实际使用你产品的人面前。产品团队中的每个人都需要了解有真正的用户在使用您的产品。这通常说起来容易做起来难，即使作为产品经理，我们也经常不会像我们应该的那样经常与产品用户互动。如果您在一个产品经理团队中工作，请一起工作，以便在日志中为亲自访问真实用户而计划访问。或者与少数用户组织一次聚会。用一些代金券之类的东西来激励你的用户。
- 设置人员面板
– 人工面板是使用您的产品的用户面板。这些应该是您产品的真实用户，他们每隔几个月（可能每季度一次）报告一次他们对产品的想法。这些人是真实的，您的工程师应该了解面板。给他们真实姓名和身份，并在您的计划和调整会议中参考他们，例如这对戴夫真的有用吗？Margaret 真的会关心我们是否使用最新的 javascript 框架吗？不时旋转人机面板以使其保持最新状态。
- 邀请工程师进行可用性测试——如果您的 UX 团队与您的产品用户进行定期会议，请邀请您的工程师一起参加。他们从看到用户偶然发现产品的特定部分而获得的见解将是无价的。当然，你不能邀请整个团队参加所有的 UX 会议，所以记录会议并在之后与团队的其他成员分享见解和记录。
暴露团队
当我们与工程师建立密切关系时，我们有时会觉得他们需要与其他业务隔离开来。
这在某种程度上是有道理的，因为我们希望避免您的明星开发人员与对技术一无所知的营销主管之间发生尴尬的冲突。如果利益相关者知道他们可以直接去找工程师，他们会立即向他们发送一份想要做的事情的愿望清单。这种情况经常发生。
但是，有一个强有力的论据可以打破这些障碍。很多时候，两个看似不相关的部门的奇怪组合可以为难题带来创造性的解决方案。
让您的工程团队更多地接触业务的其他元素会使产品人员感到不安全；如果开发人员可以直接联系利益相关者，那么我在哪里适合？这种恐惧导致我们在工程和其他业务之间挑拨离间。
不要害怕让团队了解业务中发生的事情。让工程师在电子邮件线程中与利益相关者讨论业务问题，但确保是产品待办事项决定了要完成的工作，而不是单个利益相关者的意见或要求。
每两周举行一次跨职能站会，来自更广泛业务的一些代表可以参与并解释他们正在做什么以及它如何与整体业务目标保持一致。
鼓励工程师花一些时间与您的客户服务团队在一起，以便他们能够看到用户每天遇到的实际问题。
将自己从等式中移除并鼓励工程师不时地直接与利益相关者交谈，可以为现有问题或对未来计划的创造性观点带来新的见解。
传播爱心
工程师喜欢被表扬（我们也一样！）。确保您的团队感到被爱和支持是非常非常重要的。对已开发的功能给予真诚的赞美，并解释这为企业解决了哪些问题。
通常，工程师会假设任务的复杂性与其影响有关。例如，一个小的变化可以被视为不重要，因为它不需要大量的工作，但有时微小的变化会对业务产生意想不到的巨大影响。清楚地表明每件工作都会产生影响，即使是较小的工作也是如此。
确保在整个团队中平均分配您的爱。即使您确实有一个“明星”开发人员，就像许多团队一样，请确保不要将所有注意力集中在团队的 1 或 2 名成员上，并尝试平等对待每个人。
定期分享信息
- 由于新的实时聊天功能，您的 NPS 从 35 增加到 40
- 在上周的错误之后，您的 NPS 已从 40 降至 35
- 您的客户服务团队已收到客户的便条，说明他们非常喜欢已推出的新功能
- 收入自去年以来增长了 15%，产品是收入增长的核心
尽可能定期与您的团队分享这些小消息。有时，利益相关者会向您发送一封电子邮件，感谢您所做的工作。整个团队都应该参与这些交流，以确保他们在交流时也能获得好处和赞誉。这对团队来说非常有动力。
变得个人化，但不要太个人化
当您第一次开始与工程团队合作时，他们通常会对您保持警惕。你是局外人，“商人”，“经理”。他们会假设你别有用心，直到你证明不是这样。
与团队中的每一位成员建立牢固、深厚的关系对于产品的成功至关重要。不要将工程师视为代码机器。他们不是。相反，将他们视为人类并在个人层面上与他们互动，以便建立真正的联系。
询问您的团队他们住在哪里，他们周末在做什么，他们在 Netflix 上看什么，并在您的计划会议和回顾中开一些玩笑以减轻心情。有些人会一直想一个人呆着，所以让他们一个人呆着。其他人会想要发展一种关系。
虽然在工作中创造一种愉快、开放、充满活力的氛围是美妙的，但要警惕试图成为每个人最好的朋友。如果你越界而成为另一个同事，在你需要的时候就更难坚持自己。尝试在相互尊重的基础上发展亲密关系与保持对产品方向和您做出的决定的一定程度的权威之间找到平衡。
要有主见
我们都听说过自信这个词，但自信的真正含义是什么？
工作场所的行为有 4 种类型：
- 好斗的——大声、烦人、讨厌的人，他们大喊大叫，要求得到他们想要的东西。你在这些人周围走在蛋壳上，因为他们在周围非常不愉快。你经常希望他们能找到一份新工作或死去，但他们很少这样做。令人担忧的是，我注意到声音最大的人有时会得到他们想要的东西。但他们在此过程中造成的附带损害可能是致命的——这取决于公司本身的环境。如果公司里到处都是咄咄逼人的混蛋，他们无疑会很好地融入其中。
- 被动攻击- 你整天微笑，嘲笑人们的笑话并对一切说“是”。在你的内心深处，你对被迫做你认为不应该做的工作或被利用的工作感到愤怒和不满，但你缺乏必要的意志或技能来为自己挺身而出，并为此做一些事情害怕惹恼别人。相反，你可能会说“哦，不，没关系——我能做到”，然后跑回你的办公桌，故意让猪耳朵来证明他们要求你这样做是错误的。您可能会发送一封带有看似欢乐的短语的便条，但在其之下，所有这些都徘徊在怨恨的暗流中。被动攻击性是一种特别难以处理的行为类型，不建议在产品管理中使用。如果你缺乏对产品管理中的某事或某人说不的能力，
- 自信——你既不太激进也不太被动；你是两者的微妙平衡。你坚持自己，清楚地表达你的立场和观点，而不采取激进的策略。你可以说是也不是。你不会害怕别人对你的看法，以至于它会削弱你和你的决策。当然，你想被喜欢，就像大多数人一样，但你渴望被喜欢并不会因为害怕被不喜欢而麻痹你做出受欢迎的决定。
- 被动的——你真的什么都不在乎。而且你可能会在下一轮裁员中被裁掉。
当您与您的工程团队交谈时，您必须采取自信的立场。任何其他沟通方式都可能对您的声誉和团队造成严重损害。我认为被动攻击是这些行为中最糟糕的。比侵略更糟糕，因为你混淆了你的真实信念，比被动更糟糕，因为你确实在乎，你只是找不到正确表达自己的力量。被动攻击使团队合作和领导力变得异常困难。
如果您的计划会议因为团队花费 25 分钟来讨论一个故事应该是 3 分还是 5 分而失控，请通过明确表示讨论过多并继续下一个故事来维护自己。
如果团队成员对某个项目有不必要的消极态度，请坚持自己并告诉他们他们的消极态度是无益的，并且正在污染团队的其他成员，他们应该在回顾中提出这一点。
如果一个故事花费的时间是它的大小的 10 倍，请保持自信并询问为什么会这样。通常你会知道一个真正的原因，但如果你觉得自己被利用了，不要害怕说出来并质疑时间表以及为什么事情比你最初预期的要长。
如果您过于自信，您可能会觉得您的工程团队会讨厌您。但是，我发现事实恰恰相反。开发人员通常更愿意直接被告知某些事情（正面或负面），而不是不得不通过人为的情感表面来找出你的真实意图或信念是什么。
解释为什么
没有任何背景或理由的情况下，没有什么比列出要做的事情更令人沮丧的了。
作为产品经理，我们本质上是在为业务和产品团队创建一个待办事项列表。如果没有实际管理任何工程师，没有人会被迫做你说的任何事情。激励人们去做清单上的事情的最好方法是解释清单背后的原因。
- 为什么要修复这个错误？
- 为什么你优先考虑这个功能而不是另一个？
- 为什么这组特定功能有如此严格的截止日期？
- 为什么我们现在要做一些我们在 2 个 sprint 前说过我们不会做的事情？
- 为什么 Facebook 登录与我们的受众无关？
你会在别人为你写的待办事项清单上做任何事情而不解释你为什么要这样做吗？你当然不会。
作为产品经理，第一步是让你清楚为什么你首先要优先考虑一项工作。您应该知道为什么要以特定方式构建产品，为什么现在需要修复错误，或者为什么现在可以花 2 周的冲刺来进行清理。
您的计划会议是清楚阐明背后原因的最佳场所。在您的计划会议开始时，花 5 分钟左右的时间向团队解释在更广泛的业务环境中发生了什么以及这对下一个 sprint 意味着什么。
然后，在适当的情况下，当你讨论每个故事时，简要解释为什么优先考虑这个问题。如果您正在努力寻找团队应该处理这个故事的原因，那么首先问问自己为什么它被优先考虑。
