webService.Project.Do
웹 프로젝트 진행 과정 한눈에 보기
프로젝트는 윗사람이 만들자고 해서 바로 만들어지는 것이 아니다. 또는 아이디어와 만들고 싶은 게 있고, 돈도 있다고 개발자나 개발회사를 섭외해서 바로 만들어지는 것도 아니다. 아이디어가 있다면 아이디어를 어떻게 만들 것인지 상세하지는 않지만, 전체 구상하는 그림은 있어야 한다. 가령, 내 주위의 마스크 판매처를 지도에 표시하면 편리할 것 같다는 아이디어가 있다. 이 아이디어 하나만 가지고 만들어줄 개발자를 섭외해서 ‘알아서 잘 만들어주세요'라고 요청하는 것은 성형외과에 가서 ‘예쁘게(멋있게) 성형해주세요'와 같이 막막하기만 하다.
눈을 좀 더 크게 하고 싶다던지, 코를 더 세우고 싶다던지, 입술을 도톰하게 하고 싶다던지 등등 의뢰자가 제시해야 거기에 맞추어 어떻게 할 것인지 계획을 세우고 진행한다. 예쁘다, 멋있다는 말의 기준이 사람마다 다르기 때문에 정확한 ‘기준'을 말해줘야 한다.
마찬가지로 내 주변의 마스크 판매처를 지도에 표시하고 싶다는 아이디어도 내 주변 반경 몇 미터까지인지, 내가 이동하면서 실시간으로 표시해야 하는지, 판매처를 지도에 표시만 하면 되는 건지, 판매처를 선택해서 경로까지 알려줘야 하는 건지, 경로는 걸어서인지, 대중교통인지, 자가용으로 표시하는 건지, 판매처가 약국인지 편의점인지 마트인지 등등의 ‘기준'을 세워야 정확한 개발 계획이 세워진다.
이런 ‘기준'을 IT에서는 요구사항이라고 한다.
처음 요구사항은 너무 자세 할 필요는 없다. 그렇다고 ‘지도에 표시하고 싶다'라는 정말 단순한 요구도 곤란하다. 어느 정도 이야기가 될 수 있는 원하는 요구사항은 가지고 있어야 순조롭게 진행될 수 있다.
요구사항이 정해졌다 해도 요구사항에 대한 가능성을 살펴봐야 한다. 현재의 기술로 가능한지, 구글, 다음, 네이버 등 지도 서비스를 하는 회사에서 표시가 가능한지, 이동 중에 실시간으로 검색이 가능한지 등도 고려해야 한다. 이러한 기술적 가능성을 알아보는 것을 RFI-Request For Information (정보 요청서)라고 한다.
RFI는 몇몇 회사에 기술적 자문을 구하고, 정보를 수집하는 절차이다. 한마디로, 가능성을 타진하고, 필요한 기술을 수집하는 것이다. 가능성이 없다면 포기하거나, 아이디어를 다른 방향으로 수정할 수 있다. 가능성은 있지만, 기술이 많이 들어가고, 돈이 많이 투입돼야 한다면 기능을 축소할 수도 있다.
RFI로 정보를 수집했으면, 좀 더 세세하게 어떤 기술을 사용하여 어떤 기능을 만들고 싶은데, 개발이 가능한 업체나 개발자에게 제안을 요청하는 제안 요청서 RFP-Request For Proposal을 만들어 공개한다. 개발업체나 개발자는 RFP를 보고 개발이 가능하면 ‘우리는 이런 기술이 있고, 당신이 만들려고 하는 것을 잘 만들 수 있어'라는 제안서를 작성하여 제안을 하게 된다.
제안서는 특별한 양식은 없고, 회사 소개, 기술력, 개발방향, 프로젝트 관리 등이 포함된다. RFP에 따라 별도의 제안 형식이나 방식을 요구하기도 한다. 제안서 작성은 긴 시간을 주지는 않고, 대체적으로 2주간의 시간을 준다. 제안 업체에서는 시간이 촉박하기 때문에 이 기간 동안 옆에 '라꾸라꾸 침대'하나 가져다 놓고 야근이나 밤샘 작업을 하는 게 부지기수다.
의뢰 주는 제안서를 확인하고 몇 개를 선택하는 작업을 한다. 제안한 업체가 많지 않고 별 다른 문제가 없다면 바로 시작할 수도 있지만, 제안한 업체가 많으면 선택한 제안서의 업체별로 제안 발표를 한다. 제안서로는 부족한 부분을 발표를 통해서 개발 의지나 질의응답으로 한번 더 검증하는 절차이다.
최종적으로 하나의 업체를 선정했으면 계약 협상에 들어간다. 이때가 가장 민감한 절차이다. 돈이 오가는 부분이기 때문에 의뢰 주 입장에서는 더 깎으려고 하고, 개발자 입장에서는 더 받으려고 서로 줄다리기를 한다. 줄다리기를 하는 건 좋은데.. 제발 인건비로 줄다리기를 하지 말았으면 좋겠지만, 대부분 인건비로 줄다리기를 한다. 기능은 다 해야겠고, 실력 있는 개발자도 필요하지만 예산은 별로 없으니, 인건비를 건드리는 것이다.
인건비는 그 사람이 지금껏 살아온 경험과 지식을 돈으로 환산한 금액이다.
이런 경험과 지식을 깎는다는 건 인정하지 않는다는 의미이고, 개발자를 무시하는 처사라고 생각한다.
제안한 업체 입장에서도 경쟁업체와 경쟁하기 위해서 경상비나 일정 등을 손보지만, 그래도 경쟁이 힘들다고 느껴지면, 개발 등급에 무리수를 두는 경우가 있다. 경력이 10년 이상이 해야 하는 업무를 중급에게 맞긴다던지, 다른 개발 업무를 더 추가하여 서비스로 제공한다던지 하는 경우이다. 이 경우에는 프로젝트 자체가 굉장히 힘들어진다. 그렇게 해서 프로젝트를 가져온다 해도 원활히 잘 진행되기보다는 오히려 막판에 힘들고, 손해가 발생하는 경우가 많다.
의뢰를 발주한 업체 입장에서는 한정된 예산으로 모든 기능을 개발해야 하기에 개발업체를 설득하기 위해 ‘다음에 챙겨 주겠다'라던지 ‘다음 예산에 좀 더 힘써 보겠다' 등등으로 현시점을 벗어나기에 급급하다. 이 말을 믿는 업체는 솔직히 단, 한 군데도 없을 듯하다.
어쨌건 이 기간 동안 돈에 따라 기능이 축소될 수도 있고, 사람이 축소될 수도 있고, 아예 업체 선정을 다시 할 때도 있다.
계약까지 완료되면 이제야 프로젝트가 진행된다. 이러한 절차는 큰 프로젝트나 중규모의 프로젝트에는 대부분이 같은 방식으로 진행된다. 소규모나 개인 프로젝트는 프로젝트를 연결해 주는 사이트나 프리랜서를 섭외해서 진행하지만, 초기의 아이디어를 구체화시키는 것은 어느 프로젝트나 동일하다.
