大丈夫、落ちる

読み始める前に、大企業についてどれだけの感情を述べているか考えてください。 それはドライブ、革新、運動、あるいはむしろ官僚主義、保守主義ですか？ そのようなアイデアがどこから来たのか、それについて何をすべきかについて話しましょう。







カットの下- 大企業で柔軟な管理方法論を導入する試みについての劇的な物語。



この記事は、Web-scale IT Conference 2017 での Dmitry Smolyarovのレポートに基づいています。Dmitryは、特に15年以上にわたって大規模なホールディングで働いており、特にRusHydroのIT部門を率い、企業のマシンの構造を直接知っています。 彼の話は、企業顧客とのやり取りのプロトコルをよりよく理解するのに役立ち、このプロトコルがどのように違反される可能性があるかを知らせます。 行こう！

なに？

まず、話をしたいです。 むかしむかし、若いエンジニアとして、私は野心的なタスクで広大な国の水力発電所の1つに到着しました。それを3日間で一般的な企業スペースに含めることです。



ニコライ・イワノビッチという名前の素晴らしい男に会いました。 このように私の外観に反応したのは、強力なビジネスエグゼクティブでした。







確かに、彼はすべて順調です。すべてが調整され、すべてが安定して機能し、ITシステムが詳細に文書化され（特に驚くべきことです）、すべてが安定しています。 そして、突然、誰かが侵入し、この経験豊富な経営幹部がすべてを変えるための迅速で異常な方法を提供します。 私は強力な抵抗に会いました。 これは、大企業が何を必要としているかを理解するきっかけとなりました。



ドライブ、ドライブなどが頻繁にないのはなぜですか？ -大企業には異なる優先順位や他の価値があるため。

大企業の主なリスクと動機

• 保護 -大企業は常に自分自身、資産、および投資を保護します。

常に多くのリスク要因と、会社に加わり、その費用で「餌をやりたい」人がいます。

• 安定性と予測可能性 。

多くの場合、最先端のイノベーションや革新的なソリューションではなく、保証された結果が必要です。 大企業は革命をあまり好きではありません。

• また、それは常に他人のお金です。

意思決定者が他人の資本を管理し、あなたが自分の行動を説明し、彼らの決定について所有者と規制当局に説明責任を果たす必要があるときが来ます。



これは、ITシステムを実装するときに次のような多くの結果を引き起こします。

• 請負業者の慎重な選択 ;
• よく考えられた合意は、 ゲートのシステムです （プロジェクトを継続する可能性、投資を保護する能力についての決定点）。
• 定義された制御点 。
• 既存のソリューションとの継続性を確保します。
• レポートとドキュメント！

決定を下し、コントロールポイントを渡すには、常にレポートドキュメントの準備が伴います。 これは同じ報告であり、大企業の官僚制度に最もよく関連付けられている文書そのものです。



あなたがこの場所であくびをし始めたら私はあなたを理解するでしょう。 しかし、大企業での日常生活は常にこの「官僚主義」に常に関連付けられているという事実に再び注目します。それは自然な要素であり、常にそうです。

「ゲート」-制御ツール

伝統的に、契約は各段階で完全な結果が得られるように構築されており、企業のさらなる活動に使用でき、この結果は文書化されます。 このようなドキュメントの例としては、概念的および技術的プロジェクト、民間の技術仕様、テストレポートなどがあります。



このようなドキュメントの存在は、原則として無形資産を生じさせるITプロジェクトにとって特に重要です。 そして、結果を文書化しない場合、トレースさえないかもしれません：いくつかのシステムが立っているサーバーがあり、このシステムは何かをします。 何が行われたか、この行為が何のために署名され、支払われたかは明らかではありません。 したがって、大企業でのITプロジェクトの従来の実装は、ドキュメントに記載されている結果の一貫した達成です。 それぞれが内部調整と承認を受け、完了した決定として受け入れられ、支払われます。



これはアジャイルにやや似ていますが、意味が異なります。 ITプロジェクトは、顧客企業の管理性と保護を高めるために複数の段階に分けられます。 アジャイルとは異なり、顧客に最適な結果を得ることを目指しました。

実装機能

プロジェクトの実装のもう1つの側面は、顧客経営者の行動です。 彼らの優先事項の中には、自分の実行可能性と重要性を確認し、自分の居場所を維持し、キャリアを作りたいという願望があります。 したがって、顧客は非常に頻繁にリスクを軽減し 、結果を保証しようとします 。 これは、人々と会社の従業員の両方の行動に特定の機能を課します。



通常、顧客はプロジェクトの参加者の数を制限しようとします 。 もちろん、同僚は尊敬されている人ですが、プロジェクトチームに参加することは、レポートドキュメントの承認数の増加を意味します。 実際には、プロジェクトの期間が長くなります。 意思決定に関わる人が少ないほど、社内でプロジェクトを実施するのが簡単になります。



会社が大企業の対象となるユーザーを含め、何らかの方法でプロジェクトのコストを削減しようとしていることは理解できます。 そして、リソースと見なされます。 したがって、それらは通常、実装サイクルから除外されます-ユーザーは作業するだけです。 ユーザーの意見は重要ではありません。 さらに、トレーニングはかなりの費用がかかる項目であり、トレーニングが少なければ少ないほどプロジェクトは安くなります。



別の要因は、 顧客が顧客の 役割 を 果たそうとしないことです。 多くの場合、大企業のリーダーにとって、自動化の観点から望むものを定式化することは問題です。 彼らはこれを行う方法を知らず、自動化が必要であることを理解しているだけです。

プロジェクトのコンテキスト

ここで説明するプロジェクトは、電子文書管理システム（EDMS）を置き換えるプロジェクトです。 システム自体にユニークなものは何もありませんでした。このプロジェクトをどのように実装したかは興味深いです。



プロジェクトが実装された会社は、大きな変革の過程にありました。 大幅な人事異動が行われ、ビジネスプロセスが変更され、会社のオフィスが別の都市に移転することさえありました。 同時に、同社は顧客のためにいくつかの重要なプロジェクトを実施し、その活動には約8000件の文書と34,000件の指示が伴いました。 継続的な変更にもかかわらず、中断のない運用を保証する必要がありました。



プロセスに関する会社の活動を確立し、経営規律の管理を確立するために、電子文書管理システムを置き換えることが決定されました。

すべて順調です-落ちています！

上記の大企業のすべての機能と変更のコンテキストで、プロジェクトを開始しました。







いつものように、彼らは長い間プラットフォームと請負業者チームを選択しました。 最小限の人数で構成される内部チームを編成しました。 私たちは、プロジェクトの開発や各機能分野の私的委託条件などの必須のマイルストーンを含む契約に署名しました。 一方、システムが動作する瞬間まで、 30日が残っていました。 このアプローチの結果は単純です。この時点までに取り組んだ方法を変更しない場合、結果は完全に明確になります。システムはありません。

別の方法が必要です...

この時点で、30日間のマージンがあったときに、以下を含むすべてのレポートドキュメントのプロジェクトが正式に準備されました。

• 技術プロジェクトのスケッチ;
• 概念設計のスケッチ。
• すべての個人的な技術的なタスクの下書き。

機能的な顧客によって承認された文書はありません。 それ以上の移動はできません。



すばらしいもののいくつかは言った：

「...以前と同じようにビジネスを行う場合、異なる結果を期待するのは難しいです」

したがって、私たちは別の経験をすることにしました。







多くは明確ではなく、実用的な知識はありませんでしたが、何か違うことをしようとする意欲と意欲がありました。 実装の経験もなかったため、これが企業文化にどのように影響するかは不明でした。 私たちは一つのことを理解しました：私たちが試みなければ、私たちは知りません。 そして、私たちは見つけ始めました。

• 人と相互作用は、プロセスとツールよりも重要です。
• 実用的な製品は、包括的なドキュメントよりも重要です。
• 顧客とのコラボレーションは、契約条件の交渉よりも重要です。
• 変化への意欲は、当初の計画に従うよりも重要です。

「痛み」の機能的な顧客

私たちは通常の企業文化から離れ、異なるロジックで顧客との対話を始めました。 以前は、通常のロジックで準備された計画を満たす方法を探していましたが、今度は、顧客が文書に署名しない根本的な理由は何かという質問を自問しました。 私たちは幸運で、機能的な顧客はコミュニケーションに対してオープンであり、彼の痛みと願望を理解するのに十分な情報を受け取りました。 顧客の行動を決定する主な要因は3つでした。



1つは、プロジェクトの時間の単純な不足です。 プロジェクトを時間通りに完了したいという願望があったとしても、顧客には必要なだけプロジェクトに時間を割く機会がありませんでした。 これは、職務の遂行によるものです。



二番目。 プロジェクトには、事務局長の要件によって決定される3つの主要な優先事項があることが判明しました。

• 年の初めから、会社は新しいEDSで作業を開始する必要があります。
• 四半期の結果に基づいて、新たに承認されたばかりのスタッフの動機付けシステムに従ってボーナスを計算するために、役員規律に関するレポートを作成する必要があります。
• 行政規律に関する報告書は州下院のテーブルに掲載されるべきです。

三番目。 機能的な顧客は、詳細な仕様が利用できるにもかかわらず、完成したシステムが期待を満たせなかったため、そのようなプロジェクトの実装に否定的な経験を持っているため、話を繰り返すことを恐れています。

実装

これらの要因を理解したため、レポートドキュメントの最終バージョンの準備とプロジェクトの終了時の承認を延期し、主要な結果の達成に専念することにしました。



つまり、私たちが最初に違反したのは、コントラクトポイントの通過と請負業者から顧客への責任の移行ポイントを介したプロジェクトの一貫した実装の伝統的な方法です。 機能的な顧客が文書を承認し、この責任を移転することを要求しませんでした。 彼女はこれまでプロジェクトチームに残っています。



この意味では、この場合、リスクはIT部門全体と請負業者が引き受けるため、非常に大胆でした。 プロジェクトの段階を予定通りに完了できないリスクを含みます。

ステップ1.作業およびプロジェクト管理スキームの優先順位を変更する

私が言ったように、私たちはすでにこの時までにインタビューを行っていました、一般に、システムが何をすべきかは明らかでした。 四半期の終わりにレポートを作成できる統計を収集するために、期限までにシステムの開始を準備することができました。

聴衆からの質問：上級管理職はプロジェクトが燃えていると言うことができますか、そしてあなたは署名を得ることができませんか？



この決定は、大企業の精神に基づいています-5ポイント！ 私はおそらくそれを前にしたでしょう。 しかし、私が言ったように、ChTZを準備する方法はうまくいきませんでした。 このアプローチは、私たちを導いたものへと導きました：時間がない、システムは動作するはずです。 さらに、同僚にプレッシャーをかけるのはあまり良くないが、時々そうすることもあると思う。 しかし、私たちは意識的に反対の道を行くことにしました。 主な答えはこれです。

私たちは、顧客、会社、ユーザーに適したシステムがないことを完全に意識的に理解していました。 つまり、似たようなものになりますが、そうではありません。 それにもかかわらず、彼らは何が起こったのかの操作を開始し始めました。

ステップ2.フィードバックを伴う継続的な改善システムを作成する

次のステップは、システムが顧客の期待に近い結果になるようにする方法です。 フィードバックを伴う継続的な改善システムを作成しました。







次のエンティティがあります。 プロセスを説明し、要件の蓄積者である専用の顧客担当者（私も彼に感謝します！）-プロセス管理者。 プロジェクトチーム。



パイロットパイロットと呼ばれ、命令によって確保された操作が開始されました。 システムの使用に伴い、顧客は開発の要件を策定し、修正および変更する必要があるものを示す機会を得ました。 プロジェクトチームへのタスクの結果として生じるフローは、スプリントとはほとんど言えません。 システムを完成させるための提案の長いリストがあり、それらはプロセスマネージャーによって優先順位が付けられ、実行のために提出されました。 システムの継続的な改善のプロセスが開始されました。

ステップ3.ユーザーを改善システムに参加させる

次のステップでは、システムの再構築を支援したユーザーに意識的にユーザーを含めました。 実際、プロジェクトチームの構成を拡張し、ユーザーをサブジェクトの役割からオブジェクトの役割に移行しました。







最初は、機能的な顧客を直接管理する限られた数のユーザーをトレーニングし、フィードバックを提供することを想定していました。 この変曲点に達したので、この数を増やして、すべてのユーザーがシステムの問題点を記述できるようにすることにしました。



さらに3つの情報フローがありました。

1. 質問「使用方法」短いトレーニングの結果に基づく。
2. エラーメッセージ：「システムが正常に機能しない-エラーが表示され、明確に説明できます。」
3. システムを変更するための提案。

重要な点-最後のスレッドはプロセス管理者に送られ、プロセス管理者は、どの提案を運用するべきかを決定しました。 フィルタリングされたオファーを受け取りました。



このアクションにより、エラーを特定して排除できるだけでなく、ユーザーがシステムを完成させるための要件を生産的に策定することもできました。

ステップ4.中間レベルの管理に従事する

次に行ったのは、機能的な顧客と同じレベルの構造ユニットの責任者を個別に関与させることでした。



最初に、グループ研修が開催され、中間管理職への2つの提案で終わりました。システムを改善するための提案の形でフィードバックを提供し、必要に応じて個別の研修を受けることです。 潜在的に、これは金銭的爆発につながる可能性があります。つまり、変更や個別のトレーニングに多すぎるお金を必要とする可能性があります。 実際、改訂の提案があるメモは1つしかなく、個人で勉強したい人は1人だけでした。 しかし、他の人は私たちの申し出を覚えていました。 人々は私たちの注意を見て、感情的な強さはおさまりました。



おそらく想像してみてください。原油システムはパイロットの工業運転にあり、会社は革命に近づいています-廊下に沿って火花が輝きます！ 当然、会社の経営者の意見を形成する人々にとって、そのようなサインは非常に効果的でした。 私たちは、彼らからフィードバックを受け取る意欲と、彼らと個別に仕事をする意欲を示しました。 機能的な顧客自身もトレーニングに参加し、連絡を取りました。

ステップ5.宣伝

次のステップは公開することでした。 これを行うために、この特定の実装パスを選択した理由について、企業ポータルで記事を書いて公開しました。 この記事により、何が起こっているのかを説明し、厳しい実施体制に関連して発生した発生率を減らすことができました。 さらに、システムの入り口で、すべてのユーザーがプロファイルにアクセスして意見を述べることができます。 これもまた有益な簡単なステップです。

呼び出しの減少のダイナミクス

控訴に関する小さな統計を示します。

• 変更を受け取って実装したわずか5か月で、約250件。
• これらのうち、最初の3か月で200。

最初の急増は12月で、プロトタイプを作成し、機能的な顧客からフィードバックを受け取りました。 さらに、ユーザーが接続すると、2月まで続くジャンプが表示されます。 減少傾向は、システムがどのように改善され、その変更に対する提案の数が減少したかを示しています。

いくつかの事実

数字での実装結果の概要は次のとおりです。

• システムを実装するために、3人（1月10日のピーク時）の請負業者スペシャリスト、トレーニングおよびユーザーサポートのための内部サービスのみが関与しました。
• 実装は 、他の同様のプロジェクトと比較して平均で20％高速でした。
• トレーニングの増加により、コストは約5％増加しました。
• すでに開始時には、計画された120人ではなく、 400人のユーザーが個別に接続しました（最終的には800人以上）。
• 改善のための提案がある唯一の（公式）メモ。
• NGNオペレーターは、最初のサポートライン全体を引き受けたいという要望を表明しました。

後者の事実は、人がプロジェクトに参加したいときの会社の感情的な状態の実例と考えています。 オペレーター自身がシステムの使用方法に関する質問に答えることを申し出ましたが、これは彼の機能的責任には含まれていません。

蜂蜜の樽にタールの滴

すべてがうまくいったわけではなく、困難がありました。 一方で、当社のアプローチにより、顧客がニーズを認識したときにシステムを変更するための要件を策定できることを嬉しく思いました。 一方、顧客はすぐに慣れてしまい、プロジェクトを離れなければならなかったときに「エラー」を受け取りました。 実際には、これらは間違いではなく、システムの使用方法に関する問題、または顧客が自分の要件を完全に理解しておらず、レポートを正しく読めなかったという事実の結果です。 プロジェクトの最終月に完成したすべてのイベントのうち、実際に開発者の間違いであったイベントは1つだけでした。



しかし、顧客はこの作業方法に慣れていたため、レポート文書に基づいてビザの取得に多大な労力を費やしました。テストプログラムと方法論を作成し、テストを割り当てる必要がありました。つまり、すべての大企業に共通する形式主義です。



さらに、一部のアクションが遅れて実行されたことを認める必要があります。 たとえば、パイロット制作の開始前にポータルで公開された記事は、より効果的です。

手順または人？

要約すると、このプロジェクトと通常のプロジェクトの主な違いは何ですか。 私は長い間大企業で働いてきました。私はこれらの企業の製品であり、最初はそれが手順であるという事実に慣れています。 これにより、非常に安定した関係の理解が可能になり、リスクがなくなります。 この場合、私たちは手順から離れて、顧客を彼の恐怖、特徴、優先順位などを持つ人として見ました。



このような見解により、私たちは生まれ、実行されたアイデアに到達することができました。 つまり、ここのアジャイルは、むしろツールではなく、旗、触媒、アイデアです！ しかし、このアイデアは、顧客の人を見て、その上に自分自身を向けることを可能にする心の変化につながっただけです。







次の段階では、得られた価値を維持し、プロジェクトの標準コースと標準契約を変更したいと思います。



それにもかかわらず、私たちはまだどのように回避するかを知らないルールがあり、それらを回避する必要があるかどうかさえ確信していません。 まず第一に、これは会計文書の署名の形での責任の移転のポイントであり、金額と時間の制限です。 システムを他の改訂チームに移すことができるレポート文書の形式での継承も保持されます。

飛行は続きます！

記事を締めくくりたいと思いますが、一方では、大企業が生きるルールを知り、官僚化を理解し、受け入れる必要がありますが、それらを破ることを恐れないでください。



勇敢で行動しましょう！

---

May RIT ++ Conference Festivalで講演することにより、専門家や専門家を招待して開発または実装の興味深い経験を共有します。このプログラムにはさまざまな狭いテーマ領域があり、今日のトピックに関する会議はWeb-scale IT Conference 2017 と呼ばれ、完全なリストがサイトにあります。