메뉴 바로가기 검색 및 카테고리 바로가기

한빛미디어

개발 7년차, 매니저 1일차

개발만 해왔던 내가, 어느 날 갑자기 ‘팀’을 맡았다!

한빛미디어

번역서

판매중

  • 저자 : 카미유 푸르니에
  • 번역 : 권원상 , 한민주
  • 출간 : 2020-02-04
  • 페이지 : 372 쪽
  • ISBN : 9791162242551
  • 물류코드 :10255
초급 초중급 중급 중고급 고급
4.6점 (42명)
좋아요 : 3

경력이 쌓이면 누구나 겪게 될

‘개발 관리’의 모든 것을 한 권에!

  • 사수, 멘토, 팀장, CTO까지 직책별 관리 기술 대백과
  • 개발자도 꼭 알아야 하는 소프트 스킬, 사람 및 조직 관리 노하우 수록
  • 개발 팀을 성공으로 이끄는 IT 팀장에 대한 모든 것

 

대다수 사람들은 조직에 들어가고 ‘관리받게’ 된다. 하지만 경력이 쌓일수록 ‘관리하게 되는’ 비중이 늘어난다. 따라서 개발자가 매니저로 전향하는 순간이 오는 건 피할 수 없다. 이 책은 매니저로 성장하면서 겪는 여러 문제를 구체적인 사례를 통해 보여 주고, 이를 극복할 수 있는 실질적인 조언을 담았다. 개발자에서 테크리드로, 팀장으로, 여러 팀을 관리하는 CTO로 성장하며 겪게 되는 다양한 시나리오와 각 직책별 좋은 매니저의 모습을 알려 준다. 또한, 소프트 스킬이 부족한 사수를 둔 개발자를 위해 사수에게 어떤 도움을 받을 수 있는지에 대한 구체적인 내용도 담았다.

 

 

이런 분들 주목!

  • 개발자 vs 매니저 갈림길에 서 있다.
  • 개발 관리를 체계적, 효율적으로 하고 싶다.
  • 내 사수가 사수 역할을 못해서 내가 고생 중이다.

 

이 책을 주목해야 하는 이유!

첫째, 아마존 베스트셀러 『The Manager’s Path』의 한국어판! 현재 아마존 ‘엔지니어링/기술 프로젝트 관리’ 분야 베스트셀러이다.

둘째, 멘토로 시작하여 시니어 리더십에 이르기까지 각 직급에서 알아두어야 할 관리 기술을 모두 담았다. 개발자라면 한 권은 구비해 두고 경력 ‘레벨업’ 할 때마다 꺼내 읽어야 하는 바이블 같은 도서이다. 

셋째, 개발 관리에서 겪게 될 여러 문제를 사례를 통해 보여주고, 실질적인 조언을 제시했다. ‘개발자’라는 환경에서 겪는 특수한 상황들을 들려줌으로써, 비슷한 상황이 닥쳤을 때 잘 대처할 수 있는 방향성을 알려 준다.

추가로 원서에 없는 삼성전자, AWS 코리아, GroundX 등 국내 대기업에서 활동 중인 현업자들의 이야기까지 담았다.

 

(한빛미디어) 개발 7년차, 매니저 1일차_상세이미지(700px).jpg

 

 

저자

카미유 푸르니에

패션계의 넷플릭스로 불리는 의류 대여 회사, 렌트더런웨이(Rent the Runway)의 전 CTO이다. 저자는 과감하고 결단력 있는 리더십으로 렌트더런웨이에서 '망치(The Hammer)'라고 불리었다. 분산된 시스템과 엔지니어링 리더십, 이와 관련된 컨퍼런스와 소프트웨어 개발자 이야기 등 많은 글을 자신의 블로그 'Elided Branches(www.elidedbranches.com)'에 올렸다.

역자

한민주

삼성전자 무선사업부에서 개발자로, 유엔난민기구에서 디지털 담당자로, 웹 개발 프로젝트 매니저로 일했다. 서로의 전문성과 다양성을 존중하는 문화를 함께 만들어 나가고자 한다. 순수한 호기심이 가득하고 서로의 지식과 경험을 기꺼이 나누는 개발자 문화를 사랑한다.

 

역자

권원상

웹 사이트, 교육용 컨텐츠 개발에서 시작해서 디지털 아카이브, 홈네트워킹, 임베디드 시스템 등 다양한 분야에서 개발자로 일했다. 최근에는 조직 개발, 리더 코칭 등에 관심을 가지고 회사에서 애자일 코치로 일하고 있다. 우리나라에 구성원들이 더 건강하고 효과적으로 일할 수 있는 조직이 많아지기를 바라며 이에 기여하려고 노력 중이다.

감사의 말

옮긴이의 말

한국 독자에게

지은이의 말

이 책을 읽는 방법

 

1장 IT 관리 101

매니저에게 기대하는 것

CTO에게 묻는다 : CTO가 되려면 무엇을 해야 하나요?

‘관리되는’ 방법

자신의 경험 평가하기

 

2장 멘토링

주니어 팀원 멘토링의 중요성

멘토 되기

CTO에게 묻는다 : 인턴 멘토링은 어떻게 하나요?

좋은 매니저, 나쁜 매니저 : 알파 긱

멘토의 매니저를 위한 팁

CTO에게 묻는다 : 인턴 채용할 때 무엇을 고려해야 하나요?

멘토를 위한 핵심 요약

자신의 경험 평가하기

 

3장 테크리드

테크리드 되기

모든 훌륭한 테크리드가 아는 한 가지 비결

테크리드의 기본 역할

CTO에게 묻는다 : 테크리드는 끔찍한 자리인가요?

복잡한 프로젝트 관리하기

설명의 중요성

프로젝트 관리에 도움 되는 가이드라인

CTO에게 묻는다 : 테크리드가 되고 싶지 않아요

시니어 개발자로 남을지, 매니저가 될지 선택하기

좋은 매니저, 나쁜 매니저 : 프로세스 독재자

훌륭한 테크리드가 되는 방법

자신의 경험 평가하기

 

기고 : 좋은 매니저는 누구인가_ 임백준

 

4장 사람 관리

새로운 팀원과 관계 맺기

팀과 소통하기

여러 가지 원온원 스타일

좋은 매니저, 나쁜 매니저 : 마이크로매니저, 위임하는 매니저

효율적으로 위임하기 위한 실질적인 조언

지속적으로 피드백하는 문화 만들기

360도 성과 평가하기

CTO에게 묻는다 : 팀원의 잠재성은 어떻게 찾나요?

승진 게임 익히기

도전 상황 : 성과가 낮은 사람 해고하기

CTO에게 묻는다 : 성장하지 않는 직원을 어떻게 해야 하나요?

자신의 경험 평가하기

 

5장 팀 관리

한 사람의 매니저 되기

기술 역량 유지하기

문제 있는 팀을 디버깅하기

CTO에게 묻는다 : 동료였던 팀원을 관리하게 되었어요!

바람직한 방패막이 역할

좋은 의사 결정을 내리는 방법

좋은 매니저, 나쁜 매니저 : 갈등 회피자, 갈등 조정자

도전 상황 : 팀 결속력 파괴자

프로젝트 일정 관리 방법

CTO에게 묻는다 : 작은 팀 매니저가 되면 무엇부터 해야 하나요?

자신의 경험 평가하기

 

6장 여러 팀 관리

CTO에게 묻는다 : 코드가 그리워요!

시간의 우선순위 정하는 방법

매니저가 되기 위한 가장 어렵고도 가장 짧은 수업

업무 위임 노하우

CTO에게 묻는다 : 팀이 위기에 빠지기 전에 알아차릴 수 없을까요?

도전 상황 : 거절 전략

CTO에게 묻는다 : 테크리드가 관리를 하지 않습니다

코드 그 이상의 기술 요소

개발 팀 운영의 건강도 확인 법

좋은 매니저, 나쁜 매니저 : 우리 대 상대, 팀 플레이어

게으름과 성급함의 장점

자신의 경험 평가하기

 

기고 : 매니저직은 개발자의 무덤인가_ 정도현

 

7장 매니저 관리

CTO에게 묻는다 : 오픈도어 정책에 실패했어요!

스킵 레벨 미팅 진행하기

매니저에게 책임 일깨우는 법

좋은 매니저, 나쁜 매니저 : 사람들의 기분을 살피는 사람

신입 매니저 관리하기

숙련된 매니저 관리하기

매니저 채용 시 고려할 점

CTO에게 묻는다 : 해본 적이 없는 팀을 맡게 되었어요!

제대로 작동하지 않는 조직을 디버깅하기

예측치 설정하기와 스케줄에 맞게 진행하기

도전 상황 : 불확실한 로드맵 다루기

나의 기술 능력을 유지하는 법

자신의 경험 평가하기

 

8장 빅 리그

자신의 업무를 대하는 바람직한 자세

개발 시니어 리더십에 대한 모델

개발 부사장의 역할

CTO가 하는 일

CTO에게 묻는다 : CTO와 개발 부사장의 차이는 무엇인가요?

우선순위 변경 시 유의할 점

기술 전략 수집 노하우

도전 상황 : 나쁜 뉴스 전하기

CTO에게 묻는다 : 개발 비전공 상사와 일하는 것이 힘들어요!

다른 역할의 시니어 동료들과 잘 지내는 법

나를 팀에서 분리하기

두려움으로 지배하고, 신뢰로 이끌기

최고 책임자가 지켜야 할 업무 원칙

추천 도서

자신의 경험 평가하기

 

9장 문화 개선

회사 구조 파악하기

문화 만들기

핵심 가치 적용하기

문화 정책 만들기

경력 경로 작성하기

다기능 팀의 장점

개발 프로세스 적용하기

CTO에게 묻는다 : 한 번에 여러 프로세스를 도입해도 될까요?

의사결정을 객관적으로 하는 법

자신의 경험 평가하기

 

기고 : 뉴비 프로젝트 매니저를 위한 이야기 한 조각_ 배상언

 

10장 결론

나 자신부터 관리하기

 

찾아보기

  • 소개

    이번에 리뷰하게될 이 책은 Camille Fournier의 The Manager’s Path 번역서인 개발 7년차, 매니저 1일차이다.

    Camille Fournier는 MS 개발자를 시작으로 다양한 경험을 쌓은 CTO로 컨퍼런스를 통해 이러한 주제에 대한 스피커를 자주 맡고 있다.

    사실 원서와는 다르게 제목부터 특이했고 여러 챕터에 있는 사례조차 굉장히 자극적이면서도 흥미로워 관심이 있었다.

    한빛의 리뷰어를 통해 운 좋게 책을 읽어볼 수 있게 되었다.

    흥미로운 사례 제시

    관리 측면에 대한 경험과 스토리텔링이 녹아져있다.

    멘토링, 테크 리딩, 사람, 팀, 다수의 팀, 매니저 등등 다양한 관리를 통해 문화를 개선하고

    결론적으로는 나 자신을 관리해야 한다는 통찰의 시점으로 가는 로드맵에 대한 흐름으로 읽힌다.

    이 와중에 시니어 개발자로 남을지, 매니저가 될지 선택하기좋은 매니저, 나쁜 매니저 : 프로세스 독재자도전 상황 : 성과가 낮은 사람 해고하기

    같은 자극적인 챕터가 소소하게 있어 읽는 내내 흥미로운 부분이 있었다.

    가끔 소제목에 비해 내용이 자극적이지 않아 김이 빠지는 경향도 있었으나 충분히 가치 있는 이야기였다.

    예비 팀장보다는 우리 모두를 위한 관리 기술

    팀장으로 성장하는 내용을 주로 다루는 그런 내용이지만

    결국은 팀장이 아닌 반대 입장으로 읽을 수 있기 때문에 공감되는 내용이 많이 있었다.

    제목과 내용의 흐름이 팀장에 초점을 맞추고 있더라도 충분히 볼거리 많을 수밖에 없는 이유이기도 했다.

    팀장이 왜 그렇게 행동할 수밖에 없었는지 팀장도 어쩌면 결국 같은 팀원이구나 하며

    내가 팀장이라면 나는 어떻게 했을까라는 가정도 가능했다.

    재미요소

    책의 중간중간

    • CTO에게 묻는다
    • 좋은 매니저, 나쁜 매니저,
    • 자신의 경험 평가하기,
    • 도전 상황

    위와 같은 코너를 통해 사례에 대한 액션 플랜과 액션 아이템을 제시하고 있어 깊이 고민할 시간을 가지며 자아성찰을 하게 된다.

    결론

    정년이 길어지는 동시에 인구와 고용은 감소하고 있다.

    이런 상황에 개발자로서의 길을 계속 걸으며 많은 일과 수많은 고난을 겪게 될 것이다.

    어쩌면 팀장이 되기 싫을 수 있을 수 있고 팀장이 되고 싶지만 될 수 없을 수도 있다.

    국내 IT 상황과 100% 일치하지는 않지만 다양한 사례에 대한 액션을 많이 담고 있기 때문에

    어려운 순간이나 슬럼프가 왔을 때 좋은 인생 멘토의 경험이라 생각하고 두고두고 펴볼 수 있을 것 같다.

  • "개발 7년차, 매니저 1일차"는 한빛미디어 리뷰 이벤트 덕분에 받아보게 된 매니저에 대한 책이다. 이 책이 굉장히 흥미로운 점은 개발자가 매니저 역할로 돌아서면서 심리적으로 두려워하는 부분, 우려하는 포인트 그리고 역할 등에 대해서 잘 표현하고 있다는 점이다. 가령 매니저가 정말 개발자의 무덤인지, 팀을 위해 무엇을 해야 하는지, 갈등은 어떻게 해소해야 하는지와 같은 이야기가 잔뜩 실려있다.

    일단 책 제목이 재밌다. 개발 7년 차에 매니저 시작이라니. 그런데 곰곰이 생각해보면 정말 재미있는 표현이다. 우리 주변에 매니저 역할을 수행하는 사람의 연차를 돌이켜보거나 개발자가 진로에 대한 깊은 고민에 빠지는 시기가 아니던가. 제목부터 센스가 돋보이는 이 책을 소개한다.

    이 책은 당연한 이야기들이 교과서처럼 쓰여있지만 그럼에도 많은 사람들에게 추천할 만한 책이다. 매니저 역할을 수행하게 되는 사람뿐만 아니라 개발자가 읽기에도 재미있다. 우리 팀, 혹은 매니저, 과거의 경험들과 비교하면서 읽어보면 더욱 재밌다. 이 책은 번역서지만 우리나라 정서에도 꽤 잘 맞는다. 특히 중간에 기고되어 있는 글은 이 책을 더욱 훌륭하게 만들어준다.

    - 기고 : 좋은 매니저는 누구인가_ 임백준
    - 기고 : 매니저직은 개발자의 무덤인가_ 정도현
    - 기고 : 뉴비 프로젝트 매니저를 위한 이야기 한 조각_ 배상언

    위에 기고 내용만 보더라도 매니저를 너무 잘 표현하고 있다. 책을 다 읽고 표지를 덮고 나서 생각해보니 기고들은 마치 이 책의 요약본 같은 느낌이었다. 그리고 나는 운 좋게 주변에 좋은 매니저가 많았고 그들을 통해서 가치관까지 영향을 받았으니 매니저는 단순히 사람을 관리하는 역할만 있는 것은 아니겠다. 한편 과거에 매니저 역할을 수행하면서 받았던 다양한 스트레스 상황이 이 책에 잘 녹아있어서 나를 돌아보는 계기까지 되었으니 이 얼마나 좋은 책인가 :-) 

    요즘처럼 소프트웨어 직군이 다양하게 나뉘어져 있는 시대에 매니저는 어쩌면 슈퍼맨이 되어야 할지도 모른다. 모든 직군의 테크니컬 한 부분을 이해할 수 없음에도 이를 인정하고 팀은 케어하고 앞으로 나아갈 수 있어야 하니까. 조금 거창하지만 현대를 살고 있는 매니저들에게 깊은 존경을 표하고 매니저를 필두로 좋은 기업이 넘쳐나는 대한민국이 되기를 바라본다.

  •  

    제목을 정말 잘 지었다. 개발자로서 경력을 쌓다가 관리직에 첫 발을 들여놓은 사람을 위한 책이다. 

     

    [1장 IT 관리 101]

     

    101은 미국 대학교에서 어떤 코스의 첫단계를 뜻하는 수업 번호이다. IT 관리의 시작점을 의미하는 장이다. 일대일미팅에서는 매니저 뿐만 아니라, 팀원도 주제를 고르고 시간과 장소를 정해서 미팅을 만드는 책임을 함께 나눠지는 것이 좋다는 걸 처음 알게 되었다. 

     

    [2장 멘토링]

     

    여기서 묘사하는 알파 긱(Alpha geek)은 꼭 개발자가 아니더라도 회사에서 한 명쯤 있는 상사를 그대로 그려놓은 것 같다. 

     

    "알파 긱(Alpha geek)은 팀에서 인정받은 최고의 개발자로, 늘 정답을 말하며 어떤 어려운 문제도 풀어내는 사람이다. 지적이고 기술력에 최고의 가치를 두며, 실력이 의사결정에 영향을 미쳐야 한다고 믿는다. 그런데 이들은 대개 다른 의견에 대처하지 못하며, 자기가 받아야할 관심을 빼앗는 사람이나 자기를 능가하는 사람을 만나면 쉽게 위축된다. 알파 긱은 자신이 최고라고 믿으며 이에 동조하는 말에만 반응한다. 한마디로 이들은 뭐든 뛰어나야 하는 '탁월함의 문화'를 만들려고 하지만 결국에는 '두려움의 문화'를 만드는 경향이 있다."

     

    [3장 테크리드]

     

    우리나라에서 흔히 '개발팀장'이란 단어로 통칭하는 역할이 테크리드와 비슷하다. 순수한 관리자(매니저)가 아니면서도 순수한 개발자(엔지니어)도 아닌, 보다 무거운 책임을 지는 단계이다. 개발 외길만 걸어온 사람들이 처음 맡았을 때 가장 힘들어하는  역할이기도 하다. 내용 중에는 '시니어 개발자의 이상적인 생활' vs '시니어 개발자의 실제 생활', '매니저의 이상적인 생활' vs '매니저의 실제 생활' 부분이 심히 웃기면서도 공감이 갔다. 

     

    [4장 사람 관리]

     

    새로운 팀원과 관계 맺기부터 시작해서 팀과 소통하기, 일대일 미팅의 기법 등 다양한 방법으로 사람을 관리하는 내용이 나온다. 제목이 사람 관리이지만, 실제로 누군가를 쥐어짜서 원하는 형태로 만들어 간다는 자세가 아니라, 상호 소통과 그리고 문제 해결기법에 중점을 두고 있다. 

     

     

    [5장 팀 관리]

     

    동료였던 팀원이 내 관리대상이 되는 건 정말 어색한 일이다. 그리고 신임 팀장에게는 좋은 의사 결정을 내리는 방법과 프로젝트 일정 관리 방법을 비롯해서 익혀야 할 일들이 산더미 처럼 많다. 무엇보다도, 세세한 것 하나까지 사사건건 간섭하는 마이크로매니저는 되지 말자고 다시 다짐하게 됐다. 

     

    [6장 여러 팀 관리]

     

    여러 팀을 관리한다는 것은 다수의 개발팀장을 관리하게 된다는 의미이다. 이 역할은 엔지니어링 디렉터라고 칭해지는 경우가 많다. 그리고 더 이상 코드를 짜고 있지 않을 것이다. (정확히는 코드를 짤 시간이 없다.) 이 위치에서는 조직의 전반적인 기술 역량을 책임지고, 필요한 경우 교육과 채용을 통해 전체 팀의 역량을 이끌고 성장시키는 역할을 해야한다. 이 장은 맨 뒤의 "기고: 매니저직은 개발자의 무덤인가_ 정도현" 부분이 제일 인상적이었다. 나도 매니저는 꼭 필요한 역할이지만 개발자보다 이직이 많이 불리하다고 생각해왔기 때문이다.

     

    [7장 매니저 관리]

     

    매니저의 매니저이다. 이제부터는 자신이 전문성을 갖지 못한 일까지 관리해야한다. 세부사항을 알 수 없을 때에도 의사결정을 하는 방법을 익혀야 하다니, 생각만해도 머리가 아프다. 그래도 책에 나온 방법대로 매니저에게 책임 일깨우는 법, 신입 매니저 관리하기, 숙련된 매니저 관리하기 등을 익힌다면 좀 나을지도 모르겠다.

     

    [8장 빅 리그]

     

    기술 시니어 매니저, CTO, 부사장 등의 위치는 명실상부한 리더 자리이다. 회사가 무엇을 해야 하는지, 어디로 가야 하는지, 어떻게 행동해야 하는지, 어떻게 생각해야 하는지, 무엇을 소중히 여겨야 하는지를 알고, 또 전파해야 한다. 그로 인해서 사람과 문화와 기술을 모두 이끌어 나가야 한다. 생각만해도 얼마나 어려울지 끔찍하다. 

     

    [9장 문화 개선]

     

    회사 구조를 파악해서 명확하고 신중한 개발팀 문화를 만들어야 한다. 중요한 인프라에 신경을 쓰는 것만큼 팀 문화에도 신경을 써야한다. 정말로 뛰어난 기업들은 그들의 기술보다도 그들의 문화로 인해 더 널리 알려졌다는 걸 되새겨본다.

     

    [10장 결론]

     

    나 자신부터 관리하기. 다른 사람들을 잘 관리하기 위해서는 나 자신을 먼저 관리할 수 있어야 한다. 자신이 반응하는 방법, 영감을 주는 일, 자신을 미치게 만드는 일에 대해 이해하기 위한 시간이 필요하다. 동시에 상황을 다른 사람의 시각으로 객관적으로 살펴보는 것도 중요하다. '사람들은 무엇을 하려는 것일까? 사람들은 무엇을 중요시할까? 사람들은 무엇을 원할까?' 등에 대해 언제나 호기심을 가지고 관찰해야 한다. 

     

    [후기]

     

    이 책은 내게 많은 조언과 고민거리를 동시에 안겨줬다. 읽는 내내 이전에 했던 관리적인 실수가 떠올라서 얼굴이 화끈화끈해졌다. 시니어 개발자를 벗어나는 사다리의 첫 시작점부터 CTO 이상까지 모든 커리어 패스에 적용되는 내용이기 때문에, 나이를 먹고 직장생활의 연륜이 깊어질수록 두고두고 다시 펴서 참고할 수 있는 책이다. 

     

    [단점]

     

    P.S. 아쉽게도 편집 실수가 약간 있다. 본문 중 저자 외에 다른 사람이 작성한 컬럼이 군데군데 삽입되어 있는데, 원서는 박스로 별도 표기되었지만, 번역서에는 컬럼도 저자가 작성한 본문과 구분되지 않게 동일한 스타일로 편집되었다. 그래서 책을 읽다보면 문단 끝에 갑자기 엉뚱한 사람 이름이 붙어있는 경우가 있는데, 이럴 때는 조금 당황스러웠다. 

     

  • 시간이 지남에 따라 세상은 복잡해져 간다. 복잡한 세상의 다양한 수요를 충족하기 위해 소프트웨어도 점점 복잡해진다. 이러한 복잡한 소프트웨어나 IT 서비스를 개발하기 위해서는 다양한 사람들의 협업이 필수인 시대가 된 것이다. 지금 개발자의 경력을 쌓고 있는 당신도 언젠가는 누군가, 혹은 특정 조직을 관리할 필요가 생길 수 있다는 의미다.

     

    본인은 관계없다고 생각할 수 있지만 우리는 이미 회사 내에서 관리를 받거나 관리하는 입장에 놓여 있다.

    - 신입 사원 멘토링을 하는 사수

    - 테크 리드

    - 팀 관리자

    - 다수의 팀을 관리하는 관리자

    - CTO

     

    이 책의 내용을 요약하자면 

    - 각 직책별 관리자의 역할과 책임 설명

    - 관리자로써 만날 수 있는 다양한 상황 제시 및 올바른 해결 방안 설명

    - 잘못된 방법과 올바른 방법의 비교 설명을 통해 관리자가 흔히 빠질 수 있는 실수 설명

     

    비록 현재 자신이 관리자가 아니더라도 이 책의 내용은 회사 생활에 많은 도움이 될 수 있다. 현재 자신의 상사 입장에서 프로젝트나 조직을 바라볼 수 있는 넓은 안목을 가질 수 있다. 이는 당신이 회사에서 인정 받고, 승진하고 더욱 중요한 역할을 차지하기 위한 필수 요소이다.

     

    이 책에서 아쉬운 점이 있다면 읽어도 잘 이해가 되지 않는 문장이 종종 보인다는 점이다. 주어와 동사 관계가 어색하기도 하고, 주어가 생략된 경우에는 매니저가 주어인지 팀원이 주어인지 모호한 경우도 가끔 있었다. 원서의 내용이 그런 것인지 번역하는 과정에서 발생한 문제인지는 잘 모르겠지만 이 부분은 약간 아쉬움이 남는다.

     

    하지만 이 점만 제외하면 내용은 무난하다고 생각하며 관리자 업무를 맡아야 하거나 개발자와 관리자를 선택해야 하는 갈림길에 서 있는 사람들이라면 참고하기에 좋은 책이다. 그리고 마지막으로 효율적 개발 관리를 위한 수많은 프로세스와 기술이 존재하지만 결국 관리의 주체는 사람이고 사람 간의 의사 소통이 가장 중요한 핵심이 아닐까 생각한다. 지금까지 너무 코딩에 집중한 나머지 팀원들과의 의사 소통에 조금이나마 소홀하지 않았나 반성해본다.

  • 책 소개


    경력이 쌓이면 누구나 겪게 될

    ‘개발 관리’의 모든 것을 한 권에!

    • 사수, 멘토, 팀장, CTO까지 직책별 관리 기술 대백과
    • 개발자도 꼭 알아야 하는 소프트 스킬, 사람 및 조직 관리 노하우 수록
    • 개발 팀을 성공으로 이끄는 IT 팀장에 대한 모든 것

     

    대다수 사람들은 조직에 들어가고 ‘관리받게’ 된다. 하지만 경력이 쌓일수록 ‘관리하게 되는’ 비중이 늘어난다. 따라서 개발자가 매니저로 전향하는 순간이 오는 건 피할 수 없다. 이 책은 매니저로 성장하면서 겪는 여러 문제를 구체적인 사례를 통해 보여 주고, 이를 극복할 수 있는 실질적인 조언을 담았다. 개발자에서 테크리드로, 팀장으로, 여러 팀을 관리하는 CTO로 성장하며 겪게 되는 다양한 시나리오와 각 직책별 좋은 매니저의 모습을 알려 준다. 또한, 소프트 스킬이 부족한 사수를 둔 개발자를 위해 사수에게 어떤 도움을 받을 수 있는지에 대한 구체적인 내용도 담았다.

     

     

    이런 분들 주목!

    • 개발자 vs 매니저 갈림길에 서 있다.
    • 개발 관리를 체계적, 효율적으로 하고 싶다.
    • 내 사수가 사수 역할을 못해서 내가 고생 중이다.

     

    이 책을 주목해야 하는 이유!

    첫째, 아마존 베스트셀러 『The Manager’s Path』의 한국어판! 현재 아마존 ‘엔지니어링/기술 프로젝트 관리’ 분야 베스트셀러이다.

    둘째, 멘토로 시작하여 시니어 리더십에 이르기까지 각 직급에서 알아두어야 할 관리 기술을 모두 담았다. 개발자라면 한 권은 구비해 두고 경력 ‘레벨업’ 할 때마다 꺼내 읽어야 하는 바이블 같은 도서이다. 

    셋째, 개발 관리에서 겪게 될 여러 문제를 사례를 통해 보여주고, 실질적인 조언을 제시했다. ‘개발자’라는 환경에서 겪는 특수한 상황들을 들려줌으로써, 비슷한 상황이 닥쳤을 때 잘 대처할 수 있는 방향성을 알려 준다.

    추가로 원서에 없는 삼성전자, AWS 코리아, GroundX 등 국내 대기업에서 활동 중인 현업자들의 이야기까지 담았다.

     

    자세한 내용 : https://www.hanbit.co.kr/store/books/look.php?p_code=B3838365362

     

     

    개발 7년차, 매니저 1일차

    대다수 사람들은 조직에 들어가고 ‘관리받게’ 된다. 하지만 경력이 쌓일수록 ‘관리하게 되는’ 비중이 늘어난다. 따라서 개발자가 매니저로 전향하는 순간이 오는 건 피할 수 없다. 이 책은 매니저로 성장하면서 겪는 여러 문제를 구체적인 사례를 통해 보여 주고, 이를 극복할 수 있는 실질적인 조언을 담았다.

    www.hanbit.co.kr

     

    목차


    감사의 말

    옮긴이의 말

    한국 독자에게

    지은이의 말

    이 책을 읽는 방법


    1장 IT 관리 101

    매니저에게 기대하는 것

    CTO에게 묻는다 : CTO가 되려면 무엇을 해야 하나요?

    ‘관리되는’ 방법

    자신의 경험 평가하기


    2장 멘토링

    주니어 팀원 멘토링의 중요성

    멘토 되기

    CTO에게 묻는다 : 인턴 멘토링은 어떻게 하나요?

    좋은 매니저, 나쁜 매니저 : 알파 긱

    멘토의 매니저를 위한 팁

    CTO에게 묻는다 : 인턴 채용할 때 무엇을 고려해야 하나요?

    멘토를 위한 핵심 요약

    자신의 경험 평가하기


    3장 테크리드

    테크리드 되기

    모든 훌륭한 테크리드가 아는 한 가지 비결

    테크리드의 기본 역할

    CTO에게 묻는다 : 테크리드는 끔찍한 자리인가요?

    복잡한 프로젝트 관리하기

    설명의 중요성

    프로젝트 관리에 도움 되는 가이드라인

    CTO에게 묻는다 : 테크리드가 되고 싶지 않아요

    시니어 개발자로 남을지, 매니저가 될지 선택하기

    좋은 매니저, 나쁜 매니저 : 프로세스 독재자

    훌륭한 테크리드가 되는 방법

    자신의 경험 평가하기


    기고 : 좋은 매니저는 누구인가_ 임백준


    4장 사람 관리

    새로운 팀원과 관계 맺기

    팀과 소통하기

    여러 가지 원온원 스타일

    좋은 매니저, 나쁜 매니저 : 마이크로매니저, 위임하는 매니저

    효율적으로 위임하기 위한 실질적인 조언

    지속적으로 피드백하는 문화 만들기

    360도 성과 평가하기

    CTO에게 묻는다 : 팀원의 잠재성은 어떻게 찾나요?

    승진 게임 익히기

    도전 상황 : 성과가 낮은 사람 해고하기

    CTO에게 묻는다 : 성장하지 않는 직원을 어떻게 해야 하나요?

    자신의 경험 평가하기


    5장 팀 관리

    한 사람의 매니저 되기

    기술 역량 유지하기

    문제 있는 팀을 디버깅하기

    CTO에게 묻는다 : 동료였던 팀원을 관리하게 되었어요!

    바람직한 방패막이 역할

    좋은 의사 결정을 내리는 방법

    좋은 매니저, 나쁜 매니저 : 갈등 회피자, 갈등 조정자

    도전 상황 : 팀 결속력 파괴자

    프로젝트 일정 관리 방법

    CTO에게 묻는다 : 작은 팀 매니저가 되면 무엇부터 해야 하나요?

    자신의 경험 평가하기


    6장 여러 팀 관리

    CTO에게 묻는다 : 코드가 그리워요!

    시간의 우선순위 정하는 방법

    매니저가 되기 위한 가장 어렵고도 가장 짧은 수업

    업무 위임 노하우

    CTO에게 묻는다 : 팀이 위기에 빠지기 전에 알아차릴 수 없을까요?

    도전 상황 : 거절 전략

    CTO에게 묻는다 : 테크리드가 관리를 하지 않습니다

    코드 그 이상의 기술 요소

    개발 팀 운영의 건강도 확인 법

    좋은 매니저, 나쁜 매니저 : 우리 대 상대, 팀 플레이어

    게으름과 성급함의 장점

    자신의 경험 평가하기


    기고 : 매니저직은 개발자의 무덤인가_ 정도현


    7장 매니저 관리

    CTO에게 묻는다 : 오픈도어 정책에 실패했어요!

    스킵 레벨 미팅 진행하기

    매니저에게 책임 일깨우는 법

    좋은 매니저, 나쁜 매니저 : 사람들의 기분을 살피는 사람

    신입 매니저 관리하기

    숙련된 매니저 관리하기

    매니저 채용 시 고려할 점

    CTO에게 묻는다 : 해본 적이 없는 팀을 맡게 되었어요!

    제대로 작동하지 않는 조직을 디버깅하기

    예측치 설정하기와 스케줄에 맞게 진행하기

    도전 상황 : 불확실한 로드맵 다루기

    나의 기술 능력을 유지하는 법

    자신의 경험 평가하기


    8장 빅 리그

    자신의 업무를 대하는 바람직한 자세

    개발 시니어 리더십에 대한 모델

    개발 부사장의 역할

    CTO가 하는 일

    CTO에게 묻는다 : CTO와 개발 부사장의 차이는 무엇인가요?

    우선순위 변경 시 유의할 점

    기술 전략 수집 노하우

    도전 상황 : 나쁜 뉴스 전하기

    CTO에게 묻는다 : 개발 비전공 상사와 일하는 것이 힘들어요!

    다른 역할의 시니어 동료들과 잘 지내는 법

    나를 팀에서 분리하기

    두려움으로 지배하고, 신뢰로 이끌기

    최고 책임자가 지켜야 할 업무 원칙

    추천 도서

    자신의 경험 평가하기


    9장 문화 개선

    회사 구조 파악하기

    문화 만들기

    핵심 가치 적용하기

    문화 정책 만들기

    경력 경로 작성하기

    다기능 팀의 장점

    개발 프로세스 적용하기

    CTO에게 묻는다 : 한 번에 여러 프로세스를 도입해도 될까요?

    의사결정을 객관적으로 하는 법

    자신의 경험 평가하기


    기고 : 뉴비 프로젝트 매니저를 위한 이야기 한 조각_ 배상언


    10장 결론

    나 자신부터 관리하기


    찾아보기

    책을 읽으며


     

    이번에 리뷰하게 된 책은 한빛미디어의 개발 7년차, 매니저 1일차 입니다.

    이 책을 받기까지 해프닝이 하나 있었습니다. 개발 관련 서적을 받아야하는데 택배를 뜯어보니

    이런 책이 배송되어 있어서 굉장히 놀랐습니다. 놀란 마음으로 담당자분께 연락드렸더니 책을 다시 보내주셔서 받은 책이었습니다. OREILLY 책인데도 불구하고 동물 사진이 아니라서 다소 어색한 책이긴 합니다.

     

    개발자로 일하다보면 어느순간 매니저 역할을 할때가 많습니다. 신입사원이라던지 인턴이라던지. 어떻게 하면 잘 할 수 있을까를 항상 고민하던 저에게 좋은 책이었습니다.

     

    책 내용 중 와닿는 내용에는 '팀원이 매니저에게 기대하는 것은 피드백이다.' 라는 부분입니다. 제가 매니저에게 미팅을 요청했을 때 매니저로부터 피드백을 받기 위해 요청하는 경우가 많았기 때문에 기억에 남았고 체크해두었습니다. 책에서는 이런 내용들을 많이 다루고 있습니다. 팀원이 매니저에게 바라는 것, 매니저가 팀원에게 해줄 수 있는 부분에 대한 내용. 매니저라는 것이 강제가 되서는 안된다 등 매니저에 대한 내용을 볼 수 있습니다. 

     

    미팅도 그렇지만, 원앤원 미팅에는 팀원과 매니저 사이의 인간적인 연결 이라는 것을 강조합니다. 그도 그렇듯, 매니저도 사람이고 팀원도 사람이기 때문에 상호간의 인간적인 대화랑 연결이 참 중요하다고 생각합니다. 전에 있던 직장에서는 매니저와의 미팅을 거의 할 수 없었지만 현 직장은 매니저와의 대화를 통해 업무를 조율하고 컨디션을 조율할 수 있었습니다. 그렇다보니 일에 있어서 자신감도 생기고 시간 관리도 할 수 있는 근무환경에서 근무 중에 있고, 매니저가 필요한 이유를 알 수 있는 경험이었습니다.

     

     

    제가 주의 깊게 봤던 문장은 '뛰어난 개발자가 주니어 팀원에게는 훌륭한 멘토일 수 있지만, 시니어 개발자에게는 그저 자기 주장만 강한 변호형 일지도 모른다.' 라는 문자이었습니다. 많은 것을 알고 있는 개발자는 좋은 멘토 역할을 할 수 있지만 시니어 개발자와의 충돌이 생길 수도 있고, 자기 주장만 강한 사람이 될 수도 있다는 문장이 마음에 와닿습니다. 개발을 하다보면 아는 내용만 맞다라고 생각 될 때가 있고 그러한 생각을 항상 조심해야 한다는 생각을 하는데 그런 부분들을 잘 짚어주는 책이라 좋았습니다.

     

    마지막 장에는 가장 중요한 문화를 개선해야하는 내용이 나옵니다. 맞습니다. 문화가 개선되지 않으면 좋은 매니저가 있더라도 그런 문화가 좋게 보이지 않는 회사라면 매니저의 역할을 할 수 없다. 반대로 좋은 문화가 자리잡혀 있다면 그 속에서 좋은 매니저가 나오기는 쉬울 수 있다고 생각한다. 그런 부분에서 내 자신과 내가 일하고 있는 회사를 돌아보게 해주는 좋은 책이다.

  •  

    개발 7년차, 매니저 1일차. 이 책은 '개발' 조직에서의 매니저의 역할을 얘기한다. 멘토링 부터 시작해서, 테크리드, 사람 관리, 팀 관리, 여러 팀 관리, 매니저 관리, 문화 개선까지-

    표지와 제목에서도 느낄 수 있듯이 가볍게 읽어볼수있는 책이다.

    각 챕터별로 CTO에게 묻는다 라는 코너가 있는데, 실제 내가 궁금해 하는 부분을 정확히 콕 찝어주었다.

    '테크리드가 되고 싶지 않아요', '성장하지 않는 직원을 어떻게 해야 하나요?'

    또, 시니어 개발자, 매니저의 이상적인 생활과 실제 생활 비교 부분은 재밌기도 하고 공감가기도 한 웃픈 내용이였다.

     

    나같이 당장 '매니저'에 관심 없는 사람에게도 도움이 될만한 부분이 많았다. 연차가 쌓이면 주니어 팀원분들과 함께 일하게 되면서 매니징은 아니더라도 멘토의 역할을 하게 될 수도 있고, 꼭 매니저는 아니더라도 테크리드의 역할을 하게 될 수도 있으니-

    (사실 이책을 읽기 전 까진 테크리드가 정확히 뭔지도 잘 몰랐다.)

     

    또, 결국은 '나 자신부터 관리하기' 라는 결론으로 나를 되돌아 볼 수도 있었다.

  •  

    20204, 두번째 [나는 리뷰어다]. 이번에는책이 너무 늦게 와서 다른 일정이 바쁜 탓에 급하게 쓰는 감이 있다. 추후에 브런치 같은 곳에 업로드하게된다면 퇴고하는 걸로. :-(

     

    결론적으로 좋은 매니저가 되는 방법은, 서로 잘 소통하는 것이라고책은 말하고 있다.

    개발은 팀 프로젝트만 해 본 나이지만, 책에서 말하는 부분이 공감가는게 몇 있었다. 팀원이 아무리 적더라도 의견 차이와 갈등은 생기기 마련이더라. 그 부분을 잘 조율하고 일정관리를 잘 하는 것이 좋은 결과물을 내는 것에 가장 중요한 법이다.

     

    사적인 얘기지만, 소프트웨어 개발자를 지망하고 공부함에 있어 무엇보다중요한 역량은 협업 능력이라고 생각한다. 사실 어떤 직종이든누군가와함께 일하기는 필수적인 능력이긴 하다. 하지만 그 중에서도 Git, Slack 등 협업 툴이 기본인 개발 직종이기에 더 중요한 느낌이 드는 것이다. 그동안 협업을 할 기회가 많이 없어서 아쉬웠는데 이번에 NaverHackday를 진행하게 되면서 Gitflow를 사용하며 협업할 기회를 갖게 되어 열심히하면서 많이 배울 생각이다.

     

    2018년 통계에 의하면 지구상 최초로 합계출산율이 0.98명이 된 놀라운 나라 대한민국에서, 취준생으로 2020년을 맞이하게 되어 정말... 여러 가지 생각이 든다. 사실 이번 해에는 유럽 여행을 가려고 생각하고 있었기에 돈을 7~8백정도 모아 두었었다. 그런데 COVID19가 터져버렸고... 계획하던 1달 반의 유럽여행은 포기하고 학자금을 갚는 것에 값지게쓰였다. 어떻게 보면 여행을 못 가게 되어 취준을 본격적으로 시작하게 된 느낌도 있다. 여러모로 답답한 상황이긴 하지만 부디 각자의 자리에서 노력하고 취뽀하기를.

     

    미국 회사에서 근무한 사람이 쓴 책이기도 하고, 돈을 받으며 일해본 경험이 없어서 그런지 책에 관해서는 쓸 내용이 많이 부족했다. 내 주저리가 많이 담긴 똥글이 탄생해버렸지만 나같은 고민을 하는 사람이 꽤나 있을 테니 이 글을 읽는다면 한 줌의 위로가 되었기를.

     

  •  

    개발만 하던 내가 어느 날 갑자기 "팀"을 맡게 되었다!!


    헉, 갑자기 숨이 막혀 온다.. 나역시도 개발자 7년차인데 지금이야 팀원으로서 맡은것만 잘 수행하면 되는데 갑자기 팀을 이끌게 된다면... 머리가 아파오기 시작한다.

     


    내 위에 팀장님은 개발은 안하는것 같고 온갖 회의와 문서작업만 하고 밑에 팀원들 관리하느라 오늘도 에너지 드링크를 열나 흡입하고 계신다... 그만큼 중압감이 장난 아닐것 같다.

      


    이번에 리뷰하게 될 책은 "개발 7년차, 매니저 1일차" 라는 책이다

     


    "대다수 사람들은 조직에 들어가게 되면 "관리를 받게" 된다. 하지만 경력이 쌓이고 직급이 올랄수록 "관리하게 되는" 비중이 늘어난다. 개발자가 매니저로 전향하는 순간이 오는것 피할 수 없을 것이다. 하기 싫어도 하게 될것이다. 매니저로 성장하면서 겪는 여러 문제를 구체적인 사례를 통해 보여 주고, 이를 극복 할 수 있는 실질적인 조언을 담았다. 개발자에서 테크리드, 팀장, 여러 팀을 관리하는 CTO로 성장하면서 겪게 되는 다양한 시나리오와 각 직책별 좋은 매니저의 모습을 알려준다. 또한, 소프트 스킬이 부족한 사수를 둔 개발자를 위해 사수에게 어떤 도움을 받을수 있지에 대한 구체적인 내용도 담았다."

     - 옮긴이 -

     

     1장은 매니저를 따르는 방법과 매니저에게 기대 할 수 있는 것이 무엇인지 설명한다.

      - 매니저는 팀원 경력에 지대한 영향을 끼친다. 따라서 취업 기회를 따져 볼때는 직업, 회사, 급여뿐 아니라 실력있는 매니저까지 고래해야 할 것이다.

     2장,3장 매니저가 되는 단계에서 중요한 단계인 멘토링과 테크리드를 설명한다.

      - 개발자는 대개 비공식적으로 관리 관련 업무를 맡는다고 한다. 이를 테면 팀에 합류한 신입 개발자의 멘토가 되면서 관리 관련 업무를 시작하게 된다. 주니어 팀원 멘토링의 중요성과 멘토링을 어떻게 하면 될지 유용한 팁에 대해서 설명한다


    - 3장에서는 테크리드의 역할과 테크리드가 되는 과정에서 소프트웨어 개발자, 시스템 아키텍처, 비즈니스 분석가, 팀 리더로서 직접 할일과 다른 사람에게 위임할 일을 구분할 줄 알아야 한다.  


    4장부터 7장까지는 직원을 관리하는 방법, 팀을 관리하는 방법, 여러 팀을 관리하는 방법, 매니저를 관리하는 방법등을 설명한다.


    8장 에서는 시니어 리더십의 모든 것을 다룬다. 


    9장은 팀문화를 수립하고, 수정하고 향상시키기를 원하는 사람들을 위한 장이다.

     

     각 장별로 매니저의 경험에 따라 읽는 방법을 가이드 해준다. 중간에 "CTO에 묻는다". "좋은 매니저 나쁜 매니저", "도전 상황" 이라는 세가지 코너가 있어 여러 상황에 대한 노하우를 얻을 수 있다.

     

    이 책은 팀의 팀원으로 있는 사람이 봐도 무방할 것이다. 팀장들은 어떤 유형의 사람을 좋아하는지 또 어떤식으로 팀을 관리하고 그 에 대한 팀원의 역할을 무엇인지에 대해서 생각해 볼 수 있다. 


    팀장에게 이쁨 받는 팀원이 되고 싶다면 이 책을 한번쯤 읽어봐도 좋을 것이다.

     

    끝으로 가장 기억에 남는 부분은 " 나 자신부터 관리하기" 이다 


    다른 사람들을 잘 관리하기 위해서는 나 자신을 관리 할 수 있어야 한다는 점이다. 자기 자신, 자신이 반응하는 방법, 자신에게 영감을 주는 일, 자신을 미치게 만드는 일에 대해 이해하기 위한 시간을 가질수록 더 나아질 것이다.

     

  • IMG_2820.jpg

     

    이제 3년차에 접어든 주니어가 과연 읽어도 괜찮은지 의문이 들었지만, 많은 사람의 추천으로 읽게 되었고 많은 인사이트를 얻게 되었다.

    주변의 개발자들과 마찬가지로, 나는 쭉 나이들어서도 개발을 하고 싶고, 때문에 한국 사정상 연차가 쌓일 수록 매니저가 될 수 밖에 없는 숙명에 한탄하며, 해외 이직을 생각하곤 했는데 그런 생각 또한 다시한번 생각하게 되는 계기가 되었다.

     

    매니징을 하는 일이 사람을 다루는 일이다보니 프로젝트 매니저가 된다면 자연히 나의 기술적 지식이나 실력이 떨어질 것이고 그에 따라 내가 매니저를 하지 않고 다시 시니어 개발자로 돌아가고 싶을때 돌아 갈 수 없을것에 대한 두려움이 컸었다. 하지만, 이 책을 읽고 나선 매니징이 단순히 사람들을 이끌고 프로젝트를 이끌어 성공하는게 다가 아니라, 그 안에서 더 많은 기술을 접하고 시야를 넓히며 기술과 실무를 더 적절히 배합 할 수 있는 능력을 기를 수 있다는 것을 알게 되었다. 

     

    최근에 프로젝트를 잠시나마 혼자 맡아서 진행한 적이 있었는데, 리더의 부재가 너무 힘들었었다.

    그와 함께, 나와 같은 일이 일어나지 않도록 좋은 리더가 되기 위해선 어떻게 해야하는지에 대해서 고민하기 시작했는데, 이 책은 이 부분에 대해서도 어느정도 해법을 주는 것같았다. 또한 아직 매니저가 아닌 팀원 입장에서 좋은 팀원이 되기 위해서는 어떻게 해야하는지에 대한 인사이트를 주었다.

     

    매니저가 될 사람 뿐만 아니라, 나같은 주니어, 혹은 IT업에 종사하면서 개발을 하지 않고 프로젝트 매니징을 하는 사람들은 꼭 한번쯤은 읽어 보았으면 하는 책이다.

    이 책을 읽으면서 막연하게 내가 생각했던 편견들을 많이 알게되었는데, 어떠한 사람들이 읽건 각자의 위치에서 각자의 인사이트를 충분히 얻을 수 있는 책이다.

    또한 한번 읽어서 끝날 책이 아니라, 여러번 두고두고 읽으면서 하나의 지침처럼 보아도(꼭 책의 내용이 정답은 아니지만) 어느정도 방향은 알려 줄 수 있지 않을까 생각이 된다.

  •  



    본 리뷰는 한빛미디어로부터 도서를 지원받아 작성되었습니다.


    표지


    예쁘다


    한빛미디어의 책을 읽으면서 표지 디자인 때문에 실망했던 적은 없었던 것 같다. 오히려 디자인이 너무 마음에 들기에 읽지 않으면서도 괜히 버스나 지하철을 타면 무릎 위에 얹어두고 싶을 만큼 예쁘다.


    개발만 해왔던 내가, 어느 날 갑자기 '팀'을 맡았다!


    경력이 쌓이면서 어느새 팀원들의 업무와 실적을 책임져야만 하는 매니저가 된 사람의 이야기를 담고 있다는 사실을 제목을 보조하여 독자에게 알려준다.

    사람을 상대하고, 그들에게 도움을 주거나 받는다는 것은 생각보다 어려운 일이었다. 그리고 지금도 여전히 어렵다. 그렇기에 이 책이 더욱 끌리는 것이 아닌가 생각된다.


    내용


    노하우의 끝판왕


    시작부터 끝까지 노하우의 연속이다. 여기서는 그 어느 페이지에서도 정돈된 이론과 간단한 결과를 이야기하지 않는다. 모든 페이지에서는 경험에 기반한 결과, 그리고 그 결과를 원하는 방향으로 비틀기 위한 노하우를 전수 해 준다. 그야말로 이 책 밖에서도 충분히 어디서나 배울 수 있지만 어디서도 알려주지 않는 통찰력을 빌려주는 책이다.

    물론 그 통찰력이 모든 사람의 모든 상황에서 동일하게 정해진 공식처럼 적용되는 것은 아니기에 그것을 자신의 것으로 만드는 것은 독자의 몫이다.


    '나 자신부터 관리하기'


    이 책에서는 계속해서 팀, 기술, 사람을 지켜보고 관리하며 팀 안에서 시너지효과를 일으킬 수 있도록 도와주는 방법에 대해 길게 설명한다. 그리고, 끝에서는 '나 자신부터 관리하기'라는 이름으로 이야기한다.

    필자도 이 부분에서는 크게 고개를 끄덕일 수 밖에 없었다. 그 누구보다 게으른 사람이 주변 사람들에게 성실하게 살았을 때의 장점을 이야기하면 그것을 믿고 따를 사람이 몇 명이나 있겠는가?

    팀을 이끌기 위해서는 우선 나 자신부터 바르게 이끌어나갈 수 있어야 한다는 사실을 다시금 느낄 수 있었다.


    결론


    잘 보았다. 아직은 팀을 이끌만큼 경력이 많지도 않고 이끌 팀도 없지만 작은 프로젝트를 진행하거나 과제를 수행할 때, 또는 자기 자신과 싸워야 할 때(?) 큰 도움이 될 수 있을 것이라 생각되는 책이다.

    그리고 팀의 리더라면, 그리고 자신이 좋은 리더라고 깊게 착각하고 있다면 더더욱 한 번쯤 읽어보았으면 한다.

  •  

    경력 3 년 곱하기 2 7 년 차개발 7년차, 매니저 1일차

     

    어떤 분야에서 일을 하든 그 분야에서 3 년 정도를 일하면, 그 분야에 발을 들여 놓았다고 말을 할 수 있을 것이다. 아울러이 책의 제목처럼 3 년의 2배 수, 7년차 정도 되었다면 주변에서 경력을 인정해주면서 다른 사람들과조화롭게 함께 일을 진행할 수 있는 매니저 자격을 주는 것이 일반적이라고 생각한다.

     

     

    KakaoTalk_20200429_200333378.jpg

     

     

    특히 내가 몸 담고 있는 IT 프로그래밍 쪽에서는 관리직을 자연스러운경력의 단계로 보지 않고 개발만을 전적으로 담당하고 싶어하는 사람이 많은 것으로 알고 있다. 객관적인통계 자료가 있진 않지만, 주변인을 바라볼 때, 관리직으로넘어가느냐 개발직군으로 계속 남아 있느냐를 두고 고민을 하는 사람이 많은 것이 사실이다.

     

    개발 7년차, 매니저 1일차라는제목을 가진 이 책이 출시되자 마자 주변의 개발직군 동료들이 다양한 SNS 에서 이 책의 출간 소식을알리며 함께 살펴보자 독려하던 모습들은 그동안 많은 동분야 사람들에게 팀원이 아닌 팀장 혹은 매니저로써 어떤 역할을 수행해야 하는지 어떻게 관리하게되는지 혹은 관리에서 만나게 될 문제들은 무엇인가에 대한 시원한 가이드 북이 그동안 없었음을 증명하는 것이 아닐까 싶다.

     

    특히 IT 는 연차별로 쌓이는 경력보다는 새로운 내용을 받아들이고기술에 대한 경험을 많이 습득 하는가에 따라서 실력과 능력이 천차만별로 나뉘어지는 것이 다반사이기에 개발 연차가 쌓였다고 해서 자연스럽게 관리기술까지 늘어나는 것이 아니기에 더더욱 그러하다.

     

    그간 일을 하면서 직간접적으로 느꼇을 많은 일들은 멘토가 나이가 많다 하여 혹은 경력이 많다고 하여 훌륭하게멘티들을 이끌 수 있는 것이 아님을 증명하고 있다.

     

    이 책의 내용을 간략하게 요약하자면, 개발자가 테크 분야에서 리더로써성장함을 기본으로 동시에 다양한 팀원과 팀장, 팀장을 관리하는 관리직의 역할까지 설명하는 일종의 롤플레잉매뉴얼로써 느껴졌다.

     

    다만 한가지 아쉬운 점은 이 책에서 종종 나오는 인사분야의 대처 방법이 서양과 동양의 차이를 적절히 담아내지못했다는 생각을 버릴 수 없었다. 짧은 시간이었지만 해외에서 일을 해 본 경험을 바탕으로 이 책에서의내용은 직원의 채용과 해고가 비교적 자유롭고 실직에 대한 리스크 관리가 공공의 분야에서 잘 갖춘 서양 문화에 어울릴 내용이어서종종 고개를 갸우뚱하면서 과연 한국에서(?) 라는 의문이 들었던부분이 있다.

     

    예전부터 다양하게 주장되어온 것들을 확장적으로 살펴보면 XP 에서애자일, 도구로서 칸반과 스크럼, 최근은 OKR 등등.. 서양에서는 개인으로써 프로가 되어 일하는 방식과 팀으로성과를 내는 방향과 지향점, 다양한 시도를 해보고 있는 것들을 시도해보고 있는 것으로 알고 있다. 아울러, 개인적으로도 시도해 본 경험이 있는데, 해외 취업을 위한 구직사이트 내용을 살펴보면, 해당 회사가 어떤방식으로 팀을 운영하고 성과를 측정하는지에 대한 구체적인 안내들이 있던 것으로 기억된다. 이 책의 내용을마치 증명이라도 하 듯 말이다. 당신이 프로임을 증명할 방법이라고 미리 공지를 하는 느낌이랄까.

     

    아직도 행해지고 있는 사실들이지만, 아주 일부라고 믿고 싶다. 아직 한국의 일부 관리자는 팀 관리와 성과 관리를 아직도 제조업의 컨베이 벨트 타입에서나 통할 것 같은 방법으로하고 있는 곳이 많다. 단위 시간을 정해 놓고, 엑셀 시트를꺼내 놓고, 거기에 빗금을 쳐가며, 앉은 자리에서 완성/미완성의 O/X 를 채워 넣는 일로 팀원을 관리/감독하는 형태의 성과관리를 말이다. 아이러니하게도 대부분의 개발자들이혀를 내두르는 SI 현장에서 특히 이 방법은 아주 훌륭하게 동작한다.

     

    최근 들어 IT 업무가 주된 비즈니스의 한 축으로 동작하는 회사들이많아지고, 글로벌화 된 IT 문화를 자연스럽게 받아 들이고, 호칭 문화의 개선으로 대표 될 수 있는 다양한 시도를 통해 평등한 문화를 받아 들이는 곳이 많이 있는데, 평등은 결코 관리직의 부재를 뜻함이 아니라 공동의 권리임과 동시에 책임과 의무의 분산을 의미하는 것이기에 마냥핑크 빛은 아니다. 프로가 되어 책임을 다하고, 그 결과로성과를 가져갈 수 있는 문화가 정착된 곳이 많이 나타나고 있다.

     

    그리하여, 개인이 팀의 구성원으로써 역할과 팀장으로써 역할, 아울러 다른 사람과 함께 어우러지는 다양한 소프트 스킬 등을 이 책에서는 마치 사전처럼 나열하며 알려준다. 이 책의 마지막 페이지에서 결국 책임이라는 것은 결국 자신을 둘러싼 많은 요소들을 관리를 할 수 있는가를 보여주는것이고, 가장 먼저 할 것은 자기관리라는 결론에 도달하게 된다.

     

    뒤통수를 한 대 쌔게 얻어 맞은 기분이 들면서, 이게 정답이 아니라면, 이 세상 그 어떤 무엇이 정답이겠는가? 라는 질문을 던지게 된다. 우리가 만나는 모든 문제들의 해답을 찾다 보면 결국 철학을 찾게 되고, 그철학의 근본은 나는 누구인가?” 로 시작되지 않는가 말이다.

     

    자신의 현재 위치가 어디든누구든 한 번은 읽어 보기를 강권한다. 앞으로 어떤 길을 갈지 누구도 알 수 없지만, 나 자신부터 점검하고알고 준비하고 길을 나서는 사람과 그렇지 않은 사람은 그 길 위에서의 과정은 분명 다를 것이기에

    KakaoTalk_20200429_200333560.jpg

     

  • 한빛 미디어 나는 리뷰어 다 를 통해서 이번에는 "개발 7년차, 매니저 1일차" 라는 책을 리뷰하게 되었다.

     

    "개발 7년차, 매니저 1일차".

    우선 이 책의 제목부터가 흥미롭다. 

    개발자로 일을 하고 있는 사람이라면 언젠가는 겪어야 하는 과정의 한 부분이기 때문이다. 그런데 현실은 그렇게 만만치 않다. 누군가 자세히 설명해주는 사람도 없다. 그러한 과정들이 항상 되풀이 되고 이제 곧 나에게도 다가올 것이라는 생각이 든다.

     

    책은 매니저에서 부터 시작해서 점점 더 큰 조직을 맡게 되면 어떻게 팀을 관리를 해야 하는지, 매니저들은 어떻게 관리를 해야 하는지에 대해서 이야기를 해준다. 그리고 중간 중간에 같은 상황에 대해서 어떻게 대처하느냐에 따라서 상황이 어떻게 달라지는지 비교해서 설명을 해주는 부분들도 있다. 

     

    도움이 되는 Q&A 와 생각해볼수 있는 문제들

    각 챕터 중간중간에 위와같이 "CTO에게 묻는다" 라는 소주제들이 있다. 질문과 답변 형식으로 되어있고 실체 처음 관리를 맡게 되는 사람들이 궁금해 할 만한 질문들로 이루어져 있다. 답변들을 천천히 읽다 실제로 우리 주변에서 많이 볼수 있는 일들이어서 공감이 많이 됐다.

    그리고 챕터 마지막에는 오른쪽과 같이 질문들이 있어서 한번 생각해보고 챕터를 마무리 할 수 있다.

     

    실제 종사자들의 경험담

    많지는 않지만 3편 정도의 기고글이 책 중간에 담겨져 있다. 실제 이러한 일들을 겪었던 분들의 경험담이기 때문에 같은 고민을 하고 있는 분들이나 이야기에서 말하는 상황에 놓인 분들에게 도움이 될만한 내용이다.

     

    이런 분들에게 꼭 권해주고 싶어요.

     

    책을 읽으면서 처음 부터 끝까지 나와 비슷한 상황 또는 고민들에 대한 내용들이 많이 나왔다. 아마 나 또한 직장생활한지 이제 곧 10년정도 되어가고 관리를 해야되는 역할에 다가가고 있어서 그런것 같다. 나는 항상 개발밖에 할수 없으며 무엇인가 관리하는 일들은 정말 나와는 안맞는다 라고 생각해왔다. 아래 글을 잠깐 보자.

    딱 내가 생각했던 것들이다. 매니저가 되면 개발할 시간이 줄어들고 여기저기 회의에만 쫓아다녀야 하고. 그런 모습들이 정말 싫었다. 그리고 처음 개발을 할때에는 이러한 업무들은 개발보다 중요하지 않다고 생각을 하기도 했다. 하지만 그건 나의 잘못된 생각이었다. 이건 쉽게 생각할 업무가 아니고 정말 무거운 책임을 갖고 임해야 하는 중요한 일이다. 또 매니저란 역할은 연차가 올라간다고 맡는게 아니라 그 업무를 잘 해낼수 있는 사람에게 맡겨야 된다는 생각이 들었다. 이 책에서도 그러한 이야기를 계속 해주고 있다. 

    안타깝게도 실제 우리가 다니고 있는 회사에서는 그런 것들을 배려해주지는 않는다. 그래서 이런 글들을 통해 조금이라도 준비를 할수 있으면 실제 매니저가 되었을때에 아주 조금이라도 덜 힘들지 않을까 생각이 든다. 

    이제 곧 매지너라는 역할을 맞이 해야하는 모든 개발자 분들에게 이 책을 적극 권해주고 싶다. 파이팅.


    https://blusky10.tistory.com/453

  •  

    올해 시니어 매니저가 되면서 기존과 달라지고 있는 업무 형태에 대한 고민이 많았습니다. 
    좋은 기회로 이 책을 접하게 되어 당면한 숙제, 그리고 앞으로 풀어나가야 할 숙제들에 대한 많은 팁들을 얻을 수 있었습니다.
    책에서 소개하고 있는 경험 기반의 업무 스킬, 조직 및 프로젝트 관리 노하우 들은 앞으로 지속적인 도움이 될 것이라고 생각합니다.Emotion Icon

     

  • 개발자로서의 본인의 능력이 타인의 멘토, 관리자로서의 능력과 일치한다고 보기는 어렵다. 그 방향에 본인이 능력을 가지고 있는지의 여부는, 땅이 알고 하늘은 알겠지만 본인 스스로는 잘 알기 어려운 것이 당연하다. 덕분에 당신이 개발한지 굳이 7년차가 되지 않았더라도, 개발한지 7년이 훌쩍 넘었더라도 이 책은 한번쯤 읽어볼만하다.

     

    개발자로서 일하는 와중에, 인턴이나 신입 혹은 후임과 함께 일하게 되는 것은 당연하고 자연스러운 과정이다. 때로는 여러모로 갖춰지지 않은 선임과 매니저와 일하는 경우가 발생하는 것도 사실이고... 이럴 때는 정말 눈물이 쏟...


    이 도서는 분명히 본인이 매니저 혹은 멘토, 테크 리드로서 적합한 자인지 아닌지, 현재까지 그 역할을 제대로 수행했는지 하고 있는지에 대한 회고에 적지 않은 도움을 줄 것이다. 자기 개발서류의 약간의 뻔한 이야기는 포함되어 있지 않느냐고 묻는다면 아니라고는 못 하겠다. 'ㅅ') 후후. 사람들이 일하는 형태라는게 거기서 거기 아니겠는가.

     

    본인이 개발자라면 커뮤니케이션, 팀과 코드 작성을 위한 시간의 분배, 기술 부채의 해결과 운영 등 시간이 갈수록 나이가 들수록, 고려해야 할 불확실성과 이슈 사항은 늘어가고 부담감과 고민, 때로는 죄책감까지도 마음에 쌓이고 있을 것이다. // 그게 아니라면 당신은 행운아 아니면 천재 'ㅅ')!

     

    매니저로서의 자신과 시니어 개발자로서의 자신을 저울질하며 앞으로의 진로를 선택하며 나아가는 과정에 있는 누구에게나, 이 도서는 참고할만한 레퍼런스가 되어줄 수 있을 것으로 생각되어 일독을 조심스레 권해본다. // 개인적으로는 어느 회사에나 존재하기 쉬운 프로세스 독재자에 대한 이야기와, 테크리드, CTO 에 대한 이야기가 흥미로웠다. 'ㅅ')

     


  • 결론

    갑자기 결론이지만, 결국은 나 자신을 잘 관리하는 능력이 요구된다는 내용입니다. 무척 단순한 말일 수도 있지만, 단순한 결과를 도출시키기 위해 필요한 배경에 깔려 있는 과정을 무시해서는 안 된다는 말이기도 합니다. 개발자로서 현장에서 요구되는 코드는 당연한 것이고 사람을 대하는 기술도 코드 경력만큼 필요하다는 것을 자각하면서 읽어야 할 것 같습니다.

    국내 IT에서 매니저의 역할은 슈퍼맨

    매니저라는 직업은 무척 힘이 드는 직업입니다. 특히 외국과는 약간 다른 위치에 있을 것으로 보이는 국내 개발 환경 실정에서의 매니저는 무척 중노동을 강요당하는 입장입니다. 개발도 책임감 있게 해야 하고, 부하 직원들도 제대로 관리해야 하고, 회의에도 꼬박꼬박 참여해야 하고, 릴레이 회의 뒤의 회의록도 작성해야 하는 등 몸이 두 개라도 모자란 환경에 내몰리게 되는 경우가 많이 있습니다. 정말 잔혹하게 혹사당하는 경우가 비일비재하죠. 이런 환경에서 말이라도 잘 들어주는 팀원이라면 다행이지만 그렇지 않다면 지옥도가 그려지기 시작하는 것이죠. 이 책이 이런 상황에 처해있는 관리자 신입생들에게 조금이나마 도움이 되는 책이 될 것 같다는 생각이 들었습니다.

    나의 경험

    책의 원서의 배경이 외국인만큼, 국내 실정과는 거리가 있는 내용이 있기도 합니다. 프로그램, 개발자 직군은 아니지만 IT업에 종사한 지 경력이 좀 있다 보니 책에서 다루고 있는 PL 업무를 보게 되는 경우도 종종 있습니다.

    책을 읽으면서 공감되는 부분도 많이 있었고 리더에 대해 제대로 배울 수 있는 경험도 없이 갑자기 4, 5명의 팀원을 관리하게 될 경우 대책 없이 시작된 만큼 잘 진행될 리가 없었습니다. 책을 읽으면서 계속 나쁜 기억이 떠오르며 다음에 또 비슷한 자리에 앉게 된다면 지난번과 같은 실수는 하지 않기를 바라며 읽게 되었습니다.

    책에 대해서

    벌써 2쇄??

    초판이 2월 4일인데 근 두 달 만에 2쇄 발행이라면, 상당히 잘 나가고 있는 책 아닌가요? 이쪽 분야에서 이런 내용을 다루는 책이 부족했음을 직감할 수 있는 부분이었습니다. 책 선정을 잘한 것 같습니다.

    다양한 부분의 내용을 다룹니다

    좋은 매니저인지, 나쁜 매니저 인지는 참 판단하기 어려울 수 있습니다. 외부적으로는 좋은 매니저가 내부적으로는 공공의 적 취급을 받기도 하고 그 반대의 경우도 있고 참 어려운 문제이긴 합니다. 업무가 잘 돌아가게 하기 위해 정치적인 부분도 어느 정도 필요하고, 모두의 시선에 지독한 사람이라 손가락질을 받을 수도 있는 위치에 서게 되는 등 정신적 스트레스가 이만저만이 아닙니다.

    다시 결론

    나이를 나타내는 숫자가 하나씩 늘어남에 따라 사회에서 요구하는 능력치도 같이 올라가게 됩니다. 그 과정에 있는 누구나 경험하게 되는 매니저라는 역할. 업종을 불문하고 경험하게 되는 과정 속에서 개발이라는 특화된 분야의 내용을 잘 정리한 책이라는 생각이 들었습니다. 이 책을 조금 더 매니저의 역할에 대해 고민하게 되었습니다.

    개발자 뿐만 아니라 누구나가 경험해야 할 '관리'

    언젠가 다시 팀원을 관리해야 하는 상황이 온다면 다시 읽어보게 될 책일 것 같습니다. 현재 개발자이지만 부사수를 관리해야 하는 입장에 있다면, 갑자기 많은 인원을 관리해야 하는 상황이 온다면, 내가 관리하는 팀의 불협화음이 심하다 느껴진다면, 내 팀을 좀 더 좋은 방향으로 이끌고 싶다면 한 번쯤 일독을 권하고 싶습니다.

     

     

  •  

    개발7년차.jpg

     

    서평단 책으로 신청을 하면서 제목을 보고 신청할지 말지 고민을 많이 했다. 나는 아직 대학생인데 매니저들이나 읽을 법한 책을 읽어서 얻는 게 있을까라는 생각 때문이었다. 그래서 매니저는 어떤 사람들이 하고 어떤 일을 하는지 알고나 있자는 가벼운 생각으로 신청하게 됐다.

     

    책의 내용은 멘토부터 CTO까지 직책별로 필요한 관리 기술에 대한 내용이다. 팀을 관리, 경영하는 것이 주 내용이고 그 내용 속에 팀원(개발자, 멘티)이 팀에서 어떻게 해야 하는지에 대해서도 이야기한다.

     

    이 책의 초반 ~ 중반까지는 매니저뿐만 아니라 개발자들에게도 도움이 되는 내용이 많아 대학생의 입장에서 내가 신입 개발자가 됐을 때 어떻게 해야 할지를 초점에 두고 읽었다. 책의 후반부는 아직 대학생인 내가 읽기에는 지루한 내용이 많고 너무 먼 미래의 이야기처럼 느껴지기도 했다.

     

    주니어, 신입 개발자가 멘토, 매니저에게 무언갈 얻고 싶은 마음이 있듯이 매니저도 그들에게 기대하는 게 있을 것이다. 책에서는 매니저의 입장에서 팀을 관리하고 경영하는 걸 이야기하면서 동시에 주니어, 신입 개발자들 개발자로서 어떤 자세를 가져야 할지도 알려주면서 굳이 매니저가 아니어도 충분히 읽어볼 만한 내용들이 있다.

     

    미래에 팀을 이끌고 프로젝트를 진행할 매니저 혹은 그 이상을 원하는 대학생이라면 충분히 읽을 가치가 있다. 또 굳이 매니저까지 생각하지 않더라도 책의 내용은 앞으로 개발자로서 살아가는데 필요한 아주아주 기본적인 자세에 대한 이야기도 있어 읽어볼 만하다. 그리고 책에 나오는 매니저로서 갖춰야 할 기술들은 대학생에게도 충분히 필요한 기술들이라고 생각한다. 대학생활 중 진행하는 프로젝트에서도 프로젝트를 팀으로서 진행하게 될 텐데 이 책의 내용들은 도움이 될 수 있다고 생각한다.

     

    개발자 혹은 매니저로서 잘하기 위해서는 나 자신부터 관리해야 한다는 책의 결론 부분이 와닿았다.

  • 서점에서 몇번을 들었다 놨다 책이었는데 결국은 읽게 되었다.

    읽자마자 느꼈던 것은 너무너무 재밌다! 였다.

     

     

    SE-42a0fabc-52e9-4405-8258-87db7a76faa4.jpg

     

     

     

    주니어라고 하기에도 민망한 아직은 초보 개발자인 입장에서 내가 책을 읽어보고 싶었던 이유는 매일매일 만나는 동료들에 대한 마음이 가장 컸었다. 과장님들은 진급할 무서움이 없었을까? 팀장님도 처음부터 팀장님은 아니었을텐데.. 같은 생각들 말이다. 나의 팀장님은 장애가 발생해도 냉정하고 침착하게 대응하시며 사람 관리까지 해내시고 그러면서도 팀원들 고생했다고 해주시는 . 가끔 경험과 마음가짐이 감탄스러워 팀장님은 어쩌다 팀장님이 되셨어요? 여쭤보면 "그냥.. 어쩌다보니 해야되니까 하게 됐네요 ㅎㅎ" 하며 웃으신다. 거절하고 싶어도 언젠가는 관리자가 되어야 한다면 어떤 관리자가 되어야 할지.. 나같은 주니어들이라면 한번쯤은 해봤을 그런 생각들 저자도 똑같이 무서워했고 같은 마음을 겪어보았기에 양쪽 입장에서 서로의 입장을 풀어나간다.

     

    반대로 입장에서는 매니저가 날보다 팀원으로 일할 날들이 많기 때문에 하게 되는 나는 좋은 팀원일까? 업무 + 사람에 대한 고민에 가뜩이나 힘든 팀장님에게 도움이 되는 직원일까? 같은 고민들을 위로해주는 내용들도 존재한다.

     

    개발자 농담에 낄낄 웃게 사람이라면 분명 이건 얘기 이건 동료같다! 하며 실실 웃으며 읽게 되는 책이었다. 지금 매니저를 맡고 있는 사람이든 아니든 본인과 팀원들을 생각하며 즐겁게 읽을 있는 책이라고 생각한다. 지금 입장에선 현재 같이 일하는 분들께 좋은 동료가 되려면 또한 어떤 사람이 되어야 다시금 돌아볼 있는 기회가 되었다.

    

  •  

    개발 7년차, 매니저 1일차 책 표지

    저번달 3월에 이어 4월에 받아서 서평을 작성하는 책은 "개발 7년 차, 매니저 1일 차"라는 책이다.

    사실 3월부터 이 책을 읽어보고 싶어 서평단 책으로 신청을 했지만, 아쉽게 다른 책이 선정되어 4월 신청 목록을 보고 바로 신청을 했다.

    제목에서 알 수 있듯이 아직 학부생 4학년인 내가 읽어도 될까?라는 의무심이 들게 되는 책이다. 
    하지만 내가 읽어보고 싶다고 생각한 이유는 18년도 군 전역후 지금까지 휴학 없이 쉴 틈 없이 학부생 생활을 하고 있다. 
    우리 학교는 매 학기 프로젝트형 수업을 진행하면서 팀 프로젝트를 진행하고 있으며, 매 학기 1-3개 정도의 팀 프로젝트를 진행한다.

    그 과정에서 어쩌다 보니 나는 팀장이라는 역할을 어느순간 자연스럽게 하고 있었고, 팀원들과의 소통 및 프로젝트 진행에서 좋은 리더란 어떤 사람인가 라는 의무심을 갖게 되던 중 우연히 인스타그램에서 이 책에 관련된 내용을 쓰신 분의 내용을 보고 기회가 된다면 한 번쯤 읽어 보고 싶다는 생각이 들었다. 또한 책 소개 페이지를 보니 아래와 같이 글이 써져 있었기 때문에 더욱더 '무슨 책일까?'라는 생각을 들게 해 주었다

    이런 분들 주목!
    • 개발자 vs 매니저 갈림길에 서 있다.
    • 개발 관리를 체계적, 효율적으로 하고 싶다.
    • 내 사수가 사수 역할을 못해서 내가 고생 중이다.

    (출처 : https://www.hanbit.co.kr/store/books/look.php?p_code=B3838365362)

     

    목차


    1장 IT 관리 101
    2장 멘토링
    3장 테크리드
    4장 사람 관리
    5장 팀 관리
    6장 여러 팀 관리
    7장 매니저 관리
    8장 빅 리그
    9장 문화 개선
    10장 결론
    나 자신부터 관리하기

    목차에서 볼 수 있듯이 IT분야에서의 팀 관리와 관련되어 작성된 글이다 라고 생각할 수 있지만, IT와 관련된 기술이 아닌 하나의 팀을 관리하는 팀장 혹은 매니저에 대한 글이기 때문에, 어느 분야의 팀장 혹은 매니저 직급을 가진 사람이라면 한 번쯤 읽어보고 '나는 어떠한 리더인가..' 혹은 '어떠한 리더가 되어야 할까..'라는 생각을 하기에 좋은 책이다.

    이 책은 장 끝부분에 간단한 체크리스트가 있어 나의 경험을 평가하며 자신에 대해 생각하게 해 준다. 사실 이 부분이 공감은 많이 안되었지만, '리더란 어떤 사람이다'라는 생각을 해주게 된 페이지이다.

    책의 일부분

    이 책을 읽으면서 많은 생각을 하게 되었다.

    사람마다 원하는 좋은 리더가 다를 것이다. 또한 나에게 좋은 리더일지라도, 다른 사람에게는 좋은 리더가 아닐 수도 있다.

    다시 한번 팀장 혹은 리더라는 직급에 대해 자신의 자리는 책임감이 항상 따른다는 생각을 하게 된 책이었다.

  • 20200426_143224.jpg

     

     

    지은이 카미유 푸르니에는 미국 회사에서만 근무해본 개발자이기에

    미국인의 관점에서 쓰인 책이지만,

    여러 종류의 사내 위계질서와 조직 구조에 대한 이야기가 담겨있고,

    관리와 조직 구조가 가지는 가치에 대해서 독자를 설득한다.

     

    개발만 해오던 개발자가 매니저가 되었을 때,

    어떻게 해야할지 막막할텐데,

    저자는 이러한 사람들을 위해

    어떤 매니저가 되어야 하는지, 어떻게 사람을 관리해야하는지

    이 책을 통해 알려준다.

     

    그리고 숙련된 매니저는 현재 겪고 있는 어려움에 맞춰

    해당 장을 찾아 읽으면 된다는 팁까지 소소하게 준다.

     

    중간중간 담겨있는 CTO에게 묻는다, 좋은 매니저, 나쁜 매니저, 도전 상황을 통해

    현실적인 상황들과 조언을 보며 쉬어갈 수 있다.

     

    꼭 개발자가 아니라 직장 생활을 하는 사람들이라면

    한번쯤 읽어보면 도움 될 책.

  • 리더라는 것은 참 애매하다. 아래에 있을땐 위로 가면 모든사람에게 잘해주자고 마음을 먹게되지만, 정작 위로 가면 어떻게 해야할지 모르는 경우가 많다. 필자 역시 그런 경우가 많았고. 아직 학부생이고, 인턴경험도 없어 사내의 분위기가 어떤지는 잘 모르지만, 확실히 팀원과 팀장이 가지는 느낌은 무언가 다르다는 생각이 든다. 

     

    우리는 언제나 밑의 개발자로만 있는것은 아니다. 지금 있는 자리가 항상 그대로일수도 없고, 또 연차를 먹게 되면 언젠간 밑에 후배나 인턴 같은 신입들이 들어오길 마련이다. 그렇다고 그들을 그냥 알아서 잘 자라듯이 놔둘수도 없지 않는가. 

     

    이 책은 개발자라면 누구나 겪게될 관리의 모든것에 대해 얘기를 하고 있다. IT서적임에도 개발이 아닌 매니지먼트 관련 얘기를 하는것이 독특하다. 게다가 그냥 간단하게 얘기하는 것이 아니라 세부적으로 애기를 하고 있다. 멘토링부터 사람,팀,매니저 관리하는 법에 조직문화 개선방법까지. 단순 자기계발서로 얘기하기엔 내용도 자세해서 마치 매니저를 잘 하는 법엔 이런것들이 있다는 듯이 소개하는 전문 서적을 보는 것 같다.

     

    사실 아직 학부생이어서 쉬이 공감을 하지 못한 부분이 많기는 하다. 조직문화나 팀 분위기 같은것이 더욱 그랬다. 하지만 조별과제나 동아리 같은 그 동안 경험했던 단체생활과 비교해본다면 이 책에 나온 말이 확실히 맞다는 점이 몇몇 보이곤 한다. 

     

    기업에서 중간급에 위치한 개발자 겸 매니저를 하고 계신 분들에게는 적극 추천하고 싶고, 신입 개발자한테도 후에 좋은 선배가 되기 위한 좋은 밑거름이 될 수있게 해주는 교양도서로의 역할도 잘 할법한 도서라고 생각된다. 개발자라면 기술서적뿐만 아니라 이런 관리쪽 서적이 필요하다고 생각이 들었는데, 이 책이 좋은 해결책을 보여줄 것이라고 생각한다.

  • managers_path.jpg

     

    "개발 7년차, 매니저 1일차" 책의 제목만 보고 실용서 느낌이 물씬 풍겼다. 궁금하여 원제를 찾아보니 다음과 같았다.

    > The Manager's Path : A Guide for Tech Leaders Navigation Growth and Change.

     

    매니저의 길 : 성장과 변화를 모색하는 테크리더를 위한 가이드. 아, 이 책이 무슨 이야기를 하게 될까? 조금 더 느낌이 온다.

     

    "개인적인 경험"이지만 "개발 매니저"에 대한 이야기로 시작해본다.

     

    ## 개발 팀장이 됐어요.

    개발 팀장은 언제 어떻게 되는 걸까? 그리고 우리나라 개발자의 현실은 또 어떠할까? 관리를 잘해서, 리더십이 있어서, 팀을 잘 이끌 수 있는 능력이 검증되어서 팀장이 되는 경우는 드문 것 같다.

     

    "경력 연차도 어느 정도 쌓였고, 개발 역량도 있으니 이제 관리도 해야 하지 않을까?" 그렇다. 스스로 원해서라기 보다 때가 되었고 개발도 잘한다고 인정받고 있으니 팀장 역할을 떠맡는 게 아닐까 생각이 든다. 또 이렇게 관리의 길로 들어서는 게 "승진"인 우리나라 개발자의 커리어 패스이고 현실이기도 하다.

     

    ## 나 다시 (개발자로) 돌아갈래.

    개발자로서의 역할과 매니저로서의 역할이 전혀 다른데 이렇게 떠맡게 된 자리에 많은 스트레스를 받는 게 이내 우리나라 개발 팀장들의 현실이지 않을까?

     

    어느새 GOD의 "길"을 들으며,

    > 내가 가는 이길이 어디로 가는지 어디로 날 데려가는지 그 곳은 어딘지...

      알 수 없지만~ 알 수 없지만~ 알 수 없지만~ 오늘도 난 걸어가고 있네~~

     

    하루에도 열두번씩 행복했던 그리고 원하던 개발을 맘껏 하던 개발자로 다시 돌아가야 하나 진지한 고민을 해보지 않은 개발 팀장은 없지 않을까?

     

    ## 매니저의 길을 알려주마.

    이렇게 개발 팀장이 되었는데 과연 잘할 수 있을까? 스스로에 대한 대답은 "아니오."이다. 개발은 많은 레퍼런스와 문제 해결을 위한 과정들을 함께 고민하고 알맞은 해결 책을 찾아나갈 수 있는 반면 관리란 눈에 보이지 않는 무형의 것으로 사람과 조직을 관리하며 회사와 조직의 목표를 달성함은 물론 개인의 동기부여와 성장까지 이끌어야 하는 -내 몸 하나 챙기기 어려운 이 시대에- 진정 리더의 모습이 필요하다.

     

    이 책은 바로 이런 조직 그리고 개인의 성장과 변화를 이끌 수 있는 테크 리더를 위한 친절한 안내서와 같은 책이다. 대인관계, 소통, 리더십 등 소프트 스킬은 물론 신입 멘토링을 시작으로 테크 리드, 팀 관리까지의 주옥같은 팁들, 더 나아가 역할 레벨이 올라감에 따라 더 많은 팀, 매니저 관리, CTO의 역할과 책임은 무엇인지 저자의 경험을 살려 친절하게 설명하고 있다.

     

    ## 통찰, 그리고 시도해보기

    작은 개발 팀을 관리하는 리더로서 이 가이드를 보고 이제 나는 무엇을 해야 할까? 책에 나온 "알파긱"이란 모습에 스스로가 투영되었다. 자의든 타의든 내가 갖게 된 리더라는 역할에는 큰 권한이 주어지며 그 이면에는 더 큰 책임과 의무가 함께 주어진다는 것을 다시 한번 생각해보는 계기가 되었다.

     

    또 이 책의 부제가 "A Guide for Tech Leaders Navigation Growth and Change."인 것처럼 내가 지금 테크 리더, 매니저로서 올바르게 잘 가고 있는지 되돌아볼 수 있는 친절한 안내서이다. 안내서에 나와 있는 다양한 전략들, 지침들을 시도해보고 내 상황과 환경에 맞게 적용시켜보는 것. 책을 덮고 나니 또 하나의 숙제가 남았다.

     

    ## 매니저 또 하나의 길

    매니저의 길로 들어선 수많은 개발자들에게 매니저의 숲에서 헤매지 않고 잘 헤쳐나갈 수 있게 도움을 줄 수 있는 입문서로써 매우 추천한다. 번역의 질도 괜찮다. 다만 책의 제목은 원제가 이 책을 더 잘 설명해 주는 것 같아 다소 아쉽다.

     

     개발자에게 관리라는 것이 떠맡게 되거나 기피하는 대상이 아닌 또 다른 영역으로 도전하고 싶은 그런 역할이 되면 좋겠다. 그 경험을 통해 개인은 물론 팀, 회사의 성장과 변화를 이끌고 더 넓은 안목을 얻게 된다면 우리나라 개발 문화가 한층 성숙해질 수 있는 계기가 되지 않을까?

     

  • 속이 시꺼매질 일이 있던 차에 발견한 책입니다.

     

    일찍 만났더라면 속이 시꺼매지지는 않았을까요? 상처를 되짚으며 전부 읽다 보니 일찍 읽었다면 다른 팀원들에게는 더 잘할 수 있었겠다는 생각이 들었습니다.

    아무래도 저자가 미국인이다 보니 2 pizza team 같은 개념을 생소해 하는 중장노년 인구가 많은 한국사회와는 다소 다른 면이 군데 군데 보입니다. 그렇다 해도 사수, 멘토, 팀장, CTO까지 직책별 관리 기술 대백과라는 홍보문구는 절대 과장이 아니었습니다. 팀원, 상사, 그 상사의 마음도 조금은 더 알 듯했습니다. 제가 더 잘해야 하는 영역을 발견하기도 했습니다.

    연차가 오르며 곧 리더가 되고 매니저가 될 것이 눈에 보인다면 꼭 읽어 보세요. 다 읽고 이해가 갈 듯 말 듯 하더라도 책장에 넣어두고 관리직이 되거나 관리업무 비중이 늘어난다 싶으면 다시 뽑아 보시길 바랍니다. 아주 유용할 겁니다.



    출처: https://wizmusa.tistory.com/ [전산쟁이 wizmusa의 IT 이야기]

    출처: https://wizmusa.tistory.com/ [전산쟁이 wizmusa의 IT 이야기]
    일찍 만났더라면 속이 시꺼매지지는 않았을까요? 상처를 되짚으며 전부 읽다 보니 일찍 읽었다면 다른 팀원들에게는 더 잘할 수 있었겠다는 생각이 들었습니다.

    아무래도 저자가 미국인이다 보니 2 pizza team 같은 개념을 생소해 하는 중장노년 인구가 많은 한국사회와는 다소 다른 면이 군데 군데 보입니다. 그렇다 해도 사수, 멘토, 팀장, CTO까지 직책별 관리 기술 대백과라는 홍보문구는 절대 과장이 아니었습니다. 팀원, 상사, 그 상사의 마음도 조금은 더 알 듯했습니다. 제가 더 잘해야 하는 영역을 발견하기도 했습니다.

    연차가 오르며 곧 리더가 되고 매니저가 될 것이 눈에 보인다면 꼭 읽어 보세요. 다 읽고 이해가 갈 듯 말 듯 하더라도 책장에 넣어두고 관리직이 되거나 관리업무 비중이 늘어난다 싶으면 다시 뽑아 보시길 바랍니다. 아주 유용할 겁니다.

     

  • 안녕하세요, 괴짜 개발자 namedboy 입니다. :)

     

     

    제가 오늘 리뷰할 책은 `개발 7년차, 매니저 1일차` 라는 책입니다.  

    저는 사실 그동안 왜 이런 책이 국내에 없었을까 싶을 정도로 이런 내용을 다루는 책이 반가웠습니다.  

    책의 내용이 좋고 나쁨을 떠나서 드디어 국내에서도 관리자의 역할에 대해 고민하고 있다는 반증이라는 생각에서 입니다. 

     

    국내에서 개발자로 일을 하다 보면 언젠가는 팀 관리에 대한 요구사항을 만나게 됩니다.  

    회사에서는 좋든 싫든 관리자 역할을 요구하게 되는 것이지요. 당연히 그 이유는 일을 잘하는 직원은 많지만 관리를 잘하는 직원은 찾기 힘들기 때문이지 않을까 싶은데요.  

    사실 요구사항만 있지 어떻게 해야 관리를 잘 할 수 있는지에 대한 내용은 국내에선 잘 다뤄지지 않는 것 같습니다.  

    특히나 회사에서 관리자라는 역할은 `그냥 대충 일 잘하는 사람이면 다들 할 수 있는 것 아닌가?`라는 생각을 많이 하시기 때문에 맡은 업무를 잘 하는 직원에게 관리자 역할도 덤으로 주는 것 같네요.  

     

    하지만 관리자로 하게 되는 일들 또는 "업무" 입니다. 관리자가 하는 업무인거죠. 단순히 일을 잘하니까 다른 사람들 관리도 하세요. 라고 할 수 있는 일이 아니라는 겁니다. 때문에 해외에서는 관리에 대한 자격증도 존재하고 관리를 할 때 어떻게 해야 하는지에 대한 교육도 이루어지고 있습니다. 대기업에서는 HR 부서에서 이런 내용을 다루기도 합니다. 하지만 우리나라 사람들이 가지고 있는 관리자에 대한 개념은 이런 전문적인 일이라는 인식은 많이 떨어지는 것 같습니다.

    기본적으로 관리자가 되는 과정에 대해 제대로 가르쳐 주는 곳이 잘 없기 때문이기도 합니다.  

     

    그런 의미에서 이 책이 정말 반가웠고 마음이 들떠서 읽게 되었습니다.  

    개발자로 오랜 기간 일을 하다 보면 팀 리더로 일을 하게 되거나 그냥 현업을 지속하거나 둘 중 하나의 길을 선택하게 됩니다. 개인의 성향 또는 커리어에 따라 결정하게 됩니다.  

    기술직으로 계속해서 경력을 쌓고 싶은 사람이라면 경력이 많아도 기술직으로 일을 할 수 있는 회사에 있어야 할 것입니다. 보통은 그런 커리어를 쌓게 두지 않기 때문입니다. 보통의 회사는 경력이 5년 이상 되면 관리직의 요구사항을 직원에게 요구합니다. 그렇게 되면 반 강제적으로 관리직을 겸해야 하죠. 관리자는 기술직이 아니기 때문에 관리에 대해 전혀 생각해보지 않았다면 그 때부터 지옥이 시작된다고 생각합니다. 이런 상황이 되면 당사자는 완전히 새로운 업무를 하는 것처럼 느껴지게 됩니다. 기술직으로 일을 할 때는 하지 않는 일들을 하게 때문인데요.

     

    그런 일들은 상사에게서 욕을 들어가며 배우거나 해보면서 알게 되는 거라며 그런걸 가르쳐 주는 곳이 어디있냐고 얘기를 하는 곳도 있긴 합니다.

     

    기존에 힘들게 배웠던 분들이니 그렇게 얘기할 수도 있다고 생각합니다. 하지만 지금은 아니라고 말씀드리고 싶네요.  

    그런 내용이 바로 이책 `개발 7년차, 매니저 1일차`에 담겨있다고 생각이 듭니다. 내가 관리자의 역량을 키우고 싶거나 CTO 또는 관리직을 생각하고 계시다면 이 책을 읽어보는 것을 강력히 추천드립니다. 정말 피가되고 살이 되는 책일 것이라 자부합니다.

     

    저는 개발자로 10년이 넘게 일을 해오고 있습니다. 그렇기 때문에 개발자가 관리직으로 올라서야 할 때 무엇을 해야 하는지에 대해 몇 년 전부터 계속해서 고민을 해오고 워크샵이나 교육들을 들었었는데 이 책에 그런 내용들이 고스란히 담겨 있는 걸 보고 많은 간접 경험을 할 수 있었고 매니징을 어떻게 해야 하는가에 대해 꽤 많은 인사이트를 얻을 수 있었습니다.

     

    관리직을 생각하고 계시다면 이 책을 추천드립니다.


  • 제목을 참 잘 지은 것 같다. 누군가 어느날 맞이하게 될 현실적인 일을 아주 간결하게 뽑아냈다.

    개발자의 회사생활에 대한 이야기라서 개발과 관련되어 있지만 코드 같은 이야기를 다루는게 아니다. 개발시 관리의 문제에 대해서 다룬다.

    비단 개발 분야만 아니라 직장 생활에서 마주치는, 필요한 이야기도 많다. 어차피 개발자도 직장인 중에 한 직군일뿐 아닌가.

     

     

    02.jpg

     

     

    이 책은 나름 양방향 소통을 하려고 한다. 독자의 경험을 질문하는 부분이 있다. 초반부에 질문들은 위와 같은데 전혀 개발 관련 이야기라고 볼 수 없을 만큼 보편적인 내용이다. 따라서 개발자가 아니라 개발직군과 함께 일하는 유관부서 인원도 읽으면 도움이 될 수도 있을 것 같다.

     

    03.jpg

     

     

    직장 생활 중에 만날 수 있는, 옆에서 봤던 참 불편한(?) 상황에 대한 이야기까지 있다. 매니저 입장에서 필요하긴 하지만... 뭔가 개발 관리에 대한 내용을 더 많이 기대해서 그런지 약간 방향이 틀어지는 것 같기도하고.. 그래도 꼭 필요한 내용이고... 다소 혼란스럽다.

    이런 보편적인 이야기만 있는 것은 아니다. 사람마다 다르지만 개발을 계속 하면서 매니저가 되고 싶은 사람도 있고 개발자로 남고 싶은 시니어들도 있다. 그래서 개발을 계속 하고 싶어하는 문제에 대해서도 책에서 다루고 있다.

    다른 분야도 비슷하겠지만 본인의 주업무, 실무만 하다가 관리라는 업무를 맡게 될 수 있다. 개발자는 개발만하다가 갑자기 매니징까지 하게 되면 당혹스러운 부분이 있을 것 같다. 자신의 커리어와 다소 무관하며 매니저도 하나의 전문 분야인만큼 본인의 부단한 노력이 필요하다.

    이 책은 세상 모르고 개발에 매진하던 순진한 공대생이 조직 생활의 노하우와 인력관리에 대한 세상을 마주할 때 겪는 어려움을 극복하는데 도움이 될 것 같다.

  • "개발 7년차, 매니저 1일차"

    제목을 보자 마자 느낄수 있었던건 부사수된 입장, 리딩 당하던 입장에서 벗어서 이제는 다수의 팀원을 이끌수 있는 리더십에 대한 이야기라 생각했다.

     

    특히 "개발만 해왔던 내가, 어느 날 갑자기 '팀'을 맡았다!" 라는 상황에 놓였을 경우를 생각해보니, 사실 아찔한 생각이 들었다.

    지금 가지고 있는 지식으로, 지금 가지고 있는 스킬로 나라면 어떻게 할까? 특히는 사람과의 관계가 가장 어려운 부분인데 이 부분은 어떻게 해결해야 할까?

    고민에 대한 답을 찾을수 있지 않을까 라는 생각이 들었다. 

     

    리더의 입장에서 다수를 이끈 다는건 쉽지 않은 일이고, 아직까지 그런 상황을 경험하지는 못했다. 앞으로 언젠가는 이런 상황의 입장에 놓이게 된다는 생각으로 책을 접하게 되었다.

     

    이 책은 아래와 같이 도움을 받을 수 있다.

    . 사수, 멘토, 팀장, CTO 까지 직책별 관리 기술 대백과

    . 개발자도 꼭 알아야 하는 소프트 스킬, 사람 및 조직 관리 노하우 수록

    . 개발팀을 성공으로 이끄는 IT 팀장에 대한 모든것

     

    먼저 이책은 카미유 푸르니에라는 렌트더런웨이의 CTO 역할을 했던 분이 저자이다. 

    사실 우리나라와 외국의 상황이나 팀 문화 등이 다르다는 것은 이미 좀 알고 있기 때문에 우리나라 정서와 맞을까라는 의문도 들었다. 

     

    자, 좀더 살펴보자. 이책은 이런 분들을 위한 책이다.

    . 개발자 VS 매니저 갈림길에 서 있다

    . 개발자 관리를 체계적, 효율적으로 하고 싶다

    . 내 사수가 사수 역할을 못해서 내가 고생 중이다

     

    책의 가장 첫장에는 친절하게도 이 책을 읽는 방법에 대한 가이드를 설명해 주고 있다. 

    장별로 있는 방법과 매니저의 경험에 따라 읽는 방법을 가이도 해주고 있고, 중간에 "CTO에게 묻는다", "좋은 매니저, 나쁜 매니저", "도전 상황"에 대한 코너도 마련하여 여러 상황에 대한 노하우를 얻을 수 있었다.

     

    책을 읽으면서 가장 떠오르는 단어가 있다면 "소통" 이라는 단어가 머릿속에 맴돌았다.

     

    항상 매니저라 하면 방패막, 팀원들의 우산이 되어 줘야하고 뭔가 책임을 져야하는 무거운 자리 임을 생각하고 있었던 내게 이 책은 꼭 그런것 만은 아니다라는 생각을 들게 했다.

    매니저는 팀원들이 핵심 목표를 이해 하고 이에 집중하도록 도와 줘야 하지만 모든 것에서 보호해야 하는것은 아니다. 때로는 스트레스의 일부를 팀에 전달하여 처한 상황을 함께 이해할 필요도 있다는 것이다.

    그리고 가장 쉽지 않다고 생각했던게 어쨋든 갈등들은 항상 생기는 문제인데 이것은 어떻게 생각해야 할까라는 부분이었다. 이책은 내가 매니저일때 할수 있는 생각들에 대한 답변을 주고 있었다. 

     

    회사내 어떤 위치에 있던지 마주하게 되는 어려움들이 있다. 이러한 어려움을 이겨낼 수 있도록 상담해 주는 책이라는 생각이 들었다. 매니저의 마음을 이해 할 수 있는 계기가 되었고 또한 좋은 매니저로서 나 자신과 그리고 팀원들과 소통할 수 있는 방법들에 대한 생각을 정리하게 만들어주는 시간이었다.

     

    그리고 마지막 결론 부분에 기억에 남는 말이 있다면,

    다른 사람을 잘 관리하기 위해서는 나 자신을 관리할 수 있어야 한다는 것..

    훌륭한 매니저는 갈등을 잘 해결해야 한다는 점 (대화할때 자존심을 잘 분리한다는 의미)

     

    사람들에 호기심을 가져라. 프로세스에 호기심을 가져라. 기술과 전략과 비즈니스에 호기심을 가져라.

    항상 호기심을 품고 좋은 매니저가 되기 위한 준비를 해야겠다.

     

  •  

    책 제목을 보는 순간 개발 8년차인 나와 비슷한 눈높이에서 많은 조언을 얻을 수 있을 것 같다는 생각이 들었다. 사실 나는 아직 매니저 역할은 하지 않고 있고, 아직 먼 얘기라고 생각하고 있지만 나와 비슷한 연차에서 매니징을 하시는 분들도 많기 때문에 그 분들은 어떤 고민을 하고 있을지 또 어떤 판단과 결정을 내리고 있는지 궁금했다.

     

     

    책을 읽으면서 매니저에 대해 내가 생각하지 못했던 부분들이 참 많다라는 것을 느꼈다. 그 동안은 매니징을 받는 입장이었기 때문에 매니저 입장에서는 거의 생각을 해본적이 없었던 것 같다. 왜 팀장님은 저런 지시를 내리고 지난 번에는 이 업무가 꼭 필요하다는 듯이 얘기했으면서 갑자기 우선순위가 떨어지니 다른 업무를 먼저 하라는 지시를 내리는 것인가, 그리고 왜 내 일정은 고려하지 않고 일정을 결정하고 통보를 할까 등등 이해하기 어려운 부분들이 있었다. 어느 장단에 맞춰서 업무를 해야하는지 파악하기가 어려운 부분도 있었다. 그래서 이러한 것들 때문에 불만이 많이 쌓이기도 했고, 내 입장만을 생각했던 것 같다.

     

     

    이 책을 읽으면서 작게나마 팀장님들의 고충을 이해할 수 있었다. 회사는 내 위주로 돌아가는 것이 아니고, 팀장 입장에서는 나 말고도 매니징해야하는 직원들이 많이 있다. 팀장님 또한 오더를 받는 입장이고, 이에 따라 일정은 언제든지 바뀔 수가 있는 부분이었던 것이다. 이런 내용을 일일히 다 팀원들에게 설명하기에는 업무량이 너무 많고 체력적으로도 힘든 부분이 있었기 때문에 팀원들 입장에서는 갑자기 일정이 바뀐다거나 중요했던 업무가 한순간 사라지는 등과 같은 일들이 발생했던 것 같다. 책에서 팀장님도 사람이고 팀장님도 짜증을 낼 수 있고 팀원들은 가끔은 팀장님에게 휴가를 줄 수 있어야한다는 내용이 있는데 많은 생각이 들게 했다.

     

     

    이 책은 사실 매니저로 들어서는 개발자 뿐만아니라 팀원으로 업무를 하고 있는 개발자들에게도 많은 도움이 되는 책이다. 왜냐하면 팀원으로써 가져할 자세나 마음가짐, 그리고 후임 또는 새로운 개발자가 들어왔을 때 알아두면 좋은 점들, 나를 발전시키기 위한 팁 등등 정말 많은 정보를 담고 있고, 이 내용들이 모두 저자의 경험과 시행착오로부터 나왔다는 것이 독자에게 큰 도움을 줄 수 있다고 생각한다.

     

     

    나는 아직 매니저는 아니지만 이 책을 읽고나니 한번 도전해보고 싶다는 생각이 들기도 했다. 원래 나의 꿈은 나이 들어서까지 개발을 하는 것이었는데 책에도 언급되어 있듯이 마냥 어렵게 느껴지는 매니징이 겪어보지 않고는 나에게 적합한지 아닌지를 판단할 수가 없는 것이다. 개발을 엄청나게 잘하는 사람도 매니징 능력은 정반대일 수 있는 것이고, 개발은 어느정도 하지만 자기도 몰랐던 매니징 능력을 발견할 수도 있다. 나 또한 매니징은 한번도 해보지 않았기 때문에 지금까지는 나와는 맞지 않는 업무라고 생각해왔지만 겪어보지 않고는 모르는 일이라는 생각이 들었다. 기회가 된다면 매니징 업무를 해보는 것도 큰 도움이 될 수 있을 것 같고, 책에서도 얘기하듯 매니징 업무로 간다고 해서다시 개발을 할 수 없는 것은 아니기 때문에 맞지 않는다는 생각이 들면 다시 개발 업무도 할 수 있을 것이라 생가한다.

     

     

    어쨋거나 중요한 것은 현재 나의 위치에서 잘할 수 있는 방법을 찾고, 항상 더 나아지려고 노력하며 나와 팀원들, 그리고 회사에 기여하는 것이다. 이러한 노력들이 쌓이면 개발이든, 매니징 업무든 잘해낼 수 있을 것이라고 생각한다.

     

  •  

    AF9AA425-57B4-4F03-96D6-92887CEB4695.jpeg

     

     

    올해도 한빛미디어 나는 리뷰어다에 신청을 했는데 당첨이 되어서 너무 좋았습니다.

     

    신청한 책 중에 올해 들어 꼭 읽고 싶은 책이 있었는데 다행히도 이 책이 당첨되어서 너무 좋았어요

     

    그 책은 개발 7년 차 매니저 1일 차라는 책입니다.

     

    일단 이 책을 선정한 이유는 작년에 잠시 팀장님이 그만두셨을 때 임시로 팀장 대행을 역할 하였습니다.

     

    처음으로 동료들이 아닌 팀장 대행 역활로써 동료들을 대할 때가 너무 달랐고 당황스러운 것도 많았습니다.

     

    이 책을 읽다 보면 책의 내용 중에 자신의 경험 평가하기라는 챕터가 끝나갈 때 나오는 내용인데 생각을 많이 하게 되는 것 같습니다.

     

    이 책은 저와 같이 시니어 개발자분들도 꼭 읽어 보셨으면 좋겠습니다. 우리나라에서 경력이 쌓다 보면 언젠가는

     

    팀을 이끌 팀장 역활이 올 수 도 있을 겁니다. 그때 당황스러울 수도 있지만 이 책을 읽다 보면 다양한 케이스의 사례를 예시로 이야기가 나오고 또한 저자의 다양한 경험이 녹여져 있는 책입니다. 여러모로 도움이 많이 될 것입니다.

     

    또한 개발 직군이 아니더라도 관리의 다양한 사례와 내용이 많음으로 관리자 직급의 여러 업종의 사람들이 읽어도 좋을 것 같습니다.

     

    그리고 이 책에서 제가 좋았던 점은 개발자가 관리자가 되더라도 언제나 다시 개발자로 돌아오도록 항상 기술 트렌드와 자기계발에 열심히 해야 한다는 내용이 있어서 많은 공감을 하게 되었습니다.

     

    이렇게 좋은 책을 추천해주신 한빛미디어 관계자분들께 감사드립니다.

  • #한빛미디어 #매니저되기 #오렐리 #O'Reilly

    어느날 내 사수가 사라졌다!.

    제발 누가 날 매니저좀 해줘!

    셀프 매니징이 필요한 현재, 책에서 답을 구하고자 이책을 선택해 보았다.


    책표지. 개발 7년차, 매니저 1일차

    Head_IMG.jpg

     

    이런분들 필독 세번째와 유사한 사수가 없어서, 팀의 매니저가 팀의 팀장이 없어서 내가 고생 중이라 고르게 된 책.

    나쁜 매니저의 특징, 나쁜 부사수 또는 부사수별로 다루는 방법들에 오히려 스스로 공감하며,

    나스스로를 관리하기 위해, 매니저가 아닌 상사만이 있는 나를 위해 이책을 손에 들었다.

    한장 한장 넘기며, 고개를 끄덕이지만 좀더 넘어가면 나와는 별개의 세상이다.

    그러나 언젠가 다가오던가 또는 오히려 매니저들을 이해하기 위해서라도 읽어보는 것은 좋은 경험이다.

    상대팀을 대하는 법, 매니저의 매니저에 대한 대응 방법, 상사에 대한 대처 방법.

    그 모든 것들이 필요한 내용이지만, 예제가 많이 필요한 본인에게는 아쉽기 그지 없는 내용이다.

    나중에 기회가 된다면, 나의 부사수에게는 좋은 매니저가 되리라 다짐해 보면서

    스스로에게 스스로가 좋은 매니저가 되기 위해 노력하고자 한다.

    매니저를 위해 썼다고 하지만 사람을 대하고 업무에 대하여 임하는 자세는 누구에게나 필요한 내용이라고 생각 하므로, 누구에게나 헌번쯤은 읽어보길 권한다. 특히 좋은 매니저를 알아보기 위해서라도 새내기 주니어들도 한번쯤을 읽어 보길 권한다.

    책꽂이에 꽂아두고 필요한때 꺼내보기 위해 오늘도 킵.

  • 표지.png

     

    “현대의 소프트웨어 개발은 팀 스포츠입니다. 매니저는 ‘코치’이자 ‘지지자’가 되는 것이 가장 좋습니다. “
     책의 앞부분에 있는 ‘한국 독자에게’ 코너에 있는 이 말은 이 책을 통해 저자인 카미유 푸르니에가 하고자 하는 말을 함축적으로 나타내고 있다. 대부분의 직장은 나 혼자만 잘해서 성공하기 어렵다. 단기간이나 또는 특정 업무, 소규모 프로젝트에서는 뛰어난 누군가에 의해 성공으로 비춰질 수도 있지만, 장기적으로 보면 조직과 그 조직에 속한 구성원들이 성공하기 위해서는 같이 업무를 수행하는 구성원들이 같은 목표를 향해 달려나가야 한다. 저자가 말했듯 팀플레이가 제대로 되어야 하는 것이다.
     누군가와 함께 일을 한다는 것은 공식적이던, 비공식적이던 지에 관계없이 일을 시키는 역할과 그에 따르는 역할이 존재하게 된다. 일을 시키는 사람은 같은 팀의 선배일 수 도 있고, 팀장일 수도 있고, 조직에서 더 높은 상사일 수도 있다. 이 책은 소프트웨어 개발 조직에서 일을 시키는 사람의 입장, 즉 관리에 초점을 맞추고 있다.
     전체 10개의 파트로 구성된 이 책은 점차 조직의 상위 관리자로 나아가는 방식을 취하고 있다. 팀 내에서 멘토 되기, 훌륭한 테크리드가 되는 방법, 매니저가 되어 팀을 관리하기, 여러 팀을 관리하고, 또 매니저들을 관리하는 방법 끝으로 개발 부사장, CTO 등 최고 책임자로서의 역할과 책임에 대해 다루고 있다.
     책의 초반부는 마치 내 이야기 같아서 흥미로웠고, 중반 쯤은 내가 속한 조직의 상사들을 떠올릴 수 있어 재미있었다. 그 뒤의 이야기는 아직은 먼 미래의 이야기 같은 느낌에 몰입도가 떨어진 것도 사실이다. 하지만 곁에 두고 조직의 구성원과의 관계에서 어려움을 마주할 때 꺼내어 볼 만한 책임에는 틀림이 없다.

     

     

  • 개발 7년차, 매니저 1일차

    작가
    카미유 푸르니에
    출판
    한빛미디어
    발매
    2020.02.04.

    리뷰보기

     



     

     코로나로 재택근무를 하는 중인데, 집에서 있는 시간은 분명 많아졌지만 일하는 시간이 상대적으로 많아서 그런지 쉬거나 독서할 시간이 부족해진 느낌이다.

     

     이 책은 SNS에서 임백준님의 글로 먼저 접하게 되었다. 그 글이 인상 깊었던 건지, 나의 현재 상황에 어느 정도 투영되어서인지 책을 한번 보고 싶었다. 마음이 넓고 그릇이 커야 한다는 부분이 특히 마음에 와닿았다. 

     

     

     수 년 간 개발만 한참 하다가 최근 들어서야 딱히 직책은 없지만 파트장 역할을 맡아서 개발자 몇 명과 함께 업무를 보고 있다. 다른 팀과 공유하는 내용이 많은 업무다 보니 얽힌 사람, 얽힌 코드가 무척이나 많은데, 업무 자체의 양도 많아서 스트레스를 많이 받고 있다. 스트레스를 많이 받으니까 자꾸 남 탓을 하고 싶어지고 속이 좁아진다는 느낌을 받던 차에 이 글을 읽을 수 있어서 마인드 컨트롤을 더 잘 해보자는 의지가 생긴다.

     

     알파긱이라는 용어는 처음 접해봤는데, 장점들을 보며 나랑 비슷한데?라는 생각을 하다가도 단점을 보면 어 이것도 나랑 비슷하네라는 느낌을 받았다. 여기서 설명하는 알파긱은 좋은 경우도 있지만 폐쇄적이고 자기중심적인 그런 면이 좀 더 부각돼 보인다. 나는 장점에 좀 더 가깝다고 생각해본다. 사회생활을 하면서 느낌적으로만 알고 있던 어떤 현상(?)에 대해 이렇게 명확한 용어와 개념을 알게 되면 스스로에 대해 좀 더 정확한 분석이 가능해지는 느낌을 받는다. 

     

     

     3장 정도까지는 딱 매니저 역할을 시작하는 사람에게 알맞은 내용인 것 같고, 그 뒤 이야기는 어느 정도 매니저를 경험해본 사람에게 많은 도움이 될 것 같다. 멘토, 매니저, 테크 리드, 시니어 개발자 등 다양한 역할에 대해 각각의 장단점과 이상적인 업무 생활에 대해 잘 설명해준다. 아마 회사 생활을 어느 정도 해본 사람은 공감되는 내용이 아주 많을 것이다.

     

     어떤 역할에 대해 어떤 어떤 업무를 해야 한다라든지 정확한 평가 기준에 대해 정확하고 수치적으로 설명해주지는 않지만 어떤 방향으로 어떤 내용에 대해 생각해봐야 하는지 경험적으로 제시해준다. 역할이 바뀌면서 맡아야 하는 업무는 어느 정도 스스로 파악할 수 있지만, 장점이나 단점 시행착오 등은 이 책에서 소개해주는 여러 경험자의 얘기를 들어보는 게 많은 도움이 될 것이다. 챕터 뒷부분에서는 자신의 경험을 기억해내고 한번 더 고민해볼 수 있는 질문지가 있어서 생각을 정리하는데 도움을 준다.

  •  

     

    ◈ 이 책은 한빛미디어의 <나는 리뷰어다> 이벤트로 지원받은 도서 리뷰입니다.

     

    IMG_8978.jpg

     

     

    [한 줄 평]

    "모든 IT인의 길잡이 책"

     

     

    [도서 리뷰]

    처음 "개발 7년차, 매니저 1일차"라는 책을 접했을 때, '나에게는 조금 이른 책이 아닐까'라는 걱정이 들었습니다.

    이제 막 경력 3년차를 바라보고 있는 IT인에게는 "관리"라는 단어는 낯설고 두려운 단어였기 때문입니다.

    두려움을 안고 펼친 책의 목차를 훝던 중에 가장 관심을 끈 항목은 "2장 멘토링"이라는 주제였습니다.

    이제 막 신입사원을 맞이한 초보 사수로서 여러 난관에 봉착한 상황이었기에 단숨에 읽었습니다.

    덕분에 멘토링의 중요성과 멘토의 책임감에 대해서 무겁게 와닿았고

    '나는 좋은 멘토가 될 수 있을까?'라는 걱정에 대하여 세세하고 좋은 방안을 안내주고 있었습니다.

     

    이 책은 IT인이라면 한번쯤 겪을만한 여러 문제사항과 그에 대한 방안에 대해서 명쾌하고 세세하게 가이드하는 책입니다.

    앞서 IT인의 길을 걷고 있는 선배들이 풀어놓은 경험담에서 문제를 현명하게 해결할 수 있는 많은 꿀팁을 얻을 수 있습니다.

    그로인해 '나에게 조금 이른 책이 아닐까'라는 의문은 사라지고 '지금 읽어야하는 책이구나'라고 생각이 바뀌었습니다.

     

    앞으로 경력을 쌓아갈수록 인간관계나 의사소통과 같은 다양한 문제에 직면하게 될 것입니다.

    그런 류의 문제는 기술적인 문제와 다르게 직접 경험해보기 전에는 해답이 보이지 않는 경우가 대다수이며 답을 알더라도 대처하기 힘든 상황에 놓일 수 있습니다.

    "개발 7년차, 매니저 1일차"라는 책을 통해 

    문제사항에 대해서 '나라면 어떻게 대처할까' 고민하고

    '어떻게하면 더 좋은 동료로 성장할 수 있는가'에 대해 계획해보고 

    '이런 나쁜 동료로 남아서는 안되겠다'라는 다짐을 키울 수 있는 기회를 얻게 되었습니다.

     

     

    [도서 추천]

    주니어 IT인에게 이 책을 추천하고 싶습니다. 

    앞으로 어떤 시니어로 성장할 수 있을지에 대해서 진지한 고민과 방안에 대해서 길잡이가 되어 줄 것이라고 생각됩니다.

     

  • 개발자는 아니지만, 소프트웨어 관련 직군에서 일하고 있는 사회 초년생의 관점에서 이 책을 읽었다.

    어떻게 보면 지금 이제 막 회사에 적응하고 일을 배워가고 있는 단계에 개발 7년차에 매니저 일을 하게 된 사람의 이야기가 완전히 와닿았다고 보긴 어려울 것이다.

    하지만 사회 초년생의 입장에서 이 책을 보았을 때, 조직이 어떻게 운영되고, 윗 사람이 자신의 부서를 어떻게 관리하려고 하는지를 알 수 있었다.

    사실 회사에 갓 들어간 나로써는 내가 하는 일에만 집중해도 모자란데, 그런 큰 그림을 볼 생각조차 없었다.

    하지만, 이 책을 읽음으로써 '아, 윗사람이 사람을 보는 시각은 이렇구나', '난 이런 사람이 되지 말아야겠다' 이런 생각을 하면서 자신을 되돌아보게 되었다. 

  • 네이버 블로그에 '개발 7년차, 매니저 1일차'에 대한 포스팅을 한 적이 있습니다. (네이버 포스팅 보러가기) 이 당시엔 모든 내용을 정독하진 못했고 일부 내용을 보고 포스팅을 작성했었는데 이번엔 어느정도 책을 읽고 다시 포스팅을 해보려 합니다.

    <깔끔한 표지>
     
    지난 포스팅에서도 언급했지만, 이 책은 작년의 저에게 많은 도움이 되었을 책입니다. 물론 현재도 매니저직을 맡고 있긴 하지만, 현재는 프로젝트 특성상 거의 '개인 = 팀'의 형식으로 이루어져있기에 팀원관리라는 난제를 수행할 필요는 없는 상태입니다. 작년에 맡은 팀은 팀원도 약 10여명이 되었고, 무엇보다 저에게는 생소한 '애자일(Agile)방식'으로 팀을 운영하다보니 팀원관리가 여느때보다 힘들었던 기억이 납니다. 책을 읽어보고 처음 든 생각이
     
    '이 책을 미리 알았더라면 작년의 내가 고생을 덜 했을텐데...'
     
    라는 것이니 얼마나 큰 도움이 되었을지는 짐작이 가시리라 생각합니다.
     


    <SETP BY STEP>


    '개발 7년차, 매니저 1일차'는 관리자가 가져야할 스킬에 대한 것은 물론, 적절한 예시를 통하여 이해하기 쉽게 글을 풀어나가는 방식을 취하고 있습니다. 흔히 기술서적은 특성상 딱딱하다고 느껴지는데, 이 책은 기술서적이긴 하지만 결국 '사람 대 사람'을 대하는 방식에 대해 언급하고 있기 때문에 꽤나 읽기 편하게 느껴집니다. (개인적으로 외국저자의 책들은 대부분 읽기 편한것 같습니다.)

    다만 책의 저자인 카미유푸르니에가 '한국 독자에게' 라는 별도 파트에서 언급했듯이 미국 개발회사에 맞추어 만든 책이기 때문에 국내와는 상황이 조금 다를 수도 있습니다. 저자는 자신의 책이 한국어로 번역이 되어 놀랐다고도 하니, 책이 한국의 상황에 고려하지 않은 상태로 발간된 것은 분명합니다.

    <그럼에도 불구하고 이 책은 분명 관리자라면 도움이 될만한 소스로 가득 차 있습니다.>


    책의 내용에 대해서는 현재 필기를 병행하여 공부중입니다. 공부한 내용을 바탕으로 따로 포스팅을 연재할까도 생각중인데, 우선 지금 진행하고 있는 프로젝트가 막바지라서, 이 프로젝트가 끝나면 본격적으로 연재를 진행할 예정입니다. (포스트 발행을 네이버에서 할지, Blogger에서 할지는 좀 더 고민해봐야겠습니다.)



    책의 내용에 대해 궁금하신 분들이라면 꼭 구매해서 읽어보시거나 추후 제가 연재할 포스팅을 기다려주시기 바랍니다. 기다리기 어려우신 분들이라면 아래 링크를 통해서 책을 구매하실 수 있습니다.

    <한빛서점에서 책 구경하기 - 이미지 클릭>


    오래간만에 매니저에 대해 볼 만한 책이 출판된 것 같습니다. 한동안 제 책상에 자리잡고 있을 것 같네요 ^^ 좋은 책을 제공해준 한빛출판네트워크측에 이 자리를 빌어 감사의 말씀을 드립니다.

  • 개발자로서 참 많이도 경력을 쌓아왔지만 아직도 올해 막 들어온 신입사원만큼이나 잘 못하는 게 있다. 바로 누군가를 관리하는 일이다. 사람이 사람을 관리 즉 매니징 하는 것이란 참 불편하고 번거롭고 어려운 일이다. 특히나 나처럼 내성적이고 말을 조리 있게 하지 못하는 사람은 고역도 이런 고역이 없다. 오죽하면 식당에 가서도 불편한 점을 내색하느니 차라리 그냥 조용히 먹는 편을 택하는 게 편하다. 

    그러나 일에 있어서 그런거 없다. 나의 성향이 그렇더라도 하기 싫어도 맡은 자리의 역할이 그렇다면 해야 하는 게 프로가 아니겠는가. 회사 내에서 뭔가 직급이 올라가면서 책임을 지는 자리가 되었던지, 하는 일이 매니저라면 한 번쯤 읽어 보면 괜찮을 거 같다. 

    책 제목 맘에 든다. 개발 7년차, 매니저 1일 차

    개발자로서 역량은 많지만 사람 관계는 꽝인 나와 비슷한 상황이랄까? 명확하게 의사소통하는 법이라던가 멘토로서의 마음가짐 같은 것들을 나열하는데, 전부 정독하기보다는 그냥 심심할 때 쉬는 시간에 가볍게 읽기 좋다. 

    책.jpg

     

    • 이 책은 한빛미디어의 «나는 리뷰어다» 이벤트로 받은 서적입니다.

    […] CTO는 관리 직무이기도 하다. […] 다시 말해 그 비즈니스에 적극적으로 달려들 대규모 팀에 대한 모든 책임을 지고 싶지 않다면, CTO는 당신에게 맞는 직무가 아니다.

    글쓴이와 사뭇 다른?

    1

    먼저 이 책의 저자인 카밀 푸르니에(Camille Fournier)는 Rent The runway의 CTO이자, 골드만삭스의 부사장을 역임했던 인물이며 아파치 주키퍼의 커미터다. 쉽게 말해서 관리자(CTO), 비지니스 이해관계자(부사장, Stakeholder), 개발자(커미터)임을 기억하고 읽어야 한다.

    만약 이 사전 지식없이 책을 읽으면 엄청난 꼰대가 말도 안되는 소리 한다는 느낌을 받을 수 있다.

    2

    책의 전반적인 내용 중에서 약 1/3은 충불히 줄일 수 있을 것 같은 느낌이다. 왜냐하면 비슷한 이야기가 반복해서 나오는 경향성이 있다. 그리고 국내 상황과 비교해서 적절한지 묻지 않을 수 없다. 예를 들어 «1장 IT 관리 101»에서 아래와 같은 구절이 나온다.

    매니저가 문제를 해결해주길 바라는 대신 매니저에게 문제 접근 방식에 대한 조언을 구하자. 조언을 구하는 것은 존중과 신뢰를 표현하는 좋은 방법이기도 하다.

    책에 서술한 바와 같이 조언을 구하는게 존중과 신뢰를 표현할 수 있지만 과연 해당 매니저가 존중과 신뢰를 할 지 아니면 일을 떠넘긴다고 느낄지는 Case by Case 경향이 강하다. 그러니 이 책을 수용하는 독자는 이 분이 주로 근무하시는 곳이 ‘미국’임을 잊지 않아야 하며 환경이 사뭇 다르다는 점도 사전에 알고 있어야 한다.

    3

    반면 이 책의 전체 분량 2/3에 대해서 한 마디로 정의하면 ‘우린 문제를 해결하기 위해 존재한다’라는 명제를 계속해서 주장하고 있다는 점이다. 이게 일반적인 관리자를 위한 에세이와 사뭇 다른 점이다.

    그러나 기술적으로 뛰어난 것과 좋은 테크리드가 되는 것은 직접적인 관련이 없다. […] 기술적인면과 팀 전체 요구사항 사이의 균형을 잡는 방법을 찾아야 한다. « 3장. 테크리드 »

    테크리드라는 역할은 코딩을 해야 하지만 너무 많이 해서도 안 된다. 마술사가 모자 속에서 토끼를 꺼내듯이 해결책을 내놓고 싶더라도 우선 문제를 알릴 줄 알아야 한다. « 3장. 테크리드 »

    제품 매니저가 주장하는 엄청난 아이디어를 시스템에서 구현할 수 있을지를 평가하는 데 스스로 확신이 있다면 상황을 관리하기가 엄청 쉽다. « 5장. 팀 관리 »

    매니저가 되기 전에 충분한 시간을 들여 반드시 프로그래밍을 숙달하기를 권한다« 6장. 여러 팀 관리 »

    훌륭한 디버깅이 관리와 무슨 관련이 있을까? […] 이 블랙박스는 눈으로 확인 가능한 입력과 출력이 있지만, 출력이 예상과 다를 때 그 이유를 살펴보려면 블랙박스를 열어 내부적으로 어떤 일이 벌어지고 있는지 보아야 한다. « 7장. 매니저 관리»

    인용 구문에서 볼 수 있듯이 뭔가를 관리하는데 집중하는 것 같지만, 그 관리의 목적이 ‘비즈니스 문제’를 해결하기 위한 관리라는 것을 암묵적으로 전제하고 있는 듯 하다.

    여기저기 디버깅?

    4

    임백준님을 비롯한 다른 분들의 에세이도 실려있는데, 이런 점은 매우 훌륭하다. 왜냐하면 책일 읽으면서 미묘하게 느껴지는 이질감을 해소시켜 줄 수 있고, 기고자와 글쓴이가 묘하게 대립되는 주장을 하고 있는 부분이 있는데 이런 대립되는 주장에 대해서 다시 생각해 볼 수 있는 기회를 주기 때문이다.

    여기저기 디버깅?

    5

    비슷한 내용이 많아서 조금 늘어지는 감이 있지만, 책의 내용이나 글쓴이의 견해가 매우 명쾌하기 때문에 회사에서 어쩔 수 없니 매니저 업무를 진행해야 된다면 참고하면 좋을 책이고, 개발을 처음 시작하는 분들에게도 좋은 책이다. (초입개발자는 이 책을 읽고 여러분의 매니저가 어떻게 행동하는지 관찰해보면 좋지 않을까?)

    Written on March 26, 2020

  • 개발 7년차, 매니저 1일차

    ​한빛 미디어 <나는 리뷰어다> 3월 이벤트에 당첨되어 책을 읽게 되었다.
    페이스북에서 계속 광고 뜨고 추천하는 분도 있길래 어떤 책인지 궁금해서 신청했다.

     

    1585174975654.jpg

     

    1585174977160.jpg

     

    도움이 되는 내용도 많지만 아쉬운 부분도 있었다.

    책 표지만 봤을 때에는 8~9년차 경력의 국내 남성 매니저가 쓴 경험담인 줄 알았다.
    표지에 나온 사람이 상당히 젊은 청년 이미지이고, 제목도 '개발 7년차, 매니저 1일차'라고 해서 개발 소그룹의 매니저 막 겪어 보고 쓴 책인가 싶었다.

    하지만 책을 받아서 초반부를 읽어보니, 어 처음 책 표지를 봤을 때의 이미지와 다르네? 싶었다.
    찾아보니 지은이는 10년 이상 경력을 지닌 미국 여성이었다.
     
    작가님은 대학교 졸업 후 MS에서 18개월 일하고, 2005년에 석사 학위를 받았다고 한다.
    책이 나온 2017년에는 벌써 15년 전후의 경력을 지니고 있었겠구만. 그리고 2014에는 CTO 자리까지 올랐었다고 하니, 내용과 너무 어긋난 책 표지나 제목이 그리 마음에 썩 들진 않는다.
    오히려 원숙한 엔지니어의 책인 줄 알았다면 좀 더 빨리 봤을 것 같다.
    (이렇게 쓰면 다음 서평단에서 탈락하려나.. 그래도 솔직한 감상을 알려주는 게 '서평단'의 역할 아닐까.)
     
    그리고 책 읽는 내내 참 지겨웠다. 한 이야기 하고 또 하고.. 뻔히 아는 이야기를 굳이 이렇게 늘여서 써야 하나 싶기도 했다.
    얼마 전에 읽은 '실리콘밸리의 팀장들'의 데자뷰 느낌도 났다. 그때도 책의 분량이 2/3 정도만 되면 좋겠다고 생각했는데, 이 책도 마찬가지였다. 그래서 읽다가 지치면 중간중간 내용 패스해 가면서 끝까지 겨우 읽었다.
     
    그럼에도 불구하고, 기억해둘 만한 구절이 꽤 되었다.
    주요 내용은 다음과 같다.
     ...
     
    -------------------------
    블로그에 썼던 내용을 복사/붙여넣기 하려 했으나, 내용이 제대로 안 붙어서 네이버 블로그 포스팅을 링크합니다.
    이해 바랍니다.
     

  • 책 처음에 읽는 방법도 소개되어 있다.

    매니저 별로 읽는 방법도 쓰여져 있는데 일단 매니저는 아니지만 신입 매니저 권장 버전으로 읽어보았다.

    권장버전은 1장부터 3장 또는 4장까지는 정독, 나머지 장은 간단히 훓어보는 방식을 소개했다.

    그리고 이 책 중간중간 QnA같은 글이 있는데 네이버 지식인에 직장인이 울면서 올린 글에 초고수가 답변해준 느낌이다. 짧기도 해서 짬을 내서 읽어주는 부분 같았다.

    그리고 매니저에 대한 기고글이 있는데 경험에 기반한 글이니 마치 네이트판에 글을 보고 있는 기분이니 이것도 잠깐 시간 여유가 났을 때 보도록 하자. 보면서 본문에서 조금 낯설던가 이해가 느리던 게 이 기고글에서 고개 끄덕이면서 이해가 아주 일부라도 될 수도 있다.

     

     

    읽으면서 계속 느낀 것이 있다면...

    나는 아직 일반 사원이고 언젠가 매니저라는 역할을 맡을 수도 있고 아닐 수도 있겠지만 현재 내 상황에서 봤을 때 팀장님이 나에게 요구하신 반응은 대충 이러했겠구나, 또는 아, 이 때 피드백을 했어야 했구나. 를 느끼게 해준다는 것이다.

    분명 매니저를 위한 책은 맞을 것이다. 그리고 동시에 우리 밑에 사람도 읽어보면 좋을 것 같은 것이 매니저가 우리한테 말한 것에 대뜸 겁을 먹고 안절부절 할 필요는 없다는 것을 느끼게 해준다는 것이다.


  •  

    이번에는 전문서적이긴 하나 개발쪽 보다는 프로젝트 매니징에 관련된 책이다.

    이 책인데, 이번에 한빛미디어에서 새로 나온 신간이고 표지가 너무 이쁘다..

    아무튼 이번에 이 책을 받게 되어서 읽어보고 느낀점에 대해서 적어보려고 한다.



    외관은 참 이쁘다. 잘 만든 것 같다. 페이지는 360페이지 정도 되는데 사이즈가 다른 책보다 좀 컴팩트 하다. 가져다니기 딱 좋은 사이즈 인 것 같다.



    책 안에는 파란색을 위주로 한 색이 사용되는데 표지와는 또 다른 색을 사용해서 그런지 보기에는 부담이 적다.



    내용은 생각보다 되게 좋았다. 중간중간마다 CTO에게 묻는다! 이런 코너에서 실제적인 예시와 경험을 들을 수 있어서 매우 좋았다. 이 책은 PM을 처음 접하는 사람들에게는 힘들 수도 있을 것 같다는 생각을 하긴 했다. 처음에는 PM에 대해서 설명하지만 이후에 나오는 장들을 잘 이해하려면 팀규모에서 협업을 하고 PM을 해본 경험이 있다면 훨씬 수월하게 읽을 수 있다는 생각을 했다.

    이 책의 3장인 테크리드에 대해서는 참 많은 도움이 되었다. 나는 대규모로 팀을 뭐 맡을 일도 없고 진행해본 적도 없어서 많아봤자 3~6명이 전부인데, 이럴 때 개발자로 뭔가 리드를 해야할때 리더가 어떻게 해야하는지에 대해서 배울 수 있었다. 진짜 이런 것 들을 어디 캠프나 워크샵 같은 곳에서 배워야 할 것 같은데 이런 내용들을 책으로 볼 수 있다는게 좋았다.



    회사에 처음 들어간 분들이나 소규모 스타트업이나 팀 개발을 하시는 분이라면 한번쯤 읽어보고 어떻게 해야하는지 가이드를 얻으면 참 좋을 것 같다는 생각을 했다.



    * 이 책은 한빛미디어의 나는 리뷰어다 이벤트로 받은 서적입니다.

     

     

     

    IMG_0281.jpg

     

     

     

     

     

     

     

     

     

     

    IMG_0283.jpg

     

     

     

     

     

     

     

     

     

  • 한빛 미디어 <나는 리뷰어다> 3월!

     

    오랜만에 책 택배가 집에 도착했다. 지난 2월 한빛 미디어에서 하는 <나는 리뷰어다> 에 참가 신청을 했었는데 선정되어 2020년 1년 간 활동하게 되었다.

    미션 신청할 때 3권의 도서를 신청하고 랜덤으로 1권을 받게 되는데 꼭 3권을 고를 필요는 없기에 나는 2권만 선택했었다. 기대되는 시간이 지나 도착한 책.

     

    '개발 7년차, 매니저 1일차'

    페이스북에서 간간히 이 책이 보여 재밌을 것 같다는 생각을 했었는데, 좋은 기회에 이 책을 받게 되었다.

    이 책은 매니저가 된 개발자를 위해 매니저로 성장하면서 겪는 여러 문제를 사례와 조언을 담았다. 또 소프트 스킬이 부족한 사수를 둔 개발자를 위해 사수에게 어떤 도움을 받을 수 있는지에 대한 내용도 담겨있다. 책의 표지에 귀여운 사람 그림이 그려져 있는데 지금 보니 눈 부분이 조금 무섭다....

     

    이 책에는 <한국 독자에게>가 있다. 한국어 외에도 러시아어, 독일어, 일본어까지 번역되는 사실에 놀라며 하며 말미엔 이런 내용을 남겼다.

    세계 어디서든, 회사의 문화가 어떻든, 개발 관리는 힘들고 외로운 업무입니다. 이 책을 혼자 읽기보다 친구와 동료들과 함께 읽기를 추천합니다. 제 경험으로는 업무의 어려움에 대해 다른 매니저들과 의견을 나눈 방법이 관리를 더 잘 할 수 있도록 이끄는 데 최고의 방법이었습니다.

     

    - 카미유 푸르니에

     

    저 내용이 공감됐다. 개발 관리는 힘들고 외로운 업무다. (내가 해본 건 아니지만...) 그래도 일이라는 게 혼자 하는 것 같지만 혼자 하는 게 아니지 않은가. 나도 읽어 보면서 혼자 읽는 것 보다 여럿이 읽고 이야기하면 더 뜻깊은 독서가 될 것 같았다.

     

    좋았던 점

    좋은 매니저, 나쁜 매니저

    • 개발 매니저들이 팀이 성장하고 목표를 달성하기 위해 본래의 목적에서 벗어나 바람직하지 못한 방향으로 가는 나쁜 습관들을 파악하고 이를 극복할 수 있는 전략을 알려주는 코너다.
    • 이 코너에서는 위에 설명된 대로 나쁜 습관을 파악하고 극복하는 전략을 알려주는데 사실적인 예제를 가지고 설명하기 때문에 이해도 잘 되고, 아 이런게 나쁜 습관이구나, 나쁜 매니저가 이런 행동을 하게 되는 구나 하고 알게 된다.

    2장 멘토링

    • 이 장에서는 멘토링의 중요성과 멘토링을 어떻게 해야하는 지 설명하는 장인데 멘토, 멘티, 멘토의 매니저를 위한 팁을 제공해 모두가 적용할 수 있는 장이다.
    • 회사 입사하게 되면 멘토/사수 이런 관계가 만들어지는 데 그때 실질적으로 어떻게 해야하는지 알려주는 장이라 좋았다.

     

    아쉬웠던 점

    책 뒷면 "이런 분들 필독!" 에 '내 사수가 사수 역할을 못해서 내가 고생 중이다.' 라는 문구가 있었는데 읽는 중에 저 부분에 해당되는 내용은 아직 많이 발견하지 못했다..해야하나 쓰다보니 저런 생각을 가지고 있는 사람이 읽는 거라면 이렇게 하면 좋은 매니저가 될 수 있다고 일러주는 책같다. (주절주절)

     

    총평

    함께 읽었을 때 더 가치있는 책

  • KakaoTalk_20200323_133404093.jpg

     

     

    일을 잘 하는 사람과 일하는 팀의 매니징을 잘 하는 사람은 같을 수도, 혹은 다를 수도 있다. IT 업계에서 시키는 일만 잘 하는 사람이 있고, 코딩을 잘 짜는 사람이 있으며, 사람 관리를 잘 하는 사람도 있고, 코딩을 잘 하며 사람 관리를 잘 하는 사람도 있기 마련이더라. 중요한 건 본인의 일만 잘한다고 해서 나중에 관리도 잘할 것이라 생각해선 안된다. 그렇기 때문에 개발 7년차, 매니저 "1일차"라고 타이틀을 지은 것 같다. 특히 "난 밑바닥에서 잘했으니 매니저로 올라가면 뭐든 잘할 수 있겠지?"라며 근자감에 차신 분들의 편견을 훌륭하게 깨줄 것이다. 그렇다고 "일은 잘 몰라도 난 사람 관리를 잘 하니까 이 책은 필요 없겠지?"라고 생각하시는 분들에게 도움이 되지 않는 책은 아니다.

     

    저자가 외국인, 정확히는 미국인이다 보니 한국과는 정서적으로나 업무 내용적으로 다른 내용이 많지 않을까?라는 우려를 가지며 책을 접했던 것 같다. 다행히 이는 기우였다. 사내 위계질서와 구조를 지지한다는 저자의 생각을 바탕으로 책이 만들어졌다 보니, 나 또한 어느 정도의 위계질서가 중요하다고 생각하는 입장에서, 그리고 글로벌적인 추세에 비해 아직까진 수직적인 분위기가 강한(물론 이는 앞으로도 완화되어야겠지만) 한국의 회사 생활에도 적용될 수 있기에 이해하는 데에 어려운 책은 아닐 것이다.

     

    ​나의 경우에는 커리어의 대부분을 호주 호텔 비즈니스를 차지하고 있고, 지금은 한국으로 돌아와 교육업에 종사하고 있다. 일반적인 한국의 회사 생활과는 조금 거리가 있겠으나, 여전히 프로젝트를 주도하며 진행함에 있어 매니지먼트에 대한 개념이 유효한 것 같다. 최종 결정권은 따로 있지만 결정권자의 입장에서, 그리고 팀원의 입장에서 생각에 생각을 더하며 양방향을 설득하고 있다. 교육업에서는 주로 커리큘럼과 시간대, 프로모션 등이 이에 해당하는 듯? 최근에 이 책으로 많은 내용을 배우고 있는 것 같다.

     

    책은 총 10 챕터로 구성되어 있다. IT 관리, 멘토링, 테크리드, 사람 관리, 팀 관리, 여러 팀 관리, 매니저 관리, 빅 리그, 문화 개선, 결론으로 되어있으며, 챕터로 넘어갈수록 보다 큰 규모의 집단을 매니지먼트하는데에 도움이 되도록 글을 썼다. 그러므로 해당 규모에 맞게 글을 적당히 읽는 것이 좋으며, 만약 보다 높은 자리에 올라가길 희망한다면 미리 책의 끝까지 읽는 편이 좋을 것이다. 굳이 300페이지가 넘어가는 책을 한 번에 읽어야겠다는 부담감을 가지시기보다는, 상황에 맞게 읽는 편을 추천드린다.

     

    ​단순히 어떻게 하면 효율적으로(흔히 이야기하는 아랫사람들을 굴리는) 업무를 추진하는지에 대하여 이야기하지 않는다. 어떻게 하면 팀과 소통하며 문제없이 관리하는 것이 책의 주요 내용이다. 게다가 단순히 팀원이 문제일 경우에 대해 사면 이야기하지 않고, 매니저는 어떠면 좋고 어떠면 나쁜지에 대하여 구체적인 예시까지 이해가 쉽게 적혀있다. 게다가 단순 신참 매니저로 가는 길에 대해서만 적은 것이 아닌, 시니어 관리자 등 보다 높은 위치에 있을 경우 어떻게 매니지먼트를 해야 하는지에 대해서도 훌륭히 적혀있다. 특히 감정과 팩트를 나눠서 이야기를 해야 한다던가, 혹은 피드백은 너무 늦게 주기보다는 제때 주는 편이 좋으며 다 같이 있을 때보다는 개인적으로 이야기하는 편이 덜 부담스러운 등, 상당히 실용적인 내용이 많아 좋은 책이라 느껴진다.

     

    책의 전반적인 내용이 훌륭하여 전부 인용하고 싶으나, 가장 중요하다고 생각하는 결론 파트의 내용을 부분 인용하도록 하겠다.

     

    "훌륭한 매니저는 갈등을 해결하는 전문가다. 갈등을 잘 해결한다는 의미는 대화할 때 자존심을 잘 분리한다는 의미이다. 복잡한 상황을 명확히 보려면, 내가 상황을 어떻게 합리화했는지 잘 인지하고 있어야 한다. 직원에게 하기 힘든 이야기를 전해야 할 때, 직원이 그 이야기를 들어주기를 바란다면, 사실을 당신 입장에서 꾸며서 이야기하면 안 된다. 매니저가 되고 싶어 하는 사람은 상황이 어떻게 돌아가야 하는지에 대해 단호한 의견을 가지고 있다. 자기 객관성을 유지할 때 단호함은 좋은 자질이다. 하지만 그러지 못할 때는 상황을 잘못 해석하게 만들 수 있다. 주관적인 해석은 그저 해석일 뿐이다."

     

    굳이 IT업계에 종사하지 않는 분들일지라도, 모든 업종의 매니지먼트를 갓 시작하거나 자기만의 방식으로 진행하면서 답답한 경우가 많은 분들께 충분히 권해드릴 수 있는 책이다.

     



  • [한줄평]

    신입 팀장이 알아할 개발 관리 내용이 잘 정리 되어 있다.


    [목차구성]

    1장 IT 관리 101

    2장 멘토링

    3장 테크리드

    4장 사람 관리

    5장 팀 관리

    6장 여러 팀 관리

    7장 매니저 관리

    8장 빅 리그

    9장 문화 개선

    10장 결론


    [이 책의 특징]

    • 사수, 멘토, 팀장, CTO까지 직책별 관리 기술 대백과

    • 개발자도 꼭 알아야 하는 소프트 스킬, 사람 및 조직 관리 노하우 수록

    • 개발 팀을 성공으로 이끄는 IT 팀장에 대한 모든 것

     


    [대상 독자]

    - 개발자 vs 매니저 갈림길에 서 있다.

    - 개발 관리를 체계적, 효율적으로 하고 싶다.

    - 내 사수가 사수 역할을 못해서 내가 고생 중이다.


    [서평]

    이책은 개발 매니저 뿐만 아니라 신입 매니저라면 꼭 봐야할 책입니다. 멘토링 부터 시니어 리더십 까지 각 직급에서 알아야 할 관리 기술들을 잘 정리 되어 있습니다.


    특히 처음 개발 관리를 하다보면 겪게 되는 여러가지 이슈 사항을 사례를 통해서 실질적인 조언을 과 문제 해결책을 제시 해줍니다.


    보너스로 각 챕터마다 국내 대기업에서 활동 중인 현업자들의 이야기들이 들을수 있습니다.

     

    이책은 신입 개발자 보다는 개발과 관리가 교차되는 시점의 개발 팀장 혹은 시니어 개발자들에게 길잡이가 되어줄 개발관리 바이블로 추천 해드립니다.

  • 나는 경력 12년차 이다.

    하지만 개발은 2년차 이다.

    그동안 개발보다는 주로 관리를 많이 해왔다.

    하지만 그 업무가 이 책에서 말하는 매니저의 업무와는 전혀 상관 없는 업무다.

    그런데 회사에서 이제 매니저의 역활을 줄려 한다.

    개발 경력도 얼마 되지 않고, 매니저와 함께 일해 본 경험도 없다.

    어떻게 해야 할지 눈 앞이 캄캄 하기만 하다.


    "개발 7년차, 매니저 1일차"

    아직 매니저가 아니지만 

    곧 들이닥칠 새로운 업무에 대해 걱정이 많았다.

    우연히 발견한 책이지만 아무것도 모르는 나이게 정말 한 줄기 빛과 같은 책이다.


    이 책은 제목처럼 '매니저 1일차' 인 신입 매니저 부터

    경력이 많은 시니어 매니저에 이르기 까지 폭 넓은 독자층을 아우른다.


    각각의 회사가 각각의 사내 문화와 사칙을 가지고 있듯이

    각 회사의 매니저 역할도 같지는 않을것이다.

    하지만 매니저로서 기본적으로 가져야 할 자세와 임무는 비슷하지 않을까?


    이 책을 통해 가장 중요하게 생각되었던 부분은 '소통' 이다.

    신입사원의 '멘토'가 되었거나, 혹은 신입사원으로써 '맨티'가 되었거나

    둘 사이에는 소통이 중요하다.

    또한, 매니저로서 중요한 업무중 하나로 소개한 '원온원'을 제대로 하기 위해

    필요한 것도 소통 이라고 본다.

    어떤 상황에 따라 어떤 소통의 기술을 발휘해야 하는지는 각자의 몫이지만

    어떻게 해야 할지 모르는 사람들을 위해 약간의 팁을 제공하고 있으니

    상황에 맞게 적용해 보는 것도 좋을거 같다.


    마지막으로 이 책은 꼭 매니저가 아니더라도 읽어 봤으면 하는 책이다.

    언젠가는 모든 개발자가 계속 개발자로 계속 남을지

    아니면 매니저로 전환 할지 선택을 해야하는 순간이 올 것이니까.

결재하기
• 문화비 소득공제 가능

배송료 안내

  • 책, 아이템 등 상품을 1만원 이상 구매시 무료배송
  • 브론즈, 실버, 골드회원이 주문하신 경우 무료배송

무료배송 상품을 포함하여 주문하신 경우에는 구매금액에 관계없이 무료로 배송해 드립니다.

닫기

리뷰쓰기

닫기
* 도서명 :
개발 7년차, 매니저 1일차
* 제목 :
* 별점평가
* 내용 :

* 리뷰 작성시 유의사항

글이나 이미지/사진 저작권 등 다른 사람의 권리를 침해하거나 명예를 훼손하는 게시물은 이용약관 및 관련법률에 의해 제재를 받을 수 있습니다.

1. 특히 뉴스/언론사 기사를 전문 또는 부분적으로 '허락없이' 갖고 와서는 안됩니다 (출처를 밝히는 경우에도 안됨).
2. 저작권자의 허락을 받지 않은 콘텐츠의 무단 사용은 저작권자의 권리를 침해하는 행위로, 이에 대한 법적 책임을 지게 될 수 있습니다.

오탈자 등록

닫기
* 도서명 :
개발 7년차, 매니저 1일차
* 구분 :
* 상품 버전
종이책 PDF ePub
* 페이지 :
* 위치정보 :
* 내용 :

도서 인증

닫기
도서명*
개발 7년차, 매니저 1일차
구입처*
구입일*
부가기호*
부가기호 안내

* 회원가입후 도서인증을 하시면 마일리지 500점을 드립니다.

* 한빛 웹사이트에서 구입한 도서는 자동 인증됩니다.

* 도서인증은 일 3권, 월 10권, 년 50권으로 제한됩니다.

* 절판도서, eBook 등 일부 도서는 도서인증이 제한됩니다.

닫기

해당 상품을 장바구니에 담았습니다.이미 장바구니에 추가된 상품입니다.
장바구니로 이동하시겠습니까?

자료실