brunch

브런치북 스타트업 종사자를 위한 네번째 11화

라이킷 30 댓글 1

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 신현묵 Jul 19. 2019

개발 속도를 증가시키는 기획의 팁!

비즈니스 구조를 이해하고 만들어야 함. 개발 구조가 아니라...

개발자에게 '이거 1개만 더 추가하면 됩니다'

라는 말의 의미가...

이미 올라간 건축물에 대해서...

'이거 건물 위치를 1cm만 옆으로 옮겨주세요.'

라고 이야기하는 것과 비슷하다는 것을 기획자들은 알아야 한다.

비슷한 말로...

'건물 중간에 층수 하나만 더 넣어주세요'도 있다.

그렇다면, 그런 상황을 나중에 하지 않고, 미리미리 더 좋은 성과를 내기 위한 방법을 이야기해보자.

기획에서 개발 속도를 증가시키는 팁이 몇가지 있다.

첫째. 사용자에게서 획득되는 정보의 흐름과 데이터의 내용이 초반에 명확해야 한다.

대부분의 사용자 흐름, 사용자 UX는 이 흐름과 권한, 발생 시기와 저장, 체크하거나 획득하는 것들에게서 변화가 발생한다. 초기에 이 흐름을 잘못 잡으면 개발자들에게 매우 큰 고통을 주게 된다.

그래서 다음과 같은 내용들은 초반에 조사되어야 한다.

- 해당 정보가 특정 규제나 법규, 규정 등에 영향을 받는 것에 대해서는 정말 명확해야 한다.

- 데이터의 크기, 길이, 정합성에 대한 명쾌한 규정

- 데이터가 의미하는 것과, 데이터 상호 간의 규칙과 연관성

- 데이터의 획득 시기, 입력 시기, 수정이 되거나 변경되는 시기

- 데이터가 가지는 수명과 한계, 보호해야 할 것들

그리고, 데이터가 생성되는 각각의 트랜잭션에 대해서 명세가 나열되어야 한다.

데이터 1,2,3이 한 번에 생성되는지, 각 단계에서 취소되거나, 복원되거나, 선택되어야 하는 것들에 대한 상태 값과 각 데이터의 수치나 수량이 의미하거나, 받지 말아야 할 값들의 형태

기획자들이 해당 데이터의 흐름에 대해서 명확하게 현업이나 비즈니스 모델에서 추출하지 못하면, 대부분의 서비스나 데이터 단계, 화면들은 큰 변화와 고통을 가져오게 된다.

이 단계에서 사용자의 UX단계까지 더 정리가 되면, 향후.. 데이터 정제에도 매우 유용하니 이 부분을 간과하지 말자.

둘째. 한 화면에 너무 많은 기능을 넣으려고 하지 말아라.

고객이나 사용자의 '의사결정'을 하거나 '정보성', '참조'의 의미 등에 대해서 잘 구분하면서, 한 화면에서 너무 많은 기능을 넣으려고 하게 된다면, 개발 속도가 떨어지고, 작업량도 늘어나게 된다.

가능하다면, 기능을 최대한 분산해서 정리하는 것이 좋다.

특히, 화면에서 특정 선택이나 기능 변경 등에 따라서 화면에 표시되는 데이터의 필터링이나 변경 등의 기능들이 복합적으로 들어갈수록, 기능은 점점 복잡해지고, 개발은 더욱더 늘어지게 된다.

셋째. 기획과 개발 구조를 일치시키려고 하지 말아라.

개발자의 개발 구조에 대해서 너무 많은 이해를 하려고 하면서, 오히려 기획의 구조가 흐트러지게 되고, 개발 구조에 영향을 주게 된다.

개발 구조는 초기의 데이터 흐름이 명쾌하다면, 해당 문제들은 개발자들 스스로 해결하기 위해서 움직일 것이다. 기획은 기획의 구조가 흔들리지 않고, 사용자의 데이터의 발생 시기와 흐름 등이 흔들리지 않게 되어야 한다.

이 흐름이 계속 변화한다고 하면, 처음부터 변화의 요인에 대해서 개발자에게 '사실'을 전달하면 되는 것이다.

기획과 개발 구조는 상이하고, 고민하는 방법도 다르다.

넷째. 99%는 아니지만, 1%라도 등장한다면, 그것은 매우 덩치가 큰 기능일 수 있다.

기획자들이 착각하는 것 중의 하나는 '만의 하나 이런 기능'이 필요할 수 있다고 정리하면서, 해당 기능을 중요하지 않은 것처럼 정리하게 되고, 실 서비스에 들어갔을 때에 해당 기능 때문에 못 사용하겠다고 하는 '고객'때문에 결국, 개발자는 다 만들어진 건물을 1cm 옮기게 되는 현상을 일으킨다.

1%, 1번이라도 동작하는 것이라면 그것은 그냥 '기능'이다.

개발 일정에서 소홀하게 다룰 수 없다는 것을 잊으면 안 되고, 해당 기능을 동일한 가중치로 관리해야 한다.

다섯째. 전체 흐름을 계속 파악하고 있어야 한다.

비즈니스의 흐름과 서비스의 흐름의 범위에 대해서 명확하게 구조를 잡고 있어야, 개발자들을 괴롭히지 않게 된다. 이는 개발 구조가 아니다. 기획자 자신이 알고 있는 비즈니스 흐름이 흔들리거나, 데이터의 발생 시기, 변화 시기, 수정되는 시기가 발생하면...

이는 개발 구조에 큰 변화를 일으킨다.

전체적인 흐름에서 해당 구조를 초기부터 잘 잡아야, 개발자들이 속도를 낼 수 있다.

마지막으로...

개발 속도를 증가시키는 기획자의 가장 큰 팁은...

점진적으로 프로덕트를 완성할 수 있도록 작은 규모로 목표 시스템을 제안하는 것이다.

그리고, 해당되는 작은 규모는 '개발 규모'가 아니다.

데이터가 움직이고, 그 데이터를 기반으로 비즈니스가 동작할 수 있는 작은 규모를 의미한다.

이는 개발을 몰라도 되는 이유이기도 하다.