-
Notifications
You must be signed in to change notification settings - Fork 2
📚 팀빌딩 회의 내용 정리 (작성일 : 2024 10 28)
Hyein Jeong edited this page Nov 5, 2024
·
2 revisions
- 분류: 정규 회의 정리
- 생성 일시: 2024년 10월 28일 오후 7:13
- 선택: 정리본
GPT를 통한 정리와 개인적인 정리 내용이 합쳐져 있습니다.
- 내가 사용할 수 있는 서비스(쓸것 같은 서비스)
-
“내가 이게 필요한 이유를 팀원 전체가 공감해야 함.”
- 설득의 영역이 아니라, 감정의 영역..
- 해결할 문제를 정해서 주제를 먼저 정하고 기술을 여기에 맞추자
- 주원님의 이야기가 나오다보니.. 우리는 주제를 바꾸는건 크게 좋은 선택이 아닌 것 같음
- 주제에 대한 도메인
- 위치기반으로 오기도 했고… 그니까 이 범주 내에서 생각
- @혜인 정 :: “집중할 때 집중하자.” → 심리적 나태함 방지
- 데드라인을 명확히!
- 팀적으로 생산성을 극대화하자. → 안되면 바로 옆에 말하고, 작업상황 빠르게 공유해서 누구하나 야근 없이 정해진 작업량을 제시간에
- 팀의 핵심 기능 개발에 대해서 야근이 있어서는 안된다.
- 혼자 끙끙 거리지 마라.
- @혜인 정 :: 팀의 핵심 기능 개발에 대해서 주어진 시간을 넘기지 마라. → 곧바로 공유해라.
- 그외는 알아서 해도 되는데.. 팀에게도 지장갈 수 있으니 주의한다.
- @동율 이 :: 6주가 짧다. → 그니까 이후에 유지보수로 추가할 생각하지 말고 핵심 기능은 6주에 다 담자.
- @동율 이 :: 팀이 지치지 않는 것도 중요하니까, 6주가 짧지만 기니까… 컨디션 관리를 할 수 있게 여유를 두자. (완충을 잘 두자.)
- @주원 김 :: 공통의 목표를 향해서 다 같이 으쌰으쌰하는 경험. → 밤새라는 말은 아님. 비동기소통을 하든 뭘 하든 문제를 공유하거나 지식을 공유했을때 피드백이 빨라서 서로 빨리빨리 뭔가 몰입해서 됐으면 좋겠다.
- @주원 김 :: 피드백이 빨라서 작업흐름이 팀적으로 쭉 이어졌으면 좋겠다.
- @Zen :: 분업이 아닌 협업이었으면 좋겠다.
- @Zen :: 다 같이 한주에 기능 하나 구현해서 배포를 목적으로 달려들었으면 좋겠다. (일정은 이 범주내에서 여유롭게 알아서…)
- 스프린트 백로그 나오면 각자 알아서 가져가서 구현하고 합치는거…
- 네이버 부스트캠프에서 제공하는 크레딧은 @Zen 가 수령후 공유한다.
- @Zen 이 깃허브 퍼블릭 레포를 개설한 뒤 팀원을 초대한다.
- 익일(10월 29일 화요일)까지 각자 주제에 대한 아이디어를 사전에 작성해서 공유한다.
- 슬랙에 올라간 팀원간의 소통글을 읽고 댓글을 남긴다.
- 노션에도 글을 읽고 내용을 첨삭하거나 없을 경우 댓글을 남긴다.
- 시간 관리와 작업 집중도: 각자의 집중도가 떨어지지 않도록 시간 관리를 철저히 하고, 핵심 기능은 팀 내에서 공유하며 공동의 목표로 진행하기로 했습니다. 또한 긴 작업 시간으로 인해 팀원들의 컨디션이 저하되지 않도록 스케줄에 여유를 두는 방안을 마련했습니다.
- 심플한 주제 선정: 심플한 주제를 유지하며 기능을 나누고, 각자의 기능을 책임지고 관리하는 방향으로 협업할 것을 강조했습니다.
- 분업을 통한 성장과 몰입: 팀원 각각의 강점을 살리면서도 프로젝트 전반에 걸친 협업을 경험하도록, 단순한 분업을 넘어 기술적 공유와 상호 피드백이 활발하게 이루어지도록 할 계획입니다.
- 실제 사용 가능성: 팀원 모두가 사용할 수 있고 현실에서 필요로 하는 서비스를 만드는 것을 목표로 삼았습니다. 주제는 단순히 기술을 구현하는 것에 그치지 않고, 일상에서 겪는 사소한 불편함을 해결하는 방향으로 설정했습니다.
- 포트폴리오로서의 가치: 완성된 프로젝트가 향후 포트폴리오로 활용될 수 있도록 하여, 프로젝트의 기능성뿐만 아니라 코드 품질과 유지보수 가능성을 높이기로 했습니다. 특히 각 기능이 GitHub에 기록되어 체계적으로 아카이빙될 수 있도록 관리합니다.
- 지속적인 개선 가능성: 6주라는 프로젝트 기간이 끝난 이후에도 팀원들이 쉽게 유지보수할 수 있도록 코드를 작성하며, 향후 필요한 경우 기능 확장과 업데이트가 가능하도록 고려했습니다.
- 협업과 문서화의 중요성: 코드를 읽고 관리하기 쉽도록 문서화에 신경 쓰며, 협업 과정에서의 명확한 역할 분담과 상호 피드백을 통해 코드의 품질을 높이고자 합니다.
- 비동기적 소통: 팀 내 피드백을 빠르게 주고받아 작업의 흐름이 끊기지 않도록 하며, 필요 시 비동기적 소통을 통해 문제 상황을 신속히 해결하는 방안을 채택했습니다.
- 주간 목표 설정: 매주 한 가지 주요 기능을 구현하여 배포하는 방식으로, 각 기능의 완성도를 높이는 동시에 팀원 간의 협력과 피드백을 유도합니다.
- 필요성과 공감대: 팀원 전원이 필요성을 공감할 수 있는 주제를 우선적으로 선정하기로 했습니다. 주제에 대한 공감이 팀 프로젝트의 동기 부여와 방향성을 높이는 데 중요하다고 판단했습니다.
- 구현 가능성과 완성도: 기능의 크기가 크고 복잡할 경우 완성도에 영향을 미칠 수 있으므로, 핵심 기능을 간단하고 명확하게 설계하여 전체 프로젝트의 완성도를 높이는 데 중점을 두었습니다.
-
각 팀원의 의견과 필요:
- 팀원마다 목표와 필요가 다르기에 각자 원하는 방향으로의 성장 기회를 존중하고자 했습니다. 예를 들어, 일부는 React와 TypeScript의 포트폴리오에 집중하고 싶어했고, 다른 팀원들은 새로운 기술(예: Three.js)을 활용해 보고 싶어했습니다.
- 다만 이 역시, 문제에 대한 접근을 먼저 두고, 필요에 맞춰서 기술을 도입하기로 했습니다.
- 자유롭게 의견 발화 이후 피그잼을 이용
- 포스트잇으로 자유롭게 주제 제시 후 군집화
- 이후 스티커를 바탕으로 해서 각자 3개씩 투표
- 이를 바탕으로 팀 내 조율
주제 : 중장년층을 위한 지도 서비스
목표 : Accessibility를 극도로 고려한 위치 혹은 지도 관련 서비스 개발
(우리의 가족이 쓸 수 있도록)
제약사항 : 너무 많은 타겟을 고려하려고 하지 말자.
- 처음에는 작게 시작하자. => 중장년층만을 대상으로
- 많이 고려해도, 노안, 노청(?)을 고려하는 정도로만 하자.