본문 바로가기

Q&A(자문자답)13

Q. 프로젝트 종료 단계에 고객이 하자보수? 유지보수 계획에 대해서 제출해 달라는데, 하자보수와 유지보수의 차이가 뭔가요? Q. 프로젝트 종료 단계에 고객이 하자보수? 유지보수 계획에 대해서 제출해 달라는데, 하자보수와 유지보수의 차이가 뭔가요? 하자보수 계획서? 유지보수 계획서? 어떤 걸 써야 하고 어떤 내용으로 써야 하나요? 우리 프로젝트의 RFP에는 유지보수가 포함되어 있지 않아요~A. 핵심은 계약 범위와 책임 주체입니다! 딱 3가지로 명확히 정리해 드릴게요. 💡하자보수 vs. 유지보수 핵심 요약:하자보수: 시스템 개발사 책임으로, 구축 시점에 발생한 결함/오류를 무상으로 수정해주는 활동.책임 기간: RFP에 명시되어 있지 않다면 공공 프로젝트의 경우 통상 1년으로 진행됩니다.한 마디로 '공짜 A/S'! (원래 잘못 만들어진 부분 고쳐줘!)유지보수: 시스템 운영 단계에서 안정화, 성능 개선, 신규 기능 추가 등 유상으.. 2025. 6. 28.
Q. 시험 단계에서 PM이 가장 중요하게 관리해야 할 활동들은 무엇인가요? 📋 Q. 시험 단계에서 PM이 가장 중요하게 관리해야 할 활동들은 무엇인가요? 📋A. PM은 시험 단계에서 '전체적인 그림'을 보고 '조율'하는 역할을 합니다. 제가 중요하게 챙기는 활동들은 다음과 같아요!테스트 계획 관리: 처음 세웠던 테스트 계획이 잘 지켜지고 있는지, 테스트 범위는 적절한지 지속적으로 점검해야 합니다. 계획대로 테스트가 진행되어야 예상치 못한 문제가 발생했을 때도 신속하게 대응할 수 있어요.테스트 실행 모니터링: 테스트가 실제로 어떻게 진행되고 있는지 현황을 파악하고, 진척률을 관리합니다. 테스트 케이스가 제대로 수행되고 있는지, 테스트 환경은 충분한지 등을 확인해야 해요.결함 관리의 총책임자: 발견된 버그(결함)가 얼마나 심각한지, 언제까지 해결될 것인지, 해결 후 재테스트는 어떻게.. 2025. 6. 11.
Q. 개발 일정이 지연될 때 PM은 어떻게 대응해야 하나요? ⏰➡️😫 Q. 개발 일정이 지연될 때 PM은 어떻게 대응해야 하나요? ⏰➡️😫A. 일정 지연은 PM의 심장을 쫄깃하게 만드는 상황이죠. 하지만 침착하게 원인을 파악하고 전략적으로 대응하는 것이 중요합니다!PM (프로젝트 매니저) 관점:PM은 개발 초기부터 WBS(작업 분해 구조)를 상세하게 수립하고, 주기적으로 진척 현황을 파악하여 지연 징후를 조기에 식별해야 합니다. (촉을 세우세요! 👃)지연이 예상되거나 실제로 발생했을 때는 PL과 함께 정확한 원인(기술적 어려움, 리소스 부족, 예상치 못한 변수 등)을 분석합니다.분석된 원인을 바탕으로 우선순위 조정, 인력 재배치, 외부 전문가 투입, 또는 고객과의 일정 협의 등 다양한 대응 방안을 고려하고 실행에 옮겨야 해요.PM 찐팁: 지연 상황 발생 시 감추려 하지.. 2025. 6. 10.
Q. WBS(Work Breakdown Structure)는 분석 단계에서도 만들었는데, 설계 단계에서는 어떻게 더 활용되나요? 뭐가 더 중요해지나요? 🤔 Q. WBS(Work Breakdown Structure)는 분석 단계에서도 만들었는데, 설계 단계에서는 어떻게 더 활용되나요? 뭐가 더 중요해지나요? 🤔A. WBS는 프로젝트의 '내비게이션'이라고 할 수 있습니다. 분석 단계에서 프로젝트의 큰 갈래와 주요 산출물(deliverables)을 정의했다면, 설계 단계에서는 이 WBS가 '더욱 촘촘하고 구체적인 작업 단위'로 확장되고 상세화됩니다. 마치 대략적인 지도 위에 세부적인 길과 건물들을 그려 넣는 과정과 같죠! 🗺️분석 단계의 WBS가 프로젝트의 "무엇을 해야 하는가"에 대한 큰 그림이었다면, 설계 단계의 WBS는 "어떻게, 누가, 언제까지 해야 하는가"에 대한 구체적인 실행 계획이 됩니다. 이 단계에서는 WBS의 역할이 훨씬 더 중요해져요!📌 .. 2025. 6. 9.
Q. '테스트 계획서'들이 여러 종류(단위, 통합, 시스템, 사용자, 인수)가 있는데, PM 입장에서 '설계 단계'에서는 각각 어떤 내용을 중요하게 '계획'하고 '정의'해야 하나요? Q. '테스트 계획서'들이 여러 종류(단위, 통합, 시스템, 사용자, 인수)가 있는데, PM 입장에서 '설계 단계'에서는 각각 어떤 내용을 중요하게 '계획'하고 '정의'해야 하나요? 🤔A. 맞아요! 테스트는 PM의 마음을 편안하게 해주는 '품질 보증 설계'의 핵심이죠! 설계 단계에서는 실제로 테스트를 수행하기보다, '어떤 테스트를 어떤 기준으로, 어떻게 진행할 것인지'에 대한 청사진을 그리는 것이 중요합니다. PM은 이 계획이 시스템의 품질을 제대로 검증할 수 있도록 꼼꼼히 챙겨야 합니다! ✨시스템 개발에서 테스트는 마치 건물을 짓는 과정에서 안전 점검을 하는 것과 같아요. 🏗️ 각 단계마다 다른 목적과 관점으로 점검을 해야 튼튼하고 안전한 건물을 완성할 수 있겠죠? PM은 이 모든 점검 계획을 미리.. 2025. 6. 9.
Q. 요구사항 추적표'가 PM에게 왜 그렇게 중요한가요? 그냥 요구사항 정의서만 있으면 안 되나요? Q. 요구사항 추적표'가 PM에게 왜 그렇게 중요한가요? 그냥 요구사항 정의서만 있으면 안 되나요?A. 앗, PM의 숙면을 지켜주는 아주 중요한 질문입니다! 😴 요구사항 추적표는 단순한 문서가 아니라, 프로젝트의 모든 요구사항이 최종 시스템에까지 제대로 반영되고 있는지 '추적'하고 '관리'하는 PM의 핵심 도구예요."그냥 요구사항 정의서만 있으면 되지 않나요?"라는 질문, 정말 많이 듣습니다. 😅 하지만 요구사항 정의서만으로는 부족해요! 왜 그런지 제가 직접 겪었던 경험과 함께 '요구사항 추적표'가 왜 필수적인지 자세히 설명해 드릴게요.📌 요구사항 추적표가 PM에게 중요한 이유 (PM의 평화를 위한 필수템! 🧘‍♀️)변화 관리의 핵심 도구: 🔄 프로젝트가 진행되면서 요구사항이 바뀌는 경우는 정말.. 2025. 6. 9.
Q. 설계 단계에서 PM이 가장 중요하게 챙겨야 할 활동은 무엇인가요? 체크리스트가 궁금해요! Q. 설계 단계에서 PM이 가장 중요하게 챙겨야 할 활동은 무엇인가요? 체크리스트가 궁금해요!A. PM의 '세심한 눈'과 '강력한 조율 능력'이 필요한 시기죠! ✨설계 단계는 건물을 짓기 전 설계도를 그리는 것과 같아요. 🏗️ 이 설계도가 부실하면 나중에 건물이 흔들리거나, 심지어 무너질 수도 있죠! 그래서 PM은 이 단계에서 아래 사항들을 꼼꼼하게 확인하고 조율해야 합니다. 제가 현장에서 늘 쓰는 체크리스트를 공개할게요! 📝📌 설계 단계 PM 체크리스트! 시스템의 뼈대와 내장 디자인 확인하기: 아키텍처, 프로그램 기능, 데이터 흐름 등 시스템의 모든 것을 구체적으로 그리는 작업이에요. 🏗️핵심 기능 정의 명확성: 요구사항에 맞춰 시스템이 어떤 기능을 수행할지 명확하게 정의되었나요?아키텍처 적정성.. 2025. 6. 9.
Q. 폐쇄망인데 챗GPT 같은 AI(LLM) 사용이 가능할까요?(소스코드 지원 포함!) Q. 폐쇄망인데 챗GPT 같은 AI(LLM) 사용이 가능할까요?(소스코드 지원 포함!)A. 결론부터 다시 말씀드릴게요! 폐쇄망에서도 AI(LLM)를 사용해서 개발팀의 간단한 도움이나 소스코드 지원을 받는 것은 충분히 가능합니다!쉽게 말해, 우리가 평소에 쓰는 인터넷 기반의 AI 서비스(예: ChatGPT)는 마치 '외국에 있는 큰 도서관'에 가서 책을 빌려보는 것과 같아요. 그런데 폐쇄망은 '우리 회사 안에만 있는 작은 도서관'이라고 생각하시면 됩니다. 인터넷 연결 없이도 이 도서관에 있는 책들을 자유롭게 이용할 수 있는 거죠.그럼 어떻게 우리 회사 안에서 AI 도서관을 만들 수 있을까요?'우리 회사 전용 AI 비서'를 데려오는 거예요!우리가 흔히 아는 ChatGPT 같은 AI는 너무 거대해서 회사 안에.. 2025. 6. 4.
Q. PM으로서 분석 단계에서 가장 중점적으로 관리해야 할 산출물은 무엇인가요? Q. PM으로서 분석 단계에서 가장 중점적으로 관리해야 할 산출물은 무엇인가요?A : 당연히 PM이 가장 매의 눈으로 봐야 할 '핵심 중의 핵심'은 바로 요구사항 정의서(RDD)입니다.왜 요구사항 정의서가 가장 중요할까요? 요구사항 정의서는 "우리가 무엇을 만들 것인가?"에 대한 고객과 개발팀 간의 유일한 합의문이자 약속입니다. 이 문서가 명확하지 않거나 불완전하면, 설계 단계에서 혼란이 오고, 개발 단계에서는 엉뚱한 결과물이 나올 수 있습니다. 프로젝트의 '청사진'이라고 불리는 이유가 여기에 있습니다. PM은 요구사항 정의서가 모든 이해관계자의 니즈를 정확히 반영하고, 모호함 없이 구체적으로 기술되었는지, 그리고 최종적으로 공식적인 승인을 받았는지 철저히 확인해야 합니다. 요구사항 정의서는 마치 항해.. 2025. 6. 4.
Q. 요구사항 변경은 어떻게 관리해야 하나요? Q. 요구사항 변경은 어떻게 관리해야 하나요?A. 아, 요구사항 변경... PM이라면 누구나 가슴을 쓸어내리는 키워드죠! 😅 특히 분석 단계에서의 요구사항 변경은 프로젝트 후반부로 갈수록 눈덩이처럼 불어나는 비용과 직결되기 때문에 '황금률'처럼 관리해야 합니다.첫째, 변경 요청은 무조건 '공식화'하세요. 구두 요청은 '없던 일'이 될 수 있습니다. 변경 요청서(Change Request Form, CRF)를 통해 변경 사유, 내용, 요청자, 예상되는 영향(일정, 비용, 범위) 등을 명확히 기록하고 제출하도록 유도해야 합니다. 공식적인 서류 한 장이 나중에 발생할 수 있는 수많은 분쟁을 막아줍니다. 마치 중요한 계약서를 구두로 하지 않고 서류로 작성하는 것과 같죠!둘째, '영향도 분석'은 필수입니다. ".. 2025. 6. 4.
Q. 프로젝트 중 갈등이 발생했을 때, PM으로서 어떻게 해결해야 할까요? 특히 발주기관과 수행사 간의 갈등이요. 매번 진땀 빼는 것 같아요. Q. 프로젝트 중 갈등이 발생했을 때, PM으로서 어떻게 해결해야 할까요? 특히 발주기관과 수행사 간의 갈등이요. 매번 진땀 빼는 것 같아요.A. 끄응... 프로젝트는 언제나 '사람 사는 세상'이라 갈등은 피할 수 없는 동반자죠. 특히 발주기관과 수행사 사이의 갈등은 마치 시한폭탄처럼 언제 터질지 몰라 PM의 심장을 쫄깃하게 만듭니다. 저도 아직까지 대화를 하다가 실시간으로 흰머리가 늘어가는게 느껴 집니다! 하지만, 여러 상황을 겪으며 이제는 '갈등? 어서 와! 해결해 줄게!' 모드가 되어가고 있답니다! 😎🕵️‍♀️ 갈등 레이더 가동!: 싸움은 커지기 전에 막는 게 최고입니다. 분위기가 심상치 않거나, 사소한 불만이 새어 나오면 바로 PM의 '갈등 레이더'를 켜고 원인을 파악하세요. 커피 한 잔 하.. 2025. 6. 3.
Q. 공공기관 프로젝트에서 사업수행계획서(사수계)가 정말 중요한가요? 제안서랑 크게 다를 게 없는 것 같은데요? Q. 공공기관 프로젝트에서 사업수행계획서(사수계)가 정말 중요한가요? 제안서랑 크게 다를 게 없는 것 같은데요?A. 으음... 제안서와 사수계가 비슷하다고 느끼셨다면, 아직 프로젝트의 찐한 맛을 덜 보신 걸지도... (넝담~💖) 제안서가 '저희 이런 걸 정말 잘 만들 수 있어요!' 하고 썸타는 단계의 어필 서류라면, 사수계는 이제 '결혼 준비를 위한 상세 계약서'라고 할 수 있습니다! 💍제안서는 '꿈'을 파는 거라면, 사수계는 그 꿈을 '현실'로 만드는 구체적인 계획서예요.🔍 돋보기 디테일: 제안서가 큼직한 그림이었다면, 사수계는 그 그림의 모든 점과 선, 색깔까지 하나하나 디테일하게 '이게 다 돈이고 시간이다!'라고 박아 넣는 작업입니다. 이거 하나로 프로젝트의 모든 범위, 일정, 사람, 품질, .. 2025. 6. 3.

티스토리툴바