同僚と彼らがどのように仕事に取り組むかをすでに知っている場合、パンデミックが始まって以来、彼らはおそらくそれほど変わっていないので、それは問題ありません。
ただし、インターネット上で見られるマイクロサービスではなく、人々は人々のままであるため、これらの仮定を新しいチームメンバーに安全に転送することはできません。
COVID-19の前は、私の知ってる、ある都市の企業には、在宅勤務の重要な文化がありませんでした。
もちろん全員がオンサイトであり、リモートデスクトップまたはVPNの資格情報についての議論はありませんでした。
ソフトウェア開発チーム全体が、数日で100％オンサイトから100％リモートに移行する必要がありました。
過去数か月にわたって、特に相互に効果的にコミュニケーションをとる方法において、その移行中にさまざまな課題に直面しました。
企業のオンサイトワークスペースは、約4 x3のレイアウトで配置されたチームのすべてのメンバーのデスクで構成されています。
ほとんどの小規模なディスカッションは、デスク近くのホワイトボードで行われます。
皆さんのより長い議論は、昔ながらの典型的な会議室で行われます。
私たちがリモートワークに移行したとき、私たちはそのすべてのインフラストラクチャと、それらが課した構造を失いました。
これが、そこから生じた課題・問題をどのように解決したかです。
そこで、問題の解決策を探ってみたいと思います
Contents
あなたは新しいチームメイトにそれほど早く適応しません
新型コロナウイルス、いわゆるパンデミックが始まったとき、私たちのチームは全員、物理的なオフィスを共有していました。
それは私たちが、昼食をとったのと同じ人々でした。
それは私たちが、一日中冗談を言ったのと同じ人々でした。
しかし、平均的な人は2〜3年仕事を続けており、過去数か月の間にチームは変わり始めました。
新しいdevopsエンジニアを追加し、コミュニケーションマネージャーは新しい仕事に移りました。
最も重要なことは、私が一緒に仕事をしている品質アナリストが去ったばかりです。
私はこの1年間、ある人と緊密に協力し、自然で効果的なワークフローと信頼関係を築いてきました。
時間が経つにつれて、それは私が特定の仮定をすることを可能にしました。
彼女は私のチケットの1つに問題を見つけたらすぐに、いつも私にメッセージを送ってくれました。
何も聞こえなかったら、チケットは大丈夫だったのです。
QAにチケットを送信してから、最初の数時間以内に何も聞こえなかった場合、それは通過していましたのです。
新しいQAアナリストと一緒に、数日前に彼女にチケットを送りました。
何も聞こえなかったので、マスターブランチへのマージが承認されるまで、コードがさまざまなテストプロセスを蛇行していると思いました。
代わりに、彼女はチケットにコメントを追加し、私たちが使用するプロジェクト管理ツールが電子メール通知を送信するので、私が知っていると思いました。
このQAは通常、オフィスの私のそばに座っているのです。
そこでは何日も話さず、チケットや作業の整理とアプローチについて何気なく話し合わなかったはずがありません。
解決策
同僚と、カジュアルな会話をする必要があります。
私のチームでは、ほとんどの開発者は、立ち上がっただけでなく、誰とも話をしなかった日がありました。
同僚と彼らが、どのように仕事に取り組むかをすでに知っている場合、COVID-19・パンデミックが始まって以来、彼らはおそらくそれほど変わっていないので、それは問題ありません。
ただし、インターネット上で見られるマイクロサービスではなく、人々は人々のままであるため、これらの仮定を新しいチームメンバーに安全に転送することはできません。
私のエラーは、QAチームのメンバーである人間ではなく、ラムダ品質保証機能を使用しているかのように対話を処理し始めたことにありました。
誰も会話に飛び込むことができないので、小さな間違いが増えます
私の品質保証アナリストと、私がオフィスの機能について話し合っている時の事です。
私たちのビジネスアナリストは私たちのことを耳にし、正しくないことを聞いた場合は介入します。
チームは通常同じ物理的空間を共有するため、すべての会話は基本的にチームのものです。
リモートで作業する場合、これらの会話は通常、対面でのチャットにサイロ化されます。
大規模なチャットを1つ行うだけでは、すべてを読むのは面倒ですね。
特に、全員が会話に到着するまでに時間がかかり、100個の古いメッセージを読む人はほとんどいないためです。
私たちは実際にこのアプローチを試しましたが、以前の会話で人々を追いかけるのに多くの時間が費やされます。
すべてのキャッチアップチャットは電話のゲームのようで、別の誰かが繰り返すたびにメッセージが劣化していました。
解決策
チャットをアルファベット順に並べるSlackではなく、最後のメッセージでチャットを並べ替えるMicrosoft Teamsを使用します。
つまり、必要なグループメンバーだけで、チャットが使用されていないため不要な場合に、特定のチャットを多数作成できます。
長い間、それは邪魔にならず、底に向かって漂います。
チャットは最後に使用された日時でランク付けされるため、整理することについてそれほど心配する必要はありません。
関連性がなくなったものは、画面からドロップするだけです。
会話やトピックを復活させる必要がある場合は、以前のすべての情報がすでにそこにありました。
物事を書き留めないことのコストはより高い
職場を離れるまで、物理的な空間を共有するだけでグループの知識体系に、どれほど貢献できるかはわかりませんでした。
そのため、最初は、直接の説明が簡単だったため、仕様書や詳細なドキュメントをあまり作成しませんでした。
開発者の1週間の作業を表すチケットは、1〜2文であった可能性があります。
リモートワークに移行すると、詳細の欠如が小さな間違いの増加につながりました。
これは、多くの小さな説明が必要なすべての人に届かないのです。
ビジネスアナリストが、想像どおりにUIが統合されているかどうかを、確認することができなかったためです。
解決策
会議やチャットの終了後に再度書き留めることなく、重要な決定や詳細が本番環境に反映されることはないと想定し始めました。
非公式のチャットは、もはや誰にも届きませんでした。
重大な問題については、最新の電子メールがその問題のステータスを維持する電子メールスレッドを保持しています。
会議は、私たちが何を決定し、何を達成しなければならないかについてのメッセージで締めくくられます。
また、より包括的なチケットの作成も開始しました。
目的の結果に繰り返し近づくことができるため、カジュアルなやり取りが簡単で利用できる場合は、1つの文が機能します。
物事が不明確な場合は、後で整理できるというアプローチが非常にありました。
いくつかの挑戦の後、私たちは反対方向に行き過ぎました。
圧倒的なディテール。これをどのように解決したかは、次のセクションの一部です。
たくさんの書面を持っているコストもそうです
これら2つの問題について、学習しているときにスプリントが困難だったのです。
その為に、特に次のスプリントのタスクが大きく複雑だったため、積極的にドキュメントを作成し始めました。
最初のいくつかのエラーに過剰反応し、場合によっては要件のページとページを作成しました。
1枚のチケットで、ドキュメントの長さが5〜10ページになるのは驚くほど簡単です。
問題は、そのようなエッセイは読むのに疲れており、すぐに議論するのが難しいということです。
長い会議は解決せずに終了しました。
品質保証アナリストは、すべての要件が満たされていることを確認するために、長いドキュメントを1行ずつ繰り返し確認する必要がありました。
ドキュメントをスクロールして全員をページ間を移動し、重要な決定を下すには別の人が必要であることに気付くと、1時間は簡単に費やすことができます。
解決策
情報の長い段落ではなく、箇条書きのチェックリストを作成します。
さまざまなUIコンポーネントが、どのように表示されるかを一貫してスケッチすることができるようになりました。
段落は読みやすくなっていますが、どの機能要素が終了したかを追跡するための特に良い方法としては役立ちません。
問題の質問/解決策を明確にすることは、チャットや電子メールの奥深くで失われる
解決する必要のある問題に焦点を当てているため、ソフトウェアエンジニアリングの専門家の実用的なドキュメントと呼ばれていると聞きました。
問題から始めることは、キーワードのインデックスをざっと読むのではなく、人々が物事について考える自然な方法です。
SOの優れている点は、問題を解決するのに1人で済み、誰もがそのソリューションを今後活用できることです。
これは、私自身を含む多くの組織にとっての課題です。
以前に質問に回答したものの、チャットルームに移動したり、チャットルームで迷子になったりした同僚のメールの奥深くに回答が埋もれているため、同じ問題の解決と同じ問題の解決に多くの時間を費やしています。
問題を最初から、解決する方法をもう一度考え出すか、正しい解決策をもう一度明確にする必要がありました。
これが、要件ドキュメントの単語数が劇的に増加したもう1つの理由です。
どの組織でも、長期にわたって保持するのに役立ち、理想的には検索可能な形式で利用できる小さな学習がたくさんあります。
それらは、すべて再びカバーされなければなりませんでした。
解決策
会議を明確にするために、回答された重要な質問の中央ドキュメントを作成しているので、それらの質問を続ける必要はありません。
内向性の人は積極的に口頭での会話に参加する必要があります
会議に内向性を含めることは常に問題でしたが、音声通話は課題を悪化させます。
ビデオチャットでさえ、かなりの欠陥があります。
直接会うことで、参加者は誰かがいつ話したいかを見ることができます。
他の人は、起き上がったり、手を上げたり、口を少し動かして何か言いたいことがあることを示したりすると、心を話す余地が与えられます。
音声会議はそれらの微妙な信号を完全に欠いているので、話したい人は誰でもそれを与えられるのではなく話すために休憩を見つけなければなりません。
私たちのスプリントレビューは通常音声会話であり、電話をかけている5〜8人ではなく、2〜4人の間で簡単に話し合うことができます。
ビデオチャットでも、ある程度の手がかりを得ることができます。
しかし、そのためには、スピーカーがさまざまなウィンドウすべてを積極的に監視する必要があります。
これは、画面を使用して提示したり、議題を提示したりする場合は困難です。
解決策
会議中の特定の時間に、特定の機能についてコメントするようにキーパーソンに具体的に依頼します。
これにより、使用または辞退できるスピーキングスロットを挿入する傾向がない人も使用できます。
このように会話を管理することで、飛び込むのが苦手な人でも会話に参加できます。
余分なコミュニケーションは生産性を損なう可能性があります
他の開発者に、メッセージを送るために何らかの形式の非同期通信を使用して、集中力を壊さないようにすることは、長い間開発者のエチケットでした。
私たちの多くが認識するであろう、これについての人気のある漫画があります。
開発者の間では、これは珍しいことではありません。
ただし、この動作は他の分野の従業員にはあまり馴染みがありません。
彼らがそれを知っていたとしても、それは実際の仕事のシステムというよりは、ステレオタイプの開発者の内向性と見なされています。
優先情報の伝達の問題もあります。
システムがダウンしている場合は、ただちに対処する必要があります。
コロンがありませんか？
これは、次のリリースにいつでも追加できます。
しかし、開発者がメッセージ全体を読んで、メッセージの重要性と、メッセージにすぐに対応する必要があるかどうかを判断する必要がある場合、それは非常に混乱を招きます。
解決策
どの通信方法をいつ使用するかについて、いくつかのルールを設定します。
問題のみを対象とした、一般的なチームチャットを使用します。
それ以外の場合は、チャットメッセージは通常、都合がよいまで無視できることに同意しました。
大量の情報でチャットが混雑するのを避けるために、長いエッセイは電子メールで送信されます。
電子メールは、決して優先タスクではありません。
重大な問題でない限り、予定外の電話通信は避けてください。
結論
これらの新しいプロセスはすべて、以前は有機的なプロセスに大量の構造を追加しているように見えるかもしれませんが、その構造の多くはすでに存在しています。
それは見えないだけで、通常の社会的行動に組み込まれています。
たとえば、人に手を挙げて話してもらうのは厳格で柔軟性がないように見えるかもしれません。
しかし、とにかく誰かが何か言うことがあるかどうかを判断するために、ボディランゲージの微妙な手がかりをすでに使用しています。
それらの手がかりに反応するという期待は、すでに存在します。
それは挙手ではなく、すぐに話すことを期待して前かがみになったり言葉を口にしたりする人です。
これは、物理的なオフィスで多くの隠れたコミュニケーションが発生し、デジタルオフィスで代替手段を探す必要がある多くの方法の1つです。
多くの点で、リモート通信への移行は、より多くのルールを作成する場合では無いのです。
物理的な手がかりと、コンテキストに部分的に基づいてルールのセットが常に存在することを認識するだけです。
それらがなければ、ルールを再構築する必要がありました。
コメント