개발이 기획에 대해서 잘 알아야 할, 9가지 요소
기획의 구조와 기획의 개념에 대해서 이해해야 합니다.
기획서가 하나 만들어지고, 비즈니스가 실제 서비스로 전환될 때에 발생되는 수많은 경우의 가짓수와 사용자의 흐름, 유용한 가치에 대한 고민은 기획 역할을 가진 사람들의 가장 큰 이슈입니다.
기획자들은 언제나 비즈니스나 서비스를 최대한 유용하고, 유의미하게 만들려고 노력하고, 개발과정에서의 변화를 최소화하기 위해 노력합니다.
기획자들이 보기에는 개발단계에서 언제나 깔끔하게 만들어진 기획서를 제공해도, 완벽하게 소프트웨어나 서비스가 구성되는 경우를 본 적이 없습니다.
개발과정에서 언제나 생략되는 기능이 있거나, 기획의도가 제대로 전달이 안되어서, 개발자 관점으로 변경된 구성이 나오기도 하고, 심지어 전혀 엉뚱한 결과물이 나오기도 합니다.
소프트웨어 공학이라는 관점에서 이를 해석하는 것은 그냥 절차와 단계에 대한 설명일 뿐, 현재의 개발과정과는 많은 괴리가 존재합니다. 많은 스타트업이나 소프트웨어 개발단계의 구성이 이렇게 복잡해지고, 다양한 관점이 존재하는 시대는 첫 출현인 듯합니다.
개발자가 이러한 관점에서 기획에 대해서 알아야 할 중요한 9가지를 정리해보겠습니다.
첫째. 요구사항은 매우 당연하게 변경됩니다.
완전한 요구사항이 수집되고, 만들어진 버전이 꾸준하게 유지되는 단계의 소프트웨어 개발은 솔루션 개발이거나, 특정 업무용 소프트웨어를 기반으로 움직이는 상황에서는 이 역할이 가장 중요합니다.
하지만, 스타트업 대부분은 완성되지 않은 비즈니스 모델과 급변하는 사용자 요구사항에 따라서 초기에 거창한 기획들을 모두 넣어서, 개발을 진행할 수 없습니다.
이 경우 매우 당연하게 요구사항은 변경됩니다.
개발자 스스로 요구사항에 탄력적으로 대응할 수 있는 방법을 찾아야 합니다.
둘째. 완전한 기획서를 추구하기 어려울 정도로 개발 주기나 비즈니스 주기가 짧아졌습니다.
중요한 시점과 경쟁사들보다 빠른 접근이 매우 중요합니다.
스케치에 가까운 아이디어 상태와 최소한의 데이터 모델만 디자인된 상태에서, 빠르게 대응할 수 있는 단계를 만들어주는 것이 중요합니다.
셋째. 가능한 기획자들이 상상하기 좋은 프로토타입을 개발자들은 구성하는 것이 좋습니다.
매우 유연하게 프로토타입 도구를 사용하는 기획자도 있습니다만, 대부분의 기획자들은 프로토타입 도구들을 잘 다루지 못하고, 비즈니스 운영이나 개발의 단계를 이해하지 못하는 경우가 많습니다.
목업과 프로토타입 형태로 구현체와 비슷한 형태로 최대한 기획자들이 시각화하기 좋은 형태로 빠르게 대응하는 것이 좋습니다.
넷째. 개발자는 기획자의 의도를 명확하게 파악해야 합니다.
분명, 말로 설명하기 미묘한 기능들이 있으며, 개발 주기가 짧아서 포기하는 기능이나 성능도 있습니다. 기획자가 다음 추가 개발을 하거나, 시간상 이슈가 있는 부분에 대해서 커뮤니케이션하면서 의도를 명확하게 파악해야 합니다.
다섯째. 기획도 개발의 단계입니다. 유연해야 합니다.
개발은 진행하다가 실패하기도 합니다. 기획도 동일합니다. 이때에 서로 비난을 하기보다는, 기획이 잘못되거나, 문제가 있다고 생각하면... 그 부분을 서로 고치도록 노력해야 합니다.
이때에 PM이거나 일정에 대한 권한을 가진 사람에게 기획자와 한 몸이 되어서 개발의 단계 중에 실패와 변화, 수정에 대해서 좀 더 적극적으로 나서야 합니다.
여섯째. 기획자도 점쟁이나 마법사가 아닙니다.
추상적인 비즈니스 상황을 모두 고려하여, 완벽한 기획서를 만들아 고 하는 것은, 기획자들에게 '기적'을 행하라고 하는 것과 동일합니다.
그 어떤 사람들이 '미래'를 모두 예측할 수 있겠습니까?
기획자들이 가능한 개발자와 의사소통할 수 있도록 최소한의 과정을 완성할 수 있도록 필요한 요소와 개발에 필수적인 부분들에 대해서 끊임없이 대화를 나누고, 일을 풀어나갈 방법으로 대응을 해주어야 합니다.
일곱 번째. 기획은 의도를 가지고 있고, 얻어야 할 가치들을 나열하고 있습니다.
개발자적인 관점으로 문제를 너무 단순화하거나, 이해가 가지 않는 다고, 기획자의 의도를 자의적으로 해석하여 서비스를 구현하면 안 됩니다.
기획자가 가지고 있는 가치와 다음번 스탭에 대해서 전방위 적으로 이해를 하는 형태로 접근해야 합니다.
여덟 번째. 사용자 화면은 극단적으로 매번 갈아버릴 준비를 해야 합니다.
많은 개발 플랫폼이나 유연한 사용자 화면을 구성할 수 있는 다양한 기법들이 있습니다. 이 기법들은 최대한 사용자의 사용성을 증가시키기 위해서 지속적으로 발전하고 있는 것들입니다.
기획자는 사용자의 만족과 서비스의 성공을 위해서 매우 끊임없이 해당 화면을 수정합니다.
개발자는 언제든지 화면의 기능 개선과 사용자 만족을 위해서 적극적인 자세로, 기능 수정과 배치 변경, 디자인 변경에 대해서 유연하게 대응해야 합니다.
기획자나 개발자나 유의미한 서비스를 만들기 위한 노력은 동일하니까요.
아홉 번째. 기획자들 역시, 머릿속에 비즈니스 상황과 서비스 상황을 넣고 다닙니다.
기획자들은 책상에 앉아서, 스케치만 하거나, 무의미한 회의 시간을 보내는 사람들이 아닙니다.
비즈니스를 분해하고, 유의미한 기획 요소를 찾고, 사용자의 만족과 서비스의 완성을 위해서 최선을 다하는 사람들입니다.
그들도 정시퇴근을 한다고, 일을 하지 않는 것이 아닙니다.
기획자들 역시, 머릿속에 지속적인 비즈니스 고민을 하고, 정리 룰 하고, 아이디어를 찾고, 그것에 대한 토의를 합니다.
.
.
.
훌륭한 기획자는
야생마처럼 변덕스러운 비즈니스 상황을 이해하고,
개발자들이 최소한의 변화과정을 거칠 수 있도록...
그 충격을 줄일 수 있는 방법을 고민합니다.
짧고, 최소로 개발하고, 최대의 효과를 내기 위해서 고민합니다.
마치, 광란하는 폭풍우가 존재하지만,
카페에서 우아하게 커피 한잔을 마시면서,
폭풍우를 지켜볼 수 있게 해주는 고마운 존재입니다.
거시적인 기획자와 미시적인 개발자의 환상적인 콜라보이거나...
미시적인 기획자와 거시적인 개발자의 역할 분담...
미시적인 기획자와 미시적인 개발자의 알콩달콩...
거시적인 기획자와 거시적인 개발자의 멋진 만남...
언제나,
기획자들은 최대한 비즈니스를 최소 단위로 접근하기 위해서 애를 쓰고 있습니다.
그래야, 서비스 개발이 성공적으로 진행되니까요.
그리고...
반대되는 입장의 글도 다음처럼 있습니다.
https://brunch.co.kr/@supims/603
