웹 프로젝트 진행 과정 한눈에 보기

프로젝트는 윗사람이 만들자고해서 바로 만들어지는 것이 아니다. 또는 아이디어와 만들고 싶은 게 있고, 돈도 있다고 개발자나 개발회사를 섭외해서 바로 만들어지는 것도 아니다. 아이디어가 있다면 아이디어를 어떻게 만들 것인지 상세하지는 않지만, 전체 구상하는 그림은 있어야 한다. 가령, 내 주위의 마스크 판매처를 지도에 표시하면 편리할 것 같다라는 아이디어가 있다. 이 아이디어 하나만 가지고 만들어줄 개발자를 섭외해서 ‘알아서 잘 만들어주세요'라고 요청하는 것은 성형외과에 가서 ‘예쁘게(멋있게) 성형해주세요'와 같이 막막하기만 하다.

---

눈을 좀 더 크게 하고 싶다던지, 코를 더 세우고 싶다던지, 입술을 도톰하게 하고 싶다던지 등등 의뢰자가 제시해야 거기에 맞추어 어떻게 할 것인지 계획을 세우고 진행한다. 예쁘다, 멋있다라는 말의 기준이 사람마다 다르기 때문에 정확한 ‘기준'을 말해줘야 한다. 

 

마찬가지로 내 주변의 마스크 판매처를 지도에 표시하고 싶다라는 아이디어도 내 주변 반경 몇 미터까지인지, 내가 이동하면서 실시간으로 표시해야하는지, 판매처를 지도에 표시만 하면 되는건지, 판매처를 선택해서 경로까지 알려줘야 하는건지, 경로는 걸어서인지, 대중교통인지, 자가용으로 표시하는 건지, 판매처가 약국인지 편의점인지 마트인지 등등의 ‘기준'을 세워야 정확한 개발 계획이 세워진다. 

 

이런 ‘기준'을 IT에서는 요구사항이라고 한다. 

 

처음 요구사항은 너무 자세 할 필요는 없다. 그렇다고 ‘지도에 표시하고 싶다'라는 정말 단순한 요구도 곤란하다. 어느정도 이야기가 될 수 있는 원하는 요구사항은 가지고 있어야 순조롭게 진행될 수 있다.

 

요구사항이 정해졌다 해도 요구사항에 대한 가능성을 살펴 봐야 한다. 현재의 기술로 가능한지, 구글, 다음, 네이버 등 지도 서비스를 하는 회사에서 표시가 가능한지, 이동 중에 실시간으로 검색이 가능한지 등도 고려해야한다. 이러한 기술적 가능성을 알아보는 것을 RFI-Request For Information (정보요청서)라고 한다. 

---

RFI는 몇몇 회사에 기술적 자문을 구하고, 정보를 수집하는 절차이다. 한마디로, 가능성을 타진하고, 필요한 기술을 수집하는 것이다. 가능성이 없다면 포기하거나, 아이디어를 다른 방향으로 수정할 수 있다. 가능성은 있지만, 기술이 많이 들어가고, 돈이 많이 투입 되야 한다면 기능을 축소할 수도 있다.

 

RFI로 정보를 수집했으면, 좀 더 세세하게 어떤 기술을 사용하여 어떤 기능을 만들고 싶은데, 개발이 가능한 업체나 개발자에게 제안을 요청하는 제안 요청서 RFP-Request For Proposal을 만들어 공개한다. 개발업체나 개발자는 RFP를 보고 개발이 가능하면 ‘우리는 이런 기술이 있고, 당신이 만들려고하는 것을 잘 만들 수 있어'라는 제안서를 작성하여 제안을 하게 된다.

---

제안서는 특별한 양식은 없고, 회사소개, 기술력, 개발방향, 프로젝트 관리 등이 포함된다. RFP에 따라 별도의 제안 형식이나 방식을 요구하기도 한다. 제안서 작성은 긴 시간을 주지는 않고, 대체적으로 2주간의 시간을 준다. 제안 업체에서는 시간이 촉박하기 때문에 이 기간동안 옆에 '라꾸라꾸 침대'하나 가져다 놓고 야근이나 밤샘 작업을 하는게 부지기수다.

 

의뢰주는 제안서를 확인하고 몇개를 선택하는 작업을 한다. 제안한 업체가 많지 않고 별 다른 문제가 없다면 바로 시작할 수도 있지만, 제안한 업체가 많으면 선택한 제안서의 업체별로 제안발표를 한다. 제안서로는 부족한 부분을 발표를 통해서 개발 의지나 질의응답으로 한번 더 검증하는 절차이다.

---

최종적으로 하나의 업체를 선정했으면 계약 협상에 들어간다. 이때가 가장 민감한 절차이다. 돈이 오가는 부분이기 때문에 의뢰주 입장에서는 더 깎을려고 하고, 개발자 입장에서는 더 받을려고 서로 줄다리기를 한다. 줄다리기를 하는건 좋은데.. 제발 인건비로 줄다리기를 하지 말았으면 좋겠지만, 대부분 인건비로 줄다기리를 한다. 기능은 다 해야겠고, 실력있는 개발자도 필요하지만 예산은 별로 없으니, 인건비를 건드리는 것이다. 

 

인건비는 그 사람이 지금껏 살아온 경험과 지식을 돈으로 환산한 금액이다. 

 

이런 경험과 지식을 깎는 다는건 인정하지 않는다는 의미이고, 개발자를 무시하는 처사라고 생각한다. 

 

제안한 업체 입장에서도 경쟁업체와 경쟁하기 위해서 경상비나 일정 등을 손보지만, 그래도 경쟁이 힘들다고 느껴지면, 개발 등급에 무리수를 두는 경우가 있다. 경력이 10년 이상이 해야하는 업무를 중급에게 맞긴다던지, 다른 개발 업무를 더 추가하여 서비스로 제공한다던지 하는 경우이다. 이 경우에는 프로젝트 자체가 굉장히 힘들어 진다. 그렇게 해서 프로젝트를 가져온다해도 원활히 잘 진행되기 보다는 오히려 막판에 힘들고, 손해가 발생하는 경우가 많다. 

---

의뢰를 발주한 업체 입장에서는 한정된 예산으로 모든 기능을 개발해야하기에 개발업체를 설득하기 위해 ‘다음 에 챙겨 주겠다'라던지 ‘다음 예산에 좀 더 힘써 보겠다' 등등으로 현 시점을 벗어나기에 급급하다. 이 말을 믿는 업체는 솔직히 단, 한군데도 없을 듯 하다.  

 

어쨋건 이 기간 동안 돈에 따라 기능이 축소 될 수도 있고, 사람이 축소될 수도 있고, 아예 업체선정을 다시 할때도 있다. 

 

계약까지 완료되면 이제서야 프로젝트가 진행된다. 이러한 절차는 큰 프로젝트나 중규모의 프로젝트에는 대부분이 같은 방식으로 진행된다. 소규모나 개인 프로젝트는 프로젝트를 연결해 주는 사이트나 프리랜서를 섭외해서 진행하지만, 초기의 아이디어를 구체화 시키는 것은 어느 프로젝트나 동일 하다. 

 

---