程序员还是产品开发人员?为什么差异很重要!
前段时间，我们主持了一次经验面试Bas Vodde．Bas与Craig Larman一起开发了大规模Scrum (LeSS)。一个框架，在保持原始Scrum原则的同时，将Scrum扩展到中型到大型产品。在这次聚会中，Bas回答了我们Patreon社区提出的各种各样的问题。2022世界杯国家队排名
例如:
- 用2分钟的时间来解释LeSS会怎样?
- 在什么情况下应该使用LeSS ?哪些是不喜欢的呢?
- 为什么我应该使用LeSS而不是任何其他伸缩框架(SAFe, Nexus等)?
- LeSS是指许多团队一起开发一个产品。对于许多团队致力于多个相互集成的产品，LeSS有什么要说的呢?
- 您所见过的LeSS框架中最常见或最大的偏差是什么?
- 您在虚拟产品开发方面有什么经验?改变了什么?它如何影响LeSS的使用?
想知道Bas是如何回答这些问题的吗?看看视频!
在这篇博文中，我们关注一个具体的主题。它是由爱莉，意大利用户组成员:
如何帮助Scrum团队的开发人员从“程序员”转变为“产品开发人员”?
埃莉奥诺拉的问题来自詹姆斯·肖尔的书敏捷开发的艺术， Bas Vodde也做出了贡献。在这本书中，Bas解释了他工作过的大多数团队是如何从“程序员”到“产品开发人员”的。这意味着整个团队都深刻理解客户和客户领域，而不是依赖于某人为他们澄清并传递澄清的结果。
在这篇博文中，我将分享我对这个问题的看法。与您所期望的相反，我尽量减少Scrum术语的使用。我试图写这篇文章的框架不可知论。最后，作为一名产品开发人员的重要性不在于Scrum、XP或任何其他框架。这很重要，因为经验工作的基本价值和原则。
程序员的态度
现在，你可能会想:“谁在乎这个区别呢?这不是单纯的文字游戏吗?”就我个人而言，我认为这是一种看待开发人员责任的完全不同的方式。还有，开发人员的潜力。也许，开发人员的工作描述并没有字面上写着“程序员”，但这可能是他履行其角色的方式。我给你们举几个例子。它们可能听起来有些极端，但其目的是澄清程序员和产品开发人员之间的区别，以及为什么这很重要。
作为一个程序员……
- 您的重点主要放在编写代码上。代码本身不会产生业务价值。如果它不能解决涉众和/或产品用户的需求，那么为什么还要写代码呢?需要明确的是，编写代码来解决技术债务仍然是有价值的，因为它提高了产品的质量，而质量允许我们以恒定的速度发布增量的产品增量。
- 你没有直接接触涉众。涉众是帮助你决定下一步做什么有价值的人，因为对他们来说，获得时间和/或金钱投资的回报很重要。您只能与需求专家交谈。这个人解释他/她所理解的规格说明，您将其转化为软件。你和利益相关者之间没有直接的沟通渠道。
- 你没有参与设定目标。在迭代计划会议的开始，即将到来的迭代的目标被宣布。作为一个团队，你选择必要的工作来实现它。或者更糟糕的是，反复出现的目标是“完成我们选择的所有工作”。因此，没有独特的、鼓舞人心的和价值驱动的目标供团队关注。
- 你没有主动组织与涉众的评审会议。您确实收到了参加评审会议的邀请，但您不参与准备或主持。不管怎样，这是一个相当无意义的会议。它主要是一个技术解释和演示，对于缺乏技术背景的人来说是不可能理解的。它通常也没有任何利益相关者，它的参与者是来自您自己的组织的人，他们自己并不使用产品。
- 你没有将产品作为一个整体来关注。编写软件是你的主要关注点。你可以解释后端功能的所有细节，但你无法描述完整的客户旅程。这是设计师、测试人员或业务分析师的责任。即使你明白软件只是一种输出，而产品才是真正的结果。
产品开发人员的态度
在许多方面，产品开发人员的态度是与程序员相反的。下面，我将分享一些例子。用最简单的方式来描述两者的区别就是，产品开发人员是主动的，而程序员是被动的。产品开发人员积极主动地寻求与涉众的协作，以更好地理解他们的需求。程序员的反应性更强，他们会等待别人告诉他们下一步该做什么。
作为一个产品开发人员……
- 你要为产品设定一个“长期”目标。在复杂的工作中，共同的目标是帮助您穿过浓雾到达港口的灯塔。没有它们，你很可能会迷路并跑上岸。为了确定您首先应该从哪里出发，您需要为产品创建一个长期目标。这可能需要多次迭代才能实现。理想情况下，您应该与关键涉众一起制定产品目标。每个人都提出了他们认为重要的想法，它被精炼到只剩下一个目标的程度。这是团队在接下来的一段时间将关注的产品目标。
- 你帮助制定“短期”目标。短期目标让团队专注于迭代过程中重要的事情，同时允许灵活地调整进程，并根据需要避免出现的障碍。当团队致力于一个特定的目标时，实际工作会根据需要不断地改变，以反映发现、见解和想法。目标的创建应该是整个团队及其涉众的共同努力。理想情况下，每次迭代只有一个目标，每个人都已经对即将到来的目标有了一个粗略的概念。这能让每个人都能集中精力和清晰地做事，让每个人都能权衡该把时间花在什么事情上。
- 你与利益相关者打交道。当你不知道你的利益相关者是谁以及他们想要什么时，你就很难创造出有价值的东西。研究表明，当团队与利益相关者紧密合作时，他们会更有效。否则，您就不能确定您正在构建正确的产品并添加正确的功能。涉众通常对什么使您的工作更有价值有深刻的见解。因此，作为一名产品开发人员，您需要主动接触涉众，以更好地理解他们的需求，并且您可以提出减少工作的技术选项，同时仍然可以实现产品目标
- 您开始细化工作项。细化是将较大的项目分解为较小的项目的过程，目的是在一次迭代中以可以轻松交付给涉众的项目结束。在细化上花费更多时间的团队也更有可能频繁发布。反过来，他们有更满意的涉众和更高的团队士气。作为产品开发人员，您了解哪些项目可以从细化中受益，并积极地将它们细化为更小的工作块。
作为产品开发人员，您了解哪些项目可以从细化中受益，并积极地将它们细化为更小的工作块。
- 你积极参与涉众的产品评审会议。每个回顾会议的目的是检查到目前为止已经完成的工作，并根据从中学到的知识决定下一步应该采取什么措施。该检查是团队和涉众之间的共同努力。你不仅要检查结果，还要检查当前的市场状况、组织变化、预算和时间表。作为产品开发人员，您准备评审会议，并支持涉众使用新特性来收集反馈。所有这些都能帮助你决定下一步要做什么。
- 你的重点是为利益相关者提供价值。在开发产品时，“价值”通常具有多种形态。明确在backlog中表示什么类型的值是有帮助的。作为一名产品开发人员，您了解对涉众来说什么是有价值的以及为什么有价值。您还能够解释即将进行的工作对涉众的价值。特别是当业务价值不明确时，例如高技术工作和/或消除技术债务。
- 你参与产品发现。产品发现是团队通过实验、现场测试和研究发现新的有价值特性的主动行为。通常，来自这些积极行为的见解会产生更多有价值的特性，并避免不必要的工作。因此，作为一名产品开发人员，您要访问您的利益相关者，了解什么是最重要的，并共同努力探索您的产品状态和市场条件。您不仅要了解涉众的业务视角，还要分享可能影响开发过程的技术方面。
- 你对利益相关者的需求做出反应。响应能力是团队对不断变化的需求、新的见解和来自涉众的新问题做出反应的能力。由于产品开发的复杂性，许多问题、想法和机会只能在开发过程中发现。经常发布新版本的团队有更多的机会从涉众那里得到现实的反馈，并验证双方存在的假设。反过来，这让你的团队减少了在不必要的功能上浪费时间和金钱的风险，同时也创造了利用新见解的机会。产品开发人员完全理解响应性的重要性，因此不断地寻找尽早和经常发布的机会。
Sprint评审，Scrum团队与涉众合作检查增量，收集反馈，并定义下一步。
转向产品开发人员的快速提示
到目前为止，您应该已经清楚地了解了程序员和产品开发人员之间的态度差异。希望您能看到作为产品开发人员的价值。但如何实现这种转变呢?如何从被动的态度转变为更积极主动的态度?可能是您个人已经想要进行这种转变，但您的环境不支持它。因为很容易陷入困境，我们总是鼓励团队朝着正确的方向迈出一小步。我们称这些小步骤为“快速技巧”。快速提示的目的是在你的Scrum团队中引发微小的、增量的变化。朝着正确的方向迈出一小步，以消除障碍，改进协作，管理风险，并更快地交付价值。
所以，在接下来的一段时间里，考虑尝试以下方法:
- 在你的下一次迭代中，为你的待办事项列表收集至少3个可行的想法面试的人跟你的产品有很大关系。
- 邀请2个用户参加您的下一个产品评审会议(远程或亲自)积极使用您的产品。
- 对于迭代backlog中的每个项目，一起添加并完成:' [item]，和这对我们的用户很重要，因为……”
- 在下一个迭代中，验证两个项目你正在与产品的一个或多个活跃用户一起工作。
- 下周,到一个有很多用户的地方进行实地考察你的产品。你也可以分开访问多个网站。向对方报告你的发现。
所有的快速提示都包括在Scrum团队调查．有了这个免费的产品，Scrum团队可以通过广泛的、经过科学验证的调查进行自我诊断，并在完成后收到详细的结果和基于证据的反馈。试一试，你就会收到关于调查包含的30个主题的快速提示!
关闭
在这篇博文中，我解释了程序员和产品开发人员态度的区别。这种态度上的改变很重要，因为你的团队越了解涉众和他们的产品，他们就越有可能做出正确的东西。否则，他们可能会在涉众没有的问题上浪费大量的时间和金钱。因此，产品开发人员参与创建长期和短期目标，与涉众接触，积极参与产品评审会议，启动改进，关注价值，参与产品发现，并响应涉众的需求。
你的团队中开发人员的态度是什么?如何帮助开发人员关注整个产品，而不仅仅是软件?我们总是渴望从你的经验中学习，所以请随意分享。让我们一起学习和成长!