タスクのライフサイクル

誰もがタスク管理について長い間知っています。 残念ながら、または幸いなことに、特別なことはありません。 同じ情報がより詳細に、より面白く、よりカラフルで、「科学的アプローチに基づいて」伝えられるコメント、ヒント、およびアドバイス、方法論、実践へのリンクは数千とまではいかないまでもあります。

しかし、知識の量にもかかわらず、実際の問題は小さくなりません。 たとえば、プロジェクトマネージャーと話をします。タスクマネージャーについてはすべて知っている必要があります。 まあ、はい、彼はすべてを知っているようです。 あなたは彼が働いているシステムを見て-そしてぎこちなく黙っている。 そんな膨大な知識を持ったあなたは、また何百万回目に、人々の活動を手に負えないゼリーに変えますか？

1年以上前のタスクをハングアップします。 なぜぶら下がっているのですか？ 読み始めます。 そして、それはずっと前に行われました、それを閉じる必要があります。 ああ、これはもうやる必要はありません、顧客はずっと前に辞めました。 うわー、これはクールなタスクです、私たちがそれを見たのは奇妙です。 そして、なぜこれは動かないのですか？ 開発者は質問をしましたが、顧客は答えませんでしたか？ 彼は何に答えるべきか知っていますか？ くそー、警告システムを確認する必要があります。

タスク管理では、重要なのは知識ではなく、日常的な日常業務における知識の具現化です。 エンティティとしてのタスク、または自然現象の主な違い-それらは無限です。 つまり、彼らは決して尽きません。 人々がタスク管理から遠ざかり、「すべてが何らかの形でうまくいく」モードに切り替えることを強制するのは、実現しない場合（常に）、「これをすべて実行し、できるだけ早くそれを忘れたい」という潜在意識の欲求です。

私自身も時々同じ状態に陥りますが、それがどれほど有害かは知っています。 それから、私は数字で、タスクの非管理のために、私、チーム、または会社全体が2回、さらには3回沈んだと確信しています。 これは、タスクを処理する際の基本的な規則に従わない場合の代償です。 これは、ルールを実装するインセンティブであり、その実装により、タスクの数（および/または重量）が2〜4倍に増加します。

ルールはシンプルで、誰もが理解できるもので、従う必要があるだけです。

ライフサイクル

すべてのルールの本質は同じです-タスクには、実行する必要があるライフサイクルがあります。 すべての問題は、このサイクルのある段階でタスクがフリーズし、先に進まないため、結果として終了しないために発生します。 同様に、心理学では、ストレスを処理することをお勧めします-そのサイクルを何らかの方法で完了するために、そうでなければ、それはまた「凍結」し、人生を台無しにします。 たとえば、ストレスの多い状況を経験する、恐怖を経験するなど。

単純化された形式のタスクのライフサイクルは次のようになります。設定-実行-終了。 これらの3つの状態に限定する場合、タスクが状態間をどのように通過するかが明確ではないため、問題が発生します。

たとえば、私たちはgithubのプライベートリポジトリを使用してタスクについて顧客と協力しています。 顧客担当者が問題を作成します。 声明を実行する-ライフサイクルの最初の段階。 すべてが単純なようです-それを取り、それを行います。

しかし、単に服用して行動するだけではうまくいきません。 まず、多くのタスクがあります-同時に数十、数百です。 選択ルールが必要です。最初に実行するルールです。 第二に、声明は必ずしも明確ではないため、明確な質問をする必要があります。 第三に、タスクを実行する必要があることに必ずしも同意するわけではありません（二重になったり、すでに解決済みであったりします）。

多くの困難がありますが、1つの結果-タスクは理解できない状態です。 記録されているようですが、パフォーマンスは行きません。 タスクについて質問しますが、顧客は応答しません。 今の仕事は何ですか？ ソリューションはすでに存在していると書き、リンクを提供しました。 顧客は応答せず、タスクは閉じません。 彼女はどんな状態ですか？ 明確ではありません。

この「理解不能」は多くの問題を引き起こします。 そのようなタスクのリストを入力する開発者は、何をすべきかを理解していない場合があります。 最初は、彼はタスクを選択できません。 彼が最終的に選択したとき、彼はそれが行われるべきかどうかを理解できません-おそらく議論はまだ終わっていません。 完了したら、タスクにコメントを書きましたが、顧客はチェックしません。 再び、理解できない。

タスクの2つの状態のみがクリアされます-セット（開いているリストに表示されます）と閉じられました（閉じられた状態に切り替えられます）。

誰でも、ステータスシステムを通じて、タスクのライフサイクルを制御および管理する方法を正確に知っています。 githubでステータスを実装するための少なくとも2つのオプションがあります-ラベルとマイルストーンを使用します。 おそらく、ステータス管理はどのシステムにもあるため、ルールは普遍的であると考えることができます。

タスクのステータス

ステータスは、特定の状況に必要なだけ正確にすべきです。 「正しい」または「普遍的な」状態のセットはありません。 主な条件は、特定のステータスのタスクを誰が、何を、いつ実行するかを誰もが正確に知る必要があるということです。

少し奇妙に聞こえますが、タスクでは、さまざまなタイミングで、さまざまな人に対してさまざまなアクションを実行する必要があります。 ある時点で、コードを記述するコーダーが必要です。 別の瞬間には、結果を確認するテスターが必要です。 3番目の瞬間に、顧客のデータをテストする必要があります。 4番目の瞬間に、タスクを閉じる必要性を顧客に常に思い出させるマネージャーが必要です。

ステータスに応じて、タスクの操作方法も異なります。 初等、タスクが実行のためのものである場合、一人がそれを操作します。 またはその逆-1人が1つのタスクを処理します。 リストから選択するか、選択した優先度システムが座ってそれを行います。

「まだ仕事に受け入れられていない」などの状況では、アプローチは異なります。1人が複数のタスクを処理します。 彼はそれぞれに来て、読み、決定を下します。 顧客に質問することにより、改訂のために1つのタスクを送信する必要があります。 別のタスクを実行して受け入れ、実行者にコメントを書き、ステータスを変更する必要があります。

「完了、顧客による確認待ち」の状態では、特別なことは何もする必要はありません。締め切りに従ってください。 昨日行われた場合、何もできません。 3日が経過した場合、確認の必要性を顧客に思い出させるためにコメントを書く必要があります。 1か月が過ぎたら、通常の専門家がdr死するように、顧客のマネージャーに手紙を書く時間です。

すべてが明らかなようです、ありがとうございます。 しかし、状況に応じたアプローチの違いは、プロセス、アルゴリズムの選択、モード、さらにはそのような作業の時刻に違いを生じさせるはずです。

たとえば、グループ処理を必要とするステータスのタスクでは、1日に数回働くことは意味がありません。 午前中に30分またはそれ以下を費やしただけで、朝まで対応する方がはるかに簡単で効率的です。 このルールに従わない場合、1日中に数回気を散らす必要があります（たとえば、到着した新しいタスクなど）。 気晴らしのコストは不当に高いことが判明しました（現在の充足をやめました-新しいものを読みました-私は侵入しました-私は何かに答えました-ステータスを変更しました-現在のものに戻りました-いいえ、私は喫煙する必要があります-そして今、コーヒーを飲みませんか？）

どんなに馬鹿げているように聞こえますが、異なるステータスのタスクには、異なるエネルギーが必要です。 私はエネルギーの専門家ではなく、直感的に定義していますが、その違いを鋭く感じています。 顧客を蹴って実行された作業を確認することは1つのことです。 プログラミングはまったく別です。

ステータスを簡単に見てみましょう。

ステータス「タスクが設定されています」

このステータスは、着信タスクに自動的に割り当てられます。 通常、私が働いていた場所には、顧客（内部または外部）とチーム（開発者、マネージャー）の2つのタスクのソースがあります。

ここでの主な問題は、おそらく、すべてのタスクがこのステータスに該当しないことです。 簡単に言えば、すべてのタスクが記録されるわけではありません。
自動化されたタスク管理システムが広く使用されているにもかかわらず、未記述のタスクの問題は依然として非常に重要です。
誰かが会議またはSkype会議で何かをするように頼みました。 誰かが喫煙室に現れました。 誰かがオフィスを覗き込み、敷居から彼がそこで必要なことを放送し始めました。

特に、コンピューターで作業したくない人が多い工場では、タスクが書かれていないことがよくあります。 「クールマネージャー」はそこに帰することができます。彼らは一言でプログラマーに目を向け、彼にすでに大きな名誉を示したと信じています。 したがって、彼は注意深く耳を傾け、「自分の仕事を自分のクソシステムに書き留める」必要があります。

失われたタスクの別のストリームは、主にメールやインスタントメッセンジャーなど、システム外のあらゆる種類の電子通信です。 はい、ボットがあります。多くのシステムにはメールの自動読み込みがあります。 しかし、彼らは問題を100％解決しません。

タスクを記録する必要があります。 あらゆる種類の顧客は、タスクを記録する必要があります。 すぐにではなく、徐々にではなく、思考に慣れています。タスクが適切に書き留められていないと、解決されません。 違反なし。

タスクを書き留めないが、それらを実行することを引き受ける開発者のための別の行に言及したいと思います。 これは信じられないような嫌悪感です。なぜなら、2番目の制御されていないワークフローが表示されるからです。 顧客は、発表されたルールにも関わらず、常にフォールバックオプションが存在するという事実に慣れます。「見よ、コリアン、普通の男、彼はそれを受け取り、くだらないことをします。」 そして、記録されたタスクに基づいてマネージャーまたはチームリーダーが効率を管理しようとしている場合、2番目のストリームが存在すると、彼の労力はゼロになります。

「配信済み」ステータスのタスクは、「改訂版の送信」または「作業の承認済み」に移動する必要があります。 官僚システムでは、承認が追加されます-たとえば、IT部門の責任者、顧客の部門の責任者、またはプロセスが影響を受ける場合は関連部門の責任者。

ステータス「改訂版送信済み」

顧客がワッドアップされている場合（そして、それが過半数である場合）、そのようなステータスは重要です。 彼は石を顧客の庭に投げ込み、仕事の運命に責任を負わせます。 もちろん、修正の送信には通常のコメントまたは質問を添付する必要があります。そのため、何が理由で何をする必要があるかが明確になります。

このステータスがなければ、エグゼキュータは、部門全体として、「送信され忘れられた」という原則に基づいて「投げられたタスク」になる可能性のある一種のterになります。 タスクセットが自動的に受け入れられたと見なされると、パフォーマンスの質が低下し始め、パフォーマーの有効性も低下します。

顧客は問題を解決する責任を理解する必要があります。 「修正のために送信された」ステータスの存在は、そのような責任を高めるのに役立ちます。

ステータス「改訂版の送信」には2つの方法があります。「配信済み」または「ファイル」に戻る-実行者のコメントで問題を解決すべきでないと確信した場合（たとえば、重複する機能を要求した場合） 。
もちろん、理由もなく改訂版を送信することに夢中になるべきではありません。

ステータス「仕事に合格」

ここではすべてが明確です。 雇われた-私たちはやる。 どのように、いつ、どの順序で-別のトピックであり、実際にはタスクのライフサイクルに関連していません。

承認されたタスクには2つの方法があります。「完了」と「改版の送信」です。 実行プロセス中に、タスクを実行する必要がないことが判明する可能性があることは明らかです。 または不可能（レセプションでは可能だと思われたが）。 または高すぎる。 または、実行の過程で、外部サプライヤが使用するモジュールの1つに同様の機能が現れることが判明しました。

しかし、メインパスはもちろん「完了」です。

完了ステータス

タスクが完了としてマークされると、責任は再び顧客に移ります。顧客は自分のデータで結果を確認する必要があります。 この時点では、開発者による内部テスト、個別のテスターの作業、ドキュメントなど、中間ステータスのバリエーションが多数ありますが、簡単にするためにこれらの手順は省略します。

「完了」の状態では、多くのタスクがハングします。 理由は簡単です-顧客はすでに結果を受け取っており（生産中の場合）、追加のアクションを実行するのは面倒です。 それは動作します、他に何が必要です。

しかし、パフォーマーにとって、特にマネージャーにとって、「顧客に受け入れられた」ステータスへの移行は非常に重要です。 多くの場合、彼の収入はこれに依存します。 はい、ありふれた-タスクはリストから離れる必要があります。そうしないと、タスクの管理コストだけでなく、すぐに膨張します。 10個のタスクを移動することと、100個を移動することはまったく別です。

ステータスが「完了」のタスクには2つの方法があります。顧客に受け入れられ、ライフサイクルが完了するか、結果が満足できない場合は請負業者に返されます。

ライフサイクル管理

ライフサイクルの管理、つまり タスクのステータスを変更するには、さまざまな方法があります。 おそらくあなたはそのような仕事であなた自身の豊かな経験を持っています。 貯金箱に自分のものを追加します。 ここでの主要なことは、繰り返しますが、知ることではなく、行うことです。

タスク設定

最初に練習することは、すべてのタスクを記録することです。 ここでのルールは簡単です。タスクは書き留められていません-タスクは解決されていません。 顧客、顧客の行動、性質に応じて、2つの方法があります。 1つ目は、自分の手でタスクを記録させることです。

顧客によると、2つ目はタスクを自分で記録することです。 個人的には、2番目の方法に関与するべきではないようです。彼らはすぐに慣れてしまい、離乳するのが難しくなり、個人的なin辱として認識されます。 秘書の役割は完全に回避されない可能性が高いですが、マネージャーには口頭でタスクを指示する正式かつ道徳的な権利を持つ優れたマネージャーがいます。

リストフィルタリング

ステータスにとって重要な2番目のことは、ライフサイクルの各段階のタスクリストをすばやく簡単に表示できることです。 ほとんどのシステムでは、これは基本的に行われますが、単純なステータスではなく、グループ化不可能なステージを持つ美しいビジネスプロセスが発生する場合は例外があります。 この場合、タスクの状態を理解するには、その状態に入り、上から下に読む必要があります。

さて、ステータスによる美しいフィルタリングでも、このステータスを変更しない怠zyなパフォーマーとマネージャーには常に問題があります。 新しいタスクを読んで、顧客に質問をしましたが、ステータスを「修正のために送信」に設定しませんでした。 もちろん、顧客は質問に答える必要があるという通知をメールで受け取りましたが、これは夕方遅くに起こり、朝、彼は単に忘れていました。 彼らが教えてくれたように、「改訂版の送信」または「完了」のステータスに応じてフィルタリングされたタスクのリストに行きました。 そして、タスクがハングしました。

理想的には、特に顧客向けにリストを事前に構成する必要があります。 実際、2人で十分です-「修正のために送信」と「完了」、そしてディレクターによるフィルタリング。 これらのリストにタスクが存在するということは、何らかのアクションを起こす必要があることを意味します。 彼には「タスクの処理」というタスクがあります。 リストが空の場合-すべてが正常であれば、何も必要ありません。 彼が監視したい場合、彼は「仕事中」のリストに行き、見ます（しかし、彼はそこに何を見ますか？）。

同様に、実行者のマネージャー用に事前に構成されたリストが必要です-タスクが割り当てられています。 その中に何かがある場合、あなたはそれに取り組む必要があります-実行のためにそれを受け入れるか、修正のためにそれを送信します。 私は午前中に入って、働いて、リストを空にしました-彼ら自身のビジネスを続けました。

ステータス変更日

私はそのような慣習を持っていました-ステータスの期限を指定します。 たとえば、新しいタスクの決定を行うには、1営業日後にタスクが「赤面」し始めます。

同様に、締め切りは顧客にとって必要であり、通常はより柔軟です。 改訂のために送信されるタスクの場合、実行者の観点からはそのようなタスクは存在しないように見えるため、安全に月を設定できます。 そして、それは存在しないので、それを心配する意味はありません。
顧客による確認待ちの完了済みタスクの場合、通常の期間は3〜5営業日です。 短すぎる期間は意味がありません;それは決して満たされません。 私たち、つまりパフォーマーは、タスクで作業することだけを行うのです。 顧客は、高い確率で、完全に異なる業務に従事しており、ある種の彼自身の活動に従事しており、せいぜい1日に1回だけタスクを処理できます。

ステータス日付情報の保存

これは明らかなように思えますが、私は別のポイントを選び出します。 しかし、すべてのタスク管理システムにそのような情報が含まれているわけではありません。

ステータスが変更された場合、この変更の日付と時刻はタスクに保存する必要があります（または近くのどこかに問題ありません）。 データ自体ではなく、バージョン管理システムにそのような情報があれば十分だと考える人もいます。 一部のシステムでは、データの場合と同様に簡単にバージョンを処理できる可能性がありますが、実際にはこれらに遭遇していません。 バージョンは信頼性が低く、管理者またはデータベース圧縮などの日常的な手順でクリーニングできます。 さて、多くのバージョンがあり、ステータスが変更されたバージョンを見つけるには、いじくりまわす必要があります。 同じgithubで、ステータス変更の日付はAPIを介してのみ計算できます。または、コメントを巻き戻して、「追加されたラベル」がどこ、いつ、誰であるかを調べることができます。

プリミティブ型のいくつかの詳細（日付と時刻）をタスクオブジェクトに追加し、それらに変更を保存する方がはるかに簡単です。 その後、「赤み」と状態変化からの経過時間を計算するのは非常に簡単です。 タスクのライフサイクルが測定可能になるため、ステータス変更時間に関する情報は管理に非常に役立ちます。 容認されていない、または検証されていない状態でロバがどれくらいの時間突き出ているかを正確に知っており、その将来の運命を決めることができます。

制裁

通常、従来のタスク管理モデルでは、あらゆる種類の制裁が実行者にのみ課されます-タスクのタイミングの悪い実行。 しかし、現在わかっているように、タスクのライフサイクルは実行だけではありません。

したがって、ライフサイクルのすべての段階、特に顧客に責任がある部分に制裁を適用することを好みます。 制裁の本質は、お客様との法的関係に依存することは明らかです。

最も効果的な制裁は、顧客が社内にいる場合です。 私の練習では、罰金までの制裁がありました。 剥奪。タスクを処理する義務を果たすことができないためですが、もちろんこれは多すぎます。

私は「自然な」制裁を好みます。 たとえば、顧客が10個のタスクを設定し、そのうち5個が修正のために彼に送信され、長い間何もしなかった場合、彼は新しいタスクへのアクセスを拒否されました。 彼の新しいタスクが現れるまで、状況は現状を維持します。 新しいタスクが出現し、設定する機会がなくなると、5つのハングしたタスクが魔法のように動き始めます。 もちろん、一部の詐欺師は同僚にタスクを設定するように依頼しただけですが、そのようなケースはまれです。

より緩やかな制裁のもう1つの例は、5営業日以内に顧客が確認していないタスクを自動的に閉じることです。 これは制裁ではなく、サービスであり、怠け者のお客様には非常に便利です。

顧客が外部にいる場合、状況はより複雑になります。 私たちはバランスを取る必要があり、非常に穏やかな制裁のみを適用します。 たとえば、スパムは毎日、または他の妥当な間隔で愚かであり、進行状況を確認したり、問題のステートメントを明確にしたりすることを思い出させます。 設定は簡単です-以下を含む客観的に明確です 顧客に-処方が指定されていない場合、タスクは動きません。

トリックを使用して結果を検証できます-新しいタスクでは、未検証のものを参照し、データまたはアルゴリズム間に厳密な内部関係があると言います。前のものが検証されるまで、新しいものを行うことはできません。

いくつかの統計

私はあなたの多くと同じように、長年にわたってタスク管理を行ってきました。 それでも、毎回、タスクのライフサイクルを管理すれば、このプロセスがどれほど効果的になるのか、驚きました。

毎回、新しい会社や新しいチームに参入したり、新しい顧客と仕事をしたりするたびに、最初に自分に言い聞かせます-いいえ、そのような些細なことは必要ありません。 ここにはすべての知識を持ち、正しいことをする知的な人々が座っています。 まあ、同じ問題がどこにでもあるということはありえません。

彼らが言うように、私は数週間または数ヶ月の間、「自分のビジネスに参入しないでください。」 私はいつものようにチームで働いています。 そして、私が同じことを見るたびに-安定性。 同じ開発、期間内の同じ数のタスク、同じハングのリスト、ダイナミクスなし。
忍耐が破裂し、タスクのライフサイクルの管理を開始します。 繰り返しになりますが、生産性と効率は向上しており、ほぼ常に倍増しています。 コストは一定であるため、効率は生産性と同じように向上します。

これが最新のプロジェクトの例です。 10月に開始し、安定した数値に達して、3月まで立ち往生し、4月にタスクのライフサイクルを管理し始め、すぐに倍増しました。 5月はすでに平均月間レベルにありますが、半月未満が経過しましたが、5月上旬の就業日-さらに少ないです。

写真の説明：赤い線は主な開発者、黄色は補助的なもの、青は総合的なパフォーマンスです。 効率は、顧客が検証した達成済みタスクのポイントのスコアの合計と見なされます。 ポイントでスコア-ポーカープランニングシステムに従って。