훌륭한 프로젝트 인수인계는 지금까지 만들어온 모든 것을 지켜줍니다. Trupeer를 사용하면 무료 프로젝트 인수인계 템플릿으로 시작해 브랜드 가이드라인에 맞게 커스터마이징하고, 인수인계를 비디오 워크스루로 전환해 받는 팀이 빠르게 적응하도록 도울 수 있어 인수인계 문서 작성에 드는 시간을 몇 시간씩 절약할 수 있습니다.

프로젝트 인수인계 템플릿이란 무엇이며, 무엇을 담아야 하나요?

프로젝트 인수인계 문서는 무언가를 만든 팀이, 이를 운영할 팀에게 전달하는 문서입니다. 이 문서에는 그 대상이 무엇인지, 현재 누가 소유하는지, 현재 상태가 어떤지, 아직 남아 있는 미해결 사항이 무엇인지, 그리고 누구에게 연락해야 하는지가 명시됩니다.

템플릿은 섹션을 제공합니다. 대부분의 버전은 대체로 동일한 구성으로 제공됩니다. 개요, 상태, 산출물, 연락처, 미해결 작업, 문서, 메모, 승인(사인오프)입니다.

이 구성은 적절합니다. 대부분의 인수인계가 잘못하는 것은 섹션이 아니라 분량이며, 특히 서로 완전히 다르게 동작하는 두 종류의 콘텐츠를 분리하지 않는 점입니다.

인수인계가 발생하기 전에 반드시 충족되어야 하는 조건과, 누가 거부할 권리가 있는지 찾고 있다면 이는 다른 문서이며, 프로젝트 인수인계 체크리스트 템플릿에서 다룹니다. 이 페이지는 실제로 인수인계하는 내용을 다룹니다.

인수인계 문서는 ‘구식’이 되도록 작성됩니다

인수인계 문서를 프로젝트가 만들어내는 다른 모든 문서와 구분 짓는 속성이 있습니다.

그 역할은 받는 팀이 아무것도 모르는 상태에서 유능하게 운영할 수 있는 상태로 전환되도록 돕는 것입니다. 그 일이 보통 몇 주 안에 이루어지면, 문서는 제 역할을 다한 것이며 다시 열어볼 필요가 없습니다. 팀의 자체 이해, 자체 런북, 자체 메모가 이를 대체합니다.

이것은 실패가 아닙니다. 성공이 바로 이런 모습입니다.

실수는 이를 ‘영구 참고자료’처럼 작성하는 것입니다. 영구 참고자료는 포괄적이어야 하고, 포괄성이야말로 중요한 첫 주에 읽히지 않게 만드는 정확한 이유입니다. 187페이지짜리 패키지는 시스템을 계속 운영하면서도 첫 2주 동안 4명이 읽지 않습니다. 문서는 보관됩니다.

따라서 인수인계 문서는 처음 48시간과 처음 3주에 맞춰 최적화되어야 하며, 모든 영구적인 내용은 다른 곳에 두고 링크로 연결해야 합니다.

Trupeer에서 이 템플릿을 커스터마이징하는 방법

1단계: 템플릿 섹션 열기

메인 내비게이션에서 템플릿 섹션으로 이동하세요.

2단계: 템플릿 선택 후 열기

작업하려는 템플릿을 클릭해 열어보세요.

3단계: 템플릿 보기 확장

필요한 경우 템플릿 보기를 확장해 전체 레이아웃과 세부 정보를 명확히 확인하세요.

4단계: 템플릿 편집

편집(Edit)을 클릭해 선택한 템플릿을 수정하기 시작하세요.

편집기에서 다음을 할 수 있습니다.

• 새 섹션 추가

• 서식 규칙 정의 또는 업데이트

• 로고를 추가하고 위치 및 관련 설정을 조정

5단계: 커스터마이징한 템플릿 저장

필요한 모든 변경을 마친 후 저장(Save)을 클릭해 업데이트된 템플릿을 본인 템플릿으로 저장하세요.

6단계: 템플릿 미리보기 및 미세 조정

커스터마이징한 템플릿이 어떻게 보이는지 확인하려면 미리보기(Preview)를 여세요.

미리보기 화면에서 필요하다면 계속해서 조정을 직접 진행할 수 있으며, 템플릿이 원하는 그대로 표시되도록 할 수 있습니다.

프로젝트 인수인계 템플릿을 사용하면:

• 인수인계 시간을 절약: 전환을 위해 구조가 설계된 빈 페이지를 건너뛰세요.

• 모든 산출물 커버: 내장 섹션 덕분에 어떤 deliverable, 문서(doc) 또는 사인오프(sign-off)도 누락되지 않습니다.

• 브랜드에 맞게 유지: Trupeer의 브랜드 키트를 사용해 로고, 폰트, 색상을 적용하세요.

• 받는 팀을 더 빠르게 온보딩: 인수인계를 비디오 워크스루와 함께 제공하세요.

• 프로젝트 전반에 표준화: 모든 프로젝트 전환에 동일한 템플릿을 사용하세요.

• 글로벌 팀에 도달: 클릭 한 번으로 인수인계 문서를 65+개 언어로 번역하세요.

부트스트랩 콘텐츠와 레퍼런스 콘텐츠는 다른 것들입니다

모든 후보 항목을 두 가지 범주 중 하나로 분류하면, 패키지가 스스로 재구성됩니다.

부트스트랩 콘텐츠. 지금 당장 필요하지만, 나중에는 쓸모가 없습니다. 두 문장으로 이게 무엇인지. 지금 누가 소유하는지. 무엇이 취약한지. 무엇을 위해 누구에게 연락해야 하는지. 무엇이 미해결인지. 요청 없이 바꾸면 안 되는 것. 나머지 모든 것이 어디에 있는지.

레퍼런스 콘텐츠. 가끔 필요하고, 수년간 필요합니다. 아키텍처. 실제 구축 구성(As-built configuration). 런북. 테스트 결과. 요구사항 추적성. 사용자 가이드. 계약서.

부트스트랩 콘텐츠는 인수인계 문서에 있어야 하며, 인수인계 문서는 두 페이지여야 합니다.

레퍼런스 콘텐츠는 운영 문서(operational documentation)에 있어야 합니다. 받는 팀은 이미 그곳에 필요한 것들을 보관하고 있으며, 인수인계 문서에서 링크를 통해 그것을 찾게 됩니다. 레퍼런스 콘텐츠는 패키지 안에 들어가면 안 됩니다. 패키지에 묶는 것이 패키지를 읽기 어렵게 만들고, 팀의 자체 시스템에 흡수되는 것이 아니라 ‘한 덩어리’로 아카이브되게 만드는 원인이기 때문입니다.

저희의 프로젝트 문서 템플릿은 어떤 레퍼런스 문서를 반드시 보관할 가치가 있는지 다루고, IT 문서 템플릿은 이후에 실제 구축 자료(as-built material)가 어디에 있어야 하는지 다룹니다.

무엇이 먼저 깨지나: 템플릿에 없는 ‘그것’

인수인계 팀이 쓸 수 있는 가장 가치 있는 단 하나는 ‘무엇이 취약한지’ 목록이지만, 어떤 인수인계 템플릿도 그것을 요구하지 않습니다.

프로젝트 팀은 알고 있습니다. 어떤 통합은 예정된 재시도로 유지되는지, 어떤 구성은 상위 시스템이 일관되게 동작해야 하는지, 파일이 늦게 도착하면 어떤 작업이 실패하는지, 그리고 빌드의 어떤 부분은 처음부터 완전히 만족스럽지 않았는지 말입니다. 이 지식은 인수인계 당일에는 완전하지만, 한 달 안에 사라집니다.

사라지는 이유는 아무도 그것을 요구하지 않기 때문입니다. 테스트 결과는 통과한 것을 기록합니다. 리스크 로그는 사람들이 사전에 걱정했던 것을 기록합니다. 하지만 엔지니어가 ‘어디가 약점인지’에 대해 개인적으로 판단한 내용은 둘 다 담지 못합니다.

다섯 가지를 요청하세요. 무엇이 먼저 깨질지, 왜 그런지, 그것이 깨졌을 때 어떤 모습인지, 그리고 무엇을 해야 하는지. 프로젝트 매니저가 아니라, 그것을 만든 사람들이 작성해야 합니다. 프로젝트 매니저는 모르기 때문입니다.

실제로 이 방식이 작동하게 만드는 데는 두 가지가 있습니다. 첫째, 책임을 묻지 않는 방식으로 명확히 하세요. 이것은 부실 작업을 인정하는 게 아니라, 그들이 넘겨줄 수 있는 가장 유용한 것이라는 점을 강조하고, 이를 결함 목록(defect list)으로 프레이밍하면 빈 섹션이 보장됩니다. 둘째, 인수인계 당일이 아니라 인수인계 2주 전에 요청하세요. 당일에는 답이 “제가 아는 한 아무것도 없습니다”가 되기 쉽습니다.

첫 주를 위한 2페이지 문서

여기서 복사하세요. 두 면이며, 확장을 억제하세요.

이것이 무엇인지. 그 대상이 무엇이며 비즈니스에 무엇을 해주는지 두 문장으로 설명합니다.

현재 누가 소유하는지. 받는 소유자를 이름으로, 그 위의 에스컬레이션 담당자를, 그리고 소유권이 이전된 날짜를 적습니다.

무엇이 먼저 깨지는지. 위와 같이 다섯 가지를 적되, 증상과 첫 번째 조치를 함께 작성합니다.

무엇을 위해 누구에게 연락할지. 짧은 라우팅 목록입니다. 내부 팀, 시스템 인테그레이터, 각 벤더의 지원 라인(계약 참조 및 근무 시간 포함), 그리고 하이퍼케어(hypercare) 기간 동안 계속 사용 가능할 프로젝트 담당자(이름 명시)입니다. 인테그레이터만 이름 붙인 연락처 목록은 반복적으로 발생하는 비용이 큰 누락입니다.

무엇이 미해결인지. 소유자와 날짜가 포함된 심각도별 오픈 결함, 결정을 통해 연기된 항목 기록, 그리고 인수인계 이후에 프로젝트가 하기로 합의한 모든 것을 적습니다.

요청 없이 바꾸면 안 되는 것. 변경 시 비가시적인(명확하지 않은) 결과가 생길 수 있는 구성, 작업(jobs) 또는 설정입니다. 짧고 구체적으로 작성하며, 실제로 예방에 도움이 되는 섹션 중 하나여야 합니다.

나머지 모든 것이 있는 곳. 받는 팀이 이미 사용하는 위치에서, 이름으로 레퍼런스 자료에 대한 링크를 제공합니다.

여기까지 복사하세요. 두 면을 넘어간다면, 그 안에는 레퍼런스 콘텐츠가 포함된 것입니다.

무료 프로젝트 인수인계 템플릿: 복사할 구조

전체 인수인계는 위의 두 페이지 문서와, 참조된 자료의 정의된 세트로 구성됩니다. 패키지는 두 가지의 합집합이며, 단일 번들이 아닙니다.

첫 주 2페이지 문서, 위와 동일.

참조된 레퍼런스 자료, 각각은 패키지 안이 아니라 영구적인 ‘자기 집’에 존재:

실제 작업을 수행하는 누군가가 검증한 구축 설명(As-built description). 모든 예정된, 자동화된 또는 반복 작업을 위한 런북. 아키텍처 또는 자산 기록. 알려진 한계와 현재의 우회 방법. 역할 기반 계정으로 이전된 접근 및 계정 기록. 갱신 날짜가 포함된 계약, 라이선스 및 지원 체계. 표준이 요구하는 경우에 한해 보관하는 최종 요구사항 및 수용 증거. 모니터링 및 알림 구성.

인수인계 기록. 날짜, 당사자, 무엇이 이전되었는지, 수용(acceptance)에 붙는 조건, 하이퍼케어 조건, 서명. 1페이지이며 아카이브합니다.

이것이 번들로 다시 붕괴되는 것을 막는 두 가지 규칙이 있습니다. 모든 참조 문서는 인수인계 전에 받는 팀의 시스템에 실제로 존재해야 하며, 약속만 하면 안 됩니다. 그리고 두 페이지 문서는 그 어떤 문서를 열지 않아도 읽을 수 있어야 하며, 이것이 부트스트랩 콘텐츠가 실제로 분리되어 있는지 확인하는 테스트입니다.

187페이지 중 22페이지를 읽은 방송사 담당자

약 800명 규모의 출판사이자 방송사인 Sedgewick Media는 새로운 디지털 자산 관리 시스템의 인수인계를 받았습니다.

패키지는 14개의 문서에 걸쳐 총 187페이지였고, 여기에 41장짜리 슬라이드 덱이 추가로 포함되었습니다. 프로젝트 개요 8페이지. 아키텍처 22페이지. 요구사항 추적성 34페이지. 테스트 결과 46페이지. 실제 구축 구성 31페이지. 사용자 가이드 28페이지. 연락처 목록 2페이지. 미해결 항목 3페이지. 사인오프 1페이지.

받는 팀은 디지털 운영 분야의 4명이었습니다.

1주차에 인제스트(ingest) 작업이 실패했습니다. 런북이 없었습니다. 그들은 약 3시간 동안 실제 구축 구성(as-built configuration)을 읽어가며 문제를 해결했습니다.

2주차에는 예정된 퍼지(purge)가 보관되어야 할 자산을 삭제했습니다. 프로젝트 팀은 이것이 취약하다는 사실을 알고 있었습니다. 보관 규칙은 상위 시스템이 메타데이터 필드를 채우는데, 그 필드가 일관되지 않게 채워지는 방식에 의존했기 때문입니다. 이 사실은 118페이지에 나타났는데, 테스트 결과(test result) 안에서 ‘알려진 동작(known behaviour)’으로 설명되어 있었습니다. 61개의 자산을 아카이브에서 복구해야 했고, 직원 시간과 벤더 비용을 합쳐 약 1만 4천 파운드가 들었습니다.

3주차에는 연락처 목록이 시스템 인테그레이터를 지칭했기 때문에, 잘못된 벤더에 두 번이나 연락했습니다. 자산 관리 벤더의 지원 라인이 아니었습니다.

나중에 무엇이 도움이 되었을지 물었을 때, 받는 팀의 답은 2페이지였습니다. 무엇이 먼저 깨지는지, 누구에게 연락해야 하는지, 무엇이 미해결인지, 그리고 무엇은 건드리지 말아야 하는지.

187페이지 중 첫 달에 읽은 것은 22페이지였습니다.

다음 인수인계는 권한 관리 시스템이었는데, 2페이지짜리 첫 주 문서와 운영 팀의 자체 문서에 보관되어 링크로 연결된 94페이지 분량의 레퍼런스 자료를 사용했습니다(번들로 묶지 않음). ‘먼저 깨지는 것’ 목록은 5개 항목이었고, 이를 만든 두 명의 엔지니어가 작성했습니다.

첫 달에 사건은 한 번 있었습니다. 그 목록의 두 번째 항목이었습니다. 40분 만에 해결되었습니다.

프로젝트 인수인계 문서에는 무엇이 포함되어야 하나요?

위의 부트스트랩 콘텐츠와, 대부분의 패키지가 누락하거나 묻어버리는 5가지가 특히 포함되어야 합니다.

무엇이 먼저 깨지는지, 제작자(빌더)가 작성.

벤더 지원 라인, 인테그레이터만이 아니라 계약 참조와 근무 시간까지 포함.

바꾸면 안 되는 것, 짧고 예방 목적이어야 합니다.

소유자와 날짜가 포함된 미해결 항목, 날짜가 없는 오픈 결함은 영구화되기 때문입니다.

레퍼런스 자료가 있는 위치, 패키지 안이 아니라 받는 팀의 시스템에 있어야 합니다.

문서를 인수인계하면서도 문서에서 빼야 할 것: 아키텍처 다이어그램, 테스트 결과, 요구사항 추적성, 사용자 가이드, 구성 내보내기(configuration exports). 모두 유용하지만, 누군가가 첫 주에 읽는 ‘그 문서’ 안에 들어가면 안 됩니다.

프로젝트 인수인계 문서를 작성하는 방법

인수인계 2주 전부터 시작하세요. 당일에 하면 안 됩니다. ‘먼저 깨지는 것’ 목록은 생각할 시간이 필요하고, 프로젝트가 끝나 흩어질 엔지니어들이 필요합니다.

다른 어떤 것을 조립하기 전에 먼저 2페이지 문서를 작성하세요. 이 순서로 하면 부트스트랩과 레퍼런스의 분리가 강제로 이루어집니다.

취약한 항목은 회의가 아니라 빌더에게 개별적으로 요청하세요. 프로젝트 매니저가 있는 그룹에서는 답이 “모두 괜찮습니다”가 되기 쉽습니다.

모든 레퍼런스 링크가 실제로 연결되는지 확인하고, 링크가 가리키는 문서가 프로젝트가 아니라 받는 팀의 시스템에 있는지 확인하세요. 아카이브될 프로젝트 SharePoint로 연결되는 링크는 지연이 있는 ‘깨진 링크’입니다.

받는 팀에서 누군가가 두 페이지를 읽고, 문서가 가리키는 것만 사용해 실제 작업 하나를 시도하게 하세요. 그들이 묻는 모든 질문은 ‘빈틈(gap)’입니다.

그 다음 하이퍼케어 조건을 합의하고 서명하세요. 이 내용은 저희의 프로젝트 인수인계 체크리스트 템플릿에 포함되어 있습니다.

인수인계 리포트 변형(variants)과 각 문서를 읽는 사람

‘인수인계 리포트’라는 단어는 넓은 범주의 문서를 포괄하며, 문서들은 실제로도 서로 다릅니다. 템플릿 라이브러리를 찾고 있다면 알아둘 만한 가치가 있습니다.

이 중 두 가지는 별도의 방식으로 다뤄집니다. 건설 인수인계(construction handover)는 운영 문서(operating documentation)를 중심으로 하며, 저희의 운영 및 유지보수 매뉴얼 템플릿(operation and maintenance manual template)은 왜 보통 확인이 아니라 해당 문서가 수용되는지 그 이유를 다룹니다. 역할 인수인계(role handover)는 산출물(artefacts)보다 지식에 관한 것이며, 저희의 지식 전달 SOP 템플릿(knowledge transfer SOP template)은 작성된 목록이 드러내지 못하는 것을 표면화하는 방법을 다룹니다.

모범 사례와 반복되는 실수

문서(document)를 작성하세요. 패키지(pack)가 아니라. 두 페이지와 링크는 매번 번들을 이깁니다.

취약한 것이 무엇인지, 책임을 묻지 않는 방식으로 미리 물어보세요. 가장 가치가 큰 섹션이면서도, 아무도 요청하지 않는 섹션입니다.

인테그레이터만이 아니라 벤더를 명시하세요. 첫 달에 반복적으로 발생하고 쉽게 피할 수 있는 비용입니다.

모든 미해결 항목에 날짜를 붙이세요. 날짜가 없으면 영구가 됩니다.

레퍼런스 자료는 인수인계 전에 받는 팀의 시스템에 넣으세요. 프로젝트의 시스템에 넣지 마세요. 프로젝트는 아카이브됩니다.

인수인계하고 같은 날에 종료(클로즈)하지 마세요. 종료는 하이퍼케어가 의존하는 예산과 사람을 제거합니다.

받는 팀이 문서를 ‘읽는’ 대신 ‘테스트’하게 하세요. 인수인계 패키지를 읽는다고 해서 그것이 실제로 작동하는지 알 수는 없습니다.

프로젝트 인수인계 문서인가요, 인수인계 체크리스트인가요?

둘은 같은 이벤트의 두 부분이며, 서로 다른 문서입니다.

체크리스트는 인수인계가 발생할 수 있는지 여부를 결정합니다. 수용 기준(acceptance criteria), 이를 검증하는 사람, 그리고 거부할 권한이 있는 사람을 포함합니다. 체크리스트는 인수인계 전과 인수인계 시점에 완료되며, 인수인계가 수용(accepted)되는 순간 그 가치는 끝납니다. 저희의 프로젝트 인수인계 체크리스트 템플릿은 이를 다루며, 기준(criteria)은 종료 시점의 프로젝트가 아니라 계획 단계에서 받는 팀이 작성해야 하는 이유까지 포함합니다.

인수인계 문서는 실제로 전달되는 것입니다. 받는 팀이 운영을 시작하는 데 필요한 부트스트랩 콘텐츠가 여기에 담깁니다. 인수인계가 수용되는 순간부터 그 가치는 시작됩니다.

대부분의 조직은 첫 번째(체크리스트)에는 어떤 형태로든 버전이 있고, 두 번째 대신 번들을 사용합니다. 문서 없이 체크리스트만 있으면, 실행할 수 없는 팀에게 ‘규정 준수(compliant)’ 인수인계를 제공하게 됩니다. 체크리스트 없이 문서만 있으면, 아무도 거부할 수 없었던 좋은 브리핑이 만들어집니다.

엑셀이나 워드에서 프로젝트 인수인계 템플릿을 받을 수 있나요?

두 페이지 문서에는 Word 또는 Google Docs가 적합합니다. 글(prose)로 되어 있고, 정렬해서 읽는 게 아니라 읽기 때문입니다. 두 면으로 유지하고, 기록용으로 PDF로 내보내세요.

열(columns)이 필요한 두 개의 목록에는 Excel이 적합합니다. 심각도(severity), 소유자(owner), 목표 날짜(target date)가 포함된 미해결 항목. 그리고 시스템, 벤더, 계약 참조, 근무 시간(hours), 전화번호가 포함된 연락처 라우팅 목록. 둘 다 첫 몇 달 동안 변경될 수 있으며, 둘 다 읽는 것이 아니라 참고하게 됩니다.

프로젝트와 함께 아카이브되는 서명된 인수인계 기록에는 PDF가 적합합니다. 1년 뒤 무언가가 잘못됐을 때 사람들이 다시 돌아와 확인하는 문서이기 때문에, 고정(동결)하고 날짜를 지정하는 것이 중요합니다.

어떤 형식이든, 모든 것을 담은 단일 번들 문서는 작동하지 않습니다. 이 페이지가 설명하는 실패가 바로 그것이며, 형식은 그 문제를 바꾸지 못합니다.

‘먼저 깨지는 것’ 목록을 빠르게 작성하는 방법

여기서 가치가 가장 높은 두 섹션, 즉 취약한 항목과 그것이 가리키는 런북은 누락될 가능성이 가장 높고, 같은 이유로 그렇습니다. 둘 다 프로젝트에 시간이 가장 적은 주에, 몇 달 전에 자신이 만들었던 무언가를 누군가가 상세히 설명해야 합니다.

Trupeer AI는 그 비용의 대부분을 제거합니다. 작업을 만든 엔지니어가 직접 실행하는 모습을 기록하고, 실패했을 때의 모습과 그에 대해 무엇을 하는지도 포함합니다. 결과물은 단계와 화면이 이미 캡처된 ‘서면 런북’입니다. 취약한 항목과 그 첫 번째 조치는 같은 기록에서 나옵니다.

기록하세요. 브랜딩하세요. 번역하세요. Trupeer하세요.

이렇게 하면 받는 팀이 설명을 읽고 ‘희망’하는 것이 아니라, 기록에서 파생된 가이드를 사용해 실제로 작업을 수행할 수 있으므로 인수인계가 ‘주장’이 아니라 ‘검증 가능’해집니다. 절차(procedures)는 SOP creator가 다루고, 이후에 유지할 가치가 있는 항목은 저희의 IT SOP 템플릿이 다룹니다. 그리고 자료는 일관된 브랜딩으로 지식 베이스에 저장되며, 레퍼런스 링크는 이곳을 가리켜야 합니다. 설정 지침은 문서 템플릿 설정 가이드에 있습니다.

자주 묻는 질문

엑셀에서 무료 프로젝트 인수인계 템플릿을 제공하나요?

엑셀은 문서보다 두 개의 목록에 더 적합합니다. 심각도, 소유자, 날짜가 포함된 미해결 항목과 연락처 라우팅 목록입니다. 잠금 해제 다운로드도 없고, 폼도 없습니다. 두 페이지 분량의 서술형 내용은 문서로 유지하세요. 급하게 한 번 읽는 용도이며, 셀은 그에 맞지 않는 컨테이너이기 때문입니다.

워드에서 무료 프로젝트 인수인계 템플릿을 제공하나요?

위의 두 페이지 구조는 Word 또는 Google Docs에 그대로 붙여넣을 수 있습니다. 형식보다 ‘길이’에 대한 규율이 중요합니다. 두 면을 넘어가면, 그 안에는 레퍼런스 콘텐츠가 포함된 것이며 받는 팀의 문서에 링크와 함께 들어가야 합니다.

PDF에서 무료 프로젝트 인수인계 템플릿을 제공하나요?

두 페이지 문서와 서명된 인수인계 기록을 PDF로 내보내 아카이브용으로 저장하세요. 레퍼런스 자료를 같은 PDF에 번들로 묶지 마세요. 아무도 읽지 않는 문서를 만드는 정확히 그 패턴이기 때문입니다.

PDF로 된 프로젝트 인수인계 문서는 어디에서 찾을 수 있나요?

여러 대학과 공공 기관이 이를 공개하고 있으며, 항목 목록(item list)에는 유용합니다. 무엇이 없는지(부재)도 함께 읽어보세요. 거의 모든 문서에는 취약-항목 섹션이 없고, 대부분 레퍼런스 자료를 패키지에 묶어 넣는데, 이 페이지는 바로 그 두 가지에 반대하는 논지를 펼칩니다.

프로젝트 인수인계 문서는 얼마나 길어야 하나요?

사람들이 읽는 문서는 두 면, 그리고 그 대상이 실제로 필요로 하는 레퍼런스 자료의 양만큼은 별도로 보관하세요. 위의 실제 예시가 그 논거입니다. 187페이지짜리 패키지 중 첫 달에 읽은 것은 22페이지였습니다.

프로젝트 인수인계 문서는 누가 작성해야 하나요?

프로젝트 매니저가 두 페이지 문서를 작성하고, 해당 대상을 만든 엔지니어가 취약한 항목을 작성합니다. 이 분리는 중요합니다. 프로젝트 매니저는 무엇이 취약한지 모르고, 엔지니어는 연락처 라우팅 목록을 작성하지 않을 가능성이 있기 때문입니다.

인수인계 리포트란 무엇인가요?

프로젝트 인수인계보다 더 넓은 범주의 문서로, 교대 인수인계(shift handovers), 역할 인수인계(role handovers), 자산 이전(asset transfers), 고객 수용(client acceptance)을 포함합니다. 템플릿 라이브러리에는 간호, 창고/물류, 시설 관리 등 업종별로 특화된 것을 포함해 수십 가지 변형이 나열되어 있습니다. 위 표는 각 경우에 누가 누구에게 넘기는지 정리하고 있는데, 핵심 콘텐츠가 상당히 다르기 때문입니다.

인수인계 문서는 언제 작성해야 하나요?

인수인계 2주 전부터 시작하세요. 취약한 항목은 생각할 시간이 필요하고, 곧 흩어질 사람들도 필요합니다. 당일에 작성하면 해당 섹션이 비어 돌아오게 되며, 가장 가치 있는 인수인계의 일부가 사라지는 가장 흔한 방식입니다.