작은 팀 프로젝트 관리, 우리가 놓치고 있는 한 가지
작성자 공여사들
작은 팀 프로젝트 관리, 우리가 놓치고 있는 한 가지
프로젝트 관리 노션까지 만들었는데, 왜 현장은 더 바빠질까요?
프로젝트 관리의 필요성은 다들 압니다. 그래서 시간 들여 노션으로 프로젝트 관리 DB도 만들어두죠. 그런데 막상 팀에서 쓰려 하면, 속성은 잔뜩이고 구조는 복잡해서 손이 잘 안 갑니다. 결국 프로젝트는 메신저와 대화방, 머릿속 기억 위주로 굴러가고요. 그러다 일이 틀어지면, 누군가는 “왜 프로젝트 관리가 제대로 안 될까..”하며 다시 확인해야 합니다.
이건 개인의 성실함 문제가 아니라, 처음부터 구조를 너무 무겁게 잡아둔 결과에 가깝습니다.
많은 팀이 노션 프로젝트 예시를 거의 그대로 따라 만들었다가, 실제 운영 단계에서 오히려 “확인하고 정리하는 일”만 늘어나는 경험을 합니다.
이대로 두면, 일은 시스템이 아니라 ‘잔소리’로 관리돼요
처음에는 “요즘 다들 바쁘니까” 하면서 넘어갑니다. 그런데 프로젝트는 바쁠수록 더 자주 틀어집니다. 일정은 계속 미뤄지는데, 어디서부터 꼬였는지 적어둔 곳이 없으니 일단 카톡이나 전화로 “나중에 정리하자”고 넘기게 됩니다. 메신저·통화·구두 전달이 섞이다 보니, 빠진 업무는 시간이 꽤 흐른 뒤에야 드러나고, 그때는 이미 뒷수습하느라 하루가 다 날아갑니다.
결국 누군가는 확인할 게 점점 늘어나고, “이거 내가 끝까지 챙겨야겠다” 모드로 돌아가게 됩니다. 현장에서 일하는 입장에서는 기준이 계속 바뀌는 느낌이라, 더 방어적으로 움직이게 되고요. 이렇게 되면 프로젝트 관리 시스템이 아니라 어떤 사람의 기억력과 잔소리에 의존하는 회사가 됩니다. 일이 가장 많은 사람이, 동시에 가장 많이 확인해야 하는 구조. 작은 팀에게는 특히 치명적인 구조입니다.
이런 상황이라면,
문제는 ‘개인 역량’이 아니라 ‘일이 흘러가는 구조’입니다.
프로젝트 관리의 기준, 혹시 여기서부터 어긋난 건 아닐까요?
많은 팀이 노션으로 프로젝트 관리 세팅을 할 때, 이렇게 생각합니다. “프로젝트니까 시작일도 있어야 하고, 마감일도 있어야 하고, 중간 점검도 필요하고…” “시간 들여 만드는 김에 제대로 다 넣어두자.” 그리고 아래처럼 촘촘한 구조를 한 번에 만들어버리죠.
그런데 작은 팀의 프로젝트는 이 구조에서 거의 100% 무너집니다. 이유는 단순합니다. 작은 팀의 프로젝트는 계획대로만 움직이지 않고, 매일 현실에 맞춰 바뀌기 때문이에요. 즉, 작은 조직의 프로젝트 관리는 ‘완벽한 계획표’를 맞추는 게 아니라, 일정이 자꾸 바뀌어도 계속 굴러가는 구조가 되어야 합니다.
노션 프로젝트 템플릿을 그대로 가져다 쓰면, 작은 조직에는 필요하지 않은 관리 항목까지 같이 떠안게 되는 경우가 많습니다.
“그래도 시작일은 있어야 관리되지 않나요?”
현장에서 느끼는 기준으로 이야기해볼게요. 작은 팀의 프로젝트에서 시작일은 거의 ‘사치’에 가깝습니다. 바빠지는 순간 가장 먼저 틀어지는 값이 시작일이기 때문입니다. 시작일이 밀려도, 그 책임이 누구에게 있는지 애매하기도 하고요.
반대로 마감일은 어떨까요? 마감일이 틀어지는 순간 바로 티가 납니다. 납기, 매출, 신뢰, 고객 컴플레인까지 한 번에 영향을 줍니다. “언제 시작했는지”보다 “언제까지 끝내야 하는지”가 훨씬 더 현실적인 기준이 되는 이유입니다.
여기에 시작일까지 넣기 시작하면 문제가 커집니다. 날짜가 단순히 “하나의 값”이 아니라 “시작~마감까지의 구간”이 되면서, 계속 업데이트해야 하는 칸이 늘어나고 → 누락이 늘어나고 → 관리 부담이 확 치솟습니다.
결과적으로 이렇게 됩니다. 프로젝트 관리 DB는 있는데, “속성은 많은데, 아무도 업데이트하지 않는 DB”. 쓰는 사람도 열기 싫고, 보는 사람도 보기 싫어서, 결국 다시 카톡과 구두 지시로 되돌아가 버리는 거죠.
엑셀로 간트 차트 템플릿을 다운로드받아 시작했다가, 날짜 수정만 반복하다가 포기하는 경우도 같은 이유에서 생깁니다.
작은 팀에서 프로젝트 관리를 볼 때, 기준은 무엇이어야 할까요?
작은 팀에서 우리가 중요하게 봐야 하는 기준은 “언제 시작했는가”가 아닙니다. 누가, 언제까지 끝내야 하는가입니다. 이 두 가지만 또렷하게 잡혀 있어도, 현장에서 프로젝트를 굴리는 일이 훨씬 단순해집니다.
담당자가 정해지면 책임이 생기고, 마감일이 정해지면 우선순위가 생깁니다. 이 두 가지가 프로젝트 관리 화면에서 한눈에 보이면, 굳이 “그거 언제 끝나요?”를 매번 물어볼 필요가 없습니다. 시스템이 대신 보여주기 때문이죠.
관리 항목이 많다고 해서 좋은 시스템이 되는 건 아닙니다. 현장에서 최소한의 속성만으로도 꾸준히 돌아가는 시스템이 좋은 시스템입니다.
화려한 노션 프로젝트 예시보다, 단순한 구조가 작은 팀에서는 실제로 훨씬 오래 살아남습니다.
담당자 + 마감일만 잡으면, 현장은 어떻게 달라질까요?
BEFORE: 시작일까지 모두 넣는 프로젝트 관리
시작일이 계속 밀려서, 그때마다 날짜를 일일이 다시 맞춰야 합니다.
바빠질수록 업데이트가 누락되기 시작합니다.
메신저로 다시 확인이 오가고, 확인받는 쪽에서는 잔소리처럼 느껴져 점점 피하게 됩니다.
AFTER: 담당자 + 마감일만 두는 프로젝트 관리
입력해야 할 항목이 줄어들어, 작성률 자체가 올라갑니다.
마감일은 빼먹기 어려워서, 중요한 정보가 덜 누락됩니다.
“누가 지금 무엇을 맡고 있는지”를 몇 분 안에 파악할 수 있습니다.
실제 고객사 피드백에서도 같은 패턴을 확인할 수 있었습니다.
"대형 프로젝트도 두렵지 않게 되었습니다. 프로젝트 관리 탭에서 상위/하위 프로젝트를 생성해서 하나씩 따라가다 보면 어느새 목표 지점에 도달해 있더라고요. 예전에는 한 사람의 PM이 기억과 노트 필기를 가지고 일종의 생체 기록 장치 역할을 했는데, 이제는 더 이상 그럴 필요가 없어졌습니다."
ㅡ 라이프스타일 브랜드 고객사 후기 중에서
결국, 작은 회사 프로젝트 관리의 초점은 “얼마나 많이 적었냐”가 아닙니다
작은 팀에서 프로젝트 관리를 할 때, 핵심은 딱 하나로 정리할 수 있습니다.
“마감일 안에 끝내는 게 중요하다.”
시작일을 줄이자는 말은 일을 대충 하자는 얘기가 아닙니다. 현장에서 유지 가능한 최소 단위로 구조를 줄여서, 실제로 쓰이게 만들자는 얘기입니다. 담당자와 마감일을 중심으로 재구성한 이 구조(작은 팀 프로젝트 관리 기준)가 실제로 어떻게 구현되는지 보고 싶다면, 아래 웨비나에서 화면 그대로 확인해보실 수 있습니다.
현장에서 프로젝트를 굴리는 사람들이 함께 많이 본 콘텐츠
프로젝트 관리의 필요성을 느끼고 있다면, 다음으로는 메신저 이야기를 짚어볼 차례입니다. 작은 팀일수록 ‘메신저’와 ‘업무 시스템’이 어떻게 달라야 하는지, 5분 안에 정리해 드립니다.
항상 프로젝트 마감 직전에 벼락치기하듯 일을 처리하고 있다면, 이 사례를 한 번 읽어보세요. ‘눈앞에 쌓인 일’만 처리하던 팀이, ‘3개월 전부터 미리 준비하는 구조’로 바뀐 과정을 담았습니다.
© 공여사들. ‘일의 구조’를 만듭니다.