#2 기술 검토 및 일정
- 기술 검토
- 기능 분석
- 업무 일정 산정
- 피드백 및 반영
프로젝트의 기획서를 통해서 나타난 기능들에 대해 분석하며 기술적으로, 일정적으로 가능성을 따져야 한다.
프로젝트를 통해서 만들고자 하는 다양한 기능들이 있을 것이다.
만들고자 하는 기능들은 브레인 스토밍을 통해서 나오거나 막연하게 만들었으면 하는 그런 기능들이 있다.
그렇기에 실제의 개발에 들어가기 전에
기술적으로 해당 기능을 우리 팀에서 만들 수 있는지,
그것이 산정된 일정 내에 가능한 것인지,
일정 내에는 무엇을 만들것인지,
등을 선제적으로 파악하는 기술 검토를 해야 한다.
#2-1 기술 검토
기획서를 통해서 정리된 기능들은 대부분 구현이 가능한 것들이다.
하지만 때로는 새로운 기술을 도입하거나, 기존에 회사에서 제공하지 않았던 것들을 제공하거나, 새로운 것을 도입하려고 하는 경우가 있다.
이럴때는 실제의 개발에 들어가기에 앞서서 해당 기술이 현재의 개발 인력 및 기술로 구현이 가능한 기술인지를 따져야 한다.
예를 들어서, AR 카메라를 만들다고 가정해보자.
필자가 경험 했던 경우인데 카메라를 통해서 AR 기술을 통해 동물들을 화면에 보여주는 기능을 넣으려고 한다면 무엇을 고려해야 할까?
가장 먼저 해당 기술이 구현이 가능한가를 따져야 한다. 이때 가장 좋은 방법은 우리가 만들고자 하는 것을 이미 제공하고 있는 서비스가 있는지 찾는것이다. 누군가가 만들었다면 당연히 우리도 만들 수 있기 때문이다.
그리고 그 다음은 그러한 기술이 우리가 지원하고자하는 다양한 os 와 device 에서 동작을하는지 파악해야한다.
우리가 만들려고 했던 동물AR 기능은 웹으로 구현하기에는 무리가 있었다.
또한 Desktop 에서는 지원하지 않고 Mobile 에서만 지원이 가능했다.
게다가 Mobile 도 모두 다 지원이 가능한것이 아니고 일부 버전 이상의 Mobile Device 에서 지원이 가능했다.
또한 iOS 와 AOS 의 구동 방식이 달랐기 때문에 하나의 동물당 두벌의 AR 정보가 필요했다.
이러한 식으로 차근차근히 실제의 개발이 가능한지 기술적으로 검증이 필요하다.
그리고 그렇게 검증을 해 나가면서 해당 기능이 일정내에 가능한 기술인지를 파악해야 한다.
만들고자 하는 것은 그 무엇이든 만들 수 있는 것이 개발자이다. 물론 기존에 존재하고 있는 것이라면.
하지만 만들 수 있다고 할지라도 충분한 기간이 없이는 만들수가 없다.
그렇기에 신기술을 학습하고 적용을 하는 것이 기간 내에 가능한지
만약 그렇지 않다고 한다면 내부 인력이 아니라 외부의 인력을 쓰거나 다른 회사를 통해서라도 해당 기능을 만들것인지 등에 대한 의사결정 논의 과정이 필요하다.
이러한 것들이 기술 검증 과정에서 충분히 이루어져야한다.
이 과정이 모두 끝난다면 이제 남은 것인 기획과 구현이 가능한 기능들이다.
#2-2 기능 분석
구현이 가능한 기능들만 남았다고 해서 모두 다 구현이 가능한 것은 아니다.
위에서 언급한 것처럼 구현이 가능한 기능들은 그에 걸맞는 충분한 일정이 있어야 한다.
간단한 홈페이지를 만들려고 해도 그에 걸맞는 일정이 필요하다.
상용되는 서비스를 만들어야하는 개발자의 입장에서 또한 충분한 일정이 필요하다.
그리고 그런 일정이 필요하다는 것을 정확한 자료를 통해서 내부 개발자와 외부 협엽 부서가 충분히 그리고 합리적으로 이해할 수 있어야 한다. 이때 필요한 것이 바로 기능 분석이다.
쉽게 말해 기능 분석이라는 것은 만들고자 하는 것들을 쪼개서 분석하는 것이다.
만들려고 하는 모든 기능들을 목록화 하는 것이다.
홈페이지를 만들려고 한다면
여러가지의 페이지들로 홈페이지를 나눌 수 있을 것이다.
그리고 이때 화면에 보이는 페이지 외에 페이지의 뒷 단에서 일어나는 기능들 또한 가늠해볼 수 있다.
하나의 페이지는 또 여러개의 화면 구성요소로 이루어져 있다.
이렇게 여러가지의 구성요소로 페이지를 쪼갤 수 있는 것이다.
또한, 눈에 보이지 않는 프로젝트 전체의 구조를 잡는다거나 데이터 구조를 잡는 등의 개발 설계에 대한 내용들도 있을 수 있다.
프로젝트를 쪼개고 쪼개서 분자 단위의 기능들로까지 쪼갠다면 해당 기능들은 구현 가능한 레벨이거나 그 위의 단계까지 목록화가 가능해진다.
또한, 이렇게 나누는 과정에서 기획이나 설계 단계에서는 미처 잡지 못 했던 놓쳤던 기능들에 대해서도 한번 더 미리 생각해볼 수 있는 여지가 생기게 된다.
그렇게 된다면 프로젝트 진행 도중 갑자기 새로운 기능 또는 미처 놓쳤던 기능이 나타나서 일정을 당황시키는 경우를 예방할 수 있다.
프로젝트를 분석해서 다양한 기능들의 목록으로 만들자.
#2-3 업무 일정 산정
그렇게 만들어진 기능들의 목록은 수십, 수백 어쩌면 수천, 수만개로 이루어져있을지도 모른다.
그 양은 사실 압도당하기 쉽지만 차근 차근 하나씩 개발해 나가다보면 어느새 일정 내에 핋요한 기능들을 모두 소화할 수 있을 것이다.
그렇기 위해서 쪼개 놓은 모든 기능들의 일정을 산정해야 한다.
이때, 먼저 기능들을 누가 만들것인지 역활을 구분해 두면 좋다.
프로젝트를 혼자서 진행한다면 모두 다 내가 만들어야 하지만
같이 개발하는 동료들이 있다면 각각의 업무를 동료들과 나눌수가 있을 것이다.
그렇게 업무를 모두 개략적으로 먼저 나눈다. N빵으로 또는 비슷한 것들을 묶어서 나누면 좋다.
각자는 나누어진 각 기능들을 어느정도 걸려서 만들 것인지 계산해 보아야 한다.
이때 필요하다면 다시 한번 기능을 쪼개는 것도 필요하다.
그렇게 각자가 일정을 산정해본다면 다 같이 모여서 다시 한번 전체 기능들에 대해서 일정을 조율하는 것이 좋다.
누군가는 처음 만들기때문에 오래 걸리는 것이 누군가는 경험이 많아서 좀 더 빠르게 만들 수도 있다.
이때 필요하다면 익숙한 사람에게 배분을 해서 일정을 조율 할 수도 있게 된다.
그렇게 모여서 조율된 일정은 순차적으로 구성이 가능할 것이다.
누구나 하루의 업무 시간은 8시간이기 떄문이다.
각 사람별로 업무시간 별로 업무를 병렬로 시간의 흐름에 맞춰서 구성을 한다.
그렇게 되면 모든 기능들을 구현 가능한 전체의 일정 시간이 계산될 수 있다.
#2-4 피드백
그렇게 산정된 일정은 순수한 개발 일정일 것이다.
또한 기능들의 목록의 수에 따라서 일정의 길이 또한 결정된다.
그렇다면 프로젝트의 기간내에 가능한 일정이라면 큰 문제가 없지만
프로젝트의 기간을 넘어서는 일정이라면 조율이 필요하다.
모든 기능을 일정내에 개발 할 수 없다는 의미인 것이다.
물론 프로젝트의 일정을 개발 일정에 맞추어서 늘리는 방법도 있지만
대부분 그렇게 일정이 초과할 경우 중요한 기능들을 먼저 개발하고 중요하지 않는 것들을 후반부에 개발을 하게 우선순위를 조율할 수 있게 된다.
그렇게 일정을 조율하다보면 일부의 기능들은 현재 프로젝트 기간내에 못 만들게 되어 스펙아웃이 되기도 하고 2차 개발 일정으로 넘어가게 된다.
이러한 피드백 과정을 서로 거치다보면 최종적으로 개발 기간내에 가능한 기능들이 남게 된다.
이제 남은 일은 개발 하는 일이다.ㄴ
