モスクワから地方都市に到着して、私はある会社のIT部門の責任者として就職するつもりでした。 モスクワでの専門能力開発と、1行目から3行目までのすべての作業段階を完了した後、私は管理と人/プロセスの管理が好きで、それができることに気付き、空席を探し始めました。
カットの下の詳細。
会社が「特別、刈り取り、ゲーマー」を必要とするとき（人がボードをはんだ付けし、1C構成を書く必要があるとき）、トランスの空室に特に気を取られませんでした。 2か月後、部門の次長が同意するのは難しいという提案で私のところに来ました。 方向性が現れたばかりで、連邦規模の会社で、地域にサポートおよび開発部門を設立しました。計画は壮大で、私の期待に完全に一致していました。 チームとプロセスをゼロから構築し、既存のプロセスに最適化して統合することができました。 全員が「コーディネーター/テクニカルサポートの責任者」の職務を務めた。 さて、私は戦いの準備ができていました。
最初の目標：
- 1行目と2行目のサポート。
- 知識ベースの作成
- ユーザードキュメントの作成
- 「ビジネス相談」の実施のためのビジネスプロセスを掘り下げること
- ITIL Service Desk方法論のフレームワーク内でユニット間のやり取りのルールを準備する（アプリケーションとインシデントを渡すプロセスと、そこからSLAを書くプロセスのみを採用することを計画しました。
- サポートスタッフを雇います。
ドキュメント作成
求めていたもの：購入した情報システムをサポートする必要があり、ハードウェアインフラストラクチャをさらに扱う必要があったため、次第に、そして私にとって最も明らかな側面から、システムとドキュメントによって自動化されたプロセスのルールを求めました彼女に。 そして、私は最初の驚きに出会いました-「お金」のために購入したシステムのドキュメントがありませんでした。 開発者が膝にスケッチしたスライドがあり、特定の役割がプロセスにどのように関与しているか、それだけです。 同社にはさらに4か月の契約サポートがあり、システムの運用に関する質問について連絡が取れました。 システムの実装に関する内部プロジェクトはありませんでした。期限は、合意と特定の改善の実装のタイミングを示すExcelドキュメントによって設定されました。 はい、採用後、システムはさらに5か月間補足されました。
何が起こったのか：罪が半分になると、いくつかのプロセスがVisioダイアグラムの形式で記述されます。 部分的に説明されたシステムモジュール。 期限により、購入したシステムの開発者とのコミュニケーションはさらに悪化しました。 私はそれを理解しているので、購入のための義務的な文書が指定されていませんでした。
結論： 文書化されていない未完成のシステムは、開発者の助けがなければ説明が不十分です。 通信プロセスを確立してみてください。
知識ベースの作成
私が望んでいたこと：最初の行のサポートは、ユーザーからの質問の特定のプールを収集することになっており、マネージャーは少なくとも部分的にこのプールをすでに持っていると想定されていました。 しかし、営業部長との交渉の後、プールがなく、プロセスは次のようになることが明らかになりました：ユーザーが電話し、それが技術的な部分に接続されている場合、私たちは助けます。 答えのビジネス部分はまったくなかったので、最初のユーザーはそれほど幸運ではなかったはずです。 繰り返しになりますが、会話中に、ビジネスは実際には新しいユーザーを重視しておらず、これらのリスクを冒す準備ができていることに気付きました。
明確にするために、そのような情報源では、写真はかなりあいまいに見えましたが、私は挑戦としてそれを取りました。
何が起こったのか：最初のビジネス相談をカバーするドキュメントが作成されました。 ビジネスでの作業手順を規制することはできませんでした。 企業は、「リストにない」新しい質問に答えるのを忘れることがあります。 コントロールを維持しながら、再リクエストする必要がありました。 docuwikiに基づいて、問題の説明、システムアーキテクチャ、2番目のサポートラインの基本アクション、および管理者を含むナレッジベースが作成されました。 システムで新しい製品を作成するためのセットアップを記述することはできませんでした。それは、それがセミプログラム可能な方法で作成され、プログラマと一緒に記述する必要があるためです。
結論： 顧客の忠誠心を犠牲にする知識ベースを作成することは間違ったステップです。 ビジネスがこれを行う場合、追加の負のクライアントの欠点と封じ込めの言い訳という形で、サポートに追加の負担がかかります。
スタッフ募集
私が望んだこと：従業員を選択するために、チームに系統的に行きました。コンピテンシーのリストを選択し、これらのコンピテンシーに関する電話インタビューの質問を作成しました。 最初は、すべての質問の重みが同じでしたが、2、3回のインタビューの後、すべての候補者が空室に等しく適しており、そのようなペースで長期にわたって人材を雇用できることに気付きました。 すべてのコンピテンシーに重みが付けられ、プロセスがさらに楽しくなりました。
最初の行の能力表：
このテンプレートは、管理者による承認のために送信されましたが、「apply-not apply」という応答は返されませんでした。
私はテンプレートを持たない古い同僚の推薦で最初の人を連れて行きました（私は一週間働きました）。 次のボスがかかりました。 残りの3人（女の子）は、部分的には私の参加で募集されましたが、私の推奨事項を尋ねたり、意見に興味を持ったりすることはありませんでした。 私が受け取っていない物質的な動機と予算への入場。
何が起こったのか：従業員が第一線で素晴らしい仕事をしている要件部門を完全に満たしていない楽しいが採用されましたが、システムに深く没入するには、適切に構造化されたトレーニングと知識移転のプロセスが必要です。 私と一緒に、RFPが市場平均を上回っている人々は、作業プロセスが正しく設定されていないため、目に見えない動機を失いました。
結論：新しいやる気のある従業員に作業量を準備します。 そうでなければ、それは雇用主とシステムへの忠誠心に悪影響を及ぼします。 スタッフのモチベーションのプロセスを理解する-物質的および非物質的の両方。
作業プロセス
私が望んでいたこと：システムを起動した後、最初の困難に直面し始めました。古いインターフェイスはひどく見え、すべてのユーザーフレンドリーなコンセプトに反していました。 呼び出しの主な流れは、ビジネスプロセスではなく、インターフェイスに不満を抱きました。 ユーザーは単にリクエストを送信できませんでした。 主な間違いは、新しく採用された開発チームにすぐにもたらされましたが、ここで2番目の問題に直面しました。外部からシステムをサポートした人たちだけでなく、システムを修正するための優先順位もありませんでした-すべての努力は新しいものを書くことに専念しました機能と製品の場合、呼び出し回数を半減させるような基本的なエラーを修正する担当者を割り当てることはできませんでした。
何が起こったのか：問題をもう一度経営陣に指摘した後、それでも修正を行う許可を与え、コールフローは3倍に減少しました。
結論： タスクの優先順位付けのプロセスを確立し、開発チームとの対話の順序を議論します。
上記の各タスクに直面して、プロセスを最適化し、ビジョンを会社のビジョンと調整しようと提案するたびに経営陣に来ましたが、常にマネージャーの雇用（システムの問題）または「これまで」と「あまり形式化したくない」という答えに遭遇しました「。 また、部門を5人に拡大する予定であることも知っていましたが、サポートプロセスとリソースの管理方法を理解する必要があることもわかりました。 私は、変更を実施しようとする絶え間ない試みのために、当局が私のために計画を変更したとすでに疑い始めました。 私はもはやコーディネーターやボスと呼ばれていませんでした。システムの開発に関連する集会には参加しませんでした。
その後、私は戦略を準備し、自分が何かをしているかどうかを理解することにしました。 なぜなら、上司は戦略の面で私とまったく連絡しなかったからです。 戦略はモスクワのITの優秀な人に即座に向けられ、私にとっては、私の仕事の姿が変わりました。 それから戦略はモスクワから私の直接の上司に向けられ、私は地元の上司と対立することになりました。
結論： ユニットの戦略を分析します。 短期および長期計画を定義します。 リーダーシップとビジョンについて話し合う。
「マレゾンバレエ」の第2部
上記のエピソードの後、直接の上司は私と話すのを事実上止めました。 そして、私は去ることについて考え始めました。 当初、私は興味深いプロジェクトを見ました。このプロジェクトは、プロセスのすべての参加者の適切な相互作用に関する特定の困難を克服した後、正常に完了することができ、適切なKPIを持ち、ビジネスにとって理解可能な明確なアウトプットインジケーターを備えた強力な意欲的なサポート部門を獲得しました。 今、私は部署がまだ実際に開発することなく日常業務に陥っているのを見ました。 2つのタスクが優先事項になりました-呼び出しに応答し、gitlabを使用してシステムのバグ（改善ではない）を説明します。これらは開発者によって修正されました。
もう1つのストーリーは、マネージャーがそれを実行することを提案した「テスト」プロセスです。 誰もこれらの手順を理解しておらず、別のテスターもいませんでした。 リリース前のチーム全体によるパフォーマンスインジケータなしの「ブラックボックス」の機能テスト。 他の方法は使用されませんでした。 採用されたスタッフは、開発分野のバックグラウンドとトレーニングの不足の両方が原因で、テストに効果的に参加できませんでした。 リリース日は常に失敗したか、テストなしでリリースがロールアウトされました。
結論：部門は、2つの大きなプロセスを並行して効果的に処理することはできません。 何らかの形で2つのプロセスが進行します。
対立は続きました。 マネージャーは、私が重要だと考えたすべての管理要素を反転させました。
- 戦略的ビジョン
- 制御
- 管理
- やる気
「早く仕事に来て、後で辞めるという形での会社への忠誠心」などの魔法のポイントも表明されました。
やっとモチベーションを失ったので、私は上司に会社での私の将来の地位と辞任の決定について話をするように勧めました。 その結果、サポート部門の仕事に対する私のビジョンを実現しようとする実践的な経験を積んで、退職しました。
何が起こった：経験、経験、そして再び経験。
結論： 自分のために記録したエラー：
- 時間を無駄にしないために-事前に計画を修正して調整する
- 戦略を明確に定義します。 漏れがある場合-すぐに問題を解決する
- 自分にとって快適なワークフローを決定します。 物質的な動機と非物質的な動機との間の妥協点を見つける
- たぶん、これらのことを理解するのに時間がかかりすぎたのでしょう。 表面に多くのレイ
また、経験の浅い私が注意を払わなかった実装のストーリーとニュアンスを同僚から聞きたいと思います。