팀 채팅이 별도의 앱에 있어서는 안 됩니다

태스크는 한 도구에 있습니다. 파일은 다른 것에. 대화는 세 번째에. 그런데도 팀은 어떻게든 정렬을 유지해야 합니다. 이것이 대부분의 소규모 팀, 프리랜서, 학생 그룹의 기본 설정입니다. Trello나 Asana에서 작업을 추적하고, Google Drive나 Dropbox를 통해 파일을 공유하며, Slack이나 Discord로 대화합니다. 최소 세 개의 도구, 각각 자체 알림 시스템, 자체 검색, 자체 버전의 진실. 결과적으로 프로젝트 맥락이 플랫폼 전반에 걸쳐 파편화됩니다. Slack에서 결정이 이루어집니다. 그 결정을 반영하는 태스크는 프로젝트 보드에 있습니다. 태스크와 관련된 파일은 Drive에 있습니다. 전체 그림을 이해하기 위해 누군가 세 가지 다른 장소를 확인해야 합니다. 그리고 Slack 메시지가 보내질 때 온라인이 아니었다면 전혀 보지 못할 수도 있습니다. 이것은 단순한 불편함이 아닙니다. 오해, 중복 작업, 놓친 일들의 실제 원인입니다. 사람들이 태스크를 설명하는 대화를 찾지 못하면 추측하거나 누군가를 방해하여 질문합니다. 둘 다 효율적이지 않습니다.

Slack과 Discord는 훌륭한 커뮤니케이션 도구입니다. 하지만 프로젝트 수준의 커뮤니케이션이 아닌 조직 전체의 커뮤니케이션을 위해 설계됐습니다. 그 차이가 중요합니다. Slack에서 주제, 팀, 프로젝트를 위한 채널을 만듭니다. 시간이 지남에 따라 채널이 늘어납니다. 대화가 채널 사이를 떠돌아다닙니다. 중요한 결정들이 밈, 무작위 링크, 주제에서 벗어난 스레드 아래 묻힙니다. 검색은 올바른 키워드와 올바른 채널을 기억하는 경우에만 괜찮습니다. Discord도 같은 구조적 문제를 가집니다. 서버가 채널로 채워지고, 프로젝트별 대화가 소음 속에 사라집니다. 게임 커뮤니티와 개발자 그룹에게는 괜찮습니다. 실제 프로젝트 작업을 관리하기 위해서는 빠르게 쌓이는 마찰을 도입합니다. 핵심 문제는 이 도구들이 프로젝트가 아닌 채널로 대화를 정리한다는 것입니다. 프로젝트에는 태스크, 파일, 타임라인, 마일스톤이 있습니다. 그에 대한 채팅은 완전히 다른 구조로 정리된 별도의 앱이 아닌 그것들 옆에 있어야 합니다.

IndieDevBoard에는 모든 프로젝트 안에 팀 채팅이 포함됩니다. 프로젝트를 열고 채팅으로 들어가면 대화가 칸반 보드, 타임라인, 노트북, 파일 바로 옆에 있습니다. 즉각적인 이점은 메시지가 관련 작업과 연결된 상태로 유지된다는 것입니다. 누군가 태스크에 대해 물으면 태스크가 한 클릭 거리에 있습니다. 누군가 결정을 공유하면 관련 마일스톤과 메모가 사는 같은 워크스페이스에 있습니다. 맥락이 다른 앱으로 증발하지 않습니다. 이것은 온보딩 문제도 해결합니다. 새 팀원이 프로젝트에 합류하면 맥락 안에서 전체 채팅 기록에 접근할 수 있습니다. 실제 작업과 함께 프로젝트를 형성한 대화들을 볼 수 있습니다. Slack에서는 여러 채널을 검색해야 하고 관련 토론의 절반을 여전히 놓칩니다. 또 다른 과소 평가된 이점은 프로젝트 아카이빙입니다. 프로젝트가 끝나면 채팅도 함께 갑니다. 아무도 아카이브를 기억하지 못하는 좀비 Slack 채널이 생기지 않습니다. 프로젝트가 완료되고 대화가 보존되며, 메인 커뮤니케이션 도구에 아무것도 어지럽히지 않습니다.

소규모 팀들은 종종 동기적 커뮤니케이션을 기본으로 합니다. 누군가 질문이 있으면 Slack에 게시하고 지금 답을 기대합니다. 모두가 동시에 온라인일 때는 작동하지만 시간대 차이, 유연한 일정, 또는 깊은 집중 시간이 필요한 팀원들과 함께라면 빠르게 무너집니다. 일별 스탠드업과 끊임없는 Slack 알림의 더러운 비밀은 그것들이 깊은 작업을 방해한다는 것입니다. 모든 알림은 컨텍스트 전환입니다. 연구에 따르면 방해 후 완전히 집중력을 회복하는 데 약 23분이 걸립니다. 팀이 하루에 여섯 번 서로에게 핑을 보내면 사람당 두 시간 이상의 생산적인 시간을 잃는 것입니다. 비동기 커뮤니케이션은 다르게 작동합니다. 업데이트나 질문을 게시하고 사람들이 준비됐을 때 답합니다. 대화는 여전히 거기 있습니다. 아무것도 잃어버리지 않습니다. 하지만 아무도 실시간으로 참여하기 위해 하던 것을 내려놓을 필요가 없습니다. 소규모 팀을 위한 최고의 설정은 기본적으로 비동기, 필요할 때 동기입니다. 즉각적인 답이 필요하지 않은 업데이트, 질문, 결정에는 프로젝트 채팅을 사용하세요. 실제로 실시간 토론이 필요할 때 통화로 넘어가세요. 이 균형이 사람들에게 정보를 제공하면서 집중 작업 능력을 파괴하지 않습니다. 프로젝트 워크스페이스 안에 채팅이 있으면 자연스럽게 이것을 지원합니다. 메시지는 영구적이고 프로젝트에 연결됩니다. 사람들은 프로젝트를 확인할 때 체크인합니다. 맥락이 보존되어 그들이 확인할 때 언제든 볼 수 있기 때문에 즉시 답해야 한다는 압박이 없습니다.

너무 많은 도구를 갖는 것에는 실제 비용이 있습니다. 워크플로우의 추가 앱마다 로그인, 알림 세트, 확인해야 할 것, 정보가 숨어 있을 수 있는 곳이 하나 더 생깁니다. "도구 피로"라는 용어가 많이 쓰이지만 실제 문제를 설명합니다. 세 명의 팀이 태스크, 채팅, 파일, 문서, 달력에 별도의 도구를 사용하면 다섯 개의 다른 인터페이스를 관리하는 것입니다. 그 오버헤드는 전담 IT 직원과 온보딩 프로그램이 있는 대규모 조직보다 소규모 팀에게 비례적으로 더 무겁습니다. 통합은 모든 것을 완벽하게 하는 하나의 도구를 찾는 것이 아닙니다. 팀이 확인해야 하는 장소의 수를 줄이는 것입니다. 태스크, 채팅, 파일, 메모가 모두 같은 프로젝트 워크스페이스에 있으면 관심을 경쟁하는 네 개의 탭과 네 개의 알림 세트가 줄어드는 것입니다. 이는 이미 수업, 클라이언트 작업, 개인 프로젝트를 저글링하는 학생 팀과 프리랜서에게 특히 맞습니다. 그들에게 필요한 마지막 것은 관리할 또 다른 앱입니다. 프로젝트 관리와 함께 채팅이 포함된 워크스페이스는 이미 복잡한 하루에 컨텍스트 전환을 하나 줄여줍니다.

프로젝트 수준의 채팅은 모든 팀 커뮤니케이션을 대체하는 것이 아닙니다. 조직에 수백 명이 있다면 여전히 회사 전체 커뮤니케이션 플랫폼이 필요합니다. Slack은 공지, 소셜 채널, 팀 간 토론, 그리고 원격 팀을 사람답게 유지하는 무작위 휴게실 대화에 훌륭합니다. 주장은 Slack이 나쁘다는 것이 아닙니다. Slack은 작업과 연결되어 있어야 하는 프로젝트별 토론을 위한 올바른 장소가 아니라는 것입니다. 회사를 위해 Slack을 사용하세요. 프로젝트를 위해 프로젝트 채팅을 사용하세요. 마찬가지로 오픈 소스 커뮤니티나 게이밍 그룹의 일부라면 Discord는 다른 목적을 제공합니다. 프로젝트 관리 도구가 아닌 커뮤니티 도구입니다. 둘 다 공존할 수 있습니다. 목표는 대화를 그것이 속한 곳에 두는 것입니다. 회사 전체 것은 회사 전체 도구로 갑니다. 프로젝트별 대화는 프로젝트로 갑니다. 두 가지를 섞는 것을 멈추면 둘 다 더 깔끔해집니다.

프로젝트 밖에 사는 프로젝트에 대한 모든 메시지는 잃어버린 맥락의 한 조각입니다. 나중에 검색을 통해 찾을 수 있을 수도 있습니다. 못 찾을 수도 있습니다. 어느 쪽이든 누군가 추적하는 데 시간과 에너지를 써야 합니다. 가장 단순한 해결책은 이미 작업이 있는 곳에 대화를 두는 것입니다. 채팅이 태스크, 타임라인, 문서와 함께 프로젝트 안에 있으면 아무것도 잃어버리지 않습니다. 정보가 바로 거기 있기 때문에 사람들이 정렬을 유지합니다. 팀이 작다면 이것은 더욱 중요합니다. 모두에게 정보를 제공하는 것이 전임 직업인 프로젝트 매니저가 없습니다. 여러분이 프로젝트 매니저이자 개발자이자 디자이너입니다. 조율의 오버헤드를 줄이는 것은 무엇이든 실제 작업을 위한 시간을 돌려줍니다. 그것이 전부입니다.