我是一名软件工程师,在过去的几年中,我之所以成为事实上的软件项目经理,仅仅是因为没有人。因此,为了保持我们在研发/工程部门的理智,客户已经习惯了向我提出他们的要求。我没有这个领域的经验,所以这是我第一次担任软件项目的项目经理。我已经管理了其他东西,但没有管理软件。
那么,您如何管理软件项目并标记优先级?请求以不频繁的间隔出现,因此我们很可能会为其他人做某事,然后另一个人来了需要处理的“紧急”工作。只是说“先来先服务”还是更容易赚钱?
我是一名软件工程师,在过去的几年中,我之所以成为事实上的软件项目经理,仅仅是因为没有人。因此,为了保持我们在研发/工程部门的理智,客户已经习惯了向我提出他们的要求。我没有这个领域的经验,所以这是我第一次担任软件项目的项目经理。我已经管理了其他东西,但没有管理软件。
那么,您如何管理软件项目并标记优先级?请求以不频繁的间隔出现,因此我们很可能会为其他人做某事,然后另一个人来了需要处理的“紧急”工作。只是说“先来先服务”还是更容易赚钱?
Answers:
我发现,越来越多的客户抱怨他们的请求多么紧急,除非他们自己也是开发人员,否则通常这是一个很好的信号,表明该请求根本不是紧急的。我在大学里的一位教授总是告诉我们不要让紧急事件打断重要事件。
我通常按以下顺序对请求进行分类(YMMV):
最后一个实际上需要花费更多时间,因为他们往往是“紧急,昨天我需要”的请求。实际上,用户很少会完全考虑他们的实际需求或它将如何支持他们的业务模型。通常,这些紧急请求一旦发出,最终就会被使用一次或两次而被遗忘。一旦被遗忘,它们将无休止地困扰着安全漏洞和意外后果。
我喜欢的原则:
我见过一些项目,这些项目的需求变更是由重量级变更控制系统管理的。这不好。许多重要的更改不会发生,因为客户不想经历提交更改控制的麻烦,因此该软件无法满足他们的需求。为了避免此过程,“隐藏”中进行了一些小的更改,因此该软件甚至与您认为的功能不符。
相反,我也看到过项目经理认为“反应灵敏”的项目,这意味着让编码人员响应用户的每个请求,这仅意味着您永远无法完成任何核心开发,并且您的代码会成为一堆笨拙的乱码骇客。从本质上来说,您现在没有任何开发人员,但是拥有一支合格的销售工程师团队。
因此,人们可能希望在这两个方面之间都存在良好的情况,并且我希望最适合您的是个人选择和处境。把握每次变更的成本绝对有价值。在Scrum这样的框架中,您可以用故事点表示成本,团队可以权衡每次迭代中所做的工作与可用的总工作量。如果您有产品经理,则可以请该人量化更改或功能请求的预期收益。这通常是根据受保护的收入(如果您不这样做将离开多少客户)和吸引的收入(如果您这样做将吸引多少客户)来实现。这可以帮助确定优先顺序,但也可以反映产品经理的偏见或个人偏爱。
这里有些想法...
目前在市场上,可以帮助你,很多软件http://www.fogcreek.com/与FogBugz的,GeneXus美国与XPM http://www.genexususa.com/xpm等。
这就像平衡新功能请求和错误修复以及您自己的想法一样。下个冬天你必须得食物,但今天也要吃饭。
您有时间,资源和范围,尽最大努力。
亨利·福特(Henry Ford)也曾经有句著名的话:“如果我听客户的话,我会给他们更快的一匹马”。
就个人而言:保持活力,不要像您说的那样制定规则……并谨慎对待其他人的规则……它们可能会在上下文中很好地发挥作用,但在您的上下文中却无法发挥作用。