2016년 9월 21일 수요일

프로세스 혁신 관점에서의 Business Analyst 도입 효과

예전에 썼던 글인데 목표로 했던 곳에서 사용하지 않게 되어 블로그에 게재하기로 했다.

가. 혁신의 의미와 필요성

혁신(革新)이란 ‘묵은 풍속, 관습, 조직, 방법 따위를 완전히 바꾸어서 새롭게 함.’ <국립국어원 표준국어대사전>라는 뜻이다. 경영학자인 피터 드러커는 “경영 혁신은 기존의 지식, 제품, 고객의 요구, 시장 등에서 부족한 점을 발견하여 새롭고 더 생산적인 것으로 변화시키는 일이다.” 라고 말했다. 실생활에 있어서는 조직이나 개인들이 새로운 생각과 방법을 통해 여태껏 없었던 새로운 가치를 만들거나 기존에 있던 가치를 더욱 크게 만드는 것을 혁신이라는 말로 표현한다. 가치의 창출이 혁신이 지향하고자 하는 바임을 정확하게 이해할 필요가 있다.

BA는 새로운 생각과 방법을 도출하기 위한 기법을 제공함으로써 혁신에 기여한다. 기존에 없었던 가치를 만들어 내기 위해서는 다양한 관점을 가진 사람과 조직이 모여 의사소통 해야 하고, 전체와 세부사항을 아우르는 폭 넒은 시각으로 문제를 바라보아야만 한다. BABOK에서는 Elicitation, Requirement Management and Communication, Requirement Analysis라는 지식 영역에서 문제를 보는 시각을 갖도록 하여 사람들이 해결을 위한 아이디어를 만들어 내는 것을 돕는다.

또한 BA는 도출된 새로운 아이디어를 행동을 통해 직접 가치로 전환시키는 솔루션을 적용하는 경우에도 Solution Assessment and Validation이라는 지식 영역에서 가이드라인을 제공하고 있다. 실제로 개인 고객이나 고객 회사에 가치를 제공하기 위해서는 실행력을 필요로 한다. 최근에는 모든 조직에서 IT기술을 활용하여 나름대로의 정보시스템을 보유하고 있다. 실행력이란 조직이 보유한 정보시스템과 그것을 사용하는 조직원을 통해 실현된다. 정보시스템으로는 ERP, BPM 같은 SW가 널리 사용되고 있다. 정보시스템에서는 프로세스, 데이터, 역할을 정의하여 업무를 수행하도록 한다. BA는 정보시스템에 아이디어를 적용하여 효과가 있는지 검증하게 되는데 이 과정에서 새로운 아이디어를 프로세스, 데이터, 역할 관점에서 변경하고 효과가 있는지를 사전에 세워둔 목표(KPI)과 비교하여 검증한다. 효과가 있는 것으로 검증되면 정보시스템과 사람들에게 새로운 방법을 널리 퍼뜨리고 적응시켜 목표를 달성해 나가면서 혁신을 이루어 낼 수 있다.

혁신이 필요한 이유는 무엇인가? 혁신하지 않으면 생존 자체를 위협받기 때문이다. 헤라클레이토스(기원전 530~470)는 “만물은 변한다. 변하지 않는 것은 세상의 모든 것이 변한다는 사실뿐이다.”라고 말했다. 예나 지금이나 모든 것이 변한다는 사실에는 차이가 없지만 그 속도에 있어서는 차이가 매우 크다. 문명의 발전 속도가 가면 갈수록 가속화되어 점점 더 빨라지기만 하기 때문이다. 이제 이 시대를 살고 있는 기업, 정부, 비영리단체, 개인 모두는 변화하지 않으면 살아남기 힘들다는 생각을 떨쳐버리기 힘들게 되었다. 변화한다는 사실을 받아들이고 어떻게 하면 변화를 꾀할 수 있을지 많은 고민을 하고 있는 상황이다.


나. 혁신의 조건

‘혁신’이라는 개념과 ‘개선’이라는 개념을 엄밀하게는 다르게 보는 관점도 있지만, ‘적극적으로 변화에 적응하고자 하는 노력으로 인한 결과’이라는 측면에서는 공통점이 있기 때문에 여기에서는 그 둘을 구분하지 않고 ‘혁신’이라고 부르도록 한다. 혁신은 조직 내외의 환경변화에 민감하게 반응하는 유연한 사고를 가진 사람들이 민첩하게 동작하는 조직내의 정보시스템(ERP, BPM)을 잘 활용하여 새로운 변화(사업모델, 운영방식, 새로운 제품)를 만들어내어 가치를 창출하도록 도와주고 믿어주는 리더십이 있어야 가능하다. 먼저 변화하지 않으면 도태된다는 신념과 새로운 가치를 창출하는 것이 목표라는 생각을 가진 다음, 유연하고 쉽고 빠르게 변화하기 위한 환경을 사람들, 정보시스템, 조직문화에 내재해야 한다. 이 모든 조건이 갖추어 졌을 때 비로소 혁신은 결과로서 나타나게 된다.

다. 혁신의 방법

혁신을 이루어내기 위한 일반적이고 범용적인 이론이나 방법론은 많이 접할 수 있다. 그렇지만 각 조직은 처한 환경이 모두 다르므로 이론과 방법론의 정수를 습득해서 이해한 후 자신들의 상황에 맞추어야 한다.

옷을 고를 때를 예로 들어보기로 한다. 사람은 나에게 딱 맞으면서도 싼 가격에 빠르게 옷을 갖고 싶어한다(목표). 기성복을 고르면 많은 선택이 가능하고 (맞춤복에 비해) 상대적으로 저렴한 가격에 옷을 고를 수 있다. 하지만 자신만의 신체적 특징(ex. 팔이 긴 경우)으로 인해 자신에게는 딱 맞지 않는 경험을 하기도 한다. 이에 반해 맞춤복을 선택하면 처음부터 몸의 사이즈에 대한 치수를 정확하기 측정해서 만들므로 신체적 특징에 맞는 자연스러운 옷을 얻을 수 있다. 대신 옷이 만들어지기까지의 제작기간과 (기성복에 비해) 상대적으로 비싼 가격을 주고 옷을 사야한다.

혁신을 위한 이론과 실제실행은 기성복과 맞춤복의 관계와 닮아있다. 이론과 현실실행은 서로 제공하는 가치가 다르기 때문에 목표를 명확하게 하고 이론과 실제실행을 모두 고려해서 조직에 맞는 방법을 찾아내야만 한다. 이 과정에서 BA가 조직 내외의 주체들을 연결하는 고리로서 활약할 수 있다.

BA가 활약해야 할 부분과 혁신을 어디서 어떻게 만들어 내는지 구체적으로 살펴보기 위해 [그림]을 참고하도록 한다. 조직 내부에는 리더십과 조직원, BA가 주체로서 존재한다. 조직 외부에는 고객과 외부환경(트렌드, 법, 규제 등)이 있다. BA는 리더십으로부터 미션과 비전, 사업전략에 대한 정보를 얻는다. 조직 내의 다른 조직원들로부터는 불만이나 개선 아이디어를 얻을 수 있을 것이다. 외부에 있는 고객에게서는 요구사항이나 수요에 대한 정보를 얻고 외부 환경에서는 트렌드나 사업 기회와 같은 정보가 BA에게로 흘러 들어온다. BA는 최대한 받은 정보들을 분석하로 체계화하여 실행으로 옮기기 위한 작업을 BABOK의 다양한 기법을 활용하여 수행하고 그 결과를 각 프로세스에 반영한다.




그림. 혁신을 위한 조직 내외의 구성과 동작원리

정보시스템 부분은 삼베를 짜는 배틀에 비유해 보도록 하자. 조직 내의 비즈니스 기능(팀, 부서)를 세로줄인 날줄로 프로세스는 가로줄인 씨줄로 보면 쉽게 이해할 수 있다. 정보시스템은 각 역할을 가진 사람들 사이를 가로지는 프로세스와 그 과정에서 생겨나는 데이터, 지식을 통해 가치를 만들어 낸다. 여기에 새로운 발상과 아이디어를 접목시켜 기존에 있던 프로세스를 개선하거나 아예 없었던 프로세스를 만들어내면 새로운 가치가 발생하게 된다. 새로운 가치는 고객, 리더십, 조직원들에게 전달되어 혁신의 결과로써 인정받게 된다. 결국 핵심은 새로운 가치를 만들어 내는 것에 있고, 새로운 가치는 프로세스를 통해 직접적으로 발생한다. 보통 혁신을 말하면서 프로세스의 혁신으로 귀결되는 이유가 바로 여기에 있다.

프로세스는 정보시스템을 통해 실체화 되는데 프로세스와 관련된 정보시스템 기술은 IT의 발전과정과 그 궤를 같이 하여 발전해 오고 있다. 천공카드를 쓰던 시절부터 파일을 사용하기 시작하고, 데이터베이스를 사용하여 정보들을 체계화 했다. 데이터베이스를 통합하여 전사적 자원 관리(ERP)로 발전한 후 최근에는 프로세스 중심으로 업무를 다시 바라보는 비즈니스 프로세스 관리(BPM) 솔루션으로 진화해 오고 있다. BPM은 서비스 지향 아키텍처(SOA)를 통해 플랫폼에 상관없이 사용 가능한 서비스를 엮을 수 있게 되었고, 클라우드상에서 제공되는 서비스를 통해 많은 컴퓨팅 자원을 필요로 하는 작업도 처리할 수 있는 힘을 얻고 있다.

앞서 평면적으로 혁신을 위한 부분들을 보았다면 이제는 시간적인 순서로 혁신을 이루어 내는 과정에 대해 설명한다. 그 과정을 혁신 실천법이라고도 볼 수 있다.

혁신은 프로세스에서 새로운 가치를 창출해 냄으로써 가능하다. 희미하거나 있으나 마나한 프로세스에서는 혁신을 기대하기 어렵다. 혁신을 위해서는 있던 프로세스는 더욱 강화시키고 없던 프로세스는 새롭게 만드는 직접적인 실행 활동이 필요하다. 한 번 만드는 것으로 끝내면 일회성 이벤트로 끝나버리기 때문에 지속적으로 활동을 이어나가는 것도 필요하다. 혁신은 지속적으로 프로세스를 만들고 다듬어 나가는 과정을 통해 이루어진다.

프로세스를 가꾸어 나가기 위해서는 3단계를 거치면 된다. 먼저 사람들의 머리속에 있는 프로세스를 끄집어내어 눈에 보이는 형태(BPMN)로 만드는 시각화 단계(1), 시각화된 프로세스를 BPM이나 기타 프로세스를 동작시켜주는 시스템에 구현하는 시스템화 단계(2), 시각화화된 프로세스와 동작하는 시스템에 대해 조직 내외의 사람들에게 프로세스에 대한 내용을 전파하고 교육하여 적응시켜 자연스럽게 업무수행법으로 인식하게 만드는 체화단계(3)를 거치면 하나의 프로세스가 생성되고 강화된다. 그 후 반복적으로 다른 업무의 프로세스를 만들고 개선해 나가면서(이번에 인사관리의 채용 프로세스를 만들었다면 다음에는 평가 프로세스를 개선하는 식으로 진행하면 됨) 조직 전체적으로 활동을 지속해간다면 역량이 쌓이기 시작하여 임계점을 넘게 되면 조직적 차원의 혁신을 경험하는 시점이 오게 된다.


프로세스 개선 실천법에 대해서는 나중에 출간될 직접 집필한 책에서 자세하게 다룰 예정이다.


태그 :  , ,   With No comments 

2016년 8월 1일 월요일

CIO Korea, TechLibrary에 게재된 기사 링크 공유


평소에 즐겨보는 사이트인 CIO Korea에 6/29 Atlassian conference에서 발표했던 내용을 바탕으로 작성된 기사가 게재되었기에 링크를 공유합니다.

CIO Korea 기사 원문 링크
http://www.ciokorea.com/news/30710



TechLibrary 기사 원문 링크
http://www.itworld.co.kr/techlibrary/100552 (PDF)


태그 :  , ,   With No comments 

2016년 7월 6일 수요일

영업제로인데도 ‘팔리는’ 이유 – 창업13년만에 3900억엔 기업으로. 호주 아틀라시안에게 듣는 [급성장술]

원문링크 : http://www.itmedia.co.jp/news/articles/1502/27/news002.html

영업제로인데도 ‘팔리는’ 이유 – 창업13년만에 3900억엔 기업으로. 호주 아틀라시안에게 듣는 [급성장술]
’Confluence’나’HipChat’등 엔지니어를 위한 툴로 알려져 있는 호주 아틀라시안사는 창업후 겨우 13년만에 세계 135개국 4만개 회사 이상에 확산하여 기업가치가 3900억엔 달한다고도 알려져 있다. 급성장의 비결을 일본을 방문한 공동창업자에게 들어 보았다.
[PR/ITmedia]








스캇 파쿠아 Co-CEO
호주에 본사를 두고있는 소프트웨어 기업 아틀라시안사가 급성장을 계속하고 있다. 동사는 프로젝트/버그 관리 툴인 ‘JIRA’나 (문서를 통한) 협업 툴인 ‘Confluence’, 채팅 툴인 ‘HipChat’ 등 기업활동에 특화시킨 업무 효율화 소프트웨어를 폭넒게 전개하고 있다. Facebook이나 NASA, Tesla Motors등의 대형 고객을 시작으로 해서 세계 135개국 4만개사 이상에서 도입하고 있다.
창업은 13년 전인 2002년 (역자주- 본기사가 작성된 시점은 2015년2월임) 글로벌에서 급성장하여 그 기업가치는 벌써 33억달러(3900엔 상당)에 달한다고 알려져 있다. 미국이나 네덜란드, 일본 등에 현지 법인을 설립하여 종업원 수는 1200명이며 이번 연도에도 추가로 1000명을 추가할 계획이라고 한다.
글로벌에서 쾌속진격을 계속하고 있는 동사의 특징은 ‘영업팀은 일체 두지 않는다’라고 하는 유니크한 사풍이다. 영업없이 성장가능한 이유에 대해 일본을 방문한 아틀라시안의 공동창업자 겸 Co-CEO인 스캇 파쿠아씨에게 물었다.
학생 벤처임에도 B2B를 조준
 동사를 창업한 것은 파쿠아씨가 21세였을 즈음이었다. 뉴사우스웨일즈의 대학 재학중에 알게된 마이크 캐논브룩스씨와 2명에서 아틀라시안을 창업했다. ‘내가 마이크를 공동창업자로 고른 기준은 지인들 중에서 가장 머리가 좋았고, 함께 창업해줄 정도로 바보 같은 사람이었기 때문이다.’ 라고 말하며 파쿠아 씨는 웃었다.
 당시 넥타이를 매고 회사에 다니는 ‘샐러리맨’만은 되고 싶지 않았다고 한다. ‘취업활동은 하지 않았다. 가능한한 넥타이를 매지 않고 대졸초임정도 벌려면 어떻게 해야할까라는 생각을 하다가 얻어낸 결론이 창업이었다.’
 학생 벤처라고 하면 Facebook을 대표적인 회사라고 할 수 잇는 것처럼 일반인을 위한 제품을 만드는 기업이 많으나, 동사는 처음부터 기업을 위한 시스템에 특화시킨 서비스를 개발하고 있다. 학생이면서도 B2B에 염두에 두었던 이유는 무엇일까?
”재학중에 IBM이나 프라이스워터하우스쿠퍼스(세계1위 다국적 회계감사기업) 등의 대기업에서 엔지니어의 인턴쉽을 하고 있었다. 그 때 비즈니스 소프트웨어의 심각성을 눈으로 보았다. 나라면 훨씬 더 좋은 소프트웨어를 만들 수 있다고 생각했다. ”
[영업맨 없이] 팔리는 이유
 둘 다 엔지니어로 영업경험은 제로인 상태였다. 그럼에도 불구하고 회사 설립후 얼마되지 않아 큰 발주를 획득했다. 대형 항공사인 아메리칸항공으로부터의 수주였다. “아무것도 하지 않았는데도 팔렸다. 좋은 것을 만들면 영업이 없어도 팔린다라는 사실을 그때 확신했다.”
 지금도 동사에는 영업맨이 없다. ‘서비스가 고객에게 도달하기까지의 “저항”을 최소한으로 하고 싶다’라고 생각하기 때문이다. “되도록 많은 소프트웨어 개발자에게 접하도록 하기 위해서는 영업맨이 한사람 한사람에게 전화를 걸어서는 이미 늦어버리게 된다. IT업계에는 10인 미만의 작은 회사도 많이 있고 작은 회사에서는 특히 영업 비용을 쓸 수 있는 상황이 아니다.(역자주-아틀라시안도 당시에는 작은 회사였기 때문)”
그러면 어떻게 제품을 팔 것인가? 가장 중요한 것은 ‘입소문’이라고 한다. 현장의 엔지니어가 제품을 시험삼아 써보고 좋다고 생각하면 입소문으로 평판을 넓혀 나가는 방식이다. 그렇게 하기 위해 동사는 좋은 제품을 계속 만들어 내는 것을 가장 중요하게 여기고 개발에 최대한의 리소스를 투입하여 제품의 개선을 계속하고 있다.
“아메리칸 항공은 설마 우리 회사가 엔지니어 딸랑 2명인 회사라고는 생각하지 못했을 것이다”라고 말하는 스캇 파쿠아씨

 동시에 영업맨에게 문의하지 않아도 제품에 관한 모든 정보를 파악할 수 있게끔 웹을 통해 정보공개를 철저하게 했다. “특히 회사가 작은 기간 동안에는 가능한한 브랜드를 어필하여 도입사례를 공개하는 등 정보를 오픈하는 것이 중요하다.”
 영업맨의 존재를 부정하는 것은 아니다. “안티 영업맨이 아니라 오토메이션(자동화)의 프로다.” 라고 파쿠아씨는 자사의 ‘영업’을 정의한다.
 파쿠아씨는 생긴지 얼마 되지 않은 스타트업 벤처회사가 신뢰를 얻기 위한 “비법”도 알려주었다. “아메리칸 항공에게서 주문을 받았을 당시, 창업자 2명인 회사였지만 상대는 그렇게 생각하지 않았을 것이다. 마치 큰 회사인 것처럼 sales@atlassian.xxx support@atlassian.xxx 같은 20여개의 메일 주소가 있었기 때문이다. 인터넷은 자신을 부풀려서 보여줄 수 있는 좋은 곳이다.”
급성장을 뒷받침하는 “메쉬형 커뮤니케이션”
”대부분의 회사는 틀린 조직구조를 가지고 있다.”라고 파쿠아씨는 지적하면서 자사의 “메쉬형” (조직)구조가 급성장으로 연결되었다라고 말한다. (역자주-애자일 방법론에서 자기 조직화된 팀을 가지게 하는 것과 쿄세라 창업주인 이나모리 가즈오가 말하는 ‘아메바 경영’과 일맥상통하는 부분이 있다.)
많은 기업의 조직은 피라미드형으로 하층에 있는 사람은 결재권을 가지지 못한다. 하지만 아틀라시안에서는 “메쉬형”의 조직을 설계하여 톱에서는 방향성만을 정하고 현장에 큰 재량을 부여하여 판단을 위임하는 것으로 행동을 스피드업하고 있다. “경영자는 회사의 방향성을 생각하는 것에 에너지와 시간을 집중하고 어떻게 수행할지는 아래에 맡기고 있다.”라는 것이다.
사내에서는 정보공유를 철저히 한다. “동료의 급여 이외의 모든 것을 알고 있다.”라고 말할 수 있을 정도로 오픈된 조직운영을 하고 있어 글로벌에서의 개발상황이나 버그 대응상황 등도 공유하고 있다. 그렇게 하기 위해서 예를들면 버그가 발견된 경우에도 호주의 엔지니어가 퇴근한 뒤 그 대응이력을 보고 아직 근무시간중인 일본의 엔지니어가 대응하는 등 국경을 넘어선 협력도 용이하다고 한다.
동사의 제품이 (고객에게서) 선택받는 이유 중 하나로 flat한 조직구조이기에 가능한 “현장시선”이 있다. “HP나IBM등 기존의 소프트하우스의 제품은 종이로 처리하던 것을 PC로 옮겨보자라는 발상에서 만들었으나 우리 회사의 제품은 개발자 시점에서 개발자를 위해서 만들고 있다. 관점이 전혀 다르다.”
동사의 제품을 도입하면 메쉬형 커뮤니케이션을 촉진하는 것이 가능하다고 한다. 예를 들면, 사이버 에이전트(역자주-일본의 인터넷회사)의 ‘아메바’ 서비스 운영팀은 confluence를 도입하여 복수의 부서, 층에 걸쳐 근무하고 있는 엔지니어나 디자이너 간에 소스코드나 개발 툴의 정보를 다방면에서 공유하는 것으로 업무효율을 높이고 커뮤니케이션의 활성화로 연결하고 있다.
또한, 여행온라인 예약서비스인 Expedia나 saleforce.com, Dropbox는 사내에서 채팅 툴인 HipChat을 활용하고 있다고 한다. 이렇듯 동사의 제품을 도입하여 메쉬형 커뮤니케이션을 실현하고 있는 예는 셀 수 없을 정도이다.
 일본에는 피라미드 구조의 회사가 아직도 많지만, 메쉬형으로 바뀌는 것이 가능할까? “일본에서도 젊은 세대는 스스로 판단을 할 수 있고 메쉬형 구조로 설계된 Facebook와 같은 SNS에도 익숙하다. 이런 젊은 사람들이 대기업에 들어가 문화를 바꾸던지 자신이 회사를 만들던지 하는 수밖에 없다. 다른 나라에서는 이미 그렇게 되고 있기 때문에 일본도 그런 흐름을 따라가지 않을까 생각한다.”
호주에서 일하는 보람이 1등인 회사로
동사는 ‘호주에서 일하는 보람이 1등인 회사’라고 알려지게 되었다.  “세계135개국에서 의료부터 자동차, 우주관련 등 거의 모든 분야에 걸쳐 4만개 이상의 회사가 당사의 툴을 사용하고 있다. 많은 기업의 업무를 개선할 수 있었던 것은 매우 큰 의미와 보람이 있는 일이다.”
게다가, 현장에 재량권을 부여하는 “메쉬형”의 조직체계가 한사람 한사람이 자발적으로 판단하여 행동하는 문화로 연결되어 사원의 하려는 마음과 기동력을 높이고 있다고 한다. 급성장하면서도 조직의 문화를 유지해 가는 것은 “간단한 일이 아니다”라고 하면서도 입사시의 트레이닝을 철저하게 실시하는 것으로 통풍이 잘 되고 일하기 쉬운 문화를 유지하고 있다라고 파쿠아씨는 말한다.


태그 :  ,   With No comments 

2016년 6월 10일 금요일

소프트웨어 공학 국제표준 SEMAT Essence를 JIRA에 구현해 보기



SEMAT Essence라는 소프트웨어 공학 국제표준이 있다.

SW를 개발할때 적용하는 수많은 방법론의 공통적인 핵심부분을 뽑아내서 공통의 기호를 통해 표현하고 각 방법론을 비교할 수도 있게 해주겠다는 야심찬 의도를 가지고 추진하는 국제표준(OMG)이다. Essence에 대해 알게 된지는 2년도 넘었지만 겉핥기 식으로만 알고 있던 상태였는데, 최근들어 회사에 적용하고 있는 개발방법론을 버전업하려고 생각하다가 Essence를 JIRA에 구현해 보면 어떨까라는 생각이 들었고, 실제로 만드는데 성공해서 그 내용을 정리하고자 한다.

JIRA에 구현하려는 마음을 먹게 된 계기는 멤버로 참여하고 있는 BA전문가포럼에서 고맙게도 한글로 번역한 알파상태카드를 받았던 것이었다. 지금까지 Essence의 개념에 감동을 받았지만, 사내에 확산시키기에는 영어로 된 자료밖에 없다는 것이 가장 큰 장애물이어서 펼칠 엄두도 못내고 있던 상황이었다. Essence가 다루는 분야는 매우 방대하지만 그중에서도 핵심이 되는 알파에 대한 것만이라도 한글화가 된다면 실제로 업무에 적용했을때 큰 효과를 볼 수 있을 것이라는 확신이 들었다. 팀 주간 회고시간에 받아온 카드가지고 현재 진행되고 있는 프로젝트들의 상황을 카드놀이 식으로 늘어놓았는데 각 프로젝트별 상황이 깔끔하게 정리되어 보이는 것은 물론이고, 다른 팀원들도 그 상황을 쉽게 파악하는 모습을 보니 큰 가능성을 느낄 수 있었다.

자세한 내용을 설명하기에 앞서 SEMAT에 올라와 있는 참여자들의 의도를 엿볼 수 있는 Call for Action(원문링크)이라는 글을 살펴볼 필요가 있다.

소프트웨어 공학은 지금 미성숙한 실천법(practice)에 의해 중대한 저해(gravely hampered)를 받고 있다. 예를 들어 구체적으로 아래의 항목과 같다.
- 개념의 유행이 엔지니어링(공학 및 기술활동)의 한 분야라기 보다 패션업계와 비슷함.
- 확실히 널리 수용된 이론적 기초가 결여되어 있음.
- 매우 많은 방법론(methods)과 그 파생들. 또한 그것들 사이의 차이를 거의 이해할 수 없는 상태로 작위적으로 강조되고 있음.
- 신뢰할 수 있는 실험적 평가(experimental evaluation)와 타당성 확인(validation)이 결여되어 있음.
- 산업계의 실천법(industry practice)과 학계의 연구(academic research)와의 괴리가 존재함.
우리들은, 견고한 이론 및 검증된 원칙과 베스트 프랙티스에 기초하여  소프트웨어 공학을 재건(refound)하고자 한다.
 그 방법은 이하의 특징을 가지고 있다.
널리 합의된 요소들로부터 특정용도에 확장 가능한 핵심(Kernel)을 가져,
기술의 문제와 사람의 문제 양쪽을 모두 포용할 수 있고,
산업계, 학계, 연구자 그리고 사용자들에게 지지를 받는,
(새로운) 요구사항들과 기술(technology)의 변화에도 대응가능하며,
(표준으로서) 따를 수 있도록 하는 확장성을 제공한다. 
처음 이 글을 읽었을 때의 느낌이 생생하다. 당시 사내에 적용할 개발방법론에 대한 자료를 찾느라 머리가 너무 복잡했던 때라 더 큰 감동을 느꼈다. Essence에 대해 조금이나마 알고나니 '세상에 난무하는 모든 방법론을 하나의 언어로 표현한다는 것이 과연 가능한 일일까?'라는 의문은 깨끗하게 풀려버렸다. 이 사람들 정말 대단하다라는 생각 밖에 들지 않았다.

Essence에 대해 조금만 알아보기로 하자. 실은 나도 아직 정확하게 이해하고 있다고 자신하기는 어려운 상황이기는 하다.


Essence는 가장 핵심적인 개념인 커널을 가지고 있다. 크게 4가지 요소(알파, 액티비티 스페이스, 패턴, 컴피턴시)가 있고 그 중에서도 SW를 개발하면서 어떤 것을 고려해야 하는가를 표현하는 알파가 가장 중요하다. 알파는 7개가 있고 그것들 사이의 관계는 아래와 같다.



각 알파는 그 안에 프로세스처럼 표현되는 상태(state)를 가지고 있고, 각 상태는 완료조건이 되는 체크리스트를 가지고 있다.

상태와 체크리스트는 범용적으로 적용될 수 있는 내용들인데 이 항목들만 잘 챙기더라도 SW개발 프로젝트를 성공시킬 가능성이 매우 높아질 것이라 확신한다. 그간 성공의 법칙은 뛰어난 PM, 아키텍트, 개발자의 머리속에만 있었을 텐데 그 지식들이 세상밖을 튀어나온 것이라 해도 무방하지 않을까?

여기까지 보면 대충 Essence의 알파가 어떤 구조로 되어 있는지 감을 잡을 수는 있을 것이다. 자세한 것은 검색을 해보거나 책을 읽어보거나 표준문서를 직접 읽어 보는 것을 권한다.

파악하기 가장 좋은 방법은 아래의 카드를 입수해서 내용을 읽어보고 카드놀이를 좀 해보는 것일 것이다. 현재는 KOSTA에서 비매품으로 교육생들 대상으로 배포하고 있다. BA전문가포럼 세미나에서 구입할 수 있는 방법이 있는지 물어봤었는데 계획이 없다고 한다. 진가를 느껴보고 싶다면 어떻게든 입수해 보기 바란다.


카드같은 오프라인으로 하는 방법이 기본이겠지만 SW프로그램으로 만나볼 수도 있다.
아래는 아이패드용 앱으로 사용 가능한 Alpha State Explorer라는 앱이다. 영어로 되어 있어 불편함은 있겠으나 알파를 이해하고 프로젝트에 적용해보기 가장 좋은 SW라고 생각한다.

실제로 JIRA에 구현할 때도 이 앱을 레퍼런스 삼아서 비슷하게 구현했다.


글씨가 작아서 잘 보이지 않을 수도 있으나 느낌만 받아도 충분하리라 생각한다.

JIRA에 구현한 내용을 간략하게 설명해 보도록 하겠다.
기본적으로 JIRA Agile Kanban을 사용하고, 이슈타입은 7개의 알파로 생성하고 각 상태를 JIRA의 아이템으로 생성했다. 상태의 완료체크리스트는 커스텀 필드로 만들어서 한글 번역된 카드의 내용을 그대로 타이핑해서 입력해 두었다. Agile board에서 각 아이템을 클릭하면 체크리스트 내용이 표시된다. 화면에 노랗게 보이는 아이템들은 깃발을 올린 아이템들이다. 깃발을 올리는 것으로 상태가 완료되었음을 표시하는 것이 가능하다.

이렇게 만들어 두니 한 화면에서 프로젝트의 진행상황을 일목 요연하게 보는 것이 가능하다. 각 상태들은 JIRA의 이슈아이템이기 때문에 담당자들이 상세내용을 입력할 수도 있고 다른 페이지 링크를 하거나 산출물을 첨부파일로 업로드 하는 것도 가능하다.

아직 실제 프로젝트에 적용까지 해보지는 못한 상태이나 매우 유용하게 사용될 것이란 확신이 든다. 나중에 적용하게 되면 실제 사례내용도 업데이트 할 것이다.

앞으로의 계획은 현재 준비중인 사내 개발방법론2.0의 핵심개념이자 실제로 시스템에서 동작하는 도구로 제공하고 프로젝트 관리에 사용하도록 이끌어 나가는 것이다. 사내 표준으로 승인받아야 하는 과정이야 있겠으나 꼭 설득에 성공해서 실제 프로젝트에 적용해 보고 싶다.







태그 :  , , ,   With No comments