O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

개발팀을 위한 소통과 협업스킬

1.313 visualizações

Publicada em

기업 강의 자료입니다.
경험담을 들려줄 아저씨가 필요하다면 연락주세요.

주제
- 개발팀은 다른 팀과 어떻게 소통해야 하나?
- 개발팀은 내부 업무처리를 위해 어떻게 소통해야 하나?

Publicada em: Software
  • Seja o primeiro a comentar

개발팀을 위한 소통과 협업스킬

  1. 1. 개발팀을 위한 소통과 협업스킬
  2. 2. - 2 - 문제가 무엇일까?
  3. 3. 누가 왜 그렸을까? - 3 -
  4. 4. 국내 IT 사업환경의 변화 - 4 - 유선 인터넷 시장 휴대폰 콘텐츠 시장 국내 SI 시장 스마트모바일 시장 정부 – 전자정부 금융 – 차세대 통신 – 인프라 및 서비스 구축 유통 – 물류 전산화 국방 – 첨단 전자장비 제조 – 공정 자동화, 수율관리 등등… • B2C 서비스 :: 광고 메일  다양한 가두리 서비스 출시 • B2B 산업 :: 시스템 납품(SI)  B2B 가입자 기반의 서비스 서비스 생산 및 유지관리 방법의 변화가 필요한 시대
  5. 5. 우리 나라만 그런가? - 5 - 라이코스, 야후
  6. 6. 협업과 소통을 연구 - 6 - Kent Beck(1961~) 소프트웨어개발방법론, 익스트림 프로그래밍 창시자 소프트웨어 디자인 패턴의 개척자 Apple, Facebook 에서 근무 당시 Cutter Consortium에서 근무 Robert C. Martin(1952~) 클린코드의 저자 Rational, Teradyne 등 근무 당시 Object Mentor 운영 Jeff Sutherland(1941~) Scrum Inc. CEO 당시 PatientKeeper의 CTO
  7. 7. 협업의 역사 - 7 - 소규모 팀 대형 분업화 중규모 팀 • 시스템 생산 판매 • 대량생산 체계 • 공정 중심의 분업화 • 기획팀, 디자인팀, 개발팀 • 가입형 기반 서비스 • 서비스의 지속성 • 시스템 고도화 중요 • 사업1팀, 개발1팀 • 혁신적인 서비스 • 빠른 서비스 런칭 • 시스템 보다 사업 • 벤처회사 친목, 화목이 중요 프로세스, 업무체계 협업방식, 문화
  8. 8. 협업 방식의 변화 - 8 - 사업기획 서비스기획 시스템기획 시스템구현 서비스오픈 서비스운영 신규기능 기획 기능구현 계획 기능구현 기능오픈 서비스 추가운영 데이터축적 사용자분석 서비스전략 수정 서비스 변경기획 시스템 구조변경 서비스 변경개발 서비스 재오픈 서비스 운영 신규시스템 구축 서비스 운영 서비스 고도화 프로세스 기반 업무 프레임 - Rollback 의 어려움
  9. 9. 기획자에 대한 잘못된 이해 - 9 - 모든 걸 알고 기획했겠지 개발이 시키면 다 해야 하는 팀인가? 그래도 이 기술을 대충 알고 있겠지? - 기획자는 아이디어를 듣고 새로운 기획을 하는 사람 - 세부적으로 어떻게 진행될지 결과가 어떻게 될지 알지 못한다. - 특히 어떤 기술 문제가 있는지 전혀 알지 못한다. - 개발팀이 구현하지 않하면 거짓말쟁이, 바보가 된다. - 무시하고 싶은 게 아니라, 목표에 달성하고 싶은 거다. - 제발 해주세요. - 기획자가 이해하는 것은 1 depth level 까지만. - 예외사항과 문제상황은 거의 모른다. - 요구명세에 해당하는 기술스펙을 쓸 수 없다.
  10. 10. 개발자에 대한 잘못된 이해 - 10 - 안된다 … 나한테 삐진걸까? 이렇게 하면 되지 않아요? 우리 개발팀은 너무 느려요. - 개발팀 일정상 종료일을 맞출 수 없다는 의미다. - 판단하기 애매할 때 일단 안된다고 이야기한다. - 당장 준비되어 있지 않다는 뜻이다. - 몰라서 못하고 있는 거 아니다. - 언제 어떻게 할 지 결정하지 못했다는 것이다. - Side Effect 들을 검증하지 못했다는 뜻이다. - 먼저 받아들여야 그 문제를 풀 수 있다. - 개발팀이 빨라지는 건 구글도 바라고 있다. - 시스템, 조직, 협업 관점에서 복합적인 원인이다.
  11. 11. 언어의 종류 - 11 - Descriptive Language vs Figurative Language 개발팀의 언어는 공학적이고 정확한 기술언어
  12. 12. 비즈니스의 듣기 - 12 - Context 관계적 맥락이 없으면, 소통한 것이 아니다. 출발지를 알아야 맥락이 보인다.
  13. 13. 비즈니스의 말하기 - 13 - 나는 무슨 말을 하고 있지? 문제 원인이 제거 되었는가? 그 다음에 어떻게 진행되지? - 설득, 설명 : 상대방의 반응을 살핀다. - 공격, 짜증 : 일방향적인 감정의 소모. - 방어, 변명 : … - 고민이 해결되지 않으면 다양한 방법이 시도된다. - 원하는 것이 해결되었는지 되묻는다. - 방치 … - 다음 일이 진행됨 - 기다려 주기 - 포기하기
  14. 14. 비즈니스에서 대화 이해하기 - 14 - 맥락을 놓쳤다면 잘못 들었을 가능성이 크다. 이해하기 어렵다면 되물어야 한다. 나의 용어로 되묻는다. 내가 이해될 때까지 반복해서 묻는다.
  15. 15. - 15 - 소통의 필요성
  16. 16. 이들은 어떻게 일하고 있을까? - 16 - 자동차는 약 3천개의 모듈(=3만개의 부품)로 구성됨 전자부품 및 SW가 전체 원가의 30%를 차지함 구매, 제조, 판매까지 많은 컴퓨터가 이용됨 자동차를 만드는 과정은 약 450여개의 파트를 조립하고 6,000 군데를 용접하는 과정
  17. 17. 기술 비즈니스의 특징 - 17 - 진행상황이 눈에 보이지 않는다.
  18. 18. 협업, 잘 되고 있을 때 현상 - 18 - 전체 업무 현황에 대해 모두 대충은 알고 있다. 문제에 부닥치는 순간 관련자에게 모두 상황전파가 된다. 문제 해결 현장에 핵심 실무자만 나타난다. 제 때 제 때 보고가 된다. - 세부적인 내용은 몰라도 전체적인 상황공유는 되고 있다. - 각자가 업무의 강약 조절을 스스로 하고 있다. - 팀원들의 스트레스 수치가 잘 관리되고 있다. - 피해상황이 적시에 파악된다. - 언제 어떻게 대응해야 할지 서로 잘 알고 있다. - 윗선이 개입하지 않아도 문제가 해결되고 있다. - 실무 담당자 간의 소통채널이 확립되어 있다. - 진행상황이 적시에 자주 자주 공유된다. - 공유된 정보는 도움을 줄 수 있도록 준비하게 만든다.
  19. 19. 협업, 잘 안되고 있을 때 현상 - 19 - Abilene Paradox
  20. 20. 협업의 종류 - 20 - DIVISION CO-WORK • 프로세스 (공정) • 매뉴얼 • 품질검사 • 규격 • 원칙 • 1:1 소통 • 일상, 습관 • 현황을 공유
  21. 21. 좋은 소통과 협업 - 21 - INFRA CAPACITY PLAN Communication Based On
  22. 22. 유명회사 사례 - 22 - 상용서버 상용데이터 Confluence Jira Source Repository 협업팀 게이트키퍼 사용자 협업 자원들 운영팀 개발3팀 제품 매니저 개발1팀 개발2팀
  23. 23. 유명회사 사례 - 23 - Naver, Daum
  24. 24. - 24 - 협업을 위한 준비사항
  25. 25. 현실과 희망 - 25 - 소스 시스템 (서비스) 개발 생산성 불가능은 없다. 하지만, 내일 당장 뭔가를 할 수는 없다. 매일 한걸음만 걸을 수 있다. 어떻게 먼길을 갈까?
  26. 26. 필요한 공감대 - 26 - 제품의 품질 자원의 투입량 완성도 100%
  27. 27. 협업, 팀 리소스 현황 파악 - 27 - Green Zone Hot Zone Overhit Zone Yellow Zone 시간 가동률
  28. 28. 문제 드러내기 - 28 - • 불안한 감정, 걱정, 느낌 등을 감추지 않는다. • 문제의 정도를 수치로 표현한다. • 대안을 함께 찾는다.
  29. 29. 회의, 언제할 것인가? - 29 - 1. 문제를 정의 2. 의사결정 기준 정의 3. 우선순위 기준 정의 4. 대안 모색 5. 각 대안을 평가 6. 최적의 대안을 계산 7. 결과를 모니터링하고 평가 Rational Decision Making Model 1 : 1 대면 미팅 1 : n 대면 미팅 n : n 대면 미팅
  30. 30. 회의, 어떻게 할 것인가? - 30 - TASK-1 TASK-2 TASK-3 PROCESSING STOP PENDING STANDBY FINISH SOMEDAY
  31. 31. 회의, 어떻게 정리할 것인가? - 31 - 전문가의 직관은 대부분 빠르고 정확하다. “배려와 신뢰를 기반으로 할 때만”
  32. 32. 기본 마음가짐 - 32 - 적정기술 재개발방법론 맥락 이해하기
  33. 33. 기술, 어떻게 설명할 것인가? - 33 - • 기술 용어가 아닌 일상언어로. • 우리 자원에 대한 이해가 선행. • 기술 문제를 어떻게 해결할지. • 무엇을 도와줘야 할지.
  34. 34. 안되요, 어떻게 말할 것인가? - 34 - PROPOSAL CURRENT PLAN CONVERSATION
  35. 35. - 35 - 소통과 협업의 핵심 스킬 다섯가지
  36. 36. Kanban - 36 -
  37. 37. Scrum - 37 -
  38. 38. Sprint - 38 -
  39. 39. Backlog - 39 -
  40. 40. 회고 - 40 -
  41. 41. - 41 - Q&A

×