개념 사전 · 업무 지식

프로젝트 협업

프로젝트 협업 · 변경 관리

은 작업을 나누고 ·책임·변경 사항을 관리하여 팀의 산출물을 통합하는 활동이다. 담당자에게 작업을 배정하는 것뿐 아니라 입력 조건과 완료 증거를 명확하게 만드는 일이 중요하다.

밑줄 용어에 마우스를 올리거나, 키보드로 선택하거나, 터치하면 설명을 볼 수 있습니다.

01무엇이고, 어떤 일을 하나

가상 작업 설정: A 환경 준비 2일, B 네트워크 구성 3일, C 서버 구성 4일, D 통합 시험 1일을 가정한다. B·C는 A 이후, D는 B·C 둘 다 끝난 뒤 시작한다.
독립 인력의 일정: B와 C를 다른 담당자가 동시에 수행하면 전체는 2+max(3,4)+1=7일이다. A→C→D가 이 단순 모델의 임계 경로다.
B의 여유: B는 5일째 끝나고 C는 6일째 끝난다. B가 1일 늦어져도 D의 시작은 6일째로 유지된다.
변경 요청 반영: B에 2일이 추가되면 B가 7일째 끝나므로 D까지 총 8일이다. 새 는 A→B→D가 된다.
공유 인력의 제약: 한 사람이 B·C를 순차로 수행해야 한다면 기본 계획도 2+3+4+1=10일이다. 담당자를 확인하지 않은 7일 약속은 자원 제약을 빠뜨린다.
상태 보고: 추가 작업의 이유, 영향 받은 경로, 승인자, 새 완료 예측과 줄일 수 있는 범위를 함께 보고한다. 단순 “2일 지연”보다 어떤 이 바뀌었는지가 핵심이다.

최종 결정자 누락: 작업 수행자만 있고 승인 주체가 없으면 서로 다른 완료 기준을 사용할 수 있다. 수행과 최종 결정의 권한·기한을 함께 정한다.
차단 상태의 이유: 대기 중이라는 상태에 필요한 입력, 제공 주체, 요청 시각과 다음 확인 시점을 기록한다. 상태 이름만 반복해서 갱신하지 않는다.
늦은 통합: 각 팀이 내부 시험만 통과하고 최종 주에 연결하면 인터페이스 오해가 늦게 드러난다. 최소한의 종단 경로를 먼저 연결해 계약을 검증한다.
변경 누적: 작은 요청도 여러 개 합치면 시험·문서·운영 범위가 커진다. 승인한 변경과 미승인 제안을 구분하고 일정·완료 기준의 영향을 누적해서 본다.
서로 다른 상태 정의: 한 팀의 완료가 다른 팀의 시작 준비에 불과할 수 있다. 리뷰·시험·인계까지 포함하는 공통 정의와 팀별 중간 상태를 구분한다.
의사결정 소실: 결정 이유·대안·전제 조건이 없으면 담당자 변경 때 같은 논의를 반복한다. 결정 기록에 재검토를 촉발할 조건도 함께 둔다.

헤더 구조, 설정 예시, 수치 계산과 수업 캡처는 아래 노트에서 이어집니다.

기초 개념과 동작 설명을 대조한 자료입니다. 제품 버전과 실제 설정에 따른 차이는 본문 및 원문에서 확인하세요.