David.Cheon
UIpac
David.Cheon
  • UIpac (647) N
    • Planning · PM (227)
      • 프로젝트 · PM (58)
      • UX · Product (49)
      • 서비스 기획 (40)
      • Business · Growth (60)
      • 일하는 방법 (20)
    • AI (64) N
      • AI Product (13)
      • AI 활용 · 자동화 (7)
      • AI Technology (11)
      • AI Trend (33) N
    • Projects · Tech (2)
      • Toy Project (1)
      • Web · IT (1)
      • Tools (0)
    • Archive (352) N
      • Weekly Curation (251)
      • Performing Arts (17) N
      • Collection (6)
      • Books (0)
      • Life (78) N

인기 글

Tags

  • 애플리케이션
  • 인공지능
  • 사물인터넷
  • UX
  • 벤치마킹
  • 기획참고
  • 큐레이션
  • 2014
  • 가트너
  • trend
  • 트랜드
  • 2015
  • 기획
  • Gartner
  • Curation
  • Mreport
  • 디자인
  • 분석
  • 세계 게임시장 규모
  • daumkakao
  • 웨어러블
  • 모바일
  • UI
  • 트렌드
  • 디자인참고
  • 유니티
  • 다음카카오
  • 동향
  • 사이트
  • 반응형웹

최근 댓글

방명록

전체 방문자
오늘
어제
hELLO · Designed By 정상우.
David.Cheon

UIpac

Archive/Life

큰 계약 절차를 프로젝트 일정처럼 정리해 보기

2018. 11. 20. 20:39

 

아파트 계약처럼 단계가 긴 일을 앞두면 머릿속이 금방 복잡해집니다.
회사에서는 일정표와 체크리스트로 일을 관리하면서, 정작 일상의 큰 일에는 그 방식을 잘 쓰지 않았던 것 같아요.
그래서 큰 계약 절차를 프로젝트처럼 다루는 방법을 한번 정리해 보려고 합니다.
특정 경험담이 아니라 일반적인 틀이고, 아래 예시는 모두 가정입니다.
법률과 세금에 관한 내용은 단정하지 않고, 확인이 필요한 항목으로만 표시하겠습니다.

 

큰 계약은 한 번의 사건이 아니라 여러 단계가 이어진 과정이에요.
알아보기, 비교하기, 자금 계획 세우기, 계약 맺기, 잔금 치르기, 입주하기처럼 단계마다 해야 할 일이 달라집니다.
문제는 이 단계들이 몇 달에 걸쳐 흩어져 있다는 점이에요.
앞 단계에서 정한 것이 뒤 단계의 마감을 결정하는데, 그 연결이 머릿속에만 있으면 쉽게 놓칩니다.
게다가 서류는 여러 곳에서 받아야 하고, 발급일로부터 유효 기간이 있는 서류도 있다고 하더라고요.
이런 구조는 사실 프로젝트와 아주 비슷합니다.
목표 날짜가 있고, 선후 관계가 있고, 관여하는 사람이 여럿이고, 늦어지면 비용이 생기니까요.

 

프로젝트를 짤 때 저는 세부 작업보다 마일스톤을 먼저 정합니다.
큰 계약이라면 이정표를 대략 이렇게 잡아 볼 수 있을 것 같아요.

  • 조건을 정하는 날 (예산, 지역, 일정의 범위)
  • 계약을 맺는 날
  • 자금이 실제로 움직이는 날 (대출을 쓴다면 심사와 실행 시점 포함)
  • 잔금을 치르고 열쇠를 받는 날
  • 이사와 주소 변경, 각종 신고를 마치는 날

이 다섯 개 정도만 먼저 달력에 박아 두면, 나머지 작업은 그 사이를 채우는 일이 됩니다.
특히 잔금일처럼 움직이기 어려운 날짜를 기준일로 삼으면 거꾸로 계산하기가 쉬워져요.

 

잔금일을 D로 놓고, 아래처럼 상대 날짜로 적어 보는 방식입니다.
숫자는 어디까지나 가정이고, 실제 일정은 계약 조건과 상대방 사정에 따라 달라집니다.

  • D-90: 조건 정리, 자금 계획 초안, 필요한 서류 목록 만들기
  • D-60: 후보 비교, 현장 방문, 대출이 필요하다면 가능 여부 문의
  • D-45: 계약 진행, 계약서 사본 보관, 특약 사항 정리
  • D-30: 대출 서류 제출, 이사 일정 후보 정하기
  • D-14: 이사 업체 확정, 공과금과 관리비 정산 방식 확인
  • D-day: 잔금, 열쇠 인수, 현장 상태 사진으로 기록
  • D+14: 주소 변경과 각종 신고 마무리 확인

여기서 중요한 건 숫자보다 의존 관계예요.
대출 서류가 늦어지면 잔금일이 흔들리고, 잔금일이 흔들리면 이사 업체 예약도 다시 잡아야 합니다.
이 연결 고리를 표에 화살표로라도 적어 두면, 어디가 병목인지 한눈에 보입니다.

여유 기간, 즉 버퍼도 한 줄 넣어 두면 좋아요.
서류 발급이 하루 이틀 늦어지거나 상대방 일정이 밀리는 일은 흔하기 때문에, 중요한 날짜 앞에는 며칠의 여유를 일부러 비워 둡니다.
프로젝트에서도 일정이 빡빡할수록 작은 지연 하나가 전체를 흔들었거든요.
그리고 일정이 바뀌면 지우지 말고, 바뀐 날짜와 이유를 한 줄 남겨 두세요.
나중에 왜 이렇게 됐는지 돌아볼 때 큰 도움이 됩니다.

 

일정표와 별개로 서류 체크리스트를 하나 만들어 두면 마음이 훨씬 편해요.
항목마다 아래 네 가지를 적어 두면 좋습니다.

  • 무엇인지 (서류 이름)
  • 어디서 받는지
  • 언제까지 필요한지, 유효 기간이 있는지
  • 지금 상태 (준비 전, 신청함, 받음, 제출함)

돈도 같은 방식으로 관리할 수 있어요.
계약금, 중도금, 잔금처럼 큰 금액뿐 아니라 중개 비용이나 이사 비용, 각종 수수료까지 한 줄씩 적어 두는 겁니다.
빠져 있다가 막판에 튀어나오는 비용이 가장 곤란하니까, 모르는 항목은 모른다고 적고 물어볼 질문으로 남겨 두세요.

 

이런 정리는 어디까지나 관리 틀일 뿐, 법적으로 맞는 절차를 알려 주지는 않습니다.
계약금과 잔금의 비율, 신고 기한, 취득이나 보유에 따른 세금, 대출 한도 같은 내용은 상황과 시기에 따라 달라지는 것으로 알고 있어요.
그래서 저는 이런 항목에는 "확인 필요"라고 적고, 담당 전문가나 공식 안내에서 직접 확인한 뒤 일정에 반영합니다.
확인한 날짜와 확인한 곳도 메모해 두면, 나중에 기억이 흐려져도 근거를 찾을 수 있어요.
계약서는 읽다가 모르는 문구가 나오면 그 자리에서 표시해 두고, 서명 전에 질문 목록으로 정리하는 게 좋겠습니다.

프로젝트에서 위험 목록을 만들듯이, 이 일에도 "이게 틀어지면 곤란한 것"을 서너 가지 적어 두면 좋아요.
예를 들어 대출 심사가 예상보다 늦어지거나, 이사 날짜에 맞는 업체를 구하지 못하거나, 서류에 오류가 있어 다시 받아야 하는 경우를 가정해 볼 수 있습니다.
각각에 대해 미리 정해 둔 대응책이 있으면, 막상 일이 생겨도 당황하지 않고 다음 행동을 고를 수 있어요.

 

큰 계약을 프로젝트처럼 정리하는 것의 장점은 불안이 줄어든다는 점이었어요.
불안의 상당 부분은 무엇을 모르는지 모르는 데서 오는데, 마일스톤과 체크리스트는 모르는 것을 눈에 보이게 만들어 줍니다.
다만 모든 걸 표로 만들다 보면 일정 관리 자체가 일이 되어 버리는 점은 조심해야 할 것 같아요.
처음에는 마일스톤 다섯 개와 서류 목록 한 장 정도로 시작하고, 필요할 때만 늘리는 편이 좋겠습니다.
일이 끝나면 프로젝트 회고처럼 잘된 점과 아쉬운 점을 짧게 적어 두는 것도 추천해요.
다음에 비슷한 일을 할 때 가장 값진 자료가 되니까요.
남은 질문은 이런 틀이 사람마다 달라지는 사정, 예를 들어 가족과 함께 결정해야 하는 상황에서 어떻게 역할을 나누느냐입니다.
그 부분은 이 틀을 다시 정리할 때 보충해 적어 보겠습니다.

저작자표시 비영리 변경금지 (새창열림)

'Archive > Life' 카테고리의 다른 글

AWS 용어 정리  (0) 2019.05.03
2019년 읽은 PM/기획 관련 책 정리  (0) 2019.01.21
See you again & One call away - J fla  (0) 2017.10.27
Mastering the Game of Go without Human Knowledge  (1) 2017.10.19
CSS 네이밍 규칙  (3) 2017.08.14

티스토리툴바