リモートワーク:チームリーダーとプログラマー

リモートワークの利点は明らかです。適切な資格を持つスペシャリストの検索に対する制限が少なく、MKAD以外の人を雇う能力があり、ビジネス費用が少なくて済みます。 一方、問題もあります。最も重要なものは、仕事の組織からのものです。 過去4年間、私は外国人顧客のためにプログラマーの分散グループ(異なる時期に3〜15人)のチームリーダーとして働いてきました。そのような仕事の経験をhabradersと共有したいと思います:-)



以下、以下の労働組織を意味します。

  1. ヨーロッパ/アメリカのどこかのオフィスにいる顧客(+オンサイトチームはオプション)。
  2. Timは分散チームのリーダーです。exUSSRの広大な地域のどこかにいます。
  3. 分散チームのメンバーは、exUSSRの広大な地域のどこかにいます。
必要に応じて、顧客はすべてのチームメンバーと通信できることが理解されます。 お支払いは1時間ごとです。





プログラマー



プログラマにとって、リモートワークには長所と短所の両方があります。 あなたの利点のうち、コントロールが少ないと、予想よりも早く作業でき、不必要にズボンを拭かないでください。 マイナス面-あなたの仕事のスピードは非常に疑わしく、長いタスクは誰もが神経質になり、チームが困難な残業に陥りやすい。



次のことに注意してください。

  1. あなたのチームリーダーは適切である必要があります:-)これが最も重要なことです。そうでない場合、開発者がどれほど優れていても、成功しません:-)彼またはあなたは去るべきです。 論理的な結果を待ってはいけません-プロジェクトの崩壊と顧客がすべてを引き裂き、問題についてできるだけ早く書いてください(あなたの神経を気の毒に思う必要があります)。
  2. また、チームリーダーと顧客は、プロジェクトの問題点を常に十分に把握している必要があります。そのため、常に正確に把握しておく必要があります。 締め切りに間に合わない可能性があると思われる場合は、できるだけ早くティムリッドにこのことについて書いてください。 チームリーダーが状況に反応しない場合、これは彼の問題であり、あなたの問題ではありません。
  3. あなたがリモートで作業している場合、これはあなたが1日1〜2時間働くことができることを意味しません:-)彼らは非常にすぐにそれに気づくでしょう:-)もちろん、あなたが本当にあなたの給料で平均プログラマーよりも40%速く働くことを知っている場合(すなわち過小評価されています)、もちろん、5時間で日中の仕事をし、3休憩をとることができます(ただし、その逆はできません-3休憩、そして必死に働く:-))。 確かに、スケジュールよりも早くタスクを引き継ぐことはあなたの将来にとってより良いことです:-)
  4. どんな状況でもだれかをだますことは価値がなく、何かがうまくいかなくても隠れないでください。 悪い真実は常に未知のものよりも優れています。 このアイテムはおそらく最も重要です。 悪いニュースを話す力を見つける必要があり、反応する時間を増やすために、できるだけ早くこれを行う必要があります。


ティムリーダー



すべては、あなたとチームのモチベーションに依存します。 誰がどれだけ仕事をし、誰がより速く働き、誰がより遅くなるかを制御しなければ、効果的なコミュニケーションスキームを組織することができず、プロジェクトはすべての人にひどい結果をもたらします。 制御がなければ、チームのパフォーマンスは1か月で3倍になる可能性があります。



次の要素は、作業をより効率的にするのに役立ちます。

  1. すべてのチームメンバーは、1日あたり少なくとも2つのタスクで、クロックに費やした時間に関する日次レポートを送信する必要があります。 レポートの送信期限を設定する必要があります(たとえば、モスクワ時間の2泊)。 報告に遅れた場合-頻繁に繰り返される場合のre責-代替品を探す必要があります。
  2. ニンジンとスティック:re責、ボーナスの喪失、解雇-オフィスよりも頻繁に訴えなければならない 多くのプログラマーはリモートで効果的に作業することはできません。これで他に何もすることはできません。 インタビューの段階では、これもわかりません。 最も勤勉な従業員に報いるために、毎月のボーナス予算に同意することは素晴らしいことです。 あなたは個人的にも良いモチベーションを持つべきですが、これを個人的に監視する必要があります。
  3. すべてのチームメンバーは、Skype +マイク、画面共有ソフトウェア(YuuGuuなど)、バグトラッカーへのアクセス(tracまたはbugzilla-これがないと、5〜10を超えるとタスクがすぐに忘れられます)、重要な情報と内部のwikiドキュメント。 すべてのメールは1分の間隔で確認する必要があります(ただし、職場での非干渉のサポーターであれば、緊急通信をすべてIMに転送し、スキャン間隔を30〜60分に設定できます)。
  4. すべての文字で、時間は1つのタイムゾーンで示される必要があります。 たとえば、モスクワ時間、または顧客の現地時間です。 (顧客の現地時間は、Skypeで見るのに便利です-連絡先情報で)
  5. チームメンバーはsvnに精通し、少なくとも毎朝ローカルコピーを更新し、可能であれば1日の終わりまでに変更をコミットする必要があります。 彼らが何をコミットしたかを見て、必要に応じて直接尋ねる必要があります。「これらの10行に本当に8時間を費やしたことがありますか?」(もちろん、実際に8時間を費やすことができる行があります)。 プログラマは、物理的に誰も背後にいないという事実にもかかわらず、作業の結果が常に考慮されることを知っておく必要があります。
  6. テストサーバーと運用サーバーにはポリシーが必要です。svnから自動更新される1つのテストサーバー、または各プログラマーのテストサーバーのいずれかです。 実動サーバー(例えば、あなた)を更新するのは1人だけです。
  7. すべての人のメールアカウントを同じサーバーに置くことをお勧めします。 これにより、スパムフィルタリング、メッセージ配信速度、および添付ファイルの最大サイズに関する問題がなくなります。 メールに保存されない大きなファイル(50MB以上)をアップロードできる場所があると便利です。
  8. プログラマーの場合のように、悪い情報を差し控えて、すべてが本当に悪い場合は顧客から隠すべきではありません。 可能な限り早期に悪い知らせを発言し、反応を起こすのは常に良いことです。 プログラマーの1人が期限に間に合わないと言ったら、反応する必要があります。自分自身を助けるか、チームの誰かが助けるか、残業するか、期限の変更について顧客に知らせます。 プロジェクトを引き渡すことができなくても、顧客と常に「連絡を取り合って」(朝食や実現不可能な約束なしで)、ロシアの開発者に関する彼の意見を完全に台無しにしないでください:-)


おわりに



この情報が誰かが分散したチームでプロジェクトを成功裏に完了し、邪悪なインディアンから市場の一部を奪うのに役立つことを願っています:-)



All Articles