프로젝트란 무엇인가?
프로젝트의 특징을 이해하자
프로젝트의 정의
이 책에서는 프로젝트의 정의를 지금 현재 상태인 as is에서 원하는 상태인 to be로 만들기 위해 진행하는, 시작부터 목표까지 이어지는 여러 가지 업무라고 정의한다. 예를 들어, 새로운 고객을 확보하고 매출을 늘리기 위해 전자상거래 앱을 개발하여 출시하거나, 번거로운 사무 작업의 효율화를 위해 업무 시스템을 개발하는 것과 같은 프로젝트가 많은 기업에서 이루어지고 있다.
프로젝트의 본질적 특성이란?
프로젝트 실패율이 높은 이유는 프로젝트의 세 가지 본질적인 특성에서 기인한다.
- 시작과 목표가 정해져 있다.
- 불확실한 요소가 많다.
- 서로 다른 입장과 전문성을 가진 사람들이 각자 분업하여 참여한다.
시작과 목표가 정해져 있다
예를 들어, 사업을 진행하는 회사에서 업무 효율화를 위한 시스템을 도입하는 프로젝트의 경우, 다음과 같은 흐름으로 프로젝트가 진행된다.
1. 기획: 프로젝트의 기획 의도와 필요성을 검토한다.
2. 견적: 업체에게 견적을 받아 비용과 일정을 확인한다.
3. 결재(사내 합의): 비용 대비 효과와 일정의 타당성 등을 검토하고, 사내 결재를 통해 업체에게 발주한다.
4. 프로젝트 계획: 프로젝트 계획을 수립하고 프로젝트를 시작한다.
5. 요구사항 정의: 요구사항 정의와 디자인을 수행하여 개발할 시스템의 큰 틀을 잡는다.
6. 설계: 설계를 수행하고, 시스템 사양을 구체화한다.
7. 구현: 시스템을 구현하고, 추가 요구사항 및 사양을 처리한다.
8. 테스트: 테스트하여 시스템이 제대로 구현되었는지 확인한다.
9. 출시: 사전에 결정된 절차에 따라 배포 및 현장 도입을 실시한다.
10. 유지보수 개선: 시스템이 제대로 작동하도록 유지보수를 하고, 기능 등을 개선한다.
프로젝트를 진행할 때는 시작부터 목표까지의 흐름 중에서 ‘지금 어느 단계에 있는지’를 의식해서 매니지먼트하도록 하자.
프로젝트는 불확실한 요소가 많다
프로젝트를 진행하다 보면 처음에는 모호했던 것들이 작업과 시행착오를 통해 명확해져 간다. 예를 들어, 시스템 개발 안건의 기획 검토 시, 발주자의 아이디어가 A4 용지 한 장에 조목조목 나열되어 있거나 첫 미팅에서 구두로 ‘아이디어’를 상담하는 경우는 흔한 일이다.
그런 상태에서 시작된 프로젝트도 시작부터 끝까지 진행하다 보면 제품이나 이를 기반으로 한 사업이 점차 구체화되어 간다.
또한, 추진하는 기획 내용에 따라서는 프로젝트 멤버 전원이 그 업무나 기술을 처음 접하는 경우도 드물지 않다. 예를 들어, 수주 개발로 시스템을 구축하는 경우, 그 시스템이 이용되는 현장의 업무를 처음에는 전혀 모르거나, 이제 막 나온 새로운 기술을 사용하여 시험적으로 제품을 만드는 일도 흔한 일이다. 프로젝트에서 완전히 동일한 업무나 기술을 멤버가 이미 경험한 적이 있는 경우는 극히 드물다.
서로 다른 입장과 전문성을 가진 사람들이 각자 분업으로 참여한다
예를 들어, 업무 시스템 개발 프로젝트에는 프로젝트 매니저 외에도 다음과 같은 다양한 업무 및 다양한 입장과 전문성을 가진 사람들이 참여한다. 입장이나 전문성이 바뀌면 주요 관심사도 바뀌게 되는데, 이러한 서로 다른 관심사를 가진 사람들이 수행하는 작업을 잘 연결하는 것이 프로젝트 매니저에게 요구된다.
- 발주(발주자)
경영자 및 경영진: 프로젝트의 QCD에 관한 결재권한을 가진 사람
발주 담당자: 프로젝트 진행 및 QCD를 관리하는 사람
업무 담당자: 시스템을 사용하여 업무를 수행하는 사람
- 벤더(위탁 개발)
영업: 발주자와 주로 청구 관련 업무를 담당하는 사람
디자이너: 화면의 디자인을 작성하는 사람
프런트엔드 엔지니어: 화면 구현을 담당하는 엔지니어
백엔드(서버 사이드) 엔지니어: 데이터베이스나 서버 사이드 프로그램 등을 담당하는 소프트웨어 엔지니어
인프라 엔지니어: 서버의 구축을 담당하는 엔지니어
테스터: 시스템이 예상한 대로 동작하는지를 확인하는 사람
프로젝트의 어려움이란?
프로젝트의 전체 그림에 대한 구성원들의 공유가 부족한 경우
프로젝트에는 서로 다른 입장과 전문성을 가진 사람들이 각자 분업으로 참여한다. 입장이나 전문성이 다르면, 같은 프로젝트라고 해도 사람에 따라 다르게 보일 수 있다.
예를 들어, 시스템 요구사항이나 사양이 예산이나 납기 측면에서 비현실적인 것이 되거나, 화면 디자인이 기술적으로 구현이 불가능하거나 작업량이 많이 소요되는 형태로 바뀌는 등의 문제가 발생하게 되는 것이다.
이러한 전문 영역의 차이를 방지하고 더 나은 시스템을 만들기 위해서는 프로젝트 매니저가 다양한 관점에서 프로젝트 전반을 정리하고, 문서를 기반으로 프로젝트 구성원들 간의 인식을 일치시켜야 한다.
또한, 개발할 시스템 자체의 전체적인 그림뿐만 아니라 도입될 업무와 조직 전체에서 어떻게 활용될 것인지에 대한 포지셔닝 파악도 필수적이다. DX나 업무 개선 프로젝트에서 현장 인터뷰를 해보면, 대부분의 사람들은 자신이 관여하는 업무에 대해서는 잘 알지만, 옆 부서의 사람들이 매일 무엇을 하고 있는지, 조직 전체적으로 업무가 어떻게 조합되어 돌아가는지 자세히 알지 못한다는 것을 알 수 있다.
따라서 업무 흐름을 개선하거나 시스템 및 툴을 도입할 때, ‘조직 전체적으로 무엇을 어떻게 효율화해야 하는지’를 전체적으로 파악하여 개선을 추진하는 사람이 필요하다. 즉, 조직에 프로젝트가 어떻게 기여할 수 있는지를 전체적인 관점에서 검토하고 정리하는 것도 프로젝트 매니저의 역할이다.
관계자들(발주자/벤더/구성원/관련 기업)이 대등하게 논의할 수 있는 관계성 구축이 안되어 있는 경우
우리나라에서는 아직도 ‘돈을 지불하는 사람이 제일 높다’는 생각이나 ‘직급이 높은 사람이 말하는 것이 항상 옳다’는 생각이 남아 있어 발주자나 상사가 고압적이 되거나, 벤더나 프로젝트 멤버가 비굴해지는 경우가 있다.
그러나 그렇게 되면 불편한 사실을 숨기거나 의견을 말하기 어려워지고, 결과적으로 프로젝트가 실패하는 원인이 된다.
각자의 입장과 전문성을 살려야만 다양한 관점이 생겨 불확실성이 높은 프로젝트도 성공할 수 있다. 이를 가능케 하는 환경을 조성하기 위해서라도, 프로젝트 관계자들 간에 상하관계가 아닌 파트너십을 구축하여 항상 의견과 새로운 발견을 공유할 수 있도록 해야 한다.
프로젝트 매니저가 바쁘거나 능력이 부족하여 전체적인 시야를 잃고 있는 경우
프로젝트 매니저는 항상 해야 할 일이 많기 때문에 매우 바빠서 체력도 기력도 빨리 소모하게 된다. 그중에서 주의해야 하는 것이 ‘파악할 수 있는 프로젝트의 규모’와 ‘자기 자신이 수행할 작업과의 거리감’이다.
사람의 주의력과 사용 가능한 시간은 한정되어 있다. 그리고 무엇보다도 프로젝트 매니저는 항상 정상적인 판단을 내릴 수 있도록 멘털을 정상으로 유지하는 것이 프로젝트 성공에 필수 불가결하다.
요구사항 정의
프로젝트가 실패하는 원인의 약 50%가 요구사항 정의
실현해야 할 것을 결정하는 단계
요구사항 정의란 프로젝트에서 실현해야 할 것, 즉 요구사항을 결정하는 것이다. 기업 간에는 여기서 결정한 요구사항이 약속이 되기 때문에 신중하게 진행해야 하는 단계다.
특히 IT 제품은 눈에 보이지 않는 소스 코드나 전문 용어와 표현이 사용된 자료를 다루기 때문에 요구사항의 불완전성을 발견하기 어려운 경향이 있다. 테스트에 들어가서 제품을 만져본 관계자들로부터 ‘이렇게 될 줄 몰랐다’는 불만이 제기되는 프로젝트가 많은데, 대부분의 경우 요구사항 정의가 불충분한 것이 원인인 경우다.
‘요구’와 ‘요구사항’을 구분한다
실현하고 싶은 것과 실현해야 할 것은 다르다
요구사항 정의에서 흔히 저지르는 실수는 ‘발주자나 의사결정권자의 요구’와 ‘프로젝트 요구사항’을 혼동하는 것이다. 요구는 ‘실현하고 싶은 것’이지만, 요구사항은 ‘실현해야 할 것’이기 때문에 그 의미가 다르다.
이를 혼동한 채로 요구사항 정의를 진행하면 요구를 전달한 쪽은 나중에 ‘아, 말했는데 안 해줬잖아?’라는 심리가 생겨 프로젝트의 여유가 없어졌을 때 문제가 발생할 수 있다.
진행 방법의 포인트는 발주자나 상사로부터 ‘요구’를 정리하여 구체적으로 검토를 진행함으로써 ‘요구사항’을 도출해내는 것이다. 구체적인 테크닉으로는 엑셀 등으로 ‘요구’와 ‘요구사항’의 컬럼을 구분하여 관계자에게 공유하면서 검토를 진행하면, 자연스럽게 구분이 명확해지기 때문에 추천한다. 이때 요구의 항목은 ‘--하고 싶다’라는 표현으로 하고, 요구사항의 항목은 ‘--한다’라는 표현으로 한다.
결정해야 할 사항을 일정의 관점에서 파악한다
필요 최소한의 요구사항 판단하기
요구사항 정의는 정리하기 어려운 단계이기 때문에 충분한 시간을 갖는 것이 이상적이다. 그러나 실제 프로젝트에서는 예산과 일정의 틀이 정해져 있어 충분한 시간을 확보하기 어려운 경우가 많다. 예를 들어, ‘비즈니스상의 이유로 6개월 안에 신규 사업에서 핵심이 되는 새로운 서비스를 출시해야 한다’는 프로젝트에서는 요구사항 정의에 사용할 수 있는 기간이 고작 1~2개월 정도밖에 되지 않아, 그 안에서 원래 채워야 할 요구사항을 모두 채우는 것이 어려운 경우가 많다.
이럴 때 필요한 것은 원래 채워야 할 요구사항 중에서 반드시 요구사항 정의 단계에서 채워야 할 요구사항과 이후 단계에서 채워야 할 요구사항을 구분하고, 관계자에게 이를 이해시키는 것이다. 요구사항에는 프로젝트의 뼈대가 되는 것들이 있는데, 이러한 요구사항은 애매모호한 상태인 채로 프로젝트를 진행하거나 미흡한 검토로 인해 나중에 변경하거나 하면 프로젝트 전체에 큰 영향을 끼칠 수 있다.
실현하고자 하는 것(What)의 축과 개요를 그린다
여기서는 일반적인 ‘시스템 요구사항 항목’을 나열한다. 시스템 요구사항에 대한 좋은 책이 많이 있으므로 필요에 따라 참고하면 좋을 것이다. 시스템 요구사항에서 검토한 내용은 설계 단계에 이어져 보다 세밀하게 검토하게 된다.
시스템 아키텍처
시스템 아키텍처는 제품이 서버, 데이터베이스, 로드밸런서 등 어떤 인프라 구성에서 동작할 것인지, 연동 시스템은 어디에 있는지를 도식화하는 방법이다. 제품에서 구체적으로 어떤 기술을 이용할 것인지, 그때 어떤 포지션의 전문가가 필요한지 파악하기 위해 활용한다.
기능 요구사항 목록
기능 요구사항 목록은 제품이 어떤 기능을 가지고 있는지를 나열한 것이다. 요구사항 정의에서 많은 기능 관련 요구사항이 제시되는 경우가 많기 때문에 초기 개발 프로젝트에서는 QCD 관점에서 무엇을 필수 기능 요구사항으로 선정하는 것인지가 가장 중요한 고려사항 중 하나다. 기능 요구사항만으로는 우선순위나 필수 여부를 판단하기 어렵기 때문에 업무 요구사항과의 밸런스나 필요한 공수와 관련해서 검토하는 편이 좋다.
화면 전환도
화면 전환도는 제품에 어떤 화면이 있는지, 그리고 그 화면들이 어떻게 연결되어 있는지를 그림으로 보여주는 방법이다. 제품의 화면 수와 기능 목록은 견적에 큰 영향을 미치므로 요구사항 정의의 비교적 초기 단계에서 작성하는 것이 좋다.
시퀀스 다이어그램
시퀀스 다이어그램은 사용자의 작업, 프로그램, 데이터 처리의 흐름과 개요를 그림으로 표현하는 방법이다. 시퀀스 다이어그램은 초기 개발 설계 시뿐만 아니라 유지보수 운영 및 개선 시에도 시스템의 세부 사항을 파악하기 위해 이용한다. 특히 업무 시스템에서는 여러 시스템이나 서브시스템에 걸친 데이터 처리가 존재하는 경우가 많기 때문에 이에 대한 인식을 명확히 하는 것이 핵심이다.
ER 다이어그램/테이블 정의서
ER 다이어그램(Entity-Relationship Diagram, ERD)과 테이블 정의서(table specification)는 제품에서 사용하는 데이터를 어떻게 구조화하는지를 정의하는 방법이다. 화면이나 기능, API에서 이용하는 데이터를 적절히 추출할 수 있는지, 범용성이나 확장성이 확보되어 있는지를 염두에 두고 구조화를 실시한다.
API 목록
API 목록은 제품에서 어떤 API를 이용할지 목록화한 것이다. 개발할 제품의 화면이나 연동하는 시스템이 어떤 데이터인지 검토하여 목록화한다. 또한, 외부에서 제공하는 API가 어떤 것이 있는지도 파악해 두어야 한다.
합의된 사항을 문서화한다
가능한 한 ‘그림으로 표현한다.’
잘 고려한 요구사항 정의는 요점만 적는 것도 가능하지만, 그것만으로는 누락이 발생하기 쉽다. 특히 업무나 IT와 같은 ‘눈에 보이지 않는’ 것들의 요구사항을 정리할 때는 가능한 한 그림으로 표현하도록 하자.
그림이라고는 했지만 개념도나 흐름도에는 일러스트레이션과 달리 ‘그림 실력’이 필요하지 않으며, 회의에서 이야기하면서 화이트보드나 miro 등의 온라인 툴로 그리는 것만으로도 충분하다. 추상적인 개념을 그림으로 표현하는 것에 익숙해지는 것이 좋다. 예를 들어, 업무에 관한 검토는 플로 차트로 설명하면 공통된 인식을 쉽게 얻을 수 있으며, 요구사항 정의의 검토와 정리도 원활하게 진행된다.
또한, 그림으로 작성하면 ‘검토해야 할 사항의 전체 이미지’나 ‘검토가 누락된 요구사항’도 쉽게 알 수 있다. 요구사항 정의에서는 종종 ‘이렇게 똑똑한 사람들이 모여 있는데 왜 이렇게 중요한 검토가 빠졌을까’라는 사태가 발생한다. 이는 말로만 검토를 진행하여 전체 그림을 확인하지 않은 것이 원인이다.
슬라이드 생성 툴로 작성하지 않는다
요구사항 정의 자료를 파워포인트와 같은 슬라이드 작성 툴로 작성하는 경우를 많이 볼 수 있는데, 필자는 다년간의 경험을 통해 이를 지양하는 것이 좋다고 생각한다. 슬라이드 작성 툴은 자료의 페이지 가로 세로 사이즈에 제한이 있어, 요구사항 정의에서 이루어지는 다양한 검토의 과정과 결과를 남길 수 없기 때문이다.
요구사항 정의 자료는 많은 전제 조건과 검토 과정을 거쳐 결정된 사항을 기재하는 것이므로 결론뿐만 아니라 검토 과정과 다른 자료와의 연관성을 반드시 기재할 필요가 있다. 나중에 동일한 검토를 하거나 요구사항을 잘못 인식하여 시간 낭비와 혼란을 방지하기 위함이다.
조직의 보안 규칙이나 신청 절차에 따라 Visio, draw.io, Lucidchart, miro, Whimsical, Cacoo 등 개념을 그림으로 정리할 수 있는 툴을 찾아두면 요구사항 정의에 많은 시간을 할애할 수 없는 프로젝트에서도 효율적으로 작업할 수 있을 것이다.
‘올바른 그림 표기법’보다 ‘내용 전달이 잘 될 수 있는 자료’
흐름도나 시스템 아키텍처 등은, UML 등의 ‘올바른 그림 표기법’이 많이 존재한다. 처음 업무 흐름도를 그리는 경우에는 그러한 올바른 그림 표기법을 배우는 것이 도움이 되지만, 실제 프로젝트에 적용할 때는 그것에 집착하지 않는 것 또한 중요하다.
‘올바른 그림 표기로 그려진 자료’는 그것을 읽을 때도 파악할 수 있는 능력이 필요하다. 자료의 작성자와 수신자 사이에 문해력의 격차가 있으면, 결과적으로 중요한 정보가 누락되어 아무도 제대로 파악하지 않은 채 형식적으로 승인하는 등의 사태가 발생한다.
자료의 완성도가 60% 정도 되었을 때 내부 관계자에게 보여줌으로써 부족한 부분을 확인하여 실전에서 실패하는 것을 방지하자.
before(As Is)/after(To Be) 작성하기
요구사항 정의에서 또 하나 빠지기 쉬운 포인트로는, ‘어떻게 해야 하는지(after/ToBe)’는 어느 정도 명확해졌어도 ‘지금 어떻게 되어 있는지(before/Asls)’가 명확하지 않다는 점이다.
완전히 새로운 제품을 만드는 경우는 필요 없지만, 업무 개선이나 제품 리뉴얼 등을 할 때는 ‘지금 어떻게 되어 있는지’가 매우 중요하다.
업무 개선의 시스템 도입에서 실패하는 사례로 ‘지금 현재 어떻게 되어 있는지’를 제대로 파악하지 못하여 해당 프로젝트로 인한 영향이 예상치 못한 결과로 이어지는 경우가 종종 있다.
