원격으로 일하면서 여전히 최고가 되는 방법

게시 됨: 2022-03-11

Ryan Wilcox는 거의 10년 동안 원격 직원으로 번창했으며 현재 Toptal 엔지니어이자 자신의 회사 설립자로서 전 세계 기업의 컨설턴트이자 개발자로 일하고 있습니다. 그는 현재 웹 및 iOS 제품 회사인 Fanzter에서 풀타임으로 일하고 있습니다.

원격 작업자의 도구 벨트

새로운 원격 작업을 시작하거나 재택 근무를 시작하는 것은 계약 프로젝트든 정규직이든 매일 사무실에 출근하는 데 익숙하다면 약간 겁이 날 수 있습니다.

그러나 이러한 스타일의 고용은 인기를 얻고 있으며 일부 유명 회사에서 이를 보증합니다.

저는 다양한 규모와 기간의 프로젝트에서 이러한 도구를 사용하여 원격으로 성공적으로 작업했습니다. 이 게시물을 통해 다양한 상황에서 작업하기 위해 선택했던 몇 가지 모범 사례를 열거하고자 합니다. 여기에서 제공하는 원격 및 재택 근무 가이드는 소프트웨어 및 하드웨어에 대한 특정 권장 사항에서 팀의 기한을 맞추기 위한 팁에 이르기까지 다양합니다.

원격 또는 홈 오피스 설정

올바른 사무실 설정의 중요성은 아무리 강조해도 지나치지 않습니다. 그것은 당신을 더 생산적으로 만들고 더 전문적으로 보이게 할 것입니다. 예를 들어 헤드셋은 온라인 통화 중 에코를 방지하는 데 매우 중요합니다. 원격으로 일할 때 이와 같은 작은 것들이 먼 길을갑니다.

다음은 내 홈 오피스에서 필수라고 생각하는 원격 작업을 위한 몇 가지 도구입니다.

  • 헤드셋 . 특히 중요한 시간에 배터리가 부족하지 않기 때문에 유선 헤드셋을 정말 좋아합니다. 많이 입게 될 테니 편안한 옷을 준비하세요. 저는 두 개의 iMicro 헤드셋이 있습니다. 하나는 책상용이고 다른 하나는 노트북 가방에 넣습니다. 노트북 가방 헤드셋으로서 두 가지 큰 장점이 있습니다. USB로 전원이 공급되기 때문에 배터리를 충전 상태로 유지하는 것에 대해 걱정할 필요가 없고, 가방에서 배터리가 파손된 경우 교체하는 것이 매우 저렴하다는 것입니다. 사실, 나는 이 특정 헤드셋이 긴 회의 통화에 약간 불편하다는 것을 알게 되었습니다. 많은 작업을 수행하는 경우 Corsair Vengeance 2000을 추천합니다. 배터리 기능이 있는 편안한 무선 헤드셋으로 하루 종일 작업할 수 있습니다. (참고로 이들 중 어느 것도 추천 링크가 아닙니다.)
  • 문이 닫히는 조용한 장소 , 특히 다른 사람들과 함께 살 때, 특히 가족이 있는 경우.
  • 안정적인 인터넷 연결 또는 양호한 백업 연결. 예를 들어, 나는 DSL을 가지고 있고 DSL이 꺼지면 내 전화기에 테더링을 설정했습니다. Skype 문제가 계속 발생하거나 전화가 끊기면 여러 원격 직원을 관리하려는 다른 사람들의 눈에 덜 안정적이고 덜 전문적이 됩니다.
  • 스카이프 . 이것은 임시 회의 통화, 클라이언트와의 인스턴트 메시징 또는 낮은 의식 대화방을 만드는 데 적합합니다.
  • SkypeOut , 전화기에서 Skype 연락처로 전화를 걸고 받을 수 있습니다. 이것은 특히 컴퓨터에서 멀리 떨어져 있을 때와 (시간을 잘못 계산했거나 클라이언트에 긴급 상황이 발생한 경우 등) 굉장합니다.
  • 전기 주전자 . 가끔은 뜨거운 커피를 마시고 싶지만 내 흐름을 방해하고 싶지는 않습니다.
  • 물 갤런 주전자 . 주전자, 또는 음료. 긴 코딩 세션 또는 긴 회의 통화에 적합합니다.

이상적인 원격 또는 재택 근무 설정의 묘사.

이들 중 일부는 명백하게 들리지만 여기에서 모든 표시를 하지 않는 리모콘의 수에 놀랄 것입니다. 개발자로서 우리는 방해받지 않고 생각할 수 있는 조용한 공간이 필요합니다. 그리고 원격 근무자로서 우리는 회의, 회의, 짝 프로그래밍 세션 등을 방해받지 않고 주최할 수 있는 조용한 장소가 필요합니다. 소파에서 일하는 것만으로는 장기적인 원격 근무 솔루션이 아닐 수 있습니다.

소프트웨어 도구

일반적인 개발 환경을 보완하고 원격 작업과 관련된 문제를 극복하는 데 도움이 되는 우수한 소프트웨어 도구가 많이 있습니다. 다음은 내가 정말 좋아하는 몇 가지입니다.

  • AwayFind 는 SMS를 통해 메시지를 전달하므로 긴급 이메일, 특히 회의 참석자의 막바지 메시지에 유용합니다.
  • 전 세계의 클라이언트 및 동료와 작업하기 위한 시간대 변환기 . 시각 장애인이 더 쉽게 접근할 수 있는 버전으로 Time And Date의 World Time Clock, Every Time Zone, World Time Buddy 또는 The Time Now를 좋아합니다.
  • 팀의 모든 사람을 위한 채팅/IRC 룸 . 이것은 형식적(예: Campfire 방)이거나 Skype 대화방(Keep It Simple, Silly) 스타일일 수 있습니다.
  • 버그 추적기 - 이것은 자체 섹션이 필요하므로 아래를 참조하십시오.

회의를 계획할 때는 항상 두 시간대를 모두 확인하십시오. 그리고 초대를 받았을 때 항상 수학을 거꾸로 계산하고 같은 숫자가 나오는지 확인해야 합니다. 회의에 여러 시간대가 포함되는 경우 UTC 시간도 포함하는 것이 좋습니다. 모든 사람이 UTC에서 오프셋을 알아야 하므로 모든 사람이 같은 페이지에 있는지 확인하는 또 다른 검사입니다.

저는 몇 년 전에 적당한 규모의 Rails 팀에 ​​있었습니다. 여러 팀원들이 최소한 시간의 일부를 원격으로 일했고, 팀 문화는 많은 일을 저녁에 하는 것이었습니다. 나는 당시 공식 팀장을 통해 캠프파이어나 다른 유료 채팅 서비스를 가리키며 채팅방을 개설하자고 제안했다. 아무런 조치도 취하지 않고 몇 주가 흘렀고, 채팅방이 팀의 자산이 될 것이라는 내 이론을 테스트하기 위해 개발자만으로 Skype 채팅방을 설정하기로 결정했습니다. 이 실험은 매우 성공적이었습니다. 너무 성공적이어서 다른 솔루션 대신 Skype 채팅을 계속 사용했습니다. 이 Skype 대화방은 제가 거의 1년 후에 프로젝트를 떠났을 때 여전히 사용 중이었습니다. 때로는 단순한 것이 최선의 선택이 될 수 있습니다.

나중에 같은 프로젝트의 중요한 기한 동안 개발자, 비즈니스 분석가, 프로젝트 관리자 및 클라이언트가 포함된 Skype 대화방을 설정하여 일반 그룹에서 질문을 신속하게 해결할 수 있었습니다. 개발자 전용 채팅방만큼 활발하지는 않지만 여전히 잘 작동했습니다. Skype 채팅은 일부 그룹 채팅 명령, 채팅 역할 설정 및 액세스 권한 설정으로 조정 및 제어할 수 있으므로 채팅방을 사용 사례에 맞게 실제로 사용자 지정할 수 있습니다. 이러한 단순성 설정만으로도 원격 생산성을 향상시킬 수 있습니다.

원격 작업 모범 사례: 버그 추적

내가 사용하고 있는 버그 추적기에서 세 가지를 알고 싶습니다.

  • 나는 지금 무엇을 하고 있습니까?
  • 이 소프트웨어의 다음 릴리스에 대한 내 판은 무엇입니까?
  • 이 소프트웨어 릴리스에 대한 전체 팀의 결과물은 무엇입니까?

이들 각각에는 목적이 있습니다.

첫째, "내가 지금 무엇을 하고 있습니까?": 전통적인 사무실에서 일할 때 배경 잡담이 있습니다. 이것은 다른 사람들이 무엇을 하고 있는지에 대한 일반적인 아이디어를 제공합니다. 버그 추적기 시스템에서 "예, 지금 적극적으로 작업 중입니다."라는 명시적 표시는 원격 작업에 유사한 패턴과 느낌을 도입할 수 있습니다.

둘째, "다음 릴리스에 대한 내 판은 무엇입니까?" "내가 책임지고 있는 버그" 또는 "내가 처리하고 있는 버그"를 의미합니다. 모든 팀에는 확실히 앞뒤가 맞지 않는 부분이 있지만 버그를 잡고 싶거나 릴리스용 버그를 마무리하는 데 도움이 필요한지 묻는 사람을 아는 것도 좋습니다.

팀이 이와 같이 작동하지 않을 수도 있습니다. 예를 들어 워크플로는 각 개발자에게 처음에 하나의 버그만 할당하고 하나의 버그가 완료되면 할당되지 않은 더미를 선택하는 경우일 수 있습니다. 이것은 또한 생산적일 수 있습니다.

"소프트웨어의 다음 릴리스"는 큰 의미가 없습니다. 저는 "다음 릴리스"가 "지금부터 3일 후에 클라이언트를 위한 새로운 알파 빌드를 릴리스할 예정"을 의미하는 팀에 있었습니다. ". 그러나 이 새 릴리스에서 무엇이 나올지 모두가 아는 것은 여전히 ​​좋습니다. 특히 현재 티켓이 완료되었을 때 할당되지 않은 티켓을 선택하는 경우.

게시물 하단에 특정 버그 추적기에 대한 몇 가지 권장 사항을 포함했습니다.

원격 작업 모범 사례: 팀 커뮤니케이션

일부 사람들에게 팀 커뮤니케이션은 원격으로 또는 집에서 작업할 때 가장 두려운 부분입니다. 그러나 이것은 당신이 그것을 내버려 둔 경우에만 문제가 될 것 입니다.

사무실에서 자리로 가는 길에 모든 사람들이 지나갈 때마다 "안녕하세요"라고 말하는 사람들이 있습니다. 당신의 동료들은 당신이 직장에 있다는 것을 알고 있습니다. 왜냐하면 그들은 당신이 저기, 당신의 책상에서 일하는 것을 보았기 때문입니다.

원격 작업자는 약간 더 명시적이어야 합니다. 귀하가 말하지 않는 한 아무도 귀하가 일하고 있다는 사실을 모릅니다 . 그러나 올바른 의사 소통 방식을 설정하면 사무실을 가로질러 걸어가거나 엘리베이터를 타고 내려가는 등의 작업이 아니라 버튼을 누르기만 하면 동료를 만날 수 있습니다.

이 팁은 더 큰 팀의 일원으로 원격으로 관리되는 직원에게 더 많이 적용되지만 유일한 개발자인 경우 유용할 수 있습니다.

존재감을 느끼게 하기: 보이지 않게 이동하지 마십시오

나는 Wide Teams Podcast 에피소드 48에서 이러한 아이디어 중 몇 가지를 선택했습니다.

하루를 시작할 때 IRC(또는 팀에서 사용하는 모든 도구)에 올라타서 "Hello"라고 말하고 사람들의 하루가 어떻게 돌아가는지 등에 대해 이야기합니다. IRC에 올라타서 아이들, 주말, 스포츠 팀 또는 주말 해킹. 사람들이 당신이 현재 집에서 열심히 일하고 있다는 것을 알 때, 당신은 보이지 않게 되지 않습니다. 관계를 구축하고 사람들에게 당신이 거기에 있다는 것을 알리십시오 .

채팅에서 사람들과 채팅하고 동료들과 계속 소통하세요. 이것은 커피방 등에서 사람을 만났을 때와는 다릅니다. 코드를 커밋하거나 도움이 필요할 때 사람들이 준비될 수 있도록 명시적으로 손을 뻗고 연락을 유지해야 합니다.

'시작일', '점심시간', '돌아와' 메시지

당신의 존재감을 느끼게 하는 것과 함께, 당신이 일 하지 않을 때 멀리 떨어져 있는 팀원들에게도 알려야 합니다. 전통적인 사무실 환경에서와 마찬가지로 하루 종일 사라지고 동료를 교수형에 처하게 하고 싶지 않습니다.

여러 다른 개발자와 함께 팀에 있거나 원격 직원을 관리하는 경우 근무일을 시작할 때 체크인하는 것이 좋습니다. 사람들에게 프로젝트 작업을 시작할 준비가 되어 있고 더 이상 집이나 침대에 있지 않다는 것을 사람들에게 알리는 간단한 "좋은 아침입니다."

낮에 점심이나 업무 시간에 "1시간 후에 돌아올 것" 메시지를 보내는 것도 좋습니다. 원격 근무는 여러 면에서 훌륭하지만 한 가지 걱정스러운 시나리오는 동료에게 질문을 하고 응답을 받지 못하는 것입니다. 30분 동안 자리를 비워서 응답이 없습니까? 아니면 그들이 영역 깊숙이 있고 채팅을 듣지 않기 때문에? 아마도 회의에서? "돌아오세요..." 메시지는 이러한 우려를 완화하고 워크플로를 원활하게 할 수 있습니다.

오후에 일을 마치면 사람들에게 언제 돌아올 것인지 알립니다. 아마도 "아침에 만나요" 또는 "오늘 저녁에 [x] 일을 끝내기 위해 다시 와"일 수 있습니다. 그러나 "1시간 후 복귀" 메시지와 마찬가지로 팀이 적응할 수 있는 특정 기대치를 설정합니다.

이러한 문제 중 일부를 해결할 수 있는 Sqwiggle이라는 흥미로운 스타트업이 있습니다(아직 직접 시도하지는 않았지만). 몇 초마다 사진을 찍는 것 외에도 팀 구성원이 사진을 클릭하여 비디오/오디오 채팅을 시작하고 텍스트 채팅 구성 요소를 제공할 수 있습니다. 그림 뒤에 숨은 아이디어는 한 눈에 컴퓨터를 보고 있는지 여부를 확인하는 것입니다. (온라인으로 누군가와 채팅을 시도하고 빠르게 응답하지 않는 것보다 더 나쁜 것은 없습니다. 그들이 다른 것에 사로잡혀 있습니까? 깊은 곳에서? 채팅 알림이 보이지 않습니까? 지금 화장실에 있습니까?). 나는 Wide Teams Podcast 에피소드 83에서 Sqwiggle에 대해 들었습니다.

모범 사례를 설정할 수 있는 프로젝트에서

원격 프리랜서 공연은 항상 다릅니다. (그것은 매력의 일부입니다!) 때때로 당신은 순전히 직원 보강으로 기존 개발자 팀에 합류합니다. 아마도 이 팀은 얼마 동안 함께 했고, 그런 경우에는 이미 커뮤니케이션 관행을 수립했을 것입니다.

반면에 기술이 아닌 클라이언트와 함께 작업하는 프로젝트의 유일한 개발자인 경우도 있습니다. 자체 소프트웨어 개발 모범 사례를 설정하고 작업 실행 방법을 일부 제어할 수 있습니다. 다음은 10년 정도의 원격 근무 경험에서 얻은 몇 가지 모범 사례입니다. 대부분 반주(20시간/주) 또는 전체 주(40시간/주) 일정을 대상으로 합니다.

스탠드업 미팅

프로젝트 현황에 대해 논의하기 위해 스탠드업 미팅을 개최하는 것에 대해 할 말이 있습니다. 이들은 전통적인 사무실에서 매우 일반적이지만 원격 팀을 위해 생산적이지 못한 이유는 없습니다. 클라이언트와 개발자라는 두 당사자 간의 통신을 시행하는 또 다른 방법일 뿐입니다.

기존의 스탠드업 미팅은 어제 작업한 내용, 오늘 작업할 작업 및 방해 요소가 있는지 묻습니다. 이 형식은 팀의 규모에 따라 작동할 수도 있고 작동하지 않을 수도 있습니다. 단일 개발자 프로젝트인 경우 이러한 실제 질문은 의미가 없습니다.

스탠드업 미팅을 얼마나 자주 해야 하는지는 실제로 팀 규모와 문화에 따라 다릅니다. 그러나 여기에 내 권장 사항이 있습니다.

  • 1-3명의 개발자: 일주일에 2번의 스탠드업 스타일 회의
  • 4명 이상의 개발자: 일일 스탠드업 미팅

1-3명의 개발자가 있는 경우 이러한 질문은 대부분 자명합니다. 티켓을 검토할 때 개별 작업을 추적하기 쉽기 때문에 각 개발자가 무엇을 하는지 알 수 있습니다. 하는 사람이 많지 않기 때문에 모두가 모두가 무엇을 하고 있는지 압니다. 일하다.

원격 팀이 클수록 더 많은 부분이 움직이게 됩니다. 작업을 복제하거나 호환되지 않는 변경을 하여 아무도 다른 사람의 가상 발가락을 밟지 않도록 하고 싶습니다.

Toptal의 주당 지불 구조를 고려할 때 주당 2회의 회의는 고객이 주당 요금에서 속임을 느끼기 전에 프로젝트에 대한 우려를 표명할 수 있는 충분한 시간을 제공합니다. 일주일에 한 번만 회의를 갖는다는 것은 클라이언트가 작업 품질에 대해 만족하지 못하고 개발자가 결과물을 조정할 시간이 없다는 것을 의미할 수 있습니다.

고급 원격 팀에는 집에서 일하는 동안 실제 회의를 예약하지 않고도 모든 이해 관계자를 동일한 페이지에 유지하는 다른 방법이 있을 수 있습니다. 나는 여전히 누군가와 전화/스카이프/행아웃을 하고 그런 식으로 회의를 하는 것을 좋아합니다.

소규모 팀의 경우 일주일에 2번의 스탠드업 회의가 매우 효과적입니다. 코스 수정은 신속하게 이루어지지만 개발자는 여전히 각 회의에서 보고할 상당한 내용이 있습니다.

원격으로 다음 릴리스 제공

프로젝트 규모에 따라 소규모(1-2명의 개발자) 프로젝트의 경우 매주 클라이언트에게 전달되는 결과물을 좋아하고 대규모(3명 이상의 개발자) 프로젝트의 경우 격주로 결과물을 고객에게 보내는 것을 좋아합니다. 이 리듬은 개발자가 클라이언트가 볼 수 있는 인터페이스(또는 향상된 사용자 경험)를 포함하여 상당한 양의 작업을 완료할 수 있는 충분한 시간을 제공합니다.

비기술적 고객의 경우 진행 상황을 측정할 수 있는 유일한 지표는 화면에서 볼 수 있는 것입니다.

개발자는 특히 비기술적 클라이언트의 경우 사용자 인터페이스로 시각화할 수 있는 진행 상황이 클라이언트에게 중요한 유일한 경우라는 사실을 기억하는 것이 중요합니다. 비기술적인 고객은 이번 주에 500라인의 코드를 푸시했거나 일부 웹 서비스와 상호 작용하는 데 어려움을 겪었는지 신경 쓰지 않습니다. 진행 상황을 측정할 수 있는 유일한 지표는 화면에서 볼 수 있는 것 입니다. 백엔드에서 좋은 작업을 하는 것이 중요하지 않다는 것이 아니라 클라이언트의 눈에 이 모든 좋은 작업을 유형화해야 한다는 의미입니다.

이 이미지는 특히 원격 작업 상황에서 결과물의 중요성을 보여줍니다.

트위터

이것이 내가 매주 또는 격주로 제공되는 결과물을 좋아하는 이유입니다. 그보다 짧은 것은 종종 개발자를 곤란하게 만듭니다. 아마도 이틀 동안 백엔드 작업을 하다가 막혀 인터페이스를 마칠 시간이 없어 클라이언트에게 보여줄 것이 없을 것입니다.

소프트웨어 프로젝트 유형에 따라 이러한 클라이언트 릴리스 중 일부가 일반에 공개되지는 않습니다. 예를 들어 Rails 프로젝트에서 작업 중인 경우 승인된 변경 사항을 즉시 배포할 수 있습니다. 반면에 모바일 앱에서는 릴리스를 "1.3a10"이라고 부를 수 있지만 현재 릴리스는 나중에 배포될 소프트웨어의 새로운 1.3 버전의 더 큰 기능 세트의 일부일 뿐입니다.

여기에서 원격 버그 추적기 모범 사례가 적용됩니다. 버그 추적을 통해 클라이언트는 다음을 알고 있습니다.

  1. 이 결과물에 대한 팀의 접시에 있는 내용
  2. 완료되었다면
  3. 작업이 클라이언트에 의해 승인된 경우.

클라이언트는 이 릴리스에서 무엇을 기대해야 하는지 알고 있으며 개발자는 앞으로 어떤 작업이 수행될지 알고 있습니다.

원격 팀이 지속적인 배포 및/또는 Kanban을 사용할 수 있을 만큼 충분히 성숙했다면 괜찮습니다. 그러나 이들은 모두 강력한 개발자 기반 문화를 가진 조직에 더 적합한 매우 고급 기술입니다. 사용자 정의 소프트웨어 개발이 필요하지만 비용이 많이 드는 대부분의 조직은 이러한 기술 중 하나에 대해 준비가 되어 있지 않을 수 있습니다. 왜 그래? 내가 본 두 가지는 클라이언트가 개발자가 검토하기를 원하는 변경 사항의 수를 따라가지 못 하거나 우선 순위가 너무 빨리 변경되어 개발이 한 가지 작업을 완료 할 수 없다는 것입니다.

권장 사항

모범 사례를 구축할 팀에 우연히 들어가게 된다면 원격 작업을 관리하기 위한 몇 가지 도구를 아래에 나열했습니다. 이것들은 단지 나의 권장 사항임을 명심하십시오. 확실히, 이 가이드가 모든 사람을 위한 것은 아닙니다. 이러한 도구가 마음에 들지 않으면 필요에 더 잘 맞는 도구가 있을 수 있습니다.

  • Planscope.io , 주간 모드. 이것은 시간 추적기 + 버그 추적기 + 프로젝트 추정 도구로, 고객에게 프로젝트 작업 시 매일 이메일을 보내고 진행 상황 예산 면에서 상황이 어떻게 진행되고 있는지 확인할 수 있습니다. 이것은 1-4명의 개발자/월 규모의 프로젝트에 적합합니다.
  • App Trajectory 는 프로젝트를 추정하고 1-2주 단위(반복)로 나누는 데 중점을 둔 소규모 팀을 위한 버그 추적기입니다. App Trajectory는 반복에서 얼마나 많은 작업을 완료하고 있는지, 알려진 모든 작업이 완료될 때까지 얼마나 많은 반복을 수행하는지 알려줄 수 있습니다. 이것은 2-12명의 개발자/월 규모의 프로젝트에 적합합니다.
  • Pivotal Tracker 는 애자일 방법론에 중점을 둔 고객을 위한 버그 추적 도구입니다. 공식 Agile 반복을 수행하거나 프로젝트 크기를 개발자/년 단위로 측정하는 경우에 유용합니다.
  • 채팅용 FlowDock . Flowdock은 일반 IRC 또는 Skype 채팅에 비해 몇 가지 이점을 제공합니다. 인기 있는 서비스와 통합할 뿐만 아니라 나중에 빠르게 참조할 수 있도록 대화에 태그를 지정할 수도 있습니다. FlowDock은 또한 일반 채팅과 분리된 상태 활동(코드 체크인 등) 목록을 유지합니다. (즉, 웹 인터페이스에서 자동화된 상태 업데이트는 왼쪽에 있고 채팅은 오른쪽에 있습니다.)
  • 다시 말하지만, Campfire 는 채팅에도 좋습니다.

결론

원격으로 시작하거나 재택근무를 시작하는 것은 귀하와 고객 모두에게 상당한 조정이 될 수 있습니다. 나는 그것이 매우 옳았고, 매우 틀렸습니다. 그러나 제대로 진행되면 고객이나 고용주가 "인재 위기" 문제를 해결하고 주요 기술 센터 또는 "스타트업" 허브 외부에 거주하는 개발자에게 더 넓은 범위의 기회를 창출할 수 있는 훌륭한 방법이 될 수 있습니다. 적절한 모범 사례를 사용하여 원격으로 협력하는 개발자로부터 얻을 수 있는 효율성의 세계가 있습니다.