채팅은 커뮤니케이션에 유용하고, 이슈는 지속되는 업무에 유용합니다. 빠져 있던 조각은 이 둘을 잇는 연결고리인데, Seeze가 만드는 것이 바로 그 연결입니다. (애초에 대화가 왜 맥락을 잃는지 궁금하다면 문제 분석 읽어보기 →)
Seeze는 단순한 관계를 도입합니다:
이슈는 어딘가에 접수하는 티켓이 아닙니다. 하나의 업무가 사는 자리이고, 그 업무의 대화와 결정과 파일이 모두 그 안에 있습니다. 모든 태스크는 이슈에 속하지만, 모든 이슈에 태스크가 필요한 것은 아닙니다.
앵커는 이미 두 번 보셨습니다. 메일이 이슈가 되면 그 메일이 맨 위에 인용된 채로 남습니다. 채널 메시지가 이슈가 되면 그 메시지가 맨 위에 인용된 채로 남습니다. 체인을 만드는 것은 세 번째 경우입니다. 이슈 안의 메시지가 또 하나의 이슈가 되면서, 같은 방식으로 출처를 앵커에 담아 갑니다.
새로 배울 것은 없습니다. 같은 동작을 한 겹 더 들어가서 할 뿐입니다.
호텔이 예약 확정 메일을 보냅니다. 그 메일이 예약 건 이슈가 됩니다. 그 안의 한 줄 — 공항에서 워터택시 픽업을 잡아야 한다는 — 이 그 자체로 하나의 일이라, 별도 이슈가 되고 예약 이슈를 앵커로 답니다. 두 이슈는 각자 하나의 일에 집중하고, 그 사이의 순서는 그대로 남습니다.
앵커는 꼬리표가 아닙니다. 채팅 앵커를 누르면 그 메시지가 있던 방으로 갑니다. 메일 앵커를 누르면 내 메일 클라이언트의 그 메일로 갑니다. 어느 이슈에서든 앵커를 거꾸로 따라가면 모든 것을 시작한 요청에 닿습니다. 누군가의 요약이 아니라 고객이 보낸 원본에요.
이슈체인은 이게 전부입니다. 이전 논의가 어디서 이루어졌는지 기억할 필요도, 흩어진 메시지에서 이야기를 재구성할 필요도 없습니다.
Seeze는 채팅과 업무 사이에 빠져 있던 연결을 워크플로우 안으로 가져옵니다. 중요한 대화를 구조화된 이슈로 바꾸고, 관련 히스토리를 함께 유지하며, 원래 대화가 지나간 뒤에도 프로젝트 맥락을 계속 이용할 수 있게 합니다. 그 결과 검색하는 시간, 재구성하는 시간, 정확히 그 순간에 접속해 있어야 한다는 부담이 모두 줄어듭니다. 팀은 계속 대화하면서도 업무를 놓치지 않을 수 있습니다.