Phi*_*ler 8 project-management
我觉得我有时候会碰到砖墙.
我刚刚和公司里的某个人讨论过需要鼓励我们的[公司内部]客户提前考虑他们的需求并做出更大的努力以确保他们在将它们提供给我的开发团队开始之前得到修复.
反对的论点基本上是"他们付账单,所以他们应该能够根据自己的意愿改变主意"和"他们付钱给我们,所以我们应该做我们所说的".
虽然我承认并同意客户应该能够改变他们的要求(特别是在使用精益或敏捷方法时),但我也觉得应该有一些(任何!)固定,批准和签署的要求提供给我的团队.因此,我正在尝试实施一个简化的精益软件开发流程,该流程要求客户在工作开始之前修复了一系列要求(不一定是所有要求;足以让我的团队占用3周的开发和测试迭代) .
这允许我:
这是"他们付钱的论点,所以只要做你所说的,不要争辩"是合理的吗？如果不是,有什么反驳论据？
如果客户端(或我的情况下的内部业务代表)持有以下视图:
我有合理的关注基础吗？
感谢您提出的好问题！由于您的开发流程迭代已经长达 3 周，因此解决方案可能不会涉及改进风险管理（例如，将可能更改的需求推到开发周期的末尾）或期望管理（让您的团队意识到更改是不可避免的） ）。相反，我\xe2\x80\x99d 建议一些事情：
\n\n为任何需求变更设置更高的正式障碍：表格、批准、影响分析、变更管理流程。
与业务用户一起创建最新的路线图，以给出发展方向和重点。这也将为不同的用户提供一种解决其优先事项并就如何使用有限资源达成一致的方法。
找到勇气说 \xe2\x80\x9cno，不是在这个版本中，也可能不会在下一个版本中 \xe2\x80\x9d 并坚持自己的立场。
后者，在巨大的压力下不屈服和同意那些从长远来看会使项目和软件产品陷入危险的变化的勇气是软件开发项目经理工作中最艰难的部分之一。更重要的是，因为您通常不会\xe2\x80\x99 拥有任何硬数据，因此更改的影响可能看起来不确定并且通常可以忽略不计。与建筑或机械工程行业的产品不同，软件本质上是可塑的，做一点点改变对每个人来说似乎没什么大不了的，也可能没什么大不了的，但然后又一个，又一个在上面，很快你就输了原始设计的轨迹。
\n\n开发人员常常对其管理层持批评态度，因为他们允许需求在项目后期发生变化。然而，利益相关者的压力是巨大的，PM 经常感到，即使它只是暗示，就好像他们的工作或职业生涯处于危险之中，在天平的一侧，只是一个问题。另一个人身上有模糊的直觉。
\n\n并不是说根本不应该\xe2\x80\x99 允许进行任何更改，但也有不好的一面，有时更改对于成功至关重要。这一切都在于知道何时屈服以及何时坚定立场。
\n\n关键的管理任务之一是设计开发过程，设计软件开发过程类似于设计软件本身：它\xe2\x80\x99都是为了在相互冲突的需求之间找到良好的权衡，同时保持在限制范围内：
\n\n程序员更喜欢尽早掌握有关手头任务的尽可能多的信息。创建和验证软件设计需要这些需求。后期的更改不受欢迎是有原因的：它们迫使程序员重新评估设计的大部分内容并再次进行验证过程。这需要他们投入大量额外的时间和精力。
开发经理更喜欢根据预先众所周知的稳定需求进行计划。大多数规划技术都假设有很大程度的确定性，至少在中短期内如此。
业务用户希望实现所需更改的交付时间为零，他们\xe2\x80\x99d喜欢并且通常真正需要灵活性来尽可能晚地更改需求。毕竟，这创造了相对于竞争对手的巨大优势。然而，无论企业希望能够在不增加资源的情况下维持甚至提高软件变更率；该企业还假设所交付的任何软件解决方案都将是稳健的。
但这三个群体常常忽视彼此的需求：
\n\n程序员不了解变更将解决的业务紧迫性、机会窗口、竞争优势或合规性威胁。
开发经理一次又一次地严重低估了重新设计所需的工作量；或者只是缺乏勇气阻止商业用户搬起石头砸自己的脚。
业务用户只是不知道交付一个软件所需的交付时间，开发过程从他们所在的位置来看是完全不透明的，事情似乎开始需要越来越长的时间才能发生，最终产品一团糟。
一些技巧：
\n\n始终尽最大努力对优先事项和未完成的工作有一个清晰且最新的概述，否则您\xe2\x80\x99将在开始之前失去任何需求协商\xe2\x80\x94您\xe2\x80\x99将拥有没有事实来争论你的立场或重新谈判时间表，重新洗牌功能，并且别无选择，只能屈服于压力并承诺不可能的事情。因此有：
\n\n最新的时间表。
所有未完成任务的清晰描述（或规格）和估计（即使它\xe2\x80\x99是一个数量级）。
所有未完成的任务以书面形式存储在一个地方。
在项目开始时确定可能更改的需求：
\n\n尽可能晚地安排它们
设定开发团队的期望；解释企业的思维方式和任何现有的限制
旨在提供更通用的功能，认真地从软件中排除任何必然会发生变化并且可以通过其他方式轻松处理的内容。
留意政治要求，即没有任何其他合理解释的要求。
建立清晰的变革管理流程：
\n\n正式的流程将使更改需求变得更加昂贵，因此许多突发奇想不会出现在您的列表中。
当您认为该需求会危及项目时，要有勇气说 \xe2\x80\x9cno\xe2\x80\x9d。
避免过度使用正式流程，它\xe2\x80\x99只是一个工具；不要冒着与最终用户和利益相关者完全失去联系的风险。