开发人员向产品所有者提出功能建议是正常的吗？[关闭]

我最近刚开始担任开发人员，之前曾担任系统管理员。

我对使用敏捷功能的软件开发团队的理解是，“我们需要实现什么”沟通主要发生在从产品所有者到开发人员的一个方向上。开发人员可以向产品所有者表达对技术债务的担忧，但是提出功能构想不应该是他们的主要职责之一。

我工作的公司有不同的看法。对于他们来说，开发人员不仅应该向自己团队的产品所有者提出建议，还应该向其他团队的产品所有者提出建议，如果他们认为他们可以为该团队的产品做出贡献。我们的想法是我们都是一个大团队<company name>，所有开发人员都应利用他们的专业知识来推广他们认为有用的功能。

缺少更好的词，这样的方法是否“正常”？我是不是太被动了，我应该采取主动并开始将想法推向产品所有者吗？相反，公司是否完全错了，我应该在其他地方找工作吗？

这取决于您对功能提示的意思。

在计划游戏中，开发人员通常会提供有关故事的输入，并可能会在迭代中结束。但是，这与开发人员自己编写故事有很大不同。

在成熟的系统中，开发人员可能会提出解决已知问题的方法，这可能会使它成为迭代。

可以进行增强，例如为报告添加图形，但是如果开发人员提出了真实的新故事，警报铃会为我敲响。如果这有真正的价值，我会问为什么没有一个尚未实现的故事，或者为什么它在回顾中从未出现过。

正如您所说，许多开发人员“被动”的原因是，在获得好的产品创意之前，需要一定的领域知识和经验。但是，如果他们确实来了，没有理由不建议他们并拥护他们。

请记住-开发人员，产品负责人，销售人员等都在同一团队中，目标是：制造成功的产品。可以朝着这个目标努力。

在谈到开发人员和产品所有者时，在我看来，您没有中间人来负责组织中的功能。

好吧，在我的组织中，我就是那个人。我是需求工程师，他是一位学会了如何制定良好规格和选择功能的人，从而可以通过用户友好的交互设计获得高质量的软件。（在其他组织中，UX是获得相同工作的人员，您可能对该术语更熟悉）。

而且我可以告诉您：很难获得良好的规范。当然，开发人员讨厌这样做。对他们来说，这是一个负担-他们在那里建立软件，而不是考虑利益相关者之间的权力发挥和懒惰用户的心理模型。但是你知道吗？这对产品所有者也是一个负担。他们比开发人员或用户更清楚自己的软件应包含哪些功能。创建可行的规范是一种学习的技能，如果您从未学习过，就不会擅长。当然，有很多开发人员和产品所有者可以执行此操作，因为他们必须在以前的项目中执行此操作。但是普通的产品所有者或开发人员都为此感到困扰，因为这样做自然不是他们的工作。并非每个会开车的人都可以设计一辆车。同样

您是否可以在没有需求工程师的情况下开发软件？你当然可以。但是将其整个规格的重担放在产品所有者的肩膀上是不公平的，并且不利于项目结果。特别是因为他面临着一项对他来说异常艰巨的任务，因此获得他人的支持和帮助非常有帮助。如果您处在这种情况下，请不要看着您贫穷的产品所有者，不要说“告诉我为您做些什么，我会为您做的事情”，他确实不知道他需要什么。但是与您的讨论将帮助他阐明自己的想法并探索他的想法。

当项目结构中没有需求工程师时，还有另一个问题：没有主持人。所有开发人员都在技术方面，所有产品所有者都在业务方面。当两种文化发生冲突时，可能会发生冲突，每一方都会判断另一方是愚蠢且不合理的（因为它使用自己的价值体系来进行判断）。因此，请与您的产品负责人谈谈可能的功能，但是要礼貌和耐心，即使您认为他不应该使用它。项目的成功取决于你们两个人相处的融洽，有时由于冲突而做出次优的决定总比不做出任何决定要好。建立层次结构并给你们两个中的最后一个词可能会有所帮助，因为这样可以防止死锁的冲突。如果他说了最后一句话，即使您觉得这是不公平的，也要顺其自然。

关于“被动”部分：如果您没有想法，请不要试图提出一些只是为了展示活动的想法。如果产品所有者已经没有安全感，并且不知道评估他或您的想法的良好标准，那么奇怪的想法“仅仅为了拥有一些东西”将使本来已经很困难的情况变得更加困难。提出好功能的想法不是魔术，而是需要知识。如果您没有从教科书上学到它，那么您可能需要几年的开发人员经验，尤其是在您的项目需要先暴露于用户或用户生成的可用性数据（分析，满意度测量）的项目中之前，您开始注意到：这里有一个我们可以解决的问题。用户似乎在此页面上缺少某些内容，会是什么 然后，您将有好的想法要分享。

结论1：在没有需求工程师的项目中，有建议时最好提出建议。明智而机智地做到这一点-必须避免冲突，即使这意味着您的好主意被压在萌芽状态。

如果您与需求工程师一起在团队中？

我喜欢听到所有人的特色创意！是的，有时开发人员的想法很糟糕（当他们想使用户界面遵循编程逻辑时）。产品所有者的想法通常也很糟糕（当他们希望预算不多的太阳和月亮时-哦，用户应该以最高数据质量输入个人信息页面，而不会得到任何回报）。但是提出对团队中每个人都有利的规范是我的工作。即使您的想法永远行不通，听到它也让我意识到您有问题。您可能选择了错误的解决方案来提出建议，但这并不会使您的顾虑不再那么有效。如果您发现了它，则可能需要解决它（或者我需要提出它不是威胁的原因）。如果您有负责规范的需求工程师，请随时提出建议。如果他们没有听到您的声音，那么他们在做错事（请注意，“考虑”并不意味着“接受”）。

需求工程师必须从每个利益相关者的角度（有时是同时）来看项目。我们只是人，而我们常常失败。如果您在那里提供您的真实观点，而不是我们认为的观点，那么您的意见非常宝贵。

您可以在这里更自由地进行行为。做敏感性舞蹈是我的工作。不要公开地进取，这会妨碍我的工作，但是您需要更少的自我控制和文化/沟通意识，因为我可以承担一些懈怠。在有两个相互矛盾的想法而没有人可以判断哪个更好的情况下，您也不会浮动。我应该知道这一点，如果解决不了，那是我的主意。

结论2：如果团队中有需求工程师，请向他们提出产品功能建议。这次您不需要天鹅绒手套。

最后，如果没有需求工程师，产品负责人不知所措，并且想尽办法，老板直截了当地看着你，而你却没有想法，那该怎么办？

您有几种选择。正如您提到的，一个是退出。并非所有组织都以这种方式工作，如果这种环境不适合您，请找到一个更好的环境。从长远来看，对您有好处。

您也可以等待，看看是否有任何变化。下一个项目可以有一个经验更丰富的产品所有者（或具有更多领导能力的产品所有者）。但是你不能永远停滞不前。

第三种选择是自己实际学习一些需求工程。这些天来，这项技能备受追捧。即使您从未打算担任全职需求工程师的职位，拥有这项技能也可以提高您作为开发人员的价值，因为它可以使您更好地了解团队中的其他成员（和用户）并发展过程更加顺利。而且您不必深入其中。入门级教科书解释了任务，工作流，思维模型和以用户为中心的数据模型，已经使您能够发现由商人和开发人员团队设计的软件中的许多改进机会。不要 不要选择最厚的书作为学术参考（例如最近的Pohl英文译本）-它们更多地是每个小步骤的所有可能方法的清单，而没有说明如何实际执行。选择一些以实践为导向的东西。

如果您尝试了一下，但发现您对该地区没有个人兴趣，那还是可以的。不要强迫自己去做自己不喜欢的事情。但是您可能应该在具有不同团队结构的组织中寻找工作。

结论3：不用等待多年来获得直观的理解，而是读一两本书，您已经可以提供好主意了。

是的，这很正常。

Google有80％的工作-20％的创新模式，人们20％的时间致力于他们喜欢的事情。这样，他们不仅获得了新功能，而且获得了全新的产品和服务。

我是不是太被动了，我应该采取主动并开始将想法推向产品所有者吗？

那取决于你的个性。我曾与非常有激情的人一起工作过，但也与没有任何情感的人一起工作，他们花了8个小时轮班回家。