作者：武云鹏
推荐理由
30+人初创公司，借助飞书任务，实现高效项目管理的心得体会分享。
一、关于我们
我们是一家 30+ 人的初创公司，属于“古典”互联网行业（做 ToC 的 App）。成立一年多的时间，我们的项目管理工具从基于飞书多维表格的甘特图，过渡到自己“魔改”的飞书任务，结合飞书任务相关 OpenApi，目前我们实现了非常自动化的、基于自驱而不是监督的项目管理流程，这样的流程一定程度上让我们的迭代变得更“顺”了、凡事都更有预期了。
二、需求分析
30 多人的公司，主做一款产品，虽然研发人员占比接近一半，但是也不太可能招一个专职项目管理，所以，我们一开始是产品同事借助基于多维表格的甘特图进行项目管理，一个迭代的大概流程是这样的：
明确版本号 -> 收集整理需求 -> 小范围初评明确大致范围 -> 大范围需求评审 -> 研发分工并评估时间 -> 研发编辑某一任务在甘特图上的起终点 -> 进入开发周期 -> 每天早会对照甘特图明确进度和风险 -> 进入测试周期 -> bugfix -> 灰度 -> 发版版版
我们的甘特图大概长这样：
有人觉得清楚吗？我现在看到仍然感觉很头大。
这种基于甘特图的项目管理，本质是“他人”驱动，程序员都非常明白被项目管理追着问有多难受。另外承载了这么多事情的各种状态的表格，一定是需要专人投入心力和时间去维护的，而且这个过程中一定会有很大的沟通成本，比如：
- 研发没有及时标注任务起止时间，得去追着问。
- 需求状态变了但是没有及时修改甘特图里的状态，得早会时现场改。
- 为了达到清晰明确，维护表格的人需要高频的去找每个人问或者经常组织会议。
在大厂中厂，有专门的项目管理去完成这些脏活累活，在我们公司，一开始是产品维护甘特图+主持早会，后来考虑到我作为研发团队负责人，对需求进度可能更清楚（看代码自然会更清楚）、进而可能可以减少早会时挨个问大家进度的时间成本，所以我去承担了这个角色。
在研发负责人做项目管理这样的背景下，我们又过了仍然略显混乱的两个月，总的来说，这样的项目管理方式很不适合我们，它繁琐、基于很多的沟通，大家通常对于甘特图所预期的“Timeline 视图下的清晰明确”，实际上需要付出太多的额外工作，而我自己也不太习惯花太多时间在维护表格上。
三、方案调研
既然不合适我们，那么不破不立，要让项目节奏“顺”起来，除了研发内部的各种优化提升，我也在着手调研其他项目管理方式。
这期间考虑过 Trello（在前公司尝试过在团队内落地 Trello）、飞书工作台里的三方项目管理工具，还回头去看了影视飓风 Tim 一两年前分享的他们如何借助飞书提升人效的视频（用的付费的飞书项目），还去找在大厂做项目管理的朋友聊。最终确立了这个适合我们的、新的方式必须具备的特征：
- 能跟飞书很好的融合，借助 IM让信息自然地流动起来。
- 沟通成本一定要非常少。
- 参与其中的每个人的使用成本要低（成本越低越容易落实）。
最终我们选择了飞书任务。其实在这之前我们也有用飞书任务，不过只是在研发部门群里记录一些待修复 bug 时会去建任务（大多时候是我一个人去建，测试会用 Jira 平台），以及，我自己也会用飞书任务来做我日常工作的 Todo List。
更具体的，我们使用的是飞书的任务清单，就是将一组任务收纳到一个清单里。当然只用清单是不够的，我们还需要在飞书清单的基础上做一些定制化。
四、开发流程
总体的开发分为两部分：
- 定制任务清单，融入项目管理概念。
- 借助飞书任务 OpenApi，完成更自动的项目管理。
先说第一部分，下图是我们的任务看板，一个清单默认是在列表视图，我们形成约定不管什么岗位，大家都只在看板视图下工作。
看板中的每一个任务都是一个具体可执行的事项，比如一个需求开发任务、一个技改任务。
可以看到我们的看板被定义为 7 列（图中标注 1），分别是 Backlog - Todo - Doing - Done - Testing - RC - Released。其中 Backlog 取自 Scrum 方法中的 Product Backlog，即“产品需求池”，用于承载“处于产品内部决议期、尚未进入 PRcD 阶段的需求”；RC 是 Release Candidate，即“做完了、测好了，等待最后提包发布的需求清单”。其他 5 列都是字面意思，无需解释。
图中标注 2 这里的筛选非常有用，可以筛选“负责人是小 A 的所有任务”、或者筛选我们的一个自定义字段“需求类型”中，类型被标记为“技改”的所有任务。
如标注 3 所示，我们的技改是跟需求放在同一个池子里、一起去排期的。
自定义字段示例⬇️
250px|700px|reset
标注 4 需要详细解释一下，类似“班车制”，我们的版本周期是每周一个版本。
具体的，我们会在周五划定需求范围，是否跟班车由这个需求具体的研发来定，最终确定能跟上班车的需求才会进行需求评审，然后周一到周三开发，需求开发完就提测，在周四下班时我们会发公测版本，公测时间是周五到周一，期间我们会修复公测问题，最终在周一提交商店。如标注 4 显示，这个自定义字段的名字是“DDL”，deadline，字段值只有一个“周四交付”或者空白，当一个任务的 DDL 被标记为“周四交付”时，即代表“研发、产品和测试达成一致，研发承诺这个需求会按照测试要求的时间交付，测试承诺会在周四下班前完成 bug 收敛，大家共同承诺这个需求可以在周四交付公测”。
基于这样的 7 个阶段和周四公测机制，我们的需求开发流程是：
- 产品内部进行早期讨论，将可能要做的需求添加到 Backlog
- 产品进一步决议，将 Backlog 里确定即将要做的需求拆分成各端的任务，并且在 Todo 这一列新建任务，指定某一个研发人员为任务负责人（在专人专项的前提下，这一步无需沟通，可以直接指定）
- 周四发完公测包之后，以及周五上午这段时间，产品将新一批的 Todo 任务标记为“周四交付”，并且和具体的研发进行沟通，让研发自己明确这个任务能否周四交付。根据沟通结果，将不能周四交付的任务的 DDL 字段重置为空白。这一步即是让产品明确自己想要下周上的任务，然后通过沟通，大家一起确定哪些是真正能上的
- 周五需求评审，下午研发基本可以进入初步开发
- 周一到周三开发，随时提测，测试跟测
- 周四下班 bug 改完，发公测包
- 回到步骤 3
这样的迭代节奏/方式背后的一些思考和可能的问题：
- 初创公司需要更快的迭代节奏，每周班车好过两周班车，也远远好过先定需求再顺着排时间的方式
- 更短的开发时间意味着更低的协调成本，确保每个人同一时间只做一到两件事，这样前后端的协同就会更容易（对于需要更长时间的大需求，就让相关同事按自己节奏做就行，在我们公司，这样大的需求真的很少，因为数量少，所以也很好跟踪）
- 更短的开发时间也能让产品更好地想清楚“什么是当下最重要的”，以及避免把一个需求一开始就做的大而全，最好的方式是先 MVP 上线验证
- 研发要自己决定并承诺交付时间，并且为自己的承诺负责，通过自己定时间来避免以往项目管理或者产品追着/求着研发砍时间的问题。能力有高低，速度有快慢，但是能够按照自己承诺的时间、有质量地交付，就是一个研发最好的职业素养
- 需要维护好外部用户公测群，确保足够多的人参加公测并暴露问题（自从落实了公测机制，App 质量上再也没有翻过车）
- 测试处于最后一环，的确会更被动，比如研发晚交付压缩了测试时间，我的解法是：1.给测试决定权，如果测试觉得某个功能质量还不稳，那就不发公测；2.给测试隐性的 buffer，原则上是周四交付，事实上周五是发版前的最后 buffer，测试可以在周五继续测。按理说让测试的时间明确下来会更稳当，但我还是认为和“时间”相关的沟通一定会涉及到更多人，进而带来很大成本
在将需求列表、负责人、迭代环节、发版节奏等信息融入到飞书任务清单后，我们清单里的信息量基本等同于甘特图了。一个题外话，我注意到飞书在 11 月的某次更新后，清单除了列表和看板视图，多了一个甘特图视图，然后在稍后的一次更新中，编辑任务时除了 deadline，还可以编辑任务预计开始时间，飞书任务团队和多维表格团队在项目管理的路上双向奔赴啊。
这里我们聊一下飞书任务，在项目管理的背景下，一个飞书任务除了承载需求描述，还天然的有任务创建人（产品）、任务负责人（研发）、任务关注人（测试，不过需要测试手动关注），天然的跟 IM 可以很好地协作，比如研发会收到产品新建任务并指给自己的消息，产品和测试会同时收到某个需求被研发标记为已完成的消息，还天然的起到一个“细节讨论小范围进行”的作用，相关人员可以在任务评论区进行讨论，等等。这些非常自然的 trigger 和最佳实践是多维表格不具备的。
在我们的 7 个阶段和周四公测的机制下，除了飞书任务自身能提供的信息流动，我们还有另外的一些关注点：
- 老板可能要关注周四公测的任务有哪些？它们都处在哪个阶段？
- 产品可能希望自己提的某个任务从 Todo 转到 Doing、或者 Doing 转到 Test 时被通知到。
- 我会关注 bug 改的怎么样了，按期交付稳不稳？已经周四早上了，还有个哪些任务没到 RC？
为了让这些关注点能够得到及时高效的反馈，我计划基于飞书开放平台做一些开发。不过这里遇到一些阻碍，飞书任务相关 API 不会返回自定义分组的信息（就是任务在 Todo 还是 Doing），以及对自定义字段信息返回不全，提了个文档反馈后时不时就刷一下， 从 8 月刷到 10 月，突然有一天发现文档更新了，然后马上投入开发，最终实现了以下功能：
1.当看板中任意一个任务被完成时，在我们最主要的飞书群“项目研发组”里会立刻有一条通知。此时，任务创建人产品和任务关注人测试都会收到飞书任务助手的消息推送，群消息是为了进行更大范围的同步。
清单动态提醒示例⬇️
2.当“周四任务”（即所有 DDL 为“周四交付”的任务、本周我们大家最关心的任务）中的任意一个发生状态变化时，在项目研发组会有一个小报（下图标注 1）。小报会包含总览（标注 2）和最近状态变化的任务（标注 4），另外可以看到处于 Testing 阶段的任务后面会有个 bugfix 进度显示（标注 3），如 1/2 就代表提了两个 bug，目前修复了一个。
注 1：测试提 bug 的方式是在需求任务下建立子任务，并且把负责人指为研发（所以能统计到 bug 修复进度）
注 2：产品临时的需求变更也会在需求任务下建立子任务，这样可以更好地同步到研发和测试，确保不遗漏，并 且自己还能关注到变更需求是否最终落实
注 3：各个任务前面的 emoji 代表了不同的端，☁️ 是后端，🤖 是安卓，🍎 是 iOS，🕸 是 Web，输出时做了分组，排序。
注 4： 交互细节解释，这里之所以把状态变化任务放到卡片消息的最末，是因为卡片可能会很长，如果放在卡片 头部，那么如果要看我们更关注的变更信息，就得往上翻一整个卡片的高度（在手机上几乎一定要往上划）。
项目小报示例⬇️
250px|700px|reset
3.除了状态变化，如果产品新加了一个周四任务，也会有小报发出来，如下图底部所示。这个时候会@相关研发做一个强提醒。
新添加任务提醒⬇️
4.在每天早会前十分钟，会发通知出来让大家更新看板。
早会提醒⬇️
250px|700px|reset
5.当任务的状态变化都公开在群里的时候，早会的作用就更少了，甚至我们可以用一个日报（标注 1）来代替早会，除了任务总览（标注 2），还会把昨天早会到现在，这中间所有发生状态变化的任务都列出来（标注 3），以及昨日新添加任务（标注 4）
日报示例⬇️
在有了这些小报、日报、定时消息之后，大家对需求交付进度都更有预期了。
迭代过程中我们最关键的沟通是产品和研发明确大概的交付时间，确认是否能周四交付。剩下的沟通大都是关于需求细节的，这些沟通是必要、且在任何一种项目管理方式下都无法避免的。尽可能减少非必要的沟通，是我觉得非常非常重要的。
在这样的项目管理机制实际落实的过程中，我鼓励每一个研发都用飞书任务做自己的 Todo List，拿来安排自己的日常工作，毕竟除了看板任务，自己也可以给自己建非公开的、私人的任务，在“工作”这样的场景里，大家应该避免从飞书任务这样一个 Todo List 搬到自己的一个三方工具。这样做是为了让大家能够及时更新状态，产生出跟踪项目进度所需的数据，让系统转起来。以及非常重要的，越容易的事情越好落实，在自己飞书里的 Todo List 里勾一下“已完成”比在会话列表里找到项目管理跟他发一句“xxx 需求我做完了待会打包提测”要容易落实多了。“主动汇报”这种在互联网公司里显得格格不入的行为，如果成本低到无感，那研发也是愿意做的。
这样的项目管理方式带来了信息高效流动和交付结果上的可预期，感受上远比甘特图清楚、及时且省成本。我们的确也取得了不错的实践成果，每到周四下班，绝大多数任务都被搬到了 RC 状态，大家心里都会比较踏实，并且准备迎接周五这个一周里最轻松的一天。
五、实现细节
补充一下相关的实现细节，提供给好奇的、或者想参考的朋友。
- 飞书任务状态变化时发消息到群里。
这里是用飞书开放平台的“新建看板状态观察者”API，拿到群聊的 id，然后将群组设置为看板的观察者，只观察“任务完成”这一个事件。这里无需开发，直接在网页端的 API 调试工具里调一次即可。注：我是这么拿群组 id 的，先把机器人加到群聊了，然后用 API 查机器人所在群聊，可能有更简单的办法。
- 任务状态迁移时发小报到群里。
这个其实没办法监听，只能定期去扫所有任务的状态，自己分类整理找出差异。需要用到的 API 是“分页请求清单内所有任务”、“请求任务详情”、“请求自定义分组详情”等，个别 API 有频控，需要自己控制下。
- 定期发早会提醒。
定期扫清单任务状态、发早会提醒、发项目日报，都是用 python 的 schedule 模块。
- 卡片消息格式化。
msg_type 是 interactive 的消息可以做比较丰富的格式化，有各种组件，也能支持常见 Markdown 语法。要让卡片消息好看有条理，可以先在飞书消息卡片搭建工具里可视化编辑，然后得到对应的 JSON，再填入真实的数据。项目小报卡片的内容比较复杂，所以还是遇到了些问题，用模板引擎尝试了很久拼不出来，代码写的乱糟糟，后来用了个比较有意思的方法，把编辑好的 JSON 贴到 python 文件里，注释掉，用来给 Copilot 作上下文，然后去定义 Markdown、Hr、PlainText、Button 这些能够包含对应属性以及一个 __str__ 方法的类，来获得一些可以 self-description 的组件（感谢 Copilot，这些类的代码都是他写的），最终获得了一种所见即所得的拼装卡片消息的方式，如下：
# ...
status_changed_obj = [] if len(status_changed_tasks) == 0 else [
Hr(),
Markdown("**🎈 昨日状态发生变化**" if for_daily_report else "**🎈 上个周期状态变化**"),
*map(
lambda task: Markdown(
task.platform + (" " if task.platform else '') +
("~~" if task.completed else "") + "[" +
("" if len(task.priority) == 0 else (task.priority + "-"))
+ task.summary + "](" + task.url + ")" +
("~~" if task.completed else "") + " " + task.assignee_name
+ " **<font color='green'> " + status_change_map.get(
task.task_id)[0] + " → " + status_change_map.get(
task.task_id)[1] + " </font>**"),
status_changed_tasks
)
]
# ...
message_template = {
"header": Header(
"turquoise" if for_daily_report else "indigo",
PlainText("🗓 周四任务日报" if for_daily_report else "🎯 周四任务进展")
),
"elements": [
Markdown("**📆 任务总览**"),
*all_status_section_obj,
*status_changed_obj,
*new_added_obj,
Action([
Button(
PlainText("打开看板"),
)
])
]
}
return build_string_from_message_template(message_template)
六、心得体会
作为技术管理者，我更关心技术方面的东西，所以当我去从事一些项目管理方面的工作，并且非常实在、直接的去推动、跟踪大家的日常进度，这个过程还是多多少少引发了一些不适，甚至有一种“工贼”感（虽然作为研发团队负责人，确保交付是我的首要任务），所以在甘特图时期我会选择看大家的 commit log，而不是频繁的去问，因为这样更高效也能让彼此更舒服。
但是不管是项目管理还是技术管理，管理终究是要逆人性的。在新的机制下，大家都会注意到有的同事能力突出，时不时就会播报一条“清单动态：xx 完成了 xxx 任务”，或者他的任务从 Doing 到 Done 到 Testing 到 RC 搬的特别快，也会注意到有的同事交付质量差，处于 Testing 阶段的任务后挂着一个 5/18（代表有 18 个 bug，目前改了 5 个），还会注意到有的同事标记了完成（小报里打上删除线的）的任务又被测试放回了 Doing，因为提测质量不达标。
在以彼此最舒适的、一种 Todo List 一样的、一种不 push deadline 而是让研发自己承诺交付时间这样的接近自驱的方式做项目管理时，我也会考虑让能力突出的人有更多机会涌现出来，以及无法兑现承诺的人能够及时被发现，从而能够尽快跟进，辅助开发，避免影响最终交付。
最理想的公司是所有人都有着较高的职业素养，精诚合作，为自己的产出负责，甚至为业务负责，现实中则是各种混沌复杂，低效沟通无处不在、项目管理尝试落地机制时有的人不拒绝不配合、研发要一边写代码一边给两三个角色汇报等等，项目管理的确是脏活累活，所以我的选择是用代码落实机制，让机制去达成沟通，去促进信息流动，去克服人性，去确保交付。
