중간 상승 지연과의 싸움을 중단하십시오!

중층 프로젝트가 뒤쳐지는 경우 지연이 한 가지 문제만으로 발생하는 경우는 거의 없습니다. 자재 배송이 늦어지면 조달 계획이 취약해질 수 있습니다. 설계 변경은 프레임 구성, 검사, 인력 및 현금 흐름에 동시에 영향을 미칠 수 있습니다. 나는 이것이 얼마나 스트레스를 받는지 압니다. 놓친 모든 이정표는 소유주, 계약자, 컨설턴트, 대출 기관 및 미래 임차인 사이에 압력을 가합니다. 올바른 대응은 계획 없이 모든 거래를 더 열심히 추진하는 것이 아닙니다. 프로젝트에는 사실적 검토, 실질적인 복구 일정, 일일 조정이 필요합니다. 지연의 실제 원인을 찾는 것부터 시작합니다. ### 1. 현재 프로젝트 진행 상황을 검토합니다. 승인된 일정과 실제 현장 진행 상황을 비교합니다. 이 검토에서는 다음 내용을 다룹니다. - 완료된 작업 - 공개 허가 및 검사 - 지연된 자재 - 가용 인력 - 설계 변경 - 해결되지 않은 정보 요청 - 날씨 또는 현장 조건 - 무역 계약자 성과 - 지불 및 조달 문제 일정은 프레이밍이 늦어진 것으로 나타날 수 있지만 더 깊은 문제는 불완전한 구조적 세부 사항에 있습니다. 프레임 제작팀에만 집중하면 다음 주에도 동일한 지연이 발생할 수 있습니다. ### 2. 눈에 띄는 지연과 심각한 지연을 분리하세요. 모든 지연 작업이 인계 날짜에 영향을 미치는 것은 아닙니다. 일부 활동에는 플로트가 제공됩니다. 다른 것들은 여러 가지 미래 작업을 제어합니다. 어떤 활동이 영향을 미치는지 확인합니다. - 건물 인클로저 - 기계, 전기 및 배관 공사 - 화재 예방 작업 - 엘리베이터 설치 - 검사 - 내부 폐쇄 - 점유 승인 이는 팀이 프로젝트 결과를 변경할 수 있는 작업에 집중하는 데 도움이 됩니다. 이는 현재 마일스톤을 제어하지 않는 작업에 시간과 비용이 낭비되는 것을 방지합니다. ### 3. 사람들이 사용할 수 있는 복구 일정 수립 복구 일정에는 작업, 소유자, 날짜 및 종속성이 표시되어야 합니다. 매일 사용하지 않고 공유 폴더에 보관되는 수정된 문서가 되어서는 안 됩니다. 지연된 각 활동에 대해 다음과 같이 질문합니다. 1. 작업을 방해하는 것은 무엇입니까? 2. 막힌 부분을 누가 제거할 수 있나요? 3. 어떤 정보나 자료가 필요한가요? 4. 작업은 언제 재개할 수 있나요? 5. 다음 중 이에 의존하는 작업은 무엇입니까? 6. 변경 후에는 어떤 위험이 나타날 수 있나요? 일정은 실제 현장 조건을 반영해야 합니다. 도면이 불완전하거나, 접근이 제한되거나, 자재가 도착하지 않은 경우 인력을 추가해도 지연 문제가 해결되지 않습니다. ### 4. 무역 조정 개선 중층 프로젝트에는 종종 중복되는 거래가 많이 포함됩니다. 한 팀이 섹션을 완료하는 동안 다른 팀은 액세스를 기다릴 수 있습니다. 제대로 전달되지 않으면 월별 보고서에서 확인하기 어려운 시간 손실이 발생할 수 있습니다. 나는 다음 작업 영역에 초점을 맞춘 짧은 조정 회의를 사용합니다. 각 거래는 다음 사항을 확인합니다. - 필요한 영역 - 완료할 작업 - 필요한 자재 - 수행해야 하는 검사 - 후속 거래 - 예상되는 제약 조건 2~6주에 걸친 간단한 예측 계획은 현장에 도달하기 전에 충돌을 드러낼 수 있습니다. ### 5. 설계 변경 및 정보 요청 제어 답변이 없는 질문은 여러 층에 걸쳐 작업을 중단할 수 있습니다. 설계 변경이 설치 후 도착하면 재작업이 발생할 수 있습니다. 다음 내용이 포함된 실시간 추적 로그를 권장합니다. - 요청 번호 - 제출 날짜 - 책임 있는 검토자 - 영향을 받는 거래 - 일정 영향 - 비용 영향 - 필수 응답 날짜 - 현재 상태 목표는 기술적 결정을 서두르지 않는 것입니다. 목표는 적절한 사람들에게 적시에 결정을 내리고 프로젝트에 미치는 영향을 기록할 수 있는 충분한 정보를 제공하는 것입니다. ### 6. 자재 공급망 보호 자재 지연에는 새로운 배송 약속 이상의 것이 필요합니다. 승인부터 설치까지 전체 경로를 확인합니다. - 제출물이 승인되었나요? - 구매주문서가 발행되었나요? - 공급자가 생산을 확인하고 있는가? - 배송이 준비됐나요? - 현장에서 자료를 받을 준비가 되어 있나요? - 재료에 검사나 테스트가 필요한가요? 예를 들어, 12층짜리 주거용 건물에서는 창문 설치가 주요 문제로 보일 수 있습니다. 자세히 검토해 보면 창 패키지가 여러 섹션으로 나누어 배송된 반면 현장에는 안전한 보관 공간이 부족하고 설치 직원이 다른 프로젝트로 이동했음을 알 수 있습니다. 복구 계획에서는 배달, 보관, 인력 및 접근을 함께 다루어야 합니다. ### 7. 현장 증거를 통해 진행 상황을 추적하세요. 복구 계획에는 안정적인 업데이트가 필요합니다. 보고된 진행 상황을 현장 기록, 날짜가 적힌 사진, 검사 결과, 배송 티켓, 완료된 작업 영역과 비교합니다. 유용한 일일 보고서에는 다음이 포함될 수 있습니다. - 완료된 작업 - 작업원 규모 - 작업 영역 - 수령된 자재 - 검사 통과 또는 보류 중 - 제약 조건 - 사진 - 다음 교대 근무에 대한 계획된 작업 이 프로세스는 프로젝트 팀에게 진행 상황에 대한 공유 보기를 제공합니다. 동일한 일정을 다르게 해석하여 발생하는 분쟁을 줄여줍니다. ### 8. 시간을 회복하면서 품질을 보호하세요 일정 압박으로 인해 작업이 성급해지고, 점검을 건너뛰고, 비용이 많이 드는 재작업이 발생할 수 있습니다. 그러면 첫 번째 지연 이후에 두 번째 지연이 발생합니다. 나는 복구 계획과 관련된 품질 검사를 계속 수행합니다. 팀은 작업을 시작하기 전에 필요한 검사, 보유 지점, 테스트 및 문서화를 식별해야 합니다. 설치를 제거하고 다시 완료해야 하는 경우 빠른 설치는 도움이 되지 않습니다. ### 9. 직접적인 의사소통을 유지하십시오. 소유자와 프로젝트 팀은 정직한 업데이트가 필요합니다. 유용한 상태 보고서는 다음 사항을 설명합니다. - 변경된 사항 - 변경된 이유 - 프로젝트 팀이 수행하는 작업 - 영향을 받을 수 있는 날짜 - 필요한 결정 - 다음 작업의 소유자는 누구입니까? "문제가 처리되고 있습니다"와 같은 모호한 진술은 피합니다. 더 강력한 업데이트에서는 문제, 책임자, 다음 검토 지점을 지정합니다. ### 실제 사례 한 중층 사무실 프로젝트는 콘크리트 타설이 며칠 동안 지연된 후 뒤쳐졌습니다. 눈에 띄는 우려는 구조적 일정이었습니다. 더 넓은 영향에는 기계식 슬리브 지연, 프레이밍 시작 지연, 다음 거래에 대한 액세스 제한 등이 포함되었습니다. 프로젝트 팀은 다음 6주를 검토하고, 검사 날짜를 확인하고, 보류 중인 작업 도면을 공개하고, 자재 배송을 조정하고, 영향을 받는 작업을 더 작은 영역으로 나누었습니다. 승무원은 단순히 현장 전체에 추가되지 않았습니다. 작업을 진행하는 데 필요한 도면, 접근 권한 및 자재가 있는 작업 영역에 인력이 배정되었습니다. 이러한 유형의 회복은 압력보다는 조정에 달려 있습니다. ### 지연된 중층 프로젝트에 대한 나의 접근 방식 나는 네 가지 질문에 중점을 둡니다. - 실제로 지연의 원인은 무엇입니까? - 프로젝트 날짜를 제어하는 ​​작업은 무엇입니까? - 현재의 막힘을 제거할 수 있는 결정은 무엇입니까? - 팀은 진행 상황을 어떻게 확인할 것인가? 계획이 현장 조건과 일치하면 프로젝트는 실행 가능한 경로로 돌아갈 수 있습니다. 명확한 소유권, 정확한 업데이트, 꾸준한 조정은 팀이 각 결정을 내릴 때 더 나은 기반을 제공합니다. 중층 프로젝트가 일정 압박에 직면한 경우 구조화된 지연 검토를 통해 주의가 필요한 부분과 어떤 복구 조치가 실용적인지 확인할 수 있습니다.

프로젝트가 느리게 진행된다고 해서 항상 노력이 부족한 것이 문제인 것은 아닙니다. 나는 종종 팀이 불분명한 목표, 긴 승인 체인, 반복적인 수정, 결정으로 이어지지 않는 회의로 인해 시간을 낭비하는 것을 봅니다. 그 결과는 익숙합니다. 사람들은 늦게까지 일하고, 우선순위는 바뀌지만, 최종 제품은 여전히 ​​사용자에게 필요한 것을 놓치고 있습니다. 나는 더 간단한 작업 방식을 선호합니다. 목표를 명확하게 하고, 불필요한 단계를 줄이고, 작은 아이디어를 테스트하고, 각 작업에 명확한 소유자를 지정하세요. 이를 통해 팀은 작업을 통제하면서 부담을 덜고 이동할 수 있습니다. ### 하나의 명확한 결과로 시작하세요. 팀이 한 번에 너무 많은 문제를 해결하려고 하면 프로젝트가 더 어려워집니다. 작업을 시작하기 전에 저는 "우리는 [특정 사용자]가 [특정 문제]를 해결하는 데 도움을 주기 위해 이 제품을 만들고 있습니다."라는 한 문장을 씁니다. 예: "지역 피트니스 스튜디오에서 전화 통화 없이 수업 등록을 받을 수 있도록 예약 페이지를 만들고 있습니다." 이 문장은 팀에게 유용한 필터를 제공합니다. 기능이 주요 목표를 지원하지 않으면 현재 프로젝트에 추가하는 대신 나중에 목록에 배치합니다. 명확한 목표는 토론을 더 쉽게 만듭니다. 팀은 개인적인 선호도에 의존하지 않고 같은 점을 기준으로 아이디어를 검토할 수 있습니다. ### 대규모 프로젝트를 작은 부분으로 전환 대규모 작업은 어디서부터 시작해야 할지 알 수 없기 때문에 종종 스트레스를 유발합니다. 저는 프로젝트를 작은 작업 단위로 나눕니다. - 사용자 조사 - 페이지 구조 - 시각적 디자인 - 주요 기능 - 결제 또는 접촉 흐름 - 테스트 - 출시 준비 각 부분에는 명확한 결과가 있어야 합니다. '웹사이트 작업'이 너무 광범위합니다. "모바일 예약 화면 만들기"는 사용자에게 시작하고 완료할 수 있는 특정 작업을 제공합니다. 작은 작업을 통해 진행 상황이 표시됩니다. 또한 전체 프로젝트에 영향을 미치기 전에 지연을 발견하는 데 도움이 됩니다. ### 간단한 버전을 먼저 구축하세요. 많은 팀이 사람들에게 아이디어가 필요한지 확인하기 전에 아이디어를 다듬는 데 너무 많은 시간을 소비합니다. 간단한 버전은 기본적인 질문에 답할 수 있습니다. - 사용자가 제안을 이해할 수 있습니까? - 메인 액션을 완료할 수 있나요? - 혼란스러운 발걸음을 내딛고 있나요? - 제품이 명시된 문제를 해결합니까? 예를 들어, 6명으로 구성된 서비스 비즈니스는 처음에는 대규모 예약 플랫폼이 필요하지 않을 수 있습니다. 명확한 랜딩 페이지, 짧은 양식, 확인 이메일은 수요를 테스트하기에 충분한 정보를 제공할 수 있습니다. 이 접근 방식은 표준을 낮추는 것을 의미하지 않습니다. 이는 팀에게 유용한 것을 가르칠 수 있는 곳에 노력을 기울이는 것을 의미합니다. ### 의사 결정 소유자 설정 모든 작은 선택에 여러 사람의 승인이 필요하면 프로젝트 속도가 느려집니다. 각 영역에 대해 최종 결정을 내릴 사람을 한 명씩 지정합니다. - 제품 방향 - 디자인 - 기술 작업 - 콘텐츠 - 예산 의사 결정 소유자는 여전히 팀의 의견에 귀를 기울입니다. 이 역할은 단순히 토론이 결과 없이 공개적으로 유지되는 것을 방지할 뿐입니다. 유용한 규칙은 결정 날짜를 설정하는 것입니다. 팀이 해당 날짜까지 새로운 정보를 찾을 수 없는 경우 소유자는 옵션을 선택하고 이유를 기록합니다. 이는 피드백을 무시하지 않고 움직임을 만들어냅니다. ### 회의를 행동과 연결시키세요 회의에는 한 문장에 들어갈 수 있는 목적이 있어야 합니다. 예: - 홈페이지 레이아웃 선택 - 사용자 피드백 검토 - 차단된 작업 제거 - 실행 체크리스트 확인 회의가 끝나기 전에 세 가지 세부 사항을 기록합니다. 1. 결정된 내용 2. 다음 작업의 소유자 3. 작업 검토 시기 명확한 조치가 포함된 짧은 회의는 후속 조치가 없는 긴 토론보다 종종 도움이 됩니다. ### 작업이 완료되었다고 느끼기 전에 피드백을 사용하세요. 피드백이 일찍 도착하면 사용하기가 더 쉽습니다. 소규모 사용자 그룹에게 대략적인 스케치, 샘플 페이지 또는 작업 초안을 보여줍니다. “좋아해요?”라고 묻는 대신 집중적으로 질문한다. 더 나은 질문은 다음과 같습니다. - 이 페이지가 귀하에게 어떤 도움이 된다고 생각하시나요? - 다음은 어디를 클릭하시겠습니까? - 어떤 정보가 빠졌나요? - 무엇이 불분명하다고 느껴지나요? 새로운 온라인 주문 양식을 테스트하는 지역 소매업체에서는 고객이 배송 세부정보를 찾을 수 없다는 사실을 발견할 수 있습니다. 초기 테스트 중에 이를 찾는 것은 출시 후 전체 결제 흐름을 변경하는 것보다 노력이 덜 듭니다. ### 팀의 초점을 보호하세요. 사람들이 여러 작업을 전환할 때 스트레스가 커지는 경우가 많습니다. 나는 활동적인 일을 제한하려고 노력한다. 각 사람은 새로운 작업을 시작하기 전에 소수의 작업을 처리합니다. 긴급 요청은 여러 개인 메시지가 아닌 하나의 공유 채널을 통해 전달됩니다. 간단한 일일 점검이 도움이 될 수 있습니다. - 나는 무엇을 하고 있나요? - 무엇이 나를 막고 있나요? - 어떤 결정이 필요합니까? - 무엇을 기다릴 수 있습니까? 명확한 한계는 사람들에게 생각할 수 있는 공간을 제공합니다. 빠른 작업은 모든 작업을 한꺼번에 추진하는 데서 나오는 것이 아닙니다. 이는 주의를 끌기 위해 경쟁하는 작업의 수를 줄이는 데서 비롯됩니다. ### 배송 후 프로세스 검토 프로젝트가 완료되면 개인을 비난하기보다는 프로세스를 살펴봅니다. 나는 묻습니다. -어떤 단계가 우리가 움직이는 데 도움이 되었습니까? - 일은 어디서 기다렸나요? - 어떤 요청이 너무 늦게 도착했나요? - 다음에는 무엇을 제거해야 할까요? - 앞서 무엇을 정의해야 할까요? 작은 변화로 다음 프로젝트를 개선하는 것이 목표입니다. 더 짧은 승인 경로, 더 나은 개요 또는 더 빠른 사용자 테스트는 추가 시간을 추가하는 것보다 더 많은 시간을 절약할 수 있습니다. 더 빠르게 구축한다는 것은 모든 결정을 서두르는 것이 아닙니다. 불분명한 결정을 줄이고, 작업에 집중하고, 비용이 많이 드는 문제가 되기 전에 가정을 확인하는 것입니다. 목표가 가시적이고 작업을 관리하기 쉽고 소유권이 분명하면 팀은 모든 단계에서 불필요한 압력을 가하지 않고 꾸준한 발전을 이룰 수 있습니다.

지연된 작업은 작은 문제로 남아 있는 경우가 거의 없습니다. 부재중 응답으로 인해 견적이 보류될 수 있습니다. 승인이 늦어지면 생산이 지연될 수 있습니다. 불분명한 인계로 인해 고객은 기다리게 되고 여러 팀 구성원은 다른 사람이 작업을 처리하고 있다고 가정할 수 있습니다. 나는 많은 기업에서 이런 일이 일어나는 것을 보았습니다. 지연은 종종 간단한 문제로 시작됩니다. 다음 단계가 명확하지 않습니다. ### 작업 속도가 느려지는 부분 찾기 먼저 하나의 일반적인 요청 경로를 추적합니다. 예: 1. 고객이 문의사항을 보냅니다. 2. 영업팀원이 내용을 확인합니다. 3. 관리자가 가격을 검토합니다. 4. 팀은 답변을 준비합니다. 5. 고객이 견적을 받습니다. 이 프로세스는 단순해 보이지만 각 단계마다 일시 중지가 발생할 수 있습니다. 판매회원은 상품정보를 기다리실 수 있습니다. 관리자는 검토가 필요한 요청이 무엇인지 알 수 없습니다. 팀에서 세부정보를 확인하는 동안 고객은 업데이트를 받지 못할 수도 있습니다. 각 단계에서 소요된 시간을 기록해 보세요. 일을 하는 데 소요되는 시간뿐만 아니라 반복되는 기다림도 찾아보세요. 완료하는 데 10분이 걸리는 작업이 다음 사람에게 도달하는 데는 3일이 걸릴 수도 있습니다. ### 모든 작업에 명확한 소유자를 지정하세요. 책임을 공유하면 소리 없는 지연이 발생할 수 있습니다. 세 사람에게 요청을 "처리"하도록 요청하면 각 사람은 다른 팀원이 응답할 것으로 기대할 수 있습니다. 나는 각 작업에 대해 한 명의 소유자를 할당하는 것을 선호합니다. 그 사람이 작업의 모든 부분을 완료할 필요는 없습니다. 소유자는 요청을 추적하고 다음 단계를 확인하며 필요할 때 도움을 요청합니다. 간단한 작업 기록에는 다음이 포함될 수 있습니다. - 고객 또는 프로젝트 이름 - 작업 설명 - 담당자 - 필수 정보 - 다음 작업 - 목표 날짜 - 현재 상태 이를 통해 팀은 다른 메시지를 보내기 전에 확인할 수 있는 한 곳을 제공합니다. ### 답변 기준을 설정하세요. 고객이 항상 즉각적인 답변을 기대하는 것은 아닙니다. 그들은 자신의 메시지가 올바른 사람에게 전달되었는지 알아야 합니다. 짧은 답변으로 불확실성을 줄일 수 있습니다: > "요청을 접수했으며 제품 세부정보를 확인하는 중입니다. 정보가 확인되면 업데이트를 보내드리겠습니다." 이 메시지는 팀이 지킬 수 없는 약속을 하는 것이 아닙니다. 이는 고객에게 무슨 일이 일어나고 있는지, 다음에 무엇을 기대할 수 있는지 알려줍니다. 나는 다양한 요청 유형에 대해 서로 다른 응답 표준을 사용합니다. 제품 관련 문의사항은 영업일 기준 1일 이내에 답변이 필요할 수 있습니다. 사용자 정의 프로젝트에는 더 긴 검토가 필요할 수 있습니다. 표준은 업무, 팀 규모, 고객 요청 유형과 일치해야 합니다. ### 반복되는 승인 단계 제거 승인은 품질을 보호할 수 있지만 승인 지점이 너무 많으면 일상적인 작업이 느려질 수 있습니다. 어떤 결정에 관리자가 정말로 필요한지 검토합니다. 가격이 알려진 표준 주문에는 맞춤 계약과 동일한 검토가 필요하지 않을 수 있습니다. 작은 콘텐츠 변경에는 여러 사람이 승인할 필요가 없을 수도 있습니다. 팀은 다음과 같은 명확한 규칙을 만들 수 있습니다. - 표준 가격은 승인된 가격표를 따릅니다. - 맞춤 할인은 관리자의 검토가 필요합니다. - 안전 또는 규정 준수 관련 질문은 지정된 전문가에게 문의하세요. - 정기적인 고객 업데이트는 작업 소유자가 보낼 수 있습니다. 이러한 규칙은 사람들이 더 많은 위험을 수반하는 결정을 검토하면서 대기 시간을 단축하는 데 도움이 됩니다. ### 고객 정보를 한 곳에 보관 정보가 이메일, 채팅, 종이 노트, 개인 파일에 분산되면 지연이 시작되는 경우가 많습니다. 나는 여러 위치에서 고객 요청을 기록하는 소규모 서비스 팀에서 일한 적이 있습니다. 한 직원이 최신 배송 메모를 가지고 있었습니다. 또 다른 고객의 변경 요청이 있었습니다. 제3자가 가격 승인을 받았습니다. 팀은 고객에게 서비스를 제공하는 것보다 검색하는 데 더 많은 시간을 소비했습니다. 공유 기록으로 문제의 일부가 해결되었습니다. 각 요청에는 최신 메시지, 합의된 세부정보, 미결 질문, 다음 조치가 포함되었습니다. 팀에는 복잡한 시스템이 필요하지 않았습니다. 공유 스프레드시트나 작업 보드만으로도 작업 흐름이 충분했습니다. 도구는 업데이트하는 습관보다 덜 중요합니다. ### 짧은 지연 확인을 사용하세요. 주간 검토를 통해 더 많은 고객에게 영향을 미치기 전에 문제를 밝힐 수 있습니다. 나는 네 가지 질문을 합니다. - 어떤 작업이 이동되지 않았습니까? - 어떤 정보가 빠졌나요? - 누가 결정을 기다리고 있나요? - 고객이 업데이트를 받았나요? 검토는 비난이 아닌 행동에 초점을 맞춰야 합니다. 작업이 열려 있으면 팀은 명확한 설명을 통해 작업을 완료할지, 계획을 변경할지, 종료할지 결정할 수 있습니다. 짧은 일일 확인은 많은 실시간 요청을 처리하는 팀에 적합할 수 있습니다. 장기 프로젝트의 경우 주간 점검이 더 효과적일 수 있습니다. 올바른 리듬은 작업에 따라 다릅니다. ### 고객에게 변경 사항을 조기에 알리십시오. 업데이트가 늦어지면 고객이 아무 소식도 듣지 못할 때 더 큰 좌절감을 느끼게 됩니다. 배송 날짜가 변경되면 이해하기 쉬운 말로 이유를 설명하고, 새로운 예상 날짜를 공유하고, 다음으로 가능한 옵션을 제안합니다. 나는 “곧”이나 “최대한 빨리”와 같은 모호한 표현을 피합니다. 명확한 날짜는 고객에게 유용한 정보를 제공합니다. 예: > "요청한 부품은 공급업체에서 아직 확인 중입니다. 현재 예상 배송일은 5월 18일입니다. 해당 날짜가 귀하의 일정에 맞지 않으면 다른 모델을 확인할 수도 있습니다." 이러한 유형의 메시지는 기업이 지원할 수 없는 주장을 하지 않고 고객의 시간을 존중합니다. ### 고객에게 영향을 미치는 지연을 측정합니다. 팀에는 많은 보고서가 필요하지 않습니다. 몇 가지 유용한 측정 방법을 통해 주의가 필요한 부분을 확인할 수 있습니다. - 평균 응답 시간 - 견적 요청부터 전송된 견적까지의 시간 - 승인 대기 중인 작업 수 - 고객 후속 조치 수 - 완료 후 재개된 요청 수 수치는 팀이 프로세스를 개선하는 데 도움이 됩니다. 직원에게 성급하거나 불완전한 답변을 보내도록 압력을 가하는 데 사용해서는 안 됩니다. 응답 시간이 짧다는 것은 고객이 잘못된 세부 정보를 받고 업체에 다시 문의해야 하는 경우 거의 의미가 없습니다. ### 사람들이 따를 수 있는 프로세스를 구축하세요. 가장 좋은 프로세스는 팀이 실제로 일하는 방식에 맞는 프로세스입니다. 단계를 짧게 유지합니다. 1. 요청을 녹음합니다. 2. 소유자를 확인하세요. 3. 누락된 정보를 확인하세요. 4. 다음 동작을 설정하세요. 5. 필요할 때 고객에게 업데이트하십시오. 6. 결과가 확인되면 작업을 종료합니다. 나는 서면 계획에만 의존하기보다는 실제 요청을 통해 프로세스를 테스트합니다. 사람들이 한 걸음도 건너뛰면 왜냐고 묻습니다. 문제는 불분명한 표현, 누락된 도구 또는 가치를 추가하지 않는 단계일 수 있습니다. 지연은 종종 느린 직원보다는 약한 핸드오프를 나타냅니다. 핸드오프 문제를 해결하면 팀 전체가 더 자신감 있게 대응하고 고객에게 더 명확한 경험을 제공하는 데 도움이 될 수 있습니다. 더 자세히 알고 싶으십니까? 언제든지 Wang Xiaoying에게 연락하세요: xindahheavy@gmail.com/WhatsApp +8618437869999.

Project Management Institute 2021 프로젝트 관리 지식 체계 가이드 PMBOK 가이드 Harold D Kerzner 2022 프로젝트 관리 계획 일정 수립 및 통제에 대한 시스템 접근 방식 Eliyahu M Goldratt 1997 핵심 체인 Martin Christopher 2016 물류 및 공급망 관리 James P Womack 및 Daniel T Jones 2003 린 사고(Lean Thinking) 회사에서 낭비를 없애고 부를 창출하십시오 Robert G Cooper 및 Andréa Sommer 2018 Agile Stage Gate 하이브리드 모델: 유망한 새로운 접근 방식과 새로운 연구 기회