业务需求的灵活性有多大?

谢谢你的提问!由于您的开发过程迭代已经持续了3周,所以解决方案可能不会涉及改进风险管理(例如,将可能更改的需求推送到开发周期的末尾)或期望管理(使您的团队意识到更改是不可避免的)。表)。相反,我建议一些事情:

• 为任何需求变更设置更高的正式障碍:表格、批准、影响分析、变更管理过程。

• 与业务用户一起创建最新的路线图,给出发展方向和重点。这也将为不同的用户提供一种解决其优先事项的方式,并就如何使用有限的资源达成协议。

• 找到勇气说不,不是在这次释放,可能也不是在下一次和你的立场。

后者是软件开发项目经理工作中最困难的部分之一,即在巨大的压力下,敢于不屈服并同意将长期危及项目和软件产品的变更。更重要的是,因为通常不会有任何硬数据,所以更改的影响可能看起来不确定,而且通常可以忽略不计。与建筑或机械工程行业的产品不同,软件天生就具有可塑性,做一点改变对每个人来说似乎都不是什么大事,也可能不是什么大事,但接着是另一个,又是另一个,很快你就失去了原来的设计。

开发人员通常对他们的管理很挑剔,因为他们允许需求在项目的后期发生变化。然而,利益相关者的压力是巨大的,而且PM常常会感觉到,即使这只是暗示,就好像他们的工作或职业受到威胁一样,在天平的一边,在另一边只是一种模糊的直觉。

不要说根本不应该有任何改变,有阴暗的一面,有时候改变对成功至关重要。这一切都是为了知道什么时候该屈服,什么时候该坚定地站在自己的立场上。

关键管理任务之一是设计开发过程,设计软件开发过程类似于设计软件本身:它的全部任务是在相互冲突的需求之间找到良好的折衷,同时保持在约束范围内:

• 程序员更喜欢尽可能早地掌握手头任务的信息。需要这些需求来创建和验证软件设计。而后期的更改之所以不受欢迎是有原因的:它们迫使程序员重新评估设计的大块内容,并再次进行验证过程。这需要他们额外的时间和关心。

• 开发经理更喜欢基于预先众所周知的稳定需求进行计划。大多数规划技术都有很大的确定性,至少在中短期内是这样。

• 业务用户,希望有零提前期来实现所需的更改,他们喜欢并经常会有一个真正的灵活性的需要,以改变要求尽可能晚。毕竟,这比竞争对手创造了巨大的优势。然而,无论业务部门希望能够在不增加资源的情况下保持甚至增加软件更改的速度;业务部门还假设交付的任何软件解决方案都将是健壮的。

但这三个群体往往都忽视了彼此的需要:

• 程序员不知道变更将解决的业务紧迫性、机会之窗、竞争优势或法规遵从性威胁。

• 开发经理一次又一次地严重低估了重新设计所需的努力;或者仅仅是缺乏勇气阻止业务用户自投罗网。

• 业务用户只是不知道交付一个软件所需的交付周期,开发过程从他们所在的位置看是完全不透明的,似乎事情开始需要越来越长的时间才能发生,最终产品是一片混乱。

一些提示:

1. 始终尽最大努力对优先事项和杰出工作有一个清晰的、最新的概述,否则在开始之前,您将失去任何需求协商——您将没有事实来证明您的立场或重新协商计划,重新调整功能,并且将没有其他的选择,只是屈服于压力,答应不可能的事。因此:

   • 最新的日程安排。

   • 所有未完成任务的清晰描述(或规格)和估计(即使是数量级)。

   • 所有未完成的书面任务,存储在一个地方。

2. 在项目开始时,确定可能更改的需求:

   • 安排得越晚越好

   • 设定开发团队的期望;解释业务思考的方式和任何现有的约束

   • 目的是提供一个更通用的功能,严重的重量,从软件中排除任何必然改变,可以很容易地处理其他方式。

   • 注意政治要求,即没有任何其他合理解释的要求。

3. 建立明确的变更管理流程:

   • 正式的流程将使变更需求变得更加昂贵,因此许多突发奇想不会出现在您的列表中。

   • 当您认为需求会危及项目时,请勇敢地说“不”。

   • 避免过分使用正式流程,它只是一个工具;不要冒着与最终用户和利益相关者完全失去联系的风险。

您需要了解一点“敏捷”,并适应需求变化的事实。它们意味着要更改,而您则意味着要生成满足更改的需求的代码。

你不是 曾经 注定要“完成”。这是一个古老的想法,源于错误的想法,即有可能提前、准确地知道需求。它所能做的最好的事情就是知道特定时间点的所有需求。当然,当这些需求被实现时,最初的需求将会随着业务的变化或者世界的变化而改变。

“完成”是一种幻觉。

是的,“他们付钱”是一个合理的论据。

这也是你最好的(也是唯一的)反驳。增加收入和/或减少开支应贴近任何业务人员的核心。

如果你能提出一个对你有利的金钱理由,你将有更好的机会。你必须能够量化他们的决定的影响。

你必须希望你实施的任何敏捷实践都能对公司的财务健康产生预期的积极影响。

祝你好运。

你可以从两个方面着手解决这个问题。

一个是内在的。切换到一种方法,这种方法期望在一段时间内需求会有很多变化,这应该会稍微减少您(和您的团队)的挫败感。现在你想提前三周完成这项工作。有些团队使用1周的迭代来与scrum一起工作,这使得计划更加频繁(每周),但也减少了在迭代期间发生变化的机会。你甚至可以更进一步尝试看板,在看板上你可以随时改变优先级,从工程师的角度来看,这更像是一种秩序,而不是混乱。

另一件事是与商业人士合作。如果他们真的不在乎烧钱,那可能很难,但即使这样你也可以试着 some techniques 将他们不断变化的决策与团队隔离开来(例如,使变更管理非常正式,或者让他们在每次计划另一段时间的工作时组织整个积压工作的优先级)。

精益更多的是关于纪律和避免浪费-这不是一个真正的过程。在我看来,这个问题可能更像是一个沟通问题。换言之,你不重视交给你的决定,认为它们是有效的。你的反应可能会在你的“客户”身上滋生一点敌意,这会变成一种自我挑战。

首先要想到的是,你的“客户”并不愚蠢。你可能觉得很困惑,但要记住,除非你破门而入,否则你需要在一家新公司找到一份新工作,在那里客户可以用你尊重的方式来表达自己的想法。信不信由你——我并不是想在这里严厉,我只是在暗示沟通没有顺畅,在我看来,你好像在说“我得不到我需要的东西”。

你试图改进你的流程是很好的,但是没有流程可以改变这一点:

“我有时觉得自己像是在用砖墙砸脑袋。” “他需要鼓励我们(公司内部)的客户把想法放在他们的需求上,在提供给我的开发团队开始之前,更大的努力确保他们得到了修复。”

…对我说1)你很沮丧,2)你不尊重他们的所作所为。

我以前工作过他们-我讨厌这样。我继续前进-这是我唯一的解决办法。然而,如果你喜欢这份工作,喜欢和你一起工作的人,过程不会解决任何问题——个人技能会。这就是你从一个“开发人员”转变成更专业的人的地方(你已经是了——我只是指一个更大的)。

多了解业务方面。尝试ddd实践和ubiq。这样你就能知道接下来会发生什么,会有什么改变。在这种经济环境下,你不可能有一条漫长的直路——你需要像你的企业一样适应和改变。

祝你好运!

听起来你需要的是采用进化原型。然而,为了帮助你应对他们提出另一个变更请求时的一些感觉,你应该说“是的,但这会延迟项目x天/周/月,并增加成本y金额。”如果他们愿意支付,那么就乐于工作。“他们付钱”是一个合理的理由。

我认为在敏捷中,特别是scrum方法中,迭代或sprint的内容是在一开始就决定的,然后团队将在允许的时间内交付这些内容(您的3周示例是一个很好的例子),然后您将在下一个sprint中检查和调整更改。

没有人喜欢用“已修复”或“已签署”来描述sprint是如何工作的,因为它听起来太老派了,但是sprint内容的约定(比如产品backlog中的一组用户故事)对于每个sprint来说基本上是一样的,只是比n关于敏捷项目。

如果你在几周内连这样的协议都拿不到,那么你的客户真的在烧钱,除了税务注销之外,没有任何正当理由。

“他们在付钱,所以只要照你说的去做,不要争论”是合理的,但会导致一个人想要无意识的工作,因为“为了避免争论,你必须做” 全部的 我的想法。你同意吗?”看看会得到什么样的回应。从某种意义上说,这是一个升级的过程,但有时一个糟糕的“假设”游戏需要完全结束。

可能有一些中间立场,人们可以说,“这是我们现在想要的”,这就是我们所做的,然后提出改进建议。改变需求是这个过程的一部分,因为发现你不知道的东西的唯一方法通常是困难的方法。

一个相反的观点是,团队应该对他们的工作有一种自豪感,如果一次又一次地认为交付的东西是垃圾,那么在某个时候,这将耗尽大多数人的精力。你介意高营业额吗?有些地方可以把人烧死,而有些地方则不太好。你想绕圈子跑还是在大仓鼠轮子上跑一两天?听起来不是很有趣吗?;)

你有一个合理的担心的基础,但关键是要有一些灵活性,事情会发生变化,这样虽然第一个交付物可能会按要求工作,但这不再有效,因此必须做其他事情来代替。我想起了一位前团队负责人曾经告诉我们的话:“90%的代码可能会被丢弃。这只是一种工作方式,接受它。”尽管听起来很悲伤,但在很多工作中却收效甚微,大多数情况下,这似乎是相当真实的。

关于这种自豪感还有一点需要补充 Dale Carnegie's book, "How to Win Friends and Influence People," 其原则之一是“做一个领导者:如何在不冒犯或激起怨恨的情况下改变人们”:

给他们一个好名声。

书中有几个故事说明了这一点。

帮助我们解决这个问题的一件事是,在迭代开始时,我们都坐在一起,回顾我们要做的工作。开发人员、客户、质量保证等。我们讨论并评估我们正在进行的每一项工作。这往往会让客户思考,并减少以后发生的更改的数量。

除此之外,保持迭代时间短,除了在每次迭代后进行更改。这就是敏捷/精益开发的理念。

我发现减少需求变更量的一件事是,每次需求变更或添加新的需求时,都会更改截止日期和成本。当你做出改变而不去考虑如何改变最后期限和成本时,他们会想要这个世界,当他们意识到所有这些改变都有一个附加的价格时,他们通常会更合理。如果最初的要求有问题,不要提供一个时间估计或小时估计,直到你认为你已经回答的主要问题。

关于:

• 他们付钱给我们,所以我们应该照他们说的做

一开始就可以了。但从长远来看,如果客户不被说服采用某种流程,他们会看到质量和生产效率受到影响,几乎可以肯定的是,他们会为此责怪你。

软件公司的工作不是无意识地创造客户要求的东西——这是廉价的亚洲外包团队提供的东西——而是帮助客户弄清楚他们需要什么,在某些情况下 告诉 他们想要什么。

建筑师不希望他的客户告诉他每一扇窗户的确切位置,他的工作是把他们的视野和生产出有用和真实的东西。

编辑- 既然你说他们不在乎提前交货,那么也许你必须 认识到你根本不在开发项目中:你在做研究。 那里没有严格的截止日期,研究也有不同的目标。一般来说,目标不是工作的软件,而仅仅是一个洞察或获得的知识。

因此,如果你衡量的是“获得的洞察力/知识”而不是“开发的产品准备软件”,你可能会做得很好,并且非常享受自己。

如果你不喜欢研究,那就别担心了:建议从你的软件开发项目中去掉那些不确定的东西,然后为它建立一个原型研究项目,并有明确的目标。