Empi がどのようにあなたの作業をスケジュールするか¶
スケジューリングは、単なるタスクリストにはできない、Empi ならではの機能です。プランナーはあなたの タスクを受け取り、それぞれの作業が実際にいつ行われるのかを日ごとに配置します。これにより、 どの締め切りが来る前でも、すべてが収まるかどうかを確認し、収まらないものに対処できます。
プランナーが生成するもの¶
提案 です。あなたの作業を期限どおりに終わらせるための、日ごとのカレンダー予約のセットです。 プランナーの実行時には何も予約されません。ランク付けと予測を行うだけです。提案を実際のカレンダー ブロックに変えるのは、別の明示的なステップです。Reserving time を参照して ください。
Planner view は、その提案を確認し、何が変わるかをレビューして適用する場所 です。
何がスケジュールされるか¶
タスクは、以下のすべてが満たされる場合にのみスケジュールされます。
- リーフであること。 サブタスクを持たないこと。サブタスクを持つタスクはスキップされ、代わりに そのサブタスクがスケジュールされます。親の見積もりは子の合計にすぎず、両方をスケジュールすると 同じ作業を二重に予約してしまうためです。
- あなたに割り当てられていること。 プランナーはあなたの作業を計画し、チームメンバーの作業は 決して計画しません。
- Done ではないこと。 Backlog を含め、それ以外のすべてのステータスはスケジュールされます。
- 期限と見積もりの両方があること。 締め切りがなければ計画する対象がなく、サイズがなければ 収める対象がありません。
期限または見積もり以外のすべてを満たすタスクは、黙って除外されるわけではありません。理由 ("Needs a due date"、"Needs an estimate"、またはその両方)とともに Not planned yet の下に 一覧表示され、ワンクリックでそのタスクに移動して追加できます。
プランナーは、あなたがすでに手動で予約した作業もスキップします。あなた自身がピン留めした時間は 「済み」として扱われます。残りのスケジュール対象を減らし、プランナーがそれを動かすことは決して ありません。
タスクが検討される順序¶
順序は、次の優先順位で 2 つの要素によって決まります。依存関係、次に並べ替えキー です。
依存関係が最優先であり、これは厳格です。 タスクは、それをブロックしているすべてが済んだ後に のみ配置されます。
依存関係が満たされているタスクの中では、順序は次のとおりです。
- Overdue が最初。 期限をすでに過ぎているものが最上位に来ます。
- 次に進行中の作業。 Doing ステータスのタスクは、期限がより後であっても、まだ着手していない 作業より優先されます。始めたものを終わらせましょう。
- 期限が最も早いもの。
- 優先度が最も高いもの(P1 が P4 より上)。
- 残作業が最も少ないもの。最後のタイブレークとして、2 回の実行間でプランが理由もなく並べ替え られないようにします。
作業が日々にどう詰め込まれるか: 締め切りが王様¶
プランナーはその順序付けされたリストをたどり、各タスクを期限までのまだ空き容量のある最も早い 日に流し込みます。期限の早いタスクが先に配置されるため、それらが最も早い容量を確保し、後の作業は 残ったところに流れ込みます。これが締め切りを王様たらしめる仕組みです。タスクを期限前に終わらせる 容量が存在すれば、そのタスクはそれを得ます。
知っておくとよい結果がいくつかあります。
- Today は、まだこれから先の時間帯だけを提供します。 すでに経過した時間は予約可能な容量では ありません。
- 1 日に収まらない大きすぎるタスクは、連続する複数の日に分割されます。 自分で刻む必要は ありません。
- タスクの開始日は下限です。 プランナーはそれより早く予約しないため、開始日が期限と同じ タスクは前倒しされず、その 1 日に配置されます。
- ブロックはきれいです。 予約される各ブロックは 5 分単位で、最大スロットサイズより大きくならず、 最小スロットサイズより小さくなりません。最小値に満たない残りは意図的にスケジュールされないまま 残されます。カレンダーを小さなブロックで散らかすより、会議の合間に吸収できるほど小さいためです。
どちらのスロットサイズもあなたが設定できます。Working hours and focus hours を 参照してください。
Focus shaping: deep work in your peak hours¶
各日の空き容量は 2 つのバケットに分けられます。peak の分(あなたの勤務時間とピーク集中枠の 両方に入る時間)と、それ以外すべてです。
Deep タスクはまず peak バケットから引き出し、それが埋まったときにのみ外にあふれ出します。 Shallow タスクはまず 1 日の残りの時間から引き出します。その結果、深い作業は最良の時間帯に 配置され、浅い作業はそこから外れます。
これはスロットの質に関する緩やかな優先設定にすぎません。どのタスクがスケジュールされるか、 その順序、あるいは期限を変えることは決してありません。P1 の shallow タスクは依然として peak スロットを deep タスクに譲り、shallow タスクはスケジュールされないままになるより peak の時間に あふれ出します。ピーク集中枠を宣言しなければ、プランナーはこの機能がないときとまったく同じように 振る舞います。
また、タスクの分を時計上のスロットに割り当てる際に何を最適化するかをプランナーに指示できます。 Focus first(デフォルト。最良のスロットに配置できるようタスクを 1 日の中で分割できます)または Reduce switching(1 日分のタスクのブロックを 1 つの連続したまとまりに保ちます)。どちらも Settings の Tasks にあります。
休憩¶
あなたは機械ではありませんし、プランもそのように振る舞うべきではありません。休憩は分単位で宣言 します。どれだけの連続作業の後に休憩を取るべきか、そしてその休憩がどれくらい続くかです。
次のブロックを配置すると連続作業の連なりがその上限を超えてしまう場合、プランナーはその直前に Break を予約し、連なりをリセットします。休憩はスケジュールの穴ではなく、カレンダー上の 実際の予約です。目に見え、他の人には多忙として表示され、その日の容量に対して計上されるため、 プランがこっそりあなたを過密にすることはありません。
休憩時間と同じ長さ以上の自然な空き時間は、すでに休憩として数えられます。空き時間、会議、通勤は すべて連なりをリセットするため、Empi はすでに取っている昼食の上に休憩を重ねることはありません。
Parallel threads (pipes)¶
スレッド とは、進行中の 1 つの作業のことです。親タスク全体が単一のスレッドとして数えられます。 "Website redesign" の 3 つのサブタスクに取り組むことは、3 つではなく 1 つのコンテキストです。会議は スレッドではありません。タスク作業だけがスレッドです。
pipes の目標は、ある日にいくつのスレッドを同時に扱いたいかです。スレッドは、着手した最初の日 から完了するまで、間の何もしない日でも毎日そのスロットを保持します。これが、新しいものに手を つける前に始めたものを終わらせるよう促す仕組みです。
pipes は壁ではなく緩やかな目標です。優先順位は、期限、次に pipes、次に優先度です。プランナーは、 pipe 数を超えないためだけに締め切りを逃すことは決してありません。実行可能な完全なプランを配置し、 それが求めた数より多くのスレッドを必要とした場合は、その旨を伝えます。"fits, but needs 5 parallel threads instead of 3"。プランは正しく、その数は情報であり、それについてどうするかはあなたの判断です。
何も隠さない¶
何かがうまくいかないとき、プランナーは試みた完全なプランを警告とともに、Heads up の下に 表示します。あなたの作業をこっそり除外することは決してありません。
| Warning | 意味 | あなたがすること |
|---|---|---|
| Overdue | すでに期限を過ぎています。それでも最初にスケジュールされます。 | 再スケジュールするか、遅れていることを受け入れます。 |
| Won't fit in time | 存在するすべての容量を使っても、期限当日またはそれ以前に終わりません。 | 期限を延ばす、見積もりを削る、または競合する作業の優先度を見直します。Empi は 2 つの原因のどちらが当てはまるかを伝え、ワンクリックの "Extend due to |
| Too many at once | プランが pipes 目標より多くの並列スレッドを必要としました。 | 追加のコンテキストスイッチを受け入れるか、いくつかの期限を後ろにずらします。 |
| Dependency conflict | ブロッカーが、それを待つタスクより後の期限になっているか、依存関係の循環があります。 | 依存関係または日付を修正します。スケジューリングだけではこれを救えません。 |
警告とあわせて、Not planned yet リストには、期限または見積もりがないためにスケジューリングに 入らなかったすべてが保持されます。この 2 つによって、あるタスクがプランに入っている、あるいは 入っていない理由が常にわかります。
Note
"Won't fit in time" の対策としてタスクの分割が提案されることは決してありません。プランナーは すでにタスクを日々にまたがって自動で広げており、分割しても合計見積もりは変わりません。容量を 作り出すことはできません。誠実な対処法は、より遅い期限、より小さい見積もり、またはそれと競合 するものの優先度の見直しです。
現実に合わせて計画する¶
容量とは「勤務日の時間数」ではありません。実際に空いている時間数です。プランナーは、本当に使え ないものをすべて差し引きます。
- 接続したアジェンダ上の会議やイベント。 スケジューリングに使うカレンダー上のすべての時間指定 イベントは多忙な時間です。昼食も含みます。イベントの種類は、その分がどのバケットに計上されるかを 決めるものであって、その時間が空いているかどうかを決めるものではありません。
- 通勤区間。 会議に住所があると、その前後の移動時間も多忙です。そのため、プランナーは路上で 過ごす隙間に作業を詰め込むことはありません。
- Reserve windows。 入ってくる会議のために空けておく時間は厳格な確保です。集中作業がその中に 配置されることはありません。
- Off hours。 すべての枠の外にある時間はスケジュールされず、既存の休憩もスケジュールされません。
- 手動で予約した時間。 ピン留めされており、決して動かされません。
重複する多忙な時間は 1 回だけ数えられ、複数日にわたるイベントはそれがカバーするすべての日を 差し引くため、表示される数字は本当に使える空き時間です。
カレンダー競合からの回復¶
固定したブロックは通常その場所に残ります。後から会議、移動時間、または複数日の不在 イベントと重なった場合、Empi は競合ブロックを解放し、未完了分を空きのある日に再計画します。 reserve window は自分で確保した時間なので、この回復処理を開始しません。休暇や不在で 一日が埋まっている場合は evening wrap にもその理由が表示されます。
