옛날 책 버리기 전에 훑어보기

그냥 한번 훑어보면 될만한 책이다

사서 보기는 좀 아깝고…

다 아는 입장에서 보면 인덱스는 잘 돼 있네~ 라는 느낌인데

모르고 보면… 뭐가뭔지 싶을 것 같다.

예전에 본 책들 너무 쌓여서 정리중인데
이 책도 정리 대상으로 확정 되었다.
앞으로 다신 볼 것 같지도 않고 직원이나 동료나 후임이나 .. 등등 추천 해 줄 것 같지 않아서

문제점

요즘 책은 개념적인 부분만 나오고 실용적인 부분은 예제만 제공 해 주면 된다.
어차피 세부적인 코드나 설명은 다 기억도 못 하고 요즘엔 책을 레퍼런스로 보지 않으니까
예제를 실행이 되게 만들어 놓는다면 긴 설명도 필요 없다.

이 책은 개념 설명이 짧고 코드가 길다.

• Spring, Django, RoR, WPF, … 스타트 할 때 사용할만한 기술이면 코드가 필요할 수 있는데
  특정 상황에서만 사용하는 RabbitMQ, Kafka, ElasticSearch 등등은 필요없다.
• 요즘은 책을 다시 찾아보지 않고 인터넷에서 레퍼런스나 Stackoverflow 등을 검색한다.

책 내용

첫번째 장에서 짧게 RabbitMQ 구조와 개념 설명을 하고 뒤에서부터는 자바코드와 함께 개념을 조금씩 설명하는데…
개념이 겨우 이해가 안갈정도만 설명이 되어 있다.(이해가 안간다고. 다시 인터넷 찾아봄)
지식의 밀도가 낮다 보니 더 기억에 안 남는 것 같다.

소프트웨어 회사들이 흔히 하는 실수를 다 써 놨다.
이 업계에서 일하는 누가 읽어도 이거 우리회사 얘긴데.. 싶을거다.
(진짜 잘되는 회사 제외)

프로덕트 매니저의 업무 프레임워크

프레임워크라는 것은 베이스가 부족한 경우에도 필요하고
능숙하더라도 간혹 실수를 방지 해 주는 장치로 작용한다.

프로덕트 매니저로써 능숙하게 일을 하는 사람도
지금 프로덕트 매니저로 취업하거나
프로덕트 매니저 업무를 떠맡게 된 누구에게나 도움이 되지 않을까

인상깊은 내용

• 프로덕트 매니저란?
  • 번뜩이는 아이디어, 최첨단 기술이 아닌 프로덕트를 통해 해결해야 하는 문제에 주목
• 아무도 쓰지 않는 쓰레기를 만드는 것 = 개발함정
• 성과물 vs 산출물
  • 기능의 실제 가치를 확인하지 않고 개발하는것은 산출물… 뭔가가 나왔다
  • 성과물은 핵심 목표를 달성할 수 있는 것
• 이해관계자별 다른 목표(동상이몽) [목표]-[이유]
  • CEO 매년 30% 성장을 해야돼 – 그래야 다음라운드 투자를 받아
  • CTO 모바일 전략이 중요해 – 그래야 성과급을 받지
  • COO 비지니스 회원을 늘려야 해 – 그러면 수입이 늘어날거야
  • 그런데 이런식으로 각자 목표를 세우는게 문제라면… 이 문제의 해결책은 OKR이 아닐까

…

OKR과 마찬가지로 읽으면서 씁쓸하다
이건 상당히 센스의 영역이다.
읽고나서도 여기서 뭔가 느끼고 바꿀 수 있는 경영진이 얼마나 되려나

그리고 이 책이 프로덕트매니저의 시각에서 자기중심적으로 쓰여져서 그렇긴한데…
그 직무를 맡은 사람이 없어도 모든 구성원이 이렇게 사고해야한다.
우리나라 보통 IT회사에서는 개발팀장, 기획자, 디자이너, 그냥PM등 다양한 사람이 사실상 이 책에서의 프로덕트 매니저 포지션이기도 하고
프로젝트에 따라 누구나 프로덕트 매니저가 되기도 하니까

내용이 너무 자바처럼 verbose하다

짧은 내용을 너무 길게 설명해서 지겨워서 볼 수가 없다.

ex) ch07. 객체분해 p216~217 2페이지는 대략 이정도로 표현할 수 있다

일반적으로 작업기억은 7개의 chunk를 가지고 있다. 즉, 한번에 기억할 수 있는 숫자는 7개까지로 아래 11개의 연속된 숫자를 한번에 기억할 수 있는 사람은 드물다

29689928269

하지만 아래처럼 변환하면?

2968-992-8269

한번에 인식 가능하고 외울수도 있다.
11자리 숫자를 한번에 기억했다면 아마도 무의식중에 숫자를 나눴을 가능성이 높다

이런식으로 큰 문제를 작은 문제로 분해decomposite하면 문제를 이해하기 쉽고 더 좋은 해결이 가능하다.

이거 볼 시간에 DDD, JPA를 보자.
그래도 시간이 남으면 매트릭스와 에일리언을 보자

그냥 개발수필에 가깝다
코딩호러의 어쩌고 했던책이 더 재밌었던듯

이 책에서 뭔가 내용이 많이 나오긴 하는데
맞는말이긴 한데 그냥 맞는말뿐이라서 별로 뭔소린지 기억에 남지 않는다

마틴파울러나 GoF같은 유명한 책은 많이 읽은 사람인 것 같다
개발방법론이나 조직에 대해 많이 생각해봤던
10~20년쯤 소프트웨어 개발을 했던 프로그래머
대부분 그정도 근방의 이력을 가진 사람이면 해 봤을법한 생각들

아예 초년생이라면
감명받을 수도 있겠고
뭔소린가 싶을수도 있겠는데
한번 훑어보는게 도움이 되려나

이 책의 태그를 자기계발서로 넣은건…
기술서적이 아니기 때문.