PART 01 가깝고도 먼 개발자
1. 어딘가 이상한 비전공자의 협업
- 기획자 김 군의 협업
- 디자이너 김 양의 협업
- 우리가 협업을 할 수 있었던 이유
2. 온몸으로 느낀 개발자
- 우리가 만난 세 가지 유형의 개발자
- 협업을 잘하는 개발자
- 개발자에게 하면 안 되는 말
3. 협업을 위한 준비물
- 원활한 협업을 위한 준비
- 개발 지식을 쌓는 순서
PART 02 기획자의 일
1. 서비스 기획 들여다보기
- 서비스 기획의 범위
- 인하우스와 에이전시의 기획자
- 이유와 기준이 있는 기획
- 시각화를 통한 최종 점검
2. 협업을 위한 사전 준비
- 전체를 한눈에 파악하는 IA
- 웹 사이트의 계층 구조 이해
- 목적 중심의 벤치마킹
3. 협업을 돕는 화면 설계서
- 화면 설계서를 작성하는 이유
- 목적을 명확하게 전달하는 방법
- 설계서 타이틀의 중요성
- 스토리텔링을 위한 화면 설계서
- 리뷰를 요청하는 방법
PART 03 디자이너의 일
1. 디자이너의 마인드셋
- 디자인 기획 의도와 목적
- 웹/앱 디자인과 UI/UX 디자인
- 경쟁력을 갖춘 디자이너
2. 정확한 시각화를 위한 개발 지식
- 웹 디자인의 색상
- 이미지/영상
- 폰트
- 해상도
- 프로토타이핑
3. 협업을 위한 개발 지식
- 웹 표준과 웹 접근성
- 크로스 브라우징
- 크롬의 개발자 도구
- 레이아웃
- 모바일 웹
- 그리드
- 앱 디자인 고려하기
- 놓치기 쉬운 항목 체크하기
PART 04 개발자의 일
1. 개발자 이해하기
- 웹 개발자
- 모바일 개발자
- 소통에 필요한 개발 용어
2. 생산성 향상을 위한 협업 툴
- 커뮤니케이션 도구
- 기획자/디자이너의 협업 도구
3. 개발자가 말하는 협업
- 2년 차, 대기업 개발자
- 4년 차, 중소기업 개발자
- 6년 차, 프리랜서 개발자
- 10년 차, 에이전시 개발 CTO
오늘도 개발자가 안 된다고 말했다
김중철님 외 1명
240p

![[운영] <햄넷> 20% 할인_보드배너](https://an2-img.amz.wtchn.net/image/v2/Og9Y6ZnKP4IMflSnEYv7Qg.jpg?jwt=ZXlKaGJHY2lPaUpJVXpJMU5pSjkuZXlKdmNIUnpJanBiSW1KbklsMHNJbkFpT2lJdmRqSXZjM1J2Y21VdmNISnZiVzkwYVc5dUx6RXlPRGszTkRrMk1UQXhNRGcxTkNKOS5ReWRaV0RSNGQwUTVVakl3OE9rVVI3aGtDaTQ0M0Z2UDJRcWtMWE1XRVlv)
![[운영] <햄넷> 20% 할인_보드배너](https://an2-img.amz.wtchn.net/image/v2/rMHEMZTez3HUfl62RTIWyQ.jpg?jwt=ZXlKaGJHY2lPaUpJVXpJMU5pSjkuZXlKdmNIUnpJanBiSW1KbklsMHNJbkFpT2lJdmRqSXZjM1J2Y21VdmNISnZiVzkwYVc5dUx6TXlOalF3T0RNeE16VTFNelU1SW4wLmdKeXkxbzVrdkExNndqcUMyQW1RX21vaDVFVlZCczNFVUd2ZTUtS1hybEk=)
IT 비전공자 2명이 각각 기획자, 디자이너로 일하면서 겪은 협업 경험을 녹여낸 ‘개발 협업 가이드북’이다. 이 책은 개발자와의 소통이 어려운 기획자나 디자이너에게 도움이 되고자 하는 취지에서 만들었으며, 저자들의 경험담, 현업 개발자들의 경험을 바탕으로 개발자와 좀 더 원활하게 협업하기 위한 정보, 지식을 다루었다. 이 책의 주요 대상은 IT 기업에 근무하는 신입 기획자와 디자이너이지만, 기획자와 디자이너의 일과 역할이 궁금한 개발자에게도 조금이나마 도움이 될 것이다. 아무런 개발 지식이 없는 상태에서 시작하여 지금까지 어떻게 개발자와 협업을 할 수 있었는지, 협업 과정에서 일어나는 갈등을 어떻게 해결하는지, 공동의 목표를 가지고 어떻게 협업을 해야 하는지 알고 싶다면 이 책을 추천한다.
쾌감폭발 완벽 필승 조합
크리스 헴스워스 VS 마크 러팔로
크라임 101 · AD
쾌감폭발 완벽 필승 조합
크리스 헴스워스 VS 마크 러팔로
크라임 101 · AD
구매 가능한 곳
본 정보의 최신성을 보증하지 않으므로 정확한 정보는 해당 플랫폼에서 확인해 주세요.
저자/역자
코멘트
5목차
출판사 제공 책 소개
“C를 배워보세요. 코딩의 본질을 제대로 이해할 수 있어요!”“Java를 배워보세요. 써먹을 곳이 많고 우리나라에서 많이 사용해요!”“Python을 배워보세요. 코딩이 처음인 사람도 쉽게 배울 수 있어요!”개발자와 협업을 잘하려면 개발 언어를 배워야 한다? 기획자, 디자이너가 개발자와 협업을 잘하려면 개발 언어를 배워야 할까? 아니다. 개발 언어를 아는 것으로는 협업을 잘하는 데 큰 도움이 되진 않는다. 그보다는 개발 구조를 이해하고 개발자가 주로 사용하는 표현을 아는 것이 도움이 된다. 그렇다면 협업을 위해서는 어떤 개발 지식을 어떻게 습득해야 할까? 또, 협업을 잘하려면 어떤 노력이 필요할까? 당신이 협업을 잘하고 싶은 기획자나 디자이너라면 다음 도서를 주목해주길 바란다.「오늘도 개발자가 안된다고 말했다」는 IT 비전공자 2명이 각각 기획자, 디자이너로 일하면서 겪은 협업 경험을 녹여낸 ‘개발 협업 가이드북’이다. 이 책은 개발자와의 소통이 어려운 기획자나 디자이너에게 도움이 되고자 하는 취지에서 만들었으며, 저자들의 경험담, 현업 개발자들의 경험을 바탕으로 개발자와 좀 더 원활하게 협업하기 위한 정보, 지식을 다루었다.이 책의 주요 대상은 IT 기업에 근무하는 신입 기획자와 디자이너(또는 비전공자 기획자와 디자이너)이지만, 기획자와 디자이너의 일과 역할이 궁금한 개발자에게도 조금이나마 도움이 될 것이다.아무런 개발 지식이 없는 상태에서 시작하여 지금까지 어떻게 개발자와 협업을 할 수 있었는지, 협업 과정에서 일어나는 갈등을 어떻게 해결하는지, 공동의 목표를 가지고 어떻게 협업을 해야 하는지 알고 싶다면 이 책을 추천한다.이 책의 구성PART 01 가깝고도 먼 개발자IT 비전공자인 두 저자의 협업 이야기를 생생히 다룬다.아무런 개발 지식이 없는 상태에서 어떻게 개발자와 협업을 하였는지, 어떤 개발자들이 있는지, 협업하기 위해 준비해야 하는 것은 무엇인지 경험담을 바탕으로 이야기한다.PART 02 기획자의 일개발자와 원활하게 협업하기 위해, 기획자가 알고 있어야 할 사고 방법과 정보를 다룬다.서비스를 만드는 전체 과정, 서비즈 구조 이해, 논리적으로 개발자를 설득하는 방법, 리뷰를 요청하는 방법 등을 알아본다.PART 03 디자이너의 일협업을 잘하는 좋은 디자이너로 성장하기 위해 필요한 마인드와 개발 지식을 다룬다.개발을 이해하는 디자이너가 되어야 하는 이유, 웹/앱 디자인에 필요한 개발 지식 등을 알아본다.PART 04 개발자의 일개발자의 업무 환경, 협업을 위한 소통 도구를 소개하고 회사 유형별(대기업, 중소기업, 에이전시, 프리랜서)로 개발자의 협업 사례를 다룬다.“개발하기 싫어서 안 된다고 말하는 게 아니다”많은 IT 종사자들이 안 된다고 말하는 개발자로 인해 협업에 어려움을 겪는다. 우리는 IT 비전공자로서 소통을 잘하기 위해 개발자의 입장에서 많이 생각하게 됐고, 이 과정을 통해 개발자의 안 된다는 말에 담겨 있는 여러 가지 의미를 깨달았다. 이 책에는 우리의 성장 과정에서 발견한 협업 노하우들을 담아냈다.“개발 언어를 잘 몰라도 협업을 잘할 수 있다”개발자와의 협업은 외국인과의 대화와 닮은 점이 많다. 영어 시험 점수는 높은데 외국인과 대화를 못 하는 친구와 시험 점수가 높지 않아도 외국인과 대화를 잘하는 친구를 모두 만나본 적이 있을 것이다. 개발 언어는 영어 단어와 비슷하게 많이 알면 유리하지만 당장 협업에 써먹기는 어렵다. 개발 언어를 배우기 전에 꼭 먼저 알고 있어야 할 정보들에 대해 알아보자.



John Doe
2.0
대신 이걸 보세요. 현업 기획자 도그냥이 알려주는 서비스 기획 스쿨(2020) https://pedia.watcha.com/ko-KR/contents/byXrAY2 — 얼마 안 지났다고 생각했는데 18% 왔으니까, 아마 상당히 얇은 책인 모양이다. 아무 것도 없이 (아마도) 대학 학내 스타트업부터 경험한 걸로 서술을 시작하는데 어떤 과정이었을지 그려져서 공감대가 형성되긴 한다. 다만 기획, PL, PM 등을 명시하지 않고 서술하는 게 아쉬웠다. 자기가 실무에서 겪은 걸 그대로 서술하는 거야 뭐랄 수 없지만 그래도 경력이 쌓인 지금에 와서 책을 쓴다면 체계상 어떤 구분이 있고 그때 겪었던 실무진들은 그 중에 어떤 역할들을 해줬던 거라는 식으로 풀어주는 게 맞지 않을까? 앞부분 읽다 말았으니까 뒤에 가서 더 설명할지도 모르겠다. 여기서 서술하는 인물들을 보고 싶다면 블랙회사에 다니고 있는데, 지금 나는 한계에 도달했는지도 모른다(2009)는 영화가 있으니 참고할 수 있겠다. 제목 자체가 출간 초기에 알려질 때도 비판을 받았고, 책의 서술도 좀 업계의 흔한 권력관계를 가감없이 수용한 상태로 표현하고 있고, 개발자라는 표현 자체도 나름대로 비판의 대상이 되고 있는 걸 그 맥락 그대로 썼다. 마치 정글의 법칙에서 원주민을 놀라게 하면 안 된다는 그 발언을 보는 듯 한데… 화자의 입장이 사바나 초원에 갓태어나 뚝 떨궈진 사슴 같은 느낌이라 어떤 관점을 표현하는 건지는 알겠지만 책으로 내서 확대재생산을 해도 좋을만한 문화는 아니라 아쉽다. 반대로 생각하면, 이 책의 화자처럼 아예 맨땅 헤딩으로 시작하겠다고 맘 먹은 사람이라면 야생의 현업이 어떤 식으로 돌아가는지 예고편 정도로 생각할 수 있겠다. 물론 케바케 사바사.
도영
2.0
플랫폼 또는 웹/앱개발사 지망생이거나 주니어급 직원에게 유익할 자기개발서라고 생각됩니다. 총 4개 챕터 중 개발자들과 소통하는 방식은 1챕터 뿐인데, 이 부분은 IT회사 근무자라면 모두 알아야 할 방식이라서 직군 관계없이 유용합니다. 나머지는 웹/앱 기획자나 디자이너에게 도움될 내용들이에요 요약하면, 신규 기능 뿐 아니라 기존 서비스의 안정적 운영을 위해서도 목표와 이유의 공감대 형성이 제일 중요하고, 서로의 역할을 인정하고 배려하며 협업하기 위한 대화가 중요하다는 것인데요. 개발자들에게 절대 하면 안되는 말 세가지는 정말입니다ㅋㅋ 1.쉽게 되죠? 2.이때까지 해줄 수 있죠? 3. 다른 곳에는 있는 기능인데요?
불정로
3.0
공동저자로 개발자도 들어갔다면 좋았을 것 같은데?
앨리
3.5
이 책을 처음 읽기 시작했던 이유와 당시에 겪었던 상황들이 아직도 정확하게 기억난다. 마케터에서 기획자로 전향하던 시기, 처음으로 개발자에게서 “이건 좀…”이라는 피드백을 들었던 순간이 있었고, 그때 누군가 이 책을 추천해줬다. 그래서 시작한 독서였는데, 지금 돌아보면 꽤 결정적인 도움을 준 책이었다. 이 책이 말하는 핵심은 결국 IT 조직에서 가장 큰 문제는 ‘소통의 방식과 포인트’라는 점이다.하지만 읽다 보면 “이게 과연 IT 조직만의 문제일까?”라는 생각이 든다. 팀이 하나의 제품을 함께 만들기 위해 모였을 때, 서로의 작업 맥락과 백그라운드 지식에 대한 이해가 얼마나 중요한지, 그 영향도가 높은게 IT산업이니 그렇다고 생각은 한다. 하지만 이 책이 말하고다 하는 포인트는 모든 산업, 모든 팀에 공통적으로 적용되는 이야기니까. 특히 내가 IT에 발을 들이면서 겪었던 막막함, 용어의 벽, 서로의 언어가 너무 다른 데서 오는 오해들을 이 책이 꽤 현실적으로 짚어준다. 그래서 읽는 동안 계속 고개를 끄덕이게 됐다. 단순히 개발자와 기획자의 갈등을 다루는 것이 아니라, “어떻게 소통해야 함께 더 나은 결과물을 만들 수 있는가”라는 보다 근본적인 질문을 던져 준다. 개인적으로는 IT 비전공자라면 꼭 읽어볼 만한 기본서적이라고 생각한다. 아니, 전공자라도 팀 단위로 일한다면 한 번쯤 읽어보면 좋을 것 같다. 협업의 본질을 짚어주는 책이라서, 커리어 초반의 나에게도 지금의 나에게도 여전히 유효한 조언을 준다.
권영민
3.0
개발자와 싸우자가 아니라 개발자들을 이해해보자라는 취지가 담겨 감사합니다. 아직 개발자들과 업무상 커뮤니케이션이나 협업을 어떻게 해야 할지 모르거나 어려운 연관 직무 초년생이라면, 한번쯤은!
더 많은 코멘트를 보려면 로그인해 주세요!