您如何管理功能请求和软件更改?[关闭]


21

我是一名软件工程师,在过去的几年中,我之所以成为事实上的软件项目经理,仅仅是因为没有人。因此,为了保持我们在研发/工程部门的理智,客户已经习惯了向我提出他们的要求。我没有这个领域的经验,所以这是我第一次担任软件项目的项目经理。我已经管理了其他东西,但没有管理软件。

那么,您如何管理软件项目并标记优先级?请求以不频繁的间隔出现,因此我们很可能会为其他人做某事,然后另一个人来了需要处理的“紧急”工作。只是说“先来先服务”还是更容易赚钱?




1
我用南希·里根的口号:“就说不!” 说真的 切勿当场承诺任何事情。这是软件工程师遇到大麻烦的方法之一。抵制做出随意的承诺,甚至无法估计某件事情是“困难”还是“轻松”,这一点非常重要。始终推迟决策,然后采取一些出色的建议,这些建议将出现在答案中。您的声誉取决于能否兑现您的承诺-一旦您做出过多的承诺,信誉就会大大降低。
Angelo

Answers:


21

我发现,越来越多的客户抱怨他们的请求多么紧急,除非他们自己也是开发人员,否则通常这是一个很好的信号,表明该请求根本不是紧急的。我在大学里的一位教授总是告诉我们不要让紧急事件打断重要事件。

我通常按​​以下顺序对请求进行分类(YMMV):

  1. 与最近的升级或迁移有关的问题(最重要)。
  2. 安全修复程序。
  3. 现有系统的功能已损坏。
  4. RC和Beta功能中的功能已损坏。
  5. 付费功能请求。
  6. 来自大部分用户群的R&D功能请求。
  7. 仅来自一个或两个用户的R&D功能请求。

最后一个实际上需要花费更多时间,因为他们往往是“紧急,昨天我需要”的请求。实际上,用户很少会完全考虑他们的实际需求或它将如何支持他们的业务模型。通常,这些紧急请求一旦发出,最终就会被使用一次或两次而被遗忘。一旦被遗忘,它们将无休止地困扰着安全漏洞和意外后果。


3
您的教授可能希望在一段时间内从象牙塔爬下来。
JeffO

6
他的意思是,很多人让所有引起我们立即注意的注意力分散,使我们无法专注于真正重要的事情。这是几年前的事,所以他的例子是电话。每当他与学生会面时,他都会将手机直接放在语音信箱中。我发现它很好地说明了完整性和效率。
Michael J. Sabal 2010年

4
哇,付费客户的优先级比Beta功能低?
JBR威尔金森

12

我喜欢科维的原则:

  1. QI-重要且紧急
  2. QII-重要但不紧急
  3. QIII-不重要,但紧急
  4. QIV-不重要且不紧急

那是哪里来的
鲁克

第一件事第一(1994)是一本自助书,由史蒂芬·科维(Stephen Covey)和罗杰(A. Roger)和丽贝卡·美林(Rebecca R. Merrill)撰写,en.wikipedia.org
wiki / First_Things_First_%28book%29

@Rook-也在Covey的7个高效人的习惯中列出。很棒的书。

6
  1. 设置功能/错误/请求跟踪系统,并让您的客户/同事提交工单。如果他们没有为此出示罚单,那么您就没有这样做。票证必须足够详细,以便可以执行,并且必须指定“紧急情况”(“我现在需要”与“很高兴”)。
  2. 仔细检查新票证并仔细确定范围。在票证中以美元,开发人员,资源和/或时间输入成本。这是必不可少的。当您的客户看到什么真正会使他们付出什么时,您会在“紧急”字段中看到非常不同的选择。
  3. 每天根据提交的票证及其紧急程度来确定您的日程安排。使时间表对其他人可见,因此很明显您在做什么以及将来是否有空。

+1进行问题跟踪。我以前必须和同事一起做这个。我告诉他们,对我来说真的很重要,这值得他们花5到10分钟才能提交票证。
GSto

3

我见过一些项目,这些项目的需求变更是由重量级变更控制系统管理的。这不好。许多重要的更改不会发生,因为客户不想经历提交更改控制的麻烦,因此该软件无法满足他们的需求。为了避免此过程,“隐藏”中进行了一些小的更改,因此该软件甚至与您认为的功能不符。

相反,我也看到过项目经理认为“反应灵敏”的项目,这意味着让编码人员响应用户的每个请求,这仅意味着您永远无法完成任何核心开发,并且您的代码会成为一堆笨拙的乱码骇客。从本质上来说,您现在没有任何开发人员,但是拥有一支合格的销售工程师团队。

因此,人们可能希望在这两个方面之间都存在良好的情况,并且我希望最适合您的是个人选择和处境。把握每次变更的成本绝对有价值。在Scrum这样的框架中,您可以用故事点表示成本,团队可以权衡每次迭代中所做的工作与可用的总工作量。如果您有产品经理,则可以请该人量化更改或功能请求的预期收益。这通常是根据受保护的收入(如果您不这样做将离开多少客户)和吸引的收入(如果您这样做将吸引多少客户)来实现。这可以帮助确定优先顺序,但也可以反映产品经理的偏见或个人偏爱。


2

这里有些想法...

目前在市场上,可以帮助你,很多软件http://www.fogcreek.com/与FogBugz的,GeneXus美国与XPM http://www.genexususa.com/xpm等。

这就像平衡新功能请求和错误修复以及您自己的想法一样。下个冬天你必须得食物,但今天也要吃饭。

您有时间,资源和范围,尽最大努力。

亨利·福特(Henry Ford)也曾经有句著名的话:“如果我听客户的话,我会给他们更快的一匹马”。

就个人而言:保持活力,不要像您说的那样制定规则……并谨慎对待其他人的规则……它们可能会在上下文中很好地发挥作用,但在您的上下文中却无法发挥作用。


2

我们最终想到的是,我们现在将每两个月召开一次销售/工程会议,以讨论当前项目以及即将到来的或将来的功能要求。销售工程师将成为项目经理,至少他们会与最新产品保持一致。过去,将其传递给Engineering却很容易,而不必理会。这可能会减轻软件工程师的工作负担,并承担销售和管理责任,以明智地利用我们的时间。


1

我工作的公司使用两个主要应用程序,一个称为JIRA的基于Web的工具来处理与项目相关的方面,而我们的服务台系统则通过其RFC功能来处理变更请求


1

到目前为止,我看到的答案是好的。我要特别说明的一件事是,您将不得不善于对某些请求说“不”。

如果允许客户设置紧急度,则紧急度几乎总是“高”(或更高)。

您(您自己还是团队,取决于您的设置)将需要评估这些请求,并根据您自己的标准对它们进行优先级排序。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.