국내에서 두 개 이상의 프로젝트를 한 모든 프로젝트 매니저는 이 상황을 경험했을 것이다. 회사의 영업 사원이 흥분해서 고객과 체결한 계약을 건네며 프로젝트가 또 이루어졌다고 주장하지만, 계약 (또는 위탁서) 을 들고 있을 때, 프로젝트에 관한 범위는 몇 줄의 글자에 불과하거나, 몇 줄의 상투적인 말이거나, 단지 프로젝트에 어떤 모듈이 포함되어 있을 뿐, 구체적인 업무에만 관한 것이다. (윌리엄 셰익스피어, 템플릿, 템플릿, 서비스, 서비스, 서비스, 서비스, 서비스, 서비스, 서비스) 그렇다면, 또 다른 경우, 프로젝트 과정에서 고객은 이전 시스템에 대한 변경 사항을 끊임없이 제기합니다. 더욱 화가 난 것은, 몇몇 문제들이 변하기 시작했다는 것이다. 어느 날, 고객이 갑자기 상황이 잘못되었다는 것을 알게 되어 당신이 고치게 되었습니다. 고객의 요구는 영원히 끝이 없는 것 같다. 프로젝트 주도자는 이런 실망스러운 상황에 어떻게 대처해야 합니까? 1. 왜 고객 수요가 과도하게 팽창합니까? 프로젝트의 주도자로서 정해진 시간 내에 한정된 자원으로 프로젝트를 완성하여 회사와 최종 고객을 만족시키는 것은 프로젝트 팀의 신성한 책임이다. 그러나 고객을 만족시키기 위해서, 우리는 그들의 모든 요구를 만족시켜야 합니까? 고객의 요구를 지속적으로 만족시키기 때문에 프로젝트가 실패할 경우 어떻게 합니까? 이러한 원인을 찾기 위해서는 먼저 이러한 문제의 근본 원인을 찾아야 한다. 1. 계약서에 서명할 때 프로젝트 범위를 명확하게 설명하지 않았습니다. 이것은 가장 흔한 문제 중 하나이며, 바로 초기의 이러한 문제들이 프로젝트 팀의 충분한 중시를 불러일으키지 않아 후기 프로젝트의 수정이 끊이지 않고 있다. 2. 고객 및 프로젝트 팀은 서면 문서의 요구 사항에 대해 서로 다른 이해를 가지고 있습니다. 이런 상황도 흔하다. 고객이 프로젝트 팀이 제출한 프로젝트 범위 설명서를 확인했고 프로젝트 팀이 본 문서에 명시된 대로 완전히 완료되었지만 고객은 여전히 변경을 요구하고 있습니다. 프로젝트 팀이 문서 한 장을 들고 고객과 대질했을 때, 고객도 이 요구를 인정했지만, 고객의 인식은 프로젝트 팀의 인식과 완전히 달랐다. 간단한 예: 고객이 시스템에 전자 서명을 요청했고, 프로젝트 팀 구성원은 하나를 시뮬레이션하여 시스템에 고객의 서명을 자동으로 생성했습니다. 그러나 고객에게 건네줄 때 고객이 요청한 전자 서명은 실제로 원래의 자필 서명 작업을 전자 시스템에 이식하여 지도자가 파일에서 도면을 통해 자필 서명을 생성할 수 있도록 하려는 것임을 알게 되었습니다! 때로는 처음의 약간의 소홀로 인해 프로젝트 후기의 대량 수정이나 지연이 초래될 때가 있다. 3. 고객이 팔기 전에 항상 모든 것을 남김없이 하려는 원래의 의도가 있다. 일반적으로, 프로젝트가 닫히기 전에, 고객은 프로젝트가 닫히면 프로젝트 팀 구성원을 찾아 업무 시스템을 수정하는 것이 어렵다고 생각하기 때문에, 프로젝트 팀을 강제로 해결할 수 있는 방법을 강구할 것이다. (윌리엄 셰익스피어, 프로젝트, 프로젝트, 프로젝트, 프로젝트, 프로젝트, 프로젝트, 프로젝트, 프로젝트, 프로젝트) IT 회사의 유동성이 강하기 때문에 나중에 계약자를 찾을 수 있다 해도, 당초 프로젝트를 했던 프로젝트 팀 멤버가 반드시 있을 필요는 없거나, 업무가 바빠서 이미 판매업자의 고객을 소홀히 한 회사도 많다. 4. 프로젝트 팀 구성원은 항상 무조건 고객에게 양보하고, 고객도 요구가 있으면 반드시 들어준다. 이러한 접근 방식의 출발점은 고객을 완전히 만족시키기 위한 것이지만, 실제로는 반드시 목적을 달성하지 못할 수도 있습니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 성공명언) 일반적인 고객 요구는 바닥이없는 것이며, 종종 전체 프로젝트에 많은 부정적인 영향을 미칠 수 있습니다. 물론, 우리가 고객의 요구를 지나치게 통제한다면, 고객은 분명 만족하지 못할 것이다. 둘째, 위의 프로젝트 문제와 그 원인을 해결하고, 이전의 일부 프로젝트의 교훈과 경험을 결합하면, 다음 몇 가지가 고객의 수요가 과도하게 팽창하는 문제를 효과적으로 차단하여 프로젝트를 더욱 아름답게 만들 수 있다고 생각합니다. 예방 조치: 프로젝트 시작 시 명확한 프로젝트 목표와 범위를 설정하고 주요 이해 관계자 (가장 중요한 것은 물론 최종 고객) 가 확인하도록 해야 합니다. 어떤 방식으로 프로젝트를 받든 프로젝트 매니저로서 프로젝트 초반에 세 단계로 갈 수 있다. 가장 먼저 떠오르는 질문은' 왜' 즉 고객의 프로젝트 목적이 무엇인가 하는 것이다. 이를 이해하면 향후 업무에서 고객이 어떻게 생각하는지, 프로젝트 방향이 잘못되는 것을 피하고, 결국 윈윈을 이루기 위해 노력할 수 있다. (윌리엄 셰익스피어, 윈윈, 윈윈, 윈윈, 윈윈, 윈윈, 윈윈, 윈윈) 왜' 를 알게 된 후, 우리는' 무엇을 해야 하는지' 를 아주 잘 알아야 한다. 비교적 좋은 방법은 한두 마디의 간결한 말로 전체 프로젝트를 요약하는 것이다. 프로젝트의 모든 하위 임무를 이렇게 요약할 수 있고, 프런트 데스크 업무원과 백그라운드 R&D 인원이 이해할 수 있도록 하여 프로젝트 감독이 대범하게 프로젝트의 내용에 대해 잘 파악하고 있음을 알 수 있다. 마지막으로 어떻게 해야 할지 잘 생각해야 한다. 익숙하지 않은 프로젝트에도 이 단계가 중요하다. 이 단계에서 더 많은 에너지를 소비하는 것은 절대적으로 가치가 있다. 물론, 상황에 따라 수요 조사의 이 단계에서 불필요한 작업을 단순화할 수 있으므로 프로젝트 관리자는 서로 충돌하는 프로젝트 목표의 균형을 맞출 수 있어야 합니다. 실제 업무에서는 프로세스가 필요합니다. 요구 사항을 정리하고 문서를 작성한 후에는 프로젝트 팀 구성원이 먼저 자신이 요약한 요구 사항을 고객에게 상세히 알리도록 하는 것이 좋습니다. 실제 운영에서 이 접근 방식은 프로젝트 인력과 고객의 업무 차원에서 모호한 문제를 크게 줄일 수 있을 뿐만 아니라 잠재적인 문제를 잘 식별하고 의사 소통 기술을 습득할 수 있어 계약자의 중시를 더욱 깊이 느낄 수 있습니다. 또한 프로젝트 전 수요자가 기술에 대해 매우 무지한 경우, 실제 상황에 따라 고객에게 수요를 제출하기 전에 R&D 담당자와 소통하여 불필요한 약속을 피하고 작업량을 보다 정확하게 정의하는 것이 좋습니다. 결론적으로, 프로젝트 범위를 효과적으로 계산하는 데는 시간이 걸리지만 자원과 자금을 절약하고 수요 (범위) 변화와 같은 프로젝트의 향후 두통을 해결할 수 있습니다. 또 한 가지 주목할 만한 문제는 프로젝트의 요구가 몇 번 확인되면 실력 있는 고객이 명확하게 확인하도록 하는 것이 좋으며, 서면으로 서명하는 것이 가장 좋다는 것이다. 이 설득력 있는 문서는 고객의 향후 수요 변화에 좋은 역할을 할 것입니다. 분명히, 고객이 서명했기 때문에, 항상 번복하여 반드시 손해를 볼 것이다. 업무 변화로 인해 프로젝트를 대폭 조정해야 하는 경우에도 프로젝트 팀은 유리한 위치에 있으며 자신의 회사에 대해 불만을 품지 않을 것이다. 물론, 고객들에게 이러한 이해심 많은 요구들은 향후 제품 납품의 근거가 될 것이며, 불필요한 의구심을 해소할 수 있을 것이다. (윌리엄 셰익스피어, 템페스트, 희망명언) 이것은 쌍방 모두에게 동등한 구속력을 가지고 있어 매우 유리하다. 유연성: 변경 사항이 발생하면 고객과 자주 의사 소통해야 합니다. 프로젝트가 이미 최종 단계에 이르렀을 때, 고객이 갑자기 새로운 수요를 제시하거나 기존 수요에 대한 수정을 요구하면 프로젝트 관리자는 당황하게 된다. 한편으로는 고객의 요구를 최대한 만족시켜야 하고, 다른 한편으로는 시스템에 너무 많은 변경을 할 수 없고, 진도에 영향을 줄 수 없다. 이 상황은 수요 단계와 관련이 있으며 구현 과정에서 고객과 긴밀하게 접촉하지 않고 의사 소통이 부족하다는 것을 보여줍니다. 고객의 심리에서 분석하다. 소프트웨어의 특수성 때문에 고객은 보통 후기 서비스를 매우 중시하는데, 특히 국내에서는 사람들이 하는 소프트웨어의 대부분이 실제 업무와 밀접한 관련이 있다. 프로젝트 관리자로서 프로젝트 과정에서 고객을 소홀히 한 다음, 마지막에 납품할 때 갑자기 고객과 많은 접촉을 하는 것은 매우 금기시된다. 이후 실행 과정에서 문제가 발생할 가능성이 높으며, 이전에 고객에 대해 상대적으로 익숙하지 않아 큰 위험을 초래할 가능성이 높습니다. 보다 안전한 접근 방식은 프로젝트 과정에서 프로젝트 팀이 고객과 연락을 유지하고, 서로 이해하고, 보다 조화로운 커뮤니케이션 분위기를 조성하고, 향후 주요 이행 이전 단계에서 고객과 발생할 수 있는 충돌을 준비하는 것입니다. 흥미롭게도, 프로젝트 진행 과정에서 단계적으로 프로젝트 진행 상황을 고객에게 제시하여, 고객이 프로젝트에 대해 더 직접적이고 직관적으로 이해하고, 문제를 조기에 발견하고 해결하며, 후환을 피할 수 있도록 합니다. 지속적인 커뮤니케이션을 통해 고객은 프로젝트 팀이 항상 고객의 시각에 서 있다는 것을 깨닫게 되고, 고객의 주요 책임자는 자신이 프로젝트 팀의 중요한 일원임을 깊이 인식하게 되며, 영광과 굴욕을 함께 나누며, 프로젝트 팀은 고객에게 완벽하고 지속적인 후속 서비스를 제공할 수 있습니다. 비록 선행 작업이 아주 잘하더라도, 많은 경우 수요 변화도 불가피하다. 프로젝트 책임자는 원활한 의사 소통 메커니즘을 통해 변경 사항과 발생할 수 있는 변경 사항을 적시에 파악합니다. 일단 변화가 생기면 프로젝트 팀은 반드시 냉정하게 이러한 문제를 처리해야 한다. 일반적으로 먼저 제품 분석-> 비용/이익 분석-> 대안-> 전문가의 판단에 따라 요구 사항 변화를 평가하고, 가능한 한 빨리 프로젝트 범위 변화에 대한 서면 설명을 만들어 향후 프로젝트 의사 결정의 근거로 삼을 수 있습니다. 물론, 보험 비교는 고객이 명확한 변경 사항 (서명이 최선의 선택) 을 확인할 수 있도록 하는 것입니다. 특히 변경이 가져올 수 있는 작업량 증가를 평가한 후 고객이 과도한 변경으로 인해 프로젝트가 연기될 수 있다는 사실을 인식하게 하는 것이 고객의 책임입니다. 고객이 수요 변화를 제기할 때 반드시 일정한 의사소통 기술을 습득해야 하며, 항상 무조건 고객을 수용하는 것은 아니다. 일반적으로 고객은 익숙하지 않습니다. 그들은 매우 간단한 일이 프로젝트 팀의 불필요한 정력을 많이 소모할 수 있다고 생각하기 때문에, 고객이 말한 것이 반드시 그가 원하는 것이라고 생각하지 마라! 대부분의 고객은 첫 순간 머릿속에서 갑자기 튀어나온 불꽃이기 때문에 프로젝트 팀 멤버들은 고객이 어떤 목적을 달성하고 문제의 본질을 파악하고자 하는지 냉정하게 분석해야 한다. 일반적으로 고객의 본질적인 요구를 실현하는 방법에는 여러 가지가 있습니다. 고객과의 의사 소통에서 고객과의 대립은 반드시 피해야 한다. 처음에는 고객의 의견을 잘 듣고 "어떻게 생각하세요?" 와 같은 질문을 많이 합니다. " 고객이 자신의 생각을 분명히 한 후, 프로젝트 팀 구성원은 고객의 건의를 신속하게 평가하는 것이 가장 좋다. 만약 실시가 너무 어렵다면, 그들은 고객에게 좀 더 적절한 건의를 할 수 있고, "이것이 효과가 있을 것 같습니까?" 라고 더 많이 물어볼 수 있습니다. 사실 같은 목적을 달성할 수 있다. "마지막으로, 고객과의 의사 소통 결론을 확인하는 중요한 프로세스가 있습니다. 결론적으로, 전체 프로젝트 관리는 서로 충돌하는 프로젝트 목표의 균형을 맞추는 능력입니다. 간단해 보이지만 사실은 복잡하다. 프로젝트 과정에서 프로젝트 책임자는 일반적인 변경 사항을 통제하고, 고객 수요의 무분별한 팽창을 통제하고, 프로젝트가 건강하고 안정적으로 진행될 수 있도록 하는 방법을 배워야 합니다. 1. 프로젝트가 시작되면 회사는 새 프로젝트 단계의 시작을 승인합니다. 2. 범위 계획을 준비하는 과정에서 프로젝트에서 해야 할 일을 설명하는 규범을 마련합니다. 3. 범위 정의에서 프로젝트의 주요 부분은 더 작은 부분으로 나뉩니다. 4. 범위 감사에서 항목의 범위를 받아들여야 합니다. 5. 범위 변경 관리에서 시간이 지남에 따라 항목 범위 변경을 감시할 필요가 있습니다.