项目管理

这个分类涵盖什么

在多人之间规划工作，并跟踪它是否在推进：有负责人和日期的任务、依赖关系、产能、里程碑，以及干系人要求的报表。

它与任务管理之间的界线是真实存在的。一个是安排一个人的一天，另一个是协调几个工作互相依赖的人，正是这种协调，让额外的复杂度有了理由。

个人清单和小团队看板归入任务管理。工时和计费归入工时记录。

让工具匹配工作实际到来的方式

三种模式涵盖了大多数团队，每款产品都偏向其中一种。

持续流动适合不可预测地到来的工作：一块看板、一个队列，以及对在制工作量的限制。迭代交付适合按固定周期规划、有估算、结束时有复盘的团队。计划交付适合有明确日期和依赖关系的工作，一处延误会推迟其后的一切。

给按流动方式工作的团队买一款重计划的产品，会得到没人更新的复杂计划。给建筑工程买一块轻量看板，会错过日期。先确定模式，再评判软件。

物有所值的功能

• 依赖关系，当一件事确实会卡住另一件带日期的事时。
• 产能，在截止日期证明之前，先看出谁已经超负荷。
• 自定义字段和视图，让同一份数据服务多个受众。
• 自动化，处理那些不该由人手工完成的状态变更和交接。
• 报表，面向那些永远不会打开这个工具的人。

清单上的每一项，都要在配置和自律上付出代价。只采用您会持续维护的那些，因为配置到一半的系统，比一份朴素的清单更容易误导人。

能否落地决定一切

这个分类里的失败都是一个样子。计划不再与现实相符，人们退回到聊天和记忆，工具变成一座意图的博物馆。

当更新所花的力气与回报的价值不成比例时，这种情况就会发生。看看移动一个任务、添加一条评论、修改一个日期或交接一件事，各需要多少步操作。看看手机应用能否完成每天最基本的操作。看看通知能否告诉人们发生了什么变化，又不会把他们淹没。

然后在推广之前先定好约定：状态是什么意思，谁负责一个任务，没人认领的工作怎么办。软件不会提供这些，而缺少它们，正是积压清单里躺着四百条无人问津事项的原因。

与团队之外的人协作

客户、外包人员、审计人员和高管通常只需要查看，不需要编辑。

检查访客权限、费用，以及访客默认能看到什么。然后检查面向那些永远不会登录的人的报表，因为一封按周发来的邮件摘要，往往才是真正让干系人了解情况的东西。

审批和校对在代理机构的工作中很重要，同一份文档会来回传递。为这种场景而做的产品，处理起来远好于只有一个评论框的通用工具。

费用，以及它如何增长

按用户按月收费是标准做法，自动化额度、报表深度、权限和单点登录决定档位。

悄悄增长的成本是席位。每个接触项目的人都有一个账号，闲置的账号很少有人清理，一个十二人的团队最终要为二十个席位付费。每季度检查一次。

迁移是另一个要考虑的因素。任务和评论通常可以导出，而附件、自定义字段、自动化和历史记录往往不行。尽早试一次导出，而不是等到要离开的时候，周边的算法见定价页隐藏了什么。

说明您已经超出任务清单的信号

团队转向项目软件往往比应有的时间晚，然后又配置了远超所需的功能。

真正的信号是具体的。两件工作互相等待，没人说得清哪个晚了。有人超负荷，直到截止日期过去才被发现。某位干系人不断要一份状态，而汇总它要花一个小时。

其中任何一条，都足以让额外的结构有理由。没有哪一条要求用上产品提供的全部功能。

先从负责人、日期和一个反映团队实际工作方式的视图开始，等到某个具体问题需要时，再加上依赖关系或产能。配置超出团队维护能力的系统，会产出建立在无人更新的数据之上、却显得信心十足的报表。