今日は旧正月の休暇の三日目の終了後、2月5日です。荒れ狂う流行に対処することができるようにするためには、多くのインターネット企業は、リモートオフィスモデルを開いています。私はチームが2日、各リモートオフィスの結果の前に、4つの大リモートオフィスの初めに、私たちWorktile管理は物事を議論するためにどのように始まったのかを知っている、と時間の可能控え限り発生する可能性のある問題と準備を行うには考えられません。このような状況から、私はうまく行って実際の実装、研究開発チームを見るために2日間、基本的に重要な影響はなかったです。だから我々は危機を乗り切る、我々は共有に皆のためのいくつかの在宅勤務、準備と練習を維持したいと思います。
最初の簡単な紹介で、私はオンラインと社内サーバーの管理グループを担当するプラットフォームグループ開発のコアコンポーネントの運用と保守を担当して含め省Worktileの基本的なプラットフォームの担当者、および部門がありました。当社の運用、保守チームは、常に、分散チームのメンバーは北京と杭州を含めるされた、数年は、多国籍の仕事の経験は、テレワークは新しいものではない、自分の前にあります。次は、私がどのように我々Worktile R＆Dチームの次の側面に話をしたい在宅勤務を実施することです。
明確な原則を在宅勤務
信頼、自信とすべてトップダウン以上 - 最初は、R＆Dラインの長として、私が最初に自分で在宅勤務明確な原則を与えます。換言すれば、第1在宅勤務することは、会社の最高経営責任者（CEO）や通常のチームリーダーは、彼のチームメンバーがプレーする責任を持って、時間と品質を意識し、積極的なコミュニケーション缶の仕事上のタスクを完了することができるように完全な自信を持っているかどうか、管理者に尋ねました質問。それだけが展開する在宅勤務、信頼に基づきます。それ以外の場合は、監視、制御、この危険な状況の疑いに分類されます。だから、信頼は、在宅勤務の基本です。
第二に、あらゆるレベルの管理職は一例でつながるはずです。私たちは、チームメンバーがそれ以上になるように、その後マネージャーとして、オフィス内と同じように仕事をしたいです。例えば、我々は明確なタイムラインのリモートオフィスをWorktile、あなたは私たちのマネージャーが、その間の通信チャネルがスムーズにしなければならないことを保証することになるでしょう。私たちは毎日例会は、マネージャが定期的にミーティングに参加しようとするメンバーを尋ねる（ただし、発言必須に必要ないかもしれません）参加して、我々は彼のチームがメンバーに開放しなければならないことを、この期間中、毎日書くために、すべての企業を必要とし、はっきりと目に見える範囲、マネージャー毎日。
慎重に在宅勤務のルールを開発
この前提の下で明確な信頼では、我々は非常に慎重に在宅勤務の実装の詳細を開発します。私たちは、遠隔通信のコストを最小限に抑えるためには、ルールの明確な理解をモニターし、最も効率的なコミュニケーションと協力のための制約のためにではありません持っているので、「気をつけて」と言います。我々がしようとするので、単純に、少数のルール作り。ここでWorktileの在宅勤務規則は次のとおりです。
- オンラインクリア：チームメンバーが即座に通信できることを確実にするために。
- クリア通信チャネル：Worktile、マイクロ手紙、電話、ビデオ会議。
- 毎日のミーティング：私たちは、毎日のミーティングとしてスクラム開発チームのすべての方法を実行しているので、我々はよデイリースクラムを使用しているため。
- デイリー：（CEOなど、CTO、を含む）完全な提出、部門内の評価のディレクターを見ることができます。
- また、我々は代わりにスクラムマスターの一員として、シニア（ハイレベル）内の部署やグループの担当者が、特に初期、在宅勤務時のスクラムマスターをお勧めして回転するルールが実装されている保持しています。これは主に、最初のリモートスクラムマスターは、より長い時間に会社のシニアメンバー、リソースを調整するために多くの企業が必要とする可能性が高い、より簡単かつ迅速に問題を解決を考慮しています。
例えば、私は（2月4日）昨日、次の図を提出した毎日の仕事で、レビューアは、私たちの部署のメンバーには見えCTO、です。
準備作業は、今では遅すぎではありません
そして、ビジネスの異なるラインは、R＆D部門は、より多くのツール、ソフトウェア、サービス、およびリソースを使用する必要があります。我々はチームを研究開発にリソースを一緒に入れて最初の時間は、毎日、リモートオフィスの後に明らかに個別に評価引当金を使用することができます。あなたのチームならば、今のリソースにはいくつかのリモートオフィスのアクセスの問題を抱えている、と私たちのチェックリストに従って、一つ一つを解決することができます。
- 公開された在宅勤務のリマインダー。私たちは、在宅勤務ルールの注意事項ではなく伝えるための方法を思い出させるためにしようと、それが信頼上で最も基本的な原則について話し始める私の記事に基づいています。たとえば、次の図は、我々は、マイクロ文字のグループにリモートオフィス部門を開き、2月2日の日前の情報です。
- チームメンバーは、必要なソフトウェア（アカウント）に通知する準備が整いました。たとえば、ダウンロードにチームメンバーに通知し、ビデオ会議のためのズームを更新し、必要であれば十分なのProアカウントを購入、などのテンセントの文書ドキュメントコラボレーション、部門Worktileグループとマイクロチャネルグループメンバー内の確認がプッシュでオープンに参加しています。
- 企業のITリソースを外部にアクセスできることを確認してください。例えば、初期の展開の高い依存度のいくつかのためのIPホワイトリストサーバーの開口部に関連する企業VPN、サーバーの研究開発のオープニング。
Worktile R＆Dチームの練習テレワーク
每个团队的工作方式都不尽相同，因此在远程办公的时候遇到的问题和解决的办法都是不一样的。这里我只是想结合实际的情况来介绍一下我们Worktile研发团队是如何在远程办公的场景下完成工作的。
会议安排
我们之前所有的会议安排都是通过Worktile日程同步的，通过Worktile日程不仅能安排会议时间、参会人以及参会人的反馈信息，还能查看当前团队所有的会议安排。而在远程办公的场景下，我们更加明确了“以Worktile日程安排为准”的原则，即任何的会议都要通过Worktile来组织，避免出现电话、微信等多个日程安排信息不同步的现象。
譬如下图就是我们部门本远程办公的日程安排，包括Sprint Plan、Daily Scrum、架构设计评审、管理层会议等。
下图是我们的Daily Scrum日程详情。和平日唯一的不同是，为了整个部门更好的沟通，在远程办公期间我们将另外一个组的成员也加入进来（这个组目前没有使用敏捷开发），将Daily Scrum扩展成每日工作例会。
视频会议
远程办公主要的一个依赖工具就是视频会议。由于之前的工作原因，这种会议形式并不陌生。对于团队其它没有经历过这种会议的成员，我事先提出了一些特别的要求。
- 关闭摄像头。这不仅仅是为了减少不必要的带宽占用，更主要的是希望参会人员将注意力集中到会议本身。远程办公，特别是现在的居家办公，大家的穿着、房间布置等可能都会和以往不同。开通摄像头很容造成注意力的转移。因此我第一个要求就是所有参会人员要关闭摄像头。
- 控制麦克风。成员进入会后要保持麦克风关闭，防止会议中各种杂音的干扰。如果需要发言则打开麦克风，发言完毕后关闭。这个规格还有一个好处就是能够尽量避免多人同时说话的情况。因为面对面的会议我们很容易区分说话者是谁，但是远程会议却不容易区分。因此尽量保证会议中只有1-2人发言。
- 充分使用共享屏幕的功能。现在几乎所有的视频软件都有共享屏幕的功能，和Worktile这种SaaS类工具联合使用，其效果几乎和面对面的会议没有区别。另外可以灵活使用Remote Control的功能，必要时让其他成员控制当前共享的屏幕，方便讨论。
下图是我们今天上午10点的Daily Scrum会议。我们通过Zoom进行会议，Scrum Master共享自己的屏幕，通过Worktile Agile展示当前迭代的任务板，每个成员轮流打开发言。
而下图是昨天我们团队进行的架构设计和代码评审会。一样是通过Zoom进行的。会议组织者发起并共享屏幕，在会议中一些成员通过Remote Control的功能控制组织者的屏幕，提出设计上的问题和建议。
协作文档
除了通过视频会议软件，我们还是用一些协作文档配合以及一些即时消息工具进行协作。譬如在我们2月份研发部门工作计划会上，就是用腾讯文档和微信群，大家在讨论的过程中一起完成计划表格的内容。
工作任务的协同
我们团队平日工作就是基于Worktile进行协同的，而且因为研发团队都是程序员组成的，因此即使此前在同一个工作区办公，大家也是优先通过Worktile上的在线功能交流。比如使用Worktile的即时消息对一些问题进行简单的讨论，在开发任务下面进行评论等等。
现在切换到远程办公的场景，其实工作的流程和方式变化不大。只不过是由在办公室发信息发评论变成了大家在家发消息发评论。
下图就是今天中午我们进行架构设计评审后，针对一些小问题在Worktile上的讨论。
下图是我们针对一个开发中的用户故事，通过评论进行产品细节的沟通。评论的好处是，沟通的过程和结果都可以在用户故事上保留，方便日后的查阅。
代码提交和代码评审
Worktile的代码一直是托管在Github上的，因此远程办公对于我们写代码、提交代码和做Code Review没有任何影响。唯一的影响可能是个别成员家里的网速不够给力。
而对于公司自己托管代码仓储的情况，比如搭建私有Gitlab仓储，则必须要提前由IT部门准备好外网访问权限，或者开通企业VPN。而如果像我们一样使用SaaS版本的仓储则完全不需要任何准备。
顺便说一句，我感觉这次的远程办公会让很多企业更明显的感觉到采用SaaS工具的重要性。
下图就是我们在Github上进行的Code Review。这样的方式我们之前就在使用，现在在远程办公的场景下也一样适用。
CI/CD
其实CI/CD和远程办公的关系并不是很大，但是如果我们研发部门已经建立好了完整的流水线，那么将会对远程办公帮助很大。我们知道，研发和运维的沟通和协作一直都是一个问题，而流水线的引入就是为了解决这个问题的。此前在一起工作，可能这个沟通的问题还没有那么明显的显现出来，但是现在研发团队、运维团队都是远程办公，如果有了这个稳定的流水线支持，一方面可以节省很多的沟通成本（研发提交代码直接部署），另一方面也自动化的保证了产品的质量（各条流水线集成的各种测试）。
下图就是Worktile自己的流水线执行信息。团队的所有成员都能够看到，并且在试行失败的时候会通过Worktile的消息通知整个团队。
线上的部署和维护
虽然我们有自动化的流水线，但是由于线上环境的特殊性，我们还是会使用手动触发流水线的方式部署线上环境。由于团队特殊性，我们之前就已经通过Worktile 构建了线上部署申请平台和线上数据调查平台。
研发团队在需要部署的时候通过这个平台提出申请，运维人员批准后在对应时间操作。它的好处不仅仅是减少了频繁的沟通，而且让部署操作正规化、合规化，并且可追溯。
下图就是我们的线上部署申请单。
对个人的一点建议
鉴于之前我提到的信任原则和最小化规则的原则，我们对于研发团队几乎没有给出个人工作生活的要求，譬如网上提到的开始工作前要在房门前假装刷卡，着工作装而非居家装等等。因为我们相信我们的同事能够很好的完成自己的工作，无论是在家还是在公司，是否穿着睡衣。
私たちの唯一のアドバイスは、家族の活動の作業に関与していないことと、労働生活の分離をしようとすることですが、休憩中に、時に簡単な対話型のコミュニケーションと家族の水汲み。
概要
これらの日といくつかの利益を在宅たちのR＆DチームWorktileコンテンツ上に引用するだけでなく、私たちは前にいくつかの準備を含んでいます。我々は言及されているものをより多くのR＆Dチームは、テレワークの導入をスムーズに助けることができることを願っています。
繰り返しますが、私は在宅勤務は、リーダーシップチームの責任と自己駆動力の感覚を持っている必要があり、人々の中核であると考えています。ベースとする同じ時間が必要完全な信頼ではこの前提、従業員の信頼を導くだけでなく、チームとチーム間のチームメンバーの信託との間に信頼するだけではなく。
最後に、私たちの効率的なコラボレーションの基盤を支援するためのさまざまなツールの合理的かつ柔軟な使用。ジャストインタイムの在宅勤務ではなく、近い将来に、私たちは、オフィスに戻った後。私たちは、在宅でこのビジネスを実践し、当社のR＆Dチームは、結束と効率の実行を向上させるためにあらゆる機会を求めています。
作者简介：徐子岩，Worktile 首席架构师&研发总监，前微软高级项目经理、微软MVP，《实战Windows Azure》一书作者，十五年软件开发经历，包括企业级软件的架构设计、开发和测试。熟悉服务 端开发技术 C#、Node.js 以及相关的框架(ASP.NET、Express、Web Socket 等)和数据库(SQL Server、MongoDB)，缓存和消息队列(Redis、 RabbitMQ)
Worktile公式サイト：https://worktile.com/
著者：Worktileチーフアーキテクト紫ヤンの
最初の「に登場記事Worktile公式ブログ」、ソースを明記してください。
