这是一个非常简单的管理框架，在过去的两年里，我们一直在我们的团队中使用。我们是通过实验得出的，试图将一些敏捷原则、PMBOK思想和常识融合在一起。到目前为止，我们的经验是积极的，尽管所提出的工作规则并不是真正意义上的项目管理，而是更多的关注情况，确保它不会崩溃。无论如何，这是大多数现代团队所能承受的最好结果。
每个小组都有一个团队协调员（TC），他通常不是知识最丰富的专家，而是具有良好组织能力和强烈自律的人。TC负责我们管理框架的四个基石要素。 1）计划，2）周一报告，3）每周电话，和4）演示。
计划
我们的计划是一个非常简单的文本文件，对团队中的每个人都是可见的，通常是在Google Docs中，只有TC可以编辑。 它是一个原始版本的工作分解结构（WBS）与甘特图的结合，其中每一行都是一个有形的工件，如一个文件，一个文档，一个软件模块，一个PDF报告，等等。计划中不欢迎任务，只欢迎人工制品,一个例子:
- Requirements v1 [Jeff+Bill, 25-Aug, 80%]
- Dataset with 500+ files [Anna+Jeff, 3-Sep, 100%]
- XYZ module deployed [John+Jeff, 14-Sep, 50%]
- Database redesign [Bill+Mary, 27-Sep, 20%]
- ABC package released [Jeff+Mary, 1-Oct, 0%]
- Report on data analysis [Jeff+Anna, 5-Oct, 10%]
每个工件都有1）一个所有者和2）一个审查者。 在第一个工件 "需求 v1"中，所有者是Jeff，审查者是Bill。Jeff将确保需求被交付，Bill将检查并确认。 所有者不一定是他们工件的主要贡献者，但他们有责任保持交付状态的控制。 简单地说，当一个工件按时交付时，我们会奖励所有者；当交付失败时，我们也会责备（我知道，你们大多数人不喜欢这个词）所有者。
每个工件都有一个计划的交付日期。日期可以根据需要经常改变，但是在任何时候，计划都必须为所有的工件定义日期。 列表是按照日期反向排序的。
每个工件都有一个主观测量的完成状态，比如上面第一个工件的 "80%"。TC从审查者而不是所有者那里收集这些信息。
一个人可以拥有不超过三个工件，并且可以审查不超过四个。因此，任何人都被允许控制不超过七个工件。
周一报告
每周一上午，TC通过电子邮件向所有团队发起人发送一份报告：纯文本的电子邮件，没有任何附件或花哨的格式。所有的利益相关者，包括所有的团队成员，也会被抄送,一个例子:
From: Team Coordinator
To: Big Boss
CC: Programmer #1, Programmer #2, Friend #1, etc.
Subject: WEEK13 Dataset, Requirements, XYZ
Hi all,
Last week achievements:
- Added 100 new files to the Dataset [100%]
- Fixed the deployment of XYZ [50%]
- Refined the requirements [80%]
Next week plans:
- To publish ABC package draft
- To review first draft of the report
Risks:
- The server is weak, we may fail the delivery
of the dataset, report milestone will be missed.
Bye.
电子邮件的主题以WEEK13 开始，其中13是当年前一个日历周的数字。顺便说一下，几乎每年都有52周。WEEK ，使报告邮件在收件箱中很容易被搜索到。还有一个以逗号分隔的报告最重要主题的列表，让读者对报告的结果有一个快速的印象。
上周的每项成果都以一个动词或过去式开始，如 "固定"、"增加"、"完善 "等。在动词之后，会提到我们所做的贡献的人工制品。在每一行的末尾都有一个进度状态，由报告的作者主观衡量。不管团队有多大，计划有多详细，都不应该有超过七个成就点。报告不能讲述完整的故事，而只能强调最重要的内容。
只要有可能，每个成就项目都必须补充一个链接，指向一个拉动请求，或一个文件，或一个文档。 必须有一些可追溯和可验证的东西：报告的读者必须能够找到每个项目的所有必要细节，而不需要询问其所有者或报告的作者。
新一周的每项任务都以不定式动词开始，如 "发布 "或 "审查"，然后当然会提到人工制品。列表中的任务不应超过七个。
每一个风险，以"因果"-"风险"-"影响 "的形式，都是报告者保护团队的机会：人们知道的风险越多，就越难在失败时责怪团队，而失败是不可避免的。
每周通话
每周在相同的时间和日期，我们进行30分钟的Zoom状态电话会议：每个人都参加。 我们看一下计划，讨论我们的工作是否还在轨道上, 我们互相询问:
- 所有交付的工件是否意味着成功？
- 我们是否正确地分解了范围？
- 我们在计划中错过了什么？
- 所有的人都致力于他们的日期和范围吗？
- 是否有任何风险被忽略了？
我们不使用状态电话来报告。这就是我们周一报告的目的。
我们把在状态会议上做出的所有决定称为会议纪要，并通过电子邮件发给大家（或在Telegram群组聊天中发布）。
演示
几乎每周我们都会要求一些工件所有者在一个小时的 "演示 "Zoom电话会议上展示他或她的成果。通常情况下，它发生在交付日期临近和所有者准备展示完整的东西时。然而，演示电话对于收集意见也是非常有用的，当一个工件仍在进行中。
TC的责任是每周定期进行演示电话，邀请最重要的工件的所有者参加。
所有的状态电话和演示电话都被记录下来，并发布到YouTube上的一个私人列表中，所有的团队成员都可以在以后观看。
