ソフトウェア業界のアジャイルが標準になりました。 なぜなら、今日、高い不確実性と要件の可変性の条件でプロジェクトを管理できる方法論は他にないからです。」
ジャーナリストのアナリスト、スタニスラフ・マカロフによる記事。
そして、ここにワークフローはありますか？
インバウンドとアウトバウンド、メモ、会議議事録、およびその他の官僚制度など、従来のワークフローを使用してソフトウェア製品を開発するためにプロジェクトを管理する必要がある場合を想像してください。 期限と予算を満たすチャンスは何ですか？ そうです、ゼロ。 パフォーマンスの最も厳しい制御でさえ助けにはなりません。 プログラマーはローファーやスロベニアであり、時間どおりに仕事をしたり、変な服装をしたり、不可解なことをしたりすることさえできないためです。
問題は方法論自体にあります。事前にすべてを予測し、実行者に何をすべきか明確な指示を与えることが可能であると想定されています。 理想的なシステムでは、これは機能する可能性がありますが、残念ながら、ほとんどの場合、計画から多くの逸脱があります。
これは、各変更を階層チェーンに沿って調整する必要があるため、システムが失敗し始める場所です。 プロセスのすべての参加者は、最終的に極端にならないように責任を統合することを好みます-イニシアチブは罰せられます！ たくさんの小さな質問が上司に降りかかり、彼はそれを個人的に解決する必要があります。 意思決定のサイクルが延長され、締め切りは延期されます。また、後で誰かを特に指名しない限り、有罪の当事者はいません。 コマンドおよび管理システムには、状況の変化、プロジェクトの実施で遭遇した困難、または新しい顧客の要件に対応する時間があるため、十分な柔軟性がありません。
要するに、ボスは常に正しい。 正しくない場合は、ポイント1を参照してください。 誰もが座ってガイダンスを待っているので、水平通信は機能しません。
ワークフローは、見た目ほど無害ではありません。 実際、これは厳格な階層、イニシアチブの防止、チームワークの欠如に基づいた経営概念の具体化です。
一般に、それは「分割して征服する」という古典的な原則に帰着します。
ワークフロートラップ：デュアルパーパスSED
組織が少し成長すると、すべてが「大きなもの」のようになるようにワークフローを導入することを夢見始めます。 ドキュメント内の順序が必要であると主張する人はいません。さもないと、1時間も経たないうちに、あらゆる種類の管理機関が登場したり、クライアントからの重要なドキュメントがストリームで失われたりします。 これはすべて正しいです。最悪の症状で国家の官僚機構のコピーを開始しないでください。
大きく取ると、EDMSは2つの機能領域をカバーします。
- 組織の文書化;
- ビジネスプロセス管理。
これは歴史的に起こり、今では槍を打ち破る意味はありません。それが正しいかどうかは関係ありません。 事実として考えてください。
EDMSは、ドキュメントリポジトリ（Document＆Records Management System）と組織管理システム（Workflow＆BPM、Collaborationなど）の両方であり、さらに、主にソビエトの機関に基づいたシステムを使用する慣行があります。 IDC調査の組織の半数以上が、EDMSをビジネスプロセスの自動化手段と呼んでいます。 （2番目はERPであり、実際のBPMシステムは最後にあります。）
そのため、アクティビティを文書化する必要があります。 そうでなければ、ライセンス、認証を失い、契約を保存し、失い、神の禁じられた個人データやその他の重要な何かを簡単に失う可能性があります。 しかし、ドキュメントとプロセスを同一視する必要はまったくありません。
プロセスを個別に考えてください。 時代遅れの伝統のtrapに陥らないでください。 結局のところ、「効果的なマネージャー」の主なスキルは、他の人、ほとんどの場合は部下に責任を負わせることです。 EDMSのイデオロギーにおける「チーム」の概念は完全に存在せず、企業または州の機械の「実行者」、車輪、および歯車のみが存在します。
さて、注意、質問：このような官僚的な環境で開発される少なくとも1つの本当にクールな製品に名前を付けることができますか？
質問2：ソフトウェア開発は他のタイプの集団活動と根本的に異なりますか？ では、開発チーム以外のアジャイルをすべての組織のビジネスプロセスに適用してみませんか？ 悲しいかな、ここで私たちは誤解のほとんど乗り越えられない壁に直面しています...
トルコの天文学者の物語
経営はビジネススクールで教えられます。 それだけです、ポイント。 IT担当者はプロセス管理について何も知ることができません。彼らの仕事はプログラミングです。 MBAコースがアジャイル方法論について話さない場合（そして、これはそうです！）、庭にフェンスを付けることは何もありません。 星の王子さまのトルコの天文学者の物語に非常に似ています。
私たちの場合、ジャケットとネクタイでさえ助けにはならないのではないかと心配しています。 お客様は、最新のITシステムを使用して時代遅れの管理方法を実装することを主張し、ITからの新しい方法論を受け入れる準備ができていません。
プログラム開発に関連する従来の管理の非効率性は、ずっと前に発見されました。 IBM OS / 360を作成するプロジェクトの管理の難しさと、より多くのプログラマーを惹きつけてプロジェクトを加速する試みの失敗に関するFrederick Brooksの本「Mythical Man-Month」は、1975年に出版されました。 それ以来、ほとんど変化はありません。マネージャーは、人々の数を増やすか、「パフォーマーを交換する」ことで問題を解決できると誤って信じています。
神話上のマン月
少なくとも2つの理由から、プロジェクトのリードタイムはプログラマの数に反比例しません。
- プログラミングでは、たとえば綿の摘み取りとは異なり、作業をwork意的にいくつかの独立した部分に分割することはできません。 プロジェクトの一部は互いに依存しており、一部のタスクは他のタスクが完了した後にのみ開始できます。
- プログラマーは、互いに対話するのにある程度の時間を費やすべきです。
プログラマーがN人いる場合、プログラマーのペアの数はN（N-1）/ 2です。つまり、プログラマーの数が増えると、インタラクションに費やされる時間が二次的に増加します。 したがって、Nから始めて、プログラマーの数が増えると、プロジェクトの実行が遅くなります。
締め切りに間に合わない場合、新しいプログラマーを雇うとプロジェクトが遅くなるという別の理由があります。初心者には学ぶ時間が必要です。 この本はブルックスの法則を定式化しています：
プロジェクトが期限に間に合わない場合、労働力を追加するとさらに遅れます。
非常に多数のプログラマーがいる場合、プロジェクトはまったく完了しない可能性があります。一般的な混乱により、ソフトウェアの既存のエラーを修正しようとすると、新しいエラーが発生するため、システムは改善されません（第2章）。 （ウィキペディアで引用）
プログラマーをエンジニア、技術者、B2Bセールスマネージャー、ビジネス開発スペシャリスト、翻訳者、弁護士、デザイナーに置き換えてください。同じイメージが得られます。 最終結果がチーム内の人々の相互作用と顧客との関係の構築に依存している場合、ブルックスの法律は機能します。 言い換えれば、作業に知的要素がある場合はどこでも、リソースの機械的なスケーリングは役に立たない。 そして、手ごわい注文は、すべてを時間通りに行うのに役立ちません。そうしないと、全員を解雇します。
これが紛争の本質です。現在の管理慣行は、機械的なスケーリングが機能する生産および軍隊の管理タスクから成長し、結果は請負業者の人格にあまり依存しません。 機械にどんな労働者がいるかは気にしませんよね？ そして、「知識労働者」と呼ばれる従業員のこれらのカテゴリーでは、このようなトリックは機能しません。 ある翻訳者が翻訳し、別の翻訳者が翻訳する書籍の半分を割り当てることはできません。 弁護士は1件の聴聞会に順番に出席することはできません。プロセスに関与するには時間がかかります。 だからこそ、作品の創造的で集合的な性質を考慮した管理方法が必要です-そのすべての現れでアジャイル-スクラム、かんばん、リーンなど
ベストプラクティスが常に優れているとは限らない理由
EDMSと「ドキュメント管理」管理パラダイム全体を絶対的な悪と見なすことは、非常に誇張されます。 もちろん、これが非常にうまく機能する領域があります。 しかし、官僚的な手順の使用が厳密に禁忌であるものがあります。 （ほとんどの読者が自分の経験から知っているように、これにはソフトウェア開発が含まれます。）
しかし、違いは何ですか？
方法論の適用可能性は、制御オブジェクトの性質、自動化するプロセスによって決まります。 Cynefinフレームワーク（「キネビン」と発音されるのは、デイブスノーデン教授によって発明されたウェールズ語です）は、単純、複雑、複雑、カオスの4つのドメインを定義しています。 各ドメインには独自の法律と規制があります。
EDMSがSimpleドメインで非常にうまく機能し、さまざまなルーチン手順を自動化すると想定するのは簡単です。 このドメインの主な特性は、明確で理解可能な因果関係です。 つまり、規制を作成したり、基準を設定したりできます。 ここの人々は交換可能であり、最小限の訓練を受けたオペレーターを配置でき、プロセスの品質は変わりません。
次のドメインである複雑（複雑）は、機械的な複雑さによって特徴付けられます-一見すると明確ではありませんが、見れば、すべてが論理的で予測可能であり、システムが適応する小さな変動も可能です。 ドキュメント管理の実践から、例として契約を管理するプロセスを挙げることができます-理論的には、承認と承認プロセスを非常に慎重に説明できますが、実務上、ビジネスに利益がある場合、規制に反して決定を下すことができることを誰もが理解しています。
このドメインでは、何らかの例外的な状況が発生するまで、EDMSは引き続き正常に機能します。 例外的な状況が多すぎる場合、リーダーが個人的にすべてを操縦しようとすると、組織は「手動制御」モードに入り、事実上、ベストプラクティスが機能しない複雑なシステムの領域で、過去の経験のある複雑な領域で自分自身を見つけます繰り返される場合は、毎回何らかの形で変更されます。 「同じ川に二度入ることはできない」ということを覚えていますか？ まさにそのような場合。
ほとんどの組織システムはまさにそれです。 戦略的管理、事業開発、革新、製品の発売、マーケティングなどに関連するすべて など -一般に、さまざまな参加者の利益相反が潜在的に存在する、形式化が不十分なすべてのプロセスは、複雑なシステムと見なすことができます。 したがって、部門や部門が共同の努力を必要とする問題を解決できない「白鳥、ガン、カワカマス」の状況は非常に一般的です。
複雑なドメインでは、EDMSベースの管理アプローチがカテゴリー的に有害になります。 「あなたの着信に反応して-私たちの発信」-そして少なくとも100回連続して、ケースだけは動きません。 官僚的なパラダイムの枠組みの中で最も重要なことは、責任を他の誰かに押し付けることであり、共通の理解に至らず、最適な解決策を見つけることです。
アジャイルECMおよびアジャイルBPM
アジャイル手法は、おそらくITからの最も価値のあるビジネスギフトです。 ビジネスだけがこれを手に入れる準備ができていないため、アジャイルをパルチザン方式で実装し、製品に新しい機能を追加し、新しい作業方法のサポートに焦点を当てる必要があります。 これらのイノベーションは、経営陣が好意的に見ているビジネスプロセスの柔軟性と適応性の旗の下で企業に浸透します。それは時代の精神に沿ったものでなければなりません！
実際、これは、作業を整理する以前の方法の下で定められた、真に破壊的な革新、時限爆弾です。 新しいECMおよびBPMシステムは、通常の「パワーバーティカル」を否定することなく、チームでの水平方向の相互作用をサポートすることを目的としているため、最終結果と測定可能なKPIに焦点を当てた特定のビジネスタスク用のアプリケーションを迅速に作成し、メッセージングおよびその他の情報ツールを組み込みます-ソーシャルネットワークのように、誰にも言わないで（shh！）
合計すると、ソフトウェア開発者のアジャイルマニフェストを少し言い換えることができ、EDMSのそのようなアジャイルマニフェストを取得できます。
ところで、アジャイルECMとアジャイルBPMという用語はすでに広く使用されており、多くの企業が製品をリリースしてアジャイルクラスに位置付けています。 氷が壊れた！