이거 하나 없애니까 프로젝트 관리가 쉬워졌다
노션 프로젝트 DB 만들었는데 아무도 안 쓰는 이유
프로젝트 관리가 필요하다는 건 알고 있어요. 제대로 배운 적은 없지만 대충 굴러가게는 해뒀죠. 노션으로 DB까지 만들어놨는데, 막상 열어보면 항목이 너무 많고 복잡해서 손이 안 가요. 그러다 결국 "왜 프로젝트 관리 안 해?"라며 직원들을 닦달하게 됩니다.
이건 의지의 문제가 아니에요. 구조가 처음부터 너무 무겁게 짜여져 있기 때문이죠.
방치하면 '잔소리'로 돌아가는 회사가 돼요
처음엔 "그냥 바쁘니까" 넘어가요. 하지만 프로젝트는 바쁠수록 더 자주 구멍이 나요. 일정은 계속 틀어지는데, 어디서 틀어졌는지 기록할 곳도 없어서 일단 카톡 보내두고 머리로 기억합니다.
확인할 게 늘어나고, 결국 "내가 다 챙겨야겠다" 모드로 돌아가요. 직원 입장에서는 "기준이 자꾸 바뀌는 느낌"이라 더 방어적으로 움직이게 되죠. 결국 프로젝트 관리 시스템이 아니라, 기억력과 잔소리로 유지되는 회사가 됩니다.
프로젝트 관리의 '기준'을 잘못 잡았기 때문이에요
프로젝트 관리를 노션으로 만들 때 이렇게 생각해요. "프로젝트니까 시작일도 필요하고, 마감일도 필요하고, 중간 점검도 필요하고…" "일단 한 번 만드는 김에 제대로 만들어두자."
그런데 작은 회사에선 이 방식이 거의 100% 무너져요. 작은 회사의 프로젝트는 계획대로 진행되는 게 아니라, 매일 현실에 맞춰 바뀌기 때문이죠.
시작일은 있어야 관리되는 거 아닌가요?
냉정하게 말하자면, 작은 회사 프로젝트에서 시작일은 사치예요. 업무가 바빠지면 제일 먼저 시작일이 틀어져요. 틀어졌을 때의 책임 소재도 애매하고요.
반대로 마감일은 어떨까요? 틀어지면 결과가 바로 터져요. 납기, 매출, 신뢰, 고객 컴플레인. 즉시 문제가 생기죠.
시작일을 넣으면 날짜가 1개의 속성이 아니라 기다란 구간(시작~마감)이 되면서, 업데이트해야 할 칸이 늘고, 누락이 늘고, 관리 부담이 심해져요.
결국 항목은 많은데 아무도 업데이트 안 하는 DB가 돼요. 열기도 싫고, 보기도 싫어서 카톡으로 다시 돌아가죠.
작은 팀 프로젝트 관리의 진짜 기준
프로젝트 관리의 기준은 언제 시작하는지가 아니에요. 누가, 언제까지 끝내야 하는지예요.
담당자가 정해지면 책임이 생겨요. 마감일이 정해지면 우선순위가 생기죠. 시스템이 대신 한눈에 보여줍니다.
항목이 많은 시스템이 좋은 게 아니에요. 최소한의 속성으로도 잘 돌아가는 시스템이 좋은 시스템이죠.
정리
작은 회사 프로젝트 관리는 많이 적는 것이 아니라 끝내는 거예요.
핵심은 딱 하나예요. 마감일 내에 끝내는 게 중요하다는 것.
시작일을 줄이는 건 대충 하자는 얘기가 아니에요. 관리 가능한 최소 단위로 줄여서, 실제로 쓰이게 만들자는 거죠.