프로젝트 Flow

피그마를 시작하기에 앞서서 일단은 프로젝트 Flow에 대해서 먼저 간단하게 살펴보겠습니다 일반적으로 프로젝트의 경우에는 요구사항을 분석하고, 설계하고, 구현하고, 테스트하고, 출시 및 유지 보수하는 이런 주요한 과정을 거치게 되어 있습니다 보통 개발을 시작하게 되면 어떤 방식이든 개발 방법론을 적용하기 마련인데요 그 중에 가장 대표적인 게 전통적인 워터폴 방식이 있죠 워터폴 방식 같은 경우에는 요구사항을 분석을 하고 설계를 하고 그다음에 구현을 하고 테스팅을 하고 출시 및 유지 보수까지 하는 이런 과정을 원스텝으로 진행을 하게 됩니다 그런데 우리가 실제 환경에서는 이렇게 한 번에 다 진행되는 경우는 그렇게 흔하지 않죠 프로젝트 기간이 어느 정도 길어지다 보니까 보통은 길어지다 보니까 이 중간에 많은 변화들이 생깁니다 그래서 최근에는 애자일 방법으로 많이 진행을 하게 되는데요 애자일 방법은 스프린트라고 불리는 짧은 기간 동안 이때 설계와 구현과 테스트와 분석들을 다 진행을 하게 됩니다 그래서 요구사항을 분석을 하고요 설계를 하고요 이 중간에 구현이 있겠죠 그 다음에 테스트를 하고 그 다음에 실질적으로 분석을 하고 데모하고 그 피드백을 다시 제품에 반영하고 그리고 또 다음 스프린트를 돌려서 좀 더 다른 기능들 또는 피드백을 반영한 것들을 갖다가 적용하게 됩니다 그래서 여러 차례 스프린트가 돌아오고 나면 결국 완성된 제품으로 출시가 되겠죠 이 과정에서 참 많은 커뮤니케이션이 필요합니다 뭐냐면 요구사항을 분석하는 단계부터 설계하는 과정까지 여기서 굉장히 많은 문제들이 발생을 하는데요 일단은 내가 제품을 갖다가 이런 것을 만들어 달라 요구하는 그런 고객들 또는 내부 구성원이 될 수 있겠죠 내부 구성원들의 아이디어 이런 것들을 모아 가지고 설계를 해야 되는데 이거 갖다가 딱 진행을 하게 되면 원하지 않는 결과를 만들어 낼 수도 있습니다 그 이유 중의 하나는 구성원들이 뭘 만들어야 되는지 명확한 상이 없습니다 그거 갖다가 설계에 따라서 잘 정리를 해줘야 되는데 그런 부분들이 많이 좀 어렵죠 그런 커뮤니케이션들이 많이 어렵기 때문에 우리는 이제 프로토타입이라는 것을 제작을 해서 이렇게 간단한 기능, 핵심 기능들을 가지고 간단하게 만들어 본 다음에 그것들이 구성원들이 원하는, 고객이 원하는 것대로 만들어졌는지 확인하는 그런 절차를 거치게 됩니다 그거 갖다가 만들어내는 걸 갖다가 프로토타입이라고 하고요 그런 프로토타입을 통해 가지고 많은 커뮤니케이션 오류를 줄일 수가 있습니다