이미지 출처 : https://www.yes24.com/Product/Goods/125116480
언급된 도서 Sometimes you win, sometimes you learn 아주 작은 습관의 힘’(Atomic Habits) 결정적 순간의 대화 감상 2024.05.05 긴 호흡으로 경력을 돌아보고 내다보라는 격려를 책에서 받았습니다.
인상 깊은 단락 p8 밑으로 떨어지는 경험을 해봐야 감사하는 마음으로 다시 올라갈 힘이 생긴다. 인간 관계는 수단이 아닌 목적이어야 한다고, 실패는 나침반이라고 나 자신에게 전해주고 싶다.
p20 하지만 후반기(3년)에는 시장에서 야후가 구글에 밀리면서 회사 내부가 정치적으로 변해갔다.
이미지 출처 : http://www.yes24.com/product/goods/105645204
정리 핵심키워드 정리
엔지니어링 역량 : 성장하는 10년 개발에 대한 기본 지식 : 언어, 도구, 비판적 사고(Critical thinking) 제품 디자인 : A/B Testing, 데이터 주도개발, 도그푸딩 등 개발 주기 지식 : 애자일 매니지먼트 역량 : 리딩하면서 일하는 10년 프로젝트 리드 : 계획 세우기, 역할 나누기, 시간 아끼기, 문제 해결, 우선 순위 테크니컬 리드 : How to를 고민, 모르는 일을 쪼개기 피플 매니징 : 성향 파악하기, 면담, 성과 평가, 행복 만들기, 성장시키기 프로세스 관리 : 프로세스 정립, 시스템 도입 등 비즈니스 역량 : 서포트하는 10년 채용 : 채용 목표와 원칙 세우기, 프로세스 운용 사업 만들기 : 성장 전략, 수익화, 팀빌딩 비전과 조직 문화 만들기 시간관리 목표,계획,실천,측정 싸이클 우선 순위 관리 이메일, 회의 최적화, 휴식 인상 깊은 단락 프롤로그 p12 저는 농담으로 디렉터를 정의하며 이런 표현을 씁니다.
감상 2020.04.18 멘티 개발자, TL, 매니저 등 단계별로 신경을 써야 할 일들을 이 책에서 체계적으로 정리했다고 느껴집니다. 미국 IT 업계를 배경으로 하고 있지만 국내 IT회사에 다니는 분들도 공감이 갈만한 지점이 많습니다. 1On1 미팅을 강조하고 있다는 점도 인상적입니다.
2020.06.30 ‘실리콘밸리의 팀장들’ , ‘개발7년차, 매니저 1일차’, ‘슬랙’ 을 읽고 느낀 점
다른 사람과 협업을 하는 모든 개발자는 ‘관리'의 영역에 있는 일을 신경써야 한다. 관리 업무에서 가장 중요한 지점은 ‘명확한 피드백'을 전달하는 것이고, 때로는 불편한 피드백을 주어야 하는 경우도 있다.
감상 구글/애플에서 관리자를 경험을 하고, 애플대학교에서 ‘애플경영법'을 강의했던 킴스콧이 쓴 책. ‘조직 내에서 건설적이지만 불편할 수도 있는 피드백을 어떻게 잘 주고 받을 것인가?‘가 이 책의 핵심 화두이다. 중간중간 나오는 쉐릴 샌버그, 에릭슈미츠, 스티브잡스 같은 거물들의 일화들도 흥미롭다.
인상 깊은 단락 33 (‘최고의 상사는 감정노동의 달인’ 단락)
사람들은 상사가 느끼는 ‘감정 노동'을 과소평가하며, 대개 서비사람들은 상사가 느끼는 ‘감정 노동'을 과소평가하며, 대개 서비스나 의료 산업에 종사하는 사람들, 예를 들면 정신과 의사나 간호사, 웨이터 항공 승무원이 느끼는 일로 치부한다.
http://ebook.insightbook.co.kr/book/65 에서 PDF로 구매할 수 있다.
https://www.yes24.com/Product/Goods/67350256?OzSrank=1
관련 링크 https://zzsza.github.io/etc/2018/12/16/agile-together/ 인상깊은 내용 p31 자기계발이 왜 중요하다고 생각하냐면, 현재 나에게 무엇을 투자했느냐가 1년, 혹은 2년 후의 나를 결정한다고 느끼기 때문입니다. 예를 들어 올해 업무도 잘한 것 같고 사람들에게 인정을 받은 것 같다면 1~2년 전을 잘 되돌아봅니다. 아마 그때 열심히 자기투자를 했을 겁니다. 반대로 올해 읽은 책도 몇 권 없고 새로 얻은 통찰도 없다면 지금 당장은 별 문제없는 것 같지만 (예를 들어 올해 내 연봉은 만족스러우나) 내년이나 내후년에는 분명 추락을 경험할 것입니다.
인상깊은 내용 36쪽 번다운 차트 사용
38쪽 또 다른 위험은 ‘자원 안배를 잘 못해서 잃어버리는 시간'이다. 어려운 문제인 줄 정작알았더라면 개발자를 두세 명 더 투입하거나 선임 개발자를 붙였을 게다. 팀원들이 프로젝트 위험을 줄이려고 노력하기보다 기능 날짜를 맞추는데만 급급하다면 프로젝트는 그만큼 소중한 시간을 잃는다.
40쪽 기존공학이 수백 아니 수천 년에 걸쳐 쌓아온 경험적 예측성을 소프트웨어 공학에서 기대해서는 안된다.
42쪽 기능 완료일을 맞추라고 팀을 닦달하면 팀은 편법으로날짜를 맞추거나 거짓말을 둘러댄다.
https://www.yes24.com/Product/Goods/3600609
감상 2024.02.15 다시 읽어보면 떠오르는 일들이 더 많을 것 같다.
2010.01.21 특히나 더 인상 깊은 단락들
모든 설계 결정을 내리는 영웅이나, 모든 요구사항을 결정하는 영웅이나, 모든 아키텍처 결정을 내리는 영웅이 바로 병목을 일으키는 원인이다
최근 ‘지나친 의욕은 민폐를 불러일으킨다'라는 말이 몇번 떠올랐는데, 일맥상통하는 내용이이다.
흔히 프로세스 개선 그룹, 표준 제정 그룹, 품질 부서 등이 업무 프로세스나 수행방식을 명시한다. (중략) 대개 그들은 업무를 제대로 이해하지도 못하면서 업무 방식을 정해주는 외부인에 불과하다
인상 깊은 단락 p53 업무의 구분
프로젝트 업무 임시 업무 지속 업무 정기 업무 관리 p83 사람은 한 번에 한 프로젝트에 배치하세요
p89 팀과 부서의 차이
일반적으로 작다. 즉 다섯명에서열 명의 구성원으로 이뤄진다. 공동의 목적이나 목표가 있다. 일 처리시 서로 합의한 접근 방식이 있다. 서로 보완하는 능력이 있다. 상호 관련되거나 서로 독립적인 임시 목표가 있다. 서로에게 넘겨줄 작업을 약속한다. p200 효과적인 피드백을 위한 지침.
인상 깊은 부분 49쪽 사람들은 안전하다고 느끼지 않는 한 변화를 수용하지 않는다.
62쪽 협박은 실적을 유도하기에는 불완전한 방법이다.
98쪽 최소한 단기간에 생산성을 높이기 위해서 할 수 있는 일은 사실상 아무것도 없기 때문에 제 생각에는 시간을 헛되게 쓰지 않도록 하는데 전적으로 맞추게 될 거에요
102쪽 생산성에 관한 단기적인 해결방법은 없다. 생산성 향상은 장기적인 투자의 결과다.
112쪽 프로젝트 초기에 잃어버린 한시간은 프로젝트 마지막에 잃어버린 하루와 같은 손실이 된다.