SRS를 개발 후에 연습하는 차원으로 적어보면 도움이 되지 않을까?

소프트웨어를 개발하는데 있어서 가장 어렵고도 중요한 것은 SRS(Software Requirements Specification) 즉, 스펙을 잘 작성하는 것이다. 

그럼 SRS 작성법을 배우고 싶은데 어떻게 해야 할까?

남이 작성한 SRS를 보면 도움이 될까? 

가상으로 한번 써보면 도움이 될까? 

케이스별로 얼마나 도움이 될지 알아보자.

1%

스펙을 작성하는 방법을 배우기 위해서 남이 작성한 SRS를 보는 것은 얼마나 도움이 될까?

1%정도 밖에 도움이 안된다.

남이 치는 피아노, 골프를 보고 얼마나 도움이 될지 생각해보면 된다. 작성한 SRS의 내용이 그러게 도출되는 과정을 겪지 않고 결과만 보는 것은 1%밖에 보이지 않는다.

10%

그럼 실제 프로젝트에 적용하기는 어려우니 가상의 프로젝트를 생각해서 작성하면 어떻게 될까? 10% 정도는 도움이 될 수 있다. SRS에 포함된 수많은 내용 중에는 실제 상황이 아니면 도저히 생각해 낼 수 없는 부분들이 많다. 이런 부분은 가상의 프로젝트에서는 배우기 어렵다.

30%

이미 끝난 프로젝트의 SRS를 적어보는 것은 어떨까? 나중에 혹시 유지보수에 도움이 되지 않을까? 별 도움이 되지 않는다. 

SRS는 원래 개발하기 전에 개발을 빠르게 하기 위해서 적는 것이다. 이미 종료된 프로젝트라면 적을 수 없는 부분이 많다. 또한 꼼꼼하게 적지도 않게 된다. 미리 적는 SRS처럼은 절대로 적을 수가 없다.

이미 코딩까지 끝났기 때문에 창의적인 생각이 필요한 Interface 등은 제대로 적기 어렵다. 현재 상태를 Reverse Engineering으로 적는다고 해도 깨끗하게 적을 수 없을 뿐더러 뒤죽박죽이라서 적어봐야 아무 의미 없는 경우가 대부분이다. 또는 SRS를 작성하면서 필요한 커뮤니케이션 스킬, 분석 능력, 인터뷰 능력 등은 전혀 익힐 수가 없다. 이러한 것을 빼고 내용만 일부 Dump하는 것은 Template을 익히는 것밖에 기대하기 어렵다.

100%

SRS 작성하는 법, 스펙을 작성하는 법, 요구사항을 분석하는 법을 제대로 배우려면 크던, 작던 실제 프로젝트에서 SRS를 적어봐야 한다. 어떠한 프로젝트도 SRS의 모든 챕터를 다 커버하는 것은 없다. 따라서 하나의 프로젝트에서의 경험은 상당히 제한적이다. 오랜 기간동안 여러 프로젝트의 SRS를 작성해봐야 배울 수 있다.

따라서 일단 실제 프로젝트에서 작성해보는 것이 가장 좋은 방법이다. 물론 피아노를 코치없이 배울 수 없듯이 경험이 많은 선배나 전문가의 도움을 받는 것은 꼭 필요하다.

내가 없어도 회사가 잘 돌아가면 왠지 불안하다.

그동안 이래저래 바쁘다는 핑계로 블로그에 글을 못올리고 있다. 앞으로 짧막하게라도 글을 올리려고 한다.

내가 만약 일주일동안 회사를 안나오면 회사가 잘 돌아갈까?

그럼 한달동안 안나오면 어떻게 될까?

대부분의 소프트웨어 회사는 한달동안 심지어는 일주일만 직원 몇명이 안나오면 심각한 문제를 일으키곤 한다.

이러한 종속성은 회사에게는 큰 위험이고 개발자에게는 양날의 검이다.

개발자는 본인이 없으면 회사가 잘 안돌아가는 상황을 선호하곤 한다. 실제로 우리나라에서는 개발자들이 자리를 지키기 위한 좋은 수단이 되기도 한다.  하지만 개발자가 좀더 중요하고 새로운 일을 하는데 발목을 잡히곤 한다.

물론 내가 없어도 회사가 쌩쌩 잘 돌아가는 상황이 매우 불안한 사람도 있을 것이다. 또한 그렇게 합리적으로 돌아가지 않는 회사도 있으니 잘 판단해야 한다.

개발자 뿐만 아니라 Operating에서도 문제는 벌어진다. 특정 직원이 없으면, 빌드나 팩키징을 못하거나 라이센스 발급이 안되는 경우도 있다. 업무는 특정인만 아는 형태로 진행되어서는 안되고 메뉴얼이 필요하고 백업이 가능해야 한다.

회사 입장에서는 리스크일 뿐만 아니라 이런 현상이 벌어지고 있다는 것 하나만 봐도 소프트웨어 개발 전반에 많은 문제가 있다는 것을 짐작할 수 있다.

첫째, 많은 정보, 지식이 특정인 머리 속에 들어 있고 시스템화 되어 있지 않다는 것을 알 수 있다. 또한 리뷰를 통한 공유가 잘되어 있지 않은 것이다.

둘째, 스펙이 제대로 작성되어 있지 않은 것이다.

세째, 개발 프로세스가 제대로 구축되어 있지 않은 것이다. 그 외에도 문제가 많다.

회사는 어떠한 개발자라도 한달 동안 또는 영원히 사라져도 문제 없이 돌아가는 상황이 되어야 한다. 이렇게 하기 위해서 프로세스, 스펙/설계, 기반시스템, 개발 문화를 제대로 구축하는 것이 부담이 된다고 생각하는 경우도 있다. 이는 무조건 주먹구구가 더 빠르고 효율적이라고 주장하는 것과 같다. 초 단기적으로는 주먹구구가 더 나을 수는 있지만 이런 상황은 오래 지속되지 않는다.

특정 개발자가 없어도 잘 돌아가는 환경은 개발자에게도 유리하다. 그래야 개발자는 과거의 일에 발목을 잡히지 않고 합리적으로 일할 수 있는 환경이 된다.

이를 검증하기 위해서는 개발자에게 휴가를 한달씩 줘 보면 된다. 개발자에게 한달짜리 휴가를 줄 수 있는 회사가 되어보자.

넣는 것 보다 빼는 것이 더 어렵다.

초창기에 좋은 소프트웨어로 성공하는 업체들이 지속적으로 성장하지 못하고 고전을 면치 못하는 이유는 여러가지가 있다. 그중 하나가 제품이 점점 과도하게 비대해지는 것을 꼽을 수 있다.

성공하는 회사들의 초기 제품은 간략하고 핵심적인 기능으로 사용자들의 요구를 만족시켰다. 하지만 시간이 흐를 수록 경쟁상대가 많아지고 선두를 유지하거나 따라잡기 위해서 제품은 기능은 경쟁 제품들의 모든 기능을 다 포함하기 시작하곤 한다.

고객이 많아질수록 고객들의 요구사항도 다양해지고 하나의 고객도 놓치기 싫어서 가능하면 모든 요구사항을 신제품에 다 우겨 넣으려곤 하다.

이렇게 온갖 기능이 다 포함된 제품을 우리는 "Kitchen Sink"라고 한다. 설거지통에 닦아야 할 그릇들이 잔뜩 쌓여 있는 모습을 상상해보라.

기본적으로 영업은 한명의 고객도 놓치기 싫어서 무조건 고객의 요구사항을 다 들어달라고 요청을 한다.

이것을 조정해서 새로운 제품의 전략을 수립하는 부서는 마케팅부서이다. 하지만 내 경험에 의하면 우리나라의 많은 소프트웨어 회사들은 마케팅보다 영업에 가깝다. 소프트웨어 제품 전략에서 중요한 것은 많은 기능을 넣는 것보다 얼마나 적은 기능으로 최대한의 고객을 만족시키느냐이다. 경쟁제품을 모두 조사해서 슈퍼세트의 제품을 기획하는 일은 쉽다. 어려운 일은 기능을 빼는 것이다.

기능을 빼는 과정에서 기존의 고객을 잃을 수도 있다. 하지만 이것이 두려워서 "Kitchen Sink" Software를 만든다면 더 큰 것을 잃을 수도 있다.

하지만 많은 사람들이 기능을 빼는데는 익숙하지 않다. 영업, 마케팅은 물론이고 마음씨 좋은 개발자들이 기능을 빼는 것을 주저하기도 한다. 그러면 제품의 아키텍처는 점점 복잡해지고 회생 불가능한 상태가 되곤한다.

스펙을 적을 때도 지원할 기능 외에 뺄 기능도 잘 기술해야 한다. 스펙에 지원하지 않을 기능을 적는 것은 지원할 기능을 적는것보다 더 중요할 때가 많다. 물론 모든 미지원 기능을 적는 것이 아니고 기존에 있던 기능을 빼거나 누구나 능히 포함될 것으로 생각하는 기능을 뺄때는 꼼꼼히 적어줘야 한다.

그래서 마케팅팀의 역할이 더욱 중요하다고 할 수 있다.

1%의 사용자도 쓰지 않는 수많은 기능을 개발하느라고 개발 비용은 훨씬 많이 들어가고 프로젝트가 망가져가는 것을 흔히 볼 수 있다. 중요한 것은 넣은 것이 아니고 빼는 것이다.

[공지] 요구사항 분석 세미나를 실시합니다. - 마감되었습니다.

소프트웨어를 개발하는데 있어서 가장 어려운 것을 하나 꼽으라면 "요구사항분석"입니다.

소프트웨어를 개발하는데 있어서 가장 중요한 것을 하나 꼽으라도 "요구사항분석"을 선택합니다

하지만 우리나라에서 "요구사항분석" 역량을 제대로 갖춘 개발자를 만나보는 것은 매우 어렵습니다. "요구사항분석"은 교과서를 통해서 배울 수 없고 실전을 통해서 익혀야 하는데 우리나라는 자수성가한 개발자들로부터 시작되고 이어져 왔기 때문에 이를 가르쳐 줄 수가 없었습니다. 대기업에서는 대규모 방법론이나 비싼 툴을 사용하여 "요구사항분석"을 해보려고 하는데 아무리 비싼 골프채가 있어도 골프를 잘치는 것은 딴 얘기이듯이 툴이 이것을 해결해주지는 않습니다.

결국은 요구사항분석의 핵심을 꺠닫고 꾸준히 현실 프로젝트에서 경험을 쌓아가는 것이 유일한 방법입니다. 그래서 그 실전적인 방법을 공유하고자 세미나를 개최합니다. 많은 성원 부탁합니다. 

시간과 장소는 아래 URL 참조하세요. 

http://projectresearch.co.kr/2013/03/11/대한민국-개발자들이여-깨어나라-올바른-sw-개발-방법/

참석하실 분들 댓글 달아주시고, 여기(http://onoffmix.com/event/13214)로 신청하시면 됩니다.

투명한 개발 문화의 효과

흔히 투명한 개발이 효율적이고 좋다고 한다. 그 진정한 의미를 알아보자.

투명한 개발이란 개발에 관련된 거의 모든 정보와 지식이 공유되는 것을 말하지만 추가로 내가 강조하고 싶은 것이 따로 있다.

거의 모든 결정의 과정 및 결과가 공개되고 기록되는 것이다. 이것의 효과는 꽤 대단한다. 이슈관리시스템을 이용하여 모든 정보를 공개하는 것도 좋은 방법이다. 결정해야 할 이슈들을 공개하고 결정 과정이 공개되면 근거가 부족한 일방적인 주장을 하기가 어려워진다.

일방적인 주장이라고 하면 특정부서의 입장만 밀어붙이거나 윗사람이라고 해서 일방적으로 우기는 것을 예로 들 수 있다. 영업의 입장, 회사의 비전, 개발 비용등 여러가지를 고려해야 할 결정에 영업의 입장대로만 주장하여 그렇게 결정되면 장기적으로 회사에 손해가 될 수 있다.

또, 2주는 더 걸릴 일을 추가해 놓고 일정을 전혀 손댈 수 없다고 주장을 한다면 그러한 주장이 공개된다면 상황이 좀 달라질 수도 있다. 무조건 우기기보다는 합리적인 해결책을 찾는 시늉이라도 하게 될 가능성이 높다. 그런 상황에도 독선적인 결정을 하고 그런 과정이 모든 직원들에게 공개가 되고 그런 일이 반복된다면 그런 주장을 하는 사람의 능력을 의심하게 될 것이다.

물론 이런 변화는 하루 아침에 일어나지도 않고 모든 정보가 투명하게 시스템에 기록되는 일이 쉽게 이루어지지는 않는다. 수평적인 구조와 성숙한 개발문화를 가지고 있다면 자연스로운 일이지만 그렇지 않은 조직에서의 변화는 쉽지 않고 오래 걸리는 일이다.

이럴 때는 개발팀이 주도하여 개발과정이 투명하게 공개되도록 유도를 하는 것이 좋다. 개발팀 스스로가 최대한 이슈를 등록하고 사소한 요청이나 결정사항도 이슈관리시스템을 통하고 타부서의 사용률이 저조하면 도와줘서라도 타부서 사람들도 점차 끌어들이는 것이 좋다. 경영진의 후원도 필요하지만 개발팀 스스로도 많은 노력을 해야 한다. 

우리가 흔히 모여서 회의를 통해 논의하고 결정하는 것 중 상당수는 시스템을 통해서 가능하다. 사람들이 물리적으로 모이는 것은 매우 많은 비용을 지불해야 한다. 가능하면 시스템을 이용하는 습관을 들이면 좋다. 또한 모여서 결정한 것도 시스템에 등록을 하면 좋다. 이때 최종 결정 사항외에도 그 과정과 누가 무슨 주장을 했는지 핵심적인 것을 요약해서 기록을 해주면 좋다. 이런 것이 일상화 될 때까지는 신경을 써서 노력해보자.

정보와 지식, 의논 내용 등을 기록으로 남기는 것이 습관이 들지 않으면 상당한 부담인 것이 사실이다. 하지만 모두가 어느정도 몸에 벤다면 오히려 더 시간을 절약해주고 효과적이라는 것을 알게 될 것이다.

내가 오늘 주장하거나 결정한 것이 내일 아침에 신문에 나도 나는 떳떳한가? 대부분의 정보가 공개되면 이와 비슷한 효과가 있어서 일방적인 주장이 좀 줄어 들 수 있다. 또한 한번 기록으로 남은 것은 추후 되돌아 봤을 때 언제 잘못된 결정을 했는지도 잘 알 수 있다. 말로해서 사라지거나 메일에 묻혀서 찾기 어려운 것은 그런 역할을 할 수 없다. 물론 모든 것을 기록으로 남기는 것은 불가능하지만 해보면 어디까지 남겨야 하는지 저절로 알게 된다. 걱정할 필요가 없다.

투명한 개발을 꺼려하는 개발팀도 많은 것을 알고 있다. 스펙의 많은 부분이 개발자들 머리속에 있고 뭘하나 알려고 해도 개발자에게 물어봐야 하고 온갖 정보를 숨겨서 개발자가 쥐고 있으면 그것이 곧 파워라고 생각하는 경우도 있다. 물론 단기적으로 맞는 말일 수 있으나 장기적으로는 개발자에게 오히려 손해인 경우가 많다. 회사 차원에서는 장/단기적으로 모두 손해다.

보통 개발팀은 여러가지 불합리한 것들 때문에 고생을 한다. 일방적인 요구사항 추가/변경이나 그럼에도 불구하고 무리한 일정에 많이 시달리곤 한다. 투명한 개발은 여러가지 효과가 있지만 개발팀이 조금더 합리적으로 일할 수 있게 하는 효과도 있다.

스펙을 작성하고 Wiki를 통해서 정보를 공유하는 것외에 모든 결정과정을 투명하게 공개하는 것을 통해서 좀더 효율적인 개발 문화에 한발짝 다가가보자.

소프트웨어공학은 실전이다.

이 전글에 댓글을 달려다가 좀더 정리를 해야 할 것 같아서 본글로 올린다.

2013/02/27 - [프로젝트/품질관리] - 거의 다 만들었어요.

알파, 베타의 정의를 가지고 이렇게 강하게 주장하는 경우는 처음봐서 약간 당황스러웠다. 독자들은 알아서 판단하겠지만 혼란이 있을 수도 있어서 다시 한번 내 의견을 밝힌다.

나는 20년간 한국, 미국, 대기업, 벤처기업을 다 경험하고 이론과 실전을 다 경험하고 온 국민이 쓰는 소프트웨어 개발에도 다수 참여하고 수많은 소프트웨어 프로젝트를 성공시켰고 여러 소프트웨어의 회사의 역량 개선을 시키고 있고 이런 경험을 책(소프트웨어 개발의 모든 것)으로 쓰고 블로그를 통해서 공유하고 있다. 

소프트웨어 공학은 실전이다. 이론적으로 먼저 정립된 것이 아니라 실전적인 발전을 거듭해오다가 이론적인 정리가 된 것이다. 따라서 보편적인 이론과 원리가 있고 주장이 있으며 회사마다 그 응용이 있다. 물론 모든 회사의 응용이 효율적인 것은 아니다. 대부분의 우리나라 소프트웨어 회사들의 응용이 비 효율적인 이유는 그 원리를 모르고 응용만 해왔거나 스스로 방법을 생각해 냈기 때문에 한계가 있는 경우가 많다.

세상에는 수만가지 종류의 소프트웨어가 있고 그에 알맞는 라이프사이클도 약간씩 다르다. 다른 것이 잘못된 것은 아니다. 따라서 하나의 프로세스나 이론만 들이대고 이대로 따라하면 모든 소프트웨어에 알맞다고 주장하는 것은 틀릴 가능성이 매우 높다. 

이론서를 보거나 Wikipedia를 보더라도 "generally"라는 용어를 주로 사용하는 이유가 그것이다. 

알파, 베타라는 용어도 최초에 한사람이 이를 정의하고 모든 사람들이 이것을 따르라고 한 것이 아니다. IBM에서 최초로 A, B버전을 사용하였고 수많은 회사가 이런 용어를 따라했으며 Microsoft가 이후에 많은 영향을 미쳤으며 수많은 회사들이 이와 유사한 용어를 따라서 써오다보니 어느 정도 정립이 되었을 뿐이다. 각 회사의 프로세스 정의서에 알파, 베타에 대한 정의가 서로 다르며 이것이 틀린 것은 아니다.

제가 컨설팅했던 수많은 회사에서도 알파, 베타 버전의 용어가 비슷은 하지만 미묘하게 약간씩은 다르다. 회사마다 천차만별로 다른 것이 아니고 핵심적인 것은 비슷하지만 약간씩 다른 것이다. 이것이 틀린 것은 아니다. 회사마다 소프트웨어의 성격에 따라서 강조해야 하는 것이 다르고 프로세스가 다르다. 그렇다고 회사에서 개인마다 다르게 사용해서는 안된다. 회사내에서는 동일한 절차와 정의를 사용해야 한다. 회사마다 코딩컨벤션이 다른 것도 그 하나이다.

회사를 옮기면 그 회사의 조직, 프로세스, 규칙을 익혀야 한다. 대부분의 회사가 비슷한 프로세스와 정의를 사용하기 때문에 이를 익히는데 며칠도 걸리지 않는다. 대부분은 그냥 적응한다.

회사마다 다른 극단적인 예를 들면 5년이 걸리는 화상탐사선을 개발할 때와 간단한 Web application은 알파, 베타, RC를 다루는 방법이 다르다. 화성탐사선은 스펙이 완벽하게 정해지고 수정되는 법이 없고 스펙이 바뀐다면 엄청난 크로스체크와 절차가 필요하다. 하지만 간단한 Web application은 많이 다를 것이다.

모든 것은 어떻게 하면 소프트웨어를 가장 효율적으로 개발하느냐에 집중되어 있다. 소프트웨어의 성격에 따라서 회사의 조직, 프로세스, 시스템, 문화등이 비슷은 하지만 조금씩 달라진다. 어떻게 하면 효율적으로 개발할지 고민을 하다보니 여러 라이프사이클이 나오고 방법론도 매우 많다. 그 중에서 개발하는 소프트웨어에 가장 알맞는 방법을 선택해야 한다. 여기서 한가지만 옳다고 주장하는 것도 잘못된 것이지만 비효율적인 방법을 선택하는 것도 안좋다.

우리가 주의할 것은 하나의 경험이나 학습으로 세상의 모든 진리로 착각하면 안되겠다는 것이다. 그래서 나도 글을 쓸때 항상 조심하는 편이다. 또한 다른 사람의견에 빈정대거나 공격하지 않고 건설적인 토론을 하려고 노력한다. 하지만 대중을 상대로 하는 일이라 힘들때가 많다. 교양있는 여러분의 많은 경험을 같이 나누고 싶다.

거의 다 만들었어요.

"거의 다 만들어서 2주후에 개발이 끝나요"

이 말을 이해할 수 있는가? 우리 주변에서 소프트웨어를 개발할 때 흔히 들을 수 있는 말이다.

개발자들도 이렇게 얘기하고 관리자나 경영자도 대충 알아듣는다.

하지만 이런 대화는 여러 오해를 양산한다.

영업 담당자는 2주후면 고객에게 소프트웨어를 제공할 수 있는 것으로 착각하기도 하고, 경험이 좀 있는 관리자는 아직 충분히 안정적이지 않거나 테스트가 남아 있다는 것도 알기도 한다. 하지만 정확하게 언제 고객이 쓸 수 있는 제품이 나오는지는 알 수가 없다.

그래서 우리는 좀더 전문적으로 제대로된 용어를 사용해서 커뮤니케이션을 할 필요가 있다.

우선 개발 단계별로 정확한 용어를 사용하는 것이 필요하다.

"개발"이라는 말은 너무나 모호하다. 사실 스펙을 쓰는 일부터 유지보수 까지 모두 개발이다.

그래서 분석/설계/구현/테스트 등 단계별로 세분화된 단어를 쓰는 것이 좋다.

따라서 "개발이 끝나요"보다는 "구현이 끝나요"가 좋다.

그 다음에는 개발팀에서 만들어내는 버전이 어느 정도 수준인지 표현할 필요가 있다. 내부 테스트를 진행할 수 있는 수준인지 필드테스트를 할 수 있는 수준인지 알려줘야 한다.

일반적으로 이런 수준을 표시하는 용어는 많이들 들어봤겠지만, 알파/베타/RC 등이 있다.

알파버전이란 모든 기능의 구현이 완료되었고 버그는 많지만 Show stopper가 없는 수준을 말한다. 주변에서 "개발이 다 됐어요"라고 말할 때도 자세히 살펴보면 알파 수준도 안되는 경우 많다. 기능이 99% 완료 되었으면 알파가 아닌 것이다. 예를 들어 설치 프로그램은 아직 개발을 안했다던지 간단한 기능의 일부가 미 구현상태면 알파가 아닌 것이다. 

따라서, 미국이나 인도나 어디에서도 알파버전이라고 하면 이 수준으로 이해를 하면 된다. 

그리고 알파버전 테스트에서 발견된 버그를 대폭 수정해서 버그를 많이 줄인 버전을 베타버전이라고 한다. 베타버전은 내부테스트를 하기도 하고 고객을 대상으로 외부 테스트를 하기도 한다. 베타버전은 버그는 있지만 꽤 쓸만한 버전이다.

RC버전은 Release Candidate의 약자로 테스트를 해보고 출시를 결정할 후보 버전이다. 따라서 대부분의 경우 아주 안정적이다. 출시가 결정되면 바로 고객이 사용하는 버전이다. 물론 버그가 없는 것은 아니지만 충분히 안정적이다.

따라서 알파/베타/RC등의 용어를 적절하게 사용해서 개발팀에서 만들어낸 버전이 정확하게 어느 정도 수준인지 전달을 해야 한다.

"2주후에 개발이 끝나요"보다는 "2주후에 알파버전 구현이 끝나요"가 좋다.

좀더 자세히 말하면 "2주후 금요일 오후3시 정각에 알파버전 소스코드 프리즈가 있습니다."라고 하면 좀더 정확한 의미가 전달된다.

개발자들은 3시까지 모든 소스코드를 Commit해야 하고,

빌드팀은 3시가되면 소스코드를 내려받아서 빌드를 하고

테스트팀은 3시쯤 되면 알파테스트를 시작할 준비를 하고 기다리고 있을 것이다.

관리자나 경영자는 당연히 테스트 일정을 알고 있고 언제 출시 예정인지 알고 있다.

이슈관리시스템을 보고 있으면 거의 실시간으로 발견되는 버그와 고쳐지는 버그의 현황을 볼 수 있다. 

하지만 아직도 대부분의 개발 현장에서는 이런식으로 커뮤니케이션이 이루어지지 않고 있는 것이 현실이다. 

알파/베타 등의 용어를 들어봤거나 사용하고 있어도 그 의미를 정확하게 사용하지 않고 있는 경우가 많고 개발자와 영어/관리자/경영자가 그 의미를 똑같이 공유하고 있는 않다. 서로 다르게 생각하고 있으면 커뮤니케이션에 문제가 자주 생긴다.

세계적으로 표준으로 사용하는 용어들이니 표준에 맞게 사용하고 모든 직원이 똑같이 공유를 해야 한다.

그래야 좀더 합리적인 일정으로 개발이 진행된다.