IT官僚

10年以上、すべての悪いことが私に起こったように見えましたが、新しいゴキブリに出会うたびに、いや、どれがより不快で、大きくて脂っこい、または小さいで多数であるかはまだ明らかではありません。



残念なことに、ロシアでの主な開発上の問題は、プロセスを設定および設定できないことであるという結論に達しました。 そして、無能力ではなく、単にプロセス自体の誤解です。 方法がわからないとき-学ぶのは簡単です。 理解していないが、理解していると思うと、すべてがはるかに複雑になります。



管理、およびプロセスに影響を与える人々のよくある間違いは、すべてが単純であると信じていることです。 ソフトウェアを作成するプロセスは、家を建てるプロセスとそれほど変わらないこと。 彼がタジク人に追いつき、彼らにフォアマン、プランの手にあるフォアマンを与え、プランの最上部がどこにあるかを示したため（灯台の代わりに井戸がうまくいかないように）、それでキャベツを切る準備ができました。



しかし、時間の経過とともに、彼らは何らかの理由でそれが機能しない、またはうまく機能しない、または希望どおりに機能しないことを理解しています。 この状況の原因の検索が開始されますが、原因ではなく結果が見つかります。 調査は原因と混同され、戦いは風車から始まります。



私は何について話しているのですか？ いいえ、LJは私から連れ去られたわけではなく、ICQはオフにされませんでした。 しかし、もっと悪いことがあります。 そして、彼らはそれほど目立っていないので、彼らはそれほど顕著ではないので、彼らはより悪いです。 これらは規則と規制です。



官僚制の害の例として、あなたは遠くに行く必要はありません、私たちは皆、私たちのごく最近の過去を思い出して現在を見ます。「官僚制」という言葉が否定的な意味合いを持っていることは偶然ではありません。 私たちの役人は、法律、法令、証明書、命令、その他のテープの助けを借りて、ソビエト（および現代）システムの歪みを修正しようとしました。 良い人生からではなく、システムの問題の根本はルールがないからではなく、システム自体にあるという誤解からです。



これは、新しい家を建てるのではなく、古い家にサポートとエクステンションが取り付けられている、古い家や貧弱に建てられた家の状況を連想させます。



しかし、それはできません！ 自分の能力を紙でカバーすることはできません。 これは、作業の外観、結果の可視性、およびプロセスの可視性を作成することにより、問題を悪化させるだけです。 これはデマです！ 何も改善されず、別のバックアップが表示されます。



あなたの無能を認めることを恐れる必要はありません。さらに、これなしでは、何も学ぶことはできません。 誰かが「賢い人だけが「私は馬鹿だ」と言うことができる」と正しく言ったように、学びたい、理解したい人だけが、彼がどのように知らないかわからないことを認めることができます。 そして、それを望んでいない人は、彼がすでにすべてを知っていることを確信し、すべての問題は周りの人々が彼の規則に従わないという事実から来ます。



しかし、一般的に、官僚主義は、クリスマスツリーに登ることは不可能であり、お尻を裂くことは不可能であるという事実の例です。 官僚制、規制、規則、および手順により、システムは戦車と同じくらい強力になりますが、速度は低下します。 そしてそれにより、その有効性と柔軟性が失われます。 あなたが防衛工場であるなら、それはおそらく価値があります。 10年間ロケットを作る方が良いのですが、飛ぶと、すごい、飛ぶのです！ しかし、ビジネスには効率が必要です。 あなたがより効率的であればあるほど、より速く市場を占有し、より多くのお金を稼ぐことができます。 少なくとも開発分野では、規制の助けを借りて効果的なシステムを作成することは不可能です。 それが、アジャイル開発手法が主に事務処理を最小限に抑える理由です。 どちらか一方。 信頼性、または速度と柔軟性。



しかし、官僚主義は生き続けています。 官僚機構は単純であり、問​​題の分析と深い理解を必要としないため、彼は生きています。 それらはすべてに等しく適用可能であり、等しく効果的ではありませんが、目に見える最も重要な理解可能な効果をもたらします。 そして、それらはそれほど目立たず、長期間現れないかもしれない多くの副作用を与えるという事実はそれほど重要ではなく、誰もが次のクロールアウトされた問題が病気のシステムの結果であることを理解しません。 目に見える効果をすぐに与えて、陰湿な官僚主義は病気を治しません;とりあえず、それはそれを内部に追い込みます。



さて、例えば...



VMwareを搭載したサーバーを含む、いわゆるテストベンチがあり、開発者のニーズに合わせてサンドボックスを作成できます。 このためにテストベンチが特別に作成され、仮想マシン自体は互いに完全に分離されています。 ただし、仮想マシンを作成するには、アプリケーションに入力する必要があります。 申請書は紙の形式のみであり、部門長の署名による証明が必要です。



テストベンチ自体の興味深い話。 TKは数か月（3または4）の間書かれ、いくつかの承認、さまざまなレベルのヘッドからの署名が行われました...システムのTKを作成するのに3か月、その実装には2週間かかります！



SVNの名前でさえ、いくつかの規則に従い、いくつかのプレフィックスが導入され、既存のユーザーの名前を変更する必要があります。 もちろんささいなことですが、そのようなささいなことがたくさんあるとき、思いもよらないところでつまずくとき、何かが再びどこかに署名する必要があるという理由だけで計画が崩壊するとき、そして書類は時々タスク自体よりも長くかかります...



紛失した場所ではなく、軽い場所の鍵を探しています



気付かないとき、2回目-イライラし始め、3回目が激怒し始めたら、これをすべて地獄に送るかどうかを考えます。 次の承認のために言い訳をするのは面倒なので、あなたは再びそのような期限までに何かをするという約束を果たさなかった。



ところで、私はまだ新しいルールの作成を奨励​​する主な動機が何であるか理解していませんか？ これはどこかで教えられているか、それはあなたのお尻を隠そうとする試みであるか、または仕事の外観を示す試みです。 おそらく、規制の著者自身もこれを理解していないでしょう。 そして、これはすべて不必要だと言うと、心から驚くかもしれません。 それは中世の領主に馬車が馬なしで乗ることができると言うようなもので、エンジンが足りないだけです。



しかし、開発チームにはエンジンがあります-これらは開発者自身です。 そして、車輪に棒を入れるのではなく、正しい方向にそっと誘導するだけです。



指示する方法は、これは別のトピックですが、この投稿は教えるためのものではありません。 問題を示すためです。 問題を理解することはすでにその解決策の半分です。