상세정보

일반적인 개발자들은 겸손한 태도로 자신이 맡은 역할을 성실히 그리고 묵묵히 해내고 있다. 그런데 그들의 손에 의해 빚어진 소프트웨어는 왜 거만한 모습으로 나타나는가? 이 책은 그 태생적이고 구조적인 원인을 적절한 예와 심플한 논조로 가볍게 풀어내고 있다.

일반적인 개발자들은 겸손한 태도로 자신이 맡은 역할을 성실히 그리고 묵묵히 해내고 있다. 그런데 그들의 손에 의해 빚어진 소프트웨어는 왜 거만한 모습으로 나타나는가? 이 책은 그 태생적이고 구조적인 원인을 적절한 예와 심플한 논조로 가볍게 풀어내고 있다.

- 개발자는 사용자를 잘 알고 있는가
- 프로젝트에 잘 맞게 정리된 방법론을 구체적인 현실에 제대로 구현하고 있는가
- 팀원 간에, 고객과의 관계에서 행하는 의사소통은 효과적인가
- 원활한 의사소통과 개개인의 암묵지를 담아낼 정도로 조직은 유연한가

이어서, 이 거만한 소프트웨어의 탄생을 막아낼 실천적 대안으로 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)이다.

- 무조건적 야근은 근본적인 해결책이 될 수 없을뿐더러 인센티브는 최종 보상이 되지 못한다. 내가 일하는 데서 보람을 얻는다는 느낌을 주는 것이 중요하다. 부서 사이에 협력이 되지 않을 때, 사일로가 생겼다고 한다. 다른 부서 사이에(디자인 부서+개발 부서) 존재하는 의견 대립에 타협점을 끌어내고 원래의 목표대로 팀을 이끌어 주는 제품 통합자가 필요하다.
- 개발자가 프로그램을 단순하게 만들면 사용자가 힘들다. 프로그램에 갖가지 기능을 넣었다고 외양을 복잡하게 만들어도 사용자가 힘들다. 가장 좋은 방식은 기능이 복잡하더라도 외양이 단순해 보이고 쓰기도 쉬워야 한다는 것이다.
- 프로젝트에 들어가기 전에 생각의 차이를 좁히고, 프로젝트 성격에 대한 합의를 거쳐야 프로젝트 진행에 있어 혼란이 적어진다.
- 사용자가 소프트웨어를 어떻게 사용하는지 알려면 인터뷰만 하지 말고 인터뷰와 동시에 그 사람이 어떻게 움직이며 어떻게 일하는지 관찰해야 한다. 일하는 맥락에서의 소프트웨어 사용법을 파악하는 것이 바로 맥락을 살피는 인터뷰다.
- 프로젝트 진행 시 그냥 반복하지 말고, 한 번 반복할 때마다 개선을 해 나가는 '지속적인 반복'이 필요하다.
- 일하면서 글로 적어두지 않은 경험과 노하우가 많다. 이런 것들을 정리해 조직적으로 학습을 해야 한다.
- 소프트웨어는 사람이 전부다. 오랫동안 부린 땅은 일정 기간 쉬게 해주듯이(아직 실현 가능성은 적지만) 사람에게도 안식년이라는 보상이 필요하다.

정보제공 :

목차
프롤로그 : 겸손한 개발자, 나대리 이야기 = 11
1장 과잉 친절의 시대, 그리고 거만한 소프트웨어
 과잉 친절의 시대 =  31
 No Software, It's Everyware! = 33
 거만한 소프트웨어란? = 37
 거만한 소프트웨어를 만드는 것들 = 40
2장 개발자는 사용자를 모른다
 보이는 것을 넘어서 = 43
 엘리베이터 버튼: 심성 모형 = 48
 Y를 깔았더니 X가 안되요!: 귀인 = 52
 앗! 나의 실수: 대응 = 57
 한글인가? 젠장 영어잖아!: 주의 소재 = 61
 사람한테 겨냥하지 마세요: 행동유도성 = 67
 카드를 삼킨 욕심쟁이 현금인출기: 피드백 = 73
 보기 좋은 떡이 맛있다!: 감성 = 76
 개성이 없는 자동차: 색각 장애 = 80
 정리 = 83
3장 GUI문제
 다다익선? = 85
 GUI, GUI, GUI = 90
 기술 주도의 발전, 그리고 마케팅의 탄생 = 99
 내가 필요한 건 믹서기 = 103
 지금까지 통한 법칙 = 106
 정리 = 107
4장 우리에게 있는 문제
 성공 신화 = 109
 '우리만 그렇다는 미신'과 '우리만 그런 현실' = 115
 방법론이라는 애물단지 = 120
 도덕적 해이? = 126
 정리 = 129
5장 조직의 문제
 그릇이 다르면 장맛이 다르다 = 131
 회사의 탄생 = 137
 사일로의 등장과 위기 = 145
 J-Firm vs. A-Firm = 148
 조직의 실패, 그리고 거만한 소프트웨어 = 150
 정리 = 157
6장 PAPER 원칙
 프로젝트 이야기 두 개 = 159
 쿨미디어 그리고 프로젝트 성공 = 167
 거만한 소프트웨어를 만드는 원인 = 171
 PAPER 원칙이란 = 172
7장 칼퇴근
 이념 논쟁 = 181
 팀워크가 전체주의가 될 때 = 183
 3M(Muda, Muri, Mura) = 184
 여유, 품질을 고민하는 시간 = 188
 숨겨진 야근 = 192
 근태가 성공 기준인 프로젝트 = 195
 이것만은 잊지 말자! = 196
8장 적절한 보상
 돈에 관한 몇 가지 단상 = 199
 관찰이 행동을 변화시킨다 = 203
 인센티브, 그 오묘함 = 205
 이 시대의 적절한 보상 = 209
 이것만은 잊지말자! = 211
9장 자리배치
 파놉티콘 = 213
 의상소통 게임 = 217
 프로젝트 룸 = 221
 이것만은 잊지 말자! = 225
10장 사일로를 파괴하라!
 팀을 구성하는 방법 = 227
 무한 도전과 교훈 = 230
 다양한 분야에서의 성공 = 231
 제품 통합자 = 237
 이것만은 기억하자! = 239
11장 단순함의 법칙
 메시지 창, 참을 수 없는 존재 = 241
 구현할 때 단순함 vs. 사용할 때 단순함 = 244
 구조조정이 정말로 필요한 곳 = 246
 소프트웨어 생태계 = 248
 단순함의 법칙 몇 가지 = 251
 이것만은 잊지 말자! = 256
12장 팀 빌딩
 비밀작전 같은 프로젝트 = 257
 프로젝트 관리계획 세우기, PMP만의 임무? = 259
 스파게티 회식, 그리고 프로젝트 시작 = 260
 팀 빌딩 방법 = 262
 이것만은 잊지 말자! = 271
13장 맥락을 살피는 인터뷰
 사용자를 아는 방법 = 273
 맥락을 살피는 인터뷰 방법 = 275
 맥락 인터뷰 해석하기 = 281
 이것만은 잊지 말자! = 289
14장 반복을 계획하라!
 지금까지 살펴 본 반복개발의 필요성 = 291
 팀 빌딩에서 세우는 최초 반복주기 = 294
 추청하기 = 300
 두 번재 반복주기부터 할 일 = 304
 이것은 잊지 말자! = 310
15장 암묵지를 조직화하라!
 배움의 시작 = 311
 학습의 방법 = 312
 조직적인 학습 = 315
 찻잔 속의 태풍 = 321
 이것만은 잊지 말자! = 323
16장 21세기 안식년
 이직과 손실 = 325
 암소 숭배 사상, 안식년 = 328
 이것만은 잊지 말자! = 333
17장 에필로그 = 334
감사의 글 = 338
주 = 339
참조한 책 = 345