学习作为软件项目经理应该掌握的每周惯例(作为项目经理,你需要给一个软件项目做计划安排)

这篇文章概述了项目经理的每周生活,包括里程碑标识、项目计划、风险注册和项目更新等待办事项

每天‬分享‬最新‬软件‬开发‬,Devops,敏捷‬,测试‬以及‬项目‬管理‬最新‬,最热门‬的‬文章‬,每天‬花‬3分钟‬学习‬何乐而不为‬,希望‬大家‬点赞‬,加‬关注‬,你的‬支持‬是我‬最大‬的‬动力‬。
今天,我想报道一个项目经理的每周生活。当我管理一个项目的时候,我每周都会做这些事情:

  1. 确定下一个里程碑.你有一个不到一个月的目标吗?如果没有,尽快编一个。在与团队的每次会议中讨论下一个里程碑
  2. 更新项目计划. 每周五安排一到两个小时来回顾和更新你的项目计划
  3. 更新您的风险注册表.在您的项目计划时间,更新您的风险注册表
  4. 发送每周项目更新. 在更新了项目计划和风险注册表之后,我发送了一个更新,它总结了我负责的所有项目的情况

把这些事情放在一起通常需要开会或者对话,但是对于你每周要交付的东西有一个具体的想法可以让你更清楚地关注什么。

1. 确定下一个里程碑

当人们朝着一个目标努力的时候,他们的工作表现最好,这个目标很接近,也很容易让他们的头脑接受。当他们在不到一个月的时间里完成一个里程碑时,他们会更加投入,更有效率,更有效率。这也将复杂性分割成可以管理的块。人们可以对那么多工作进行推理。他们的工作效率更高。

大多数时候,您应该已经确定了下一个里程碑。太棒了!然而,您通常会接近完成这个里程碑,项目中的事情会发生变化,或者项目不会被分解到足够的程度,以便很快就有一个里程碑。

学习作为软件项目经理应该掌握的每周惯例(作为项目经理,你需要给一个软件项目做计划安排)

为什么是一个月,而不是迟早?简短的回答是,这是我自己的经验和我所看到的一些有限数据的证据所显示的。你可以在我关于里程碑的文章中读到更多关于这方面的内容,而不是项目。

我建议让产品经理、设计师和那些对项目的技术轮廓考虑最多的人在一个房间里,并告诉他们你想要确定一个里程碑: “最好的里程碑是什么?让我们想出一些可能性,然后选择一个我们最喜欢的。”

开始约束,你总是需要一个里程碑,不到一个月的时间。如果您没有,或者您即将完成一个里程碑,请确保您已经确定了下一个里程碑。参考那篇里程碑文章来学习更多关于拆分项目的艺术,并且记住这是一个真正的技能,需要时间和练习来发展。

2. 更新项目计划

我每周预定时间更新我的项目。我回顾项目计划,并确保它反映了我目前的想法。我问自己这是否看起来仍然现实。我通过项目的剩余部分来思考延迟和风险的潜在来源。

一厢情愿是你的敌人。从怀疑的角度看待一切。对一些人来说,这是很自然的,而对另一些人来说,这需要练习。

为了更新项目计划,您经常需要其他人提供的信息。我通常为每个团队或每个项目安排每周一次的会议。在这次会议上,我邀请了主要领导人出席,让他们详细了解接下来几周的情况,向他们展示我目前对项目计划的想法,并请他们对计划提出批评意见。然后我会穿越到更远的未来,但是在更远的未来,我们会少一点忠诚。通常,我会邀请代表产品、技术领导和设计的人。

尽量让这些会议保持高水平。你希望他们不要成为参与者的一个巨大的时间浪费。我经常发现最好参加一个有更大目标的会议。例如,一个本地团队的领导会议可能每周用5-10分钟来讨论这个问题,但是我们的大部分时间可能会讨论其他事情,比如我们关心或需要改进的事情。

项目经理的一个反模式是,您可以养成一直向人们发送 ping 信息的习惯。这最多算是烦人。让人们不费吹灰之力就能知道你的情况。同时也鼓励人们把他们观察到的东西表现出来,这样你就不用更新他们的信息了。切换通信推从拉更好。

项目计划应该是什么样子的?

我每周都制定项目计划。每周都有几个要点。要点是我们计划在那周演示的内容。演示应该包括技术演示,但是我们将交付的描述应该尽可能以客户为中心。

我还添加了与项目交付相关的基于时间的事件。例如,休假时间、待命时间表和异地。

学习作为软件项目经理应该掌握的每周惯例(作为项目经理,你需要给一个软件项目做计划安排)

项目计划的目标是不要比几个要点更具体。你想要一个容易改变的计划。您的项目越具体,更改它的成本就越高。一个好的项目计划应该是一个讨论的工具,一个鼓励变更而不是阻止变更的工具。当我看到许多项目工件,以及需要更新的东西时,我会持怀疑态度。甘特图有效地沟通,但往往是一个迹象,基础数据是难以改变。

需要注意的一件事是,许多工程团队在每个项目中都针对一个人进行工作。您越能将团队用作项目的交付单元,效果就越好。这是一个更深层次的话题,所以我现在不会详述太多细节,但总的来说,当我看到详细说明每个人正在做什么的项目计划时,我认为这是一个迹象,表明项目是不必要的脆弱,一个团队过于专业化,没有做足够的知识共享。这对小公司来说可能是合适的,但在其他方面,我倾向于不鼓励这种做法。如果我在一个项目中看到“资源”的分配,我通常会尖叫,从包里拿出打火机,把头发点着,然后跑出房间。你管理的项目越少,你就能更好地利用它们,所以这是团队关注更少项目的另一个理由。

如果你所在的团队有两个星期的冲刺,人们会问你是否需要一个一周一周的项目计划。当然,这取决于你,但我会一周一周地做。否则,你就很难看到事情是否按计划进行。如果我是在一个为期两周的冲刺节奏上做这件事,我会告诉团队,这是一个计划,表明我们是否可以在每周五之前演示它。

你的风险注册处应该是什么样子的?

当你更新你的项目计划时,你也应该问问你自己什么地方可能会出错。这里有一些方法可以问你自己或者其他人一些问题,这些问题可以帮助你更好的计划:

  • 这个项目最有可能出错的地方是什么?
  • 过去有哪些类似的项目? 我们面临哪些挑战?
  • 在这个项目中,最坏的情况是什么?
  • 如果我们必须把这个月的薪水都压在这个项目上,我们现在会担心什么呢?

风险管理是一种平衡行为。你不想过度投资你的许多风险,但你确实想通过他们。在你想出新的风险后,把它们列在你的风险登记表的要点上。

学习作为软件项目经理应该掌握的每周惯例(作为项目经理,你需要给一个软件项目做计划安排)

对于每个风险,您或您的领导团队应该决定是否要采取任何行动来减轻这种风险。在风险登记表的旁边,列出你的计划,或者写下“接受风险”

如果你的领导团队运作良好,你可以就风险和降低风险的成本进行理性的讨论。我建议,当你引入一个风险注册中心时,你应该讨论一下缓解风险的成本,并且确保不仅要讨论如何缓解风险,还要讨论你是否想这么做。

每周写一次项目更新

在更新了我的项目计划和风险注册表之后,我对项目的当前状态有了一个很好的了解。现在我通过分享这种状态来帮助我周围的人,尽可能简明扼要。

每周项目更新的目的不是分享项目的所有信息。也不是为了显示你的团队有多棒。当你从这两个角度来看待项目更新的时候,你的文章读起来会很痛苦。相反,你应该关注读者的需求,给他们足够的信息,让他们在需要的时候可以来找你,进行更长时间的对话。

这条推文总结了我这些年来学到的关于写出简洁、可读的更新的很多东西。它还有一些很棒的例子,所以我强烈建议你通读一下:

学习作为软件项目经理应该掌握的每周惯例(作为项目经理,你需要给一个软件项目做计划安排)

我想强调的一点是,你应该给人一种中立的印象: 客观、坦率地承担风险、毫无偏见地揭露事情。

您的更新应该包括指向信息源的链接: 项目计划、风险注册表和演示项目当前状态的链接。

在您编写更新之后,将其发送给您的利益相关者。您可以使用 Slack 中的邮件列表或频道。你想让新人更容易跟踪信息。你可能会惊讶谁会觉得它有用。您可能会发现公司的其他部门认为您的更新很有用。

这些更新帮助你周围的人更有效率。你的经理会被告知项目的状态,这样他们就可以在会议上代表你的工作(你不知道这对他们有多大帮助)。其他依赖您的团队不必联系您来获取更新。它提供了一个非常好的通信支架。你甚至可能会收到感谢信!

顺便说一句,这些更新有助于展示您管理项目的能力。

我发现项目更新对于完成剩余的项目管理是一个很好的强制功能。知道自己必须每周更新信息,这迫使我花时间去做其他事情。

理想情况下,更新应该只有一两条 tweet 的长度。你不需要很多细节: 如果人们有问题,他们可以和你交谈。

谢谢你

我在项目管理方面有很长的历史,甚至在过去编写过项目管理软件,但是 Bjorn Freeman-Benson 确实向我灌输了如何编写一个好的更新的细节。他担任编辑,每周训练我如何做得更好。

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。

(0)
上一篇 2022年7月16日 上午11:05
下一篇 2022年7月16日 上午11:07

相关推荐