-
-
프로그래머로 사는 법
샘 라이트스톤 지음, 서환수 옮김 / 한빛미디어 / 2012년 10월
평점 : 
1. 기초
CHAPTER 1 크게 성공하기
자신이 하는 일을 사랑하라. 즐겁고 자유롭게 일하라.
자기가 하고 싶은 일을 할 수 있는 자유
비용을 지불하고서라도 하고 싶은 일을 찾아라.
재미를 느낄 때는 열정과 에너지를 쏟으며 일할 수 있고, 더 많은 일을 할 수 있다.
장기적인 목표를 갖고 꾸준히 노력하지 않고 서는 크게 성공할 수 없다.
CHAPTER 2 좋은 소프트웨어란?
소비자의 요구와 시장이 원하고 수익을 창출하는 프로그램을 제공해라.
모든 일의 원동력은 결국 시장이다. (기존고객과 신규고객을 구분하라.)
많은 경우에 사람들은 물건을 직접 보여주기 전까지는 자기가 무엇을 원하는지 모른다.
우리가 생각하기에 고객이 원하는 것이 아닌 진정 고객이 원하는 것을 만들어라.
CHAPTER 3 학교 대 직장
학교는 어항이고 회사도 어항이다
세상을 볼 수 있는 시야가 극히 제한되어 있다.
CHAPTER 4 소프트웨어 개발 분야 직장 구하기
특정분야의 기술과 전문가 활동을 구체적으로 언급하자.
자신의 가치에 대한 차별성을 확실히 강조한다.
자신감과 겸손함을 동시에 나타낸다.
CHAPTER 5 소프트웨어 개발자 초기 시절 활용법
장기적인 관점으로 특정 분야의 전문가가 될 수 있는 능력을 중점적으로 개발하라.
리더나 멘토로부터 배워라.
좋은 멘토는 기술적인 면, 조직적인 면, 정치적인 면 등 다양한 차원에서 나아갈 길을 제시해 준다.
모두 함께 늙어가는게 인생이다. 10년쯤 지나면 모두가 변해 있을 것이다.
자기가 잘 할 수 있는 목록을 만들어라.
CHAPTER 6 필수 역량
업무 역량: 요건정의, 설계, 프로그래밍, 디버깅, SW 공학 등 기술적인 역량
업무 외 역량: 팀워크, 의사소통, 강연능력, 조직, 협상력, 멘토링, 인적관리, 리더십
성공의 비결 가운데 하나는 주어진 업무의 뛰어넘는 역량을 미리 개발하여 더 나은 성과를 증명
성장을 위한 기술 역량을 게을리 하지 말라. 지속적인 톱날 갈기
시간을 효율적으로 사용하라.
중요성 | 긴급성 |
급하고 중요함 (불끄기) | 중요하지만 급하지 않음 (알차게 보내는 시간) |
급하지만 중요하지 않음 (업무방해) | 급하지도 않고 중요하지 않음 (시간 낭비) |
CHAPTER 7 소프트웨어 R&D 조직
누가 무슨 일을 하나? 회사에는 여러 전문적인 역할이 필요하다.
위대한 프로그래머 한 명은 괜찮은 프로그래머 백 명보다 낫다.
조직에서 필요한 것은 소통, 소통, 소통이다. 시금치(보고, 연락, 상담)
내가 한일을 회사와 상사와 동료에게 겸손하고 진실하게 알려준다.
관리자는 갑자기 놀랄 만한 일이 일어나는 것을 좋아하지 않는다.
CHAPTER 8 경력을 말아먹는 법
소프트웨어 팀에서 가장 중요한 건 대인관계이다.
남을 화나게 하는 사람, 박H – 사람은 무시당한 기억이 오래간다.
남을 헐뜯는 사람, 윤JS – 은밀한 곳에서 한 얘기는 절대 비밀로 남지 않는다.
대책 없이 불평만 하는 투덜이, 윤JS – 사람을 지적하지 말고 문제에 초점을 잘 맞추자.
새로운 것에만 집착하는 사람, 여JH – 새로운 것에 너무 매달리게 되면 자신에게 도움이 되지 않는다.
조직 운영에 문제가 있는 사람, 김SG – 서로 다른 목표를 가진 사람을 하나의 목표로 가도록 동기부여
의사 결정에 문제가 있는 사람, 홍SY – 자신이 판단할 수 있는 것은 자기 선에서 적절히 대응
남의 공로를 인정하지 않는 사람, 박H – 동료에게도 적절한 영광을 돌려라.
2. 리더십
CHAPTER 9 조직생활
성공하기 위해서는 다른 사람들과 협상하고 협업하는 능력이 매우 중요하다.
이 메일에는 감성이나 영혼이 빠져 있어서 누군가에게 무엇을 설득하는 데 매우 취약하다.
아무리 좋은 사람이라고 해도 자신의 시간을 희생하면서까지 나를 돕지는 않는다.
신뢰는 사람들이 항상 얘기하는 사실이나 수치 이상의 영향력을 가진다.
l 대가를 바라지 않는 호의를 베푼다.
l 상부상조: 윈-윈 시나리오를 찾아라.
l 상대방의 업무와 가치를 높여주어 기를 살려준다.
l 영광을 명시적으로 공유한다.
l 직접 대면하여 소통하는 것이 감성적으로 밀접한 관계를 유지한다.
인맥을 구축하고 유지하는 데는 시간과 에너지가 든다.
협상은 상대방을 먼저 이해하는 것에서 시작된다.
협상하기 전에 결과를 예측해 보고 적절한 양보를 계획하라.
CHAPTER 10 소프트웨어 제안서 작성법
리더로 성공하려면 반드시 사업 제안서를 잘 쓸 줄 알아야 한다.
회사의 핵심 경쟁력과 차별화된 기술을 강조한다.
사람들의 동의를 얻고 제안을 승인 받기 위해서는 상당수를 우리 편으로 만들어야 한다.
설득력이 있는 엘리베이터 발표(10분 이내 핵심설명)
여러 의사결정권자의 조언과 논의를 거처 수정보안하고 참여와 공감을 이끌어 내라.
백 마디 말보다 그림 한 장이 낫고, 백 장 그림보다 데모 하나가 낫다.
CHAPTER 11 승진
고과는 직원의 기여도를 동료와 비교하여 따지는 것이기에 항상 상대적이다.
신뢰를 낫는다 - 그리고 신뢰가 전부다
자기 재능을 가장 잘 보여주는 유일한 지표는 바로 과거의 실적이다.
항상 자신이 그 일을 할 수 있는 사람이라는 것을 증명해야 한다.
준 실시간 의사소통을 통해 관리자와 주변 사람들에게 자신의 일을 알려주는 것이다.
1년 동안 수행한 중요한 업적, 영향력이 있는 일을 기록해 두고 소통으로 공유해라.
자기 목표를 분명히 파악하고 집중하는 것은 자신이 스스로 할 수 밖에 없다.
목표지향적인 사람은 처음부터 목표를 생각하고 시작한다. 목표에서 시작해서 거꾸로 계획을 세워라.
동료와의 감정 자산을 쌓기 위한 효과적인 방법은 공개적으로 칭찬하는 것이다.
승진을 위해서는 전문성을 갖고 열심히 일하고 계속해서 사업 기여도를 높이고 성과를 내야한다.
CHAPTER 12 시간 관리
시간 관리를 한다는 것은 무엇을 생산해내고 전문가로서 발전해 나갈 계획을 한다는 것이다.
목표 중심적인 시간 관리: 목표를 설정하고 그 것을 달성하는데 필요한 것을 반영하는 것을 시작한다.
목표 중심적인 시간 관리는 자기 목표를 달성하기 위해 해야 할 일을 제대로 이해하는 것이다.
과제 중심적인 시간 관리: 제한된 시간 안에 해야 할 과제를 이해하고 우선순위를 설정하는 것이다.
일간 및 주간 계획을 세울 때 과제 중심적인 시간 관리 방법을 많이 사용한다.
영향력의 영역(에너지와 시간을 집중)과 관심의 영역(업무로 집중할 때 부정적 영향이 있을 수 있다)
오늘 수행한 부족해 보이는 좋은 계획이 언제일지 모를 미래에 수행할 완벽한 계획보다 낫다.
전략적 결정이나 설계상의 선택은 정답이 아니라 적절한 타협점, 적당한 대안을 도출해내야 한다.
절박한 마음가짐은 두 배 이상의 생산성을 이끌어 낼 수 있을 만큼 강력하다. (삶과 일 중독을 조심)
CHAPTER 13 개발 일정을 맞추는 방법
한 명의 프로그래머가 일을 늦게 처리하면 팀 전체 파장이 미치고 개발팀을 넘어서 마케팅과 영업팁 등의 부서는 물론 고객에게까지도 그 효과가 퍼진다.
데이터를 보면 IT 프로젝트는 평균 84%가 지연되며, 계획된 출시일보다 20% 이내로 지연도 1/3 수준.
소프트웨어는 결국 전부 사람 문제이다. 대부분의 원인은 사람이고 인건비로 지출된다.
1. 범위 변경문제: 잦은 범위 변경, 단위 모듈의 복잡화
2. 인력 수준의 문제: 최고의 프로그래머는 일반적으로 몇 배가 넘는 생산성을 낸다.
3. 일정 지연 시 사람을 투입하면 더 느려진다. 맨먼스 미신
4. 개발팀의 목표가 불분명한 문제: 요건을 최대한 명확하게 정리하고 달성 목표를 설정.
5. 기능별 예상치를 그냥 더해서 생기는 문제. 여러 기능이 포함된 복잡한 모듈 존재.
6. 잘못된 추정치 문제 (비율 주의): 코딩은 개발 사이클에서 1/6 정도이다.
명세서 작성, 기능 설계, 프로그래밍, 기능 테스트, 통합 테스트, 시스템 테스트
7. 공격적인 추정치: 매우 낙관적이고 이상적인 일정은 결국 처음부터 지연을 내포한다.
8. 다른 개발자의 지연에 덩달아 늑장을 부리는 경우. 자신의 모듈에 많은 시간 할애.
“소프트웨어 개발에서 평균 기능은 가장 많이 지연된 기능에 따라 늘어난다.”
9. 소프트웨어 엔지니어링의 부재: 설계 안, 명세서, 코드, 테스트, 검토가 필요하다.
10. 예상치 못한 사건을 고려: 휴가, 병가, DB 이관, 서버다운, ……
11. “일찍, 자주 내놓는다.” 작은 기능으로 출시, 몇 개월 뒤 다음 버전 출시.
일정이 지연되는 경우에는 기능 줄이기, 기능 쪼개기, 재협상으로 조정해야 한다.
완벽한 정답은 없다 최대한 현명한 타협안을 찾는 것이다.
CHAPTER 14 균형의 기술
경력은 오랜 시간을 필요하기 때문에 스스로 즐길 수 있는 일을 해야 한다.
직업적으로 하는 일에서 재미있는 일과 별로 재미없는 일 사이의 균형을 잡아야 한다.
업무와 가족, 친구, 이웃, 취미활동에 할애하는 시간 사이에서 균형을 잡아야 한다.
중요한 것을 제대로 챙기지 못했다는 좌절감을 느낀다면 균형에 적신호가 온 것이다.
l 잠을 줄이는 것은 금물이다. 건강을 헤친다.
l 결국 일에 사용하는 시간을 줄일 수 밖에 없다.
l 가능하면 다른 사람에게 일을 위임하자.
l 오랜 시간이 걸려 보이는 일은 작업 일정을 더 늘려보자.
l 유사한 업무는 한번에 묶어서 처리한다.
l 여러 가지의 많은 일을 못하는 것보다 몇 가지의 일을 정말 잘하는 것이 좋다.
l 목표지향적인 시간 관리를 통해 낭비되는 시간을 줄이자.
소프트웨어 회사는 다른 직업 군과는 다르게 자유로운 기업 문화를 가져간다.
회사에 적응하지 못하면 일상생활에 필요한 에너지마저 고갈시킬 수 있다.
행복하고 만족스런 생활을 하고 있으면 회사에서 보다 더 몰두해서 생산적을 일할 수 있다.
최대한 현실적인 목표를 세운 다음 지금 상태를 거꾸로 바라보면서 일과 삶의 조화를 이뤄라.
“일과 삶의 조화”라는 문구에서 “삶”이라는 단어에 훨씬 더 큰 무게를 둬야 합니다.
CHAPTER 15 소프트웨어 프로젝트 관리의 비밀
“가만히 있지 말고 뭔가 고쳐내는 사람이 돼라.”
우주 계획과 프로젝트 관리 원칙
l 목표를 매우 구체적이고 분명하게 전달
l 측정 가능한 목표
l 달성 가능한 목표
l 현실적인 목표
l 구체적인 시간 계획 제시
프로젝트 관리 분야에서는 다섯 가지 원칙의 머리글자를 따서 SMART로 쓴다.
Specific: 구체성
Measurable: 측정 가능성
Attainable: 달성 가능성
Realistic: 현실성
Timely: 적시성
프로젝트를 관리한다는 것은 인간 본성을 관리한다는 것을 뜻한다.
l 사랑과 관심을 받는다는 느낌을 준다.
l 수시로 진행 현황 파악을 해야 일이 돌아간다.
l 지적을 할 때는 빠져나갈 구멍을 만들어 주어라.
학생은 적은 비용으로 때로는 매우 높은 생산성을 발휘 하기도 한다.
단기 인턴(4~8개월)보다는 장기 인턴(8~16개월)이 활용도가 높다.
개발하고 있는 소프트웨어의 정량적인 가치측정과 명확한 기능정의는 그 가치를 더욱 높인다.
소프트웨어 프로젝트 계획에서는 거의 항상 일이 계획한 대로 돌아가지 않는다.
새로운 목표가 추가될 수밖에 없다는 것을 처음부터 받아들일 수 있는 성숙한 팀 문화를 구축
반복 개발법(Iterative Development)
스크럼(Scrum)
애자일 개발 절차(Agile Development Process)
* 익스트림 프로그래밍(eXtreme Programming)
린 개발법(Lean Development)
폭포수 개발 절차(Waterfall Development Process)
래피드 프로토타이핑(Rapid Prototyping)
프로젝트 팀 성숙도 테스트
1. 우선순위가 높은 기능이 전부 들어가 있는 상태로 프로젝트를 완수했는가?
2. 결함 추적 시스템을 쓰고 있는가?
3. 팀에서 소스 코드 제어 시스템을 쓰고 있는가?
4. 결함 추적 시 따라야 할 절차를 분명히 알고 있는가?
5. 테스트를 정의하기 위한 테스트 계획을 작성하고 검토하는가?
6. 관련 사람들이 업무의 종료에 대한 것에 대해 분명히 이해하고 있는가?
7. 조기 피드백을 위한 알파/베타 프로그램이나 사용 성 조사를 하고 있는가?
8. 제품의 단기 사업 목표를 분명하게 이해하고 있는가?
9. 제품이 어떤 시장을 목표로 하고 있는지 분명하게 알고 있는가?
10. 개발팀이 프로젝트 완료일정과 중간 단계를 모두 분명하게 인식하고 있는가?
11. 코딩 단계가 30% 이상 진행되기 전에 제품 명세서를 완성하고 검토까지 끝내는가?
12. 명세서나 버그리포트, 사용자 시나리오와 같은 형태로 프로젝트 요건을 문서화 하는가?
13. 테스트 케이스의 80% 이상이 자동화 되어 있고 정기적으로 실행하고 있는가?
코드의 결함을 늦게 발견할수록 비용이 더 많이 든다.
성숙한 개발팀은 애초부터 코드 자체의 결함률이 낮고, 테스트 단계에서 결함을 잡아낸다.
결함을 조기에 발견하려면 설계서, 명세서, 코드 검토다.
테스트를 막판에 몰아서 하지 말고 개발 기간 내내 지속해서 수행한다.
테스트 과정은 버그를 다 잡아내기 위한 절차이기 보다 품질을 측정하는 통계적인 단계이다.
테스트만을 통해 최고 품질의 코드를 만들어내는 것은 불가능하다.
코드 품질을 개선하고 버그를 없애는데 있어서는 코드 검토가 가장 좋은 방법이다.
CHAPTER 16 빅 리그: 외야 안타에서 홈런까지
리더십이란 사람들이 가지고 있는 가치와 잠재력을 스스로 깨달을 수 있도록 분명하게 알려주는 일이다.
리더십을 위해서는 변화를 위한 비전, 카리스마, 훌륭한 실적, 신뢰감 등이 필요하다.
관리자는 일이 제대로 돌아가게 하는 사람이다.
리더는 새로운 길을 정의하고 사람들을 독려하고 힘을 불어넣는 사람이다.
3. 거성
CHAPTER 17 소프트웨어 혁신 리더십
왜 혁신인가?
성공하는 소프트웨어 혁신
혁신의 기회
브레인스토밍
가치 인식 사이클
혁신가의 12가지 원칙: 혁신을 성공적으로 키워내는 방법
99%의 노력
CHAPTER 18 빅 리그: 거물에서 선지자로
권위자가 된다
폭을 넓히자
스스로 새로운 개념과 기술을 습득할 수 있다고 믿는다
사업 수완
특허
각종 출판물
공공 발표
성공은 좋은 스승이 못 된다
고급 소셜 네트워킹 (괴짜들을 위한 사회 친화력 증강제)
예술을 완성하기 위한 열정과 프로세스
CHAPTER 19 지금 알고 있는 걸 그때도 알았더라면…
초기 적응 기간
상사
동료
상사 관리하기
기회 창출
준비될 때까지 기다리면 너무 늦다
CHAPTER 20 홀로서기: "소프트웨어 스타트업"
좋은 아이디어 대 좋은 회사
사업 계획서와 피치
R&D 착수
자금 조달
매출 달성
골을 넘어서
날렵하고 빠르게
성장 대 인수 합병
인수 합병 전략
CHAPTER 21 보상
회사 유형에 따른 보상 차이
보상, 승진과 학위
스톡 옵션
스톡 그랜트
상여금
퇴직금
일반적인 급여 수준 (2010-2013)
간접적인 보상
전반적인 고려사항
CHAPTER 22 성공하기
어떤 사람이 성공하는가?
성공이란 어떤 것일까?
왜 어떤 사람은 못 하거나 안 하는가?
부록. 우리가 프로그래머로 살아가는 법
기획의 말, 40세 개발자는 가능한가?
지방대 대학생의 BPC 수상기
유학생의 미국 소프트웨어 엔지니어 구직 인터뷰
좌충우돌 스타트업 생존기
프로그래머의 공부
길고 구부러진 길
엔지니어가 실수하는 것들
대한민국에서 나이 많은 개발자가 살아남는 법
어떻게 프로그래머로 살까?
우연히 시작한 개발자의 꿈, 아직도 진행형