개발 조직에서 개발 프로세스란...
권한에 대한 위임과 책임이다.
소프트웨어 개발 프로세스는 제품을 개발하기 위한 구조이며, 필요한 과정이다. 순수한 소프트웨어 공학적인 해석으로는 소프트웨어 생명주기와 소프트웨어 프로세스라고 정의하고 있다. 각각의 단계별 활동과 작업들을 의미하고 있는데.. 이 개념은 현대에 와서는 고객과 바로 접점 하는 단계와 제품의 구성, 서비스의 요구사항 의사결정 과정까지 대부분을 포괄하는 개념으로 확장되어 사용하는 것이 맞다.
현재 개발 프레임과 환경들은 매우 빠른 단계로 고객과 직접 접점 한다. 고객의 요구사항이나 서비스의 변화를 의사결정 과정의 위임과 권한을 통해서 매우 짧게 구성한다. ( 빠르지 못하면 서비스가 바로 도태된다. )
특히, 스마트폰을 중심으로 한 커넥티드 되는 정보들을 중심으로 구현되는 O2O 서비스의 경우는 이 보고라인은 정말 짧게 운영된다.
정해진 미션을 완수하기 위해서 목표를 중심으로 서비스의 변화를 데이터 기반으로 판단하고, 위임받은 권한으로 팀장이거나 리드 개발자 수준에서 의사결정이 종료되는 경우가 많으며, 선조치 후 보고하는 형태가 매우 넓게 사용된다.
잘못된 판단이거나, 버그가 발생해도 이 역시 서비스의 미션을 수행하는 과정으로 인지하고, 빠르게 개선할 수 있는 형태로 대부분의 권한과 책임은 위임되는 것이 현재의 개발 프로세스이다.
개발 조직이 수평적인 문화와 의사결정 과정의 위임이 제대로 동작하고 있는 환경에서는 담당 개발자나 기획자 등이 서로 의논해서 큰 방향성에 문제가 없는 부분에 대해서는 각자 해결할 능력을 갖추고 있어야 한다.
하지만, 의사결정이 기민하지 못하고, 신뢰하는 코드를 만들지 못하며, 업무 규칙이나 환경에 대한 이해도가 떨어지는 개발자들의 경우에는 팀장이거나 경영진의 탓으로 돌리는 경우가 빈번하다.
자신들이 만들어 나가는 서비스에 대해서 이해도가 떨어지는 것은 담당자들의 능력이 떨어지는 것이지, 이에 대한 업무의 미션을 지시한 상사나 대표가 잘못한 것이 아니다.
능력 있는 개발자들은 대부분 어떤 프로세스의 형태로 복잡하게 구성되거나, 단순하게 구성되는 형태에 맞추어서 자신의 역할과 권한에 대한 기준을 잡고 일을 수행한다. 하지만, 능력 없는 개발자들은 자신의 스타일과 자신이 그동안 알고 있던 방식으로 업무를 수행하는 경우가 많으며, 자신과 맞지 않는 절차와 환경에 대해서 적응하는데 시간이 걸리거나, 방식에 대해서 불만을 가지는 경우가 많다.
그냥, 능력 없는 개발자 들일뿐이다.
개발 조직에서 위임 없이 회의가 많고, 상향 보고와 보고에 의한 판단으로 업무가 진행되는 경우에는 다음과 같은 문제들이 있다고 보면 된다.
1. 비즈니스 모델에 맞지 않게 설계된 제품의 구성이나 품질의 척도 문제
2. 업무의 구성과 고객에 대한 분석이 제대로 안된 체 기능 구성이 되었거나, 구조를 가진 경우
3. 이미 기 투자된 리소스에 대해서 손실처리하지 못하고, 기술적 부채를 키워가면서 문제를 대처하는 경우
4. 개발 조직의 실력이 부족하거나, 이해도가 떨어지는 경우
일단, 비즈니스 모델에 대한 상품 디자인이나 서비스 구성 방법, 기술적 요소의 중요한 부분이 틀어져 있다면, 이를 기반으로 제품의 설치나 서비스의 운용에서 많은 C/S를 발생시킨다. 특히, 하드웨어나 물리적인 제품이 사용되는 서비스라면 이 현상은 더 극심해진다.
신규 비즈니스 기능을 늘려나가는 것보다, 제품의 설치 운용에 문제가 발생하는 대부분의 이유는 '비즈니스 모델'에 대한 잘못된 이해와, 제품 구성의 문제에서 발생되는 경우가 대부분이다.
스타트업들은 이 경우 대부분 비즈니스에 실패하거나, 제품을 처음부터 다시 만들어야 하는 상황까지 가야 하는데, 이런 판단을 경영진이 빠르게 정리해야 한다. 처음부터 꼬인 것은 해결할 방법이 미봉책뿐이다.
대부분, C/S조직을 증가시키고, 차세대 제품을 빠르게 만들거나, 하드웨어를 다시 선정하는 작업을 빠르게 진행해 야한다.
lean 방법론을 사용했다면, 잘못된 제품 구성과 비즈니스에 대해서 판단해야 하는데, 이 판단을 경영진이 하지 않는 경우에 해당 개발 조직은 구제품과 새로운 제품의 선택과 갈등 사이에서 번민하고, 리소스가 대량 투입되어야만 이 문제가 해결된다.
그러므로, 개발 조직에서 중요한 것은 프로세스이며.
프로세스는 이런 권한과 책임을 팀장과 팀원에게 주게 된다.
팀장은 프로젝트의 실패를 선언하고, 제품 디자인을 다시 들어가야 하는데... 실제. 이것은 이론일 뿐, 프로세스 상에서 이를 구현한다는 것의 현실성이 없다.
대부분은 이미 기 투입된 시장을 지키기 위해서 지루하고 어려운 점진적 업그레이드 방법을 사용하여 비효율적인 환경으로 서비스를 대응한다. 이미, 가장 상위의 권한자가 권한을 위임하지 않고, 실패를 인정하지 않으므로 발생된 문제를 개발 조직에게 떠넘기고 있는 상황이다.
물론, 이런 문제는 스타트업 대부분이 겪고 있는 문제이기도 하다.
그래서, 첫 번째 버전은 최소로 개발되고, lean 하게 비즈니스 모델에 맞도록 제품 서비스를 확장하며, 필요한 구성들을 추가해야 한다. 그리고, 잘못된 부분은 빠르게 실패 선언하고 처음부터 다시 만드는 것이 가장 효과적이다. 하지만, 이런 빠른 판단을 하는 것은 매우 어려우며, 이를 빠르게 실현하고 있는 조직은 프로세스가 잘 갖추어진 조직이라고 볼 수 있다.
