小团队项目管理与进度督促：轻量级方法

小团队不需要一个专职PM，但需要一套能自我运转的进度系统。否则就会陷入两种极端：要么放任自流，到deadline才发现什么都没做完；要么每天追问“做完了吗”，把协作变成被动的任务摊派。

我自己踩过的坑不少。最早做独立开发时，一个人无所谓管理，功能写到哪里算哪里，结果一个2周的功能拖了两个月——因为中间被新想法带跑偏了。后来团队扩展到3人，我尝试照搬大公司的Jira+燃尽图+周报模板，结果第二周就有人私下问我：“能不能只告诉我明天该干啥？”

痛过之后，我逐渐摸索出几套轻量级的方法，专门适配2-5人的小团队。核心原则只有一条：用工具代替沟通，用习惯代替催促。下面拆开讲。

从“任务列表”升级为“进度看板”

很多人觉得看板是给开发用的，其实它最大的价值是“可视化瓶颈”。当一个卡片在“进行中”停留超过3天，视觉上就会提醒所有人：这个任务卡住了，该去问问是否需要拉一把。

小团队不需要复杂的列数。我试过最优的列是：

Backlog（待办池，只有优先级，不需要详细拆分）
This Week（本周要进入开发的任务）
In Progress（有人在做）
Review（需要被另外一个人测试或评审）
Done（本周已完成）

每周一我们从Backlog里拉5-7个任务到This Week，所有人一起讨论确认。一旦确认，本周内任何人都不允许往This Week里加新任务，除非有人完成了自己的任务且还有空余容量。这招叫“冻结批次”，用来对抗需求膨胀。

示例： 我做过一个AI写作工具，团队3人（我+后端+设计）。我们会在周日晚上把各自想做的功能写在便利贴上，然后贴在白板上。周一早上花15分钟对齐。后来换成Notion，但保留同样的逻辑。

每日站会：5分钟，问三个问题

站会容易变成流水账汇报，所以需要限制提问结构。我司（其实就几个人）的站会形式：
- 每人1-2分钟。
- 只说三件事：
  1. 昨天做了什么（可交付的单条结果）。
  2. 今天打算做什么（最多两件事）。
  3. 有没有阻碍（说一个需要其他人帮助的点）。

如果某人超过2分钟，我会直接打断：“我们回头再聊细节。”不要觉得残忍，因为所有人都还在等这个信息做自己的下一步决策。

站会不是用来解决问题的，是用来暴露问题的。具体问题放到会后找2-3分钟单独聊。

双周迭代与进度“红绿灯”

我们按两周一个迭代跑。每两周的最后一天下午做一次进度检查，不是为了批评谁，而是为了调整下周的承诺。

检查用一个最简单的红绿灯表：

🟢 绿色：按计划进行，没有重大延误。
🟡 黄色：有风险，需要介入。
🔴 红色：肯定赶不上deadline，需要重新协商范围。

每个任务一列，负责人自己填。如果填了红色，他需要在我的提醒下主动提出新的预期完成时间或放弃某些功能。我不会惩罚填红色的人，但我会问：“下次我们能怎么提前预警？”这样慢慢培养团队对时间的敏感度，而不是恐惧感。

进度督促不靠“催”，靠自动化反馈

小团队最忌讳的就是一个人整天扮演“监工”。我自己的经验是：把督促交给机器。

我们用GitHub Projects做看板，然后写了一个简单的GitHub Action，每天晚上20:00自动检查每个卡片在“In Progress”列停留的天数，如果超过3天，就在团队群发一条通知：

name: Check stalled cards
on:
  schedule:
    - cron: '0 12 * * *'  # UTC 12:00 = 北京时间20:00
jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/github-script@v6
        with:
          script: |
            const { data: cards } = await github.rest.projects.listCards({
              column_id: YOUR_IN_PROGRESS_COLUMN_ID
            });
            const now = new Date();
            cards.forEach(card => {
              const createdAt = new Date(card.created_at);
              const days = (now - createdAt) / (1000*60*60*24);
              if (days > 3) {
                // 在群里发消息（需要额外配置webhook）
                console.log(`Card ${card.note} has been in progress for ${days.toFixed(1)} days`);
              }
            });

这只是一个示例，实际需要配置列ID和webhook。但这种“非人”的提醒，比我去@每个人要有效得多，而且不伤感情。

检查清单：每周一团队的15分钟对齐

我总结了一份检查清单，每次周一开始前由轮值人过一遍（我们每人轮一周）：

本周Backlog里的任务是否都有人认领？
有没有任务在In Progress里超过3天？如果有，是否需要拆分或求助？
Review列里有没有超过2天的卡片？需要尽快清掉。
每个人本周的“不可让渡”时间（如开会、休假）是否标注在日历上？
下周release有什么风险？需要提前做什么准备？

整个清单走完不超过5分钟。如果一切正常，这15分钟就变成了闲聊时间；有问题就快速讨论。

边界：什么时候该放弃“管理”

小团队管理的本质是“降低沟通成本”，而不是“增加控制”。遇到以下情况，我会主动放掉流程：

团队只有一个人：不需要任何流程，自己用TODO文件或便签就够了。
项目处于探索期（比如做一个从未做过的MVP）：站会频率可以降低到每周一次，因为太多未知会导致每日汇报几乎无意义。
团队成员明确表示站会让他们注意力分散，且历史数据显示即使没有站会他们也能按时交付：那就取消，换成每周同步一次。

我记得有一次做一个AI音乐产品，一开始完全不知道什么功能有价值，我们3个人天天改方向。后来我说：“别站会了，你们每周五告诉我你们试了什么、发现了什么就行。”结果第二周有人直接写了一个完整的Demo，方向也明确了。

小团队最大的优势是灵活，不要让流程杀死灵活。

总结

如果你也是5人以下的小团队，可以试试我的这几条基线：

用看板让进度可见，列数不超过5。
站会限时、三问、不解决问题。
双周检查用红绿灯，把预警和责任分离。
自动化反馈代替人工催促。
明确“不管理”的场景，不滥用流程。

这套东西我们用了快两年，迭代了三个版本。最初只有看板，后来加上了红绿灯，再后来加了自动化脚本。工具在变，但内核没变：让团队自己感知进度，而不是被感知。

PaxLee