おそらく、ITアウトソーシングの分野で働いているほとんどすべての企業は、ビジネスユーザーだけでなく技術専門家もクライアント側のプロジェクトに参加している状況に直面しています。 通常、この状況ではプロジェクトの実装が複雑になります。プロジェクトチームが2人の紳士の召使に変わるからです。ビジネスと技術の両方の要件を同時に満たす必要があり、これらの要件はしばしば矛盾します。
ただし、ビジネスユーザーはそのままにして、顧客の技術専門家と彼らがプロジェクトにもたらす困難に集中します。
処分 ：プロジェクトは、「私たちの」チームによって6か月間ゼロから完全に作成されます。 この時点で、顧客のイニシアチブで、定期的（2週間ごと）のコードレビューを開始し、一般的にプロジェクトがコード標準、アーキテクチャ、イデオロギーに準拠しているかどうかをチェックすることにしました。 彼らのスペシャリストは、真空の球状の技術監督者ではなく、私たちと並行してプロジェクトを書くアメリカ（インドではなく、あなたを気にする）の非常に適切なレベルレベルのプログラマーによって代表されることに注意する価値があります。
定期的なレビューの開始から2か月後、プロジェクトは「私たち」と「彼ら」の間の冷戦状態にありました。 そして、状況は実際の軍事作戦に変わる恐れがありました-壊滅的なコードレビューと恐ろしい手紙は悲しい日常生活に変わりました。
次のような問題が発生しました。
1. We-Theyの対立
プログラマーは、自分のコードを批判するのは好きではないようです。海外の叔父がそれを非難する人がいると、神自身がポケットに入れておくように命じました。 理解できる：私たちは苦しみながらこのコードを生み出し、ネイティブの子供のようにそれを愛しています。そして、ここで行を追加しなかった人々は、このコードが一般的に不器用で、構造が不十分で、わずかに拡張可能であると突然言います。 そのような人々は敵であり、議論はここでは適切ではありません。
2.「彼らは私たちが彼らに言うことをしません」
プログラマーは軍隊の兵士ではないため、特定のスタイルに加えて、特定の深さまで、フェンスから昼食までの「上から」の指示に応答し、非常に特定の方法でトレンチが白っぽい海外建築であることが判明します。 つまり、最初の段落のポケットにある銃口に、2番目の段落をすぐに追加し、同時に無邪気に笑います。 そして、もちろん、彼らは独自のことを続けています。
また、アメリカ人の同僚が私たちをどのように想像していたのかもわかりません。 シラカバの木の下に座って30分ごとに100グラムのウォッカ（チームリード-200グラム）を飲みながらコーディングし、 クマがバラライカで私たちを演じているとは思わなかったことを願っています。 しかし、彼らの直接の指示に従おうとしないことは間違いなく、私たちの妥当性に関する意見をより良い方向に変えることはありませんでした。
a。 お客さま
b。 その観点から論理的であり、経験によって証明された要件を提示する
c。 それでも、アメリカ人:)
3.「 翻訳の難しさ 」
国内の技術専門家の中で、外国人と自由にコミュニケーションできる人の数は、私たちが望むほど多くはありません。 実際、プログラマーは5つのプログラミング言語を自由に話すことができますが、悪名高い「女の子」と「やる」を使用して、勝手に母国語を無視することもできます。 英語を学ぶための電話は何にもつながっていないと言う価値はありますか？ それが、アメリカの同僚にいくつかの複雑な建築上の決定を説明しようとする試みが、1回または2回以上停止するようになった理由です。 しかし、それほど複雑ではない議論の主題でさえ困難を伴うことがしばしばありました。
上記の問題が明らかになったとき、この状況から抜け出す方法を探す必要がありました。 私はそれらのうちの2つを見ました：
1.抑圧的かつ懲罰的-クライアントプログラマーのすべての要件をチームが満たすようにします。 しかし、私の経験では、プログラマーとのこのような手段は非常に不十分で、非常に短時間しか機能しません。 さらに、すべての関係者は結果として不満を抱いています。
2.相互理解の道筋は、それらを理解し、考えを伝え、可能な限り妥協を模索することです。 ユートピアのように聞こえますが、これは起こりませんが、試してみることにしました。
実際、 ペアプログラミングの助けを借りて相互理解を求めることにしました。 もちろん、海外の同僚をペアプログラミングに「誘い込む」というタスク自体は簡単なタスクではありませんが、成功すれば、結果は素晴らしいものになるでしょう。 いずれにせよ、それは本当に素晴らしいことが判明しました。
解決策 ：最初に、プロセス組織の技術的な詳細について簡単に説明します。 デスクトップへのリモートアクセスを取得するために、 Live MeetingとWebExの両方を使用しようとしました。 企業のセキュリティポリシーにより、同僚には「外部」メッセンジャーがいないという事実を考えると、最初は音声通信にハンズフリー電話を使用する必要がありました。 あまり便利ではなかったので、ヘッドセットを手に入れました。 その結果、WebExには、たとえばSkypeから呼び出すことができる音声通信用の特別なフリーダイヤル番号があるため、WebExに決めました。
また、特にペアセッションの終了後には、テキストチャットを手元に用意する必要があります。これは、通常、「聞かなかった」、「誤解された」、「ここに...」がたくさんあるためです
ペアプログラミング中に、次のルールを順守しようとしました。
1.プログラマーはピンポンコードを記述します 。つまり、最初にテストを記述し、2番目に実装を行い、次に役割を変更します。
2.仕事の過程で、あなたが何をしているか、何をしようとしているのか、そしてその理由を常にパートナーと話し合う必要があります。 何も話せない場合、それはタスクが間違って選択されたことを意味します-ペアで作業するために単純で明白なタスクを決して取ったことはありません。
3.ペア作業は、開始から終了までに必要な時間を占めるように計画する必要があります。 電話や会議などで開発者を中断することはできません。
次に、上記の問題にこのアプローチがどのように反映されているかを見ていきましょう。
1. We-Theyの対立
ペアプログラミングの助けを借りて、私たちは見知らぬ人としてのコードに対するアメリカ人の同僚の態度を破壊することができ、プログラマーは本質的に深く掘り下げることなく、無差別に批判することができる「左」の叔父として彼らを知覚しなくなりましたそして彼ら。 実際、コードの一部がレビューを自分で行う人々によって書かれている場合、まったく異なる態度が生じます。 さらに、時々、アメリカ人の1人がコードを批判し始めた状況にいることがわかりました。コードは、結局のところ、同胞に属していました。 そのような場合は、「ストレンジャー」がどのように彼が間違っていると説明されているかを聞いて、私たちが持っているよりもはるかに軽くてカラフルな手を聞いただけでした:)
2.「彼らは私たちが彼らに言うことをしません」
以前に、コードレビューの最後に、通過する際に悲しみを込めて実装しようとした変更のリストがあり、私たちの意見では無意味な点をスキップし、残りのことを理解している場合は、海外の同僚と一緒にこのリストで作業する機会がありました。 そのため、すべての詳細を明確にし、特定のポイントの実装を妨げる問題について議論することができます。 したがって、彼らはアーキテクチャまたはコードの特定の要件の出現の理由を説明する機会を得ました。 その結果、ほとんどの場合、私たちは非常に健全なものを提供されていることに気付き、彼らは私たちを赤いパルチザンと考えることをやめ、ブルジョワの要求のリストで階層を脱線させ、完全な妨害行為を手配しました。 シラカバの木の下でコーディングしていると考えるのをやめましたか-よくわかりません:)
3.「 翻訳の難しさ 」
誰もが理解しているように、ペアプログラミングには3位はありません。したがって、プログラマーは自分で話さなければなりません。 これはもはやマネージャーがすべてを言う一般的な会議ではありませんが、残りはOK、いいえ、はい、そして最も楽しいバイを降りることができます！
一方では、はるかに複雑ですが、一方では、2つの前にコードの一部が開いているため、より簡単です。主にそれについて説明します。 これにより、明確で限定的なコンテキストが提供されるため、コミュニケーションが容易になります。 さらに、プログラミングのアイデアは普遍的であり、用語はほとんどが既に英語を話しているので、理解を大いに助けます。
しばらくして、2つのことに気付きました。 まず、自分自身が数回突くと、外国人との会話でマークを付けると、彼は通常、すぐに走って言語を習得するほど恥ずかしくなります。 追加のインセンティブはもう必要ありません。また、会社が支払うコースは、無料で必要であることが判明しました-すぐに、個人教師のための時間と自分のお金の両方が見つかります。 そして、第二に、話し言葉がすでに十分なレベルに引き上げられ、言語の壁とコミュニケーションに対する恐怖が克服されたとき、指でほとんど話している人によく理解されているという事実から、確固たる話題があります。 何らかの理由で特別な楽しみが発生するのは、それが良いジョークであることが判明したときです。ジョークに反応して笑い声が聞こえるとき、耳から耳までこれらの満足のいくパズルを見る必要があります。
ところで、ここで私たちが遭遇したメンタリティの違いに言及したいと思います。 アメリカ人にとっては、「人生について不平を言う」ことはよくあることです。それどころか、すべてが常に「良い」はずです。 このロジックに従って、私たちはしばらくの間「苦情を申し立て」、改善のためのヒントを聞くために、最も開始されたコードをレビューに持ち込みました。 当然のことながら、レビューにこのようなひどいgovnokodを持ち込んだ場合、コードの残りの部分が何であるかを考えて、彼らはそれをばらばらに壊し、ひどく怒っていました。 最高のコードをレビューに持ち込む必要があること、そしてそれが私たちに期待していることであることに気付くまでに時間がかかりました。 レビューが成功した後、コードのこのような部分は内部標準になり、将来的にはすべてリファクタリングされました。 アドバイスは簡単です。誰も整理しようとしたことのないコードを人々に見せないでください。最初に少なくとも「恥ずかしくない」状態、さらには「誇り」の状態にしてください。
まとめ
上記のすべてを要約すると、私はあなたの外国人の同僚との相互理解を探し、とにかく彼らとのコミュニケーションを確立する価値があることに注意したいと思います。 これには多くの利点がありますが、同時に、時間のコストを除いて、このプロセスのマイナス面を思い付くことができません。 まあ、あなたのチームが外国人の同僚のミュータントを考慮し、彼らが往復するなら、私は最初にこれを行うことをお勧めします。 ペアプログラミングはこの目的にも可能な限り適しているように思えます。 そして、誰かが同じ目的のために他の何かを使用することができた場合-コメントで経験を共有していただければ幸いです。
アウトソーシングにおけるペアプログラミング：顧客の技術専門家との相互理解の実現
All Articles