团队日程

团队一周工作的管理视图:按人员划分的需求、可用产能×已分配工时以及SLA指标。及时发现超负荷情况并在延误前重新分配。

团队手上有多少工作、谁超负荷、谁闲置、交付了什么、其中有多少按期完成。这是负责资源分配的人使用的视图——而不是需求列表，需求列表在看板中。

筛选器默认打开为“全部团队”，这样才能看到同一个人同时被分配到两个团队——这正是任何单个团队都显示不出来的超负荷。选择某个团队后，所有内容（KPI、图表、SLA 和合同）都只限定于该团队。同时属于多个团队的人只计一次。

看板按每人同时只能有一项进行中需求的上限运作。当出现第二项时，该行会显示提示“N 项进行中——决定哪一项暂缓”。 这是提示，不是锁定：服务客户的团队总会被打断，而一个拒绝现实的界面最终会被人从外部绕开——那时它就什么也衡量不了了。设置这个上限，是为了让“哪项需求要等待”的决定变得可见；如今这个决定是在沉默中做出的，结果变成两项做了一半的工作。

以每项需求的预计日期为准。计算范围包括所选期间内交付的需求，以及截至今天仍未关闭的所有需求——已过期限仍未关闭的需求计为超期，因为它恰恰是需要采取行动的那个。没有预计日期的需求没有 SLA：它不计入统计并单独显示，绝不会被算进“按期”。

只有在职员工才会进入仪表板。与团队的关联是有意保留的（谁交付了什么的历史需要保持完整），但本界面衡量的是容量：已离职人员过去会以满工时、零工时记录出现，也就是看起来像是可以接活的闲置人员。

在**今天**视图中，每个单元格是一项需求：看板回答“这个人现在在做什么”。在**周**和**半月**视图中，它变成一条有起止时间的条形：回答“这件事什么时候结束、接下来是什么”。在**月**和**年**视图中，它变成比例：回答“这个人的时间有多少花在了每件事上”。 这不是设计上的讲究，而是算术。八个人每人每天一项需求，在今天视图中是 9 张卡片，在年视图中则超过 2,000 张——在一天里好用的单元格，放到一年里就无法阅读。在年视图中，没人想知道 14/03 某人做了报告 X；大家想知道的是一年中有多少时间花在了每条战线上。

当您选择按项目或按产品分摊时，需求中未填写该字段的所有内容都会落入一个带斜线的区块，并提示它占多大百分比。 它是有意显示的，绝不会被隐藏。基于 60% 工时绘出的漂亮条形图依然漂亮——却会在不报任何错误的情况下导致错误决策。只要这个区块还很大，条形图就只是装饰；等它缩小了，才成为工具。解决办法不在界面上：而是在需求中填写项目和产品。 🪤 登记在未关联产品的需求上的工时无法按产品分摊——工时记录保存的是需求，而不是产品。

访问权限由角色控制:在其访问角色中拥有查看此屏幕权限的人可以在菜单和Ctrl+K中找到它。授权由账户管理员在"访问权限"屏幕上按角色逐一进行。除角色外,所签约的套餐还必须包含运营模块——这两把锁是独立的:如果套餐中没有该模块,即使拥有权限的人也无法打开该屏幕。

不是。这是两个叠加的缺陷，已在本版本中修复：计算只看已关闭的需求（因此在它眼里根本不存在未关闭且逾期的需求），并且使用了一个对任何“先打开后关闭”的需求都成立的比较——违规计数器根本不可能离开零。现在规则与看板相同，数字也与您在那里看到的红色卡片一致。

培养搭档在团队档案的“成员”标签页中的“培养搭档”字段填写。它适用于正在培训或实习的人员。 之所以有它，是因为当没人写明学员跟谁一起工作时，学员往往只能接“剩下的活”——这是培养一个人最慢的方式。有了看板上的搭档，“这周谁在带实习生”这个问题一眼就有答案，无需开会。