본문 바로가기
생각정리

오늘의 질문 2020.04.04

by 창천향로 창천향로 2020. 4. 5.

Q.1

Q. 저는 오픈 후 결함을 극도로 싫어하여 한번씩 더 챙겨본다고 일정을 하루 이틀 지연시키는 성향이 있습니다.
그래도 오픈 후 이슈가 적은 편이 더 낫다는 판단이였는데요.
이와 반대로 지정된 일정을 맞추기만 하고 배포후 이슈가 펑펑 터지는 분이 있습니다.
연봉협상 단계에서 이분이 평가를 더 잘 받는 것을 확인하였습니다.
이 분이 작업한 프로젝트는 이후에도 버그 개선으로 더 많은 공수가 들어감에도 저 보다 좋은 평가를 받는게 이해가 가질 않습니다.
속도만 중시해서 엄청 많은 버그를 발생시키는게 맞는걸까요?

A.
음 일단 이 부분은 한번은 조직장 면담을 통해서 실제 이 이유 때문에 평가가 낮은것인지 확인이 필요해보입니다.
결국은 질문자분의 추측이라서요.
한번은 정확하게 피드백 받으시고, 이 외에도 고칠것은 없는지 한번더 조언을 받고 퇴사하시는게 맞습니다.
그리고 피드백을 받으시면 그걸 고치시면 됩니다.
사회 생활을 하면서 누군가에게 피드백을 받는게 흔한 기회는 아니라서요.
좋은 성장의 재료가 될 수 있습니다.

그리고 제 개인적인 생각뿐만 아니라 아마 대다수의 리더분들은 비슷하게 생각할텐데요.
돈을 받고 일하는 직장인 (프로죠) 으로서 납기일 (오픈일)은 필수입니다.
SI가 아닌 서비스 회사라고 해서 납기일 (오픈일) 은 쉽게 늘릴 수 있음을 의미하진 않습니다.
(실제 저 역시 명절에 일하거나, 주말에 근무하는 경우가 종종 있습니다.)

그렇다고 해서 버그가 뻔히 보이는데 놔두고 오픈하라는 의미는 아니구요^^;
돈을 받는 개발자는 납기일과 일정 퀄리티 이상의 제품 2가지를 모두 맞춰야 하는 것이 맞습니다.
시소처럼 서로 반비례 관계가 아닙니다.

1

납기일을 못지키고 품질을 높이는것 vs 납기일을 지키되 버그 투성이의 제품을 내는것에 있어서는 누가 더 우위에 있다고 판단을 못할것 같습니다.
사실 저라면 둘다 낮은 점수를 줄거라서요.

납기일을 지키되, 버그도 없는 제품을 만들기 위해서 다른 개발자분들은 가장 자신있는 기술로 가장 익숙한 방법을 선택하는 것이기도 합니다.

그 익숙한 기술을 더 연습하고, 더 개선해서 점점 작업 시간을 최소화 시키려고 노력합니다.
실제 업무에서 어떤 기능/어떤 사건이 터질지 모르기 때문이죠.

그런 점이 어떤 분들이 봤을때는 "어휴 레거시, 발전없는 사람" 등으로 품평할 순 있다고 생각합니다.

다만 그렇게 해서 납기일도 잘 지키고, 버그도 거의 없는 안정적인 제품을 출시한다면 저는 새로운기술/새로운문법/새로운방법을 시도하는 사람보다 훨씬 더 좋은 점수를 줍니다.

물론 운영 환경에서 압도적인 퍼포먼스를 내면서 새로운 기술 도입을 완수하시는 분도 계시기도 합니다.

납기일과 퀄리티는 돈을 받는 프로 개발자에게 절대 빠질수 없는 요소이기 때문이죠.
새로운 기술이나 프레임워크, 언어등은 "내가 납기일을 지키고, 기능/버그도 충분히 고칠수있을 정도로 익숙해지면" 선택하는 이유이기도 하고요.

실제로 질문자분께서 납기일을 못지킨 경우가 몇번 있다면, 왜 그랬는지에 대해 조금 더 철저하게 분석하고 보완하시는걸 추천드립니다.

  • 왜 일정을 못지킨것일까
  • 생각보다 시간을 소요한 작업이 무엇일까
  • 개발자 테스트 혹은 QA를 너무 늦게 시작했다면 왜 늦게 시작하게 됐는가
  • 오픈을 미룰정도의 버그라면 왜 미리 캐치하지 못했는가
  • 앞으로 다른 프로젝트에서는 같은 실수를 방지할 수 있는가 등등

이런 고민들은 아마 이번에만 하실게 아니라 정기적으로 해주시면 좋을것 같습니다 :)
생산성이 더 잘나오는 방법이 무엇인지,
일정과 퀄리티를 계속 유지할 수 있는 방법은 무엇인지 등등 말이죠.

이런 얘기를 하는 저 역시 많이 부족해서 이것 저것 많은 시도를 하고 있습니다.

현재 사용중인 도구의 숙련도를 더 높이고,
자주 작성하는 코드가 있다면 미리 코드 템플릿을 만들어 사용하고,
좀 더 테스트 코드를 작성할 방법이 무엇인지,
저만의 커스텀한 개발 환경을 계속 만들고 있기도 합니다.

아마 많은 개발자분들이 이와 같은 노력을 하고 있는 것으로 알고 있습니다.
새로운 기술, 새로운 언어, 새로운 프레임워크로 가지수를 늘리기 보다는 주력에 좀 더 집중하는게 일정과 퀄리티 모두를 만족시키기 위함이 아닐까 싶습니다.

이번 사내 평가는 성장하시기에 좋은 계기가 될수 있을것 같습니다.
충분한 회고를 거치시면 큰 도움이 되실것 같습니다.




'생각정리' 카테고리의 다른 글

착각 주도 개발  (1) 2020.05.03
팀에서 얻을 수 있는 것  (1) 2020.04.26
오늘의 질문 2020.04.04  (0) 2020.04.05
2.0 까지 해본 개발자  (0) 2020.03.13
2019 하반기 회고  (0) 2020.01.04
일일커밋 3주년 회고  (0) 2019.12.15