기획이 개발에 대해서 잘 알아야 할, 9가지 요소...
개발의 구조와 개발자의 관점에 대해서 이해해야 합니다.
소프트웨어 공학을 전공하고,
소프트웨어 개발을 20년을 넘게 진행해도...
완벽하게 만들어진 기획서는 본 적이 없습니다.
물론, 완벽을 추구하거나 필요한 요소들이 충분하게 구성된 기획서는 자주 봅니다.
그런 기획서가 있다고 하더라도,
개발이 정확한 시간과 일정, 리소스에 맞추어서 진행되는 상황이 어렵기 때문에
기획과 개발은 정말 손발을 잘 맞추어야 합니다.
소프트웨어 개발 현장의 구성과 진행은
기확자들이 보기에는 정말 이상하다는 생각이 들 정도로 이상하다고 느낄 것입니다.
가장 크게 고려해야 할 첫 번째 요소는...
제대로 된 개발 리소스 투입 와 일정을 잡는 것입니다.
물론,
제대로 된 리소스가 투입되어 개발이 진행되는 사례를 본 적이 없습니다.
( 그런 조직에 근무하는 기획자나 개발자라면... 천국이라고 이야기하고 싶습니다. )
어차피, 희망적인 목표와 줄어든 인력, 리소스의 부족으로 소프트웨어 개발은 늦어집니다.
다른, 이유를 찾을 필요가 없습니다.
어차피, 개발자와 제대로 상의하지 않고,
해당 개발자들이 다른 서비스 유지보수를 하고 있다면...
소프트웨어 개발은 '정확하게 일정'이나 '개발목표'를 준수할 방법이 없습니다.
둘째. 기획자는 개발목표를 중간에 바꾸면 안 됩니다.
매우 당연하게 중간에 개발 목표가 바뀌면, 범위가 바뀌고, 아키텍처가 바뀝니다.
만들고 있는 건물의 방향을 5도 틀어달라고 하는 것과 똑같습니다.
개발 목표가 바뀌면, 다 바뀝니다.
그래서, 기획이 정말 제대로 되어야 합니다.
개발 목표가 변경되지 않는 계획을 세우는 것이 최선입니다만...
대부분은 개발 중에 개발 목표가 바뀝니다.
물론, 비즈니스 상황이 변경되어, 개발목표가 변경될 수 있죠.
그렇다면, 매우 당연하게 소프트웨어 개발 일정도 같이 조정되어야 합니다.
셋째. 개발 프로세스는 그냥, 규칙의 하나일 뿐입니다. 유연해야 합니다.
애자일이건, 대단한 소프트웨어 공학들이건... 해당 방법론들 대부분은 장기간, 하나의 목표를 도달하는 업무에 적합한 미국식 방법입니다.
한국의 어설픈 인사 시스템과 부정확한 목표, 만들어봐야 시장의 구조가 작은 한국에서 프로세스를 맹신할 수 있는 곳은 아마도, 대기업만 가능할 것입니다. 최소한 그들은 더 큰 시장을 목표로 하고 있으니까요.
스타트업에서 프로세스는 개발자 커뮤니케이션을 최소한의 단계로 조절하는 것이 최선입니다.
사실, 방법론의 대부분은 테일러링이라는 과정을 통해서, 방법론을 팀의 능력과 상황에 맞추어서 구성하는 것을 기본적으로 제시하고 있습니다.
( 다만, 한국에서는 이 과정을 그냥 생략하거나, 기본을 건너뛰는 곳이 많습니다. 리소스가 부족하거나, 기본이 부족한 결과물들은 매우 당연한 형태로 결과가 정리될 뿐입니다. )
넷째. 개발자는 점쟁이가 아닙니다. 그리고, 마법사도 아닙니다.
그 누가 미래를 예측할 수 있겠습니까?
완벽을 추구한다는 것 자체가 무리인 상황도 많습니다. 최선을 다하는 개발자라면, 그들을 믿는 것이 최선이지, 그들이 점쟁이가 되어서, 미래를 완전하게 예측하게 해달라고 하는 것은 말 그대로, 그들을 신뢰하지 않는 것입니다.
언제나, 추상적으로 접근하고, 최대한 '한계'를 넘어서고, '문제'를 해결하는 것에 집중합니다.
그들은 예측한 일정을 지키려고 최선을 다할 뿐입니다.
최선을 다하는 개발자를 신뢰해야 합니다.
다섯째. 제발, 요구사항 바꾸지 마세요. 데이터 모델은 '콘크리트'나 '바위'에 해당합니다.
요구사항은 개발자로 하여금, 여러 가지의 데이터 모델을 만들게 됩니다. 저장되는 데이터 모델, 전송되는 데이터 모델, 내부 연산이나 정의를 위한 데이터 모델, 서버와 앱이 주고받을 데이터 모델 등... 정말 많은 데이터 모델을 만들어 냅니다.
기획된 내용이 설계가 되면서, 데이터 모델은 그대로 '바위'처럼 변합니다.
개발자들이 가장 스트레스받는 것은 해당 데이터 모델을 통해서 만들어지고, 전송되고 저장이 되어야 하는데, 이 구조가 변경되는 요구사항이 변경되거나, 이해당사자의 변덕에 의해서 해당 상황이 발생되면, 매우 괴로워합니다.
소프트웨어 개발에 있어서 데이터 모델이 구성되었다는 것은, 개발 목표나 요구사항 변동에 대해서 유연하게 대응하기 어렵습니다.
물론, 더 유연한 데이터 모델을 만들 수 있고, 그 방법을 통해서 서비스를 만들 수 있습니다.
문제는... 성능상의 이슈와 품질 이슈가 발생되고, 결제나 보다 명확한 데이터 모델이 필요한 경우에는 유연한 서비스 모델을 만들라고 요구하는 것은 매우 무리한 요청입니다.
여섯째. 개발자는 단순화하면서, 복잡성을 제거하려 합니다. 하지만, 그 이유로... 서비스가 제대로 동작하지 않을 수 있습니다.
개발자들의 특징이 있습니다.
복잡한 일상생활이나 요구사항들을 조각조각 나누고, 일반화시키고, 단순화시켜야만, 소프트웨어 개발이 가능해집니다. 문제는 이 과정에서 서비스의 특이성이나 기획이나 비즈니스 모델의 장점이 사라질 수 있습니다.
또한, 앞뒤를 잘 잡아둔 기획을 무너트리는 구조를 만들 가능성도 있습니다.
개발자들이 단순화하는 방향성을 잘 구성해주고, 구도를 잡을 수 있는 기획서가 필요합니다.
개발자들이 단순화를 취하되, 필요한 장점을 지킬 수 있도록 말이죠.
일곱째. 사용자 UI의 변경에 적응할 여유를 어떻게 잡는가의 문제
앱에서 UX의 기능이 변경되고, 하나의 체크박스를 넣기 위해서 복잡한 서버 API가 추가되어야 하고, 데이터 모델이 변경되고, 앞뒤의 UI의 기능들이 변경될 수 있습니다.
제대로 된 사용자 흐름을 디자인했다면, 사용자 UI의 변경에 유연하게 대응하겠지만, 기획단계에서 사용자 흐름과 데이터 모델의 정합성을 맞추는 작업을 하지 않았다면, UI 변경을 하게 되면, 개발 기간은 심각하게 영향을 받게 됩니다.
여덟 번째. 서비스 품질을 원한다면 느려야 합니다.
안타깝지만, 기획이 불완전하고, 마켓의 정의가 잘 되지 않고, 사용자의 피드백에 의해서 서비스가 변경되는 것이 명확하다면, 서비스 품질은 당장 기대할 수 없습니다.
이해당사자들이 모여서, 디자인 검토를 하고, 수정을 해야 하는 과정을 진행해야 합니다.
가능한 작은 기능을 빠르게 만들고, 전체를 완성할 수 있는 기획이 되어야 합니다.
서비스는 기획자의 욕구를 실현하는 곳이 아니라, 사용자를 위한 서비스를 만드는 것이라는 것을 잊으면 안 됩니다.
아홉 번째. 개발자가 정시 퇴근한다고 일을 안 하는 것이 아닙니다.
개발자들의 정신구조는 분명하게 비개발자들과 다릅니다.
개발자들을 유심하게 지켜보면, 그들은 지금 만들고 있는 서비스에 대해서 머릿속에 계속 몰입하고 있습니다. 그 몰입도를 기반으로 서비스 모델에 대해서 구성하고 있고, 해당 코드를 만들기 위해서 필요한 자료들이나 주변의 동료들에게 관련 정보들을 수집하고 있을 것입니다.
물론, 개발자들이 밤을 새워가면서, 코딩에만 몰입하면 좋겠죠.
매우 당연하게, 그런 열정을 불태울 수 있는 완벽한 기획서를 제공한다면, 대부분의 개발자들은 불타오를 것입니다.
개발자들이 정시 퇴근하는 이유의 대부분은 불완전한 기획서로 인한 커뮤니케이션이 증가하고, 그 커뮤니케이션 증가를 통한 스트레스와 업무의 영향도 때문입니다.
구체적인 목표가 명확하고, 필요한 단계가 일정하다면, 개발자들은 말하지 않아도, 필요한 개발을 최대한 하려고 애를 쓰고, 더 멋진 결과물들을 만들기 위해서 애를 쓸 것입니다.
뭐, 그렇지 않은 개발자가 있다고요?
그럼, 개발 조직을 믿으세요. 그런 개발자들은 선임 개발자나 개발 총괄하는 사람이 가만 놔두지 않습니다.
.
.
.
기획자와 개발자는 언제나 한 팀이기를 바랍니다.
다만, 개발자들은 '실 서비스'를 만들고, '실 서비스'를 운영하는 사람들입니다.
더군다나,
스타트업의 개발자들 대부분은 DevOps의 환경이어서...
서비스 운영과 개발을 동시에 진행하고 있고,
버그나 운영상의 미스가 발생하면...
이를 해결하기 위해서 모든 신경을 곤두세웁니다.
개발자들의 냉정한 말투...
조금은 책임을 회피하는 듯한 발언은...
개발자들 스스로의 문제를 먼저 찾는 것이라고 생각해야 합니다.
개발 조직이 좀 더 규모 있는 조직으로 가면 갈수록...
개발자들은
좀 더 자기 계발 범주를 축소하려고 합니다.
개발 조직의 단계와 프로세스를 지키도록 노력하시고...
그 단계를 유지하면서...
기획서를 더 다듬도록 노력해주시기 바랍니다.
우리는 한 팀입니다.
ps.
댓글과 다른 분들의 의견들을 보고 참조하여, 몇가지 추가글을 끄적거립니다.
첫째. 이 글은 철처하게 개발자 관점에서 쓴 글이 맞습니다.
둘째. 이 글에는 몇가지 전제조건을 서술하지 않았습니다. 개발주기나 타임박스, 스프린트 주기에 대한 언급이 없습니다.
셋째. 비즈니스 요구사항의 거시적인 관점에서의 요구사항 변화라는 관점으로 보는 제 글은 틀린 주장입니다.
그래서, 제 글이 맞지만 틀렸다는 이야기에 공감합니다. ( 뭐, 일부러 그런 논란이 있기를 바라기도 했습니다. )
답변이 아닌 추가 설명으로 끄적거리는 것은...
스프린트 주기가 짧은 경우에는 제 주장이 맞다고 생각하고, 제 글은 '스타트업'을 대상을 전제조건으로 글을 쓰거 있는 관점에서는 맞다고 군시렁 거려봅니다. ( 언제나 주장은 배경과 그 상황이 주관적일 수 밖에 없습니다. )
그리고, 이 짧은 개발 주기에도 극단적으로 어제와 오늘, 내일의 기획서가 변경되는 불행한 사태를 겪고 있는 개발자들을 위한 위로의 글이기도 합니다.
기획자와 개발자가 한팀으로 일하는 조건을 이렇게 한번 더 정리하겠습니다.
첫째. 비즈니스 모델은 변화하는 것이 맞고, 비즈니스 요구사항이 변경되는 것은 맞습니다.
둘째. 기획자는 그 변화의 충격을 잘 관리하고, 변화되는 블럭을 잘 단계별로 구분합니다.
셋째. 개발자는 가능한 해당 블럭을 짧은 주기에 잘 만들어 내고, 기획자가 만드는 블럭의 구조와 다음 단계를 이해해야 합니다.
넷째. 가능한 하나의 타임박스, 생명주기, 스프린트 주기는 최소의 팀과 조직에 맞는 단위로 쪼개져야 합니다. 2~4주 정도가 됩니다.
다섯째. 한번 만들어진 블럭과 타임박스 동안의 요구사항 변화는 최소화 되어야 합니다. 아니, 극단적으로 없는 것이 좋습니다.
여섯째. 부득이하게 추가 요구사항이 발생된다면, 해당 스프린트는 실패 처리하고, 새로운 요구사항이 들어간 스프린트가 새롭게 생성되어 움직이는 것이 현명합니다. ( 실패한 스프린트는 배포하지 않는 것이 원칙입니다. )
다시 한번 이야기 드립니다.
기획자와 개발자는 한팀이 되어야 합니다.
그리고, 개발자 관점에서 이야기드린다면...
기획자는 비즈니스에 유연하고, 개발 프로세스의 단계에 대한 이해와, 변화관리를 잘하는 것이 맞습니다.
그런, 기획자들을 많이 만나고 싶네요.
글을 쓰다보니, 또 개발자 관점이네요.
그래서, 다른 관점인 '기획자'관점으로 정리한 글도 있습니다.
https://brunch.co.kr/@supims/605
관점이 다르면, 서로 이해해야할 몫도 다릅니다.
기획자는 개발자를 이해하고,
개발자는 기획자를 이해하기를 바랍니다.
