去年第四季度，我参与复盘一个跨部门项目：原计划 6 周上线，实际用了 8 周零 3 天。复盘会上大家的第一反应是"执行不力"，但当我拉出任务列表逐条对齐时，发现问题根本不在执行环节。整个项目 137 个任务里，有 41 个任务的负责人字段写着两个以上的人，有 19 个任务从创建到关闭没有留下任何中间状态记录，还有 12 个任务在关闭时的完成标准只写了"开发完成"，验收、灰度、监控埋点、回滚方案，全都没有作为独立任务存在过。
换句话说，这个项目不是做慢了，而是从一开始就没有被拆清楚。跨部门协作里绝大多数"效率问题"，往下挖两层，都会挖到任务拆分上。这篇文章我想把这件事讲透：拆分到底拆什么、拆到什么程度、在系统里怎么落地、不同规模的组织该怎么取舍。
一、先说结论：任务拆分是跨部门效率的第一杠杆
我把过去几年经手的十几个跨部门项目做过一次横向对比，发现一个稳定的规律：项目最终延期与否，和团队执行力强弱的相关性，远低于和任务拆分质量的相关性。执行力强但拆分差的团队，往往在后期花大量时间"救火"；执行力中等但拆分清楚的团队，反而更容易准时交付。
1. 拆分粒度决定协作摩擦系数
跨部门协作的成本，本质上不是沟通次数的成本，而是"等待对齐"的成本。一个任务如果横跨产品和研发两个部门、粒度是"完成支付模块改造"，那么这两个部门之间至少要经历需求确认、方案对齐、联调排期三轮同步。而同一个工作量如果拆成三个有明确输入输出的子任务，同步次数不会增加，单次同步的模糊度却会大幅下降。
我的经验数据是：当一个任务的预计工时超过 5 人天，它的跨部门沟通成本会非线性上升。3 人天的任务，双方一次会议就能说清楚；8 人天的任务，往往要开三次会还在讨论边界。
2. 拆分维度决定责任能否落地
很多团队拆任务是"按人拆"：张三做前端，李四做后端，王五做测试。这种拆法看起来人人有活，实际结果是没有人对最终交付负责。因为按人拆出来的任务，描述的是"谁做什么"，而不是"什么交付物在什么时间点达到什么状态"。
正确的维度是按可独立验收的交付物拆。接口契约文档是一件事，接口实现是一件事，接口联调通过是一件事，三件事可以被同一个人做，但必须是三个任务，因为它们有三个不同的验收信号。
3. 拆分深度决定风险暴露的早晚
我见过最典型的一种失败：一个跨部门项目排期 8 周，前 6 周进展顺利，第 7 周突然发现第三方接口的鉴权方案没谈拢，导致整个集成层要重做。风险不是突然出现的，它从第一天就在那里，只是因为任务拆得不够深，没有人在第 1 周就把它暴露成一个独立的、需要决策的任务。
拆分的深度，本质上是你把不确定性提前货币化的程度。拆得越深，越早看到"这里可能做不完"，而不是在第 7 周才发现。
二、跨部门任务为什么会失控：三个我亲历的场景
讲方法论之前，先把场景讲清楚。下面三个场景都来自我实际参与过的项目，不是假设。
1. 场景一：一个任务挂着三个负责人，等于没人负责
某个中台改造项目里，有一条任务叫"完成用户中心与权限中心的对接"，负责人字段填了三个人：一个产品、一个后端、一个前端。这条任务在系统里躺了 23 天，状态一直是"进行中"。
问起来，三个人都说自己在做。产品说在等后端给字段清单，后端说在等产品确认权限模型，前端说在等接口文档。三个人的"在做"都是被动等待。多负责人任务的真实含义，往往不是"共同承担"，而是"责任稀释"。
2. 场景二：串行链条里的隐形等待
同一个项目里，设计稿交付依赖需求定稿，前端开发依赖设计稿，后端开发依赖接口文档，联调依赖前后端都完成。这是一条纯串行链。我统计过这条链上每个环节的实际等待时长：需求定稿后等设计排期 4 天，设计交付后等前端排期 3 天，接口文档写完到前端开始对接 6 天。
整条链的实际编码时间加起来不到 15 天，等待时间却有 13 天。串行依赖本身不是问题，问题是这些等待从来没有被拆成显式任务，所以没人能看见、也没人能压缩它。
3. 场景三：被"开发完成"吞掉的尾巴
最隐蔽的问题在交付末端。很多团队的任务拆到"开发完成"就停了，后面的代码评审、单测覆盖、测试用例评审、灰度发布、监控配置、回滚预案、文档更新，全部被塞进"开发完成"这个状态里，或者干脆不体现。
结果是：任务看板上 95% 的任务是"已完成"，但项目实际上不了线。一个任务的完成标准如果可以被多种方式解释，它就不是一个可管理的任务。这是我判断拆分质量时最先看的一条。
三、任务拆分的六个常见误区
我把自己和同行踩过的坑做了归类，大致是六个。这六个误区不是并列关系，前两个是认知层，中间两个是方法层，后两个是执行层。
1. 按人头拆，不按交付物拆
按人头拆出来的任务清单，读起来像一份排班表：张三负责接口，李四负责页面，王五负责测试。它回答的是"谁忙"，而不是"什么东西什么时候能交付"。一旦有人请假或者被抽调，整个清单就失去意义。
按交付物拆的任务清单，读起来像一份验收清单：接口契约在周三前冻结，登录链路在周五前联调通过，压测报告在下周二前交付。谁来做可以换，交付物不能换。
2. 把工时当成拆分粒度
"每个任务不超过 8 小时"是很多团队写在规范里的条款。这条规则的问题在于，它把粒度等同于工时，而忽略了任务之间的依赖结构和验收边界。
一个 4 小时的任务如果依赖另一个部门的审批结果，它的实际周期可能是 5 天。反过来，一个 16 小时的独立任务，如果不需要任何人配合，完全可以作为一个整体管理。粒度的正确度量单位是"依赖数"和"验收信号数"，不是工时。
3. 拆到动作级，管理成本反噬
另一个极端是拆得太细。我见过一个团队把"开发登录接口"拆成写 controller、写 service、写 DAO、写单元测试、写接口文档五条任务。结果是每个人每天要更新五次状态，周会上一半时间在读任务标题，管理成本吃掉了拆分带来的收益。
4. 只拆内容，不标依赖
这是跨部门场景里最致命的一条。任务拆得再清楚，如果没有标注"我依赖谁的什么产出"，那么阻塞依然会发生，只是从"不知道要做什么"变成了"知道要做什么但做不了"。
我认为依赖关系应该和任务标题同等重要，甚至是更重要的字段。因为标题影响的是个人效率，依赖影响的是团队效率。
5. 一次性拆到底，不留滚动空间
有的团队喜欢在项目启动会上把 8 周的所有任务全部拆完，拆到第 8 周的某一天下午。这种做法在前两周会给人很强的掌控感，但从第三周开始就会失真，因为需求在变、人在变、外部依赖在变。
我的做法是近两周拆到任务级，第 3-6 周拆到故事级，第 7 周以后只保留里程碑，每周滚动刷新一次。这不是偷懒，而是承认信息量随时间递减。
6. 拆分只发生在会议室，没进系统
最后一条最常见：会开得很好，白板上画得很清楚，会后没有人把拆分结果录入系统。两周后所有人只记得"我们拆过"，但拆成什么样没人说得清。
我坚持的一条规则是：没有进系统的拆分，等于没有拆分。白板和文档只是过程产物，任务管理系统里的任务列表才是唯一事实来源。
四、拆到位的四条判断标准与一个粒度基准
讲完问题，讲我实际使用的一套判断方法。这套方法不新鲜，但落地细节是我改过的，用起来比较顺手。
1. 四个判断标准：可交付、可估算、可验收、可移交
我判断一个任务是否拆到位，看四条。第一条是可交付：这个任务完成时，会产出一个什么东西？如果答不上来，说明它还是个目标，不是任务。
第二条是可估算：团队能给出一个估算区间，而不是"说不准"。说不准通常意味着范围没界定清楚，而不是能力不足。
第三条是可验收：什么人、用什么方式、看到什么结果，算这个任务完成。验收方可以是同部门同事，也可以是下游部门。
第四条是可移交：这个任务完成后，谁接手下一步？如果没人接手，说明它可能是链条的终点，需要单独确认。
2. 粒度基准：1-5 人天的经验区间
我给团队的建议基准是：单个任务控制在 1-5 人天，超过 5 人天必须再拆，低于 0.5 人天的合并到父任务里。这个区间是我在不同规模的团队里反复验证过的。
低于 1 人天的任务，状态更新频率会超过它本身的价值；高于 5 人天的任务，估算误差会快速放大。第 3 周之后，一个 10 人天的任务实际用了 18 人天，这种偏差在跨部门场景里非常常见。
3. 依赖关系的四种类型
我把跨部门任务之间的依赖归纳成四类，不同类型的处理方式完全不同。第一类是交付依赖：我必须等到你的产出才能开始。这类依赖要靠排期错位来消化。
第二类是决策依赖：我需要某个决定才能继续。这类依赖最危险，因为它常常没有明确的责任人。第三类是资源依赖：我们共用同一个人或同一套环境，这是排期问题，不是逻辑问题。
第四类是信息依赖：我不需要等你做完，但需要知道你的口径。这类依赖最容易被忽略，也最容易造成返工。把依赖分类标注，比笼统地写一句"依赖某某"有用得多。
4. 分层结构：从 Epic 到 Subtask
层级不是越深越好。我常用的结构是四层：Epic 表示一个跨部门的业务目标，Story 表示一个可以被验收的交付单元，Task 表示个人在几天内能完成的工作，Subtask 只在确实需要多人协作一个 Task 时才用。
关键点是：Story 这一层必须有跨部门可见性，Task 这一层可以只在部门内部可见。很多团队的协作混乱，根源就是把 Task 当成 Story 在用，导致下游部门看不到上游的进度信号。
五、用 PingCode 做跨部门拆分：一个 8 周项目的完整操作步骤
下面这部分是实操。我选一个我自己深度参与过的项目来讲，涉及产品、前端、后端、测试、运维五个角色，规模在 120 人左右的组织里。
1. 项目背景与失败的第一轮拆分
项目目标是把一套老的订单系统迁移到新架构上，同时不影响线上交易。原计划 8 周。第一轮拆分是在启动会上完成的，方式是产品经理把需求文档拆成 46 条任务，录入某项目管理工具。
两周后我们做了一次健康检查，问题很明显：46 条任务里有 28 条超过 5 人天，有 12 条没有标注依赖，有 9 条任务的验收人是空的。第三周开始出现阻塞，第四周的关键路径上积压了 7 个未启动的任务。
2. 第二轮重构：四步操作步骤
我们停了一天，做了一次彻底的重构。过程分成四步，每一步都有明确的产出物。
- 第一步：按交付物重写任务标题。把"订单查询模块改造"这类标题，改写成"订单查询接口 V2 契约冻结""订单查询接口 V2 实现并单测覆盖 ≥80%""订单查询灰度开关上线并验证"这样的表述。判断标准是：看到标题就知道验收时要看什么。
- 第二步：给每条任务标依赖类型。在 PingCode 的任务详情里用自定义字段标记交付依赖、决策依赖、资源依赖、信息依赖四类，并指定对应的对象任务或决策人。这一步把 41 条隐藏依赖显性化了。
- 第三步：把超过 5 人天的任务全部下拆。下拆后的任务统一控制在 1-4 人天。同时把测试、灰度、监控、回滚这些"尾巴"作为独立任务显式建出来，不再附着在开发任务里。
- 第四步：设置滚动拆分节奏。近两周的任务全部拆到 Task 级并分配到人，第 3-6 周保持在 Story 级，第 7 周之后只保留里程碑。每周一上午做一次 30 分钟的滚动刷新。
这四步做完，任务总数从 46 条变成 138 条，平均粒度从 9.2 人天降到 2.7 人天。任务数量增加三倍，但会议总时长反而下降了。原因是每次会议不需要再讨论"这个东西到底包含什么"。
3. 在系统里怎么落地：几个具体配置
落地过程中，有几个配置对我们帮助很大。第一个是依赖关系的可视化。PingCode 支持在任务之间建立阻塞关系，并且会在看板上高亮被阻塞的任务。这条功能让"我卡住了"从一句口头抱怨变成了一个可见的红色标记。
第二个是自定义字段。我们加了三个字段：依赖类型、验收人、完成标准。这三个字段在默认模板里是没有的，但它们是跨部门协作的最小信息集。
第三个是状态流转的约束。我们设置了一条规则：任务从"进行中"流转到"已完成"时，必须填写完成标准和验收人，否则不允许流转。这条硬约束把"随手关闭任务"的行为直接掐掉了。
如果需要通过接口批量创建和更新任务，PingCode 的开放接口可以这样用：
POST /open/v1/task
Content-Type: application/json
{
"title": "订单查询接口 V2 契约冻结",
"parent_id": "STORY-1042",
"assignee": "user_zhang",
"estimate_hours": 16,
"custom_fields": {
"dependency_type": "决策依赖",
"dependency_target": "DEC-0031 分库分表方案评审",
"acceptance_owner": "user_li",
"done_criteria": "契约文档评审通过并归档至接口平台"
},
"blocked_by": ["TASK-1077"]
}
批量导入的时候，我们把这个模板写成了一个 CSV，产品经理只需要填标题、父级、负责人、人天和依赖对象五列，脚本负责生成和调用。这样做的收益是：拆分的规范化不再依赖个人习惯，而是依赖模板和接口约束。
4. 重构前后的数据对比
重构后项目最终在第 7 周零 4 天上线，比原计划提前了 1 天。这个结果本身不算惊艳，但过程中的几个指标变化很明显。
5. 为什么这类组织更适合用平台而不是轻量工具
这个项目所在的组织规模在 100 人以上，涉及五个部门。这种规模下，轻量的看板工具会很快遇到天花板：跨项目的依赖无法表达、权限粒度不够、审计和合规要求满足不了、数据无法沉淀。
PingCode 主要服务中大型企业及 100 人以上组织，这个定位在实操中体现得很明显。它支持私有化部署，对金融、制造这类对数据落地有硬要求的企业是必要条件；同时支持从 Jira 平滑迁移，字段映射、历史数据、工作流都能带过来，这一点在我参与过的两次迁移里都验证过。
对正在做国产替代选型的团队来说，迁移成本往往是最大的隐性阻力。我的经验是：迁移的难点从来不是数据本身，而是工作流习惯的重新对齐。所以选型时不要只看字段能不能导入，要看工作流能不能用原来的方式表达出来。
六、不同情况下的行动建议
拆分方法没有唯一解，关键是和你的组织规模、协作模式匹配。下面按四种常见情况给建议。
1. 20-50 人团队：先解决显性化，别急着建规范
这个规模的团队，最大的问题通常不是拆分方法不对，而是拆分根本没有被记录下来。建议第一步只做一件事：把所有超过 3 人天的任务强制下拆，并且每条任务必须有验收人。
不要一上来就引入四类依赖、自定义字段、状态机约束这些东西。规模小的时候，人对人的直接沟通效率高于任何流程。等出现"同一类问题连续三次以上"的时候，再把对应规则固化。
2. 100 人以上组织：拆分规则必须进入系统约束
规模上来之后，靠自觉一定会失效。这个阶段需要把拆分规则做进工具里：任务模板强制包含完成标准字段，状态流转必须校验验收人，超期任务自动升级提醒。
同时建议指定一个"拆分规范负责人"的角色，不一定是管理者，可以是资深的项目经理或技术负责人。这个角色的职责是每周抽查一批任务，看拆分质量是否达标，并在周会上反馈典型问题。
3. 强依赖型跨部门项目：先画依赖图，再排任务
如果你的项目有大量跨部门串行依赖，不要从任务清单开始，要从依赖图开始。把每个部门的关键交付物列出来，画出谁等谁，找出关键路径上的最长链条。
找到关键路径之后，再对路径上的任务做重点拆分，要求这些任务的粒度比非关键路径更细。因为关键路径上每省一天，项目就提前一天；非关键路径上省三天，项目一天都不会提前。
4. 需求高频变更型项目：缩短拆分视野，提高刷新频率
需求一周变三次的项目，把 8 周拆到底是没有意义的。这类项目建议把拆分视野压缩到 1-2 周，每周做两次滚动刷新。同时把变更本身作为一类任务显性管理，记录变更原因、影响范围、受影响的既有任务。
我们团队的做法是在 PingCode 里单独建一个"变更登记"的任务类型，每次变更都建一条，关联到受影响的任务上。这样做的价值不是管控，而是让变更的成本可见。很多团队以为变更是免费的，看到累积成本之后，讨论会理性很多。
七、不同情况下的取舍
最后讲取舍。上面所有建议都不是无条件成立的，下面四组取舍是我在实际项目里反复权衡的。
1. 粒度：细 vs 粗
细的收益是可预测性高、阻塞暴露早、责任清晰；代价是管理成本上升、更新频率高、容易陷入事务主义。粗的收益是管理轻、灵活度高；代价是估算失准、风险暴露晚、责任模糊。
我的取舍原则是：靠近交付末端的任务拆细，靠近前期的探索型任务拆粗。因为前期本来就不确定，拆细了也是假的精确；末端的不确定性已经很低，拆细才能真正管住质量。
2. 拆分权：集中 vs 分布
集中拆分（由项目经理统一下拆）的好处是结构一致、口径统一；坏处是拆分质量取决于一个人的理解深度，而且很容易变成"替别人做计划"。
分布式拆分（由各环节负责人自己拆自己的部分）的好处是贴近实际、可执行性高；坏处是容易出现粒度不一致、依赖断点。我的折中是：结构由项目经理定，内容由执行人填，依赖由双方共同确认。
3. 工具：轻量协作工具 vs 专业项目管理平台
轻量工具上手快、成本低，适合 30 人以下、项目边界清晰的团队。但它在跨部门依赖表达、权限管理、数据沉淀、审计合规上存在明显天花板。
专业平台的能力更强，但配置复杂度也更高，需要有人真正把它配好。最常见的失败不是选错工具，而是选对了工具但没配好。我见过的失败案例里，工具本身的功能往往只用了不到三成。
4. 部署：SaaS vs 私有化
SaaS 的优点是开箱即用、升级无感、初始成本低。私有化的优点是数据可控、可深度定制、满足合规要求，代价是需要运维投入和升级周期。
我的判断标准是：如果数据合规是硬约束（比如涉及金融、医疗、制造的核心业务数据），私有化就是必选项，不需要讨论。如果不是硬约束，先用 SaaS 跑通流程，等流程稳定、团队规模上来之后再评估迁移。PingCode 这两种模式都支持，迁移时可以保留既有工作流结构，这对处于高速扩张期的组织比较友好。
结语：拆分能力是跨部门协作的底层能力
回到开头那个延期的项目。后来我们重构了拆分方式，下一个类似规模的项目在第 7 周零 4 天上线。变化不在于团队更努力了，而在于不确定性被提前拆成了可见的、可分配的任务。
我对这件事的核心判断是：任务拆分不是项目管理里的一个技巧，它是跨部门协作的底层能力。因为它同时解决三个问题，谁负责什么、什么时候能看到风险、以及用什么标准判断做完了。这三个问题解决不了，再多的沟通机制和协作工具都是在给低效打补丁。
如果你想从今天开始改，我的建议是按这个顺序做三步：
- 今天：打开你现在正在进行的项目，把所有超过 5 人天的任务挑出来，逐条回答"完成时交付什么、谁来验收"两个问题。答不上来的，这条任务就需要重拆。
- 本周：给你团队的任务模板加上三个字段，完成标准、验收人、依赖对象，并且设置成必填。这一步的投入产出比最高。
- 本月：建立滚动拆分节奏，近两周拆到任务级，每周固定刷新一次。观察四周，看阻塞的发现时间是否提前、周会时长是否下降。
三步做完，你大概率会发现：真正卡住跨部门效率的，从来不是谁不配合，而是没有人把"要做的事"拆成"能看见的事"。
常见问题解答（FAQ）
1. 任务拆分到什么颗粒度才算合适？
我以前总觉得任务拆得越细越好，结果在跨部门项目里列了上百条子任务，每天光维护状态就花掉一小时，团队反而更乱了。后来我就很困惑：到底拆到多细才是刚好？
用“2-8小时可交付、可独立验收”作为颗粒度基准。具体做法是：先判断这个子任务能否由一个人在一个工作日内完成并产出可检查的结果（文档、代码提交、设计稿、测试结论），能就停，不能再往下拆。跨部门协作时更关键的是让每个子任务只归属一个责任人，如果需要两个人同时负责，说明还没拆干净。
经验数据：一个 5 人跨部门项目，迭代周期两周，子任务总数控制在 40-80 条比较健康，超过 120 条基本意味着颗粒度太细、维护成本反超收益。判断依据很简单，如果某条子任务的状态一周都没人更新，它要么太细，要么责任人不明确，应该合并或重新指派。
2. 跨部门任务拆分时，接口和依赖关系怎么处理才不扯皮？
我们做跨部门项目最头疼的不是活多，而是 A 部门等 B 部门的接口，B 部门又等 C 部门的数据，最后谁都没动。我被这种事坑过好几次，想知道拆分的时候怎么把依赖关系显性化，别到执行阶段才发现卡住了。
做法是在拆分阶段就为每条跨部门子任务标注“输入物”和“输出物”两个字段。输入物写清楚它需要谁提供什么（比如“需要数据组提供 8 月订单明细表”），输出物写清楚它交付什么格式（比如“输出可导入的 CSV，含 12 个字段”）。然后在项目管理工具里把这些依赖连成前置任务关系，而不是只写在备注里。
判断依据：凡是跨越两个及以上部门的子任务，如果没有明确的输入物和输出物定义，一律视为高风险，必须在迭代开始前拉一次 15 分钟的接口对齐会。经验上，跨部门依赖不超过两级（A→B→C）还能靠例会盯住，超过三级就要拆成独立里程碑并指定一个接口人统一收口，否则信息会在传递中丢失。
3. 任务拆分后，怎么保证跨部门团队真的按计划推进而不是各干各的？
我参与过一个六个部门协作的项目，任务拆得挺漂亮，但执行起来各做各的，进度表上看着都是绿的，最后交付却延期了两周。我一直在想，拆分之后到底靠什么机制让大家对齐，而不是拆完就散。
靠三个机制：每日站会同步阻塞、每周依赖复查、以及统一的进度口径。具体做法是每天 15 分钟站会只问两个问题，“昨天完成了什么”和“现在被什么卡住”，卡点当场指派跟进人；每周固定一次依赖复查，专门看那些跨部门的输入物有没有按时到位，而不是只看自己部门的任务状态。
进度口径要统一为“完成=输出物已交付并被下游确认”，而不是“我这边做完了”。判断依据：跨部门项目延期的主因通常不是某个任务做得慢，而是下游在等上游却没人上报阻塞。经验数据是，坚持每日站会暴露阻塞的团队，跨部门依赖导致的延期平均能减少 30%-40%。
如果团队超过 15 人，站会改为按依赖链分组开，否则会变成念流水账。
4. 有没有一套可以照着走的任务拆分操作步骤？
我不太想要那种“先分解再执行”的空话，我想要一套具体的、第一次做跨部门项目就能照着走的步骤。我们团队现在正准备启动一个新项目，我想在开始前把拆分这件事做对，避免后面返工。
可以按五步走。第一步，先用一句话写清楚项目最终交付物是什么、验收标准是什么，写在最显眼的位置。第二步，按“交付物倒推”列出一级里程碑，通常 3-5 个，每个里程碑对应一个可检查的成果。第三步，把每个里程碑拆成子任务，套用“一个人、一个工作日、一个可验收输出”的规则，同时标注责任部门和输入输出物。
第四步，把所有跨部门依赖连线，标出关键路径，关键路径上的任务优先安排资源和提前启动。第五步，设定复盘节点，每个里程碑结束后花 20 分钟检查拆分是否合理，颗粒度不对就当场调整。判断依据是，拆分质量不看任务条数，而看关键路径是否清晰、每条任务是否有唯一责任人和明确输出。
第一次执行时建议把步骤三和步骤四的结果发给所有参与部门确认一遍，确认成本远低于后期返工成本。项目管理平台在这里的作用只是承载这些字段和依赖关系，真正决定成败的是拆分逻辑本身。
核心关键词
文章包含AI辅助创作：任务管理如何做好任务拆分？跨部门团队效率提升与操作步骤，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/352498
读者评论
给任务加前置依赖这件事我试过，前两周还能坚持，第三周开始就没人更新了。跨部门的产出时间本身就常变，依赖一改就连锁调整，维护成本比想象的高。后来改成只标“阻塞项”和“在等谁”，反而活得久一点。想问的是，依赖关系在系统里能自动刷新吗，还是只能靠人手动维护？如果是后者，节奏快的团队大概撑不过一个月。
人天这个基准感觉偏研发视角。设计和测试的任务很难按人天估，一张界面稿可能两小时也可能来回改三天，审批类任务更是按日历天走的。硬套这个区间，容易为了合规把任务拆得没有意义。可能更实际的是按职能给不同基准，或者至少把等待时长和工作时长分开记录，不然估算准确度那几条曲线放到非研发任务上会失真。
没进系统等于没拆分”我部分同意，但觉得有前提。我们十几人的团队任务录得挺全，实际推进还是靠口头同步，因为系统更新总滞后半天到一天，看板反而制造了“都完成了”的假象。真正有用的是站会前把状态对一遍，系统只负责留痕。所以关键也许不是有没有进系统，而是谁在什么时候负责把状态改对，这个责任不定，工具再规范也白搭。