개발팀을 위한 소통과 협업스킬
•
1 j'aime•2,190 vues
기업 강의 자료입니다. 경험담을 들려줄 아저씨가 필요하다면 연락주세요. 주제 - 개발팀은 다른 팀과 어떻게 소통해야 하나? - 개발팀은 내부 업무처리를 위해 어떻게 소통해야 하나?
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à 개발팀을 위한 소통과 협업스킬
Similaire à 개발팀을 위한 소통과 협업스킬 (20)
Plus de 수보 김
Plus de 수보 김 (18)
개발팀을 위한 소통과 협업스킬
- 1. 개발팀을 위한 소통과 협업스킬
- 2. - 2 - 문제가 무엇일까?
- 3. 누가 왜 그렸을까? - 3 -
- 4. 국내 IT 사업환경의 변화 - 4 - 유선 인터넷 시장 휴대폰 콘텐츠 시장 국내 SI 시장 스마트모바일 시장 정부 – 전자정부 금융 – 차세대 통신 – 인프라 및 서비스 구축 유통 – 물류 전산화 국방 – 첨단 전자장비 제조 – 공정 자동화, 수율관리 등등… • B2C 서비스 :: 광고 메일 다양한 가두리 서비스 출시 • B2B 산업 :: 시스템 납품(SI) B2B 가입자 기반의 서비스 서비스 생산 및 유지관리 방법의 변화가 필요한 시대
- 5. 우리 나라만 그런가? - 5 - 라이코스, 야후
- 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 - 소규모 팀 대형 분업화 중규모 팀 • 시스템 생산 판매 • 대량생산 체계 • 공정 중심의 분업화 • 기획팀, 디자인팀, 개발팀 • 가입형 기반 서비스 • 서비스의 지속성 • 시스템 고도화 중요 • 사업1팀, 개발1팀 • 혁신적인 서비스 • 빠른 서비스 런칭 • 시스템 보다 사업 • 벤처회사 친목, 화목이 중요 프로세스, 업무체계 협업방식, 문화
- 8. 협업 방식의 변화 - 8 - 사업기획 서비스기획 시스템기획 시스템구현 서비스오픈 서비스운영 신규기능 기획 기능구현 계획 기능구현 기능오픈 서비스 추가운영 데이터축적 사용자분석 서비스전략 수정 서비스 변경기획 시스템 구조변경 서비스 변경개발 서비스 재오픈 서비스 운영 신규시스템 구축 서비스 운영 서비스 고도화 프로세스 기반 업무 프레임 - Rollback 의 어려움
- 9. 기획자에 대한 잘못된 이해 - 9 - 모든 걸 알고 기획했겠지 개발이 시키면 다 해야 하는 팀인가? 그래도 이 기술을 대충 알고 있겠지? - 기획자는 아이디어를 듣고 새로운 기획을 하는 사람 - 세부적으로 어떻게 진행될지 결과가 어떻게 될지 알지 못한다. - 특히 어떤 기술 문제가 있는지 전혀 알지 못한다. - 개발팀이 구현하지 않하면 거짓말쟁이, 바보가 된다. - 무시하고 싶은 게 아니라, 목표에 달성하고 싶은 거다. - 제발 해주세요. - 기획자가 이해하는 것은 1 depth level 까지만. - 예외사항과 문제상황은 거의 모른다. - 요구명세에 해당하는 기술스펙을 쓸 수 없다.
- 10. 개발자에 대한 잘못된 이해 - 10 - 안된다 … 나한테 삐진걸까? 이렇게 하면 되지 않아요? 우리 개발팀은 너무 느려요. - 개발팀 일정상 종료일을 맞출 수 없다는 의미다. - 판단하기 애매할 때 일단 안된다고 이야기한다. - 당장 준비되어 있지 않다는 뜻이다. - 몰라서 못하고 있는 거 아니다. - 언제 어떻게 할 지 결정하지 못했다는 것이다. - Side Effect 들을 검증하지 못했다는 뜻이다. - 먼저 받아들여야 그 문제를 풀 수 있다. - 개발팀이 빨라지는 건 구글도 바라고 있다. - 시스템, 조직, 협업 관점에서 복합적인 원인이다.
- 11. 언어의 종류 - 11 - Descriptive Language vs Figurative Language 개발팀의 언어는 공학적이고 정확한 기술언어
- 12. 비즈니스의 듣기 - 12 - Context 관계적 맥락이 없으면, 소통한 것이 아니다. 출발지를 알아야 맥락이 보인다.
- 13. 비즈니스의 말하기 - 13 - 나는 무슨 말을 하고 있지? 문제 원인이 제거 되었는가? 그 다음에 어떻게 진행되지? - 설득, 설명 : 상대방의 반응을 살핀다. - 공격, 짜증 : 일방향적인 감정의 소모. - 방어, 변명 : … - 고민이 해결되지 않으면 다양한 방법이 시도된다. - 원하는 것이 해결되었는지 되묻는다. - 방치 … - 다음 일이 진행됨 - 기다려 주기 - 포기하기
- 14. 비즈니스에서 대화 이해하기 - 14 - 맥락을 놓쳤다면 잘못 들었을 가능성이 크다. 이해하기 어렵다면 되물어야 한다. 나의 용어로 되묻는다. 내가 이해될 때까지 반복해서 묻는다.
- 15. - 15 - 소통의 필요성
- 16. 이들은 어떻게 일하고 있을까? - 16 - 자동차는 약 3천개의 모듈(=3만개의 부품)로 구성됨 전자부품 및 SW가 전체 원가의 30%를 차지함 구매, 제조, 판매까지 많은 컴퓨터가 이용됨 자동차를 만드는 과정은 약 450여개의 파트를 조립하고 6,000 군데를 용접하는 과정
- 17. 기술 비즈니스의 특징 - 17 - 진행상황이 눈에 보이지 않는다.
- 18. 협업, 잘 되고 있을 때 현상 - 18 - 전체 업무 현황에 대해 모두 대충은 알고 있다. 문제에 부닥치는 순간 관련자에게 모두 상황전파가 된다. 문제 해결 현장에 핵심 실무자만 나타난다. 제 때 제 때 보고가 된다. - 세부적인 내용은 몰라도 전체적인 상황공유는 되고 있다. - 각자가 업무의 강약 조절을 스스로 하고 있다. - 팀원들의 스트레스 수치가 잘 관리되고 있다. - 피해상황이 적시에 파악된다. - 언제 어떻게 대응해야 할지 서로 잘 알고 있다. - 윗선이 개입하지 않아도 문제가 해결되고 있다. - 실무 담당자 간의 소통채널이 확립되어 있다. - 진행상황이 적시에 자주 자주 공유된다. - 공유된 정보는 도움을 줄 수 있도록 준비하게 만든다.
- 19. 협업, 잘 안되고 있을 때 현상 - 19 - Abilene Paradox
- 20. 협업의 종류 - 20 - DIVISION CO-WORK • 프로세스 (공정) • 매뉴얼 • 품질검사 • 규격 • 원칙 • 1:1 소통 • 일상, 습관 • 현황을 공유
- 21. 좋은 소통과 협업 - 21 - INFRA CAPACITY PLAN Communication Based On
- 22. 유명회사 사례 - 22 - 상용서버 상용데이터 Confluence Jira Source Repository 협업팀 게이트키퍼 사용자 협업 자원들 운영팀 개발3팀 제품 매니저 개발1팀 개발2팀
- 23. 유명회사 사례 - 23 - Naver, Daum
- 24. - 24 - 협업을 위한 준비사항
- 25. 현실과 희망 - 25 - 소스 시스템 (서비스) 개발 생산성 불가능은 없다. 하지만, 내일 당장 뭔가를 할 수는 없다. 매일 한걸음만 걸을 수 있다. 어떻게 먼길을 갈까?
- 26. 필요한 공감대 - 26 - 제품의 품질 자원의 투입량 완성도 100%
- 27. 협업, 팀 리소스 현황 파악 - 27 - Green Zone Hot Zone Overhit Zone Yellow Zone 시간 가동률
- 28. 문제 드러내기 - 28 - • 불안한 감정, 걱정, 느낌 등을 감추지 않는다. • 문제의 정도를 수치로 표현한다. • 대안을 함께 찾는다.
- 29. 회의, 언제할 것인가? - 29 - 1. 문제를 정의 2. 의사결정 기준 정의 3. 우선순위 기준 정의 4. 대안 모색 5. 각 대안을 평가 6. 최적의 대안을 계산 7. 결과를 모니터링하고 평가 Rational Decision Making Model 1 : 1 대면 미팅 1 : n 대면 미팅 n : n 대면 미팅
- 30. 회의, 어떻게 할 것인가? - 30 - TASK-1 TASK-2 TASK-3 PROCESSING STOP PENDING STANDBY FINISH SOMEDAY
- 31. 회의, 어떻게 정리할 것인가? - 31 - 전문가의 직관은 대부분 빠르고 정확하다. “배려와 신뢰를 기반으로 할 때만”
- 32. 기본 마음가짐 - 32 - 적정기술 재개발방법론 맥락 이해하기
- 33. 기술, 어떻게 설명할 것인가? - 33 - • 기술 용어가 아닌 일상언어로. • 우리 자원에 대한 이해가 선행. • 기술 문제를 어떻게 해결할지. • 무엇을 도와줘야 할지.
- 34. 안되요, 어떻게 말할 것인가? - 34 - PROPOSAL CURRENT PLAN CONVERSATION
- 35. - 35 - 소통과 협업의 핵심 스킬 다섯가지
- 36. Kanban - 36 -
- 37. Scrum - 37 -
- 38. Sprint - 38 -
- 39. Backlog - 39 -
- 40. 회고 - 40 -
- 41. - 41 - Q&A
Notes de l'éditeur
- * 사진 소개 - Alan Kay : OOP, windows GUI의 개척자 - Alan Cooper : Visual Basic의 아버지, Ruby의 아버지, IT에 페르소나를 도입 - Ted Nelson : HTML의 창시자 - Gerald Weinberg : 소프트웨어 개발에 대한 인류학자이자 심리학자, 애자일의 아버지 - Seymour Cray : 슈퍼컴퓨터 개발자 Lary Wall : Perl의 창시자 우리의 앞길을 걸어갔던 사람들이 있다. 그들은 어떻게 일하고 생각하고 협업했을까?
- 내가 하는 일은 대단하지만, 남의 일을 하찮게 보는 것은 IT가 매우 전문화된 기술사업이라는 특징에 기인한 것. 즉, 그들의 기술과 특징을 이해하지 못하면 협업이 어렵다.
- 털 시장 : 응용, 제휴 중심으로 사업이 발전 SI 시장 : 기존 납품형 시장에서 인터넷 서비스로 바뀌고 있음 없는 것을 새롭게 만드는 구축 노하우가 아니라 있는 것을 지속적으로 발전 개선해나가는 방법이 중요해지게 되었음
- 실리콘밸리도 2개 시장으로 나뉨. 닷컴 시장은 기존 일하던 방식이 붕괴함. (프로세스 위주의 일처리 방식들) 전통적인 기업시장도 구축시장에서 개발 유지보수 시장으로 바뀜 ※ 참고. 야후 – 분업화 위주로 대표적인 조직구조. 12개의 의사결정 단계, 주인의식의 부재, 개발팀의 이직, 해체가 잦았음 라이코스 – 수익화, 검색엔진 기능의 정체, 협업 갈등, 개발팀의 이직, 해체가 잦았음
- 애자일 선언에 참가한 사람들 : 2001년 유타주 스키장 리조트에서 새로운 일하는 방법을 토론함. 닷컴 성장 때 실리콘밸리에서 개발하던 팀장급 친구들과 컨설턴트들이 주멤버였음. - Waterfall 기존 방법으로는 변화하는 사업환경에 적응할 수 없다고 판단함. - 지속적으로 일하는 방법에 대해 연구하던 사람들. - 스탠포드 대학 출신들
- 최근의 협업 트렌드는 프로세스를 만드는 것이 아니라 의사소통과 협업을 위한 적당한 도구들을 만들어서 문제를 해결해 나감. 목적이 달성되면 도구를 버림. 계속 팀을 진화시켜 가면서 업무의 생산성을 높임. 따라서, 회사마다 고유의 문화가 자연스럽게 형성됨.
- 신규 시스템 구축은 아파트 건설 서비스 고도화 및 운영은 자동차 튜닝에 비유할 수 있음. 서비스 운영과 고도화 모두 기존에 보유한 자원의 관여도가 높아짐. 즉, 기존 고객, 데이터, 기능의 관여도와 혼잡도가 매우 높음. 이 환경에서는 팀의 타협과 포기, 변경내용의 지속적인 추적이 매우 중요하다. 즉, 핵심은 업무 Rollback(되돌아가기)을 줄이기 위한 것. 즉, 커뮤니케이션 빈도와 품질을 높여 실패 비용을 줄이는 게 핵심임. 이것은 비즈니스 지속성을 확보하기 위한 중요한 팁이기도 함.
- 우리 기획자의 특징을 말로 정의해 보자. 개발팀이 어떤 기획자를 원하는지 말로 이야기해보자. 현실을 있는 그대로 적자. 그 다음에 어떻게 해야 시너지가 일어날지 적어 보자.
- 기획자가 - 우리 개발자를 말로 정의해 보자. - 그들이 왜 그렇게 반응했는지 이유를 물어보자. - 어떤 개발자를 원하는지 말로 이야기해본다. 개발자라고 이야기하지 말고 OOO 라고 이름을 부른다. 현실을 있는 그대로 인식해야 대안을 세울 수가 있다.
- 개발자의 말하기는 설명문이면서 기술적이다. 그것은 개발자의 본능이다. 하지만, 비개발자들은 기술 내용을 이해하는 것에 대해 무관심하다. 쟁점이 되는 사항을 사업적 용어로 변환해서 커뮤니케이션 해야 한다. 설명하는 게 아니라, 판단과 의견을 제시해야 한다.
- 지속적인 스킨쉽은 맥락에 대한 이해를 높여준다. 맥락은 대화를 짭고 정확하게 하기 위한 기저선과 같다. 맥락 공유가 많이 되는 사이일 수록 대화가 짧고, 이해도가 훨씬 높다. 평상시 맥락을 공유하기 위해 잡다한 이야기를 많이 하라. 맥락이 없는 이야기를 들을 때는 맥락을 이야기해달라고 한다.
- 설명이란 일방적인 대화가 아니다. 상대방이 이해해야 끝나는 일이다. 왜 이 말을 하는지 명확히 이해해야 한다. 목적이 달성되도록, 의도가 이해되도록 대화를 해야 한다.
- 들었다고 이해한 것은 아니다. 말했다고 전달된 것은 아니다. 말하기 목적이 달성된 것인지 체크해야 한다. 듣기도 마찬가지다, 내가 제대로 들은 것인지 말한 사람에게 확인을 해야 한다.
- 자동차는 매우 긴 생산과정을 가지고 있다. 그들은 어떻게 커뮤니케이션 실수를 줄이고, 협업을 향상시킬까? 중간에 잘못된 것을 어떻게 확인하고 롤백시킬까? 과연 자동차 생산이 소프트웨어와 다른 점은 뭘까?
- 소프트웨어는 눈에 보이지 않는다. 그래서 개발이 끝난 후에야 무엇이 잘못되었는지를 알게 된다. 하지만, 그 일을 되돌리려면 너무도 많은 것을 바꿔야 한다. 그래서, 일의 진행 중에 시각적으로 드러내기 위한 시도가 많았다. 간트챠트, 주간보고 등… 하지만, 이 모든 것은 담당자의 친절한 설명으로 대체될 수 있다. 짧고 잦은 커뮤니케이션일수록 실패확률이 낮아진다.
- 협업이 잘되고 있다는 것은, 나를 중심으로 업무의 시작과 끝이 예측 가능해지는 것을 말한다. 동시에 관련팀들도 예측할 수 있도록 나와 관련된 내역을 알게 해줘야 한다.
- 비협업의 초기 증상은, 거짓 합의다. 방치되면 앞에서 이야기하기 보다 뒷담화를 주로 한다. 문제의 핵심은 들어주기를 하지 않기 때문. 그래서, 문제가 인지되거나 해결되지 않는 것이다. 예측할 수 없는 환경이 되어버리므로, 업무에 참여하려 하지 않는다. 상황을 예측가능하도록 만들어야 한다.
- 똑같은 제품을 찍어내는 대량 생산에는 분업화가 중요하다. 하지만, 협업은 힘을 합쳐서 괜찮은 거 하나를 만드는 과정이다. 즉, 협업에서 중요한 것은 커뮤니케이션이다.
- 개발자가 하루에 할 수 있는 코딩량은 제한적이다. 작은 코딩으로 훌륭한 시스템을 만드려면, 재활용 가능한 코드 인프라가 충분해야 한다. 그리고, 하루에 얼마나 개발이 가능한지 생산량이 예측가능해야 한다. (심리적 수준이라도) 즉, 개발자가 커뮤니케이션에 자신감이 드는 것은 여러가지가 준비되어 있기 때문이다.
- 페이스 북은 소스의 재활용율이 높다. 업무 히스토리와 소스 열람이 자유롭기 때문. 업무 안착이 되면 40% 정도 코드 재활용을 할 수 있다. 그러면 개발 공수가 30% 정도 줄어드는 효과가 나온다.
- 네이버나 다음 모두 기본적으로 재활용 가능한 인프라들을 많이 가지고 있다. 다만, 네이버는 팀 문화가 개발 PM 중심으로 강하게 컨트롤 되는 경향이 있고, 다음은 각자 협업하는 문화가 자리 잡고 있다.
- 사업방향을 이해하고, 미리 필요한 것들을 많이 준비해 놓을수록 개발자들의 자세는 바뀐다. 자동차를 만들 때 부품을 사다 쓰는 것과 부품부터 만드는 것과의 차이다.
- 자원은 한정되어 있기 때문에 절대 한 번에 많은 성과를 이룰 수 없다. 어떻게 협업자원을 잘 쌓아 놓을 것인가 하는 것은 개발팀의 전략이 필요하다.
- 팀의 업무 처리량이 외부 임원들에게도 보여야 한다. 외부인원들은 팀 스트레스 수치에 무관심하다. 그래서 보여주지 않는다면 업무량은 무한정 늘어난다. 수치화된 근거를 가지고 외부와 소통해야 한다.
- 전문가를 고용하는 이유는 노동력+전문지식이 필요해서다. 경력자를 고용하는 이유는 거기에다 전문경력이 필요해서다. 기술경험에서 발생된 이야기는 설명하지 말고 의견으로 이야기를 한다. 책임감을 바탕으로 하는 전문가의 견해는 대부분 틀리지 않다.
- 모두가 모이는 회의는 가급적 하지 않는게 좋다. 중요한 의사결정은 결정권자가 만나서 한다. 그리고, 그것을 내부에 공유하고 업무로그를 남긴다. 1:1 대면은 결정은 빠르지만, 곧잘 맥락의 상실로 이어진다. 다음 미팅을 할 때 맥락을 이어갈 수 있도록 기록으로 남긴다. 1:n 대면 미팅은 사전에 필요한 것을 미리 공유한다. 그리고, 요점만 간단히 하고 빨리 마무리한다. n:n 미팅은 결정을 위한 것이 아니다. 전달과 공유를 위해서만 모집한다. 물론, 가끔씩 다수결이 필요할 때도 있다.
- “언젠가”로 방치되는 업무는 반드시 뒤통수를 때린다. 노란 딱지를 붙여서 관리를 하도록 하자. 종종 꺼내보면서 확인할 필요가 있다.
- 전문가의 직관은 복잡한 설명을 단순화시키는 효과가 있다. 하지만, 맥락과 신뢰를 바탕으로 한다. 오래된 팀에서 자주 쓰는 방법이다. 제안을 하고, 책임을 진다.
- 기술자가 대화를 하려면, 세 가지의 마음가짐을 가지고 있어야 한다. 맥락은 내가 롤백하거나, 일이 삽질이 될 가능성을 예측하게 해준다. 적정기술은 내가 얼마나 시간을 투자해야 하는지를 예측하게 해준다. 재개발방법론은 기술 부채를 어떤 식으로 해결해야 할지를 예측하게 해준다.
- 기술을 설명할 때는 일상용어로 해야 한다. 임원들의 핵심은 비용, 일정이다. 나머지는 모두 개발자들의 숙제이다. 숙제를 처리할 계획을 세우고, 외부팀과 이야기해야 한다. 기획팀을 숙제를 처리할 같은 팀으로 합류시키는 것은 매우 훌륭한 전략이다.
- 부정적인 의견을 이야기할 때는 대안을 먼저 이야기 한다. 주제 넘는 표현도 괜찮다. 다만, 기분 나쁘게 이야기 하는 것만 피한다. 대화가 실패하는 것은 월권이 아니라, 감정을 건드리기 때문이다. 전문가는 감성적 이야기를 사무적으로 이야기한다.
- 칸반은 공통 현황판이다. 팀이 바쁜 정도, 정체된 지역 등을 확인할 수 있다. 칸반은 현황을 시각화 시킴으로써 대화를 빨라지게 한다. 그래서 다음 일정이 빨라진다. 만일 시각화 되지도 않고, 대화가 느리다면 칸반을 잘못 운영하고 있는 것이다.
- 스크럼이란 일일미팅이다. 각자의 역할을 확인하고, 진도를 확인한다. 개개인이 오늘 할 일들과 어려운 문제들을 이야기한다. 스크럼의 목적은 설명과 이해, 설득에 있지 않다. 스크럼은 맥락을 상시 공유하는 것에 있다. 필요한 일은 공유를 하지 않고, 필요하지 않은 일은 짧게 끝내는 것이 좋다.
- 스프린트는, 업무단위가 아니라 쉼표다. 언제 쉼표를 찍을 것인가를 결정하는 것이다. 쉼표를 찍는 이유는 롤백(업무 다시)을 쉽게 하기 위한 것이다.
- 백로그는 동기식 업무처리를 비동기식 업무처리로 바꾸는데 있다. 일 쪼개주기로 운용이 되면, 백로그 방식을 멈춘다. 비동기식 업무처리를 하는 이유는 개발자들에게 개발 시간을 많이 주기 위함이다.
- 회고. 회고는 평가다. 평가를 통해 포기할 것을 정한다. 회고는 업무를 정리하면서, 쉼표와 마침표 찍을 것을 명확히 하는데 있다. 그래서 회고할 때는 두리뭉실하게 넘어가면 안된다. 정할 것은 확실히 정해야 한다.