견적이 승인되면 프로젝트 상태를 곧바로 진행 중으로 바꾸기 쉽습니다. 하지만 승인과 착수는 같은 이벤트가 아닙니다. 입력 자료와 일정, 의사결정 경로가 비어 있으면 팀은 일을 시작한 듯 보이지만 다음 단계에서 다시 멈춥니다.
착수 조건을 명시적으로 저장하기
고객 프로젝트의 첫 메일을 작은 상태 전이 기록으로 생각해 봤습니다.
scope: 이번 단계의 결과물과 제외 범위 first_delivery_at: 첫 초안 전달 예정일 feedback_due_at: 고객 검토 회신일 client_inputs: 필요한 자료와 형식, 제출일 approver: 의견을 취합할 최종 담당자 여기서 중요한 것은 필드를 많이 만드는 일이 아닙니다. 첫 산출물과 검토 회신 날짜를 분리하고, 승인 담당자가 미정인지 확정인지 표시하는 일입니다. 메일 제목에는 프로젝트명과 착수 안내를 넣어 나중에 찾기 쉽게 합니다.
빈칸은 기본값으로 채우지 않기
- 승인자가 없으면 임의로 가장 최근에 답장한 사람을 지정하지 않습니다.
- 자료가 없으면 받음과 사용 가능을 같은 상태로 보지 않습니다.
- 계약에 없는 일정 변경은 메일 한 통으로 확정하지 않고 다시 합의합니다.
예를 들어 “로고 원본은 아직 못 받았습니다. 현재 파일을 먼저 공유해 주시면 사용 가능 여부를 확인하겠습니다”라고 쓰면, 누락된 입력과 다음 행동이 동시에 보입니다.
메일 한 통의 종료 조건
고객이 답장할 때 필요한 질문을 한두 개로 줄입니다. “이번 범위와 첫 전달일을 아래처럼 이해했습니다. 로고 원본과 확정 문구를 보내주실 수 있을까요? 최종 검토 담당자도 알려주세요.” 답을 받으면 그 내용을 같은 스레드에 남기고 실제 작업 상태를 갱신합니다.
긴 회의록보다 작은 필드와 명시적인 미정 상태가 착수 이후의 재작업을 줄이는 데 도움이 됩니다. 실제 착수 메일 예시와 체크리스트도 정리했습니다. 여러분은 승인과 착수 사이에 어떤 조건을 확인하시나요?
