개발 일정은 언제 터질까?

업무 관련 글을 정말 안 쓴 것 같아서 심심풀이로 글을 써본다.

일을 진행하다보면 항상 예상치 못한 상황을 만나게 된다.
처음 겪었을 때 당황스러운 부분은 일정이 망가지는 부분인데... 사실 별로 당황할 것 없는 것도 같다.

우리가 플래너에 적어놓고 지키지 못하는 계획이 수두룩하듯 회사에서 적어놓은 커다란 플래너에 가로선 좀 긋는다고 큰 일이 일어나진...않을 걸?

빙 image creator에 “개발 일정 폭발”이라는 프롬프트를 넣어 나온 이미지

 
보통 프로덕트를 만드는 프로세스는
 

1. 기획/디자인 진행
2. 개발 리뷰
3. 개발 일정 산정
4. 개발 진행
5. QA
6. 배포

 
이런 식으로 흘러가기 마련이다.
물론 조직마다 편차가 있지만 매우 애자일하지 않은 이상 겉보기엔 좀 달라보여도,
혹은 명확하게 쪼개져있지 않더라도 대략 저런 흐름을 타게 된다.
 
그런데! 4번 개발 진행 일정이 펑크가 난다면?!
보통 서비스 배포가 밀리는 상황으로 연결된다.
이 전에는 명확한 일정이 정해지지 않은 상태이기 때문에 밀릴 배포일이 없다 (일정 찍혀 오는 경우 제외)

따라서 고객사에게 약속한 납기일이 있는 경우에는 매우 난감하고 큰 일이 될 수 있다.
(나는 자사서비스에서만 있었기 때문에 이 상황은 겪지 못했지만... 들어보면 계약 문제이기 때문에 이 경우는 다들 야근을 해서라도 웬만하면 만들지 않는 듯)

자사 서비스라도 프로덕트를 만드는 부서 외에 협업하는 다른 부서들도 해당 배포 건과 관련한 계획이 있었다면 양해를 구하고 일정을 줄줄이 연기하게 된다. 기획 디자인은 밀려도 이런 티가 안 나는데 조금 억울하려나...
 
그러면 이 일정 펑크는 개발의 잘못일까?
책임을 따지는 일에 우리는 매우 예민하다. 특히 문제가 생긴 경우는 비난의 화살을 피하고 싶기 때문에 다른 희생양을 찾곤 하는데...

그러지 말자. 웬만하면 모두의 책임이다. 같이 하는 일에 있어서 한 쪽만 잘못하기도 어렵다.
다만 발생하기 쉬운 몇몇 케이스가 있으니 한 번 살펴보자.
 

 

1. 개발의 일정 산정 실패

estimation이라고 부르곤 한다. 가장 자주 일어나는 케이스 아닌가 싶다. (다만 개발에서 조정할 수 없이 일정을 찍어누르는 경우에는 해당하지 않는다)
이 경우는 나는 기획이기 때문에 얕게 말할 수 밖에 없지만, 원인도 다양하다. 그렇기 때문에 관리가 쉽지 않은 듯.

개발 인력의 리소스를 과대평가 했다거나 버퍼를 너무 적게 줬다거나 하는 부분은 나로서는 말하기 어려운 부분이라 생략한다.
 
주로 생각나는 원인은 아래와 같다 : 

1. 요구사항의 미비 - 아래 기획의 미비에서 다루겠다. 애초부터 리뷰하는 대상이 온전하지 않은데 온전한 일정을 산정하기 어렵다.
2. 요구사항 파악의 미비 - 일정 산정 당시 요구사항 파악 자체에 소홀할 때가 있다. 혹은 개발 리드 급이 일정을 짜는 경우, 리드가 파악하는 사이즈와 실무가 파악하는 사이즈가 다를 때가 있다.
3. 변경사항 반영의 실패 - 개발 리뷰에 들고 간 스펙이 그대로 라이브되는 경우를 본 적이 있는가? 실 상황에서는 사소한 것이라도 바뀌기 마련이다. 아무리 waterfall을 선호하고 완벽한 기획서를 가져다 주면 그대로 개발할게! 라고 말하더라도 세상에 완벽한 기획서 같은 것은 없다. 결국 리뷰에서를 포함하여 프로젝트 중 크고 작은 것들이 바뀌게 되는데 이 부분에 대하여 일정이 잘 반영되지 않은 경우에 해당한다. 

사실 어떤 원인이든 해결을 위해서는 소통이 중요한 것 같다.

• 기획이 미비한 경우, 해당하는 부분을 지적하여 이 부분들이 해소되기 전에는 일정을 산정하기 어렵다고 분명히 말해야 한다. 그 공백이 어떤 것으로 채워질 지 모르는데 일정을 그대로 정하는 건 무서운 일이다.
• 개발 리뷰 때 모든 스펙을 파악하는 게 어려운 일이다. 기획자는 하루종일 그걸 생각하고 지내왔겠지만 (목적조직이 아닌 경우) 개발자는 이 프로젝트가 초면인 경우가 많다. 이 경우 리뷰 미팅에서 이해가 안 된 내용에 대하여 확인하지 않았다가 그대로 QA에 이슈가 되거나... 나중에 구현하려고 했을 때 생각보다 사이즈가 큰 경우를 만나게 되는 것 같다. 프로젝트 진행 중에 헷갈리는 내용에 대해서는 자유로운 구현보다는 기획과 적극적으로 소통을 해주었으면 하는 큰 소망이 있다. 기획 역시도 이에 대해서 방어적으로 대응(그 때 제가 그렇게 설명드렸잖아요 /그때는 된다면서요)하기 보다는 서로의 이해를 맞춰가기 위해 협조적인 응대를 하는 것이 좋다.
• 변경사항 역시도 이것이 사이즈가 큰 지 작은 지.. 사실 기획/디자인에서는 어느정도 짐작만 할 뿐이지 가장 잘 아는 건 요구사항을 구현해야 하는 실무 개발자이다. 만약 일정을 터뜨릴 만큼 무리한 요구라면 이 부분에 대하여 충분히 이야기해야 한다. 그냥 안 됩니다! 라고 하기 보다는 이 요구사항의 어떤 부분은 어떤 이유 때문에 안 된다는 설명을 해주면 가장 좋다. (기술적으로 안 되는 이유를 매우 구체적으로 설명하라는 것은 아님) 기획자/디자이너가 문제가 되는 요구사항과 이유를 대략 알면, 그것이 top priority가 아니라면 다른 부분으로 대체할 수 있다. 비슷한 요구를 다시 안 할 수도 있고, 다음을 준비하는 일에 도움이 된다.

그리고 기획/디자인 - 개발 간의 요구사항을 던지는 사람과 받는 사람의 관계에 대해 이야기했지만, 생각보다 개발끼리의 소통 문제가 생기는 경우도 많다.

클라 작업 전에 BE 작업이 어디까지 되어야 했는데 안 된다거나, 개발자들끼리 작업을 나누기로 한 부분에 있어서 서로 싱크가 안 맞았다거나, 리드가 산정한 일정을 실무자가 수행하기 어려워하는데 말을 못한다거나...
 
신입 개발자의 첫 프로젝트로 함께 일하다가 마지막의 케이스를 겪었다. 그는 개발 완료일까지도 어떻게든 자기가 해낼 것이라고 말했지만 개발 완료일 다음 날 QA가 개발 서버에 접속하여 내용이 배포되지 않았음을 확인하게 했다.

이 경우에 일이 가장 커진다. QA 일정도 배포 일정도 다시 조정해야 하니 안 되면 빨리 소통하여 일정을 어떻게든 조정해보거나 업무에 도움을 요청해야 한다. 용기를 내야 해! 아니면 정말로 어떻게든 해내야 한다 
 
행간에서 읽히겠지만 개발의 estimation 실패라도 온전한 개발의 잘못이며 책임이라고 보기는 어렵다. (애초에 기획의 미비가 추정을 어렵게 한 원인일 수 있으니)

모든 게 원활했다는 환상적인 가정을 하더라도, 이 프로덕트에서 이 사람들과 이 프로젝트를 진행하는 건 누구나 처음이다.
유사한 작업을 해 본 경험이 있다면 좀 더 수월하겠으나, 예상치 못한 일은 언제나 일어나기 마련이다.

결국 이 것에 대한 소통이 또 중요해지는데... 모두모두 소통을 잘 하자~
 
그리고 프로젝트가 원활했든 아니었든, 프로젝트 단위의 회고가 필요하지 않나 싶다. 물론 프로젝트가 원활하지 않았을 때 범인찾기 식의 부검을 하는 것은 옳지 않다.

하지만 프로젝트가 종료되었다고 좋든 싫든 일단 덮어놓고 마무리하면 영원히 원인에 대한 개선이 이루어지지 않을 것이다.
결국 이 또한 피드백이라는 소통... 소통을 잘 하자~
 
 
 

2. 기획의 미비

많이 안 일어난다고 하고 싶지만, 당연히 많이 일어난다.
그런데 사람인지라... 어쩔 수 없다. 사실 역할 상 어쩔 수 없다. 기획자는 보통 개발의 전문가가 아니며 고려할 수 있는 개발 지식에는 한계가 있다.

예를 들면, 기획에서는 A 피쳐의 정보와 B 피쳐의 정보를 엮어서 보여주고 싶은데 A 피쳐와 B 피쳐의 정보는 아예 다른 DB에 담겨있어서 BE에서의 공수가 겁나 많이 든다든지... 이런 건 개발이 말해주기 전에는 파악하기 힘들다. 설령 데이터 분석을 해서 DB 구조를 대략 알더라도 기획이 보는 건 분석 DB 이기 때문에... 기획이 실서버에 쿼리를 날릴 수 있는 환경은 가정하지 않겠습니다.
 
결국 구멍이 송송 나 있는 기획을 들고 간 다음에 피드백을 통해 채워줘야 한다는 이야기이다.

물론 이 과정에서... 기획의 역할은 가만히 구멍 난 걸 누군가 메꿔주기를 기다리면 안 되고, 빠릿빠릿하게 개발이 가능한 요구사항으로 바꾸어가는 것에 있다. 이 과정이 빠르고 꼼꼼할 수록 일정의 펑크 확률도 줄어든다.

그리고 위에서도 언급했듯, 개발도 처음보는 기획서의 구멍을 눈을 부릅뜨고 모두 찾아내기는 어려운 일이다. 기획 쪽에서도 개발적으로 구현이 가능할 지 불안한 부분에 대해서 리뷰 전에 미리 체크해두고 먼저 확인하는 성의가 필요하다.
 
그리고 당연히 안 된다고 하고 싶은 부분은... 이미 예전에 겪었던 부분을 빠뜨리지는 말라는 것이다.
이 경우는 사소하다고 생각되는 경우들이 많지만, 결국 기획서에서 언급하지 않는다면 개발에서는 그것을 플젝 기간 중 스펙 추가로 인지할 수밖에 없다. 이런 경우를 서로 조심해야 사고를 방지할 수 있다.
 
알림을 추가해놓고 알림내역은 까먹는다든지... 포인트 적립해놓고 포인트 적립내역은 확인 안 한다든지... 엠티 화면 고려 안 하고 나중에 엠티 화면에 뭐 넛지하면 좋을 것 같은데?... 리스트 만들어 놓고 이거 모두 삭제하는 기능 있어야 하지 않나?.... 다국어 지원하는데 번역 추가 안 한다든지... 정보의 max값이나 최대 보관 기간... api 호출 트리거... 정보의 갱신 조건.... 뭐 이런 거는 미리 고민을 해놓자! 
 
개발도 답답허겠지만 말을 해줘야 한다. 그 구멍이 개발자에게만 보이는 구멍이라면 장님의 눈을 뜨게 하고 구멍을 채워달라 요청해야 한다. 그래야지 깜짝 놀라서 얼른 일을 하지 아니면 몰라서 못한다. 설령 그 구멍이 누구나에게나 보이는데 저 녀석이 일을 못/안 해서 그럴 때 조차도 그 구멍난 기획으로 일정 산정하면 추후 고달파지는 것은 본인이라는 생각을 하면서 말을 하는 편이 낫다.
 
 
 

3. 천재지변

대표님이 갑자기 바꿔달래요 / 그 사이에 다른 커다란 이슈가 터져서 개발자들은 그것을 대응해야 했어요 / 데이터 센터에 불이 났어요...

천재지변은 대응할 수 없다. 일반적인 천재지변은 대표님이나 리드 이슈인데... 그 말을 받아오는 사람이 잘 쳐내길 기도하는 수밖에 없다. 만약 그 사람이 쳐내지 못했다면 그 역시 슬퍼했을 터이니 너무 비난하지 말자. 그는 단지 전달하는 처지일 뿐일 확률이 높다는 걸 기억해주세요.  함께 갈리는 처지에
 
 
 
이걸 왜 갑자기 썼을까?
결국 소통왕 직장인만 살아남을 수 있는 세계관이다.
우리 모두 마음을 열어보아요~
 
당연히 나는 내가 겪은 케이스로 이야기를 한다. 세상엔 기획서를 몰래 잠수함 패치하는 이상한 기획자도 있고 기획서가 어떻게 생겨먹었든 자유로운 구현을 하거나 QA 기간 또한 개발기간으로 알고 있는 개발자도 있다. 하지만 이런... 이야기를 해보아야 어떤 점이 유익하겠는가.
사실 이 조차도 소통...소통을 하면...!! 물론 저런 인간들은 소통이 잘 안 됨 
 
난잡한 타 직무에 비난은 원하지 않지만 더 업무를 나아지게 하는 방식의 토론은 환영합니다.
의견이나 사례를 남기고 싶다면 댓글로 달아주세요.