Ryan Wilcoxは、リモート従業員として10年近く繁栄しており、現在はApeeScapeエンジニアとして、また彼の創設者として、世界中の企業のコンサルタントと開発者の両方として働いています。 自社 。彼は現在フルタイムで働いています Fanzter 、ウェブおよびiOS製品会社。
新しいリモコンを始めるか、自宅で仕事をするギグ、それが契約プロジェクトであろうと、 常勤職 、毎日オフィスに行くことに慣れている場合は、少し威圧的になる可能性があります。
しかし、このスタイルの雇用は 人気が高まっている 、いくつかの非常に 著名な企業 それに彼らの支持を貸します。
私はこれらのツールを使用して、さまざまな規模と期間のプロジェクトで何年にもわたってリモートで作業することに成功しました。この投稿では、さまざまな状況で作業するために私が選んだベストプラクティスのいくつかを列挙したいと思います。ここでの在宅勤務ガイドは、ソフトウェアとハードウェアに関する具体的な推奨事項から、チームの締め切りに間に合わせるためのヒントまで多岐にわたります。
の重要性を十分に強調することはできません 適切なオフィスのセットアップ 。それはあなたをより生産的にし、より専門的に見えるようにします。たとえば、ヘッドセットは、オンライン通話中のエコーを回避するために重要です。このような小さなことは、リモコンとして作業するときに大いに役立ちます。
自分のホームオフィス内で不可欠だと思う、リモートで作業するためのツールをいくつか紹介します。
スタートアップのための資金調達
これらのいくつかは明白に聞こえますが、ここですべてのマークを打っていないリモコンの数に驚かれることでしょう。開発者として、私たちは途切れることなく考えるための静かな空間が必要です。また、リモートワーカーとして、電話会議、会議、ペアプログラミングセッションなどを中断することなくホストできる静かな場所が必要です。 ソファで作業するだけでは、長期的なリモートワークソリューションとしてはおそらく適切ではありません。
典型的な開発環境を補完し、リモートワークに関連する課題を克服するのに役立つ優れたソフトウェアツールがたくさんあります。これが私が本当に好きなものです:
会議を計画するときは、常に両方のタイムゾーンを確認してください。そして、あなたが招待状を受け取ったとき、あなたは常に逆算をして、あなたが同じ数を思い付くようにするべきです。会議に複数のタイムゾーンが含まれる場合は、UTC時間も含めるのが好きです。誰もがUTCからのオフセットを知っている必要があるため、これは全員が同じページにいることを確認するためのもう1つのチェックです。
私はまともなサイズでした Rails 数年前のチーム。何人かのチームメンバーは、少なくとも一部の時間はリモートで作業していました。チームの文化は、夕方に多くの作業が行われるというものでした。キャンプファイヤーやその他の有料チャットサービスを指して、当時の公式チームリーダーを通じてチャットルームを設置することを提案しました。何もせずに数週間が経過し、チャットルームがチームの資産になるという私の理論をテストするために、開発者だけでSkypeチャットルームをセットアップすることにしました。この実験は非常に成功したことが証明されました。非常に成功したため、別のソリューションの代わりにSkypeチャットを使い続けました。このSkypeチャットルームは、ほぼ1年後にプロジェクトを離れたときもまだ使用されていました。場合によっては、シンプルが最良のオプションになることがあります。
その後、同じプロジェクトの重要な締め切りの間に、開発者、ビジネス分析者、プロジェクトマネージャー、およびクライアントを含むSkypeチャットルームを設定しました。これにより、一般的なグループが質問にすばやく対応できるようになりました。開発者専用のチャットルームほど活発ではありませんが、それでも非常にうまく機能しました。 Skypeチャットは、一部のユーザーが管理および制御できます グループチャットコマンド 、チャットの役割の設定とアクセス許可の設定。これにより、チャットルームをユースケースに合わせて実際にカスタマイズできます。このような単純さの設定でさえ、リモートの生産性を向上させることができます。
使用しているバグトラッカーから3つのことを知りたいです。
これらにはそれぞれ目的があります。
まず、「私は今何に取り組んでいますか?」:従来のオフィスで働くときは、バックグラウンドでおしゃべりがあります。これにより、他の人が何をしているのかについての一般的なアイデアが得られます。 「はい、現在積極的に取り組んでいます」というバグトラッカーシステムの明示的なマーカーは、リモートワークに同様のパターンと感触をもたらす可能性があります。
第二に、「次のリリースのために私のプレートには何がありますか?」 「私が責任を負うバグ」または「私が処理しているバグ」を意味します。すべてのチームには確かに何度か行き来がありますが、バグを取得したいのか、リリースのためにバグを完成させるのに助けが必要なのかを誰に尋ねるかを知ることも良いことです。
チームがこのようにまったく機能しない可能性もあります。たとえば、ワークフローでは、各開発者に最初に1つのバグのみが割り当てられ、1つのバグが完了すると、割り当てられていないパイルが選択されます。これも生産的です。
「ソフトウェアの次のリリース」は大きなものである必要はありません。「次のリリース」が意味するチームに参加しました。「3日後、クライアント向けに新しいアルファビルドをリリースします。 」。しかし、この新しいリリースで何が予定されているかを誰もが知っておくのは良いことです。特に、現在のチケットが完了したときに未割り当てのチケットを選択した場合。
レスポンシブデザインのための最高のメディアクエリ
投稿の下部に、特定のバグトラッカーに関するいくつかの推奨事項を含めました。
一部の人にとって、チームのコミュニケーションは、リモートまたは自宅からの作業で最も威圧的な部分です。だが これはあなたがそれをさせた場合にのみ問題になります 。
オフィスでは、席に着く途中でみんなで散歩していると、「こんにちは」と言う人が少し冗談を言います。あなたの同僚はあなたが仕事をしていることを知っています。なぜなら彼らはあなたが向こうのあなたの机で働いているのを見ているからです。
リモートワーカーはもう少し明確にする必要があります– あなたが彼らに言わない限り、誰もあなたが働いていることを知りません 。しかし、適切なコミュニケーション慣行を確立すれば、オフィスを散歩したり、エレベーターを降りたりするのではなく、ボタンを押すだけで同僚が利用できるようになります。
これらのヒントは、より大きなチームの一員としてリモート管理されている従業員にさらに当てはまりますが、それが唯一の開発者である場合に役立つことがあります。
私はこれらのアイデアのいくつかをからピックアップしました ワイドチームポッドキャストエピソード48 。
1日の始めに、IRC(またはチームが使用するツール)に参加して、 こんにちはと言う' 、人々の日々がどうなっているのかなどについてチャットします。IRCに参加して、子供、週末、スポーツチーム、週末のハッキングについて尋ねることを意味する場合でも。あなたが現在自宅で一生懸命働いていることを人々が知っているとき、あなたは見えなくなることはありません。 関係を築き、あなたがそこにいることを人々に知らせましょう 。
チャットで他の人とチャットし、同僚との関係を維持するようにしてください。これは、コーヒールームなどで人にぶつかったときとは異なります。コードをコミットしたり支援が必要になったときに人々が準備できるように、明示的に連絡を取り、連絡を取り合う必要があります。
自分の存在を感じさせるだけでなく、リモートのチームメイトにいつあなたがいるのかを知らせる必要があります ない ワーキング。従来のオフィス環境と同じように、一日中姿を消して同僚をぶら下げたままにしたくはありません。
他の多くの開発者とチームを組んでいる場合、またはリモートの従業員を管理している場合は、仕事の開始時にチェックインするのが理にかなっています。シンプルな「おはようございます、皆さん」は、あなたがプロジェクトの作業を開始する準備ができており、自宅やベッドではなくなったことを人々に知らせます。
日中の昼食や休憩時間に「1時間で戻ってきて」というメッセージを送るのもいいですね。リモートワークは多くの点で優れていますが、1つの厄介なシナリオは、同僚に質問しても応答がないことです。 30分間不在であるため、応答していませんか?それとも、彼らはゾーンの奥深くにいて、チャットを聞いていないからですか?たぶん会議で? 「Bebackin…」メッセージは、これらの懸念を軽減し、ワークフローをスムーズにすることができます。
午後が終わったら、いつ戻ってくるかを人々に知らせましょう。多分それは「朝に会いましょう」または「[x]を終わらせるために今晩遅くに戻ってください」です。しかし、「1時間で戻る」メッセージのように、チームが適応できる特定の期待を設定します。
と呼ばれる興味深いスタートアップがあります Sqwiggle それはこれらの問題のいくつかを解決するかもしれません(私はまだそれを自分で試していませんが)。数秒ごとにあなたの写真を撮るだけでなく、チームメンバーがあなたの写真をクリックしてビデオ/オーディオチャットを開始したり、テキストチャットコンポーネントを提供したりすることもできます。写真の背後にある考え方は、コンピュータの前にいるかどうかを一目で確認することです。 (オンラインで誰かとチャットしようとしてすぐに返信がないことほど悪いことはありません。彼らは他の何かに追いついていますか?ゾーンの奥深くですか?チャットの通知が表示されませんか?今すぐバスルームで?) Sqwiggleについて聞いた ワイドチームポッドキャストエピソード83 。
リモートフリーランスのギグは常に異なります。 (それは魅力の一部です!)時には、純粋にスタッフの増強として、既存の開発者チームに参加することがあります。たぶん、このチームはしばらく一緒にいて、その場合、彼らはすでにコミュニケーション慣行を確立しています。
一方、プロジェクトの開発者があなただけで、技術者以外のクライアントと協力している場合もあります。独自のソフトウェア開発のベストプラクティスを設定し、操作の実行方法をある程度制御できます。以下は、私の10年ほどのリモートワーク経験からのいくつかのベストプラクティスです。ほとんどの場合、これらは半週間(20時間/週)または1週間のスケジュール(40時間/週)を対象としています。
開催について言うべきことがあります スタンドアップミーティング プロジェクトの状況について話します。これらは 従来のオフィスでは非常に一般的です 、しかし、リモートチームにとって生産性が高くない理由はありません。クライアントと開発者の2者間のコミュニケーションを強化するためのもう1つの方法です。
従来のスタンドアップミーティングでは、昨日何に取り組んでいたか、今日何に取り組んでいるか、障害があるかどうかを尋ねられます。この形式は、チームの規模によっては機能する場合と機能しない場合があります。単一の開発者プロジェクトの場合、これらの実際の質問は意味がありません。
投資家がスタートアップに求めるもの
スタンドアップミーティングを開催する頻度は、チームの規模と文化によって異なります。ただし、これが私の推奨事項です。
1〜3人の開発者の場合、これらの質問はほとんど自明です。チケットを処理するときに個々の作業を追跡するのが簡単なので、各開発者が何をしているのかがわかります。誰もが何をしているのかを知っています。作業。
大規模なリモートチームでは、より多くの部分が動いています。作業を複製したり、互換性のない変更を加えたりして、だれも誰かの仮想のつま先を踏まないようにする必要があります。
ApeeScapeの週ごとの支払い構造を考えると、週に2回の会議は、クライアントが週の料金からだまされたと感じる前に、プロジェクトについて懸念を表明するのに十分な時間を与えます。週に1回の会議があるだけで、クライアントは仕事の質に不満を持っている可能性があり、開発者は成果物を調整する時間がありません。
高度なリモートチーム 在宅勤務中に実際の会議をスケジュールせずに、すべての利害関係者を同じページに保持する他の方法がある場合があります。私はまだ誰かと電話/スカイプ/ハングアウトに乗って、そのように会議をするのが好きです。
小規模なチームの場合、週に2回のスタンドアップミーティングが非常にうまく機能します。コースの修正は迅速に行われますが、開発者は各ミーティング中に報告すべき重要なことがまだあります。
Python関数は、通常の状況では、その値についてモジュール変数を参照できません。
プロジェクトのサイズにもよりますが、小規模(1〜2人の開発者)の場合は毎週、大規模(3人以上の開発者)のプロジェクトの場合は隔週でクライアントに送信される成果物が好きです。このリズムにより、開発者は、クライアントが表示できるインターフェイス(またはユーザーエクスペリエンスの向上)など、かなりの量の作業を完了するのに十分な時間を確保できます。
技術者以外のクライアントの場合、進捗状況を測定できる唯一の指標は、画面に表示されるものです。
開発者にとって、特に技術者以外のクライアントの場合、ユーザーインターフェースで視覚化できる進捗状況だけが、クライアントにとって重要なことであることが多いことを覚えておくことが重要です。技術者以外のクライアントは、今週500行のコードをプッシュしたり、Webサービスとのやり取りに苦労したりすることを気にしません。 進捗状況を測定できる唯一の指標は、画面に表示されるものです。 。それは、バックエンドで良い仕事をすることが無関係であるということではなく、むしろ、クライアントの目にこれらすべての良い仕事を具体的にする必要があるということです。
だから私は毎週または隔週の成果物が好きです。それより短いものは、開発者を困難な場所に置くことがよくあります。おそらく、2日間バックエンド作業を行うのに行き詰まり、インターフェースを完成させる時間がないため、何もすることがありません。 公演 クライアント。
ソフトウェアプロジェクトの種類によっては、これらのクライアントリリースのすべてが一般にリリースされるわけではありません。たとえば、Railsプロジェクトで作業している場合、承認された変更をすぐにデプロイしたい場合があります。一方、モバイルアプリでは、リリースを「1.3a10」と呼ぶことができますが、現在のリリースは、後で展開されるソフトウェアの新しい1.3バージョンのより大きな機能セットの一部にすぎません。
ここで、リモートバグトラッカーのベストプラクティスが役立ちます。バグ追跡により、クライアントは次のことを認識します。
クライアントはこのリリースから何を期待できるかを知っており、開発者は彼らの前にどんな仕事があるかを知っています。
リモートチームが使用するのに十分成熟している場合 継続的デプロイ および/または Kanban それなら大丈夫ですただし、これらはどちらも非常に高度な手法であり、強力な開発者ベースの文化を持つ組織に適しています。カスタムソフトウェア開発が必要であるがコストがかかると見なされているほとんどの組織は、おそらくこれらの手法のいずれにも対応できていません。なんで?私が見た2つのことは クライアントは、開発者がレビューしてほしい変更の数に追いつくことができません 、または 優先順位の変更が速すぎて、開発では1つのことを実行できません 。
ベストプラクティスを確立するチームにたまたま入った場合に備えて、リモートワークを管理するためのツールを以下に示します。これらは私の推奨事項にすぎないことに注意してください。確かに、このガイドはすべての人を対象としているわけではありません。これらのツールが気に入らない場合は、おそらくニーズに合ったツールがあります。
リモートまたは自宅で仕事を始めることは、あなたとクライアントの両方にとってかなりの調整になる可能性があります。私はそれを非常に正しく、そして非常に間違って行ってきました。しかし、それがうまくいけば、それはクライアントや雇用者が解決するための優れた方法になる可能性があります 「タレントクランチ」 問題を作成し、 幅広い機会 主要な技術センターまたは「スタートアップ」ハブの外に住む開発者向け。適切なベストプラクティスを導入してリモートで共同作業する開発者から得られる効率の全世界があります。