아키텍처적인 판단과 비기능적인 요소, 품질요소에 대한 것을 기준으로 우선순위를 결정하는 것은 차라리 간단하다. 아리송하고 판단하기 어려운 것은 따로 있다. 서비스를 어떤 기능이나 어떤 서비스, 어떤 영역을 먼저 시작해야 하는 가?. 아니면, 서비스가 개시되고 돌아오는 버그 리스트와 추가 요구사항 등의 사용자의 피드백을 통해서 유지보수의 순서를 정하는 것 등이 아리송한 것이다.
이번에 중점적으로 이야기하는 것은 개발자들에게 요구되는 요구사항과 업무의 작업 단위들은 왜 이렇게 많이 변화하고, 이러한 요동치는 환경들은 무엇 때문에 발생하는 것인지에 대해서 생각해본다.
대부분의 소프트웨어 개발자들은 시시각각 변화하는 요구사항과 유지보수 업무의 홍수 속에서 점점 무덤덤해지면서, 자신들이 할 수 있는 일만을 하려고 하는 경향으로 변화해 간다. 그렇게 변화하면서 개발 조직 내에서 무력감에 빠져드는 현상을 맞이 한다. 그 모든 이유의 대부분은 최고 경영자나 경영진, 리더층의 결정장애이거나 판단 미스인 것이 대부분이다.
슬프게도 최고 경영진에게는 소프트웨어 개발팀에서 업무를 제대로 처리해주지 않는다는 영업과 기획 조직들의 푸념이 늘어나는 이유는 소프트웨어 개발팀에서는 제대로 된 요구사항의 정의가 되지 않았고, 작업의 우선순위가 불분명하기 때문에 이런 기술적 판단 미스와 잘못된 기술 부채가 누적되어지기 때문이다.
기술적 부채에 대해서는 다음에 이야기하고, 이번 이야기에서는 '작업'의 우선순위를 결정하는 부분에 대해서만 이야기해보자.
우선순위를 결정하는 기준이 없거나, 기준에 대해서 의사소통이 안 되는 경우가 발생할 수 있다. 그리고, 대부분의 스타트업들은 이런 현상을 맞이한다. 물론, SI현장에서는 너무도 비일비재하게 반복되는 경우가 많기 때문에 이런 현상은 지금 이 순간에도 반복되고 있다.
도대체 왜 이런 상황을 만들었는가? 그리고, 누가 이렇게 만들었는가? 분명, 스타트업 초기에는 의기투합했던 CEO와 기술 총 책임자가, 어느 정도 기업이 성장하고 나니, 업무의 우선순위와 요구사항의 폭주 속에서 서로 일기토를 벌이는 대립된 상황이 되어버린 것은 무엇 때문일까? 도대체 이렇게 개발업무가 뒤죽박죽 되어버린 것은 누구의 책임인가?
아키텍처가 부재하고, 아키텍트 역할을 담당하는 사람이 없는 경우에는 이런 현상은 매우 당연하다. 오히려, 발생되고 있는 것을 모른다면 그것은 더 위험하다. 개발자나 담당자가 현상을 숨길 가능성도 매우 크다. 언제나 개발 리소스는 부족한 것이 정상이다.
개발 일정은 촉박하고 만들어야 할 것은 많으며, 버그는 언제나 발생한다. 이런 사항들을 어떻게 처리하는 것이 가장 합당한 것인가에 대해서 삐딱한 아키텍트의 시선으로 몇 가지 정의하여 보자.
한편으로는 이러한 상황은 매우 당연한 것이다. 소프트웨어 개발을 할 때에 수많은 업무들이 밀려온다. 또한, 요구사항들은 급변하고 시장 또한 급속도로 변화를 일으키는 것을 간과해서는 안된다.
‘냉정하게 ‘경영진’이나 ‘개발 총 책임자’의 능력이 부실해서 그런 경우가 태반이다.‘라고 필자는 이야기하고 싶다. 그런 상황을 피하게 해야 하고, 그런 문제를 해결하기 위해서 최선을 다해야 하는 것이 그들이 해야 할 일이다. 그래서, 고액 연봉을 받는다. 그러니, 이런 문제는 그들이 해결해야 한다.
결론은 그러하지만, 그런 상황을 좀 더 세밀하게 분석해보자.
보통 이러한 일이 발생하는 경우의 가장 대표적인 문제는 경영진의 ‘경영 목표’가 불분명하고, ‘프로젝트의 골’에 대해서 가치의 설정을 제대로 못하고, 이에 대해서 조직원들에게 의사전달이 불분명할 때에 이런 상황들이 대부분 발생한다. 그리고, 결과는 불을 보듯 뻔하게 된다. ( 의사소통이 안되었다고 판단하기도 하지만, 대부분 일방통행으로 전달되어지는 지시사항들이 대부분이므로, 의사소통의 문제는 아니다. 그러니, 개발자나 기획자, 디자이너의 책임이 아니다. 그냥, 지시가 잘못된 거다. )
물론, 전통적인 제조업체와 전통적인 관료조직에서는 이러한 문제를 해결하는 다양한 방법들이 연구되었고, 차근차근 일을 풀어나가는 방법에 대해서도 많은 해결책과 솔루션들이 등장한다. 하지만, ‘지적 생산’을 주 업무로 하고 있는 소프트웨어 개발에 있어서는 이러한 방법들은 정말 바보스러운 프로세스를 만들 뿐이고, 인원이 비대해지며, 불필요한 회의와 불합리한 결정들이 도배되는 경우가 많은 관료조직을 비대하게 만드는 경우가 많다. 이런 문제를 해결하겠다고, 조직의 구성 방법이나 조직을 관료화하고, Tree구조로 만드는 바보 같은 짓을 필자도 그런 실수를 반복했었다. (ㅡ.ㅡ;)
스타트업으로 빠르게 시작한 기업이 어느 정도 매출을 일으키거나, 서비스가 완성되어 갈 때에, 대규모 인원을 확충하면서 발생되는 문제들은 아이러니하게도 대부분 비슷하다. 그 문제의 핵심중의 핵심은 그 ‘문제’ 들을 어떻게 나열하느냐이다.
그렇다면, 이러한 문제들을 어떻게 명확하게 해야 하는가? 그것을 조금 더 명확하게 개발업무에 있어서 정의한다면. 소프트웨어 개발에 있어서 가장 초보적이고 기본적인 ‘업무의 요구사항’을 제대로 결정하는 것이다. 그리고, 이러한 ‘요구사항’을 어떤 방법으로 중요한 ‘업무의 우선순위’를 잘 결정하는 것이다.
이런 ‘우선순위’를 결정하기 위하여 ‘요구사항’을 어떻게 잘 정의하는가가 이 문제를 보다 명확하게 하는 방법의 가장 핵심중의 핵심이 되겠다. 물론, 똑똑한 경영자와 리더가 앞에 나서는 것은 당연한 것이겠이고, 그러한 리더는 ‘요구사항’을 정말 명확하게 정의하고, To-be에 대해서 명쾌하게 정의할 수 있다. To-be가 명확하고, 만들고자 하는 제품과 서비스가 명확하다면 이런 혼란을 발생하지 않을 것이다.
하지만, 불분명한 목표와 불분명한 요구사항은 결국, 소프트웨어 개발을 파국으로 만들어 버리는 첫 번째 문제점이다. 훌륭한 리더는 작은 요구사항과 작은 결정사항부터 명확하게 정의한다.
소프트웨어 개발 업무의 우선순위를 결정하는 방법
물론, 이 내용은 소프트웨어를 중심으로 IT설루션이나 서비스를 개발하는 업체를 대상으로 설명하기는 하지만, 일반적인 기업들도 요즘은 대부분 중요한 의사결정과 지적 프로세스들을 갖추어야 하기 때문에 발생되는 문제들은 대부분 대동소이하다고 하겠다.
또한, 경영의 목표에 대한 설정과 과학적인 접근 방법은 경영학적인 관점이기 때문에, 그 부분에 대해서도 이 글에서는 논외로 하자. 보통 조직이나 기업은 제한된 리소스와 자원과 일정을 가지고 최대의 이익과 목표를 도달하기 위한 경영자의 판단에 의해서 결정되어지고 움직여진다. ( 그래서, 사장이 똑똑해야 한다. )
대부분의 조직과 회사는 이미, 시작부터 그 결과를 예측할 수 있다고 보는 것이 합당하다. 이처럼, 냉정하게 경영의 목표를 명확하게 하고, 조직의 비전과 한 해의 목표와 프로젝트의 목표에 대해서 얼마나 잘 결정하느냐가 핵심적인 성공요소들이다. 목표가 명확하면, 업무 순위도 명쾌하다.
아무리 개발자가 똑똑하다고 해도, 경영진의 삽질을 버텨낼 수 있는 것은 거의 ‘기적’에 가까운 일이기 때문이다. 결정하고 업무의 우선순위를 정의하는 사항들이나 체크리스트에 대한 이야기인 경영진들이 판단해야 하는 내용에 대해서는 필자의 경험( 중견기업의 임원 노릇 )을 바탕으로 다음 기회에 이야기하도록 하겠다. 아마도, 스타트업과 중견기업의 임원으로 일해본 필자가 해줄 수 있는 이야기는 필자 주변에서 물어보듯이 생각보다 많은 듯하며, 브런치를 통해서 자주 언급하고 이야기하도록 하겠다.
정말 중요한 소프트웨어 개발 기업에서의 업무의 우선순위는 무엇으로 결정되어지는가? 그것은 대부분의 기업과 대동소이하다. 그것은 ‘기업이 추구해야 할 이익’이다. 그리고, 그 이익을 위해서 어떠한 경영적인 지표와 목표를 설정하느냐에 따라서 결정되어진다.
이러한 결정사항이 개발업무의 우선순위에 가장 지대한 영향을 준다. 앞서 이야기했지만 경영지표를 설정하는 것은 이 글에서는 논외이다. 일단, 여기서는 경영의 목표는 명확하다는 전제하에서 매일매일 요구사항에 따르는 업무의 우선순위가 요동치게 되는 상황을 생각해보자. ( 일단, 똑똑한 경영진이 제대로 된 목표 설정을 했다고 본다. )
하지만, 그렇게 목표 설정이 되어도, 요구사항과 업무의 우선순위가 요동치는 경우는 똑같이 발생하게 되는 경험을 하게 된다. 도대체, 왜? 이런 현상들이 발생되는 것이고, 왜? 우리는 이러한 변동되는 상황 속에 노출되어 있는 것일까?
대부분의 소프트웨어 개발 업무들을 보면, 생각 이상으로 매번 계획에 없던 일은 수시로 발생하고, 발생된 업무들은 아이러니하게도 중요한 업무 리스트로 추가되는 해괴한 현상이 수업이 되풀이된다. 도대체! 왜? 그런 현상이 일어날까?
시장의 매우(!) 변화는 당연하다.
물론 이러한 상황을 여러 가지 상황으로 해석할 수 있겠지만. 대부분의 이런 식의 업무의 우선순위가 요동치는 이유는 '회사 주변의 변화'가 극심해서 벌어지는 현상 중의 하나일 수 있다. 이러한 경우는 극히 당연하며, 이 요동치는 것을 어떻게 프로세스에 반영하는가가 관건이다. 그래서, 해당 프로세스의 분석과 반영에 집중하면 최고의 프로세스를 얻을 수 있다. 대부분이거나 특히, 일등 경쟁업체가 있고. 그 업체의 행동을 주시해야 하는 팔로워 정책을 사용하는 업체의 경우에는 이런 일은 거의 매번 발생하는 경우이니, 어떻게든 이러한 변화를 탄력적으로 운용할 수 있는 환경을 만드는 것이 중요하다.
분명, 더욱더 극심하게 발생하는 것과 소프트웨어 개발과 환경, 조직을 그에 맞추어야 하니까 발생하는 것이다. 냉정하게 해당분야의 1등 기업이 아니고서는 대부분 이러한 현상을 비일비재하게 만나게 된다. ( 보통 기업들은 애플과 같은 선도적인 기업이 아니다. ) 그리고, 이런 요동치는 '변화'에 따라서, 보통은 이러한 변화에 따라서 세부적인 실행방안과 전략, 결과물들이 변동되는 것인 어찌 보면 당연하고 지당한 범위의 변동일 수 있다.
당연하게도 이러한 ‘시장의 변화’를 내부 조직원들에게 어떻게 전파하고, 의사소통하는 것이 효과적인 것인가에 대해서 더 많은 투자를 해야 하고, 해당 정보들을 빠르게 전파할 수 있는 방법들을 고안해야 한다.
하지만, 시장은 그대로인데? 요구사항은 요동친다?
그렇지만, 시장의 변화도 없고, 경쟁기업의 변화도 그다지 없는데도, 부서와 부서원, 개발자와 영업 등에 있어서 주요한 우선순위가 요동치고, 기준점이 없는 상황에서 방황하게 되는 현상은 왜 일어나는 것일까?
재미있게도, 대부분의 '우선순위'변동은 이러한 외부요인에 의해서 발생하지 않는다는 점이다. 보통은 이런 '외부요인'에 대한 대응방안과 충격은 대부분의 회사와 조직에서 반응할 수 있도록 대처가 되어있는 편들이다. 그리고, 경영이나 관리조직은 그러한 것들을 탄력적으로 운영할 수 있는 다각도적인 방법들에 대해서 이미 익히 알고 있기 때문에, 대부분은 소프트웨어 개발 조직에 이러한 여파가 가지 않도록 최선을 다한다. (* 만일 이런 상황이 아닌데도 개발 조직에 여파가 전해진다면, 전적으로 관리조직이나 리더십의 문제, 의사소통 등의 문제들이 그대로 드러난 것이다. )
정말 대부분의 '우선순위'의 변동은 엉터리 같은 상황에서 발생되는 경우가 생각 이상으로 많다. 그것의 대부분은 납득하기 어려운 모호한 이유와 상사의 변덕, 사내 정치의 비합리적인 결정 등에 따라서 변화되는 경우가 많다.
물론, 대한민국의 SI특성상 거지 같은(?) 고객의 불합리한 요청사항 때문에 거지 밥상을 뒤엎듯이 변화하는 것 또한 엄연한 현실이고 사실이다. 하지만, 냉정하게 이러한 현실에 대해서 잘 알고 있으면서 대응을 하지 못한다는 것 또한 분명 능력과 실력의 문제이기도 하다. 분명, 거지 같은(?) 고객과 시장이라면 그에 응당한 대응조직이나 프로세스를 갖추어야 한다. 하다 못해, 술말 마시는 술상 무라도 동원하는 것이 합당하다. 대한민국 공공 SI의 성패는 ‘술자리’에서 결정되는 경우도 많다. (ㅡ.ㅡ;)
정말 중요한 것은 이런 상황을 파악하는 것 그 자체가 중요한 것이다. 이처럼 정말 중요한 것은 업무의 요구사항에 대한 본질을 정확하게 파악하는 것이다.
분명, 자신의 조직과 회사에서 '소프트웨어 개발업무의 우선순위'는 어떤 식으로 결정되어지며, 어떤 것들이 정말 중요한 업무인지 파악하고 분석하는 것이 가장 핵심적으로 필요하다. 아주 세부적인 우선순위에 대해서는 실제 해당 업무를 분석하고 정의해야 하지만, 일반적으로 이러한 ‘요구사항의 본질’을 정의하는 데 있어서, 최소한 두 가지의 스텝으로 업무를 구분하고, 다음의 4가지 정도의 업무형태는 구분해야 한다고 생각한다.
현재 팀에 적합한 소프트웨어 개발업무의 우선순위를 결정하자!
그것의 첫 번째 스텝은 정말 필요한 '0순위의 업무'와 '쓸데없고 필요 없는 일'을 구분하는 것이다. 그리고 남은 요구사항과 업무들은 일반적인 업무들이며, 그 업무들은 다음 스태프의 분석과 정의에 따라서 ‘고품질이 요하는 업무’와 ‘적정 품질을 요하는 업무’를 구분하는 것이다.
이처럼 0순위 업무, 불필요한 일, 고품질 업무, 적절 품질업무의 4가지 스태프로 구분하여 업무의 우선순위를 정하는 것이 요구사항 분석의 첫 번째 단계이다. 그리고, 그러한 기준과 성격에 대해서 조직원들에게 폭넓은 이해를 구해야 하며, 그 부분에 대해서 공감대를 형성해야 한다. 대부분 기업의 목표와 비전은 그러한 것을 전제로 구성되게 된다. 그렇다면, 이러한 해당 업무의 성격은 어떻게 구분하는지 하나씩 살펴보자. 요구사항들에 대해서 구분이 어렵다면, 필자가 사용하는 방법을 한번 사용해 보라. 아래의 표는 요구사항의 우선순위를 평가하기 위해서 필자가 사용하는 방법이다. 점수를 만들어서 사용하는 것이 가장 간단할 수 있다.
표1, 요구사항에 대한 가중치 리스트
위의 표를 이용하거나 적절하게 요구사항의 가중치를 조절하여 ‘수치화’하는 것도 일부분 가능하다. 하지만, 이렇게 정량적으로 판단하는 것보다 더욱더 중요한 것은 ‘요구사항’은 ‘정성적’인 판단을 제대로 하는 것이다.
0 순의 업무를 찾고 정의하자
가장 쉽게 이야기하면. ‘기업의 이익을 가져다주는 확실한 것’이 명확하게 드러난 것을 의미한다. 몇 가지 부연설명을 하자면, 기업이 사활을 걸어야 할 신기술이 들어간 서비스, 매출 증대를 위한 새로운 시장에 진입하는 비즈니스 모델을 갖춘 서비스, 수익모델을 만들고 실현하기 위한 일련의 서비스의 Back-office 작업들, 현재 서비스 중인 소프트웨어의 위기사항을 타개할 해결책을 찾는 것 등이 이러한 '0순위 업무‘에 해당한다.
더 명쾌하게 이야기하자면 '업무의 가치'가 명확하고, '업무의 요구의 원천'이 명확하고 정확하게 드러난 요구사항들 중에 '수익'이 명쾌하게 보이는 일이 이에 해당한다. 이러한 '업무'들은 개발 조직뿐만 아니라, 영업이나 기타 조직에서도 발 빠르게 대응하는 것이 가장 중요하다.
보통 이러한 일들에 있어, 가장 중요한 것은 '타이밍'이게 된다. 말 그대로, 발생한 시기와 해결되는 시기의 주기가 가장 짧아야 한다. 말 그대로, 고객이 원하는 제품과 서비스를 의미한다. 그래서, 0순위로 진행해야 한다.
또한, 이러한 타이밍은 기업에게도 큰 기회를 주지만, 해당 업무를 추진하는 부서와 개인에게도 큰 이익과 인사고과의 결과를 선사하기 때문에 정말로 의미 있고 중요한 업무가 된다. 다만, 이러한 0순위 업무의 구분을 해야 하는 경우에는 해당 조직과 회사에 당연하게도 인사고과나 인사정책 또한 잘 구성되어 있는 경우에만 이러한 우선순위의 결정이 의미가 있다. 또한, 결정되어지는 긴급한 의사결정에 대해서 신속하고 명확한 의사전달과 의사소통이 가능한 집단의 경우에게만 이러한 ‘0순위 업무’에 대한 정의가 가능하다.
앞서 이야기한 인사정책이나 의사소통이 불분명한 조직에서는 아무리 ‘고객’이 당장 원하는 ‘서비스’와 ‘제품’이라고 하더라도. 소프트웨어 개발 조직에서는 생뚱맞게 튀어나온 불특정 한 업무로 밖에 받아들이지 않는다.
그러한 ‘문화’와 ‘환경’을 갖추고 있지 않는 기업이라면, 이러한 ‘0순위 업무’는 가능한 발생시키지 않는 것이 최선이다. 그리고, 다음의 ‘불필요한 일’을 구분하는 정도로만 진행하는 것이 더 효과적일 수 있다.
하지만, 잘 갖추어지고 유연한 소프트웨어 개발 조직에서는 이러한 이벤트적인 최고 결정사항을 발 빠르게 대처할 수 있다. 이러한 일들은 말 그대로, 잘 수행된 이후에 기업도 이익이고 부서도 신바람 나고, 개인도 업무 고과에서 큰 영향을 받을 수 있는 일이므로, 기업에 가장 큰 이익과 긍정적인 효과를 매우 크게 안겨다 주는 업무가 된다.
가장 중요한 ‘문화’가 성립되어진 기업과 조직은 어떻게든 이러한 ‘0순위 업무’를 정말 잘 필터링하는 것이 해당 기업의 점진적인 성공과 성패의 최우선적인 결정사항이 될 것이다.
보통 이러한 결정은 어느 정도 회사의 서비스와 제품이 성공적으로 시장에 안착한 다음, 시장이 확대되거나 해외 수출 등의 매출이 급속도로 증가하는 시점에서 심각하게 고려해야 할 사항들이다.
그렇다면, 이러한 요구사항이나 업무는 어떤 식으로 결정하는 것이 최선일까? 여러 가지 의견이 있지만, 크게 두 가지로 나눌 수 있다. 하나는 대부분 이러한 업무는 특정 체크리스트와 회의에 의해서 결정될 수도 있다는 점. 또 다른 하나는 리더십을 가진 사람이거나 경험이 풍부한 사람이 직감과 경험에 의존하는 것이다.
과연 어떤 방법이 효과적일까? 프로세스로 이러한 0순위 업무를 결정할 것인가? 직감과 경험에 의존할 것인가? 두 가지 모든 것을 고려할 것인가에 대해서는, 각 조직과 기업의 성격에 따라서 조금씩 다르다.
다만, 정말 중요한 것은 ‘0순위 업무’를 제대로 구분하고, 이를 정하는 일련의 작업들을 수행하고 있는가 하는 점을 먼저 판단하는 것이다. 보통 이런 ‘0순위 업무’들은 너무도 명확하기 때문에 잘 드러나서 경험과 직관으로 결정하는 것이 더 효과적인 경우가 많다. 경험이 풍부한 고급 개발자나 아키텍트와 같은 인력을 보유하는 절대적인 이유이기도 하다.
하지만, 문화적인 형성도 힘들고, 고급인력도 없다면, 다음의 ‘쓸데없는 일’을 찾는 것에 중점을 두어보자.
현재 상황에서 ‘쓸데없는 일’을 구분하자.
대부분의 소프트웨어 개발 조직에서 가장 잘해야 하는 작업은 정말로, '쓸데없고 필요 없는 일'을 구분하는 것이다. 냉정하게 지금 당장 필요 없는 업무, 해도 그다지 성과가 없는 업무, 의미가 부족한 업무 등이 이에 해당된다. 대부분 이러한 업무들의 대부분은 '업무의 가치'가 불명확한 경우와, 누가 만들고 요구한 것인가? 에 대한 요건이 불명확한 경우가 많다.
이 두 가지에 해당되는 내용들이라면, 대부분 쓸데없는 일이나 요구사항으로 구분하여 정리하고 처리해야 한다. 물론, 요구사항의 수집이 잘못되었을 수 있지만, 그것은 수집의 문제에 대해서 다시 논하기로 하자. 요구사항 수집 공학과 관련된 이야기도 칼럼 중에 한번 이야기해야 할 내용이다.
하여간 이러한 ‘쓸데없는 일’들은 분명, 현재의 작업에 등록되어 있고, 누군가가 하고 있으며, 어떤 지시에 의해서 실제 수행되는 경우가 상당수 존재한다. 이러한 대부분의 일들과 요구사항들을 살펴보면, 현재 등록되어진 대부분의 업무들 중에 10가지 중에 1~2가지 일들은 대부분 타성적으로 흘러 지나가는 경우가 대부분인 경우가 많다. 냉정하게, 현재 등록되어진 요구사항이나 업무에 해당하는 것들의 10~20%는 정말 '쓸데없는 일'들이 많다. ( 지금 당장 업무의 Task를 살펴보면, 이런 쓸데없는 일들을 찾을 수 있다. 왜? 자신도 모르게 버퍼 삼아서 등록해 놓은 업무, 팀장이 버퍼로 등록한 업무까지 정말 많다. )
또한, 그 이외에도 대부분이 비즈니스 환경이 변하거나, 업무를 지시한 상사의 변덕 등으로 사라지는 업무들도 이에 해당한다고 볼 수 있다. 이러한 업무들은 해당 이벤트와 상황에 따라서 후순위로 처리되거나 하지 말아야 할 것들에 해당한다. 그렇다면, 이러한 쓸데없는 일들을 어떻게 구분해 내는가? 가장 대표적으로 구분하는 방법은 ‘만들어진 보고서’와 ‘결과물’이 소홀하게 관리되는 경우가 대부분 이에 해당한다고 보면 되겠다.
이러한 쓸데없는 일들의 결과들을 살펴보면, 정말 심한 경우 보고서나 결과물에 대해서 보고를 받는 시간 10~20분 정도의 대충하는 경우도 많은 것이 대부분이다. 그리고, 실제로 관료화된 조직에서는 이러한 많은 업무들이 필요 없는 업무들로 구성되어진다.
소프트웨어 개발 조직이 관료화된다는 것이 얼마나 비효율적인가 하는 점은 굳이 첨언하지 않아도 대부분의 개발자들이 잘 알고 있을 것이다. 소프트웨어 개발 조직이 관료화되어있다고 생각한다면, 대부분의 '소프트웨어 개발 업무'들은 쓸데없는 일에 30~40%의 일을 소모하고 있는 경우가 대부분이라고 봐도 무방하다.
그래서, 이러한 업무들을 구분하는 방법으로는, '업무가 추진되고 나온 결과물'을 검토하는 시간과 결과물에 대한 반응을 살펴본후, 그 반응이 어떻게 내재화되는지에 대해서 검토하여 보면 대부분 알 수 있다.
또한, 해당 서비스나 라이브러라, 산출물들이 얼마나 재활용되고 있으며, 효과적으로 반영되고 있는지에 대한 평가도 같이 하면, 이러한 ‘쓸데없는 일’을 찾아낼 수 있다. 대부분 이러한 업무들의 대표적인 것들이 냉정하게 신입사원들 대부분의 업무가 그러하고, 선임 직원들은 관성에 따라서 만들어 내는 업무들이 대부분 이러한 경우가 많다. 또한, 습관적으로 중복적인 업무들도 많이 발생한다. 이러한, 업무의 누수를 어떻게 잘 검토해 내느냐가 관건이고, 정말 필요한 일을 잘 판단하는 기본적인 체크를 할 수 있는 방법을 만들어야 한다.
이러한 분리된 스텝으로 정말 필요한 일과, 정말 필요 없는 일을 구분하는 것만 체크하고 점검하여 진행하여도, 업무의 우선순위는 대부분 정해지고, 불필요한 일과 쓸모없는 일들을 제거할 수 있다. 물론, 냉정하게 이러한 업무를 제대로 해야 하는 것이 중간관리자나, 팀장들이 일을 잘하는 경우에 해당되겠다. 또한, 효과적인 의사소통이 많아지고, 효과적으로 대응하는 경우에 이러한 업무의 구분이 보다 명확해진다. (* 그렇다고, 의사소통을 많이 하겠다고, 회의시간만 길게 잡는 것 또한 불확실한 일처리를 의미한다. 대부분 그 방법은 해당 조직들이 더 잘 알고 있다. 어떤 장소에서 어떤 시간이 더 많은 대화를 나누는 것인지 잘 알고 있다. )
최소한의 이러한 구분이 가능하다면, 좀 더 업무의 우선순위를 좀 더 세분화하여 정의할 수 있게 시도할 수 있다. 그것은 소프트웨어 개발에 있어 정말 중요한 정말 고품질을 요하는 업무와 적정한 품질로 처리해야 하는 업무에 대한 구분이다. 필자의 경험에 따르면 정말 고품질을 요하는 소프트웨어 개발의 범위는 전체 프로젝트 범위의 30%를 넘어선 적이 없다. 대부분은 변화가 있으며, 단순 처리되는 내용들이므로, 적절한 품질로 대응이 가능하다.
단순한 crud성 화면 프로그램에 엔진에서 검토해야 하는 품질 절차와 리소스를 투입하는 바보 같은 짓을 되풀이해서는 안된다. 전체적인 품질 테스트에서도 충분하게 검토될 내용과, 단위 테스트와 아키텍처적인 관점에서 접근해야 하는 고품질의 영역을 제대로 구분해 내는 것 또한 소프트웨어 개발의 요구사항을 효과적으로 대응하는 것이다.
해야 할 일중에 정말로 고품질을 요하는 소프트웨어 개발업무를 구분하자
성과가 명확하게 보이는 개발업무로써, 해당 소프트웨어의 개발된 서비스의 실체와 가치가 완벽하게 드러난 일이다. 또한, 해당 서비스나 소프트웨어가 다른 개발팀이나 다른 서비스에 많은 영향을 주는 영역의 개발이라면 당연하게도 ‘고품질’이 요구된다.
다만, 0순위처럼 '그 이익'이 정량화되지는 않았으나, 정성적인 기준에 의해서 그 가치가 명확해진 개발업무들이라고 보면 된다. 대부분 이러한 일들은 '요구사항'의 변화가 거의 없을뿐더러, 관료조직의 극성인 변덕스러운 직장상사도 필요한 요구사항을 틀지 못하는 경우가 많은 서비스이거나 업무에 해당한다.
또한, 이러한 대부분의 고품질 개발일은 이러한 '최선을 다해야 하는 일'인 경우이다. 하지만, 업무 순위를 결정할 때에 잘못하는 것 중의 하나가. 매일, 매번 이러한 '최선을 다해야 하는 일', ‘고품질’로 결정되어진다는 것이다. 그렇지만, 그렇게 결정된 ‘고품질 속성’은 잘못 결정된 판단일 가능성이 높다. 고품질은 많아야 전체 업무의 30% 정도이다. 그 이상으로 책정된다면, 평가기준부터 잘못된 것이므로 다시 살펴봐야 한다.
물론, 정확하게 일에 대해서 살펴보면 이렇게 구분하는 것은 대단한 업무 처리능력을 가진 기업이나 조직일 수 있겠지만. 그런 식으로 제대로 관리하는 기업은 한 번도 본 적이 없다. 관리의 S기업도 그렇게 정의하지는 않고, 안전이 가장 중시되는 항공기 관련 소프트웨어 개발에 있어서도 그런 식으로 기준을 정하지는 않는다. 이런 식으로 대부분의 업무가 '고품질'로 책정된다면, '업무의 중요도'를 잘못 판단하고 있는 것이다. 그러므로, 기준 작업과 검증작업을 다시 해야 한다.
다만, 개발업무내용에서 그 사용가치를 찾기 힘들고, 만들어진 결과물 또한 다른 서비스나 개발 조직에 별다른 기여를 하지 못할 것이 명백하지만, 최선을 다해야 하는 개발업무가 있다. 그것은 '사장님' 또는 개발 총괄 책임자가 만들어낸 업무이다. 그것은, 개발업무 우선순위에 있어서 '책임'은 윗분들이 결정한 것이기도 하지만, 고위층의 경영적인 판단에 의해서 움직이는 전략적인 업무일 수 있다.
보통 이러한 사항들은 '경영진의 의사결정'이기 때문에, 우선순위를 중요하게 책정해야 한다. 그리고, 이러한 ‘업무의 성격’은 명확하게 ‘요구사항’이나 ‘업무’에 명시가 되어야 한다. 그래야, 개발 조직은 개발함에 있어서 주저함이 없을 것이다.
대부분은 고품질이 아니며, 적절한 품질요건으로 만족하는 개발 영역
대부분의 '쓸데없는 일'이 아닌 보통의 개발업무들의 경우에 이 4번째에 해당한다. 이 소프트웨어 개발업무는 고품질이 아닌, 해당 개발업무의 기본적인 완성도만 추구하면 되는 일이다.
또한, 이러한 업무들은 대부분 QC와 QA의 업무가 구분되어져 있고, 해당 리소스를 투입하고 있는 경우에는 이 부분으로 처리가 되는 경우가 더욱더 많이 정의되게 된다. 가능한, 품질관리에 투입되는 리소스를 최소화하는 것이 전체적인 개발의 성과를 향상하게 된다. 소프트웨어 개발업무를 어떻게 하든 이 영역을 80% 이상으로 끌어올리는 것이 개발을 효과적으로 수행하게 하는 것이다. 필자의 경험에 따르면 ‘고품질’은 20%, ‘저품질’은 80%의 영역으로 설정하고, 고급 리소스는 ‘고품질’에 투입하도록 하는 것이 가장 합당하다.
일반적으로 소프트웨어 개발업무의 대부분의 구성 업무들은 이러한 '적당하게 해야 하는 업무'이다. 이 업무에는 '에너지'와 '시간'을 낭비하면 안 된다. 말 그대로, 적정하게 해야 한다. 그리고, 개발자들에게 ‘잉여’를 공급하게 하고, 반복적인 테스트와 품질 검토는 품질관리 조직에서 다양한 방법으로 접근하고, 문제의 발생을 추적하여 통보하여, 품질관리를 분리하는 것이 최선이다.
‘고품질’은 품질의 주요한 권한과 책임을 ‘개발자’에게 주는 것이고, ‘저품질’은 품질을 프로세스에서 검토하여 통보하는 방법으로 수행하는 것이다. 이는 개발 조직의 최대한의 역량을 ‘고품질’에 집중하게 하고, 단순 반복 테스트와 같은 업무를 소프트웨어 개발 조직에 있어서 가장 중요한 ‘개발 조직’을 효과적으로 활용하게 하는 것이다.
물론, 이러한 품질 관련 업무의 가장 중요한 고려사항은 직장상사나 동료들과의 커뮤니케이션을 가장 중요시하게 된다. 이러한 업무의 대부분은 '신뢰'가 전제가 되어야 하기 때문이다. 또한, 여기서 가장 중요한 것은 '신뢰받는 직장상사'와 ‘신뢰받는 부서’의 업무지시가 가장 핵심이 되게 된다. 또한, 이러한 업무의 우선순위가 정치적/심리적 변화에 따라서 변화되는 요구사항은 제대로 된 업무가 아닌 것이 된다. 이 부분이 가장 중요하다.
일반적으로 이해하고 있는 에자일의 핵심적인 요소는 위에서 잠시 설명한 ‘신뢰’를 어떻게 의사소통하느냐가 관건이다.
결론적으로 이야기하자면 소프트웨어 개발업무에 있어서 ‘업무의 우선순위’를 결정하는 요구사항을 분석하는 데 있어서 최고의 핵심 요소는 다음의 5가지를 잘 정의하는 것이다.
1) 업무의 가치
2) 업무의 원천( 누가 만들고 요구한 것인가? )
3) 기업의 가치 추구
4) 직장상사와 동료의 가치 추구
5) 고품질이 정말 필요한 업무의 구분
이러한 4가지의 관점을 어떻게 정성적이고 정량적인 방법으로 도출하며, 이를 의사소통하여 공통 관심사를 형성하느냐에 달려있다. 하지만, 현대의 관료화된 조직의 대부분들은 쓸모없는 요구사항들이 상당수를 차지하며, 해당 조직의 스트레스에서의 핵심 요소가 된다는 점이다.
이와 같이 업무의 요구사항들을 어떻게 구분하는 것인가부터 시작하는 것이 '요구사항 공학'의 기본적인 정의이다. 냉정하게, '업무의 가치'는 그 기업과 조직이 가지고 있는 '비전'과 '골'에 영향을 받는다.
그러므로, 경영진이 가장 똑똑해야 그 기업의 가치가 증대된다. 언제나 이야기하지만 경영자의 삽질을 이길 수 있는 슈퍼 개발자는 존재하지 않는다. 그것은 기적이다.
가입하기
