 |
|
 |
|
 |
 |
|
    |
SNS (페이스북, 트위터, 미투데이, MSN) 를
통해 YES24의 상품정보를 빠르게 추천하고,
편리하게 공유할 수 있습니다. |
|
 |
 |
원하는 서비스의 버튼 클릭 |
 |
해당 서비스 로그인 |
 |
SNS에 상품정보 자동입력 |
 |
상품정보 보내기 완료 |
|
|
|
 |
|
 |
-
- 출간일
-
2009년 04월 13일
347쪽 | 578g | 145*222mm
- ISBN-13
9788991268586
ISBN-108991268587
- 판매중
| 판매지수 522
- 배송비
- 무료
- 주문수량
-
- 해외배송가능, 최저가 보상
사람, 소통이라는 키워드를 던지고 있는 소프트웨어 개발 이론서
개발자들은 겸손한 태도로 자신이 맡은 역할을 성실히 그리고 묵묵히 해내고 있다. 그러나 그들이 만들어 내는 소프트웨어는 왜 거만한 모습으로 나타나게 되는 것인가? 이 책은 적절한 예와 단순한 논조를 통해 그러한 원인을 발생시키고 있는 태생적인 구조를 살펴보고 있는 책이다. 현직 개발자나 관리자를 위한 내용이기도 하지만, 소프트웨어 개발방법을 배우는 학생들에게도 시사점을 던져주고 있다. 거만한 소프트웨어가 나오는 원인을 살펴보고 이러한 원인을 제거하기 위한 PAPER원칙을 제시함으로써, 소프트웨어 개발의 원리를 제시하고 있다.
프롤로그 겸손한 개발자, 나대리 이야기
1장 과잉 친절의 시대, 그리고 거만한 소프트웨어
1-1 과잉 친절의 시대
1-2 No Software, It’s Everyware!
1-3 거만한 소프트웨어란?
1-4 거만한 소프트웨어를 만드는 것들
2장 개발자는 사용자를 모른다
2-1 보이는 것을 넘어서
2-2 엘리베이터 버튼: 심성 모형
2-3 Y를 깔았더니 X가 안 되요!: 귀인
2-4 앗! 나의 실수: 대응
2-5 한글인가? 젠장 영어잖아!: 주의 소재
2-6 사람한테 겨냥하지 마세요: 행동유도성
2-7 카드를 삼킨 욕심쟁이 현금인출기: 피드백
2-8 보기 좋은 떡이 맛있다!: 감성
2-9 개성이 없는 자동차: 색각 장애
정리
3장 GUI 문제
3-1 다다익선?
3-2 GUI, GUI, GUI
3-3 기술주도의 발전, 그리고 마케팅의 탄생
3-4 내가 필요한 건 믹서기
3-5 지금까지 통한 법칙
정리
4장 우리에게 있는 문제
4-1 성공신화
4-2 ‘우리만 그렇다는 미신’과 ‘우리만 그런 현실’
4-3 방법론이라는 애물단지
4-4 도덕적 해이?
정리
5장 조직의 문제
5-1 그릇이 다르면 장맛이 다르다
5-2 회사의 탄생
5-3 사일로의 등장과 위기
5-4 J-Firm vs. A-Firm
5-5 조직의 실패, 그리...프롤로그 겸손한 개발자, 나대리 이야기
1장 과잉 친절의 시대, 그리고 거만한 소프트웨어
1-1 과잉 친절의 시대
1-2 No Software, It’s Everyware!
1-3 거만한 소프트웨어란?
1-4 거만한 소프트웨어를 만드는 것들
2장 개발자는 사용자를 모른다
2-1 보이는 것을 넘어서
2-2 엘리베이터 버튼: 심성 모형
2-3 Y를 깔았더니 X가 안 되요!: 귀인
2-4 앗! 나의 실수: 대응
2-5 한글인가? 젠장 영어잖아!: 주의 소재
2-6 사람한테 겨냥하지 마세요: 행동유도성
2-7 카드를 삼킨 욕심쟁이 현금인출기: 피드백
2-8 보기 좋은 떡이 맛있다!: 감성
2-9 개성이 없는 자동차: 색각 장애
정리
3장 GUI 문제
3-1 다다익선?
3-2 GUI, GUI, GUI
3-3 기술주도의 발전, 그리고 마케팅의 탄생
3-4 내가 필요한 건 믹서기
3-5 지금까지 통한 법칙
정리
4장 우리에게 있는 문제
4-1 성공신화
4-2 ‘우리만 그렇다는 미신’과 ‘우리만 그런 현실’
4-3 방법론이라는 애물단지
4-4 도덕적 해이?
정리
5장 조직의 문제
5-1 그릇이 다르면 장맛이 다르다
5-2 회사의 탄생
5-3 사일로의 등장과 위기
5-4 J-Firm vs. A-Firm
5-5 조직의 실패, 그리고 거만한 소프트웨어
정리
6장 PAPER원칙
6-1 프로젝트 이야기 두 개
6-2 쿨미디어 그리고 프로젝트 성공
6-3 거만한 소프트웨어를 만드는 원인
6-4 PAPER 원칙이란
7장 칼퇴근
7-1 이념 논쟁
7-2 팀워크가 전체주의가 될 때
7-3 3M, Muda, Muri, Mura
7-4 여유, 품질을 고민하는 시간
7-5 숨겨진 야근
7-6 근태가 성공 기준인 프로젝트
7-7 이것만은 잊지 말자!
8장 적절한 보상
8-1 돈에 관한 몇 가지 단상
8-2 관찰이 행동을 변화시킨다
8-3 인센티브, 그 오묘함
8-4 이 시대의 적절한 보상
이것만은 잊지 말자!
9장 자리 배치
9-1 파놉티콘
9-2 의사소통 게임
9-3 프로젝트 룸
9-4 이것만은 잊지 말자!
10장 사일로를 파괴하라!
10-1 팀을 구성하는 방법
10-2 무한 도전과 교훈
10-3 다양한 분야에서의 성공
10-4 제품 통합자
이것만은 기억하자!
11장 단순함의 법칙
11-1 메시지 창, 참을 수 없는 존재
11-2 구현할 때 단순함 vs. 사용할 때 단순함
11-3 구조조정이 정말로 필요한 곳
11-4 소프트웨어 생태계
11-5 단순함의 법칙 몇 가지
이것만은 잊지 말자!
12장 팀 빌딩
12-1 비밀작전 같은 프로젝트
12-2 프로젝트 관리계획 세우기, PM만의 임무?
12-3 스파게티 회식, 그리고 프로젝트 시작
12-4 팀 빌딩 방법
이것만은 잊지 말자!
13장 맥락을 살피는 인터뷰
13-1 사용자를 아는 방법
13-2 맥락을 살피는 인터뷰 방법
13-3 맥락 인터뷰 해석하기
이것만은 잊지 말자!
14장 반복을 계획하라!
14-1 지금까지 살펴 본 반복개발의 필요성
14-2 팀 빌딩에서 세우는 최초 반복주기
14-3 추정하기
14-4 두 번째 반복주기부터 할 일
이것만은 잊지 말자!
15장 암묵지를 조직화하라!
15-1 배움의 시작
15-2 학습의 방법
15-3 조직적인 학습
15-4 찻잔 속의 태풍
이것만은 잊지 말자!
16장 21세기 안식년
16-1 이직과 손실
16-2 암소 숭배 사상, 안식년
이것만은 잊지 말자!
에필로그
주
참조한 책
일반적인 개발자들은 겸손한 태도로 자신이 맡은 역할을 성실히 그리고 묵묵히 해내고 있다. 그런데 그들의 손에 의해 빚어진 소프트웨어는 왜 거만한 모습으로 나타나는가? 이 책은 그 태생적이고 구조적인 원인을 적절한 예와 심플한 논조로 가볍게 풀어내고 있다.
- 개발자는 사용자를 잘 알고 있는가
- 프로젝트에 잘 맞게 정리된 방법론을 구체적인 현실에 제대로 구현하고 있는가
- 팀원 간에, 고객과의 관계에서 행하는 의사소통은 효과적인가
- 원활한 의사소통과 개개인의 암묵지를 담아낼 정도로 조직은 유연한가
이어서, 이 거만한 소프트웨어의 탄생을 막아낼 실천적 대안으로 PAPER원칙을 제안한다.
1. Peopleware
2. Active involvement
3. simPlicity
4. Experience
5. Repetition
6. PAPER
프롤로그; 여기서 치이고 저기서 치이는 겸손한 개발자 나대리, 온갖 악조건 하에서도 열심히 개발했지만, 결과는 사용자의 불만 가득한 목소리뿐이다. 그 원인은 무엇인가?
1~5장: 거만한 소프트웨어가 나오는 원인을 짚어 본다.
사용자와 개발자의 인식의 차이, 효율성만 쫓는 권위적인 조직 그리고 개인 간 의사소통의 실패, 이 모든 원인이 어우러져 거만한 소프트웨어가 탄생하게 된다.
- 하이테크 제품이라도 낮은 수준의 소프트웨어를 탑재하면, 품질 딱 그 소프트웨어의 수준만큼 떨어진다. 제품의 질만 떨어뜨리고, 사용자를 고려하지 않은 소프트웨어, 그것이 거만한 소프트웨어다.
- 사용자는 개발자가 생각한 대로 소프트웨어를 쓰지 않는다. 화성에서 온 개발자, 금성에서 온 사용자처럼 한 가지 소프트웨어에서 두 가지 사용법을 발견하기도 한다. 개발자는 사용자의 심리를 잘 이해하면서 소프트웨어를 만들어야 한다.
- 기능이 너무 많아도 사용자는 혼란스럽다. 꼭 필요한 기능을 직관적으로 쓸 수 있게 만들어야 한다.
- 실패를 개선의 기회로 바꾸지 않는 조직, 방법론만 적용하면 모든 게 잘 될 것이라는 착각에 빠진 조직, 효율화라는 명목으로 직원들을 내보내고 아웃소싱에 개발을 맡기는 조직, 단기적으로는 효율적이지 모르지만 장기적으로 손해를 입을 것이다.
6~16장: 그럼 이것의 원인을 어떻게 제거할 것인가?
해답은 PAPER 원칙을 실천하는 것이다. PAPER 원칙은 그 원인을 제거하는 실천법(People, Active involvement, simPlicity, Eexperience, Repitition & Paper)이다...일반적인 개발자들은 겸손한 태도로 자신이 맡은 역할을 성실히 그리고 묵묵히 해내고 있다. 그런데 그들의 손에 의해 빚어진 소프트웨어는 왜 거만한 모습으로 나타나는가? 이 책은 그 태생적이고 구조적인 원인을 적절한 예와 심플한 논조로 가볍게 풀어내고 있다.
- 개발자는 사용자를 잘 알고 있는가
- 프로젝트에 잘 맞게 정리된 방법론을 구체적인 현실에 제대로 구현하고 있는가
- 팀원 간에, 고객과의 관계에서 행하는 의사소통은 효과적인가
- 원활한 의사소통과 개개인의 암묵지를 담아낼 정도로 조직은 유연한가
이어서, 이 거만한 소프트웨어의 탄생을 막아낼 실천적 대안으로 PAPER원칙을 제안한다.
1. Peopleware
2. Active involvement
3. simPlicity
4. Experience
5. Repetition
6. PAPER
프롤로그; 여기서 치이고 저기서 치이는 겸손한 개발자 나대리, 온갖 악조건 하에서도 열심히 개발했지만, 결과는 사용자의 불만 가득한 목소리뿐이다. 그 원인은 무엇인가?
1~5장: 거만한 소프트웨어가 나오는 원인을 짚어 본다.
사용자와 개발자의 인식의 차이, 효율성만 쫓는 권위적인 조직 그리고 개인 간 의사소통의 실패, 이 모든 원인이 어우러져 거만한 소프트웨어가 탄생하게 된다.
- 하이테크 제품이라도 낮은 수준의 소프트웨어를 탑재하면, 품질 딱 그 소프트웨어의 수준만큼 떨어진다. 제품의 질만 떨어뜨리고, 사용자를 고려하지 않은 소프트웨어, 그것이 거만한 소프트웨어다.
- 사용자는 개발자가 생각한 대로 소프트웨어를 쓰지 않는다. 화성에서 온 개발자, 금성에서 온 사용자처럼 한 가지 소프트웨어에서 두 가지 사용법을 발견하기도 한다. 개발자는 사용자의 심리를 잘 이해하면서 소프트웨어를 만들어야 한다.
- 기능이 너무 많아도 사용자는 혼란스럽다. 꼭 필요한 기능을 직관적으로 쓸 수 있게 만들어야 한다.
- 실패를 개선의 기회로 바꾸지 않는 조직, 방법론만 적용하면 모든 게 잘 될 것이라는 착각에 빠진 조직, 효율화라는 명목으로 직원들을 내보내고 아웃소싱에 개발을 맡기는 조직, 단기적으로는 효율적이지 모르지만 장기적으로 손해를 입을 것이다.
6~16장: 그럼 이것의 원인을 어떻게 제거할 것인가?
해답은 PAPER 원칙을 실천하는 것이다. PAPER 원칙은 그 원인을 제거하는 실천법(People, Active involvement, simPlicity, Eexperience, Repitition & Paper)이다.
- 무조건적 야근은 근본적인 해결책이 될 수 없을뿐더러 인센티브는 최종 보상이 되지 못한다. 내가 일하는 데서 보람을 얻는다는 느낌을 주는 것이 중요하다. 부서 사이에 협력이 되지 않을 때, 사일로가 생겼다고 한다. 다른 부서 사이에(디자인 부서+개발 부서) 존재하는 의견 대립에 타협점을 끌어내고 원래의 목표대로 팀을 이끌어 주는 제품 통합자가 필요하다.
- 개발자가 프로그램을 단순하게 만들면 사용자가 힘들다. 프로그램에 갖가지 기능을 넣었다고 외양을 복잡하게 만들어도 사용자가 힘들다. 가장 좋은 방식은 기능이 복잡하더라도 외양이 단순해 보이고 쓰기도 쉬워야 한다는 것이다.
- 프로젝트에 들어가기 전에 생각의 차이를 좁히고, 프로젝트 성격에 대한 합의를 거쳐야 프로젝트 진행에 있어 혼란이 적어진다.
- 사용자가 소프트웨어를 어떻게 사용하는지 알려면 인터뷰만 하지 말고 인터뷰와 동시에 그 사람이 어떻게 움직이며 어떻게 일하는지 관찰해야 한다. 일하는 맥락에서의 소프트웨어 사용법을 파악하는 것이 바로 맥락을 살피는 인터뷰다.
- 프로젝트 진행 시 그냥 반복하지 말고, 한 번 반복할 때마다 개선을 해 나가는 '지속적인 반복'이 필요하다.
- 일하면서 글로 적어두지 않은 경험과 노하우가 많다. 이런 것들을 정리해 조직적으로 학습을 해야 한다.
- 소프트웨어는 사람이 전부다. 오랫동안 부린 땅은 일정 기간 쉬게 해주듯이(아직 실현 가능성은 적지만) 사람에게도 안식년이라는 보상이 필요하다.
|
카트
