신기한 연구소

개발자로 살아오면서 팀을 만들고 프로젝트에 참여해서 일을 하다 보면 다양한 이슈들이 발생한다. 그중 사람 이슈가 가장 힘들다 할 수 있다. 리더로서 모든 팀원의 입맛을 맞춰줄 순 없다. 이 사람 이야기를 들어주면 저쪽이 난리고 저쪽 말 들어주면 이쪽이 난리고 여기저기 불평불만이 많다. 사실 그 불평불만을 들어보면 결국 자기 편의와 이익에 집중되어 있다. 원칙을 이야기하면 원칙 원칙 한다고 짜증내고 그래서 더 잘해주면 당연히 해주는 걸로 받아들인다. 피곤하다.

특히, 고집도 쎄고 자존심도 센 사람은 정말 힘들다. 말 한 번 잘못했다간 엄청난 융단 폭격을 맞을 준비를 해야 할 것이다. 고집도 세고 자존심도 세지만 일은 똑 부러지게 잘한다면 그래도 괜찮다. 잘 구슬려서 일을 하면 되니깐.

문제는 고집도 쎄고 자존심도 센데 일은 못하는 사람이 문제다. 일을 못한다는 건 다양한 경우가 있지만 특히 능력이 안 되는 경우가 더욱 심각하다. 즉 개발을 못하는 개발자 이야기다. 신입이나 초급 개발자면 그래도 이해가 된다. 하지만 중급 이상 개발자인데 개발은 못하고 고집과 자존심에 세며 더 심각한 문제는 자기 자신은 일을 잘하고 있다고 착각하는 게 큰 문제이다. 팀을 위기로 몰아갈 수 있다. 그 착각으로 업무팀의 불만은 늘어가고 그 불만을 잠재우기 위해선 주변 개발자들이 십시일반 나눠서 업무대행을 하는 수밖에 없다. 하지만 그들도 사람인데 월급은 문제의 개발자가 다 받고 일은 우리가 무상으로 대행을 계속해야 되느냐?라는 불만을 팀장에게 제기한다.

고집도 쎄고 자존심도 센 게 나쁜 건 아니다. 좋은 방향으로 자기의 발전을 위해서 필요한 부분이기도 하기 때문이다. 사실 고집이 없고 우유부단하면 일할 때 피곤할 수도 있다. 자존심은 달리 말하면 프로의식으로 표현할 수도 있다.

혹시 누군가 내가 개발한 소스에 대해 평을 할 때 어떻게 받아들이는가?

1. 오! 그렇군. 저런 방법도 있었네, 내가 만든 것보다 더 좋은데!

2. 뭐라는거야! 니나 잘하세요. 지는 얼마나 잘 짠다고 짜증 나게.

여러분은 어떻게 반응하는가?

사실 1번으로 반응하기 힘들 것이다. 자존심이 걸린 문제이기도 하기 때문이다. 특히 평을 이야기할 때 좋게 말하는 게 아니라 약간 강한 어조로 "에이~ 이렇게 하면 안 돼. 자 이렇게 해야 되는 거야!!" 이렇게 상대가 평을 한다면 바로 아래부터 열이 확 뻗쳐 오를 것이다.

그래서 문제가 있는 소스에 대해 평을 할 때 상대의 자존심을 건들지 않고 인정하게 해서 유연하게 풀어나가야 한다.

그렇다면 혹시 내가 그 문제의 개발자이지 않을까?

간단하게 체크해 보자.

업무팀의 요청을 약속한 시간에 완성해서 오케이를 받았는가?

업무팀의 요청을 바쁘다는 이유로 미루고 있지 않는가?

"오늘 중으로 해결할께요" 라는 말을 하고 잘 지키고 있는가?

중요한 것은 신뢰를 깨지 말아야 한다. 거짓말은 또 거짓말을 낳기 때문이다.

신뢰가 깨지만 여러분이 만든 프로그램에 대한 신뢰도 깨질 수 있다.

업무팀의 신규화면 개발 요청이 왔다.

그리고 개발 요청서가 왔다. 요청서를 가지고 업무팀과 요건정의(요구사항정의)를 위해 회의를 한다.

업무 상세를 확인하고 일정을 조정 및 확정한다.

이제 컴퓨터 앞에 앉아서 요구사항을 정리하고 계획을 세우고 개발 준비를 한다.

가장 먼저 무엇을 하는가?

우선 큰 그림을 본다. 화면은 어떻게 구성되는가? 데이터 처리는 어떻게 되는가? 가장 난이도가 있는 로직은 어떤 것인가?

기간 내 개발을 완료하기 위해 가장 중요한 것은 양과 난이도이다. 아무리 쉬워도 개발 분량이 많다면 기간을 맞추기 힘들 것이고 개발 분량이 적어도 난이도가 있어서 해결할 시간이 많이 필요하다면 또한 기간을 맞추기 함 들다.

우선 전체 큰 그림을 보고 일정을 대충 맞춘 다음 난이도 있는 부분을 분리해서 따로 관리한다. 관리자 입장에서는 일일보고 또는 주간보고에 진척률을 확인하는데 시간이 흘러도 진척률이 부진하면 걱정과 문제가 있는지 확인 요청이 올 수 있다. 보통 이런 경우가 발생하는 이유는 개발자 입장에서는 "나는 난이도 있는 부분을 개발하는 중이라 분석도 하고 단위 테스트도 하면서 개발하느라 잠깐 정체되어 있는 거지 큰 문제는 없다" 라고 생각한다. 하지만 관리자는 한 명의 개발자만 관리하는 게 아닌지라 보고서의 진척률을 보고 평가할 수밖에 없다. 구두로 상황 설명을 해서 안심시키려고 했을 때 받아주는 관리자가 있는 반면 의심을 하는 관리자도 있을 것이다.

꼭 이런 상황을 대비한다기보다 개발자 본인도 명분도 있고 자신감을 갖기 위해서는 다른 방법을 사용하는 게 나을 것이다. 우선 전체 진척률을 관리하기 위해 쉬운 부분은 매일 꾸준히 진행을 하는 것이다. 그리고 따로 분리해 놓은 난이도 있는 부분은 가장 집중력이 좋은 시간대에 2-3시간 정도 작업을 한다. 집중력이 떨어지면 쉬운 부분을 작업하거나 문서작업을 하면 시간을 잘 활용할 수 있게 된다.

가장 중요한 건 내가 언제 가장 집중력이 있느냔 것을 파악해야 된다. 또한 퇴근하면서 내일 어떤 부분을 진행할지 한 번 생각해 보는 것도 좋고 아침에 출근해서 오늘 어떤 부분을 진행할지 메모를 해서 모니터에 붙여서 진행해도 일정 관리에 큰 도움이 된다.

난이도 있는 부분도 진행하고 이후 쉬운 부분도 진행해서 진척률을 관리하면 관리자 입장에서도 크게 신경 쓰지 않는다. 특히 난이도 있는 부분이 잘 진행돼서 완성되면 이제 남은 작업은 수월하게 진행될 것이다.

난이도 관리를 하지 않으면 보통은 진척률 관리에 이슈가 발생할 수도 있고 완료 시간에 다 되어서 갑자기 난이도 있는 부분이 발견되면 일정을 맞추기 힘들어질 수 있다.

먼저 큰 그림을 보고 난이도를 분리해서 관리하면 일정을 맞추는데 도움이 될 것이다.