해당 글은 코드 스쿼드 미니 컨퍼런스 때 발표했던 "개발만 잘하면 되는 줄 알았어요" 발표의 생각 정리 글이다.
나는 현재 스타트업에서 2년 조금 넘게 개발일을 하고 있는 주니어이다. 개발자가 3명일때 부터 합류해 지금은 20명 거의 가까이 되는 개발팀에서 일을 하고 있다. 사람이 늘어나면서 "일을 되게하는 사람"의 특징이 눈에 보이기 시작했는데, 주니어의 시각으로 한 번 씨부려보겠다.
지극히 개인적인 이야기이다. 내가 앞으로 걸어가고 싶은 길이기도하니 내용 상 부적잘하다고 생각되는 부분이 있다면 피드백 부탁드립니다 ㅎ
일정을 어떻게든 맞춘다.
A는 일을 진행할때 100%의 퀄리티를 뽑아낸다. 다만 퀄리티를 뽑아내기 위해서 간혹 기존 일정을 넘어서 일을 진행하는 경우가 있다. B는 결과물 자체는 80% 정도의 퀄리티를 유지한다. 하지만 A와 다르게 정해진 일정을 지키는 모습을 보인다.
이 두사람중에 일을 되게하는 사람은 B 이다.
업무를 진행하다보면 나의 의욕과는 다르게 예상 밖에 일들이 많이 일어난다. 일을 시작하기 전에는 미쳐 생각하지 못한 일들로 인해 기존에 설정해두었던 일정이 어겨지는 일도 더러 발생한다. 그래서 항상 퀄리티를 더 가져갈까? 혹은 일단 돌아가는 형태로 만들까? 에 대한 고민을 하게 된다.
이런 상황에서는 지금 진행하고 있는 업무를 적당히 끊어 마무리 짓고, 새로운 계획을 새우는 방법을 택하는 것이 좋다. 조금만 더 하면 마무리 될것 같은데 라는 생각으로 1주 2주가 계속 지나면, 해당 일정을 관리하고 있는 매니저도, 업무를 진행하고 있는 당사자도 지친다.
당연히 이런 상황에서 적당히 마무리를 짓는 선택을 하면 기존에 계획했던 모습과는 못미치는 결과물이 나올 수 있다. 하지만 적당한 템포로 업무를 마무리하고 다시 계획을 세웠을 때 오히려 추진력있게 일들이 진행된다.
개개인이 자신의 업무를 100% 마무리까지 끌고 갈 수 있는 힘을 기르는 훈련이 필요하다
최선이 아니라 차선을 선택한다.
업무를 진행하면서 여러가지 선택을 해야하는 상황이 온다. 그리고 그 여러가지 선택지들은 각각의 장단점들이 존재한다. 모두가 같은 것을 원하면 좋지만 사실 현실은 그렇지 않다. 어떤 사람 입장에서는 해당 방법이 정말 말이 안된다고 생각할 수도 있고, 또 어떤 사람은 자신이 제시한 방법의 자신의 투영하여 의견의 단점이 곧 자신을 블레임하는 것이라고 느낄 수도 있다. 사람이기 때문에 이런 현상은 당연하다고 생각한다. 하지만 이런 상황에서도 우리는 결정을 해야한다.
이때 중요한것은 현재 상황에 차선의 선택이다. 단점이 존재하지 않는 의견은 없다. 단점이 없다면 애초에 이러한 선택을 할 상황이 만들어 지지 않는다. 누가 봐도 명확한 단점이 존재하는 의견이라도 현재 상황에서 얻게될 장점이 더 크다고 판단되면 그 선택을 해야한다. 그 선택을 이해해야만 한다.
해당 단점에 대해 강하게 주장했던 사람은 해당 선택을 받아드리기 힘들 수도 있다. 그리고 또한 시간이 지난 뒤에 그때 드러났던 단점으로 인해서 위기가 생길 수 있다. 이 상황에서 일이 되지 않게 하는 사람들은 더러 자신이 과거에 주장했던 의견들을 들어내며 불평을 할 수 있다.
나는 무시한다.(이야기는 듣지만 크게 동조하지 않는다는 뜻) 현재의 벌어질 일은 현재가 아니면 알 수 없다. 그럼에도 불구하고 우리는 차선을 선택한 것이고, 분명 그 선택으로 인해 얻은 것도 있을 것다. 중요한 것은 현재이다.
문제의 원인을 가장 먼저 환경, 동료, 회사, 시간에서 찾지 않는다.
문제가 없이 진행되는 업무는 극히 드물다. 그 문제의 원인은 정말 다양한데, 개발을 진행하는 환경, 참여하는 구성원의 실수, 회사의 정책적인 이슈, 절대적인 업무의 시간 등 여러가지가 있다.
여기서 중요한 것은 프로젝트가 진행되는 중에는 절대 자신이 아닌 다른 곳에서 원인을 찾지 않는 것이다.
구성원 개개인은 사람이기 때문에, 업무에서 감정이 드러나기 마련이다. 따라서 프로젝트 진행중에는 각각의 구성원들의 감정을 상하는 일이 없이 진행되어야 한다.
그렇다고 발생한 문제에 대해 언급하지 말라는 것은 아니다. 그 문제는 고쳐지지 않으면 이후에 진행하는 프로젝트에서도 동일하게 발생할 수 있다. 따라서 프로젝트가 마무리된 이후에 회고를 통해 각각의 문제에 대한 원인을 같이 논의하고, 그 문제가 다시 재발하지 않기위해 할 수 있는 노력이 무엇인지 찾아가야한다.
능동적으로 업무를 수행한다.
업무를 진행하다보면 다른 구성원의 도움이 필요한 경우가 많다. 그렇기에 업무를 해당 담당자에게 맡긴 후 업무를 진행하는 경우가 있다. 이러한 업무 방식의 단점은 업무의 메인 담당자의 부재로 이루어 진다. 담당자가 없는 업무는 그 일이 언제 마무리될지, 어떻게 마무리가 되고 있는지에 대한 것을 알기 어려워진다.
여기서 중요한 것은 자신에게 발생한 업무를 마무리까지 끌고가는 힘이다. 다른 구성원의 도움이 필요하면 해당 구성원이 업무를 처리하기에 소요되는 시간 및 일정, 업무가 딜레이 되고 있다면 그 원인이 무엇인지 등등 디텍팅해야 그 업무는 수월하게 마무리가 될 수 있다.
개발자라는 직업으로 업무를 진행하다보니, 개발 이외에 커뮤니케이션과 인간 관계 부분에서의 성장도 중요하다는 것을 느끼고 있다. 그 성장을 멈추지 않기 위해 나는 나 스스로 경계하고 회고하며 앞으로 나아갈 것이다. 아마 주니어의 시각으로 보았을 때와 성장한 이후 미드레벨로 보았을때의 생각이 다를 수도 있다. 그 내용은 이후 미드레벨이 되었을 때 위 내용과 비교하며 이야기하겠다.
마지막으로 좋은 발표 기회를 만들어 주신 JK 께 감사 인사를 드린다. 감사합니다! ㅎ