すべてのエンジニアリングチームは、同僚と重要な製品情報をコミュニケーションするために、何らかの文書ツールに依存しています。 小さなチームが始めたばかりの場合、これはGoogleドキュメントのように簡単なことかもしれません。そして、大規模な複雑な製品を持つチームの場合、これは階層的なウィキになる可能性があります。 会社の構造によって、他のチーム（人事部やマーケティングなど）もこのウィキを使用したり、自分たちの情報を保管する他のエリアを持ったりするかもしれません。

私たちは、会社のすべての知識を中央の場所でアクセス可能にすることが最も効率的であると信じています。また、エンジニアリングチームのニーズは特有で微妙であり、技術的であることも知っています。 Guruがエンジニアリングチームの文書ニーズをどうサポートしているか、私たちのチームとGuruの顧客であるRS21の例を見てみましょう。

環境設定とオンボーディング

新しいエンジニアリングチームに参加する際（社内外問わず）、オンボーディングプロセスは、新しいチームメンバーが貢献する準備ができるまでの速さを決定するのに重要です。 コーディング環境の設定から機能文書の参照まで、新しい作業を始めるためにはさまざまな準備が必要です。

多くのエンジニアリングチームでは、オンボーディングプロセスが別のチームメンバーにとっては労力がかかることがあります。新しい従業員の「バディ」として指定され、その情報をリアルタイムで案内します。 しかし、Guruにおける専門家によって確認された最新のカードをチームに提供することにより、RS21のエンジニアリングリーダーは新入社員に自分のペースでオンボーディングを行う柔軟性を与えます。 これにより、オンボーディングの「バディ」との時間を節約し、より人間的な関係構築や未解決の質問に使うことができます。

新しいエンジニアがRS21のチームに参加すると、彼らはGuruにログインして、オンボーディング資料の作業を開始します。 「チーム情報」ボードを見て、チームメンバーについて少し知り、インフラストラクチャカードを使って正しく環境を設定し、チームのコーディング基準を読み、新しい同僚との協力方法を理解します。

同様に、Guruでは、エンジニアが新しいチームに参加したり移動したりすると、彼らのオンボーディングはGuruで行われます。 彼らは、ライフストーリーカードを使用してチームメンバーを知り、一緒に作業する方法についてのガイドを見て、新しいチームのコレクションをGuruで閲覧し、製品機能を理解します。

ベストプラクティスとチーム基準

チーム全体がオンボーディングを終えたら、コーディング基準や文書のベストプラクティスなど、継続的なリソースもGuruにあります。 ワークフローでのアクセス可能な方法で文書化されると、これによりエンジニアはチームや会社の他の部分と<次へへ引け>">生産的に協力します。 また、ポリシーや手順を暗記する必要がなくなり、さらに悪化することはありません。古い文書をブックマークして頼ることになります。

RS21のエンジニアリングコレクションには、コードをマージするための指示、バッシュスクリプトの作成、コードレビューのリクエストなど、プロセスガイドラインに特化したボードが含まれています。 また、チームが合意したコーディング構文スタイル、AWS設定手順、システム管理者情報などに特化したボードもあります。 頻繁に使用されるコードスニペットもGuruカードで簡単にコピー＆ペーストできるように提供されています。

これらのエンジニアリング専用カード以外でも、Guruはエンジニアがチーム間プロセスのためのクロスファンクショナルベストプラクティスとガイドラインにアクセスするための素晴らしい場所です。 たとえば、RS21のチームは、非同期ディスカッションをGuruを使用して実施し、チームメンバーが考えながら反応するための時間を与え、貢献するための平等なプラットフォームをすべての人に提供します。 これらの議論を設定し、監視するための指示はGuruテンプレートに保存されており、必要に応じて誰でも簡単にスピンアップできます。

Guruでは、私たちの製品開発組織外のチームに品質保証（QA）プロセスを手伝ってもらいます。 より多様な視点を持つことで、私たちはバグを特定しやすくなり、潜在的な顧客の課題を探り、リリース前にそれに対抗します。 ただし、QAという技術的なプロセスには、クロスファンクショナルチームを含むときに文書化された指示と手順が必要です。 新機能のQAを開始する前に、エンジニアリングチームリーダーは、私たちのQAプロセステンプレートを使用して、私たちのチームと利害関係者がエンドツーエンドのQAに必要なすべてを一箇所で作成します。 QAを開始する準備ができたら、彼らはこれをチームや利害関係者に発表し、メッセージ内にアクティブなQA日付を含めます。

プロジェクト計画と開発文書

新しい開発プロジェクトが開始されるたびに、その後に続く多くの文書があります。これにより、すべての人が自分の役割を果たすために必要な完全なコンテキストを持つことが保証されます。 キックオフミーティングの後、エンジニアは、製品チームからの要件文書、UXチームからの最新の機能設計、マーケティングチームやコピーライティングチームからのコピーなどに依存します。

もちろん、彼らは自分が作業している機能に影響を与える技術的文書や、後で更新する必要がある文書を頻繁に参照する必要があります。

Guruでは、製品開発に必要なさまざまなリソースを、各プロジェクトのエンジニアリングリードが主導するアクティブプロジェクトリソースカードで追跡しています。 これらのカードは、エンジニアリングチームが開発ライフサイクルの初期段階を通じて頼りにするリソースであり、変更があった場合は最新の状態に保たれます。

開発プロセスが進むにつれて、エンジニアリングとデザインの協力は綿密に行う必要があります。 しかし、仕事の非同期でリモートな性質のために、デザイナーとエンジニアは、常にZoomコールで問題やフィードバックについて話し合うことができるわけではありません。 デザインフィードバックを依頼するために合意した内部プロトコルに従っていることを確認するために、私たちのエンジニアリングチームは、Guruに文書化されたUI変更のためのデザインフィードバックのワークフローを使用しています。

将来を見越した文書

文書はエンジニアの仕事の必要不可欠な部分であり、今後もそうであり続けるでしょう。 かつては痛ましいうめき声や不満のために声を上げていたものが、日常業務において自然な一部となることができます。 Guruのブラウザ拡張機能は、エンジニアが必要とする場所に文書を直接持っていき、アクセスするためにコンテキストを切り替える必要がなくなります。また、短い形式の専門家によって確認されたカードは、過去の長い文書の作成や保守の負担を軽減します。 したがって、古い文書で技術的な負債を増やす必要はありません。今すぐ簡単に将来を見越した文書を作成できます。 今すぐ無料で始めましょう。