저번 글에서 공공 SI의 전체적인 순서를 훑어봤는데, 오늘은 그중에서도 PM의 '눈치'와 '꼼꼼함'이 가장 필요한 RFP 분석과 과업대비표에 대해 써보려 합니다.

#1 RFP(제안요청서) 분석: 행간을 읽어야 산다

사업자가 공고를 보고 "오, 이거 할만하겠는데?" 싶어서 RFP를 열면 수십, 수백 페이지짜리 문서가 반겨줍니다. 그냥 읽으면 소설책이지만, PM은 여기서 **'독소 조항'**을 찾아내야 합니다.

• 기술 점수 vs 가격 점수: 보통 9:1인데, 가끔 8:2인 곳도 있습니다. 우리 회사가 기술력으로 압살할 수 있는지, 아니면 단가 싸움을 해야 하는지 여기서 사이즈가 나옵니다.
• 투입 인력 제한: 공공은 인력 등급에 예민합니다. "특급 기술자 X명 상주 필수" 같은 조건이 있는데, 정작 회사에 보낼 사람이 없으면 시작부터 꼬이는 겁니다.
• 인프라 및 SW 스펙: RHEL 버전이나 특정 DB, 보안 장비 규격이 딱 정해져 있는 경우가 많습니다. 기존 시스템이랑 안 맞으면 나중에 '호환성 지옥'에 빠지니 미리 체크해야 합니다.

▶ 산출물 > RFP 분석서(내부용)

#2 과업대비표: PM의 방패이자 생존줄

RFP 분석의 정점은 과업대비표 작성입니다. 말 그대로 "기관이 요구한 거(RFP)를 우리가 이렇게 하겠다(제안서)"라고 일대일로 매칭해놓은 표입니다.

• 이거 왜 하나요?: 나중에 사업 끝나갈 때쯤 발주처에서 "이거 왜 안 되어 있어요?"라고 할 때, "과업대비표 보시면 이 항목은 협의 제외였습니다"라고 말할 수 있는 유일한 근거가 됩니다.
• 작성 팁: 요구사항 번호 하나하나에 우리 기능을 매핑합니다. 이때 애매한 것들은 '협의 필요'나 '상세 설계 시 확정' 같은 문구를 잘 써야 합니다. 안 그러면 나중에 다 우리 책임 됩니다.(강조 x100)

※ 제안 단계에서 점수 따려고 "다 됩니다!" 하고 과업대비표에 '수용' 박아버리면, 실제 수행 들어갔을 때 PM은 밤샘 확정입니다... 적절한 밀당이 필요합니다.

▶ 산출물 > 과업대비표

#3 실무자 입장에서 본 RFP의 현실

기관 담당자분들도 기존 RFP를 복붙해서 만드시는 경우가 많다 보니, 가끔 앞뒤가 안 맞거나 이미 단종된 기술을 요구하는 경우도 있습니다.

이럴 땐 당황하지 말고 질의 응답 시간을 활용하거나, 기술 협상 때 명확히 짚고 넘어가야 합니다. "나중에 알아서 해주겠지"라는 생각은 공공 SI판에서는 절대 통하지 않습니다. (내 몸은 내가 지킨다...)

오늘도 바쁜 현대사회에서 살아남는 PM 분들 파이팅입니다.

[공공 SI] 사업의 시작부터 계약까지, 전체 프로세스 훑어보기

감리 시정 조치 수행하고, 프로젝트 마무리 하느라 정신이 없어서 블로그를 한 달 건너 뛰었습니다. (바쁘다 바빠 현대사회)

오늘은 공공 SI 사업이 실제로 어떻게 시작되고, 계약까지 흘러가는지 그 단계를 정리해 보려 합니다.

#0 ISP 사업 (정보화전략계획, 필수 X)

SI 사업을 시작하려면 **'무엇이 문제이고, 무엇을 만들 것인가?'**에 대한 밑그림이 필요합니다. 공공기관 담당자분들은 시스템에 대해 전문적으로 깊게 아시는 분들이 많지 않기 때문에, **ISP(Information Strategy Planning)**를 먼저 발주하여 전문가들의 설계와 자문을 받습니다.

• 수행 내용: AS-IS 시스템 분석, 사용자 요구사항 분석, 인프라 환경 분석 및 목표 시스템 설계 등
• ▶ 산출물: ISP 결과 보고서

#1 사업 발주 (기관)

기관은 ISP 결과를 기반으로 **제안요청서(RFP)**를 작성합니다.

• RFP 작성: 이미 나와 있는 샘플이 많아서, 담당자분들이 기관 특색에 맞는 항목만 수정해서 '복붙' 하기도 합니다. (많이 써보신 분들은 뚝딱 만드십니다.)
• 공고 확인: 조달청 **나라장터(G2B)**에 사전규격 → 본 공고 순으로 올라옵니다.
• 사업자 대응: RFP를 분석해 사업 적합성, Cost, 불합리한 조항 등을 판단합니다. 부당한 항목은 수정을 요청할 수도 있다는데... (실제로 하는 건 본 적 없지만 가능은 하다고 합니다.)
• ▶ 산출물: 제안요청서(RFP)

#2 제안 및 입찰 (사업자)

사업자로 참여하기로 결정했다면, 이제 문서 싸움의 시작입니다.

1. 제안서 작성: 영업, PM, 기획, 개발 PL 등이 붙어서 **발표자료(PPT)**와 정성제안서를 씁니다.
   • Tip: 이때 자료를 잘 만들어두면 나중에 사업수행계획서나 보고 자료로 재활용할 게 많습니다.
   • 주의: 수주 욕심에 무리한 추가 제안을 넣으면? 나중에 수행팀이 죽어납니다. (강조 x10000) 적절한 범위 안에서 제안해야 합니다.
2. 입찰 (가격 투찰): 예산 대비 몇 %로 수행할지 금액을 써냅니다.
   • 보통 점수를 따기 위해 하한선인 80% 근처로 던지고 보기도 하지만, 진짜 실력 있는 회사는 기술 점수에서 압살하기 때문에 금액에 크게 연연하지 않기도 합니다.

• ▶ 산출물: 제안 발표자료, 정성제안서

#3 발표 평가 (심사)

작성한 제안서를 들고 평가위원들 앞에서 발표를 진행합니다.

• 자체 평가: 발주기관이 직접 진행. 투명성을 위해 외부 위원을 일부 섞어서 평가합니다.
• 조달 평가: 조달청 주관으로 진행. 주로 외부 전문가들이 위원으로 참여합니다.

#4 기술 협상 (기관 & 사업자)

우선협상대상자로 선정되면 이제 디테일한 조율에 들어갑니다.

• RFP와 제안서를 펼쳐놓고 수정하거나 추가할 내용을 논의합니다. 이 단계가 원활하게 끝나야 최종 계약으로 넘어갑니다.
• ▶ 산출물: 기술협상서

#5 계약 (최종)

기관의 행정 부서와 사업자 간의 행정 처리가 마무리되면 비로소 사업이 시작됩니다.

• ▶ 산출물: 보안서약서, 각종 각서 및 계약서류

이제 계약까지 했으니 남은 건... 문서의 늪이죠. 다음 글은 본격적인 SI 산출물에 대해서 써보겠습니다~!

아주 정신 없는 한 주 였습니다. 프로젝트 말기라서 배포, QA, 산출물 정리, 감리 의 연속이라 이번 주 블로그 쓰는걸 까먹을 뻔 했지 뭡니까.(12월에 끝나야하는 사업인데 안끝나서 너무 힘들어요. 제발 좀 끝내자)

오늘은 목적성(방향성)에 대해 이야기를 해보고자 합니다.

#1 효율적인 시간 활용을 위한 잡음 제거

우리는 많은 회의를 진행합니다. 발주기관 주간회의, 사내 주간회의, 긴급회의, 중간회의, 개발팀 회의 등등...

지금 현황에서 남은 건 무엇인지, 놓치는 건 뭐가 있는지, 오늘은 무슨 일을 할지, 이슈가 무엇인지, 이슈를 처리하기 위해선 뭘 해야할지, 이슈에 대한 개개인의 의견이 뭐가 있는지, 오늘 점심은 뭘 먹을지, 언제 프로젝트가 끝날지 이 내용이 쓸모없는 건 아닐지 등

말을 장황하게 썼지만 전달하고자 하는 말은

목표와 결과(정량적)를 도출하기 위해 쓸모없는 말을 줄이자 입니다.

사람이 많아지면 말이 많아지고, 말이 많아지면 시간이 지체됩니다.

회의 때문에 시간이 지체되는건 정말 불필요한 행위라고 생각합니다.

회의가 쓸모없는 내용이 많다고 생각이 들면 참석자를 줄이던, 쓸모 없는 말을 줄이던 결정이 필요하다고 생각합니다.

#2 빠르게 회의를 끝내기 위한 목표 설정

회의를 할 땐 여러 포지션이 함께합니다. (관리, 기획, 개발)

사업관리는 보통 많은걸 알아야 하기 때문에 많은 이야기를 들으면 좋지만

기획, 개발은 사업관리의 상세한 내용을 알 필요가 없고

사업관리, 기획도 개발의 상세한 과정까지 들을 필요는 없습니다.

사람이 말을 하다보면, 내 얘기도 하고 싶고, 아는 얘기를 나누고 싶고, 이런말 저런말 하고 싶지만

우리는 시간이 없습니다. 할 내용만 빨리 회의하고 나가서 다른 일을 해야합니다.

보통 3가지만 잡고 들어가면 빠르게 끝납니다.  ▲기간 ,▲목표, ▲정량적 수치

▲언제까지, ▲무엇을 구현해야하는데, ▲몇 프로까지 구현할 수 있는가

그 외에 이슈는 필요하면 바로바로 이야기하거나, 팀 내부에서 회의하시고 요청할 것 있으면 요청해주시기 바랍니다.!

라고 하면 보통 빨리 끝납니다.

위에 보고할 때도 마찬가지로 정량적 결과(구현 90%완료, 1월 12일까지 완료 목표 예정)만 보고 하면 됩니다.

말 많은거 싫어잉..

#3 Remind.bat

프로젝트 진행을 위해, 자료와 의견들을 전달합니다. 그리고 얼마 뒤에 개발팀에 물어보면 못들었다고 합니다.

??? 저번에 얘기했는데 왜 못들었어요?

사실 확인을 위해 근원지를 찾아가 봅니다. 아뿔싸.... 중간관리자가 바빠서 내용 전달을 못했습니다...

개발자가 논건 아니지만 우선순위가 해당 사항이 높기 때문에 전체적인 일정에 문제가 생겼습니다..

어쩌지..어쩌지... 뭘 어째요 일단 자료 전달주고 급한거라 빨리 좀 부탁한다고 요청드릴 것 밖에 할 수 없습니다..

정상적인 조직이라면, RnR이 명확하게 되어있고, 본인의 할 일만 해서 굴러가는 조직이라면 문제 될 일이 없습니다.

하지만 한 사람에게 너무 많은 일이 배정되어있다면, 놓치기가 쉽상입니다. 이는 조직 전체에 약영향을 미칩니다.

우리는 여기서 뻐꾸기가 되어야합니다.

이거 됐나요? 어떻게 진행되고 있나요? 뭐 필요한거 없나요?

지속적으로 체크해줘야 나중에 일어날 사고를 막을 수 있습니다.

그리고 우리 또한 이슈가 들어오면 어떻게 해야되지... 하고 붙자고 있지말고.. 던지십쇼... 일 잡고 있으면 나중에 큰일납니다...

다들 감기 조심하세요~

약 3년의 기간동안 공공기관 SI PM으로 일하면서 느끼고 배웠던 점, 경험을 하나씩 적어보려 합니다.

이 게시글을 읽는 분 중에는 이제 막 PM을 시작하시는 또는 취업, 이직 준비하시는 분, 암담하고 막막한 상황에서 읽으시는분 또는 우리 애(=소속된 프로젝트의 PM)는 왜 저럴까 하면서 읽으시는 분들도 있으실탠데, 누군가에게 공감이 되고 같이 이야기 할 수 있는 글이 되었으면 합니다.

첫 게시글이니 만큼 저의 이야기를 좀 적어보고자 합니다.

#1 글을 쓰게 된 계기

- 감사하게 솔루션 업체 면접을 보게 됐습니다. 정말 많은 지원 업체 중에 딱 1곳 주니어 PM 뽑는 곳에 연락이 와서 면접을 보게 됐고, 제가 했던 프로젝트와 작성한 자소서에 대해서 열심히 복기하며 면접을 준비했습니다. 면접관님 질문은

꿈은 뭔가요? 내년도에 하고싶은게 있나요? 취미는 뭐에요? 쉬는날에는 뭘하나요? 목표가 있나요?

  이런 개인적인 것들을 물어보셨고, 면접 마지막 쯤에, 준비했는데 답변하지 못했거나 더 얘기하고 싶은게 있느냐 라고 물어보셨고, 저는 '일을 하고 있는 중고신입 경력자여서, 저의 경험에 대해서 이야기를 준비해왔는데, 그런걸 물어보지 않으셔서 당황했다. 이유가 있는가?' 라고 질문을 드렸고 면접 담당자 분이 하시는 말씀은 

프로젝트에 관하여 질문하지 않은 이유는

① 면접관은 해당 프로젝트에 참여하지 않았기 때문에,
② 소통하면서 일하는건 크게 다르지 않기 때문에,
③ 이직하고 여기와서 시간을 어떻게 보낼지가 궁금하기 때문에

당신이 '시간'을 어떻게 사용하는지 보고 싶었다.
시간을 효과적으로 사용하는 사람은 그렇지 못한 사람을 순식간에 역전할 수 있을 것이다. 라고 생각한다.

프로젝트 매니징은 시간관리이기 때문에. 자신의 시간을 어떻게 관리하는지를 보면,
우리도 그 사람에게 일을 맞길 수 있지 않겠는가?

이 이야기를 들을 때 머리를 한 대 맞는 것 같았습니다. 너무 이해되는 말들이고, 반박할 수 없는 말이었기 때문입니다.

사실 저는 경험이 좀 많습니다. 학생회장, 연합회기획국장, SI 프로젝트 구축-운영(사업 제안, 개발, 구매, 기획) 등 누구보다 뛰어나다고 자부할 순 없지만, 그래도 경력대비 경험은 좀 많은 편 아닌가?(지금 생각하면 우물안 개구리입니다. 세상엔 엄청난 사람들이 많습니다.) 라고 생각하면서 살았는데, 다른 사람들이 보기엔 '월급만 받는 직장인 1' 로 밖에 안보이겠구나 라는 생각이 들었습니다.

그리고 또 해주시는 말씀이

꿈을 꾸고 있지 않으면 잘 안뽑는다. 돈까지 주고 공부시키는데 입사하고 본인 시간 투자하는건 당연한다.
거쳐가는 회사라도 상관없다. 하지만 멈출 사람을 찾고 있지 않다.

확장하는 회사는 아니지만 이 사람이 필요하다면 연봉을 맞춰줄 수 있는거고, 구성원이 성장해야 회사가 성장한다.
퇴사를 하더라도 퇴사자가 남겨놓은 것을 우리는 자료로 해서 사용할 수 있다.

여기서 커리어가 안끝났으면 좋겠다. 1,2년 언제 없어질지도 모르는 회사인데,
내일 당장 망해도 이직할 수 있는 사람이 됐으면 좋겠다.

높은 곳을 지원해보고 해당 스펙으로 지원해봐라, 합격하게 되면 이 회사에서 그렇게 한 번 해봐라, 계속 발전해야한다.해봐라

(박수)x100

비록 떨어질 걸 예상한 면접이었지만(사실 내심 기대, 기대는 할 수 있잖아요?) 그 1시간이 최근 기억나는 가장 임팩트 있는 시간이었습니다. 과거 입사할 때의 열정이 다시 불타오르는 시간이 아니었나 생각합니다.

#2 부제에 관한 이야기

- 비전은 그대로 유지하고, 방향을 바꿈으로 성장할 수 있는, 더 나은 방향은 무엇인지 찾는것을 'Pivot' 이라고 합니다. 농구 용어라고 하는데, 보통 빠르게 변화해야하는 스타트 업에서 사용합니다. 

인생도 적절한 pivot이 필요하다고 생각합니다. 과감하게 버릴 줄 알고, 새로운 걸 시도할 줄 알아야 합니다. (나이가 더 들기전에) 하지만 무작정 pivot은 돌이킬 수 없기 때문에, 여러가지를 고민하고 고려해야합니다.

- pivot에 실패했을 때 돌아올 수 있는가?(자력으로 생계를 유지할 수 있는가?)
- pivot에 방향이 적절한가?
- pivot의 목적은 무엇인가?
- pivot의 결과는 무엇인가?
- pivot하기 위한 에너지(행동력)가 준비되어 있는가?

등등 여러가지 고민을 해야합니다.

단순히 지금 있는 상황에서 벗어나고 싶은 pivot은 옳지 않습니다. (건강상의 이유 제외 - 당장 탈출 하십쇼)

만약 고민하고 준비가 됐다면, 일단 시작하시는걸 추천드립니다.

아무것도 하지않고 생각만 하면, 그냥 아무것도 안한 사람으로 남는겁니다.

#3 후일담

1. 친한 친구와 이야기를 하다가 블로그 적금 이라는 모임을 모집할 예정인데 같이 해보면 어떤가? 라고 제안을 해줘서 같이 하게 됐습니다.

2. 높은 곳을 보라는 담당자님의 말이 너무 공감돼서 창업(?)도 생각하고 있습니다. 감사합니다. 

3. 🎅메리크리스마스🎄