ボトルはどこで手に入れましたか？

Flowcon、またはボトル-タスクを含む管理手法。 ストリーム、プロジェクト、開発、ルーチン機能、レギュラーなど。

多くの人々は、方法論とそれに基づいた解決策について学び、何を、どのように、本質とは何か、どの「世界慣行」が作られているのか、どのメトリクスが使用されているのか、誰に適しているのか、どこから来たのかといった質問をします。 私はそれぞれ個別に答えましたが、同じことを何百回も書くことにうんざりして、すべてを止めました。 私はプログラマーですか？ 再利用は、コードだけでなく、情報にも使用できます。 私は一度書いて、記事のすべての質問に答えようとします。

何よりも、ボトルの誕生は、いわば私のキャリアと密接に関係しているため、物語の形で提示するように思えます。 そうします。 追われた。

PMBOK

私が知っていた最初のプロジェクトおよびタスク管理手法はPMBOKと呼ばれていました。 2006年は遠い年でした。

当時、PMBOKはプロジェクト管理のほぼ独占でした。 履歴書や空席では、PMBOKと聞いただけです。 当時、柔軟な方法論は存在しませんでしたが、それらはすでにどこかに存在していました。

PMBOKは、純粋にカスケード型のプロジェクト管理方法でした。 ステージとタスク、締め切りと依存関係の最初から最後までの厳格な構造を想定しました。 したがって、予算-時間-コンテンツの三角形の有名な（当時の）規則が絶えず違反されていたため、当時の1C実装プロジェクトで迅速かつ美しくバラバラになりました。

当時、顧客も実装者も、賢明な技術仕様を作成したり、機能要件を記述したり、企業の作業をシミュレートしたりすることはできませんでした。 はい、そしてSCPのような構成は常に驚きを投げかけました-彼らは開発しました。 その結果、編集された作品のリストは、プロジェクトの開始から1日後には無関係になりました。

しかし、プログラマの頭脳は好奇心are盛で、PMBOKと当時の未知のアジャイルの特定の組み合わせを思いつきました。 これをイエローエッジと呼びます。 そして、私も彼の謝罪者にならざるを得ませんでした。

イエローエッジ

黄色のエッジは、PMBOKによって作成されたステージに基づいており、それぞれの目標を根本的に置き換えるだけです。 PMBOKの目的は何ですか？ ステージのすべてのタスクを完了します。

イエローエッジはもう1つの目標を思いつきました。 たとえば、「倉庫会計の実装」という段階があります。 TKの設計と製図の段階で、「マテリアルレポート」、「ユーザートレーニング」、「アクセス権の設定」などの特定の作業が表示されます。 -速達試験の段階での研究の深さに応じて。

この作品のリストは、何かから始めるためのスターターキットとして役立ちました。 プログラマーが倉庫の頭にやってくるか、店主、または材料会計士が彼らと話し始めます、そしてそれは判明します...それで、それはノートブックがひどい力で終わったことが非常に判明します。

最初、PMBOKによって甘やかされた頭脳は言った：いいえ！ 不可能です！ TKに書かれていることを行うだけです！ また、プロジェクトマネージャーは、クライアントと長期にわたる否定的な交渉を始めました。 誰かが追加の作業、追加の技術タスクなどを顧客に納得させることができました。 ほとんどはありません。 顧客は言った：やれやれ、私はTKが何であるか、すべてが私のために機能するためにあなたのプログラムの改善が必要であるか分からないが、それが機能しない場合、 私は行為に署名しない 。

現実は、主に勝ち、プロジェクトは計画と事実という2つの次元で生きました。 計画は破棄されるように見えますが、キャッチがあります-それに応じて予算が作成されており、顧客側のプロジェクトマネージャーによって保護されており、それに触れることはできません。 しかし、行為に署名するために顧客が望むものの最大値の最小値を作成する必要があったという事実が残っていました、さもなければ、それぞれ支払いも給料もありません。

だから私の頭の中には、黄色ではあるが、エッジのモデルがありました。 ボトルが形成され始め、2つのタスク管理プラクティスが含まれていました。 彼らは互いに矛盾しているようですが、彼らは人生でうまくやっています。

コアPM

だから、ヒープに言及します。 私と同僚の間でプロジェクト管理の問題を見て、PMBOK以外で理論を選び始め、4つのテートが執筆した「プロジェクト管理」という簡単なタイトルの本を店で見つけました。 彼らは自分のメソッドをCORE PMと名付けました。

本質はPMBOKとほぼ同じです。 主なものは、計画の不変性と呼ばれます。 計画をどのように変更するか、別個の、別個の、大規模で、複雑で、官僚的な手順が考案されました。

その時までに、黄色の端をすでに認識していたので、この本からボトルに何も追加できませんでした。 そして、これは非常に良いことです。なぜなら、世界には賢いおじさんがいないことに再び気付いたからです。

スマートおじ

世界に賢いおじさんがいないという事実について、私はずっと前に、研究所に戻って練習をしたときに理解しました。 その後、製品の品質管理の統計的手法が好きで、工場に行き、そこで卒業証書のデータを1か月収集しました。

最初は、教師と私が特殊なソフトウェア（Statistica？）をひねりたかったデータの収集が目標でした。 アイデアは、最終製品の品質に対するさまざまな段階の影響を理解するために、コンベア生産の数学モデルを構築することであったようです。

先生は、旅行の前に、Shekhartマップ、統計的プロセス管理（SPC）、一般的な品質管理（TQM）に関する本をいくつか手渡しました。 どうやら、彼自身はそれらを読んでいない-そうでなければ、彼はマットを構築することを申し出ませんでした。 生産モデル。 それらは、例えば、モデル構築とドレーパー回帰分析が較正の基礎である圧力センサーに適していましたが、自動車産業には適していませんでした。

そして、私は本を読みます。 すべてがとてもシンプルで、息をtakingむほどでした。 また、工場には品質管理サービスの賢い叔父もいました。 彼らはこれらの本から基本的な概念を知っていましたが、驚いたことに、品質を向上させる方法だけでなく、技術プロセスの現在の状態を評価するための最も単純な公式さえ使用しませんでした。

そして、式は非常に単純でした。 100の詳細を取得し、測定し、Excelに数値を入力し、平均、標準偏差（同じシグマ）を計算し、単純でわかりやすいインジケーター-適合性指数または再現性指数（プロセスが安定している場合）を表示します。 実際、この指標は、プロセスがすべて正常であるかどうかを明確に示しています。

この数値を計算したとき、彼らはショックを受けました。 そして、彼らがついにこの数字を見たという事実から、そしてそれがどれほどひどいものであるかが判明しました。 彼らはさらにいくつかの部品と機械を数えるように頼みましたが、私はどうですか？

それから、私のプレゼンス中に、生産の質を根本的に改善するための簡単な努力を含め、多くの興味深いことがありました。 しかし、それはポイントではありません。

そのとき重要な考えが私に来ました： スマートおじさんはたくさん知っていますが、気にしないでください 。

メソッドは完全です-品質管理、タスク/プロジェクト管理、および一般管理の両方で。 有能なマネージャーに聞いてください-あなたは、そのような、そしてそのようなテクニックに従って、どのように、そして何をすべきかについての講義全体を読みます。 そして簡単に尋ねます-彼は方法論に書かれていることをしますか？ そこにイチジク。

ボトルは非常に有用な知識で強化されました。 すべてを自分で行い、確認する必要があります。誰も、特に実際に結果を示すことができない人は信頼できません。

ロシアの管理モデル

自分ですべてを理解しなければならないことに気付いて、私は何か他のものを読むことにしました。 新しい既製のテクニックを学ぶのではなく、もっと基本的なことを理解したかったのです。 アレクサンダー・プロホロフによる「ロシアの管理モデル」という本に目を奪われました。

本が素晴らしいと言うことは、何も言わないことです。 ロシアで働く場合は、必ずお読みください。 幸いなことに、そこには既製のレシピはありませんが、私たちがすべてをそのまま持っている根本的な理由はすべてエレガントに描かれています。

私は長い間絵を描きません。この資料の文脈で重要ないくつかの重要な考えだけに言及します。

1つ目は、ロシア人の仕事はねじれないように測定する必要があるということです。 私たちはシステムを欺くことに慣れているので、無意識のうちにそれを行います。 規則、制限、法律は受け入れません。 もっと正確に言えば、私たちは頭をうなずき、同意し、自分自身を欺く方法をすでに考えています。

2番目-ロシア人はいわゆる クラスターセル、すなわち 小さなチームは厳しく管理されていません。 オープンスペースは私たちのためではありません。 ご理解のとおり、同じ原則がスクラムに定められています。

第三に、ロシア人は言われたようにいまいましいことをしません。 これは、方法論を実装する際の重要なアイデアです。 あなたは行動する方法を指示し、人々に結果を待ってもらいますが、そうではありません。 なぜなら人々はあなたの指示を捨て、かつてのようにやるからです。

この本の後のボトルは信じられないほど豊かでした。 確かに、これらの「ロシア語」の問題を解決する方法は、独自に探さなければなりませんでした。 制御が見つかりました。

制御

制御は数値ベースの制御です。 私の好きなテクニックの一つ。 主に強調するのは、制御は制御ではないということです。 これが管理です。

数字がない場合、間接的な情報に基づいて盲目的に制御が実行されます。 タスクを扱うとき、これは特に当てはまります。 タスクを測定するシステムは一般に価値がありません。 通常、これは時間単位の人件費、締め切り（およびそれに着手する）、そして実際には解決されたタスクの一部です。 このデータに基づいて効果的に管理することは不可能です。

情報要件を策定する管理の部分、すなわち 数字、それらを取得する方法、再現性、品質、研究の深さなど

図は高品質である必要がありますが、そのようなものはめったに見られません。 これについてはすでにいくつかの記事を書いていますが、繰り返しはしません。 私の言葉を聞いてください。基準を頻繁に制御しても、非常に高品質の数値は見つかりません。 おそらく、誰もウィキペディアの記事の管理記事を読んだことがないからでしょう。

したがって、ボトルに制御が現れました。 それは普遍的であり、今後、あらゆる技術で必要とされるあらゆる数の形成を制御しました。

境界管理

境界管理、または境界管理は、ビジネスシステムの変換に関するあまり知られていない科学です。 おそらく何かが既に変わっているかもしれませんが、私は数年前にそれを研究しました、エリック・トリストと他の誰かの作品に関する記事によると、私はその名前を覚えていません。 インターネットは、このトピックに関する英語の本があると言っています-何も言えず、読んでいません。

一番下の行は非常に単純です： 境界線 。 内部のビジネスシステム、プロセス、1人でも-多くの境界。 肉体的、感情的、エネルギーなど

境界線は良くも悪くも有用で有害です。 プロセスの通常の流れを妨げるものもあれば、混合ストリームを2つの部分に分割して、処理を高速化するものもあります。 人を必要な情報から隔離して時間内に反応するのを困難にする人もいれば、不必要な情報から人を保護し、邪魔されないようにする人もいます。

要するに、国境とその管理は非常にクールです。 これを理解するには、試す必要があります。 あなたのような知的な人々にとって、それを適用し始めるために重要な原則を理解するだけで十分です。 残りにはケースと特定のプラクティスが必要であり、実際には多数あります。 それらはインターネット上にないだけですが、私たちは自分でそれを発明しなければなりません。

出版された氷山と水泳レーンの方法からいくつかを思いつきました。

境界管理は、ボトル、およびそのほぼすべての部分、つまりタスクライフサイクルの管理、優先順位の編成、定期的な管理に非常に強い影響を与えました。

日曜大工の地獄

彼はこのセクションを同じ名前の出版物と同じと呼びました。 これは、蓄積された知識に基づいて注文、メモ、計画、プロジェクトを管理するシステムを構築した最初の経験でした。

記事はもっと否定的に聞こえますが、経験はかなり成功しています。 システムを構築する際には、制御、境界管理、および氷山（ビジネスプログラミングから）の原則が主に使用されました。 もちろん、それはあまりにもテクノクラティックであることが判明しましたが、その有用性における経験は膨大でした。

まず、それはプログラマーの小さなチームのためではなく、会社全体のためのシステムでした。 第二に、システムはその目標を達成しました-それは、以前は前例のない高さに経営規律を高めました。

しかし、私にとっての主なことは、プログラマーではなく、一般の人々でボトルの一部を大規模に実際に使用することです。 結果によると、方法論から何かを捨てなければなりませんでしたが、いくつかの方法はそれらの有効性を証明しました。 もちろん、大部分は制御します。

体系的思考

これは私についてではなく、体系的思考と呼ばれる知識の分野についてです。 それは本やケースでいっぱいですので、私は再試行しません。 ボトルに大きな影響を与えた非常に重要な原則が1つだけあることに注意してください。それは、出現するプロパティまたは出現するプロパティです。 これらは、オン状態でのみ表示できるシステムのプロパティです。

あなたがシステムから離れて座って、それがどのように機能するかを空想している間、あなたは新しい特性を見ません。 公共の場でもデザイン、描画、プログラミング、テストを行うことができますが、実際の作業でシステムを起動すると、緊急プロパティが機能し始めます。

たとえば、ある人がタスクを実行し、別の人がタスクを実行することを引き受けると仮定します。 まあまあ。 二人目はタスクを単に見ないかもしれません。 そして彼が見れば、彼は読まない。 そして、彼が読んだ場合、彼は彼が読んでいないと言うでしょう。 または理解していません。 それとも彼の仕事ではありません。 等

または、チームではコーディネーターがボスだと思っていました。 彼にワークステーションが提供され、彼が出演者に配布する着信タスクのリストが提供されました。 システムを起動すると、それは気の毒なものを配布するのではなく、会議や企業関係者の周りでのみ実行されることがわかります。 そして、タスクは、隅に座っている、目立たない静かな男-隠されたリーダーによって分配されます。 そして、彼は気づかなかったという事実に腹を立てて、あなたのシステムの実装を妨害し始めます。

これらは緊急プロパティです。 投機的デザイン中には表示されず、システムの起動時に表示されます。

「創発的特性」は、誰もが理解している現象に名前を付けるために誰かが思いついただけの抽象化であることは明らかです。システムを起動する必要があり、アーキテクチャ設計エラーから些細なバグまで、何かが出てきます。

しかし、タスク管理の場合、私たちは常に、自動化、管理、関係を持つ人々、チームの目標、顧客、管理者などで構成される統合システムを扱います。 タスク管理の成功は、程度はさまざまですが、すべてのコンポーネントに依存しており、それらのいずれも無視できません。

そして、例えば、あなたがタスク管理を自動化するプログラマーであるなら、あなたはできるだけでなく、多くを無視するでしょう。 簡単です。 したがって、システムは動作する場合と動作しない場合があります。 バグはありませんが、意味もありません。

そして、私はそれが機能することを望んでいました。 したがって、基本的な原則の1つとして、また特定のアクセントと実践の両方として、体系的な思考をボトルに追加しました。

サムライコーデックスと5つのリングの本

奇妙に聞こえますが、ボトルをボトルにしたのはこれらの本でした。 ここで簡単に説明します。

人生のまともなsaがこれをやった。 最初に私はいくつかのマスターと一緒に武道を勉強しに行きました。 彼は彼を超えるまで勉強しました。 そして、ここには、特定の学校の技術を所有するまともな武士がいます（例え-PMBOK）。

彼は学校を去り、新しい挑戦を求めて古代日本を離れました。 決闘のために地元のマスターと呼ばれるさまざまな学校に行き、その結果に基づいて決定を下しました。 マスターがサムライよりも弱いことが判明した場合-まあ、運命ではありません。 サムライが負けたら、彼はひざまずき、彼を学生として連れて行くように頼みました。 そして、彼は再び主人に勝るまで勉強しました。

これは数回続きました。 そして、ある特定の瞬間に、saは彼自身のスタイルを持ちました。

一般的に、彼は誰にでも生まれたわけではありません。これは正常なことです。 いくつかは「顔のない」ままで、いくつかの有名な学校（このタイプのMBA）のマスターでしかありませんでした。

そして、最初の学校に入学する前から独自のスタイルを思いついた人もいました。 たとえば、日本の宮本武蔵の国民的英雄の1人、2本の剣のスタイルの発明者、5本の指輪の著者です。 または極真会空手学校の創始者である韓国国民の大山増達。 どちらも、キャリアの始まりのどこかで彼らの方法を発明し、それを磨いた。 それと、途中のもう一人は、より強力なマスターに出会い、彼らから学ぶために残った。

しかし、一方も他方も、特定の瞬間に強く見えた見知らぬ人と交換するために機器を離れませんでした。 彼らは単にテクニックを強化しました。

そして、最終的には、世界中のすべての人を破ったまともな武士が自分の学校を開いた。 そして、他のサムライが彼に来て、誰かが勝って去り、誰かが失われて留まった。 無限へと続きます。 大山増達は、一般に、人々の間に敵を見つけられず、何らかの理由で雄牛を殺し始めました。

ですから、この本を読んだ後、私は自分が何をしていたかを最初に理解しました。 私は、まともな武士として、徒歩圏内にある学校から始まりました-PMBOK。 それから彼は他の学校を追加し始めました。 確かに、私はまともなサムライに対して下品なミスをしばしば犯しました-私は銀の弾丸を求めて、練習を組み合わせずに、互いに交換しました。 PMBOKは適合しません-私たちはそれを捨て、CORE PMを取ります、それはうまくいきません-私たちは再びそれを投げ、スクラムに自分自身を投げます。 そのため、私は戦術を変えました。新しいプラクティスを実験として適用し、何が起こるかを確認し、最も成功したソリューションをボトルに残しました。

ビジネスプログラミング

ビジネスプログラミングは、ビジネスを改善するための一連の簡単な方法と実践です。 少なくとも全体、少なくとも特定の部分。

ビジネスプログラミングがボトルと並行して開発されたため、ネイティブIT部門を除き、改善の対象がすべてでした。

しかし、ある特定の瞬間に、突然理解が訪れました。 まあ、私はまったく正しくありません。 私はプロセスを改善する方法を知っており、独自のプロセスをいくつかの外国の方法で苦しめています。

一般的に、彼はビジネスプログラミングを適用し、彼の人生で初めてプログラマの効率の測定可能な増加を、そして即座に-2倍受けました。 変更は、プロセス、動機、目標、管理システム、および自動化に関係していました。 一般に、ビジネスプログラミングが機能する5つのコンポーネントすべて。 私たちは自分で作品を作りました。

その結果、私、プログラマー、経営陣、そして動機付けシステムの専門家に感銘を受けました。 しかし、まともな武士ではない私は、売却時にスクラムに関する本を買ったので、すべての結果をゴミ箱に捨てました。

スクラム

この世界には2つのスクラマがあります-善悪。 正しいものは、Jeff Sutherlandの本に記載されています。 間違っている-いわゆる スクラムガイド、および著者は同じジェフサザーランドをまだリストします。

正しいスクラムでは、作業を4倍に加速することが可能であり、必要です。 間違った人は何も言わず、ただいくつかのルールを与えます。

正しいスクラムは、品質管理の日本の手法への言及を正直に提供し、それらをスクラム哲学の基盤の1つと呼んでいます。 特に、彼はまともな武士のルールを使用することをお勧めします-スクラムを基礎として、独自のテクニックを作成します。 間違ったスクラムは言う-私たちがここに書いたようにしなさい。 そして、あなたが違うやり方をするなら、これはスクラムではありません。

一般に、私は本を取り、書かれているとおりにすべてをしました。 ボード、ステッカー、集会、回顧など 結果はすべての期待に応えました-速度が2倍になりました。つまり、単位時間あたり2倍の結果が得られるようになりました。

しかし、その純粋な形のスクラムは、1つの簡単な理由で捨てられなければなりませんでした。プログラマのチームが異なるオフィスに分散し、1つのボードを使用する機会が失われました。 彼らは2つのボードを使用してしばらく苦しんでいましたが、個人的な参加を必要とする集会、回顧もあります。 したがって、スクラムは放棄されました。

しかし、最高のものはボトルに残っていました。 スクラムで最高のものは何ですか？ そうです、タスク測定システムはポーカープランニングです。 私たちの世界のプログラマーのタスクを評価するために、これ以上まともなものはありません。

これまで使用されていたクロックシステムは、格付けのインフレーションまたはデフレが常に発生するため、さらに悪化します。 ポイントははるかに安定しています。

ボトル内の残りのスクラム要素のうち、おそらく、スプリントのみが計画オプションの1つとして残っていました。 1Cで働いた人は誰でも、スプリントが最も一般的なスペースカレンダー計画であると知っています。 一定期間販売/購入/生産する必要がある一定量の製品。

スクラム、教えてくれたすべてに感謝しますが、スクラムガイドで自分の墓を掘りました。 最善を尽くしました。

ストリームスクラム

その後、会社の戦略を実行するなどの経験がありました。 この経験はプログラマーにとってユニークです-私は非常に幸運だったと言えます。 会社のほとんどの部門の仕事と、ご存知のようにさまざまな方法を変える必要がありました。

問題のあるユニットの1つは供給でした。 なぜそんなに難しいのか、まだわかりません。機能はシンプルです。 それから私はまだスクラムに興味があり、調達にそれを使用することにしました。

しかし、彼はすぐに方法論的な矛盾に遭遇しました。 プログラマーは1つです。そこでは、各タスクはユニークで、ステッカーに書いて黒板に吊るすのに十分な価値があります。 また、サプライヤのタスクは何ですか？ 100個のブッシングを購入しますか？ そして明日-再び、百のブッシングを購入しますか？ そして明後日？

要するに、ステッカーはそうではありません。 そして、燃焼図はそうではありません。 スクラムはプロジェクトの実装用に設計されていますが、プロジェクトとは何ですか？ これは、いつか終了する何らかの活動です。 この意味で、これは目標でなければなりません。

そしてここで-購入。 購入は終了できますか？ まあ、会社でのみ。 次に、購入は何ですか？ プロジェクトではなく、プロセス。 しかし、プロセスはまあまあの言葉です。なぜなら、それは何らかの完全性をも与え、実際には開始と終了の両方を持っているからです。 そして、それらの間-煙突、インターネット、キッチンでのコミュニケーション。

ロシア大統領が2008年から2012年に首相としての仕事について話したとき、答えが出されました。 彼は言った：首相になるために-無限のタスク、問題、目標の滝の下に立つ方法。 仕事は終わりません。 何人が試さないか、常に何かすることがあります。

滝とは何ですか？ これはストリームです。 そこで、フローのアイデアが登場しました。 ありがとう、ウラジミール・ウラジミロヴィッチ。

当時私はスクラムが非常に好きだったので、この名前を捨てたくはありませんでした。サプライチェーンの方法論を最初に「ドイツスクラム」と呼びました（ドイツ人は何よりも愛するコントロールに深く関与しているため） 「カザフ語のスクラム」（笑いのため）、そして最後に「ストリーミングスクラム」。

ポイントは簡単です。 サプライヤのタスクは、常に外部からのものです。販売と生産のニーズからです。 これらのタスクの優先順位システムは非常に簡単です。 そして、仕事の本質はさらにシンプルです-フェンスから昼食まで。

ブッシングが必要です-ブッシングを注文してください。 ボルトが必要です-それで、あなたは何をすべきか知っています。 など、無限に。 流れだから。

そして、ボトルに長くしっかりと詰まっている管理は、正しいメトリックと個々の指標を提供しました。 古くからの経験豊富なサプライヤーは、悲しいかな、「以前はどうだったのか」ということを話さずに、単にやり取りするだけの「女の子」よりもずっと悪い仕事をしていることがすぐに明らかになりました。

結果は、品質と達成の速さにおいて驚異的でした-1か月で、彼らは「通常の」管理の年の間に以前は達成できなかったレベルまで委託倉庫を満たしました。

さて、ここで、ある時点で、内部自動化に関するプロジェクトはありませんが、ストリームがあることがわかりました。 内部自動化をプロジェクトに分割することは慣例であり、PMBOKに対する1Snikovの大きな愛の遺産として来ました。 お金、スケジュール、予算、手続き、官僚制度があるプロジェクトが必要です。 これらすべてが内部自動化にある場合、明らかに何かをする必要があります。

一般的に、フローとその管理はしっかりとボトルに入りました。 今後、Flowconという名前は、フロー制御というフレーズからも派生していると言います。

システム制約の理論（CBT）

Goldrattのシステム制約の理論は、どのシステムにも制約、最も遅いリンクがあり、その速度がシステムの全体的な速度を決定するという原則です。 さて、この原理に基づいた一連の方法は、ゴールドラット自身と彼のフォロワーの両方によって開発されました。 たとえば、「The New Goal」という本で説明されているVelocity方法論には、TOCとLeanが関係しています。

もちろん、主要な原則はCBTからボトルに入ってきました-制限の存在とそれを扱う手段を理解することです。 「制限の削除」を意識的に書いているわけではありません。 CBTには、排除だけでなく、制限の保護、および場合によっては人為的な作成も含まれます。

TOCによって、私はタスクのフェーズだけでなく、「キット」も見るようになりました。直接実行者の作業の前後に何が起こるかです。タスクを完了するのに15分かかることがよくあり、結果の受け入れ、調整、受け入れに数日かかることは秘密ではありません。そして、これらの数日間、顧客またはタスクのイニシエーターが待っています。

タスクライフサイクル内のこれらの官僚的な段階は、さまざまな角度から分析できます。 TOCは、これらがターゲットのユニットを生成する速度から最も離れているため、これらが制限であると言います。同じ境界管理は、この問題は調整に関与する人々の間に余分な境界が存在することであると言うでしょう。これらの境界を克服するために多くの時間が費やされます。

視点は異なりますが、結果は1つです。問題は非常に長く解決されます。そして、整列はほんの一例です。そして、「ニュースレター」が法外に長い場合、プログラマーによるタスクの選択は何ですか？これは制限ではありませんか？そして、同じタイプのタスクが常に同じエグゼキューターに到達し、彼の前に超長いキューが構築される場合、エグゼキューターの間違った選択はどうでしょうか？

TOCからの特定のメソッドもボトルに入りました。たとえば、バッファーを使用して、期限がある場合にタスクがいつ動作を開始するかを決定します。しかし、CBTの主なものはもちろん、方法ではなく原則です。ゴールドラット自身が「巨人の肩に立つ」という記事でこれについて書いています。

巨人の肩の上に立って

これは、Goldrattによる有名な記事であり、その中には、彼がそのようなまともな武士が誰であるかを示すGoldrattの言葉が含まれています。私はこの記事を再度語るつもりはありません。それはインターネットで公開されています。

重要な引用のみをお伝えします。

「適用されたソリューション（アプリケーション）と、これらのソリューションのベースとなっている基本概念との間には違いがあります。概念は一般的であり、適用されるソリューションは概念を特定の環境に適応させることです。すでに見たように、このような適応は単純ではなく、ソリューションの特定の要素を開発する必要があります。覚えておく必要があります-アプリケーションソリューションは、特定の環境に関する最初の前提（場合によっては非表示）に基づいています。このアプリケーションソリューションが、元の前提が正しくない環境で機能することを期待しないでください。 「これらの初期前提を慎重に策定すれば、多くの労力を節約し、失望を避けることができます。」

あなた自身の言葉で言えば、ゴールドラットはサムライや体系的思考と同じことを言っています。空想する必要も、「永遠のスクラム」や「TOS-でたらめ」を叫ぶ必要もない、あなたはいつも間違っているからです。試してみてください。純粋な方法はあなたに合わないことを忘れないでください。それでも同じように、あなたは観察し、考え、調整しなければなりません。

観察

さまざまなチームでボトルを紹介して、よく見ました。これは単純で興味深いだけでなく、有用でもあることが判明しました。そのため、ボトルには、私自身の発明の方法、実践、ライフハックが豊富に含まれていました。私は新しいものを発明していないことを正直に理解しており、おそらくいくつかの方法はそのような方法を説明していますが、すべての本を読むのに十分な寿命はありません。

たとえば、タスクを選択することの破壊性について多くのことが書かれています。そして、タスクが選択されているが、それを実装する方法を決定する必要がある場合、プログラマーは、例えば、時間が適切になるまで多くの時間を費やすことができ、最初に利用可能なオプションを選択しません。

ジェダイのテクニックの作者であるマキシム・ドロフェーフが面白い絵で書いたように、* opuで締め切りが行われるのを待つのはどういうポイントですか？

私は、自分自身と他の人の両方で、問題の解決策を選択するのに数日かかることを繰り返し見てきました。さらに、オプションは、パフォーマンス、最適性、ユーザーの利便性において完全に同一にすることができます。しかし、何かが解決策を許さない、それだけです。仕事-15分間、そして反射-まるでロケットを作っているかのように。

そのような例は数多くあり、それらはすべてボトルに影響を与えました。そして彼らは影響を与え続けます、なぜなら 私自身の観察が本より悪くないことを理解したら、私はもうやめられません-完璧に制限はありません。

無慈悲な自動化

一度、すべての知識を山に集めて、新しいバージョンのタスク管理システムを作成し、ボトルのすべての知識を適用し始めて、予想外の結果を得ました-プログラマーのチームの生産性は4倍になりました。-おそらくまだテーマに関する私のレポートのビデオだけで怠惰な見ていない時間と2を。

実際、この経験から、ボトルをテクニックとして配布するようになりました。私は情報と方法を体系化し、ボトルとその方法に関する記事を書き、私の実践について話し始めました。

新しいシステムの準備

その経験の後、私は純粋にソフトウェア会社に切り替え、そしてもちろん、ボトルを使用する練習を続けました。しかし、興味深い課題にぶつかりました。タスク管理システムを持っていなかったため、4倍の加速が得られました。

最初に、1〜2日で座って簡単なアナログを作成しました。方法論を知っていれば、これは問題ではありません。特に、利便性やインターフェースなどを選択する必要がない場合はそうです。

しかし、私たちの会社はGitHubを介して顧客と通信したため、このシステムを長時間使用する必要はありませんでした。知っているなら、Issuesと呼ばれるある種のタスク管理もあります。

課題はさらに興味深いものになりました。システムを最初から作成することと、方法論の要件を満たすように既存のシステムを調整することはまったく別のことです。その中で何も変更できないという事実にもかかわらず、標準のインターフェースとAPIのみが利用可能です。

そこで、私はAPIから始めました。それはまっすぐにシックだと言うことではありませんが、十分なデータを提供します。最初の問題は、問題の評価を数字の形で示すことができないことでした。ラベル（ラベル）から抜け出す必要がありました-それらは文字列型ですが、外部スクリプトで数値に変換できます。私はこのスクリプトを作成し、数か月間使用しました-彼は有効性のグラフを描きました。

しかし、GitHubでは解決できない問題があります。たとえば、優先順位付け。タグがあり、マイルストーンがあり、プロジェクトがあります。理論的には、どのタスクがより重要かを特定することは可能ですが、この情報を使用することは非常に不便です。ラベルで並べ替えることはできません。 APIを介してタスクを引き出し、正しいリストをソートして表示する別のスクリプトを作成する必要があります。

一般に、ブランチは行き止まりであることが判明しました。私は他のオンラインタスク管理システムを調べました-問題は似ています。データを入力および保存する機能はどこにでもありますが、構成ツールはほとんどありません。つまり、構成によってデータが制御システムに変わります。どこにでもAPIがあり、それを介して独自のシステムを構築できますが、質問は-なぜ彼らのシステムなのでしょうか？データソースとして？

このジレンマは私の頭の中に数ヶ月間座っていました。するかしないか？独自のブロッチを作成して、GitHubにこの手法を適用しますか？または別のシステムに？純粋な形では、誰も適切ではありませんが、合理的な時間に誰も適応させることはできません。はい、すでにうんざりしている外部スクリプトを使用します。

しかし、ジレンマにもかかわらず、この経験は成功しました。ボトルはかなり短命ですが、それ自体で非常にうまく機能し、作業を加速しました-最初の4倍、次に6に達し、10に達しました。ボトルはすでにすべてを証明しています。

別の新しいシステムへの移行

それから、私は世界に1Cがあり、1Cのような素晴らしい製品であることを思い出しました：ドキュメントフロー。誰も知らない場合、これはプロセスを構成できるプログラムです。したがって、それ自体には方法論は含まれておらず、テクニックのみが含まれており、誰かがテクニックを伝える必要があります。

ここでは、次の1Snu会議のために人々だけが集まり、私はそこに参加することにしました。私は標準の空の1C：ドキュメントフローを取得し、その中に独自の方法論、つまりボトルを設定し始めました。名誉と賞賛1C：ドキュメント管理-セットアップには数時間かかり、ボトルに非常によく対応するかなりまともなタスク管理システムを手に入れました。

彼が話した会議で、人々はそれを気に入り、多くは技術に興味を持ちました。確かに、タスク管理に1C：Document managementを使用している人はほとんどいないことが判明しました。私にとっては驚きでした。何も適切に構成できないオンラインシステムを利用し、内部にはわかりやすい方法論も効率性の概念もありません。まあ。

結果はまだ肯定的です。彼は、GitHubのタスクの使用と相まって、ボトルを他のシステムに完全に統合できることを示しました。そこで、コンサルティングと、独自のシステムでチームを加速するいくつかのプロジェクトを手に入れました。

独自のシステム

コンサルティングはもちろん楽しいですが、長くて費用がかかります。ほとんどの人は、あまり役に立たない古いタスク管理システムを捨てるのをあまり残念に思っていません。まあ、人々は2つを1つにしたいと考えています-そして、方法論と、「すべてが方法論に従っている」プログラム。

したがって、私たちは明確にボトルの下で鋭くされたタスク管理プログラムを書くために座った。設定によってプログラムからボトルが追い出される可能性があるため、設定はほとんどありません。これは、ノートブックのような次のタスク管理システムになります。

興味深いことに、プログラムの開発はすぐに方法論にフィードバックを与え始めました。いくつかのことはボトルから捨てられなければならず、いくつかは-追加、何か-変更されました。もちろん、私たち自身もすぐにGitHubからFlowconに移行しました。

そして再び流れる

私は会社を経営したことがありません。実際、私はまだ私が担当しているとは言えません。ここには2人がいて、権利と責任は約半分に分かれています。しかし、開発や実装だけでなく、会社の生活のすべての問題に対処する必要があります。

ソフトウェアとサービスの開発、古い製品の完成、新しい顧客の紹介、サービスなしの純売上、古い顧客のサポート、マーケティング、交渉、セミナーとの展示、お金などの家庭問題などがあります。要するに、私たちは小さな会社です。

この状況により、ボトルを再考し、2つの新しいエンティティ、フローとバランスを導入しました。

私がしなければならないあらゆる種類の活動はストリームです。たとえば、新製品をプログラムし、実装に関する顧客の問題を解決し、記事を書く必要があります。私はプログラマと同じように情熱的な人間なので、それほど難しいことではありませんが、これらのスレッドを切り替えることには非常に消極的です。

たとえば、新製品を開発するために座って、1週間外に出たいと思います。どうなるの？悪魔は新製品が売れ始めたときにそれを知っているので、お金はありません。クライアントと連携するように切り替える必要があります。

同じサービスでビジネスを構築するのは非常に危険なので、クライアントとの仕事に夢中になった場合、崩壊も起こります。

さて、記事を書くことに関与してください-一般的には単に吐き出します。しかし、それでは食べ物もお金もありません。したがって、あなた自身を抑制する必要があります。最初は彼は思いつきでそれをやったが、彼はしばしば誤解され、持ち去られ、失敗を受け取った。そして、これらはフローであり、すべてが適切に配置されていることに気付きました。

測定および計画できるフローがあります。たとえば、月100時間-サービスの場合、300ポイント-新製品の開発の場合、およびその間に-4つの記事。各ストリームには、独自の単位と測定方法、および独自の目標があります。また、ボトルはこれらのフローのバランスを取り、会社の均一な発展を保証する必要があります。

もちろん、3つのストリームではなく、私たちとあなたの両方のストリームがあります。そして、現在の状況や消火ではなく、戦略に基づいて持続可能な開発を望む人々のために、すべてのバランスを取る必要があります。

そのため、ボトルはタスク管理技術から企業管理技術へと進化しました。まあ、それはすでにまっすぐになっていない-このプロセスはまだ進行中ですが、結果は印象的です。

開発管理

以前は、箱入りまたはサービスの大量使用ソフトウェア製品の開発に対処する必要はありませんでした。したがって、ボトルには、これらのタイプのアクティビティに固有のメソッドは含まれていませんでした。

問題が発生したときにギャップが明らかになりました-私たちは多くのことを迅速に行い、製品は市場に参入しません。彼らがスクラムについてのジョークで言うように、私たちがそのような速度でどのようながらくたをしているのかを理解することは残っています。

リリースの概念を導入し、それらに基づいて優先順位付けのシステムを再構築するには、ボトルを調整する必要がありました。結局、リリースはプロジェクトではなく、タスクではなく、リリースを行うために実行する必要がある他のタスクの一種のコンテナです。そして、リリース、特に最初のリリースが市場に参入しています。それが起こるまで、誰も製品を見ることができず、したがって、フィードバックもお金もありません。

他に誰が忘れた？

締めくくる時だと思う。この場所を読んだ場合、あなたは多くの尊敬を持っています。まだあまり書いていませんが、主なものは、この資料に反映されていました。

ボトルに影響を与えた多くのテクニックとプラクティスがまだありますが、それらはリストしません。おそらくいつかは、用語集や参考文献のリストのようなことをするでしょう-あらゆる種類の科学的アプローチ、引用インデックス、および「世界的に有名なテクニックへの依存」を強く尊重する人々のために。

はい、ボトルに有用なものを取り出したが、この記事では言及しなかったメソッドの著名な著者には、心からおpoび申し上げます。

結果は何ですか？

その結果、ボトルがあります。これは、効率を改善する最良の管理手法の爆発的な混合物です。そして、効率を高めるためにまさに存在します。

私にとって個人的に重要なのは、シーケンスではなく、混合物です。すべての方法を適用できます。選択できるのは1つまたは半分のみです。どの方法でも、それ自体で効率が向上します。もう1つ、もう1つ少ない。

すでに記事で述べたように、長年の実践の中で、私はさまざまな企業、さらに重要なことにはまったく異なるタイプの人間の活動でボトルの一部を試してきました。プログラマー、設計エンジニア、質の高いサービス、供給、販売、生産、会計士、経済学者、経営者、そして誰が地獄を知っているのか。

職業ごとにボトル用の独自のメソッドセットと、自動化が必要であることは明らかです。ただし、すべての人に適したキットを選択できます。しかし、最も重要なのは、ボトルが開発中であり、ペースが加速していることです。彼は私の練習の限界を超え、他の人、企業、職業のフィードバックですぐに豊かになり始めたからです。

公開された資料から1つまたは2つのアイデアを取り入れて実践した人もいます。特に興味深いのは、彼らがこれについて私に書かないことです。しかし、彼らが偶然フォーラムや会議のどこかで交差した場合、彼らは正直に彼らの経験について話し、彼らはボトルからアイデアを得たと言って恥ずかしがりません。

だから、すべてがうまくなります。