협업 툴이 아니라,
일하는 방식부터 다시 설계했습니다.

입사 후 업무 방식을 살펴보니,
생각보다 문제가 심각했습니다.

20년 전에 사용하던 방식을 아직도 유지하고 있었습니다.

먼저 팀별로 어떻게 소통하고 일하는지 들어봤습니다.

툴을 정해 놓고 설득하지 않고, 팀별 인터뷰와 업무 관찰을 통해 필요한 구조부터 찾았습니다.

요청은 있었지만
소통과 기록은 없었습니다.

각 팀은 서로 다른 이유로
같은 구조에 어려움을 느끼고 있었습니다.

PO·UX·개발 모두 역할보다 산출물과 전달 순서에 맞춰 일하고 있었습니다.

그래서 전달 순서를 바꾸고,
PO·UX·개발이 처음부터 같이 시작하도록 했습니다.

PO는 문제를 정의하고, UX는 빠르게 시각화하며, 개발은 초반부터 기술 가능성과 대안을 함께 검토했습니다.

그래서 R&R을 산출물이 아니라
판단의 책임으로 다시 정의했습니다.

무엇을 그리느냐보다 각 판단을 누가 책임하고 어디서 함께 결정할지 기준을 정했습니다.

필요한 툴을 먼저 정하지 않고,
기능과 프로세스부터 구체화했습니다.

필요한 소통 방식은 확인했습니다. 이제 실제 업무에 필요한 기능과 프로세스를 구체화했습니다.

툴을 늘린 것이 아니라,
업무가 남는 하나의 운영 구조로 연결했습니다.

공식 소통은 Teams에 모으고, 상태·반복 요청·일정·공간 예약을 역할에 맞는 도구로 연결해 다시 묻는 일을 줄였습니다.

배포만으로는 다시 예전 방식으로 돌아가기 쉬웠습니다.
그래서 가이드와 운영 규칙까지 함께 만들었습니다.

도구보다 중요한 것은 어떤 상황에서 어디에 기록하고, 무엇을 공유하며, 어떻게 결정할지에 대한 공통 규칙이었습니다.

기존 방식과 개선 방식을 같은 조건으로 놓고,
소통·검색·조율에 쓰는 시간을 보수적으로 계산했습니다.

전원이 한 번에 바뀐다고 가정하지 않고,
정착률에 따라 절감 효과를 나눠봤습니다.

핵심은 툴 사용률이 아니라 공식 Channel·Ticket·상태 공유가 실제 업무에 정착되는 비율입니다.

아직 숫자로 증명할 단계는 아니지만,
초기 사용자의 반응은 같은 방향을 가리키고 있습니다.

현재는 구두 피드백과 사용 정착을 확인하는 단계이며 정량 KPI는 다음 단계에서 측정합니다.

다음 단계에서는 좋아졌다는 느낌이 아니라,
실제 운영 데이터로 검증하려고 합니다.