私の名前はAlexandraKamzeevaです。システムアナリストとして9年間働いており、そのうち3。5年間はLamodaで働いています。私はたくさん読んで、現在のドキュメントを分析し、新しいドキュメントを作成します。私の仕事では、常に情報を構造化し、可能な限り便利にします。
優れたシステム記述の長所は次のとおりです。
- 構造化されていない説明よりも、必要な情報をすばやく簡単に見つけるのに役立ちます。
- プロジェクトの失敗のリスクを軽減します。
- 従業員の乗船が容易になります。
どのチームでも使用できるような説明のテンプレートを作成しました。この記事では、システム記述テンプレートを作成するきっかけとなった理由、その作成の履歴、および現在Lamodaでどのように使用されているかを例を挙げて説明します。
テンプレートとは何ですか、なぜそれが必要なのですか
まず、パターンの理解について説明します。だらしのない部屋で小さな車を見つける必要があるとしましょう。私がそれを処理できるというのは事実ではありません。しかし、私は誤ってレゴの部分を踏むことができます。
ここで、すべてのおもちゃがその場所に置かれ、分類されていると想像してみましょう。すべての車がどのボックスに入っているかを事前に確認できます。必要なボックスをより速く、より簡単に見つけることができ、神経を無駄にすることはありません。
同様にドキュメントと。テンプレートはそのような順序です。どのチームでも使用できるシステムを記述するためのフレームワークを作成しました。
どのような条件でドキュメントを使用しますか
Lamodaには、注文の配送、コンタクトセンター、倉庫、写真スタジオ、その他の運用およびビジネスプロセスを自動化する100を超えるシステムがあります。300人以上のエンジニアが開発とサポートに携わっています。それらのいずれかは、これらの100のシステムのいずれかの説明を必要とする場合があります。
各チームは、Confluenceの個別のスペースでシステムを個別に説明します。テクニカルリードは情報を記録する義務があるため、必然的にドキュメントに関与します。また、このシステムは、知識を失ったことを残念に思うアクティブなテスターや開発者によって説明されています。そしてもちろん、アナリストは、ドキュメントが私たちの主要なツールの1つであるためです。
この自由が混乱につながるように見えるかもしれません。しかし、これはそうではありません。なぜなら、私たちには、文書化に対する責任ある態度、知識のオープンな共有、プロジェクトとシステム成果物を記録する習慣があるという企業文化があるからです。この伝統は、失敗したプロジェクトのおかげで部分的に発展しました。インシデントは、システムのプロセスと機能を文書化することがいかに重要であるかを開発チームに証明しました。
以下では、紛らわしいドキュメントやドキュメントの欠如が問題につながったいくつかのケースを強調します。
2つのボタンを追加するだけ
テンプレートを作成するように促した最初の問題-一部のシステムの説明がなかったため、障害と改善につながりました。
自己注文管理（SOM）プロジェクトがありました。クライアントの個人アカウントに、「配達日の転送日」と「注文のキャンセル」の2つのボタンを追加することにしました。それ以前は、クライアントはコンタクトセンターに電話することによってのみ注文をキャンセルまたは再スケジュールすることができました。一部の購入者がオペレーターと連絡を取る時間や希望がなかったことは明らかです。その結果、営業担当者が不要な注文をしたり、自宅でクライアントを見つけられなかったりする可能性があります。そのような場合、Lamodaが費用を負担します。プロジェクトは必要かつ重要でした。
2つのボタンが追加されているようです。実際、4つのシステムの背後には多くのロジックがありました。順序の変更は、処理システムを通過します。これは、ある場所で何かに触れて別の場所で撮影できる巨大なモノリスです。残念ながら、彼女の作品の微妙な点はドキュメントに記載されておらず、プロジェクトの設計時にこれに注意を払っていませんでした。リリース後、ボタンが期待どおりに機能せず、ロールバックされました。その結果、このプロジェクトには2人月ではなく、6か月かかりました。
もちろん、ドキュメントが不足しているだけでなく、この結果が得られました。ただし、注文のキャンセルと転送のプロセスについて明確に説明していれば、結果は異なる可能性があります。
複雑なオンボーディング
テンプレートを作成するに至った2番目の問題は、オンボーディングの複雑さです。注文処理システムチームに勤務するようになりました。没頭するために、私はシステムスペースのドキュメントを読み、3つのセクションで、システムの主要な本質である注文ステータスの3つの異なる説明を見つけました。
この場合、オンボーディングを簡単にすることはできませんでした。そのような文書は、以前に私たちのシステムに遭遇したことのない同僚に知識を伝達するのに役立ちませんでした。
白紙の状態の問題
テンプレート作成の3番目の前提条件は、白紙の状態の問題です。新しいシステムごとに、技術リーダーは適切なスペースを最初から作成する必要があります。技術リーダーは、作成するセクションについて検討します。テンプレートを作成する前に、従業員は他のスペースを調べ、どのセクションが使用され、自分のシステムに役立つかを調べました。これは以前は長い時間がかかりました。
テンプレートの作成方法と何が起こったのか
システムアナリストは毎週、スタンドアップを行い、プロジェクトだけでなくプロジェクトで発生する問題について話し合います。そして、同僚は、情報を見つけてさまざまなシステムの空間を理解することがいかに難しいかについて不平を言ってきました。このため、私たちは絶えず火傷を負っていたので、私たちは自分たちが接続しているシステムの説明を自分の手で取ることにしました。そして、何をすべきかが明確になります。
まず、優れたテンプレートの属性を特定しました。
- .
- . , , . , . .
- . , , , .
- .
次に、さまざまなシステムの現在の説明を分析し、共通のセクション
を特定しました。プロジェクトと機能のセクションには、プロジェクトを開発するための仕様がありました。開発セクションとQAセクションには、開発とテスター向けの特定の情報が含まれていました。インシデントのセクションでは、システムで発生したインシデントとその解決策について説明しました。
私たちは非公式の会議（キッチンでの昼食、スタンドアップ、定期的に話し合うチームの隣人）で他の同僚とテンプレートのアイデアを共有し、ボランティアのワーキンググループを作成しました。彼らは、2人のマネージャー、3人のテクニカルリード、2人のテスターというさまざまな能力の代表者でした。彼らは次のセクションをテンプレートに追加しました。
次に、IT部門の責任者、経験豊富な技術リーダー、大規模な統合プロジェクトのテストリードなど、幅広い能力を持つ同僚とシステム記述テンプレートをテストしました。彼らは最終的にいくつかのより有用なセクションを追加しました：
テンプレートの品質をチェックする
結果のドキュメントを、Lamodaでの適切なテンプレートの定義と照合しました。
- 必要な情報をすばやく簡単に見つけるのに役立ちます。私たちは便利な構造を持っています：私は木に沿って移動し、何がどこにあるかを理解します。システムのプロセスに関する情報（注文のキャンセルなど）が必要な場合は、「主なプロセスの説明」に進みます。
- パーティションの原子性により、システム情報は複製されません。たとえば、印刷可能なものを1つのセクションで説明し、「メインプロセスの説明」セクションからリンクして、情報が繰り返されないようにすることができます。
- . Lamoda, . , -. — .
- . .
Lamodaシステムを説明するための優れたテンプレートを作成しました。他の企業にも役立つことを願っています。特に、次の3つのセクションを強調したいと思い
ます。システムの主なプロセスの説明。はい、このセクションが必要であることは明らかです。しかし、注文をキャンセルして転送するためのボタンの場合のように、何らかの理由で常に存在するとは限りません。キャンセルと再スケジュールのプロセスを事前に説明しておけば、プロジェクトが失敗するリスクが軽減されます。
チェックリスト-通常のプロセスで最も重要なことを思い出させるセクション。たとえば、支払い方法管理システムの説明には、「新しい支払い方法を接続するためのチェックリスト」があります。支払い方法の追加または変更は、会計部門、コンタクトセンター、配送、および他のビジネスユニットと調整する必要があると書かれています。
支払い方法の変更についてコンタクトセンターに通知するのを忘れた場合。そして、クライアントが私たちのコンタクトセンターに電話してそれについて尋ねたとき、オペレーターは何も言うことができませんでした。これにより、コンタクトセンターと、支払い方法を担当する開発チームとの間で競合が発生しました。この事件の後、私たちは主要なプロジェクトの立ち上げ、新しいパートナーの接続などのチェックリストを作成します。
スペースホームページ-このシステムが必要な理由、チームと利害関係者の構成に関する情報を含むセクション。システムの変更と開発リソースを利害関係者と調整する必要があります。したがって、Confluenceを見るだけでこの情報を取得できるのは素晴らしいことです。
そこに、システムに関する質問に誰が連絡するかを理解するために、チームの構成に関する情報を示します。また、頭が腫れている初心者にも役立ちます。新入社員が、話しかけたばかりの人、この人が誰であるか、彼の役割が何であるか、そして彼の名前が何であるかをスパイできるのは素晴らしいことです。
システムでテンプレートの使用を開始した方法
- まず、テンプレートの必要なセクションを入力せずに作成しました。それは簡単で、30分もかかりませんでした。
- 次に、最も困難なことは、技術リーダーとの定期的な会議を設定し、そこでシステムのドキュメントの分析を開始したことです。最初の会議では、現在のページを3つの山に分割しました。
関係のない不要なものはすべて最初の山に送りました。これらのページを削除するか、アーカイブに送信しました。
2番目の山は必要ですが、関係ありません。ページを無関係としてマークし、Jiraでタスクを作成してから、バックログに従ってこの情報を更新しました。
3番目の山は最も単純です。すべてが明確になったら、セクションは関連性があります。適切な場所に移動しただけです。
これらの会議の前に、プロセスとアーキテクチャの説明、テスターと開発者からのメモ、およびインシデントがスペース全体に散らばっていました。ホームページもありませんでした。
6時間の会議で、すばらしい結果が得られました。混沌から、私たちは構造と秩序を形成しました。これで、プロセスの説明、アーキテクチャに関する情報、およびインシデントに関する情報がどこにあるかを把握できます。そして重要なのは、ホームページができたことです。ここには、注文処理システムが必要な理由とその利害関係者が書かれています。
私たちの大規模なシステムは、ほぼすべてのビジネスラインに関与しています。しかし、以前は私たち自身の利害関係者がいませんでした。ホームページを作成しているときに、システムの変更を調整するCTOと話し合いました。したがって、改善を優先した同僚が決定されました。今では、ホームページの作成が利害関係者の出現につながったのは面白い事実のように見えます。
テンプレートの配布方法
テンプレートの使用に関する同様の結果は、独自の方向でテンプレートを実装した他のアナリストによって受け取られました。したがって、多くの統合プロジェクトに積極的に関与しているほとんどのシステムについて説明しました。
システムが統合プロジェクトに頻繁に関与するチームがありましたが、それらについての十分な説明がありませんでした。通常、文書化が必要だったので、アイデアを売る必要はありませんでした。
そのようなチームの技術リーダーやマネージャーにテンプレートを適用することに成功した経験を示しました。私たちの例に基づいて、一部のチームは独自にドキュメントを整理し、他のチームはアナリストの助けを求めました。
テンプレートに関するフィードバック
私たちのテンプレートは、必須または必須のシステム記述ではありません。同僚は、テンプレートが必要な場合はそのテンプレートを基にして、ニーズに合わせて編集します。たとえば、システムが主に交換で構成されている場合、交換をサブセクションからセクションに転送します。
私たちのシステムはすべて説明が異なりますが、一般的な構造と一般的なロジックは保持されています。これで、システムがどのプロセスで構成されているか、システムアーキテクチャなどに関する情報をより簡単に見つけることができます。
ラモーダでは、知識を共有するのが大好きです。これを動機付ける大規模な統合プロジェクトがあります。システムの最新の説明へのリンクを送信し、同僚は、すでにロードされている技術リードに追加の質問なしで必要な情報を受け取ります。
テンプレートを作成してから2年後、同僚にインタビューし、大多数から良いフィードバックを受け取りました。彼らはテンプレートを使用して、好きなように構造を編集します。
しかし、ドキュメントやテンプレートは必要ないと考える人もいます。基本的に、これは、何かを文書化する緊急の必要がなくなったシステムのチームの推論です。
それらはほとんど変更されないシステムで動作します。統合プロジェクトはなく、これらのシステムについて他の同僚に話す必要はありません。したがって、文書化する必要はありません。
大きなプロジェクトを始める前に、私たちの文化と大きな隆起は、主要なプロセスを文書化することを思い出させ、彼らは彼らの考えを変えると思います。
あなた自身と私たちの道を繰り返したい人へのアドバイス
- , , , , . , .
- . , . , .
- , , . : , , . . , .