개발문화 만들기 - 외부세미나

어느 업무나 마찬가지겠지만, 개발자로 업무를 하다보면 어느 순간 지치게 됩니다. 무언가 새롭게 만들고 멋지게 보여주며 런칭하는 시점을 지나고 나면, 금새 유지보수의 나날들이 기다리고 있습니다. 끊임없이 생겨나는 이슈와 반복되는 패치들에 시달리게 되지요. 그리고 그 범위에서 정체되는 듯한 느낌을 받습니다. 우리팀도 예외는 아닙니다. 그나마 신규 제품을 개발하던 시점에 있었던 사람들은 새롭게 만들어봤다는 경험이 있어서 그나마 낫습니다. 그러나 대다수는 이미 출시된 제품의 유지보수 기간에 입사하게 되면서 남이 만든 코드를 들여다보며 조심스레 수정을 해야 하는 상황에 놓이게 됩니다. 천천히 지쳐가게 되지요. 이를 완화해 보고자, 팀장이 되고 나서 강조하고 있는 것 중의 하나가 외부 세미나 참석입니다. 스스로 지..

Joshua/직장 2023.11.20 Joshua95

개발문화 만들기 - 1:1미팅

매니저 트랙으로 변경한 후, 여러 개발 관리 책들을 살피다보면 항상 중요시 되는 것이 1:1미팅입니다. "1:1 미팅은 무조건 해야 된다.", "사람 가장 중요하다.", "모든 것보다 면담이 우선순위를 높여야 한다."는 조언이었지요. 팀장이 되고 첫해는 정신 없는 와중에 팀원들과 분기당 1회를 면담하겠다고 얘기를 했었습니다. 그런데, 20명을 훌쩍 넘는 팀원들을 분기당 1회 면담하는 것도 여간 힘겨운게 아니었습니다. 게다가 당시는 코로나 상황이라 모니터만으로 면담을 하려니 더욱 그 시간을 주저하게 되었습니다. 결국 분기 1회 약속은 반기 1회로 정정하였습니다. 회사에서 정식 진행되는 상반기, 하반기 평가 면담 정도만 하는 걸로 타협했습니다. 이미 매니저를 하고 있는 친구에게 면담의 어려움을 호소하였더니,..

Joshua/직장 2023.08.12 Joshua95

개발문화 만들기 - 직급별 미팅

우리팀은 20명이 넘는 개발팀입니다. 인원이 많은 팀을 맡다보니, 팀원들이 작은 파트만으로 파편화되는 모습들이 보입니다. 팀에서 진행하는 전체 이벤트로 월례회의나 개발자 토론, 회식 등이 있었습니다. 하지만, 결국 아는 사람들을 벗어나지 못해서 같은 팀임에도 말 한번 섞지 못하는 사람들이 많아집니다. 친하지 않으니 서로 의견 나누는 것을 부담스러워하고, 팀의 모임들은 주로 팀장만 떠드는 시간들이 되어 갑니다.  이를 바꿔보고자 팀원들의 의견들을 들어보았습니다. 서로 의견을 나누기에 가장 편한 상대는 같은 직급과 나이대의 사람들이라고 합니다. 그래서 직급별 미팅을 시작하기로 했습니다. 다른 파트에 있는 같은 직급의 사람들과 한달에 한번 모이기로 한 거지요. 이 시간에는 특정 주제에 대해서 1시간 가량 같이..

Joshua/직장 2023.08.05 Joshua95

개발문화 만들기 - 개발자 토론

개발팀을 맡고, 어떻게 하면 좋은 개발 문화를 만들 수 있을까 고민 중입니다. 그 중 초반에 시작한 것은 개발자 토론입니다. 개발자들 간에 서로 기술과 트렌드를 가지고 가벼운 마음으로 이야기하는 시간입니다. 업무에만 매몰되어 본인의 제품에만 갇히는 개발자들이 되지 않도록 서로 환기해 보자는 차원입니다. 2주에 한번 팀원들에게 발표를 독려하고, 발표자 없을 때는 제가 발표를 하는 형태로 진행 했습니다.아래의 내용으로 팀원들에게 개발자 토론을 소개했습니다.- 발제자는 15분~30분의 분량으로 부담 없이 자료를 준비한다.- 가능한 슬라이드 10장을 넘지 않도록 한다.- 매월 1, 3주 화요일 1시간을 할당한다.- 팀원 전체를 대상으로 하되, 필참자를 지목할 수 있다.- 발표자는 먼저 자원 받고, 그 다음은 추..

Joshua/직장 2023.07.30 Joshua95

성과가 좋지 않은 팀원

연말 평가 기간을 지나며 성과가 좋지 않은 팀원을 대하는 것이 어려운 시점입니다. 팀장으로서 저평가자들을 어떻게 가이드해야 할지 기준을 잡으려고 노력 중입니다. 드라이하게 성과를 말하기, 모호한 말로 두리뭉실 얘기하지 않기, 감정이 아니라 데이터로 말하기 등 여러 이론이 실전에서 적용하기는 쉽지가 않습니다. 혹자는 과감하게 저평가자를 팀에서 제외시켜 주는 것이 건강한 관리라고 얘기하기도 합니다. 하지만 여전히 그 기준이 제 스스로를 설득하지 못하고 있습니다. "들어올때는 까칠하게, 나갈때는 쿨하게"를 외치며, 한번 들어오면 최선으로 같이 하자고 강조를 하였는데, 막상 매년 평가마다 업무의 전환이나 타팀 이동을 종용한다는 것이 스스로도 모순적입니다. 처음 매니저가 되고자 했던 것은 탁월한 매니저로서의 성과..

Joshua/직장 2023.01.07 Joshua95

일정 기여도 평가

초보 팀장이 되고 나서, 평가 고민을 지속적으로 하고 있습니다. 어떻게 하면 잘하는 사람에게 좋은 평가를 줄 수 있을까가 고민입니다. 개발자의 목표에는 매번 일정 준수가 목표 지표로 들어가게 됩니다. 정해진 일정 준수를 하면 B, 일정은 2주 당기면 A, 일정이 2주 이상 지연되면 C가 되는 식이었지요. 평가에 무관심하던 개발자 시절에는 어차피 목표에 따른 평가가 되지 않다 보니 별 관심 없이 지나갔던 지표가 평가자가 되고 나니 고민이 되는 것입니다. 사실 개발자에게 일정으로 정확하게 평가하기란 쉽지가 않습니다. 우선 개발자들이 일정을 예측하는데, 일정을 당겼다는 것은 오히려 일정 예측을 잘못했다는 얘기가 되니 마냥 칭찬만 하고 있을 수는 없는 탓이지요. 뿐만 아니라 일정에 대한 지연은 또 어떻습니까. ..

Joshua/직장 2021.07.03 Joshua95

우리는 서로 정직하다고 가정한다

"우리는 서로 정직하다고 가정한다. 옆사람은 최선을 다하고 있다." 새로운 팀에서 다시 스크럼을 시작하면서, 우리의 다짐 중의 하나로 "우리 서로가 정직하다고 가정"하자고 얘기를 했습니다. 하나의 개발팀으로 좋은 팀웍을 위하여 필요한 것은 신뢰인데, 이것이 쉽지가 않습니다. 개발자마다 실력의 차이가 있고, 관점의 차이가 있다 보니 항상 서로 불편한 사람들이 존재하게 됩니다. 어느 때에는 얄밉게 노니는 개발자들도 있고, 어느 때에는 잘하고 싶어도 안되는 사람들도 있게 되지요. 저도 그것이 불편하고 아쉬워서 불만들을 많이 토로하였는데, 지나고 보니 결국 그 사람이 우리 팀원인 것도 우리팀의 실력이었던 것입니다. 여느 영화처럼 우리가 최고의 개발자들로 찾아서 영입하고 같이 할 수 있으면 좋겠지만, 실상은 한계..

Programming/스크럼 2021.06.19 Joshua95