그 연차에..? -일정에 대한 부담을 안고 사는 개발자
승돌쓰다
제가 몰래 몰래 훔쳐보던 블로그의 내용인데, 늘 저도 어려운 부분이 일정 산정입니다.
내가 안해봤는데, 해당 스펙에 대한 기능 구현이 얼마나 걸릴지 예측 하는 것에 대한 부담감이 늘 있습니다.
본문에도 나오듯, 5MD를 말하면, 왜 이렇게 오래 걸리나요? 하고 되물음을 당할까봐!? 짧게 말하고 야근을 하는 경우가 왕왕 있습니다.
"그 연차에..." 왜 이렇게 오래 걸리느냐? 라는 말이 오면, 사실 할 말은 없습니다.
할 수 있는 말은 그저, "능력 부족"에 원인이 있다 밖에 없죠.
차라리 그렇게 흘러가는 것보다는 넉넉하게 잡고, 빠르게 끝내는 것도 하나의 방법인데, 이게 생각보다 용인 되는 환경을 갖추기가 쉽지 않습니다.
생각해보면 개발자는 늘, 내가 해본 일과 해보지 않은 일과의 싸움입니다.
개발 일정에 유관 부서와 협의를 해야 한다거나, 다른 회사 개발자와 협의를 해야 한다거나, 시스템 추가를 한다거나 해야 할 일들이 생각지도 못하게 스펙 기능 구현 작업에 끼어듭니다. 기존에 개발 했던 시스템이나, 장비가 이상해집니다. 개발자는 시간을 초월 하는 만능 SCV가 아닙니다.
시간은 늘 부족하죠. 그 안에서 개발자는 최선의 선택을 늘 해야 합니다.
어쩌면, 시간이 지나도 서투를 수 있는 것도 인정 하는 미덕이 어느 정도는 필요 하지 않을까? 생각 합니다.
꼭 시니어 엔지니어라고, 주니어 엔지니어라고 짧게 처리 하고, 오랜 시간 처리 하는 것이 아니다. 라는 생각을 합니다.
이 업계는 특이한게 업계 경력이 모든 것을 대변 해주지 않죠. 결국, 경험치의 차이 일뿐, 기능 구현에 앎과 모름의 차이는 크지 않을 수 있다는 게 아직까지의 제 생각입니다.
결국, 연차가 많든 적든 앞을 예상 하고 예측 한다는 것은 기존 과거의 일들에 대한 예측치와 실제 소요 시간에 대한 히스토리 관리가 필요합니다. 물론, 잘 정리가 되어 있어야겠죠.
그래야만, 이런 비슷한 일들을 했었는데...? 하면서 떠올려서 이런 업무는 3일 정도 걸립니다. 말 할 수 있다고 생각 합니다.
결과적으로 개발의 일련 활동에 대한 모든 것이 추적이 되는가?
추적이 된다면 실제로 사용을 하는가?
개개인의 개발자만의 문제가 아니라 팀 영역에서 해당 정보가 관리 되는지가 중요해보입니다.
그래야 누구든, 일정 산정이 조금은 편해질 것이라 생각 합니다.
늘 말하지만, 일정 산정은 어렵습니다. 일하다 보면 솔직히 말해서 1MD (야근 제외)기준으로 하고, 지킬 수 있는 일정이 많지 않습니다.
