개발 조직과 비개발 조직이
하나가 되려면...
어찌 본다면 불가능한 이야기인지도 모른다.
결론부터 이야기한다면..
두 조직은 하나의 조직이 될 수 없다.
단, 그 예외는 분명 존재한다. 그 예외상황을 몇 가지 나열해 보겠다.
하나. 기술적 난이도가 없는 단순 정보시스템을 기반으로 한 비즈니스 모델인 경우에 가능함.
둘. 서비스의 개발보다는, 서비스를 운영하는 형태가 더 중요한 비즈니스 모델인 경우에도 가능함.
셋. 최소의 인원으로 충분한 서비스의 동작이 가능하며, 소프트웨어 품질 이슈가 비즈니스 모델에서 그렇게 중요하지 않는 단계에서도 가능함.
넷. 현업 담당자의 비즈니스 이해도가 더 중요하고, 영업이나 회사와 회사, 고객과의 접점 대부분을 비개발 조직에서 커버할 수 있는 비즈니스 모델의 경우에도 가능함.
자신이 속한 조직의 비즈니스 모델이 위에서 열거한 4가지 패턴에 해당된다면, 두 조직은 하나의 조직처럼 구성되거나, 움직일 수 있다. 줄여서 이야기한다면, 해당 조직에서 '서비스'는 실제 조직에 속한 '비개발자'들의 능력이지, 'IT서비스'를 통해서 중요한 가치가 움직이지 않는 상황이기 때문이다.
하지만, 대부분의 IT서비스들은 규모가 있고, 복잡도가 증가하는 형태를 가지고 있기 때문에 위에 열거한 4가지 예외상황은 금방 넘어가게 된다.
스타트업의 경우 초기 시드단계에서는 해당되는 단계에서도 조직이 구성되는 것이 매우 당연하지만, 시간이 조금 지나고, IT서비스가 복잡해지기 시작하게 되면, 해당 조직들은 분리되어 구성되는 것이 맞다.
이해가 안간다면, 조금은 낡을지도 모르는 이야기를 해보자.
비개발자들은 개발자들에 대해서 너무도 모른다.
개발자에 대한 정의부터 잠시 해볼까 한다. 가장 일반적인 정의는 '판단 능력을 보유한 지능적 생산수단(Intelligent Intellectual Production Unit)이라는 정의'는 매우 클래식한 정의에 해당된다.
제품이나 소프트웨어 서비스에 대한 구체적인 완성도와 기대치에 대해서 명확하게 정의될 때에 개발자들은 매우 구체적인 '동기부여'와 '열정'이 발생한다.
개발자 스스로 인지할 수 있는 스토리에 대해서 인지가 되어야 하며, 그것이 투영되는 단계에서 만들어진 상황에 따라서, 개발자들은 충분한 '동기부여'가 가능해진다.
하지만, 대부분 '개발자'들이 원하는 충분한 '동기부여'에 대해서, 비개발자들은 인지하기 매우 어려워한다. 아마도, 다음과 같은 정리를 이야기한다.
첫째. 비즈니스 모델이 구체화되지 않은 상황에서 요구사항은 변화하고, 완성도와 기대치는 당연 시점에 따라서 다르게 변화한다.
둘째. 개발자들이 원하는 합리적인 개발환경을 맞추려면, 비즈니스 모델의 시기와 시점, 환경적인 요인을 맞출 수 없다. 그래서, 개발자들은 비즈니스 모델을 이해하지 못하고 있기 때문에, 구체적인 기획서나 모델들에 대해서 너무 구체화를 원하는 것은 쉽지 않다.
안타깝지만, 이런 환경 속에서 구축된 개발환경은 대부분의 개발자들이 매우 힘들어하는 환경이 된다.
구체적인 '동기부여'를 위한 완성도와 기대치가 계속 변화하고, 꾸준하게 변화되는 비즈니스 모델을 정리 정돈해주는 사람이 없는 상황에서, 개발업무에 시달리다가, 능력 좋은 사람들은 조직을 빠져나가게 되고, 능력 없거나 변화에만 충실한 사람들만 남아서, 시스템이나 서비스가 레거 시화하는 환경으로 변해간다.
그렇다면, 이런 상황을 피하려면 '비개발자'들은 '개발자'들을 어떻게 인지해야 할까?
첫째. 좋다. 개발자를 '수단'으로 생각하는 것도 좋다는 것이다. 다만, '비싼 수단', '비싼 도구'라는 인식이라도 필요하다.
어떤 기계나 수단들이나 제대로 관리하지 않으면, 고장이 나거나, 오작동을 하게 된다. 제대로 된 관리를 하지 않으면 이 복잡한 기계(?)는 제대로 동작하지 않는다는 것이다.
심지어, 당장은 동작하는 것으로 보이지만, 결국.. 해당 서비스나 그 '비싼 수단'들이 파괴되거나, 운용되지 않는 상태로 진행된다.
둘째. 정말, 비즈니스 모델을 구체화하려면, 기획서를 제대로 만들어라.
개발자들은 대부분 완벽한 기획서나 비즈니스 모델을 원하고, 그런 환경이 '동기부여'의 가장 기본적인 최소 요건에 해당된다. 개발자를 '비싼 기계'라고 인식한다면, 그들에게 제공되는 '원재료'가 매우 균질한 상태로 들어가야 한다.
제대로 된 입력이 들어가지 않는다면, 무슨 동작을 하고, 어떤 제품이 만들어질 것인지에 대해서도 예측할 수 없다. 이런 개발자들과 의사소통을 하려면, 좋은 관리자를 두는 것이 가장 좋은 방법이지만, 개발자들과의 소통에 최선을 다하고, 개발자를 이해하는 형태로 진행하는 것이 좋다.
다만, 좋은 개발 관리자 역시, 개발자이기 때문에, 이에 대한 의사소통의 핵심은...
역시, 구체적인 '동기부여'수단이고 '열정'의 재료인.. 구체화된 비즈니스 모델과 기획서가 나와야 한다.
이 두 가지가 제대로 동작하지 않는다면, 개발자들은 '동기부여'를 받기 어렵고, '일'이 힘들어지는 상황을 미리 예측하게 된다.
물론, 그런 구체적인 '비즈니스 모델'과 '기획서'를 개발자와 같이 만들 수 있을지도 모른다. 하지만, 그 단계부터 '개발자'들은 '비개발자들'을 이해할 수 없게 된다.
그들이 왜? 존재해야 하는지에 대한 의문점과, 협업체계에 대해서 의구심을 표현한다.
셋째. 구체적인 '동기부여'인 '기획서'가 완전할수록, 개발자들은 더욱더 열정을 가진다.
가능하다면, '동기부여'를 위한 모델과 기획을 완전하게 다듬는 것이 좋다. 이는 개발자의 힘으로 만들어지는 것이 아니라, 비즈니스를 제대로 이해하고 있는 기획자와 경영자라면 이 부분에 대해서 더 많은 공을 들일 것이다.
그래야, 개발자들은 '열정'을 가지고 동작한다.
넷째. 그렇다면, 정말 좋은 개발자란 어떤 사람들일까?
이 세상에 없는 것을 만든다면, 어떤 상황에 대해서 인지하고, 분석과 설계 단계에서 최종적으로 만들어지는 구현 상태의 서비스나 소프트웨어에 대한 정확한 구현 상태를 상상하고, 이를 구현 단계로 끌고 가는 사람이 아주 훌륭한 개발자에 해당된다.
비개발자들은 이런 분석과 설계 단계에 대해서 너무 추상적이라고 인식하기 어렵다고 한다.
간혹, 좋은 개발자들은 분석/설계단계를 뛰어넘어 '기획'도 가능한 개발자가 아니냐는 '비개발자'들의 질문을 만나게 된다.
물론, 그런 개발자들이 있다.
그런 개발자들 대부분 창업하거나, 자신의 서비스를 자신의 프로덕트가 될 수 있는 오픈소스 프로젝트이거나, 그런 기획력을 기반으로 하나의 프로덕트의 오너가 된다고 설명을 할 수 있다.
비개발자가 만날 수 있는 가장 좋은 개발자들은...
잘 짜인 비즈니스 모델과 잘 구성된 기획서들을 기반으로 구체적인 서비스를 잘 만들 수 있는 분석, 설계 능력이 출중하고, 완성 물을 만들어 나갈 수 있는 팀과 인력, 기간과 프로세스, 방법론들을 잘 구성하고, 이를 완성시키는 사람이라고 정리할 수 있다.
개발자는 기획부터 시작해서 완성하고, 운영하는 것까지 모두 처리하는 '은빛 탄환'과 같은 존재가 아니다.
그런 착각을 하고 있는 사람들을 만나면 좋은 조언을 하고 싶다.
최소한, 잘 정의된 기획서로 약속된 기간 동안 프로덕트를 구성할 수 있으면, 좋은 개발자의 기본을 가진 사람이라고 이야기하고 싶다.
마지막으로...
잘못 기획된 비즈니스 모델과
제대로 만들지 못한 기획서를 기반으로
프로덕트를 만들었을 때에
그 책임을 개발자에게 물어보는 상황이 발생하지 않기를 기원한다.
하지만...
실제 서비스의 개발 단계에서 이런 일은 빈번하게 일어난다.
그리고, 완전한 비즈니스 모델과 완벽한 기획서를 개발자들 역시 바라지는 않는다.
하지만,
BM과 기획서의 미진한 부분들을 단계별로 완성할 수 있게 하는
현명한
기획자와 관리자들과 같이 일하고 싶어 한다.
분명, BM과 기획은 미진한 상태로 만들어진다.
그 미진한 상태에서 개발 중에 '동기부여'된 상태를 마무리하지 못한 상태에서...
개발 일정을 늘리거나, 구조를 바꾸지 말기를 바란다.
잘못된 기획이라면, 그 상태로 진행되고...
잘못된 부분에 대해서 개발자와 의사소통하여...
다음 기획으로 진행하고, 그 기획에 맞추어서 수정 작업을 취하면 된다.
에자일과 진하게 개발하는 방법은
그 원칙을 지키는 것부터 시작한다.
.
.
.
개발자들이 일할 수 있게 하라.
그것은, 한번 시작된 개발과정을 뒤틀지 말고...
잘못된 것은 잘못된 상태로 다음번 개발에서 수정하면 된다.
그것이 개발자와 잘 일하는 방법이고...
개발자와 비개발자가 하나가 되는 방법의 가장 기본적인 조건이다.
