현장 중심의 프로젝트 매니지먼트

현장 중심의 프로젝트 매니지먼트 - 24년 경력 PM이 알려주는 실전 프로젝트 매니지먼트의 모든 것
하시모토 마사요시 지음, 정인식 옮김 / 제이펍 / 2024년 11월

'이 리뷰는 컬처블룸을 통해 출판사에서 도서를 제공 받아, 직접 읽고 작성한 리뷰입니다.'

프로젝트 매니저먼트 를 알아보기

책을 선택한 이유

프로젝트 매니지먼트 는 성공적인 프로젝트 를 목표로 움직이는 활동이다.

프로젝트 매니지먼트 에 대해 알아보기 위해

"현장 중심의 프로젝트 매니지먼트"를 선택한다.

"현장 중심의 프로젝트 매니지먼트"는

0장 서론 : 프로젝트 매니지먼트 스킬의 전체 개요

1장 프로젝트란 무엇인가: 기본적인 지식과 사고방식을 파악하자

2장 협상: 적절한 파트너십을 구축하자

3장 작업 매니지먼트: 팀워크로 일하자

4장 프로젝트 계획: 목표 및 진행 방식을 결정하자

5장 견적: 필요한 비용과 일정을 예상해보자

6장 계약: 불리한 조건을 피하자

7장 요구사항 정의: 해야 할 것을 결정하자

8장 디자인: 고객이 진짜 필요로 하는 것을 추구하자

9장 설계: 전문가에게 건넬 배턴을 만들자

10장 테스트: 사업 리스크를 최소화하자

11장 출시: 돌다리도 두드리며 건너자

12장 유지보수/개선: 사업 성공으로 이어지도록 하자

로 구성되었다.

0장 서론 : 프로젝트 매니지먼트 스킬의 전체 개요 에서는

실제 현장에서 발휘할 수 있는 역량은 일을 해보지 않고서는 보장할 수 없다.

프로젝트 매니지먼트 를 체계적으로 습득하고 정확하게 전수할 수 있는

시니어급 프로젝트 매니저는 드물다.

프로젝트 매니저 육성에 있어서 사전 교육이 없는 OJT가

유효하게 기능하는 사례는 매우 적다.

현실의 프로젝트에 적용하기 쉽고 체계화된 구체적이고 일반적인 노하우 가 필요하다.

프로젝트 매니저로서의 자신의 스킬 을 냉정하게 분석하기 위해

업무 수행 능력을 정확하게 파악할 필요가 있다.

1장 프로젝트란 무엇인가: 기본적인 지식과 사고방식을 파악하자 에서는

프로젝트 는 현재 상태에서 원하는 상태로 만들기 위해 진행하는

시작부터 목표까지 이어지는 여러 가지 업무다.

프로젝트 의 목적은 최종 도달점이고, 목표는 달성해야 할 기준이다.

시작과 목표가 정해져 있고, 불확실한 요소가 많으며,

분업하여 참여하면서 프로젝트 실패율이 높다.

프로젝트 의 본질적 특성을 파악한 후 적절히 정리해 나갈 수 있어야 한다.

각 구성원이나 관계자들이 서로 다른 판단 기준과 이해관계를

가지고 있기 때문에, 프로젝트 매니저 는 다양한 관점에서

프로젝트 전반을 정리하고 문서를 기반으로 프로젝트 구성원들 간의

인식을 일치시켜야 한다.

시니어급 프로젝트 매니저 는 프로젝트 에 어떤 위험이 있는지

신중하게 고려해야 한다.

프로젝트 계획 및 견적 시 관리 화면 구축에 대한 관점을 놓치지 않고,

시스템 연동에 필요한 요구사항을 프로젝트 계획 시점부터 주의해야 하며,

요구사항 정의나 설계, 구현이 정말 타당한 것인지 판단해야 한다.

프로젝트 매니저 는 자신의 책임을 수행한다는 의식을 가지고,

관계자와 함께 해결해 나가는 자세를 가져야 한다.

프로젝트 매니지먼트 는 본질적인 특성으로 발생하는 리스크 를

피하기 위한 핵심이다.

2장 협상: 적절한 파트너십을 구축하자 에서는

프로젝트 매니지먼트 는 사람, 물건, 돈의 전체 균형을 QCD 관점에서

바라보고, 조정하면서 프로젝트 를 진행하는 것이다.

프로젝트 전체를 적절하게 진행한다는 점에서,

완벽주의는 부정적으로 작용할 수 있다.

정기적으로 의견 청취의 기회를 마련하고,

커뮤니케이션 수단을 구분해서 사용하며,

설명 자료와 회의록을 문서화 하고,

상담 내용 및 결정사항은 관계자들과 공유하며,

포메이션을 구성하여 협상한다.

설명할 때는 근거를 바탕으로 사실에 기반해서 이야기 하고,

어려운 협상은 최소한으로 줄이고 필요한 것을 명확히 해서

이해를 얻기 위해 노력해야 한다.

설명할 때는 근거를 바탕으로 사실에 기반해서 이야기 하면

심리적 부담을 줄일 수 있다.

어려운 협상은 최소한으로 줄이고, 프로젝트 를 적절하게

완료하기 위해 필요한 것이 무엇인지 명확히 해서,

이해를 얻기 위해 노력해야 한다.

QCD 조정에 관한 협상은 프로젝트 전체에 영향을 미치므로,

대응 방침은 회사 간에 이야기하기 전에 조직 내에서

합의가 이루어지도록 한다.

3장 작업 매니지먼트: 팀워크로 일하자 에서는

작업 매니지먼트 를 통해 프로젝트 가 적절하게 목표를 향해

나아가고 있는 확인하면서 통제한다.

작업 매니지먼트 는 프로젝트 의 목적 달성을 위해

작업을 지휘하는 것이다.

직무형 사고는 작업을 해내는 것이 동기 부여가 되는 마인드 다.

직무형 고용이란 직무의 내용에 따라 필요한 경험-스킬을 가진

인재를 고용하는 제도다.

멤버십형 고용은 직종이나 업무 내용을 지정하지 않고,

기업이 특정 부서에 배치하는 것을 전제로 고용하는 제도다.

멤버십형 사고의 멤버 가 있으면 작업이 중단되어

전체에 큰 지연이 발생할 수 있으므로, 프로젝트 에는

적합하지 않다.

작업 수행에 대한 동기 부여가 낮은 구성원이 있다는 사실을 발견하면,

즉시 상급자에게 보고 및 의견을 전달해야 한다.

프로젝트 시작 후 멤버 변경을 실시하면 심리적 저항이 적은 반면,

어느 정도 진행된 상태에서 실시하면 심리적 저항이 강해진다.

작업 도출하기, 작업을 수행할 우선순위 정하기,

작업 의뢰, 정기적 리뷰 순으로 작업 매니지먼트 를 수행한다.

4장 프로젝트 계획: 목표 및 진행 방식을 결정하자 에서는

프로젝트 계획은 프로젝트 리스크 와 목표, 기본적 진행방식을

관계자들과 합의하는 과정이다.

불안감을 없애고 프로젝트 에 관련된 사람들이 일치 단결하여

진행할 방향성을 제시하기 위해, 프로젝트 계획을 의식적으로

신속하게 작성해야 한다.

의견 청취는 프로젝트 핵심 관계자로부터 요구사항을 듣는 단계부터 시작된다.

프로젝트 의 목적이나 전제 조건 등 나중에 바꾸기 어려운 조건을

우선적으로 확인한다.

프로젝트 조직 체계는 프로젝트 전체의 조직 체계를 말한다.

프로젝트 조직 체계는 한 번 굳어지면 재구성이 매우 어렵다.

의사결정권자가 누구인지, 얼마나 이해하고 있는지를

의견 청취 시에 대화로 확인해 두는 것이 좋다.

프로젝트 진행에 리스크 가 될 수 있는 마인드 를 가진 사람이

없는지 조기에 확인해야 한다.

업무 배정은 프로젝트 실행 팀을 결정하는 과정이다.

인력 조달에 시간이 걸리고, 공백이 생기기 때문에,

프로젝트 계획 시점에 미리 소집을 해 두어야 한다.

벤더 선정시 독자적인 제안이 포함되어 있지 않으면,

좋은 프로젝트 가 되지 않을 가능성이 있다.

프로젝트 목적은 실현하고자 하는 하는 것의 근간이

무엇인지를 확인하는 것이다.

프로젝트 가 진정으로 지향해야 할 목적이 무엇인가를 확인하는 것은

프로젝트 를 올바른 방향으로 이끌기 위해 반드시 필요한 과정이다.

프로젝트 의사결정은 QCD, 품질-비용-납기 기준에 따라 결정한다.

QCD 우선순위를 프로젝트 계획 시에 확인해 두지 않으면

의사결정자 사이에서 각 기준의 충족에 대한 기대치가

당초보다 크게 높아져 협상이 어려워질 수 있다.

회의 일정은 생산성과 효율성이 크게 저하될 수 있기 때문에

신중하게 고려해야 한다.

시스템 개발 프로젝트 는 워터폴 개발, 애자일 개발 중 하나를 선택한다.

애자일 개발은 짧은 기간에 반복적으로 요구사항 정의, 설계,

구현, 테스트 를 반복적으로 수행하여 제품의 품질을 향상시키는

방법의 총칭이다.

스크럼 개발은 개발 팀 이 일정 기간 동안에 반복적으로 개발 하면서,

화면이나 기능의 구현을 결정하고, 품질을 향상시키는 개발 기법이다.

신속한 의사결정, 프로젝트 구성원의 높은 요구 수준,

외부 시스템이나 서브시스템과의 시스템 연동,

프로젝트 전체의 예산과 일정 조정 등 전제 조건을 충족해야 한다.

프로젝트 계획 시 일정을 제시할 때 마일스톤 을 설정해,

미리 발주자나 사내 의사결정권자에게 정기적으로 보고할 것을

프로젝트 계획 시점에 알려야 한다.

프로젝트 계획은 프로젝트 가 길을 잃지 않도록 준비하는 필수적 계획이다.

5장 견적: 필요한 비용과 일정을 예상해보자 에서는

견적은 공수를 추정하고 비용과 일정을 짜는 것이 철칙이다.

프로젝트 매니저 에게는 견적을 통해 비즈니스 의 현실과

프로젝트 의 현실을 맞추어 나갈 것을 요구하는 셈이다.

개략적 견적은 불확실성이 많은 단계에서 제출하는 견적이다.

개략적 견적은 버퍼를 예상하여 높게 제시하는 편이 좋다.

불확실성을 다루는 프로젝트 에는 고도의 전문 지식과

풍부한 경험이 필요하기 때문에, 저렴한 견적 금액만

중시하는 것은 바람직 하지 않다는 인식을 가져야 한다.

상세 견적은 요구사항 정의나 설계로 불확실성을

상당히 제거한 상태에서, 제시하는 견적이다.

개략적 견적으로 전체적인 비용에 대한 짐작을 공유하면서,

상세 견적에는 이를 보다 공고히 하여 예산을 확정해 나간다는

개념을 가지고 있으면 좋다.

프로젝트 목표를 실현하기 위해 누가 무엇을 해야 하는지를

세분화하여 구성원의 태스크 수준까지 분해한다.

견적서의 명세 내역에는 대응 항목별로 공수와 단가를 명기하여

기재해 두면 더 신뢰하게 된다.

프로젝트 버퍼 는 예상치 못한 상황이 발생할 경우 추가 공수다.

버퍼 를 합산해두지 않으면, 도급 계약 시에 쉽게 적자가 날 수 있다.

공수를 산출했으면 일정상에 기입해 가시화한다.

견적에서 공수는 온전히 작업에 사용할 수 있는 것을 전제하므로,

현실과 괴리가 생길 수 있다.

견적서는 발주자 측이나 사내에서 일방적으로 독주할 가능성이

높다는 점을 유념해 견적의 종류와 명세 내용을 상세히 기재하고,

공수에 프로젝트 버퍼 를 포함해 두도록 한다.

6장 계약: 불리한 조건을 피하자 에서는

계약서는 프로젝트 진행 시 책임과 의무를 명시하는 중요한 서류다.

도급계약은 발주자에게 성과물을 납품하고, 성과물에 대한 대가를 지급받는다.

위탁 계약은 발주자를 대신하여 수행한 전문적인 노무의 대가를 지급받는 것이다.

산출물에 무엇을 적느냐에 따라 프로젝트 의 부담이 크게 달라진다.

산출물은 고객이 검수를 했을 때, 계약 내용과 다를 경우에는

무상으로 대응해야 하는 계약 불이행에 대한 대응이 발생하게 된다.

검수가 문제없이 완료된 것으로 보는 기준이 중요하다.

검수 조건, 합의 사항을 문서화 해 두지 않으면, 무보수 대응을

계속 강요받아 큰 손실을 보게 된다.

계약상 부적합은 계약 내용에 적합하지 않은 것을 말한다.

불이익을 당하지 않도록 체결 시 기재 내용을 꼼꼼히 확인하고,

계약 완료 시에는 요구가 계약상 부적합에 해당하는지 확인해야 한다.

손해배상책임이 천정부지로 치솟는 경우에는 상한액을 기재하도록 한다.

발주자가 사내용으로 리스크 해지 를 했다는 증거를 남기는 의미에서

필요할 수 있다.

위탁 계약은 노동에 대해 보수를 지급하는 계약이기 때문에,

불투명성이나 부당하게 보수를 받으려는 것이 아니냐는

의심을 불러일으키기 쉬운 경향이 있다.

어느 정도의 기간과 공수를 투입하면 어떤 성과를 얻을 수 있는지

자료 샘플이나 프로젝트 계획, 업무 보고서 샘플로 조기에 보여주면서,

돈을 지불해야 하는 이유를 납득시키는 것이 중요하다.

도급 계약은 산출물의 완성 의무가 있는데 반해,

위탁 계약은 업무를 위임받은 측에 성실 의무가 있다.

위탁 계약은 발주자를 대신하여 전문적인 업무를

수행하고 있다는 것을 잊지 말고 프로페셔널 한 자세로

업무에 임해야 한다.

위장도급, 결제 기한과 지불 방법, 발주자의 입회 감사 등을

도급 계약과 위탁 계약에서 체크해야 한다.

7장 요구사항 정의: 해야 할 것을 결정하자 에서는

요구사항 정의는 프로젝트에서 실현해야 할 것을

결정하는 것이다.

발주자나 상사로부터 요구를 정리하여 구체적으로 검토를 진행하며,

요구사항을 도출해내는 것이다.

요구사항 정의 단계에서 채워야 할 요구사항과 이후 단계에서

채워야 할 요구사항을 구분하고, 관계자에게 이해시키는 것이다.

프로젝트 관계자와 우선적으로 채워 나가야 하는 요구사항을

상호 인식하여 서로 협력하면서 정해나가도록 한다.

프로젝트 목적을 명확히 하는 것은 사업에서 프로젝트 의

위치를 명확히 해 투자 판단을 할 수 있도록 할 뿐만 아니라

프로젝트 구성원의 동기를 부여하고 유지한다는 의미에서도

매우 중요하다.

프로젝트 에서 실현하고자 하는 것의 축과 개요를 그리며,

지식과 경험이 요구된다.

요구사항 정의에서 합의된 사항은 반드시 문서화해야 한다.

그림으로 표현하고, 슬라이드 작성 툴로 작성하지 않으며,

내용 전달이 잘 될 수 있는 자료 작성, 지금 어떻게 되어 있는지

확인하기 등 합의 사항을 문서화 해야 한다.

커뮤니케이션 기법으로는 대응이 어렵다고 생각되는

요구사항 변경이나 추가 요구사항도 일단 받아들이고,

프로젝트 관점에서 체크하여 처리할 수 있도록 한다.

8장 디자인: 고객이 진짜 필요로 하는 것을 추구하자 에서는

발주자나 의사결정자의 모호한 이미지 를 구체화하고,

디자인적 요소와 기능의 균형을 맞추는 것은 어려운 작업이다.

디자인 시에는 UI, UX를 모두 의식할 필요가 있다.

업무 시스템 개발이 주 업무인 논리적 성향의

프로젝트 매니저 는 디자인의 매니지먼트 가

적절한 프로세스 를 통해 합리적 디자인으로 완성할 수 있다.

페르소나 를 만들어 누구를 대상으로 만들고 있는지

명확히 하면 합의가 잘 이루어질 수 있다.

사용자 인터뷰 는 사용자의 감각이 맞지 않는지

체크할 때 매우 유용하게 작용한다.

시각적 아이덴티티 는 시각적 통일감을 주기 위해

로고, 폰트, 색상 세트 등을 정하는 작업이다.

로고 의 방향성은 말로 전달하는 것도 좋지만,

디자이너 에게 의도를 가장 쉽게 전달할 수 있는 방법은

실제 샘플을 보여주는 것이다.

로고, 폰트, 톤 & 매너 등 시각적 아이덴티티 가

어느 정도 정해진 다음 페르소나 와 함께 자료로 정리해두면,

개선할 때 프로젝트 자산으로 유용하게 사용할 수 있다.

프로세스 로는 고객의 경험을 전체 이미지 로 디자인 하면서,

화면 등 세부적인 부분을 세밀하게 다음어 나가는 흐름이다.

유사한 제품의 UI/UX 학습, 제품의 주요 화면과 기능 검토,

검토 내용의 UI 반영 절차를 거쳐 디자인을 시작한다.

프로토타이핑 은 요구사항 정의 자료나 설계서 등에서

어려운 표현으로 프로젝트 를 진행하는 것보다,

훨씬 압도적으로 관계자를 끌어들일 수 있다.

9장 설계: 전문가에게 건넬 배턴을 만들자 에서는

설계 는 사양을 결정하는 것이다.

납기 기간이 짧은 경우나 대규모 개발의 경우

여러 전문가가 설계를 담당하게 되므로,

설계의 모순이나 실수가 발생하지 않도록

정보나 의사결정의 공유에 대한 체계를 마련해 두어야 한다.

기술 스택 은 제품을 제작할 때 사용하는 기술의 조합이다.

개발을 진행하는 방법을 팀에서 합의해 둔다.

설계서를 어느 수준까지 정확하게 기재해야 하는가는

받아들이는 쪽의 수준에 따라 크게 달라진다.

정밀도를 확인했으면 설계도를 작성한다.

기술 부채는 주먹구구식 소프트웨어 아키텍처 와

여유가 없는 소프트웨어 개발이 초래하는 결과를 의미한다.

작업 결과물을 리뷰하면서 사양 정의, 설계서 간 일관성

확보를 확인한다.

단순하더라도 필요 최소한의 설계는 하는 것이 좋다.

설계는 문서화가 중심이 되어야 한다.

설계가 끝나면 구현 작업을 할당하여 작업을 진행한다.

10장 테스트: 사업 리스크를 최소화하자 에서는

테스트 는 가능해야 할 일이 실제로 가능한지 확인한다.

테스트 에서 최소한으로 수행해야 할 것은 무엇인지

제대로 파악하는 것이 프로젝트 매니지먼트 의 핵심이다.

테스트 가 무엇인가에 대한 인식을 공유할 필요가 있다.

테스트 는 결함이 없다는 것을 증명할 수는 없다.

모든 가능성을 테스트 하는 것은 불가능하다.

전체 기능을 체크하는 종합 테스트 단계가 아닌

구현 단계에서 끝내는 것이 핵심이다.

결함은 일부에 국한되는 것이 일반적이다.

테스트 에서 무엇을 확인할 것인가를 고려해야 한다.

같은 테스트 도 상황이 바뀌면 결과가 달라질 수 있다.

제한된 공수로 어떤 결함을 처리해야 하는지는

매우 중요한 판단이 필요할 수도 있다.

사용성 테스트 는 구현한 소프트웨어 가 사용하기 쉬운지

확인하는 테스트 다.

게재 정보 체크 는 정보나 이미지 오류를 확인하는 작업이다.

단위 테스트 는 처리나 기능을 개별적으로 테스트하며,

결합 테스트 는 여러 개의 관련 처리나 기능에 관한 테스트 다.

회귀 테스트 는 프로그램 수정에 예상치 못한 영향이 발생하는지

다시 한번 확인하는 테스트 다.

종합 테스트 는 소프트웨어 가 제대로 구현되었는지 전반적으로

확인하는 테스트 다.

연동 테스트 는 개발한 소프트웨어 가 연동해야 할 다른 시스템 과

서로 잘 연동하여 동작하는지 확인하는 테스트 다.

부하 테스트 는 실제 운영시 소프트웨어 가 부하를 견딜 수 있는지

확인하는 테스트 다.

취약성 테스트 는 소프트웨어 에 취약성이 있는지 확인하는 테스트 다.

설계 측면의 확인을 하는 경우에는 컨설팅 을 위탁할 수 있는 기업이나

전문가를 선정해야 한다.

승인 테스트 는 요구사항대로 소프트웨어 가 납품되었는지

확인하는 테스트 다.

테스트 주도 개발은 구현 시 테스트 코드 를 포함시킴으로써,

여러 번 포괄적 테스트 를 실시하는 공수를 줄이기 위한 개발 기법이다.

테스트 계획서 작성에 전념할 수 있는 사람을 지정한다.

테스트 전체를 관리할 사람을 두고, 대책을 추구하며,

결함 보고는 티켓으로 관리하며, 진헹 상황을 정기적 보고한다.

11장 출시: 돌다리도 두드리며 건너자 에서는

출시 일정은 관련 멤버 가동이 확실하게 확보될 수 있는 날을 선택한다.

출시 작업 자체를 담당하는 팀뿐만 아니라, 즉각적으로 문제에 대응하는

감시 체계도 고려해야 한다.

사전에 출시 계획을 세워 두어야 한다.

타임라인을 구분하여 대응 방안을 사전에 확인하고,.

컨틴전시 플랜 을 설명하고, 사전에 출시 계획을 공유한다.

리허설을 실시하여 출시 계획을 재검토하고,

출시 계획은 현장 레벨부터 대외적인 창구 담당자까지

사전에 설정해 두어야 한다.

12장 유지보수/개선: 사업 성공으로 이어지도록 하자 에서는

프로젝트 를 사업 목적의 성공으로 연결하기 위해서는

적절한 투자 판단을 할 수 있는 손익분기점 사고방식이 필요하다.

프로젝트 고정비, 프로젝트 변동비, 매출에 대해 알아본다.

죽음의 계곡 에 부딪혀 많은 신규 사업들이 좌절한다.

적절한 고객에게 적절한 상품을 제공하기 위해,

깔때기 모델 개념이 중요하다.

프로젝트 매니저 는 깔대기 모델 전체 프로세스 가

제대로 진행되고 있는지 관리한다.

프로젝트 를 사업에 직접적으로 기여할 수 있는 형태로

관리할 수 있는 프로젝트 가 되면,

더 높은 평가와 보수를 수반하는 중요한 포지션을 맡을 수 있게 된다.

프로젝트 매니지먼트 는 프로젝트 구성원들이 편하게 일할 수 있게

체계화된 기술을 사용하여 리스크 를 통제하는 프로페셔널 스타일 이다.

"현장 중심의 프로젝트 매니지먼트"

"현장 중심의 프로젝트 매니지먼트"는 프로젝트의 개요,

파트너십 구축 협상, 작업 매니지먼트, 프로젝트 계획,

견적, 계약, 요구사항 정의, 디자인, 설계, 테스트, 출시,

유지보수에 대해 다룬다.

프로젝트 매니지먼트 를 체계적으로 습득하고 정확하게 전수할 수 있는

시니어급 프로젝트 매니저는 드물다.

현실의 프로젝트에 적용하기 쉽고 체계화된 구체적이고 일반적인 노하우 가 필요하다.

프로젝트 는 현재 상태에서 원하는 상태로 만들기 위해 진행하는

시작부터 목표까지 이어지는 여러 가지 업무다.

프로젝트 의 목적은 최종 도달점이고, 목표는 달성해야 할 기준이다.

프로젝트 의 본질적 특성을 파악한 후 적절히 정리해 나갈 수 있어야 한다.

프로젝트 매니저 는 다양한 관점에서 프로젝트 전반을 정리하고,

문서를 기반으로 프로젝트 구성원들 간의 인식을 일치시켜야 한다.

프로젝트 매니저 는 자신의 책임을 수행한다는 의식을 가지고,

관계자와 함께 해결해 나가는 자세를 가져야 한다.

프로젝트 매니지먼트 는 사람, 물건, 돈의 전체 균형을 QCD 관점에서

바라보고, 조정하면서 프로젝트 를 진행하는 것이다.

설명할 때는 근거를 바탕으로 사실에 기반해서 이야기 하고,

어려운 협상은 최소한으로 줄이고 필요한 것을 명확히 해서

이해를 얻기 위해 노력해야 한다.

QCD 조정에 관한 협상은 프로젝트 전체에 영향을 미치므로,

대응 방침은 회사 간에 이야기하기 전에 조직 내에서

합의가 이루어지도록 한다.

작업 매니지먼트 는 프로젝트 목적 달성을 위해 작업을 지휘하는 것이다.

작업 수행에 대한 동기 부여가 낮은 구성원이 있다는 사실을 발견하면,

즉시 상급자에게 보고 및 의견을 전달해야 한다.

프로젝트 시작 후 멤버 변경을 실시하면 심리적 저항이 적은 반면,

어느 정도 진행된 상태에서 실시하면 심리적 저항이 강해진다.

프로젝트 계획은 프로젝트 리스크 와 목표, 기본적 진행방식을

관계자들과 합의하는 과정이다.

의견 청취는 프로젝트 핵심 관계자로부터 요구사항을 듣는 단계부터 시작된다.

프로젝트 조직 체계는 프로젝트 전체의 조직 체계를 말하며,

프로젝트 조직 체계는 한 번 굳어지면 재구성이 매우 어렵다.

업무 배정은 프로젝트 실행 팀을 결정하는 과정이다.

인력 조달에 시간이 걸리고, 공백이 생기기 때문에,

프로젝트 계획 시점에 미리 소집을 해 두어야 한다.

프로젝트 가 진정으로 지향해야 할 목적이 무엇인가를 확인하는 것은

프로젝트 를 올바른 방향으로 이끌기 위해 반드시 필요한 과정이다.

프로젝트 의사결정은 QCD, 품질-비용-납기 기준에 따라 결정한다.

QCD 우선순위를 프로젝트 계획 시에 확인해 두지 않으면

의사결정자 사이에서 각 기준의 충족에 대한 기대치가

당초보다 크게 높아져 협상이 어려워질 수 있다.

시스템 개발 프로젝트 는 워터폴 개발, 애자일 개발 중 하나를 선택한다.

프로젝트 계획 시 일정을 제시할 때 마일스톤 을 설정해,

미리 발주자나 사내 의사결정권자에게 정기적으로 보고할 것을

프로젝트 계획 시점에 알려야 한다.

프로젝트 계획은 프로젝트 가 길을 잃지 않도록 준비하는 필수적 계획이다.

견적은 공수를 추정하고 비용과 일정을 짜는 것이 철칙이다.

프로젝트 매니저 에게는 견적을 통해 비즈니스 의 현실과

프로젝트 의 현실을 맞추어 나갈 것을 요구하는 셈이다.

개략적 견적으로 전체적인 비용에 대한 짐작을 공유하면서,

상세 견적에는 이를 보다 공고히 하여 예산을 확정해 나간다는

개념을 가지고 있으면 좋다.

견적서의 명세 내역에는 대응 항목별로 공수와 단가를 명기하여

기재해 두면 더 신뢰하게 된다.

견적서는 발주자 측이나 사내에서 일방적으로 독주할 가능성이

높다는 점을 유념해 견적의 종류와 명세 내용을 상세히 기재하고,

공수에 프로젝트 버퍼 를 포함해 두도록 한다.

계약서는 프로젝트 진행 시 책임과 의무를 명시하는 중요한 서류다.

산출물은 고객이 검수를 했을 때, 계약 내용과 다를 경우에는

무상으로 대응해야 하는 계약 불이행에 대한 대응이 발생하게 된다.

검수 조건, 합의 사항을 문서화 해 두지 않으면, 무보수 대응을

계속 강요받아 큰 손실을 보게 된다.

손해배상책임이 천정부지로 치솟는 경우에는 상한액을 기재하도록 한다.

위탁 계약은 발주자를 대신하여 전문적인 업무를

수행하고 있다는 것을 잊지 말고 프로페셔널 한 자세로

업무에 임해야 한다.

요구사항 정의는 프로젝트에서 실현해야 할 것을

결정하는 것이다.

요구사항 정의 단계에서 채워야 할 요구사항과 이후 단계에서

채워야 할 요구사항을 구분하고, 관계자에게 이해시키는 것이다.

요구사항 정의에서 합의된 사항은 반드시 문서화해야 한다.

커뮤니케이션 기법으로는 대응이 어렵다고 생각되는

요구사항 변경이나 추가 요구사항도 일단 받아들이고,

프로젝트 관점에서 체크하여 처리할 수 있도록 한다.

디자인 시에는 UI, UX를 모두 의식할 필요가 있다.

페르소나 를 만들어 누구를 대상으로 만들고 있는지

명확히 하면 합의가 잘 이루어질 수 있다.

시각적 아이덴티티 는 시각적 통일감을 주기 위해

로고, 폰트, 색상 세트 등을 정하는 작업이다.

프로세스 로는 고객의 경험을 전체 이미지 로 디자인 하면서,

화면 등 세부적인 부분을 세밀하게 다음어 나가는 흐름이다.

프로토타이핑 은 요구사항 정의 자료나 설계서 등에서

어려운 표현으로 프로젝트 를 진행하는 것보다,

훨씬 압도적으로 관계자를 끌어들일 수 있다.

설계 는 사양을 결정하는 것이다.

설계의 모순이나 실수가 발생하지 않도록

정보나 의사결정의 공유에 대한 체계를 마련해 두어야 한다.

단순하더라도 필요 최소한의 설계는 하는 것이 좋다.

설계는 문서화가 중심이 되어야 한다.

설계가 끝나면 구현 작업을 할당하여 작업을 진행한다.

테스트 는 가능해야 할 일이 실제로 가능한지 확인한다.

테스트 에서 최소한으로 수행해야 할 것은 무엇인지

제대로 파악하는 것이 프로젝트 매니지먼트 의 핵심이다.

출시 일정은 관련 멤버 가동이 확실하게 확보될 수 있는 날을 선택한다.

출시 작업 자체를 담당하는 팀뿐만 아니라, 즉각적으로 문제에 대응하는

감시 체계도 고려해야 한다.

프로젝트 를 사업 목적의 성공으로 연결하기 위해서는

적절한 투자 판단을 할 수 있는 손익분기점 사고방식이 필요하다.

디지털화가 진행되면서, 프로젝트 는 기업에서 중요한 비중을 차지한다.

프로젝트 를 제대로 관리하지 못하면 비즈니스 에 심각한 타격을 입을 수 있다.

프로젝트 의 구조를 이해하고, 주요 포인트 를 세심하게 챙길 수 있어야

프로젝트 실패의 위험을 사전에 줄일 수 있다.

"현장 중심의 프로젝트 매니지먼트"는 프로젝트 를 이해하고,

프로젝트 에서 발생하는 문제점을 상세하게 기술하므로,

프로젝트 매니저 를 비롯한 프로젝트 관련자들이

성공적인 프로젝트 를 운영하기 위해 알아야 할 사항을 깨닫고

프로젝트 를 안정하게 유지할 수 있도록 한다.

프로젝트 실패는 엄청난 시간과 비용이 발생하게 되면서,

기업에 심각한 리스크 로 발생하게 된다.

프로젝트 매니지먼트 를 이해하고 철저하게 대비하면,

리스크 를 줄일 수 있다.

"현장 중심의 프로젝트 매니지먼트"는

프로젝트 매니저 경험을 바탕으로 한 매니지먼트 기법을 소개하면서,

프로젝트 를 성공적으로 구축할 수 있도록 돕는다.

제이펍 과 컬처블룸 서평단에서

"현장 중심의 프로젝트 매니지먼트"를 증정해주셨다.

감사드린다.

#현장중심의프로젝트매니지먼트 #제이펍 #개발방법론 #프로젝트관리

#24년경력PM이알려주는실전프로젝트매니지먼트의모든것 #하시모토마사요시

#정인식 #프로젝트매니저 #작업매니지먼트 #작업관리 #작업배치 #협상

#팀워크 #견적 #계약 #요구사항 #컬처블룸 #컬처블룸서평단