개발자로 살아남기

Publish date: 2022-03-20
Tags: 조직관리 경력

Table of contents

  1. 정리
  2. 인상 깊은 단락

이미지 출처 : http://www.yes24.com/product/goods/105645204

정리

핵심키워드 정리

인상 깊은 단락

프롤로그

p12

저는 농담으로 디렉터를 정의하며 이런 표현을 씁니다. “모든 일을 할 수 있지만 아무 일도 하지 않고 대신 모든 일에 책임지는 사람"이라고요.

p20

특히나 사용자와 다르게 제품을 사용하면 사용자와 다른 경험을 하게 되므로 사용자와 공감할 수 없습니다.

Part1 엔지니어링 역량

p27

소프트웨어는 과학, 기술, 엔지니어링, 수학이 잘 융합된 STE(Science, Technology, Engeering, Mathematics)의 결정체입니다.

p40

벤자민 비어의 말

“나는 세상을 약한 자와 강한 자로 나누지 않고, 성공한 자나 실패한 자로 나누지 않고, 무엇을 만들거나 만들지 못하는 자로 나누지 않는다. 나는 세상을 배우는 자와 배우지 않는 자로 나눈다.”

p46

제품 기획과 개발 단계에서 고객 여정을 설정하고 미리 시뮬레이션해야 하며, 각 과정은 숫자로 정의되어야 합니다.

p51

<디아블로 3>는 모든 디렉터가 엔딩을 보고 재미있다 할 때까지 몇 개월을 담금질되고 나서야 출시되었고, 결과는 대성공이었습니다.

p57

애자일은 무계획/무관리 개발과 지나친 계획/관리 개발 사이에서의 타협점입니다.

p59

애자일 선언 이면의 원칙

우리의 최우선 순위는, 가치 있는 소프트웨어를 일찍 그리고 지속적으로 전달해서 고객을 만족시키는 것이다.

최고의 아키텍처, 요구사항, 설계는 자기 조직적인 팀에서 창발한다.

Part2 : 매니지먼트 역량

p72

팀 형성 과정

p77

따라서 상사라면 당연히 예측 가능한 상사가 되어야 합니다.

p78

이래도 되고 저래도 되는 일까지 자신의 의견을 관철할 필요는 없습니다. 정말 중요한 일을 관철하지 못하는 일이 발생하지 않도록 하는 게 더 중요합니다.

열에 여덟아홉 사소한 일에서 확실히 물러섭시다. 중요한 한두 건만 확실히 챙깁시다.

p79

탁월한 인사이트를 갖춘 리더라면 큰 물줄기를 발견해 흐름에 올라탑니다. 인사이트가 부족하면 지류로 조직을 내몰아 바다에 닿지 못하고 배를 땅에 처박을 겁니다.

p80

인사이트를 개발하기 위해서

업무 위주의 책만 보는 것이 아니라 인문이나 리더십 서적 등 다양한 주제의 책을 읽어야 하며, 사내와 외부 사람들 모두를 많이 만나보아야 합니다.

p81

중간 관리자 역할

현실적으로 개발 팀장이 세 가지 영역을 다 잘하기는 쉽지 않습니다. 관리자는 본인이 잘하는 것에 집중하고, 부족한 부분은 도움을 받아 메워야 합니다.

p85

Debugging the development process 책 소개

p86

원래부터 계획은 세우고 고치고 다시 세우고 고치기를 반복해야 하는 겁니다. 작심삼일이면 어떻습니까? 3일마다 계획을 세워 3일동안 실행하면 되지 않습니까?

p89

야구에서의 1루수, 2루수, 3루수 같이 포지션을 정해야 합니다. 급할 때는 1루수가 2루수 자리로 옮기기도 하니까요. 서로 포지션을 약간씩 겹치면서 충돌하면서 일해야 합니다.

p94

참고로 문제 해결뿐 아니라 모든 일에서 목표(goal), 계획(plan), 실행(action), 측정(measure)이 네 가지는 중요합니다.

p96

이처럼 중요도가 낮거나 해결할 수도 없는 일이라면 (리소스 때문이든 능력 때문이든) 머릿속에서 지워버리는 것도 방법입니다.

p97

할 일을 고를 때 급한가 급하지 않은가를 따지지 말고, 한 발 물러서서 ‘중요한가 중요하지 않은가'를 먼저 생각해야 합니다.

p98

프로젝트 리드는 역할, 낭비, 문제, 우선순위 이 모든 것을 총체적으로 관리해야 합니다. 그래야 큰 그림 안에서 안정적으로 일할 수 있습니다. 이 모든 것을 관리하므로 바쁩니다. 원래 바빠야 합니다. 본인은 바빠도 프로젝트 안에서 일하는 사람들은 안정적으로 일할 수 있게 해줘야 합니다.

p101

프로젝트 리드가 ‘What to do'를 고민한다면, 테크니컬 리드는 ‘How to do'를 고민합니다.

초보 개발자는 시키는 일을 잘하고, 중급 개발자는 시키지 않아도 일을 잘하고, 고급개발자는 남에게 시키는 일을 잘하면 됩니다. 그보다 위에 있는 고수 개발자는 모르는 일, 한 번도 안 해본 일을 하는 사람입니다.

p102

모르는 일을 쪼개고 나눠서 모르는 일 하나를 아는 일 100개로 만들어야 합니다.

p112

좋은 피플 매니저가 되려면 사람에 대한 마음이 있어야 합니다. ‘결국 다른 사람들이 행복했으면 좋겠다’, ‘다른 사람들이 일을 잘해서 만족감을 느꼈으면 좋겠다'를 생각하는 사람이죠.

p115

관리자와 직원의 관계는 정확한 기대치를 알려주고, 결과가 나왔을 때 좋았던 점과 아쉬웠던 점을 알려주며 피드백을 주는 사이가 좋은 관계입니다.

p118

관리자는 직원이 스스로의 성과, 행복, 성장을 확인하고, 뭔가 잘 안 되는 것 같아서, 아니면 더 잘하고 싶어서 관리자를 사용하게 해야 합니다.

p119

관리자도 직원이 리액티브한 삶을 사는 게 아니라 스스로 계획을 세워서 원하는 것을 관리자에게 받아내는, 프로액티브한 삶을 살도록 이끌어줘야합니다.

p120

성과 평가는 2주마다 진행한 면담 결과를 기반으로 합니다. 면담이 성과 평가의 힌트가 되는 겁니다. 면담 때마다 잘 한다는 평가를 했다면, 연말 성과 평가 때도 잘했다고 나와야 합니다.

p123

직원은 회사에서 의미 있는 일을 했을 때, 그때 가장 행복하고 만족감을 느낍니다.

p130

실패에 화를 내고 엄벌하는 분위기의 회사에서는 직원이 성장할 수 없다는 걸 기억해주세요.

어려운 일을 선택하면 이후에 선택의 폭이 넓어집니다. 그런데 한번 쉬운 일을 선택하면, 어려운 일로 돌아갈 수 없습니다.

p138

프로덕트 관리는 제품을 지속적으로 정의하는 행위이고, 프로젝트 관리는 제품을 만들어가는 과정을 운영하는 행위입니다.

Part3 비즈니스 역량

p152

그러므로 30년 커리어패스를 꿈꾼다면 기회가 될 때마다 경제경영 공부(투자)를 해둬야 합니다.

p154

조직은 지속적으로 변화해야 살아남습니다.

p158

문화를 미리 세워진 가치와 정책에 의해 결정되기 때문에, 먼저 비전과 가치가 결정이 되어야 그 뒤에 문화가 따라갑니다.

제품, 기술, 프로세스가 결과에 가깝다면 조직 문화를 모두를 아우르는 운영체제에 가깝습니다. 운영체제에 따라서 프로세스가 나오고 프로세스에 따라서 모든 일이 결정됩니다.

p162

2017년 조사에 따르면 구글과 MS의 근속연수는 평균 2년 정도

한 연구 결과에 따르면 잘못된 사람을 채용하면 그 사람 연봉의 2.5배에 해당하는 금액만큼 손해가 발생한다고 합니다. 그래서 오늘날 채용 제도는 좋은 살망르 뽑는 데 집중하기 보다는 잘못된 사람을 뽑지 않는데 더 집중합니다.

p172

버킴겅 궁전의 장미를 지키는 병사 일화. https://goldenrabbit.co.kr/2022/01/17/%EB%B8%94%EB%A6%AC%EC%9E%90%EB%93%9C%EC%9D%98-%EA%B0%9C%EB%B0%9C%ED%8C%80%EC%9D%80-%EA%B0%9C%EB%B0%9C%EC%9E%90%EB%A5%BC-%EC%96%B4%EB%96%BB%EA%B2%8C-%EC%B1%84%EC%9A%A9/ 에도 소개됨

p173

이력서는 여러 명이 봐야 하고, 가능하면 시스템을 구축해 쉽게 교차 검토가 가능하도록 만들어야 합니다.

p174

비교 가능한 데이터를 만들려면 같은 질문을 사용해야 합니다. 그래서 전화 면접에는 스크립트가 필수입니다.

p181

개발자는 어떤 자리, 어떤 회사를 목표로 해서는 안 됩니다. ‘어떤 사람이 돼야겠다’, ‘무엇을 해야겠다'를 목표로 삼아야 합니다. 어떤 회사에 지원하는 이유는 그곳에 하고 싶은 일이 있어서여야 하지, 꼭 특정 회사 특정 포지션을 고집해서는 안 됩니다.

p188

스티브 잡스의 말

“똑똑한 사람들을 고용해서 그들에게 무엇을 할지 알려주는 것은 이치에 맞지 않는다. 우리는 똑똑한 사람들을 고용해서 그들이 우리가 무엇을 해야 되는지 알려줄 수 있도록 해야한다.”

“It doesn’t make sense to hire smart people and tell them what to do; we hire smart people so they can tell us what to do”

p198

모든 것을 잘하는 직원은 훌륭한 관리자가 필요 없습니다. 반대로 문제가 많은 직원에게는 훌륭한 관리자가 필요합니다.

p208

약한 곳을 빨리 발견하려면 모두가 마음 놓고 자기 생각을 말할 수 있어야 합니다.

p214

변화를 만들려면 조직 문화를 정책(policy) -> 시스템(system) -> 문화(culture) 순서대로 살펴봐야 합니다.

Part4 개발자로 살아남기 30년

P225

시간관리는 결국 시간을 쓰는 프로세스를 바꾸는 겁니다. 반복해서 이야기했듯이 항상 목표로 계획을 세우고 실천한 뒤 측정해야 합니다.

p228

일주일 동안 계속 우선순위 하단에 위치해 처리하지 못한 일은 금요일 저녁에 그냥 없애버려도 됩니다. 다음주에 다시 적을 필요가 없습니다.

p235

시간을 벌고 싶다면 시간을 써야 합니다. 5% 정도 시간을 시간 관리가 투자해야 합니다.

p236

뭔가 답이 필요해서 토론을 해야 한다면, 반드시 회의를 하길 바랍니다. 메일은 일의 방향이 결정된 후 지시를 한다든지, 현황을 정리해 참고하는 용도에 적합합니다.

p238

정보 전달 회의는 하지 않는게 답입니다. 브레인스토밍 회의는 권장합니다. 토론회의는 정말 준비된 사람만 참여해야 합니다.

p247

개도국 시절에는 애국심 마케팅이 잘 먹히기 마련입니다. 게다가 1998년 내놓은 ‘아래아한글 815특별판'은 60만 카피 이상 파리는 기염을 토했습니다.

comments powered by Disqus