하루 8시간 일하시나요?

하루에 8시간 일하시나요?

그렇다고 프로젝트 일정을 예측할 때 하루 8시간 일을 하는 것으로 계산하십니까?

그러면 프로젝트 일정을 지키기 어려울 것입니다.

보통 아무리 집중해서 일을 한다고 해도 하루에 80% 일하기 어렵습니다.

나머지 20%의 시간은 회의를 하고, 커피도 마시고, Email도 봐야 합니다.

또 2개의 프로젝트에 4시간씩 할당이 되어 있어도, 업무 전환 비용(Context switching cost)를 무시할 수 없습니다.

물론 프로젝트 일정은 프로젝트 관리자 혼자서 마음대로 정할 수가 없습니다.

실제 업무를 담당할 담당자들의 도움을 받아서 일정을 산정하게 됩니다.

이때 담당자들이 산정한 일정을 그대로 받아들이나요? 아니면 스스로의 버퍼를 따로 두시나요?

저는 하루의 업무시간을 보통 8시간*80%로 잡고 일정을 산정합니다. 

그 이유는 다음과 같습니다.

• 개발자의 기술력은 믿지만, 일정 예측 능력은 믿을 수 없습니다.
• 프로젝트를 진행하다 보면 항상 예상치 못한 일이 발생합니다.
• 프로젝트가 막바지로 가면, 특히 통합과정에서의 혼란을 개발자들은 쉽게 생각하는 경향이 있습니다.
• 과거의 경험으로 보면 예상된 일정보다 빨리 끝난 프로젝트는 거의 없었습니다.

낙관적인 일정도 나쁘지만, 일정을 너무 비관적으로 잡으면 프로젝트팀이 자칫 게을러 질 수도 있습니다. 80%의 시간만을 일하는 것으로 일정을 잡아도 프로젝트가 진행되면 부정확인 일정 예측으로 인해서 초과근무는 자주 일어납니다. 그래도 합리적인 일정으로 산정되었기에 프로젝트 일정을 지킬 가능성이 훨씬 높습니다.

이러한 일정산정을 너무 넉넉한 일정으로 비난하는 경영자나 관리자가 있을 수 있습니다.

하지만 무리하게 촉박하거나 낙관적인 일정으로 일정을 지키지 못하거나 개발자를 너무 혹사하는 것보다는 합리적인 일정이 더 낫습니다.

프로젝트팀에서는 믿을 수 있는 일정을 제시하고 지키는 것이 계획적인 비즈니스를 할 수 있게 하는 원동력입니다.

이렇게 프로젝트팀이 제시한 일정이 신뢰를 받기 위해서는 합리적인 근거 제시와 투명한 프로젝트 진행이 꼭 필요합니다. 

(아래 그림은 프로젝트 초기에 일정 산정이 얼마나 어려운지를 보여주는 그래프입니다. 

프로젝트 초기의 일정은 -50% ~ +200%까지의 오차를 보인다는 의미입니다.

그리고 정확한 일정은 끝나봐야 안다는 거죠.)

90%에서 끝나지 않는 프로젝트

Software 개발 프로젝트에서 일정이 늦어지는 경우는 흔하다. 초기 일정을 완벽하게 맞추어서 끝내는 프로젝트는 구경하기 힘들 정도이다.

그 중 대부분의 프로젝트는 90%까지는 진도가 착착 잘 나가는데 10%를 남기고 나서 일정이 계속 지연되곤 한다. 남은 10%를 끝내기 위해서 90% 끝내는데 걸리는 시간보다 더 오래 걸리는 프로젝트를 보는 것은 그리 쉬운 일이 아니다. 설령 일정에 밀려서 출시를 해도 버그가 많은 알파버전 수준의 제품을 출시해서 고객들의 원성을 사기 일쑤이다.

경영자는 매달 개발자들이 하는 다음달이면 끝난다는 얘기를 반복해서 듣게 된다.

이러한 상황을 개발자들은 그렇게 심각하게 보지 않는 경우가 많다. 하지만 비즈니스를 하는 사람은 이것이 비즈니스를 하는데 얼마나 심각한 문제가 되는지 잘 알고 있다.

소프트웨어 공학은 프로젝트 일정을 단축하고 계획대로 개발할 수 있도록 하기 위한 방법에 온 힘을 기울여 왔다. 소프트웨어 공학에서 다루는 거의 모든 분야는 일정 준수에 포커스를 하고 있다고 해도 과언이 아니다.

남은 10%의 일정이 그렇게 잘 안끝나는 주요 원인들은 다음과 같은 것들이 있다.

• 스펙을 충분히 제대로 작성하지 않았다. 단순한 요구사항을 가지고 개발자들이 알아서 개발을 한다.
• 설계가 허술해서 인터페이스가 자주 바뀐다. 통합이 잘 안되서 통합하는데 시간이 많이 소요된다.
• 상세 일정이 없이 큰 단위의 마일스톤만 가지고 있다. 일정관리는 거의 안한다.
• 리스크 관리는 해본적도 없다.
• 제품이 개발되기 전까지 스펙이 공유가 안되서 영업이나 경영층에서 프로젝트 막바지에 제품의 모습을 보고 요구사항을 계속 추가로 요청한다. 
• 프로젝트 일정에 테스트 일정을 충분히 고려하지 않았다. 테스트 케이스를 제대로 만들지 않고 테스트 인력이 부족해서 테스트 할 때마다 계속 새로운 버그가 발견되서 끝나지를 않는다.

개발 방법론이 라이프 사이클들은 여러가지가 있고 최근에 유행을 타는 것들도 있지만 결국에는 스펙을 상세히 제대로 작성하는 것이 근본적인 프로젝트 일정을 지키는 방법이다. 스펙을 제대로 작성하지 않고 여러가지 기법으로 해결할 수는 없다. 스펙을 작성하는 방법이 어찌되었든 스펙이 정확하고 상세해야 정교한 일정 예측 및 관리가 가능해지게 된다. 이런 경험이 점점 쌓이면 일정을 지키는 프로젝트가 점점 늘어 갈 것이다. 그러기 때문에 스펙을 잘쓰는데는 10~20년의 경험이 필요한 것이다.

대충 개발자들이 알아서 개발해주고 일정은 하늘(개발자인가?)에 맡기는 방법에 익숙해진 개발자들은 이런 정교한 일정관리에 거부감을 가질 수는 있으나 결국에는 일정을 지키는 방법이 개발자의 역량을 향상시키는 방법과도 일치하기 때문에 개발자 손에 달린 프로젝트가 개발자에게 파워를 가져다 준다는 생각은 버리는 것이 좋다.

프로젝트 일정은 10%가 남았다면 진짜로 10%만 더 지나면 끝나야 한다. 

이번 프로젝트 내일 끝나?

SW개발 프로젝트가 언제 끝날지 정확하게 모르는 경우가 허다하다.

프로젝트를 진행하고 있는 개발자나 PM도 이 프로젝트가 언제 끝날지 전혀 감이 안잡히는 경우가 많다. 

하지만 분명한 것은 이 프로젝트가 예정된 종료일까지는 끝나지 않을 것이라는 것은 아주 잘 알고 있다.

이것을 알고 있다면 일정을 연기해야 하는데 언제로 연기를 해야 하는지 알 수 없으니 일정 연기를 요청하기도 어렵다. 일정을 연기 했으면 그 일정은 지켜야 하는데 연기된 일정도 전혀 근거가 없이 그냥 감으로 생각한 일정이기 때문이다. 이런 일정은 또 연기되기 마련이다.

그래서 Due date이 되어서어 끝나지 않음을 알고 일정 연기를 요청하고 한다. 이렇게 촉박하게 일정이 자주 연기가 되면 영업이나 마케팅 부서에서는 도저히 개발팀의 일정을 믿을 수 없어서 자신있게 비즈니스를 하기 어려워진다.

그럼에도 일정이 늦어지고 있는 것을 늦게 알려주는 이유는 미리 얘기를 해봤자 일찍 혼나기 밖에 더하겠냐는 생각때문이기도 하다. 일정이 촉박해지면서 매일 야근을 하면서 열심히 하는 모습을 보여주면 일정을 연기해도 큰게 혼나지 않을 것이라고 생각하곤한다. 

하지만, 경영자 입장에서는 밤새면서 일정 못지키는 프로젝트보다는 6시에 퇴근하고 약속한 일정을 지키는 프로젝트가 훨씬 낫다. 그렇다고 주먹구구로 개발하면서도 일정을 터무니없게 길게 잡으면 곤란할 것이다.

제대로된 조직, 프로세스, 시스템을 갖추고 있는 회사에서 SRS를 적절하게 썼다면 1년짜리 프로젝트에서 1주일 지연이 되는 것을 6개월전에도 알 수 있다. PM은 이런 일정 지연이 생기면 이를 복구하기 위한 다양한 기법들을 사용하게 된다. 따라서 일정에 맞춰서 프로젝트를 마칠 수 있는 가능성은 대단히 높아지게 된다.

더 이상 개발팀에게 "내일은 끝나나?"라고 물어볼 필요가 없다. 개발팀도 신뢰를 회복할 수 있을 것이다.

또한, 더 중요한 것은 6시에 퇴근을 하면서도 프로젝트를 더 일찍 끝낼 수 있다는 것이다.

심정적으로 경험적으로 이것이 믿어지지 않는 분들도 많겠지만, 필요한 만큼 적절히 체계화 된 개발을 하고 SRS와 설계를 적절하게 하면 프로젝트 일정도 지키고 개발자도 행복해진다.

여기서 중요한 것은 적절하게 하는 것이다. 적절하다는 것이 가장 어려운 것 중 하나다.

내가 책임지고 해보겠습니다.

우리나라 경영자들은 "내가 책임지고 해보겠습니다."라는 말을 좋아한다. 물론 책임감을 가지고 일을 추진하는 것은 좋은 일이다. 하지만 많은 경우 엄밀히 말하면 제대로 책임을 지는 것이 아니다. 결과적으로 책임을 지겠다고 말만하는 꼴이 되는 경우가 많다. 그럼에도 무모하더라도 추진력있게 밀고 나갈 사람이 인기가 많다.

경영자들이 이런 돌격형 인재를 좋아하는 이유는 여러가지가 있다. 실제 좋은 성과를 내는 경우도 많지만 소프트웨어에서는 상황이 좀 다르다. 

경영자들이 소프트웨어 개발에 대해서 잘 모르기 때문에 그냥 알아서 개발을 해주기를 원하는 경우가 많다. 또한 이런 경우 무모한 시도가 되는 경우가 많다. 

열심히 하는 것은 좋지만 무모한 것과는 다르다. 대부분의 무모한 프로젝트는 일정이 제대로 예측이 안되는 상태로 밀어 붙인다. 일정이 촉박하다는 이유로 분석, 설계 생략하고 코딩부터 진행하고, 개발 막바지까지 현재 진행률을 파악하기가 어렵다.

비즈니스를 하기에는 이렇게 열심히 일하지만 예측 불가능한 프로젝트보다는 합리적인 일정제시와 제시된 일정에 결과가 제대로 나오는 프로젝트가 더 좋다. 그래야 비즈니스도 계획한 대로 움직일 수 있다.

이렇게 무모한 프로젝트를 진행하는 개발자들은 불투명한 프로젝트 진행을 선호한다. 투명하게 프로젝트를 진행하는 것이 더 효율적이라는 것을 몰라서 그렇게 하기도 하지만, 정보와 지식을 숨길 수록 자신들의 가치가 더 올라간다고 착각을 하기도 한다.

이런 환경에서는 경영자는 Detail은 잘 모르고 개발자들을 쪼기만(일정 압박) 하고, 개발자들은 매일 야근에 내몰리다가 프로젝트 막바지에는 이런 저런 핑계를 만들어 내기 급급해진다. 물론 가끔은 일정내에 프로젝트가 끝나기도 하지만 그 과정에서 마케팅, 영업, QA와 유기적으로 협력이 잘 안되고 혼자 달려가는 프로젝트가 되곤한다. 개발자가 개발을 끝내주면 그때부터 다른 부서는 일이 시작된다. 무엇을 개발하고 있는지 제대로 파악이 안되므로 미리미리 준비를 하기도 어렵다.

물론 개발자는 열싱히 일을 했다. 비난을 들으면 억울할만하다. 물론 나는 개발자를 비난하는 것은 아니다. 이런 일이 벌어지는 근본적인 이유는 경영자들의 무모한 개발자를 선호하고 너무 압박을 하기 때문이다. 이런 일이 반복되면 개발자는 지치고 프로젝트는 지연된다. 잘못된 방향으로 달려가던 프로젝트는 커다란 매몰비용(Sunken cost)를 치뤄야 하기도 한다. 이런 상황에서는 경영자도 개발자도 선택의 여지가 별로 없다. 아무리 손해를 보더라도 경영자는 이런 무모한 프로젝트에 계속 후원을 할 수 밖에 없다. 

이 모든 부작용은 개발 문화의 부재에서 오는 것이다. 제대로 된 스펙에 의해서 합리적인 일정을 제시하고 경영자는 이를 믿어줘야 한다. 처음에는 개발자들이 역량이 부족하여 나름대로 개발자들이 제시한 일정이 좀 틀릴 수도 있지만 개발자들은 최대한 합리적인 가능한 일정을 제시해야 한다. 그런 관계가 거듭되야 개발자도 역량이 향상되고 비즈니스 일정에 맞춰서 제품을 만들어 줄 수 있다.

혹자는 현실적으로 불가능한 일이라고 한다. 항상 일정이 너무 촉박하여 경영자는 절대로 개발자들이 제시한 일정을 따를 수 없다고 한다. 그래서 무모하게 짧은 일정을 제시한다고 한다. 경영자가 그렇게 하는 이유는 무지 때문이기도 하고 개발자들이 합리적으로 일정으 제시하지 못하기 때문이기도 하다. 가끔은 경영자와 개발자의 신뢰가 무너진 경우도 있다. 그렇게 해서는 평생을 가도 무모한 프로젝트만 진행하게 된다.

그 부작용은 개발자 사기저하, 비즈니스 일정이 꼬이고, 제품의 품질이 떨어진다.개발자들은 매일 야근에 고생을 하지만 일정 지연에 자주 내몰린다.

여기서 핵심은 경영자들의 이해이다. 그리고 개발자들도 제대로 된 분석, 설계 능력을 갖춰서 합리적인 개발 계획을 제시할 수 있어야 한다. 한번에 그렇게 될 수는 없지만, 경영자와의 신뢰 하에서 개발자에게 꾸준히 투자를 해줘야 개발자들도 그렇게 할 수 있는 역량이 올라가게 된다. 

오늘도 밤을 세워야 하는 개발자 (야근 탈출)

옛날부터 내려오는 경영자들이 믿고 있는 미신이 있습니다.

"개발자의 Output은 근무시간의 양에 비례한다."

말은 아니라고 하면서도 밤에 사무실이 텅 비어 있으면 개발자들이 군기가 빠졌다고 생각하고 주말에 누가 나와서 일하나 확인하러 가끔 사무실에 들르는 사람들이 경영자입니다.

실제로 근무시간에 성과가 비례하는 개발자들이 있다면 공장에서 벽돌 찍어내는 것과 다를 바가 없겠지요.

이 미신은 믿기 싫지만 자꾸 저절로 손이 가는 새우깡처럼 믿게 되고, 회사 조직에서 위로 올라갈수록 더 맹신하게 되나 봅니다.

이러한 이유로 어쩔 수 없이 또는 습관적으로 야근을 하는 개발자가 있다면 십중팔구 미혼이거나 결혼을 했어도 아이가 없겠죠.

이런 정상적이지 않은 생활을 하며 10, 20, 30년간 소프트웨어 엔지니어 일을 할 수는 없겠죠.

나는 "개발은 창의적인 작업으로 그 성과는 충분한 재충전에 나온다"고 믿고 있습니다.

그렇게 합리적인 시간에 개발을 하려면 소프트웨어 개발은 좀더 체계적이고 효과적으로 진행해야 합니다.

지금의 일반적인 경우처럼 일단 프로젝트를 시작해서 개발자들이 능력껏 그럭저럭 진행하는 방법으로는 또 개발자의 야근은 피할 수 없고, 별로 빠르게 끝나지도 제품의 품질이 좋지도 않게 됩니다.

그래서 소프트웨어 개발에 소프트웨어 공학을 적용하는 것이지요.

말은 거창한 것 같지만, 소프트웨어 공학이라는 것이 소프트웨어를 최소비용으로 최단기간에 개발하기 위한 온갖 방법들을 말하는 겁니다. 결코 교과서의 내용이 아니고 현실에서 수많은 회사들이 경험을 통해서 내려오는 방법이고 여러분들도 상당부분은 익히 알고 있는 방법들입니다. 이 블로그의 주제이기도 하고요.

다시 개발자들이 밤을 세지 않기 위한 방법으로 되돌아 와서 그 방법을 알아봅시다.

일단, 경영자의 인식이 바뀌어야 하는 것은 당연한 일인데, 어떻게 손을 델 수가 없는 일입니다.

그리고 나면 아래와 같이 개발자들과 프로젝트팀이 행할 수 있는 3가지 방법이 남습니다.

• 정확한 일정 예측
• 체계적인 개발 방법 
• 합리적인 일정 복구 

첫째, 정확한 일정 예측입니다. 이는 모순된 문장입니다. 어떻게 예측을 정확하게 하나요? 하지만 예측이란 그때 상황에서 최선을 다해 정확하게 예측을 해야지요. 

당연히 프로젝트가 시작하자마자 정확한 예측은 불가능합니다. 아직 스펙이 정해지지 않았거든요.

그래서 프로젝트가 시작할 때는 대충을 일정을 가지고 시작을 하다가 스펙 작성이 완료되면 스펙을 근거로 1,2일 단위의 정확한 WBS를 작성하여 소요일정과 투입인력을 따져서 프로젝트 일정을 작성해야 합니다.

회사의 모든 관련자들은 프로젝트가 시작할 때 정해진 일정을 진짜 일정으로 봐서는 안됩니다. 스펙 완료 후 작성된 일정을 진짜 일정으로 봐야지요. 이것을 당연히 이해 할 수 있어야 얘기가 되지요.

그리고도 일정은 개발중간에 지속적으로 점검하며 일정이 틀어지면 대응을 해야 합니다. 1,2일 단위로 작성된 일정은 조금만 늦어져도 금방 문제를 파악할 수 있습니다.

둘째, 체계적인 개발 방법입니다. 

이 부분은 책 한 권을 써도 될 만큼 많은 양이고 앞으로 블로그에서 지속적으로 다룰 내용이니 간단히 소개만 하겠습니다. Stage를 따라서 개발을 하거나, Daily Build를 하고, 소스코드관리/버그관리시스템을 사용하고, 피어리뷰/코드리뷰를 하고, 모든 이슈를 투명하게 Open하고, Build를 자동화하는 등 수많은 방법들을 당연히 사용해야 할 것 입니다.

셋째, 합리적인 일정 복구입니다.

프로젝트는 어쨌든 늦어지게 마련입니다.  

다음 그림을 보면 현재 프로젝트 진척이 계획보다 늦어지고 있습니다. 이럴 때 다음 4가지의 방법이 있습니다.

A. 더 낮은 우선순위의 요구사항은 다음 버전으로 연기한다. 

B. 개발자를 추가로 투입한다. 

C. 시간외 근무를 단기간 동안 강제로 시킨다. 

D. 일정을 연기하여 추가된 기능을 수용한다. 

여기서 대부분의 회사가 C를 주로 선택하고 가끔 B를 선택합니다.

C는 단기적으로는 효과가 있지만, 이 기간이 길어지면 별로 효과도 없을 뿐더러 개발자 사기만 떨어지고 회사의 경쟁력도 잃고 개발자도 잃게 되는 방법입니다. 

B는 효과가 거의 없는 것으로 익히 잘 알려져 있습니다. 프로젝트 후반에 개발자를 투입하는 것은 기존에 열심히 개발하고 있는 다른 개발자들에게 방해만 되는 경우가 허다합니다. 기존 개발자들은 이들을 가르치느라고 시간을 허비해야 하고, 새로 투입된 개발자는 별로 성능을 발휘하지 못하며 버그도 많이 만들어내는 경우가 허다합니다.

프로젝트가 늦어지고 있는지 전혀 신경을 쓰지 않다가 프로젝트 막바지에 가서야 한참 늦어지고 있다는 보고를 받고 부랴부랴 대책을 세울 때 선택하는 방법이죠.

가장 좋은 방법은 A입니다.

여기서 중요한 점은 모든 프로젝트를 시작할 때 프로젝트가 늦어질 수 있다는 것을 미리 생각해야 한다는 것입니다.

그래서 스펙의 각 기능은 Priority(우선순위)를 정해줘야 합니다. 그래서 일정이 늦어지면 우순선위가 낮은 기능을 연기하고 프로젝트를 종료하는 것입니다. 그러기 위해서는 개발 순서도 우선순위가 높은 기능부터 개발이 진행되어야 합니다.

이러한 모든 것들이 체계적으로 합리적으로 진행이 되어야 중요한 프로젝트를 하더라도 퇴근 후에 가족과 식사를 하고 아이들과 놀 수 있는 시간이 생깁니다.

위와 같이 합리적이고 체계적인 절차에 의한 데이터를 근거로 경영층에 보고가 되고 투명한 개발진행이 경영층에 신뢰를 준다면 하루 8시간 근무하는 날이 점점 늘어 날 수 있을 것입니다.

개발자 혼자서 할 수 있는 일은 결코 아니고, 회사가 조직, 프로세스, 시스템등 모든 것이 바뀌어 나가야 가능한 일입니다.

이미지출처 : Microsoft Office Online

경영진이 너무 촉박한 일정을 제시합니다.

나는 프로젝트 일정에 대해서 항상 "일정은 개발자가 산정해야 한다"고 얘기를 해왔다.

그런데 많은 개발자들과 얘기를 해보면 자신들은 도저히 그렇게 할 수 있는 상황이 아니라고 한다. 일정은 위에서 확정이 되어서 내려오기 때문에 개발자가 정할 수 없다고 한다. 또한 항상 촉박한 일정을 지시하기 때문에 스펙이나 설계는 작성할 수도 없고 코딩부터 한다고 한다. 자신들도 체계적으로 개발을 하고 싶지만 도저히 그럴 시간이 없다고 한다.

경영진이 일정을 제시하는 것과 개발자가 일정을 산정하는 것은 완전히 상반된 얘기가 아니다.

경영진은 어떤 프로젝트를 진행하기 위해서는 일정이 필요하다. 경영진이 일정을 정했다고 해서 불가능한 일정이 가능해지는 것은 아니다. 프로젝트는 들어가야 할 시간은 다 들어간다. 자칫 서두르다가 더 느려질 수 있다.

경영진이 지시한 일정은 경영자의 입장에서 필요한 일정을 제시한 것이다. 이 일정은 변경해도 되는 경우도 있고 절대 변경하면 안되는 경우도 있다.

어떠한 경우라도 이 일정을 지키는 가장 좋은 방법은 개발자가 일정을 산정하는 것이다.

일정을 산정하기 위해서는 스펙을 제대로 쓰고 1,2일 단위로 상세 일정을 개발자가 산정해야 한다. 이쯤되면 전체 일정에서 20~30%의 시간이 지난 시점이 된다.

이때 상당히 정확한 일정이 나오면 경영진이 지시한 일정을 지키기 위한 방법을 강구할 수 있다. 이 일정이 경영진이 제시한 일정과 차이가 없다면 다행이지만 촉박한 일정이라면 스펙을 조정하거나, 개발자를 더 투입할 수 도 있다. 아직 설계, 구현이 본격적으로 시작되지 않았기 때문에 스펙 조정이 가능하고 개발자를 추가 투입해도 상당히 효과가 있다. 

스펙도 조정이 안되고 개발자 추가투입도 어렵고 무조건 밤을 새가면서 일하는 수밖에 없다면 그것도 하루이틀이지 어차피 불가능한 일을 하고 있는 것입니다. 불가능하다는 것을 일찍 알아내는 것도 중요합니다. 불가능한 일을 밀어 붙인다고 가능한 일로 바뀌지는 않습니다. 기적은 일어나지 않습니다.

스펙이 끝날 때까지 손놓고 있는 것이 아니고 스펙을 쓰는 도중에도 일정이 촉박할 것으로 예상이 되면 리스크관리를 통해서 미리 대비를 할 수 있다. 

경영진이 촉박한 일정을 지시했다고 해서 이것을 돌판에 새긴 절대불변의 지시사항으로 생각하고 코딩부터 시작하면 나중에 할 말은 다음과 같은 것들 밖에 없다.

• 매일 밤새면서 일했는데 못 지켰습니다. 원래 불가능한 일정이었어요.
• 코딩은 끝났는데, 테스트는 못했습니다.

이런 핑계를 대도 사실 코딩도 안 끝난 경우도 많다. 코딩은 가능하면 늦게 시작해야 기능을 빼거나 변경하기 쉽고 더 일찍 끝낼 수 있다.

경영진은 개발자들이 합리적인 방법을 제시하고 일정을 지켜주기를 원한다. 그래야 비즈니스를 할 수 있기 때문이다.

시간이 부족해서 스펙을 적을 수 없는 것이 아니고 시간을 절약하기 위해서 스펙을 적어야 일정을 지킬 수 있는 방법이 나온다.

경영진이 6개월의 시간을 제시했다면 앞만보고 마구 달리는 것보다는 가장 빠른 시간에 6개월안에 프로젝트를 끝내는 방법을 마련해야 한다. 경영진은 이런 합리적인 방법을 제시하는 개발팀을 후원할 것이다. 가장 빠른 기간에 프로젝트를 일정에 맞게 끝낼 수 있게 방법을 마련하는 방법이 바로 적절한 스펙을 작성하는 것이다.

[Software Spec Series 2] 소프트웨어 프로젝트 실패의 원인

우리 주변에서 실패한 소프트웨어 프로젝트를 보는 것은 어려운 일이 아니다. 프로젝트를 성공하는 방법을 배우기 위해서는 프로젝트를 제대로 진행하는 방법을 연구하는 것도 필요하지만 프로젝트가 왜 실패하는지 살펴보는 것도 도움이 될 것이다. 프로젝트 실패에 대한 기준은 제각각이다. 그래서 어떤 경우에 프로젝트가 실패했다고 할 수 있는지 알아보자.

• 약속된 일정 내에 제품 또는 서비스를 출시하지 못했다.
• 소프트웨어가 요구되는 품질을 충족하지 못했다. (기능 요구사항, 성능, 안정성, 사용성, 확장성 등)
• 프로젝트에 꼭 필요한 기술 개발에 실패했다. 
• 아키텍처가 엉망진창이 되어서 유지보수가 어렵게 됐다.
• 프로젝트에 계획된 예산보다 많은 비용을 지출했다.
• 프로젝트 내내 야근을 거듭하여 조직의 사기가 떨어지고 퇴사자가 많이 발생했다.

직접적인 실패와 억지로 일정을 맞추려다 보니 다른 문제를 야기하는 간접적인 실패까지 예로 들어봤다. 이런 저런 이유로 실패하는 프로젝트는 매우 많다. 또한 실패하는 이유도 매우 다양한다. 필자는 이 중에서 가장 중요하다고 생각하는 하나에 대해서 얘기를 하려고 한다. 우선은 프로젝트를 왜 실패하는지 다양한 원인을 알아보자.

• 고객의 요구사항을 충분히 파악하지 못했다.
• 제품의 방향을 빨리 정하지 못하고 우왕좌왕하면서 프로젝트 앞부분에서 상당히 많은 시간을 소모하여 정작 개발 기간이 부족하게 되었다.
• 스펙과 설계를 제대로 작성하지 않고 코딩을 시작해서 엉뚱한 방향으로 개발을 하였다.
• 작성된 스펙을 프로젝트 이해관계자들이 충분히 리뷰 하지 않아 잘못된 스펙으로 개발하였다.
• 프로젝트를 진행할수록 새로운 요구사항이 계속 발견되어서 프로젝트가 한없이 늘어졌다.
• 변경된 요구사항을 제대로 관리하지 않아서 프로젝트 팀원들이 서로 다른 기준으로 개발을 하였다.
• 상명하복식으로 지정된 출시 일정을 맞추기 위해서 급하게 코딩부터 시작했다. 나중에 잘못된 코드를 고치느라고 시간이 더 소요되었다.
• 충분히 훈련되지 않은 개발자들을 투입하여 초반에 우왕좌왕하느라고 시간을 많이 지체했다.
• 일정관리를 대충해서 프로젝트가 지연되고 있다는 징후를 눈치채지 못했다.
• 리스크 관리를 하지 않아서 리스크로 인해서 프로젝트를 실패했다.
• 프로젝트 막판에 경영진이나 주요 고객이 프로젝트 방향을 완전히 틀어서 거의 처음부터 다시 개발해야 했다.
• 프로젝트 팀원들의 팀워크에 문제가 있어서 지속적으로 불화가 발생하여 프로젝트가 산으로 갔다.
• 도입한 외부 필수 기술이 기대처럼 동작하지 않았다. 이것을 프로젝트 막바지에 알게 되었다.
• 테스트 팀에 제대로 된 스펙을 전달하지 못해서 테스트 준비를 제대로 하지 못했다.
• 회사의 표준 프로세스를 강요하여 문서를 너무 많이 만들다 보니 정작 개발에는 소홀해졌다.

이외에도 실패 원인은 끝도 없이 많을 것이다. 이를 분류해보면 스펙, 프로젝트팀, 프로젝트 관리, 고객, 기술 등 다양하다. 필자는 이중에서 가장 중요하게 생각하는 요인은 “스펙”이다. 가장 많은 원인이 스펙과 관련이 있다. 또한 소프트웨어 버그의 절반 이상은 스펙으로부터 발생한다고 알려져 있다.

프로젝트가 아주 작다면 스펙을 제대로 적지 않고 요구사항 몇 줄로 개발해 나가도 소프트웨어를 무사히 완성하기도 한다. 소수의 경험 많은 개발자가 개발을 주도하는 경우 요구사항을 대충 알려줘도 찰떡 같이 알아듣고 개발을 잘하기도 한다. 하지만, 수백명이 투입되는 대규모 프로젝트에서는 매우 잘 정리된 스펙 문서가 필요한 경우가 일반적이다. 외국에 외주를 줄 경우 자세히 적힌 스펙 문서와 인수 테스트 계획이 필요하다.

소규모 프로젝트에서의 성공 경험을 대규모 프로젝트에 적용해서 실패를 하기도 하고, 반대로 대규모 프로젝트의 방법론이 중소규모 프로젝트에서 실패의 원인이 되기도 한다.

요구사항이 누락되거나 충분히 분석이 안된 스펙도 문제지만 너무 자세히 적거나 많은 문서를 적는 것도 문제가 된다. 대규모 방법론을 따르는 회사에서는 이런 함정에 종종 빠진다. 개발은 문서대로 진행되지 않을 뿐만 아니라 문서가 너무 많아서 수시로 바뀌는 요구사항을 문서에 제대로 반영하지 못한다.

따라서 엄격한 프로세스로 규제를 하는 것도 어렵다. 자율에 맡겨도 쉽지 않다. 필자가 생각하는 가장 좋은 방법은 원칙만 지킬 수 있는 최소한의 프로세스가 있는 환경에서 좋은 문화를 가지는 것이다. 빨리빨리 문화를 지양하고 적절히 분석하고 설계를 한 후 프로젝트를 진행하는 것이 더 빠르다는 인식을 공유해야 한다. 실제로 가장 빠른 방법이다. 모든 이해관계자들이 스펙을 철저히 리뷰하고 쉽게 요구사항을 바꾸지 않아야 한다. 이런 문화와 관행을 만들어가는 것이 프로세스보다 더 중요하다. 그래야 회사에 역량이 축적된다. 그렇게 좋은 문화와 축적된 역량이 충분해야 어떠한 프로젝트라도 성공으로 이끌 수 있다.

좋은 환경이 있어도 스펙을 제대로 적을 수 있는 역량이 부족하다면 소프트웨어 프로젝트 성공은 어렵다. 스펙을 제대로 적는 역량은 소프트웨어를 개발하는데 있어서 가장 어려운 역량이며 소질이 있는 개발자도 제대로 하려면 10년 이상의 경험과 노력이 필요하다. 꾸준히 투자하는 방법 외에 기가 막힌 방법은 없다.

share with abctech.software

소프트웨어 회사에서 경영자가 하면 안되는 것들

필자는 23년 경력의 개발자이며 이우소프트의 CEO다. 과거 8년 동안 소프트웨어 공학 컨설턴트로서 소프트웨어 개발에 관한 글을 써왔다. 우리나라의 열악한 소프트웨어 개발 환경의 핵심이 개발문화 때문이라고 생각해서 글로벌 개발 문화를 소개해 왔고 이제는 실제 한국의 소프트웨어 회사에 적용된 사례 소개하고 있다.

오늘은 소프트웨어 회사에서 경영자가 하면 안 되는 것들을 소개하려고 한다. 물론, 회사마다 기업문화가 달라서 사람에 따라서는 괴리감을 있을 수 있다. 문화란 원래 경험하지 않은 사람은 괴상하다고 생각할 수도 있고 현실성이 없다고 느낄 수도 있다. 하지만 우리 회사에서는 당연하게 생각되는 것들이고 이런 문화가 글로벌 소프트웨어 기업들과 경쟁하기 위해서 필요하고 생각하기 때문에 소개를 한다. 

첫째, 개발자들의 개발 기간 예측(Estimation)을 무시하기

많은 회사에서 벌어지고 있는 일이고 일방적으로 경영자의 잘못으로 치부하기도 힘들다.

사례는 워낙 많지만 개발자들이 1년 이하로는 도저히 개발할 수 없다고 주장하는 프로젝트를 경영자가 6개월안에 무조건 끝내라고 하는 경우는 매우 흔하다. 이유도 여러 가지다. 개발자의 주장을 믿지 않기도 하고, 프로젝트가 늦어질 것을 감안하여 필요 일정보다 무조건 당겨서 끝내라고 하기도 한다. 또한, 이렇게 개발자를 강하게 압박하지 않으면 개발자들이 야근도 안하고 열심히 일을 안 한다고 생각하는 경영자도 많다. 

당장은 이렇게 해서 몇몇 프로젝트가 성공할 수도 있고 개발 일정도 당겨지고 이익을 보기한다. 하지만, 이런 행위가 관행처럼 굳어지면 결국에는 개발자, 경영자 모두가 손해를 본다. 또한 회사의 개발 문화도 한참 후퇴한다. 경영자가 일정을 무조건 줄이면 개발자는 다음부터 어쩔 수 없이 예상보다 조금씩 늘려서 얘기를 하곤 한다.

개발자도 경영자가 납득할만한 근거를 가지고 적절한 개발 기간을 제시하지 못하는 문제도 벌어진다. 그래서 경영자는 개발자가 제시한 일정을 납득하지 못하고 무조건 일정을 줄이고 본다. 이 싸움은 누구도 승자가 될 수 없는 싸움이다. 개발자는 아키텍처가 망가지는 고통 속에서 야근을 거듭하고 경영자는 프로젝트의 예측 가능성이 낮아져서 비즈니스를 수시로 그르치게 된다.

먼저, 개발자는 잘 분석된 스펙을 바탕으로 납득할 수 있는 일정을 제시해야 한다. 그리고 경영자는 개발자가 예측한 일정을 믿어주는 신뢰관계가 필요하다. 그래야 개발자는 항상 최선을 다해서 정확한 일정을 산정하려고 노력한다. 개발자가 제시한 일정을 단축해야 하는 경우에는 합리적인 수단을 사용해야 한다. 야근도 하나의 방법이기는 하지만 습관적인 야근은 이익보다 손실이 큰 방법이다. 합리적인 수단이란 기능 축소, 핵심 기능에 집중, 단계별 개발, 전문 컨설턴트 투입, 일부 상용 모듈 구매 등 여러 가지가 있다. 

이런 개발자와 경영자 간의 신뢰 관계는 개발 방법론과 상관없이 필요하며 정착하는데 상당한 기간이 필요하다. 그리고 이렇게 개발하는 방법이 소프트웨어를 가장 빨리 개발하는 방법이라는 것을 깨달아야 한다.

둘째, 합의된 요구사항을 경영자의 취향대로 바꾸기

우리나라 회사들은 경영자가 무엇이든지 뒤집을 수 있는 막강한 권력을 가진 경우가 많다. 출시 임박한 제품의 모양을 경영자가 갑자기 바꾸거나, 취향대로 색깔을 바꾸기도 한다. 소프트웨어 분야에서도 흔히 벌어진다.

프로젝트에서 경영자의 역할은 프로젝트마다 다르다. 하지만 경영자가 프로젝트에서 절대 권력자는 아니다. 한 명의 Stakeholder일 뿐이다. 대부분의 프로젝트에서 경영자의 역할은 비전과 전략을 담당한다. 빌게이츠는 초창기 프로젝트의 기술적인 내용까지 깊숙이 간섭을 했는데 이는 경영자로서가 아니고 Chief Architect로서의 역할을 한 것이다.

프로젝트에서 경영자는 경영자 관점에서 비전과 전략 요구사항을 전달해야 한다. 그것도 초기에 제시해야 한다. 전략이 바뀌면 프로젝트는 엄청나게 바뀌는 것이므로 가능하면 초기의 전략이 유지되는 것이 좋다. 전략이 바뀌더라도 합리적인 변경을 해야 한다.

경영자가 프로젝트 막바지에 뒤늦게 관여를 해서 감 놔라 대추 놔라 하는 것은 금기사항이다. 이런 일이 벌어지면 아키텍처는 완전히 엉망이 되고 개발자들의 사기는 땅에 떨어지면 신뢰관계는 금이 간다. 우리 회사에서는 스펙이 Close 된 후에는 경영자가 요구사항을 바꾸려고 해도 Change Control Process를 통과해야 한다. Change Control Board에서 변경이 거부되면 아무리 경영자가 요구한 내용이라고 변경이 불가능하다. 

이래야 경영자도 프로젝트에서 자신의 역할을 제대로 수행하기 위해서 최선을 다한다. 뒤늦게 아무 때나 간섭할 수 있다는 생각은 하지 않게 된다.

셋째, 개발자에게 아무 때나 가서 말을 시키거나 지시하기

우리 회사에서는 경영자뿐만 아니라 누구도 개발자에게 아무 때나 말을 걸고 개발을 방해하지 않는다. 개발자가 개발에 집중을 하고 있는 경우에 중간에 방해를 하면 엄청난 손해가 발생한다. 피플웨어에서는 30분 정도의 손실이 발생한다고 한다. 이런 방해가 하루에 3,4번 벌어지면 하루를 망친다.

개발자와 면담을 할 것이 있으면 몇 시간 전이나 하루 전에 미리 시간을 Arrange해야 한다. 급하게 할 얘기가 있으면 개발자가 집중을 하고 있는지 조심스럽게 살핀다.

그래서 우리 회사에는 메신저도 금지되어 있고 근무 중에는 카카오톡도 무음 설정을 해야 한다. 개발자가 집중해서 일을 하고 있는데 메신저가 부르거나 "까똑" 거리면 집중해서 일할 수가 없다. 개발자에게 전화를 거는 일도 거의 없다. 대신에 근무 시간에 최대한 집중을 하고 야근은 되도록 하지 않는다. 

넷째, 수시로 보고서를 요구하기

공유 문화가 잘 정착되어 있는 회사에서는 진행되는 거의 모든 일이 온라인 시스템에 잘 기록되어 있다. 그래서 별도의 보고서가 없어도 경영자는 거의 모든 내용을 실시간으로 모니터링이 가능하다. 그래서 특수한 경우가 아니면 시스템에 있는 정보를 다시 정리해서 보고하라고 하지 않아야 한다. 보고서는 경영자의 시간을 약간 절약해 주지만 직원들은 수십, 수백 배의 시간을 소모해야 한다. 일보다 보고서 작성에 더 많은 시간을 쏟기도 한다. 또한 보고서만으로 업무를 파악하면 가공과정을 거치면서 내용이 왜곡되곤 한다. 시간이 허용하는 한 최대한 많은 정보를 직접 보는 것이 좋다. 보고서는 꼭 필요한 경우에만 작성해야 한다. 이것이 가능 하려면 공유 문화가 완전히 정착되어 있어야 한다. 

지금까지 네 가지 경영자가 하면 안 되는 일을 소개했다. 그럼 경영자는 별로 할 일이 없는가? 경영자는 회사의 비전, 전략을 정하고 목표를 설정해야 한다. 인재를 채용하고 직원을 코칭, 육성해야 하며 회사의 규칙을 만들고 문화를 만들어가야 한다. 이외에도 경영자가 해야 할 일은 수없이 많다. 

필자는 CEO일 뿐만 아니라 아키텍트의 역할도 일부 수행하며 또한 소프트웨어 국제화 전문가이다. 그래서 소프트웨어 공학, 아키텍처, 국제화 관련 이슈에도 전문가로서 직접 관여를 한다. 하지만 그 외의 것은 위에서 얘기한 것처럼 Stakeholder로서 의논에 참여를 하고 의견을 제시하지만 결정에 과도한 압력을 가하거나 합의된 결정을 뒤집지는 않는다. 합의를 바꾸려면 정해진 절차를 따른다. 

글로벌 수준의 개발 문화 속에서 경영자와 개발자가 각자의 전문 역할을 충실히 수행할 때 글로벌 소프트웨어 회사들과 비로소 경쟁을 시작할 수 있을 것이다.

개발 문화는 후진적인데 개발자 하나하나가 선진적이고 뛰어나다고 해서 소프트웨어가 경쟁력을 갖출 수 없다. 개발 문화라는 것이 반바지를 입는다고 공짜 점심을 준다고 좋은 공학툴이나 방법론을 도입한다고 해서 제대로 정착되는 것은 아니다. 모든 구성원의 마음과 습관을 바꾸는 것이 핵심인데 매우 어려운 과정이며 경영자부터 바뀌지 않으면 안 된다. 

이 글은 ZDNet Korea에 기고한 글입니다.

SW업계의 잘못된 통념 5가지

소프트웨어 업계에는 정말 깨기 어려운 잘못된 통념이 몇가지 있다.

많은 이들이 이러한 잘못된 고정관념과 오해에 사로 잡혀서 쉽게 변화하지 못하고 계속 잘못된 길을 걸어가고 있다.

어떠한 잘못된 통념이 있는지 알아보자.

잘못된 통념 1 : 문서(스펙)를 작성하느라고 일정을 못 맞추는 것이 아닌가? (경영자)

많은 경영자들은 문서 작성 때문에 프로젝트가 더 오래 걸리는 것으로 생각하고 있다. 그래서 개발자들이 문서를 쓰고 개발하겠다고 하면 오히려 문서를 쓰지 말고 빨리 개발해 달라고 은근히 요구하는 경영자가 의외로 많다. 

이러한 경우 경험에 의해서 문서란 개발과는 상관없이 추가적으로 시간을 잡아먹는 작업이라는 것을 학습했기 때문이다.

스펙을 써보지도 않고 일정이 모자르다는 것을 아는 것이 모순이다. 스펙이 부정확한 상황에서는 일정을 산정하는 것이 의미가 없기 때문이다. 하지만 대충 짐작으로도 턱없이 기간이 모자른 프로젝트도 있다.

진짜 스펙을 쓸 시간조차 없는 프로젝트라면 애초에 시작을 하지 않는 것이 좋다.

개발문서는 일정을 단축하기 위해서 작성하는 것이고, 그렇지 않은 목적을 가지고 있는 문서는 작성하지 않는 것이 좋다. 예외적으로 생명을 다루거나 우주선을 띄울 목적이라면 개발시간 단축외에 더 많은 것을 요구하기 때문에 시간이 더 오래 걸리는 문서도 작성하곤 한다.

하지만 대부분의 프로젝트에서는 개발 일정을 단축하는 문서만 작성해야 한다.

잘못된 통념 2 : 일정이 부족하니 당장 코딩부터 시작하자. (개발자)

진짜 개발자들 사이에서 만연해 있는 생각이다. 

개발자들은 위에서 촉박한 일정을 정해주기 때문에 무조건 일정을 맞춰야 하고 그러기 빨리 코딩을 시작해야 한다고 한다.

제대로된 스펙과 설계없이 코딩부터 시작한 프로젝트는 백이면 백 중간에 엄청난 재작업이 기다리고 있다. 통합에 막대한 시간이 소요되고 많은 버그를 생산하면 이를 고치는데 더 많은 시간이 소요된다.

코딩은 늦게 시작할수록 프로젝트가 빨리 끝나는 것이 맞다. 스펙과 설계가 충분할 수록 코딩 기간은 단축되고 일정이 부족하면 더 많은 개발자를 투입할 수도 있고 일부 기능을 미루는 것도 가능해진다.

잘못된 통념 3 : 지금은 잘 모르니 일단 개발해주면 보고나서 요구사항을 알려주겠다. (고객)

고객은 일단 개발해서 보여주면 아이디어가 마구 떠오르고 말만 하면 개발자가 바로바로 쉽게 고칠 수 있는 것으로 착각한다.

아키텍처에 영향을 주지 않는 사소한 것은 그럭저럭 바꿀 수 있어도 대부분의 기능은 고치거나 새로 추가하려면 처음부터 계획한 경우보다 몇배에서 몇십배의 비용과 시간이 들어간다.

하지만 고객이 스스로 원하는 것이 뭔지 잘 모르는 경우 개발자들은 상당한 어려움에 처하게 된다. 개발자들도 워낙 일상적으로 벌어지는 일이기에 불충분한 고객의 요구에도 자신이 아는 한도에서 대충 개발해주고 고치기를 반복하는 일을 정상적으로 받아들이곤 한다.

이렇게 개발이 이루어지만 아키텍처가 엉망이 되기가 일쑤이고, 개발자들은 재미 있는 개발을 하는 것이 아니라 회의만 들게 된다.

잘못된 통념 4 : 일정이 정해져 있어서 어쩔 수 없다. (개발자)

개발자들은 경영자들이 무리한 일정을 일방적으로 강요한다고 한다. 물론 그런 경우도 있지만 많은 경우 위에서 일방적으로 일정을 지시하지 않는다. 

표면적으로 드러난 결과가 일정 지시지만 그 과정을 살펴보면 합리적인 일정 산정과 조정이 이루어 지지 않는 경향이 있다.

개발자들이 제대로 스펙을 적어서 합리적인 일정을 제시하지 못하니 경영자도 일방적으로 도전적인 일정을 밀어 붙이고, 거꾸로 경영자가 그러하니 개발자들은 어쩔 수 없이 따르게 된다.

이는 어느 한쪽의 책임은 아니라고 볼 수 있다.

합리적으로 일정 산정을 하고 정확한 데이터를 제시할 때 경영자에게 일정에 대해서 어필할 수 있게 된다.

잘못된 통념 5 : 우리 회사는 달라서 일반적인 원칙이 적용되지 않는다. (경영자)

고객이 요구사항을 너무 자주 바꾼다. 

고객이 요청하면 당장 들어 줘야 한다. 

개발일정은 상상할 수 없을만큼 짧다.

고객이 요청하면 무조건 달려가야 한다. 

그래서 일방적인 소프트웨어 공학이 적용되지 않는다고 한다. 이것도 명백한 오해이다. 고객은 원래 그렇기 때문에 이러한 환경에서 빠른 시간에 적은 비용으로 개발하기 위해서 소프트웨어 공학이 존재하는 것이다.

우리만 그렇다고 생각하는 것도 오해이다. 많은 회사들이 정도는 다르지만 이러한 상황에 놓여 있고 많은 부분은 영업 전략으로 선택을 한 것 뿐이다.

이러한 잘못된 통념은 회사가 한단계 앞으로 나아가기 위한 변화를 방해하고 점점 열악하게 만드는데 일조한다.

소프트웨어 프로젝트는 왜 실패하는가?

우리는 주변에서 실패한 소프트웨어 프로젝트를 보는 것이 그리 어려운 일은 아니다. 프로젝트의 규모가 커지고 기간이 길어지며 많은 인원이 투입될수록 프로젝트 실패 확률은 증가한다. 

프로젝트 성공을 위해서는 프로젝트를 제대로 진행하는 방법을 연구하는 것도 필요하지만 프로젝트가 왜 실패했는지 살펴보는 것도 도움이 될 것이다. 프로젝트 실패에 대한 기준은 제각각이다. 그래서 어떤 경우에 프로젝트가 실패했다고 할 수 있는지 알아보자.

• 약속된 일정 내에 제품 또는 서비스를 출시 못했다.
• 소프트웨어가 시장에서 요구되는 품질을 충족하지 못했다. (요구사항, 성능, 안정성, 사용성 등)
• 프로젝트에 꼭 필요한 기술 개발에 실패했다. 
• 아키텍처가 엉망진창이 되어서 유지보수가 어렵게 됐다.
• 프로젝트에 계획된 예산보다 많은 비용을 지출했다.
• 프로젝트 내내 야근을 거듭하여 조직의 사기가 떨어지고 퇴사자가 많이 발생했다.

직접적인 실패와 억지로 일정을 맞추려다 보니 다른 문제를 야기하는 간접적인 실패까지 예로 들어봤다. 이런 저런 이유로 실패하는 프로젝트는 매우 많다. 또한 실패하는 이유도 매우 다양한다. 필자는 이 중에서 가장 중요하다고 생각하는 하나에 대해서 얘기를 하려고 한다. 우선은 프로젝트를 왜 실패하는지 다양한 원인을 알아보자. 

• 고객의 요구사항을 충분히 파악하지 못함
• 제품의 방향을 빨리 정하지 못하고 우왕좌왕하면서 프로젝트 앞부분에서 상당부분의 시간을 소모하여 개발 기간이 부족하게 됨
• 스펙/설계를 제대로 작성하지 않고 코딩을 시작해서 엉뚱한 방향으로 개발을 함
• 작성된 스펙을 관련자들이 충분히 리뷰 하지 않아 잘못된 스펙으로 개발함
• 프로젝트를 진행할수록 새로운 요구사항이 계속 발견되어서 프로젝트가 한없이 늘어짐
• 변경된 요구사항을 제대로 관리하지 않아서 프로젝트 팀원들이 서로 다른 기준으로 개발을 함
• 상명하복식으로 지정된 출시 일정을 맞추기 위해서 급하게 코딩부터 시작함. 나중에 잘못된 코드를 고치느라고 시간이 더 소요됨
• 충분히 훈련되지 않은 개발자들을 투입하여 초반에 우왕좌왕함
• 일정관리를 대충 해서 프로젝트가 지연되고 있다는 징후를 눈치채지 못함
• 리스크 관리를 하지 않아서 리스크로 인해서 프로젝트를 실패함
• 프로젝트 막판에 경영진이나 주요 고객이 프로젝트 방향을 완전히 틀어서 거의 처음부터 다시 개발해야 함
• 프로젝트 팀원들의 팀웍에 문제가 있어서 지속적으로 불화가 발생하여 프로젝트는 산으로 감
• 도입한 외부 필수 기술이 기대처럼 동작하지 않는다.
• 테스트 팀에 제대로 된 스펙을 전달하지 못해서 테스트 준비를 제대로 하지 못함
• 회사의 표준 프로세스를 강요하여 문서를 너무 많이 만들다 보니 정작 개발에는 소홀해짐

이외에도 실패 원인은 끝도 없이 많을 것이다. 이를 간단히 분류해보면 스펙, 프로젝트팀, 프로젝트 관리, 고객, 기술 등 다양하다. 필자는 이중에서 가장 중요하게 생각하는 요인을 “스펙"이라고 생각한다. 

다른 영역도 중요한 것이 사실이지만 스펙을 적는 것은 소프트웨어를 개발하는데 가장 중요하면서 가장 어렵다. 스펙을 적는 것을 “분석” 또는 “분석/설계”라고 한다. 설계가 여기에 왜 포함되었는지 의아한 사람도 있을 텐데, 분석 시에 상위 설계의 상당부분이 포함이 되는 경우가 많고 프로젝트에 따라서 다르지만 분석과 설계는 그 경계가 모호하기 때문에 같이 다루는 경우가 많다.

프로젝트가 아주 작다면 스펙을 제대로 적지 않고 요구사항 몇 줄로 개발해 나가면서 소프트웨어가 무사히 완성을 하기도 한다. 소수의 경험이 많은 개발자가 개발을 주도하는 경우 요구사항을 대충 알려줘도 개발을 잘하기도 한다. 수백명이 투입되는 대규모 프로젝트에서는 매우 잘 정리된 스펙 문서가 필요한 경우가 일반적이다. 외국에 외주를 줄 경우 자세히 적힌 스펙 문서와 테스트 문서도 전달하기도 한다.

소규모 프로젝트에서의 성공의 경험을 대규모 프로젝트에 적용해서 실패를 하기도 하고, 대규모 프로젝트의 방법론이 중소규모 프로젝트에서 실패의 원인이 되기도 한다.

요구사항이 누락되거나 충분히 분석이 안된 스펙도 문제지만 너무 자세히 적거나 많은 문서를 적는 것도 문제가 된다. 대규모 방법론을 따르는 회사들에서는 이런 함정에 종종 빠진다. 개발은 문서대로 되지도 않을 뿐만 아니라 수시로 바뀌는 요구사항을 문서가 너무 많아서 문서에 반영도 제대로 못한다.

 

따라서 엄격한 프로세스로 규제를 하는 것도 어렵다. 자율에 맡겨도 쉽지 않다. 필자가 생각하는 가장 좋은 방법은 원칙만 지킬 수 있는 최소한의 프로세스가 있는 환경에서 좋은 문화를 가지는 것이다. 빨리빨리 문화를 지양하고 적절히 분석하고 설계를 한 후 프로젝트를 진행하는 것이 더 빠르다는 인식을 공유해야 한다. 실제로 가장 빠른 방법이다. 모든 관련자들이 스펙을 철저히 리뷰하고 쉽게 요구사항을 바꾸지 않아야 한다. 이런 문화와 관행을 만들어가는 것이 프로세스보다 더 중요하다. 그래야 회사에 역량이 축적된다. 그렇게 좋은 문화와 축적된 역량이 충분해야 어떠한 프로젝트라도 성공으로 이끌 수 있다.

좋은 환경이 있어도 스펙을 제대로 적을 수 있는 역량이 부족하다면 말짱 공염불일 뿐이다. 스펙을 제대로 적는 역량은 소프트웨어를 개발하는데 있어서 가장 어려운 역량이며 소질이 있는 개발자도 제대로 하려면 10년 이상의 경험과 노력이 필요하다.

이 방대한 얘기를 짧은 글로 어떻게 소개할 수 있을지 걱정은 되지만, 개발자가 어떻게 하면 소프트웨어 분석, 설계 역량을 가질 수 있으며 회사는 어떻게 그런 역량을 축적할 수 있는지 다음에 몇 개의 글을 통해서 조금 더 자세히 얘기를 해보고자 한다.

share with abctech.software

이우소프트에는 이것이 있다 vs. 없다

개발자 캐리어 보장이 있다.

• 개발자가 원하면 영원히 개발자로서의 경력을 보장해준다.
• 개발자에게 나이가 많다고 관리를 강요하거나 권유하지 않고 본인의 적성과 역량에 따라서 진로를 결정하면 된다.

남녀 차별이 없다.

• 남여에 따른 역할,대우의 차이가 전혀 없다.
• 100% 역량에 따른 차이 밖에 없다.
• 결혼, 육아에 따른 차별이 없다.

아키텍트가 있다.

• SW아키텍트가 있고 스펙, 설계와 기술적인 이슈 해결을 담당한다. 코딩도 한다.
• 무조건 고참이라고 아키텍트가 되는 것은 아니다.
• 아키텍트가 되기 위한 까다로운 자격을 충족해야 한다.
• 아키텍트는 사원부터 수석 연구원까지 있다.
• 여자 아키텍트도 있다.

관리만 하는 개발팀장이 없다.

• 개발팀장이 있기는 한데 휴가 결재가 하는 일의 대부분이다.
• 개발팀장은 Technical leader로서 개발만 잘하면 된다.

전문가가 있다.

• 자신의 일에 전문가가 되지 않으면 살아남을 수 없다.
• 하지만 전문가라면 의견이 존중되는 수평적인 조직이다.
• 비전문가가 감놔라 대추놔라 하지 못한다.

영어 이름이 있다.

• 모든 직원이 서로 영어 이름을 부르고 한국 이름은 사용이 금지되어 있다.
• 팀장님과 같은 직책으로 부르는 것도 금지되어 있다.
• 수평적인 생각을 정착하기 위해서 영어 이름을 사용하며 모두 동일한 존칭을 사용한다.

직급에 따른 서열이 없다.

• 개발자들은 직급이 아무것도 말해주지 않는다.
• 역량에 맞게 일을 분배하고 개발을 할 뿐이다.
• 아키텍트가 따로 있고 PM이 일을 분배할 뿐이다.

잔디밭이 있다.

• 8층 사무실 문을 열고 나가면 하늘 정원의 잔디밭이다.  
• 잔디밭에 누워서 햇볕을 쐬면서 머리를 식히자.

운동 시설이 있다.

• 체육관, GX, 웨이트 트레이닝, 골프 등의 시설이 직원들에게 제공된다.
• 건강관리를 위해서 꾸준히 운동을 할 것을 권장하며 여러 종목의 코치를 채용하여 운동을 지도하고 있다. 물론, 자기 계발과 운동을 할 수 있는 시간을 보장한다.

파티션이 없다.

• 파티션이 전혀 없이 책상들끼리 붙이 있다. 
• 모든 직원이 한눈에 보인다.

어린이집이 있다.

• 직원에게는 무료로 제공되는 어린이집이 있다.
• 출생 6개월부터 초등학교 입학 전까지 보육을 할 수 있다.
• 자녀와 같이 출퇴근을 할 수 있다.

회의록이 있다.

• 모든 회의가 하나도 빠짐없이 기록이 된다.
• 회의록은 거의 실시간으로 기록되고 모든 직원에게 공유된다.
• 회의에 참석하지 않은 사람도 언제든지 모든 회의록을 볼 수 있다.
• 그리고 결정된 사항은 모두 철저히 추적 관리가 된다.

코리안 타임이 없다.

• 회의시간이 1초도 늦는 직원은 없다.
• 1초라도 늦은 직원은 회의 참석자 전원에게 커피를 사야하고 2번째 늦을 때는 전직원에게 피자를 사야 한다.
• 커피는 얻어 먹었지만 아직 피자는 못얻어 먹었다. 언제 피자를 먹을 수 있을지 기다리고 있다.

전문 PM이 있다.

• 전문PM이 합리적으로 일정,리스크 등 프로젝트 관리를 한다.
• 억지를 부리지 않는다.
• 그렇게 해서 최단 시간에 프로젝트를 끝내고 있다.

일정 강요가 없다.

• 경영진이 말도 안되는 일정을 억지로 밀어붙이지 않는다.
• 1,2일 단위로 개발자가 산정하며 개발자가 예측한 일정을 다른 사람이 무시하지 않는다.
• 그래도 일정이 부족하면 PM은 온갖 방법을 동원해서 일정 단축 전술을 구사하고 그래도 부족하면 일정을 연기한다.
• 필요 시 일정은 구현 시작 전에 연기하므로 비즈니스 부서에서는 일정을 조율하는데 큰 문제가 없다.

몰입이 있다.

• 하루 8시간 업무에 완전히 몰입해야 한다.

야근이 없다.

• 강요된 야근이 없다.
• 일정을 합리적으로 결정하고 몰입해서 일해야 하기 때문에 야근이 필요 없다.
• 가끔 스스로 선택해서 야근을 하는 사람들이 있기는 하지만 강요는 없고 본인이 선택하는 것이다.
• 강요된 야근은 장기적으로 SW의 품질을 떨어뜨리고 기업 문화를 퇴보 시킨다.
• PM이 야근 카드를 꺼내는 경우는 정말 피치 못할 때이고 단기적으로 사용해야 한다.

스펙이 있다.

• 소프트웨어를 개발할 때는 항상 스펙을 작성한다.
• 큰 프로젝트는 SRS를 작성하고 작은 프로젝트나 프로토타입 개발 시에는 One-pager를 작성하다.
• SRS가 완료되면 모든 Stakeholder의 대표들이 서명을 한다.
• 프로젝트 계획은 스펙을 기초로 합리적으로 수립한다.
• 스펙은 변경되면 문서를 업데이트해서 최신 버전을 유지한다.

일정이 지연되는 프로젝트가 없다.

• 지연되는 프로젝트가 하나도 없다.
• 합리적인 일정 수립과 철저한 프로젝트 관리를 통해서 일정은 무조건 지킨다.
• 일정은 협력사와의 약속이므로 목숨처럼 지킨다.
• 출시 일정은 SRS가 끝날 때 확정한다.

60세 개발자가 있다.

• 나이는 개발자인지를 결정하는데 아무런 영향을 주지 않는다.

보고서가 없다.

• 개발자에게 보고서 강요가 없다. 주간보고도 없다.
• 개발자는 개발만 하면 된다.
• 문서는 개발문서만 쓰면 된다.

재택근무가 있다.

• 회사에서 자격을 부여한 개발자는 재택근무를 선택할 수 있다.
• 가끔 회사에 나와서 회의를 하고 커뮤니케이션은 거의 이슈관리시스템을 이용한다.

서울에도 스마트워크 센터가 있다.

• 본사에 동탄에 있는만큼 서울 북부 거주자 등 지역적인 어려움이 있는 직원들은 서울에 있는 스마트워크 센터에서 일할 수 있다.

E-mail이 없다.

• 모든 커뮤니케이션은 이슈관리시스템을 이용한다.
• E-mail은 주로 외부인과만 주고 받는다.
• 내부 모든 커뮤니케이션은 기록이 되고 공유가 되며 추적이 된다.

개발자에게는 가장 빠른 PC가 있다.

• 회사가 감당할 수 있는 한도 내에서 개발자에게 가장 빠른 PC를 지급한다.
• 빠른 CPU와 SSD를 장착하여 빌드 속도를 2배 빠르게 한다.
• 그만큼 개발자는 일을 더 많이 해야 한다. 그리고 정시 퇴근해라.

피어 리뷰가 있다.

• 개발자가 작성하는 코드 대부분을 리뷰한다. 리뷰를 통해서 버그를 찾고 공유, 학습을 한다.
• 더 중요한 것은 스펙, 설계 리뷰다.
• 개발자는 자신의 업무시간의 20%는 동료를 위한 리뷰에 사용해야 한다.
• 시니어 개발자는 20% 이상을 리뷰에 할애한다.

마시고 죽자는 회식이 없다.

• 원치 않는 음주 회식에 참여해서 끌려 다닐 필요가 없다.

즉석 라면이 있다.

• 회사 식당에서 제공하는 아침 메뉴 중에는 즉석 라면이 있다.
• 요리사가 별도로 맛을 낸 해장 라면을 즉석에서 끓여주고 충무김밥이 제공된다.

꼭 지켜야 하는 문화가 있다.

• 공유, 협업, 커뮤니케이션이 꼭 지켜야 하는 문화다.
• 공유와 협업을 철저히 하지 않으면 같이 일을 할 수 없다.