프로젝트 진행 A to Z
다는 아니고요 저희 회사의 경우만 그렇습니다
프로젝트라는 게 사실 진행하다 보면 쓸 거리가 대서사시 뺨 칠 정도로 나오지만, 자세한 얘기는 차차 풀어보기로 하고 우리 회사에서 진행되는 프로세스를 남겨보기로 한다. 대부분의 회사에 통용된다기보다는, 아마도 일반 회사에서 IT 쪽으로 뭔가를 한다고 할 때 대충 이런 프로세스지 않을까.. (하는 추측만을 남기고...)
1. 요건 정의
자체 프로젝트건 현업 부서 요청이건 유관 부서는 있을 수밖에 없다. 회사를 다니면서 일을 하다 보면 어느 정도 마주치는 부서는 정해지기 마련인데, IT팀은 그런 게 없다. 마치 경영학과 전공처럼.. (4년을 다녀도 매번 전공 수업에 모르는 사람뿐)
이 단계는 아주 간단해 보이지만, 프로젝트 전체를 통틀어 가장 중요한 단계다. 요건을 명확히 해놓지 않으면 프로젝트는 근간이 흔들린다. 하나의 큰 방향을 정해놓고 곁가지를 더하거나 쳐내는 방식으로 진행이 되어야 하는데, 메인 방향성이 자꾸 바뀐다. 당연히 프로젝트에 좋은 영향을 미칠 수 없다.
여러 번의 협의를 거쳐 대상 사이트 (PC/MC/BO), 구축 범위(요건) 등의 프로젝트 범위를 산정한다. 현업에서 어떤 걸 하고 싶은지 청취하고 그에 따른 부가적인 요소는 우리가 미리 찾아내야 한다. 예를 들어 모바일 앱에만 구축 요청을 받았다고 치자. 앱이라면 어느 영역에 들어갈지에 따라 하이브리드인지 네이티브인지 알아야 어떤 개발자를 투입할지, 기간은 어느 정도 걸릴지를 산정할 수 있다. 당장의 요청 사항은 모바일 앱에만 한정되어 있어도 추후 모바일 웹이나 PC까지 확대될 가능성은 없는지도 고려해야 한다. 기간 내에 확장 범위 개발이 불가능하다 해도 DB 테이블은 확장성을 고려하여 설계할 수 있어야 한다. 현업에서는 당연히 백 오피스나 DB까지 고려할 수 없기 때문에, FO 요건에 맞춰 어느 정도까지 건드려야 하는지 가늠한다.
성공적이고 무탈한 프로젝트 진행을 위해서는 첫 단계에서 가장 힘을 쏟아야 한다.
기반이 탄탄한 건물은 무너지지 않는다. 프로젝트는 소통을 하며 균형을 맞춰나가는 일의 연속인데, 중심만 탄탄하면 흔들거리다가도 어느샌가 안정을 찾기 마련이다. 기초 공사를 나중으로 미룰 수는 없다. 그때는 그저 책임을 회피하기 위해 억지로 회반죽만 덕지덕지 발라둔 실패가 기다리고 있을 뿐이다.
2. 견적 문의
대략의 요건이 정해졌다면 본격적으로 견적을 문의한다. 문의 방법은 프로젝트 성격마다 조금씩 다른데,
1) 직접 관련 기술이 있는 파트너사에 컨택
2) SI 업체에 의뢰
하는 두 가지 방식이 있다. 직접 컨택하지 않고 SI 업체에 의뢰하는 경우, 보통 또 다른 파트너사의 견적을 받아 각 파트너사별 견적서를 다시 우리에게 전달한다. SI업체에서 직접 프로젝트 인력을 파견하는 경우도 있으나 대부분은 PM 등 관리/기획 직무 정도만 파견한다.
프로젝트의 범위나 회사 내외부적 상황 등 그때그때 알맞은 방식을 택한다. 다만 여기서 갈리는 방향에 따라 프로젝트를 발주하는 우리의 역할이 상당히 달라진다. 직접 컨택하는 경우 비딩에 앞서 RFP를 미리 작성하기도 하고, SI 업체에 의뢰하는 경우 업체와 함께 RFP를 작성하기도 한다. 혹은 비딩 이전 대략적인 내용만 공유하고 비딩 참여를 제안하기도 한다.
3. 비딩
앞선 두 단계가 프로젝트 준비 단계였다면, 비딩부터는 본격적으로 대외적인 프로젝트가 시작되는 단계다. 공식적으로 작성된 RFP를 비딩 참여할 파트너사들에게 발송하고, 제안 요청 설명회를 진행한다. RFP만으로는 전달되지 않는 요건에 대해 상호 간 확인을 위한 자리이다. 일정 기간이 지난 후 파트너사들의 경쟁 입찰, 제안 설명회를 진행한다. 통상 회사 내부 의사결정권자들과 SI 업체의 담당팀, 구매팀이 배석하여 진행한다. 이 단계에서 적정한 파트너사를 찾지 못하면 유찰 후 재진행하게 된다. 선정된 파트너사는 프로젝트 우선 협상 대상자로 지정되어 계약에 관한 본격적인 협의를 진행한다.
4. 우선 협상 업체 선정 및 요건 협의
RFP와 파트너사의 입찰 PT에서 드러나지 않은 주요/상세 요건을 협의한다. 계약 전에 정해지는 대략의 요건에 따라 파트너사에서 투입할 인력 계획이 달라지기 때문이다. 현업 입장에서는 원하는 기능이 메인 화면에 들어가나 상품 상세에 들어가나 똑같겠지만, 한 화면은 네이티브고 한 화면은 웹이라면? 이미 계약이 끝나고 구축 단계에서는 수정하기 힘들어진다. 현업에 이 내용을 확실히 주지시켜야 한다.
정해진 기간과 예산으로 투입 가능한 인력을 조정한다. 개발 난도에 따라 초급부터 특급, 각 직무에서 투입될 인원의 수와 기간에 따라 금액이 달라진다. 매년 공시되는 소프트웨어 개발자 노임 단가를 참고 자료로 사용할 수 있다.(참고 링크) 또한 인력의 상주/비상주 여부나 컨택 포인트, 주/월간 및 진행 단계에 따른 보고 등의 내용 협의도 들어가면 좋다.
이 과정에서 회사에서 금액을 줄이기 위해 디자인이나 QC 등 일부 파트를 내부 운영팀으로 돌리려고 하는 경우가 있다. 프로젝트 진행 담당자라면 사이에서 조율하고 균형을 잡는 일이 중요하다. 모두를 만족시킬 수는 없더라도 최선의 방향을 도출해내도록 노력해야 한다. 모든 요건을 프로젝트팀에서 진행하더라도 운영팀과는 늘 진행 상황을 공유해야 한다. 프로젝트 팀이 철수한 이후 실제 운영을 맡게 되는 건 운영팀이다. 프로젝트를 진행하며 추후를 생각하지 않고 현재 운영 환경과 프로젝트를 뚝 떼서 생각하는 경우가 종종 있는데, 큰 불상사를 초래할 수 있다. 우선 협상 대상 업체와 합의가 되었다면 계약을, 불발 시 유찰 처리되고 앞의 비딩 단계부터 재진행한다.
5. 계약
이제 드디어 계약이다! 파트너사와의 협의가 끝나면 계약서를 작성하고 내부 절차에 따른다. 품의 쓰고 법무 검토받고 정산할 파트너사 등록하고 착수금 지급하고
그나마 하나의 업체와 직계약이라면 정산이나 인력 관리가 쉽다. 그런데 프로젝트 규모가 좀 크고 복잡해질수록 계약 구조도 복잡해진다. 우리는 똑같이 한 업체와만 계약은 했겠으나.. 실제 투입된 인원은..
SI 업체 > 파트너사 > 파트너사의 파트너사 > 파트너사의 파트너사의...
하도급법상 업무 지시 등 애매할 수 있는 부분이 있으니 잘 확인하도록 하자.
또한 어느 정도 규모가 있는 회사라면, 대고객 서비스일 때의 보안 수준 등 보안 점검 인력 및 비용을 꼭 계약 시에 포함해야 한다.
6. 기획
계약 후 프로젝트팀과 요건 상세 정의를 시작한다. 앞서 정한 요건이 줄기라면, 가지에 해당하는 상세 요건을 다듬는다. 레이아웃을 짜고 그에 맞는 기능을 정의한다. 보통 프로젝트는 기획 - 디자인 - 개발의 순서로 흘러가지만 기획 단계에서부터 디자이너, 개발자 등 다른 파트와 소통하는 게 중요하다. 기획단에서 생각한 UI나 기능을 구현할 수 있는지, 불가능하다면 어떤 식으로 변경해야 하는지 작은 단위부터 미리 공유하고 의견을 나누는 일이 전반적인 속도 향상에 도움이 된다. 커뮤니케이션의 단절은 프로젝트에 가장 큰 독이다. 귀찮고 싫어도 덤벼들어야 한다.
매 단계 컨펌은 필수 절차. 보통 프로젝트 팀과 1차 컨펌 - 운영팀과 2차 컨펌 - 현업과 3차 컨펌의 순을 거친다. 현업에 시안이나 기획이 한 번 넘어가면 높은 확률로 보고 자료에까지 사용되기 때문에(...) 우리 선에서 대략 내용을 다 정의해서 던져야 한다. 현업의 시야에 맞추는 게 중요한데, 그들은 딱히 UX에 대해 고민하지 않기 때문에 왜 이 부분을 이렇게 기획했는지에 대한 의견을 곁들이면 좋다. 그리고 예상되는 요구 사항에 대한 수용 가능 여부와 자료도 알아두는 게 좋다. 우리가 기획해서 컨펌 요청한 자료를 현업에서 그저 좋다며 받아줄 가능성은 0%에 수렴하고, 그렇다고 해도 갑자기 대장이 나타나서 엎을 가능성이 다분하므로 마음을 다져두자. 옳지 않은 방향이면 언제든 계급장 떼고 아닌 건 아니라고 할 수 있어야 한다. 아니라고 했는데도 그 방향으로 진행되는 것과, 말도 못하고 그저 시키는 대로 진행하는 일은 다르다.
7. 디자인
8. 개발
디자인과 개발 단계에서는 할 일이 없다. 숨 쉴 틈도 없던 프로젝트 일정 중 유일하게 여유로워지는 구간(이라 쓰고 폭풍전야라 읽는다). 시안이 나오면 기획에 맞게 구성됐는지, 변경을 원하는 부분이 있다면 디자이너와 명확히 소통하면 좋다. 두루뭉술한 느낌이 아니라 구체적인 이유를 들어 구체적인 수정 방향을 논의하는 쪽으로 하자. 디자인이나 개발 단계에서는 어차피 상세 내용을 우리가 점검할 수는 없으니 해당 기간 동안 일정과 이슈 관리를 중점으로 한다. 이후 컨펌 과정은 기획 단계와 같다.
9. 테스트
테스트는 기능 단위로 수행하는 단위 테스트, 테스트 시나리오에 맞춰서 전체를 점검하는 통합 테스트로 나뉜다. 보통 내부적으로 단위 테스트를 수행한 후 유관 부서 등 실무자도 참여하는 통합 테스트를 거친다. 우리 회사의 경우 담당자가 보통 진행하는 프로젝트의 단위/통합 테스트를 모두 참여하고 현업 테스트도 주관해서 진행한다. 전문 QC 인력도 있지만 현업 테스트 진행까지는 업무 범위가 아니고, 기획 단계부터 참여한 담당자가 프로젝트 전반의 내용을 제일 잘 파악하고 있기 때문이다. 담당자가 테스트 단계에 참여하지 않기도 하는 것 같던데, 업무 여건이 허락한다면 직접 테스트에 참여하는 편을 강력히 추천한다.
테스트를 하며 본인이 직접 서비스를 굴려 봐야 서비스 자체의 퀄리티를 높일 수 있다. 머릿속과 실제 구현된 결과가 같은지, 기획과는 맞게 나왔는지, 상상도 못 한 결함은 없는지. 테스트를 많이 수행할수록 현업에서, 혹은 실사용자 단에서 하는 문의에 대응할 수 있다. 생각해보면 당연한 일이다. 서비스를 경험한 이후 뭔가 이상해서 담당자에게 질문을 던졌는데 담당자도 잘 모른다..? 당황한다..? 확인해보고 연락해주겠다고 한다..? 근데 연락이 없고 담당자는 모르는 결함이었다...? 당연히 믿음이 가지 않을 것이다. 가끔 그럴 수도 있지만 당신이 프로젝트 진행을 주 업무로 한다면, 한 번의 실수가 이미지로 박히기도 한다. 프로젝트는 이번 한 번으로 끝이 아니다. 프로젝트는 끝나도 그 프로젝트를 진행했던 당신의 평판은 계속된다.
테스트 참여를 추천하는 또 하나의 이유는, 전체 프로젝트 중에 짧다면 짧은 기간인 테스트 기간 동안 프로젝트의 모든 파트와 수도 없이 접할 수 있다. 물론 레드마인 등의 프로젝트 관리 도구를 사용하여 결함을 등록하겠지만 레드마인은 어디까지나 문서화와 관리를 위한 도구다. 상주 프로젝트인데 레드마인에만 등록해두고 마냥 기다릴 필요가 없다. (비상주의 경우에도 필요하다면 대면 회의, 전화를 활용해야 한다.) 테스트의 세계란 정말 무궁무진해서, 뭔가 안 되는데 1. 이게 진짜 결함인지 2. 기획/정책/디자인/개발상 의도한 부분인지 3. 일시적 서버 오류인지 4. 단말기/OS 이슈인지 5. 내부망 이슈고 릴리즈 되면 해결될 문제인지 6. 결함은 아니고 제대로 개발은 된 건데 하다 보니 방향이 좀 바뀌어야 하는 건지 아리까리할 때가 많다. 본인이 아무리 담당자라고 해도, 프로젝트의 1부터 10까지를 다 알고 있다고 해도 뭔가 정말 헷갈리거나 이상하면 해당 파트로 달려갈 줄 알아야 한다. 서비스의 품질을 높이겠다고 찾아가는 건데 싫어할 사람은 없다. (크런치 모드로 몇 주째 야근 및 주말 출근 중이라면 가끔 짜증 낼 수도 있다)
이 단계가 마냥 낭만적이지는 않을 것이다. 보통 테스트 단계에서는 크런치 모드에 돌입한 경우가 많기 때문에 다들 피곤하고 한껏 날이 서있다. 의사소통 과정이 잘못 전달되었을 수도 있고, 결함이 맞는데 해결 진척이 영 안 날 수도 있다. 사실 프로젝트하는 동안 테스트 단계에서 가장 많이 싸운다. 니 탓이니 내 탓이니도 하고... 갑자기 개발자가 연락두절되거나 튀기도 하고... PM이 소리도 치고... 현업에서 갑자기 이상한 방향으로 치고 들어오고... ㅎㅏ... 첫 프로젝트 때는 그냥 진행만 하느라 진이 빠졌었고, 두 번째 프로젝트는 진행하다 울기도 했는데 그냥 지금은 필요하면 쌈닭이 되기도 한다. 다시 한번 강조하지만 업무를 진행함에 있어 아닌 건 아니라고 할 수 있어야 한다.
테스트 단계에서는 앞 단계와 달리 급박한 의사결정이 많이 일어난다. 오픈 전까지 결함 처리가 완료되지 않았을 경우 처리 범위와 오픈 후 개선 건으로 넘길 범위를 정한다. 크리티컬한 결함 발생 시 정책 수정이나 오픈 일정 연기를 논의하기도 한다. 프로젝트가 얼마나 잘 진행되었는지는 앞선 단계에서 분위기로 한껏 느꼈겠지만 테스트 단계에서는 진하게 체감된다. 프로젝트에서 오는 스트레스의 반 이상은 테스트에서 온다고 봐도 무방하다. 그만큼 중요하고 빠르게(정신없이) 진행되는 단계다. 보안성 점검과 오픈 시나리오까지 협의하고 나면 어찌저찌 테스트 기간이 끝난다.
10. 오픈/안정화
그렇게 테스트를 열심히 했는데도 오픈하면 어디서 듣도보도 못한 결함이 나온다(!) 테스트 서버와 운영 서버의 환경은 다르고, 실제 운영에 릴리즈 됐을 때 사용자들은 시나리오대로 움직여주지 않기 때문이다. 테스트 때는 잘만 되던 기능이 이상하게 운영 서버에만 가면 안 되는 경우가 있다(사실 많다). 오픈 이후에는 결함을 계속 처리해서 서비스를 궤도에 올려놓는 작업을 한다. 계약 시에 안정화 기간을 빼먹거나, 파트너사 쪽에서 무상 유지보수 기간을 이유로 들어 개발 기간까지만 기간으로 잡기를 요청하는 경우가 있다. 얼마나 완벽히 진행된 프로젝트이건 간에 오픈 이후에 전혀 문제없이 돌아가는 서비스는 없다. 반드시 최소 2주 정도의 안정화 기간을 잡기를 바란다.
11. 프로젝트 마무리
보통 안정화 기간과 병행한다. 파트너사에서 프로젝트 산출물을 제출하고, 운영팀에 각 파트별 인수인계를 진행한다. 프로젝트 산출물에 보고 자료가 있는 경우 프로젝트 기간 중 각 시기에 맞춰 착수/중간/완료 보고를 하기도 한다. 등록된 결함 중 프로젝트팀에서 처리해야 할 범위와 운영 이관 건을 협의한다. 모든 사항을 확인 후 검수서에 날인하고, 사무실에서 퇴거하시고, 잔금까지 치르면 프로젝트 끝!
다는 아니고요 이렇게 끝나기도 합니다쓰다 보니 생각보다 길어지기도 하고 약간 토할 것 같아서 계약 대금 지급이나 오픈 시나리오 같은 부분은 좀 날렸다. 아마 이렇게 글로 써둬도 실제로 몸으로 부딪히면서 접하는 프로젝트는 다를 것이다. 무엇보다 프로젝트가 정해진대로 흘러가는 꼴을 못 봤다 (...) 뭐 대충 그렇게 다 우당탕탕하면서 하는 거죠. 어지간히 깽판을 치지 않으면 다 시간이 지나면... 다 미화되니까요... 지금 너무 힘들어도 다른 프로젝트 하면서 보면 그게 그렇게 좋은 프로젝트였을 수 없습니다... 죽어도 미화되지 않는 프로젝트도 물론 있지만요. 다들 프로젝트에서 몸건강 정신건강 챙기시고 건승하시길 바랍니다. 화이팅.
