공공 프로젝트(SI) 착수 단계: 현직 PM의 완벽 가이드 (사업관리, 품질관리, 인력관리)

공공기관 SI 프로젝트, 삐걱거림 없이 시작하는 '착수 단계' 완벽 가이드! 

안녕하세요! 여러분의 든든한 수다쟁이 PM입니다! 👋 지난번 공공 프로젝트의 제안, 기술협상, 계약 과정까지 퀵~하게 알아봤는데요. 이제 드디어 프로젝트의 시작을 알리는 '착수 단계'이네요. 본격적인 프로젝트 수행의 첫걸음인 '착수 단계'인 만큼, 여기서부터는 깊게 파헤쳐 볼까 합니다! (어느 정도로 깊게 파야 할지 고심을 많이 했습니다. 우선은 최대한 경험 위주로 주요 내용을 짚고, 정말 깊게 파야 하는 부분은 별도로 떼서 용암이 흘러나올 정도로 깊게 파 보도록 하겠습니다. 🌋)

프로젝트 수주에 들뜨고, 프로젝트 팀원들, 그리고 고객들과 처음 보거나 오랜만에 만나 어색함이 가득한 시간. 마치 처음 소개팅 나간 자리 같죠? 이 시기는 특히 '업무 불평등'이 심화되는 시기입니다. 문서 관련 파트들은 커피 마실 시간도 없이 정신없이 바쁘고, 개발 파트들은 상대적으로 한가하게 느껴질 수 있죠. (부럽다...😂) 이 시기뿐 아니라 다른 시기에도 업무 불평등은 단계별로 계속 발생하겠지만, 착수 단계는 특히 더 심합니다. PM이 인력 투입에 대한 조정, R&R(Roles & Responsibilities)에 대한 명확한 정의, 그리고 상호 협업 방안을 제대로 만들지 않으면 프로젝트 내내 삐걱거리고, 심하면 중간에 좌초되는 불상사까지 발생할 수 있습니다. 이해관계자들 및 고객의 성향도 빠르게 파악해서 프로젝트의 기준을 빠르고 유연하게 정해야 합니다. 🚨 (전 처음에 뭘 해야 할지 몰라 고객에게 저만 정신없이 끌려다니고, 정신 차리고 보니 저만 일하고 프로젝트 팀은 엉망으로 돌아가는 걸 뒤늦게서야 깨달은 경험이... 🤦‍♀️)

 

<PM이 꼭 알아야 할 '단계별 업무 불평등' 타개법!>

위에서 프로젝트의 단계별로 바쁜 시기가 다르다고 했었는데요. 정리해보면 아래와 같습니다. (투입 인원들의 분류를 크게 사업관리(PM, QA, PMO) 파트와 PL, 그리고 수행팀(개발팀 및 H/W 구축팀 등)으로 나누어 보겠습니다.)

 

단계	사업관리	PL	수행팀
착수(사업 준비) 단계	매우 바쁨	보통	한가함
분석 단계	바쁨	바쁨	한가함
설계 단계	보통	매우 바쁨	한가함
구현 단계	한가함	바쁨	바쁨
시험 단계	보통	바쁨	바쁨
전개(오픈) 단계	바쁨	매우 바쁨	매우 바쁨
인도 단계	바쁨	바쁨	보통
완료(종료)	바쁨	보통	한가함

이를 고려해서 인력의 투입 시기를 조정하면 좋지만, 공공기관과 같이 인력의 투입이 유연하기 어려운 곳에서는 처음부터 모든 팀원이 투입되어 업무를 시작하는 경우가 많습니다. 즉, 단계별로 모두 업무 불평등이 발생하게 됩니다. 

저의 경우는 프로젝트를 시작할 때 팀원 모두에게 서로서로 도울 수 있는 '통로'를 만들고 도움을 요청합니다. 착수 단계부터 이런 통로를 만들고 실행해야 프로젝트 기간 동안 계속 서로 도우며 잘 마무리할 수 있게 됩니다. (이것이 바로 PM의 숨겨진 역량! ✨)

<잠깐! 공공 SI 개발 분류!>

SI 개발사업을 크게 세 가지로 구분하면 아래와 같습니다. 난이도는 차세대 > 신규개발 > 고도화 라고 알려져 있으나, 경험상으로는 프로젝트의 여러 상황별 영향이 더 크다고 봅니다. 하지만 PM 및 사업관리 그룹에서는 발생할 수 있는 위험요소가 다른 만큼 세 가지를 구분해서 다르게 접근해야 할 필요가 있습니다.

1. 신규 개발 사업: 기존에 없는 새로운 서비스를 만드는 사업입니다. 고객의 무한한 상상력을 조심해야 합니다. 🤯 아무것도 없는 상황에서 고객과 소통해야 하는 만큼 소통의 어려움이 존재합니다. 공공의 수직 체계상 사소한 부분에서 결정이 오래 걸릴 수 있으니, 메인 페이지부터 먼저 디자인 시안을 2~3개 정도 만들고, 고객의 승인을 받는 게 좋습니다.
2. 고도화 사업: 신규 개발 이후 4~6년 정도 운영/유지보수하면서 개선해야 할 기능이 쌓였을 때 진행합니다. 신규 사업에 비해 그래도 기준을 삼을 수 있는 화면이 있다는 장점이 있으나, 수년간 쌓여온 개선 요구 사항이 어마어마합니다. 그리고 현재 운영/유지 중인 소스를 수정하는 만큼, 유지보수 사업단과 소스 형상관리 부분에서 문제가 되는 경우가 많으니, '구현 단계' 이전에 유지보수 사업단과도 충분한 논의가 필요합니다.
3. 차세대 사업: 신규 개발 이후 보통 10~20년 동안 고도화를 진행하다가, 개발 언어나 플랫폼 등 기존 환경에서는 더 이상 유지가 어렵다고 판단될 때 전체 시스템을 새로 갈아엎는 대규모 사업입니다. 주관 부처별로 규모가 달라질 수 있으나 일반적으로 100억 이상의 사업으로 2~5년의 기간 동안 진행됩니다. 대규모 자원이 투입되는 만큼 많은 인원이 투입되어 작업을 하다 보니, 인력 관리와 소통의 문제가 더욱 크게 발생합니다. 

 

<용어 정리 - 아래 용어들은 알고 계셔야 합니다!>

• 착수계: 계약 체결 후 사업을 시작하겠다는 의지를 발주기관에 공식적으로 보고하는 문서 묶음입니다. 프로젝트 수행 계획, 인력 현황, 보안 서약서 등 사업의 첫 단추를 끼우는 데 필요한 모든 서류가 포함됩니다. 
• 사업수행계획서(사수계): 프로젝트의 나침반이자 설계도입니다. 계약 문서를 바탕으로 사업 범위, 추진 일정, 인력 및 장비 계획, 품질 보증, 위험 관리, 보안 대책 등 사업 수행의 모든 기준과 방법을 상세하게 명시하는 문서입니다. 
• 착수보고회: 사업수행계획서 내용을 바탕으로 발주기관에 사업의 시작을 공식적으로 알리고, 사업 내용, 추진 체계, 일정 등을 공유하며 상호 협의하는 자리입니다. 주로 PM이 PT 본을 만들어 발표합니다. 발표자료를 만들 시간이 부족하기에 대부분 경쟁 입찰 PT 자료를 조금 손봐서 보고하는 '재활용의 미학'을 보여주곤 하죠. 😉
• 워크샵 (Workshop): 특정 주제에 대해 심도 있게 논의하고 결과물을 도출하기 위한 회의 방식입니다. 착수 단계에서는 이해관계자 간의 관계 형성, 요구사항 심층 분석, R&R 및 협업 방식 논의 등을 위해 워크샵을 활용할 수 있습니다. 과거에는 펜션이나 호텔등을 빌려서 1박이나 2박을 하면서 진행하는 경우도 많았으나 현재는 대부분 회의실에서 진행합니다. 고객과의 워크샵도 중요하지만, 프로젝트 팀원들과의 워크샵다 필요합니다. 우리가 하는 일이 무엇인지와 목표, 위험요소는 무엇인지 까지도 팀원들에게도 명확하게 주지시켜주는 자리가 필요합니다.
• 킥오프 (Kick-off): 관련된 이해관계자들(특히 고객들) 간의 미팅 자리입니다. 고객을 포함해서 수행 인원들의 업무 및 얼굴을 익히는 자리라고 보면 됩니다. 착수보고회나 워크샵 이후에 회식처럼 진행하는 경우가 많습니다. (공공기관은 김영란법 시행 이후 주관기관에서 회식 비용을 내거나 주관기관 담당자들과, 사업자의 비용을 별도로 부담합니다. 이런 엄격함 덕분에 회사는 비용이 줄지만, '어색함 어택'은 늘죠... 😅 김영란법과 무관한 일반회사의 경우는 보통 수행사가 회식비를 냅니다)
• R&R (Roles & Responsibilities): 프로젝트 참여자 각각의 역할과 책임을 명확히 정의하는 것입니다. 업무 불평등을 줄이고 효율적인 협업을 위해 착수 단계에서 명확히 설정해야 합니다. (이거 안 정하면 "이건 네 일 아니야?" "응, 네 일~" 무한 핑퐁에 빠질 수 있습니다. 🏓) 프로젝트, 고객, 주관기관의 성향에 따라서 바쁜 파트가 달라지므로 잘 상황을 판단하고 업무를 조절하는 능력이 PM 의 필수 스킬입니다.
• 이해관계자 (Stakeholder): 프로젝트의 성공 또는 실패에 영향을 받거나 영향을 미칠 수 있는 모든 개인이나 그룹을 의미합니다. 고객, 팀원, 관련 부서, 유지보수 사업단 등 다양한 이해관계자의 니즈와 기대를 관리하는 것이 PM의 중요한 역할입니다. 
• 개인정보 영향평가 (PIA, Privacy Impact Assessment): 개인정보 처리 시스템을 구축하거나 변경할 때, 개인정보 침해 위험 요소를 분석하고 개선 방안을 도출하는 평가 제도입니다. 개발 사업에서는 개인정보를 취급 안 할 수가 없기 때문에 최근 공공의 모든 사업에서는 개인정보 영향평가가 필수라고 보면 됩니다. 
• 하도급 승인: 원사업자가 계약된 사업의 일부를 다른 사업자(하도급 업체)에게 맡길 경우, 발주기관의 사전 승인을 받아야 하는 절차입니다. 공공 프로젝트에서는 매우 중요하게 관리됩니다. 
• 개발 방법론 테일러링: NIA 가이드나 PMBOK 등 표준 개발 방법론을 프로젝트의 특성(규모, 기간, 기술 스택 등)에 맞춰 최적화하고 조정하는 과정입니다. 획일적인 적용보다는 유연한 적용이 필요할 때 활용합니다. 
• 소프트웨어 개발 보안 (시큐어 코딩): 소프트웨어 개발 과정에서 발생할 수 있는 보안 취약점을 최소화하기 위한 활동 및 기법을 총칭합니다. 착수 단계에서부터 보안 관리 계획을 수립하고 준수 방안을 제시해야 합니다. 

 

[[ 공공 프로젝트, '착수 단계' 핵심 활동 10가지! ]]

프로젝트의 착수 단계는 일반적으로 계약 체결 후 시작되며, 사업의 본격적인 수행을 위한 계획 수립 및 준비 작업이 이루어지는 매우 중요한 시기입니다. 이 단계에서 수행해야 하는 주요 활동들은 다음과 같습니다:

1. 착수계 제출 및 검토/승인:
   • 무엇을? 계약서에 명시된 바에 따라, 발주기관이 요구하는 법적 서류 및 사업수행계획서, 사업품질보증계획서, 역할 분담에 따른 발주기관 협조사항 등이 포함된 '착수계'를 제출합니다.
   • 언제? 계약 체결 후 10일 이내 (하도급 승인 시 3일 이내) 제출합니다.
   • 확인 사항: 계약책임자계, 보안확약서 및 서약서, 사업수행계획서, 산출내역서 등 모든 관련 서류가 누락 없이 포함되었는지 꼼꼼히 확인해야 합니다.
   • 프로세스: 발주기관은 제출 후 7일 이내에 검토하고, 미비 시 보완을 요구할 수 있으며, 사업자는 보완 요구일로부터 7일 이내에 재제출해야 합니다. 
2. 사업수행계획서 작성 및 승인:
   • PM의 나침반! 계약 문서를 바탕으로 사업 범위와 수행 방법의 기준을 제시하는 핵심 문서입니다. RFP, 제안서, 기술협상서 내용을 반영하여 작성합니다.
   • 필수 포함 내용: 사업 범위, 추진 일정, 인력/장비 투입 계획, 표준화 및 보안 대책, 공정/조직/인력/변경/산출물/위험/품질/보안 관리 방안, 개발 표준화 준수, EA 현행화 계획, 교육 계획, 발주기관 협조 요청사항 등이 상세히 명시되어야 합니다.
   • 승인: 공급자는 계약 체결 후 발주기관에 제출하고 검토·승인받아야 합니다. 
3. 착수보고회 진행:
   • 목적: 사업수행계획서 내용을 바탕으로 발주기관에 사업의 시작을 공식적으로 알리고, 사업 내용, 추진 체계, 일정 등을 공유하며 상호 협의하는 자리입니다. 모든 이해관계자가 모여 프로젝트의 목표와 방향성을 공유하고 동기를 부여하는 중요한 시간입니다. 
   • 준비: 개최 일정, 참석 범위, 진행 형태, 발표 자료 등을 발주기관과 협의하여 준비합니다. 필요하다면 워크샵 형식으로 진행하여 팀원 간, 고객과 수행사 간의 관계를 돈독히 하고, R&R 논의 및 협업 방안을 구체화할 수 있습니다.
   • 의무: 제안요청서, 제안서 등에 명시된 경우 반드시 수행해야 하며, 개최하지 않는 경우 '착수 보고서'로 대체하여 관리하고 승인을 받아야 합니다.
4. 초기 보안 조치 시행:
   • 보안은 생명! 공공 프로젝트의 가장 중요한 요소 중 하나입니다.
   • 보안 특약: 사업 계약 시 비밀유지 계약서, 개인정보 처리 위탁 계약서(개인정보 위탁 시) 등 보안 특약이 포함되었는지 확인합니다.
   • 보안 서약서: 용역 사업 참여 인원 전원은 보안 서약서를 작성 후 주관 기관에 제출해야 합니다.
   • 보안 관리 계획서: 사업 착수계 제출 시 필수 첨부 자료이며, 제안요청서 및 제안서 상의 보안 관리 항목을 모두 기술했는지 검토하고 미비점을 보완 요청합니다.
   • 하도급 보안: 하도급 계약이 있다면, 본 사업 계약 수준의 비밀 유지 조항이 하도급 계약서에 포함되었는지 반드시 확인해야 합니다.
   • 보안 교육: 사업 시작 전 참여 인원에 대한 비밀유지 의무 준수 교육을 실시하고 주관 기관의 확인을 받습니다.
5. 작업 장소 등 협의 및 준비:
   • 사업 수행에 필요한 작업 장소, 설비, 기타 작업 환경을 발주기관과 상호 협의하여 결정합니다. 보안 등의 이유로 인해 일반적으로 발주기관이 작업 장소를 제공합니다. 보안과 관련하여 여러 가지 복잡하고 시간이 걸리는 요소가 많으니 착수하자마자 바로 서두르세요. (6개월짜리 프로젝트에서 보안 문제로 망 연결하는 데 2달이 넘게 소요된 경험도 있습니다. 😤 )
6. 개인정보 영향평가 대상 검토 및 계획 수립:
   • 수행: 관련 가이드에 따라 영향평가를 수행하고 그 결과를 사업에 포함하여 구축 적용해야 합니다. 개인정보 처리 단계별(수집, 보유, 이용/제공, 위탁, 파기) 보호 조치 계획을 수립해야 합니다. 공공 소프트웨어 개발 사업의 경우 개인정보를 취급 안하는 경우가 거의 없기 때문에 대부분 개발사업에 개인정보 영양평가를 해야 한다고 보시면 됩니다. 정해진 외부업체에서 진행하며, 체크하는 항목 대부분이 개발에 대한 사항 보다는 보안담당자(고객)의 관리책임에 대한 부분이니 수행팀에서 크게 신경쓰실 부분은 없습니다. 
7. 하도급 승인 신청 및 관리 (하도급 시):
   • 사업 과업의 일부를 하도급하려는 경우, 발주기관으로부터 사전 승인을 받아야 합니다.
   • 계약 체결 시 소프트웨어 사업 하도급 계획서를 제출하고, 하도급 계약서에 본 사업 계약 수준의 비밀 유지 조항을 포함해야 합니다.
8. 개발 방법론 테일러링:
   • 방법론의 가이드들은 여러 개발 사업별로 상세히 분류하기 어렵기 때문에 모든 내용을 포함하고 있습니다. 즉, 현재 프로젝트에 맞는 맞춤 방법론 및 산출물은 고객과 테일러링을 통해 정해야 합니다. 이 단계에서 제대로 정의를 해 놓아야 추후 필요도 없는데 억지로 산출물을 만들어야 하는 문제를 예방할 수 있습니다.
   • 방법론은 해당 기관에 가이드가 있거나 RFP 상 명확하게 명시되어 있다면 해당 방법론을 가지고 진행하지만, 보통 그런 경우가 드물기 때문에 공공은 일반적으로 NIA의 CBD 방법론과 사업관리 가이드 방법론을 기반으로 테일러링을 진행합니다.
9. 데이터 이행 및 표준화 계획 수립 (기존 시스템 전환 시):
   • 기존 시스템에서 새로운 시스템으로의 데이터 추출 및 적재 절차, 전환 계획을 수립해야 합니다. 데이터 이행 시나리오 최적화, 단위 작업 튜닝 등을 통해 최종 이행 시간을 최소화하는 방안을 제시해야 합니다.
   • 데이터 이행 품질 확보 방안(GAP 분석, 매핑 정의서, 이관 프로그램 등) 및 정제 방안, 검증 방안을 제시합니다.
   • 데이터 표준화 방향 및 목표에 따라 표준화 대상, 범위, 추진 과제, 일정, 예산 등을 포함한 표준화 계획을 수립합니다. (표준용어, 도메인, 코드 등의 표준 수립 및 적용 관리 포함)
   • 데이터 표준화: '공공 데이터베이스 표준화 지침'에 따라 범정부 및 기관의 데이터 표준 지침 적용 여부를 검토하고 요구사항을 제시합니다. 데이터 구조 설계 및 검증, 관리 방안, 데이터 값 검증 방안, 데이터 표준/구조/값/개방 관리 체계, 메타데이터 등록 및 현행화 방안 등을 포함합니다. 기존 데이터가 표준화 되어 관리되거나 표준화용 TOOL 이 있다면 조금 낫지만 그렇지 않은데 RFP 상 "데이터 표준화" 항목이 있다면, 고객과 잘 협의 하여 표준화 범위를 정해야 합니다. 데이터 베이스 뿐 아니라 개발까지도 함께 영항을 미칠게 됩니다.
10. 품질 계획 수립:
    • 사업 품질 보증 계획을 수립하고, 개발 결과물에 대한 단계별 시험(단위, 통합, 시스템, 인수 시험)을 위한 시험 방법, 소요 자원, 일정 등 총괄적인 시험 계획을 수립합니다.
    • 테스트 환경 구성 및 테스트 데이터 확보 방안을 제시하고, 각 단계/작업별 산출물에 대한 품질 목표 달성 여부, 측정 지표, 체크 리스트 등을 기준으로 점검을 수행해야 합니다. (테스트... 이름만 들어도 눈꺼풀이 무거워지는 마법! ✨ 그래도 해야 합니다! 😇)
    • 소프트웨어 개발 보안(시큐어 코딩) 준수: 해당 사업인 경우 착수 단계에서 표준 코딩 스타일 정의, 적절한 개발 절차/방법론, 교육 계획 등 가이드 준수 방안을 제시해야 합니다. (출처: 소프트웨어 개발보안 가이드 2021.12.29)

이 외에도 사업 추진을 위한 제반 비용 (네트워크, 전기, 바닥 시설 공사 등) 처리 계획 수립, 사업 관련 문헌 구입 계획 수립, 산출물 디지털 형태 제작 관리 방안 제시, EA 현행화 계획 수립, 기술 이전 계획 제시 등이 착수단계 또는 그 계획에 포함되어야 할 활동입니다. (PM님, 할 일이 정말 많죠? 어깨 주물러 드리고 싶네요... 💆‍♀️)

 

착수 단계는 PM에게 '관료주의의 정점'처럼 느껴질 수도 있습니다. 😅 수많은 문서와 검토, 승인 절차들이 PM의 속을 뒤집어 놓을 때도 있죠. 하지만 이 모든 과정은 향후 프로젝트의 '안정적인 항해'를 위한 필수적인 기반입니다. 

제가 겪은 바에 따르면, 착수 단계의 핵심은 '완벽한 문서화'와 '선제적인 소통'입니다. 공공기관은 유독 문서가 많습니다. 모든 보고와 소통이 문서로 이루어 지기 때문에, 멋지게 잘만든 개발 소스보다 잘만든 문서로 칭찬받고 문서에 실수가 있으면, 페널티를 받기도 합니다. (다수의 공공기관에서 점('.') 하나 조차도 잘못 찍거나 안 찍었다고 테클 들어온 경우가 많답니다.  😇 )

1. 문서화는 '귀찮음'이 아닌 '방패'다!
   • 발주기관이 요구하는 모든 서류와 계획서는 "PM의 방패"라고 생각하세요. 완벽하게 준비된 문서는 나중에 발생할 수 있는 책임 공방이나 추가 요구사항에 대한 명확한 근거가 됩니다. 지금의 귀찮음이 미래의 평온함을 가져다줄 거예요! 
   • 모든 문서는 최악의 상황에서 쓰일 증거라고 생각하는 게 좋습니다. 
   • 회의록은 그중에서도 가장 중요합니다. 고객마다 선호하는 회의록의 스타일이 다르니 고객과 잘 협의하셔서 서식을 만들고, 내용은 "최악의 상황에서 쓰일 증거"라는 마인드로 작성하면, 오히려 최악의 상황은 일어나지 않습니다~! 
2. 선제적으로 '고객'과 '이해관계자'와 소통하라!
   • 사업수행계획서 등 핵심 문서는 고객 및 다양한 이해관계자와 최대한 자주, 그리고 상세하게 소통하며 조율해야 합니다. 단순히 '제출'에 그치지 않고, 고객이 무엇을 중요하게 생각하는지, 어떤 부분에 대한 이해가 부족한지 미리 파악하고 반영하는 것이 중요합니다. 이 단계에서 고객 및 이해관계자와의 신뢰를 쌓는 것이 앞으로의 프로젝트를 순조롭게 이끄는 열쇠가 됩니다. '워크샵'이나 비공식적인 미팅을 통해 상호 이해를 높이는 것도 좋은 방법입니다. (밥 사주고 술 사주고, 가끔은 커피도..., 비즈니스 영업맨 뺨칩니다! ☕🤝)
3. 명확한 R&R 설정과 상호 협력 통로!
   • 초반에 언급했듯이, 착수 단계는 '업무 불평등'이 심한 시기입니다. PM은 이 시기에 각 팀원과 파트의 R&R을 명확히 정의하고, 이를 사업수행계획서에 반영해야 합니다. 또한, 단순히 R&R을 나누는 것을 넘어 "서로 도울 수 있는 통로"를 PM이 먼저 만들어야 합니다. 개발팀이 한가할 때 문서 작업에 필요한 기술적 검토를 돕거나, 향후 분석/설계 단계에 필요한 사전 학습을 유도하는 등 '빈 시간'을 활용해 팀 전체의 역량을 높이고 협업 문화를 구축하는 것이 중요합니다. (놀고 있는 개발팀은 PM에게 죄책감을 줍니다... 일 시켜야 해요! 😈 물론 웃으면서 말이죠! 😊) 이 통로를 착수 단계부터 만들고 실행해야 프로젝트 기간 동안 계속 서로 도우며 잘 마무리할 수 있게 됩니다.

 

 

지난 블로그에서 언급했던 NotebookLM이 이제부터 빛을 발하게 됩니다. 

• RFP 본문 및 내용 안에 언급된 "관련 법령", "고시" 등 관련 문서들을 모두 업로드해 놓고, 이후부터 모르는 용어와 상황들에 대해서 물어보면 됩니다. ChatGPT와 같이 출처를 모르는 답변이 아닌 명확한 출처와 답변을 제공합니다. (마치 당신의 개인 비서이자 법률 자문가랄까요? 💼)
• AI는 당신의 '문서화 파트너'다! 방대한 착수계 서류 작성이나 사업수행계획서 초안 마련이 막막할 때는 LLM(Large Language Model)을 적극 활용해 보세요! 관련 가이드라인이나 이전 프로젝트 자료를 입력하고, "~에 대한 계획서 초안 작성", "보안 서약서 문구 검토", "각 항목별 필수 포함 내용 리스트업" 등을 요청하면 시간을 대폭 절약할 수 있습니다. 🤖

착수 단계의 중요성을 간과하지 마세요. 이 단계에서의 꼼꼼함이 곧 PM님의 역량을 증명하고, 프로젝트 성공의 초석이 될 겁니다!

 

 

다음 글에서는... 드디어 프로젝트 수행의 본격적인 시작, "분석 단계"에 대해 자세히 알려드릴게요! 가장 중요한 단계 중 하나이니 놓치지 마세요! :>