The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
这是一个非常简单的管理框架，我们在过去的两年中在我们的团队中使用过。我们通过试验的方式来到它，试图将一些敏捷原则、PMBOK理念和常识融合在一起。我们迄今为止的经验是积极的，尽管工作规则实际上与项目管理无关，而更多地是关注情况并确保不会崩溃。这是大多数现代团队能够承担的最好的方式。
每个小组都有一个团队协调员（TC），通常不是最有知识的专家，而是具有良好组织能力和强烈自律性的人。TC负责我们管理框架的四个基石元素：1）计划，2）周一报告，3）每周电话，4）演示。
我们的计划是一个非常简单的文本文档，对团队中的每个人都可见，通常在谷歌文档中，只有TC才能编辑。它是一个工作分解结构（WBS）和甘特图的简化版本，其中每一行都是一个有形的成果物，例如文件、文档、软件模块、PDF报告等等。计划中不欢迎任务，只接受成果物。例如：
每个文档都有1）一个所有者和2）一个评审人。在第一个文档“需求 v1”中，所有者是Jeff，评审人是Bill。Jeff将确保需求被交付，Bill将检查并确认。所有者不一定是文档的主要贡献者，但他们负责保持交付状态的控制。简而言之，当一个文档按时交付时，我们会“奖励”所有者；当交付延误时，我们也会“责怪”（我知道，大多数人不喜欢这个词）所有者。
每个文档都有一个计划交付日期。日期可能随时更改，但任何时刻计划必须为所有文档定义日期。该列表按日期进行逆排序。
每个文档都有一个主观评估的完成状态，比如上面的第一个文档是“80%”。技术委员会从评审人那里收集这些信息，而不是从所有者那里收集。
一个人最多可以拥有三个文档，最多可以评审四个文档。因此，任何人都只能控制不超过七个文档。
每个星期一上午，技术总监会通过电子邮件向所有团队赞助商发送一份报告：一封纯文本的电子邮件，没有任何附件或花哨的格式。所有利益相关方，包括所有团队成员，也都被抄送。一个例子：
邮件的主题以WEEK13开头，其中13是当前年份中上一个日历周的编号。顺便说一下，几乎每年都有52周。WEEK部分使得报告邮件在收件箱中容易被搜索到。报告还包括一个以逗号分隔的最重要的主题列表，以便让读者对报告的结果有一个快速印象。
上周的成就每个都以动词或过去式开头，比如”fixed”、”added”、”refined”等等。动词后面提到了我们对应的成果。每行的末尾都有一个进展状态，由报告的作者主观评估。无论团队有多大，计划有多详细，成就点都不应超过七个。报告不能讲述完整的故事，只能突出最重要的内容。
在可能的情况下，每个成就项目必须补充一个链接，指向一个拉取请求、文件或文档。必须有可追溯和可验证的东西：报告的读者必须能够找到每个项目的所有必要细节，而无需询问项目的所有者或报告的作者。
每个新周的任务都以不定式形式的动词开头，比如”to publish”或”to review”，然后当然提到了相应的成果。列表中不应超过七个任务。
每个风险以原因-风险-影响的格式呈现，对记者来说，这是保护团队的机会：越多的人了解风险，责备团队的难度就越大，而失败是不可避免的。
每周在相同的时间和日期，我们进行一次30分钟的Zoom状态电话：每个人都参与其中。我们查看计划并讨论我们的工作是否仍然在进展中。我们互相询问：
我们是否正确地分解了范围？
我们的计划中漏掉了什么？
所有的所有者都对他们的日期和范围都有承诺吗？
有任何风险被忽视了吗？
我们不会使用状态电话进行报告。这就是我们有星期一报告的原因。
我们在状态电话上做出的所有决定都称为会议纪要，并通过电子邮件发送给所有人（或在我们的Telegram群聊中发布）。
几乎每周，我们都会要求一位文物所有者在一小时的“演示”Zoom通话中展示他或她的成果。通常情况下，这种情况发生在交付日期临近且所有者准备好展示完整成果时。然而，当文物仍在进行中时，演示通话也非常有用于收集意见。
定期进行演示通话是技术委员会（TC）的责任，每周邀请最重要文物的所有者。
所有状态通话和演示通话都会被录制并发布到YouTube的私人列表中，这样所有团队成员都可以之后观看。
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-12-27 at 10:28
