프로젝트 시작 시 팀에게 도움되는것이 무엇이있을까?
한정적인 시간이 주어진다면, 무엇보다 빠른 보딩이 필요하다. 빠른 개발 환경 구축은 팀에게 도움이 될 것이다.
팀장만이 해야하는 것을 기다리는 수동적인 자세로 참여하지 않는다. 모두 도우면서 하는것이 팀워크고 협력이라 생각한다.
누군가에게 과도한 스트레스와 책임감이 몰리면 안된다. 내가 먼저 나서서 도와야되고 주도적으로 참여해야한다.
다른 사람의 어려움을 함께 해결하고자 적극적으로 손을 뻗어야 나도 어려운 상황에 도움 받을 수 있다. 팀으로 움직여야 한다.
보딩 루틴의 시작
나는 버릇처럼 내가 먼저 나서서 아이스 브레이킹을 시작한다.
먼저 곧바로 시작을 위해 효율적으로 생각을 정리 할 수 있는 마인드맵을 통해서 아이디어를 추출하고, 정리하기 시작했다.
관심사가 몰려있는 아이디어는 프로젝트 가이드와 맞물리도록 설계를 하기 시작했고, 회의를 통해 실제 기획 단계로 넘어간다.
초기 세팅에 여러가지 준비해두었던 자료들을 재사용하면서 빠른 랜딩을 위한 서포트를 제공하려 노력했다.
어떠한 양식 조차 만드는 것 조차도 “일”의 범위다. 이것 또한 시간을 소모하며 이것 또한 제한된 시간이 소모된다.
나는 차곡차곡 양식들을 쌓아오고 있으며 이러한 유사한 양식이 준비된 상태에선 보다 빠르게 변경, 적용 할 수 있었다.
하지만 급하면 안된다.
급하면 넘어진다. 프로젝트를 항상 빠르게 시작하려하지만, 빨리 천천히해야한다?
빨리해야 한다는 것은 이전에 준비된 것들을 활용해서 빠르게 하는 것이지, 단순히 급하게 하는것을 의미하지 않는다는 것을 명심하자.
특히 기획, 설계단계에서 많은 부분들을 고려하지 않으면 결국 스케쥴에 쫓기거나 생각하지 못한 흐름으로 진행되는 프로젝트를 많이 봐왔다.
나는 전체적인 로드맵을 잡고 기획 단계는 절차지향적으로 진행해야 한다고 생각한다.
물론 수많은 프로젝트를 진행하게 되면 사소한 것들은 계속해서 수정하고 바뀌어 가지만
놓치는 것이 많아질수록 누적되면 짜증이되며, 짜증은 곧 감정적으로 타인에게 영향을 미칠 수 있음는 것을 생각한다.
개인 프로젝트가 아니라 말그대로 팀 프로젝트니까 주고 받는 커뮤니케이션이라는 것 조차 “일”의 범위라고 생각한다.
이것을 관리하기 위한 룰 또한 이미 양식화 되어 있으며, 회의를 통해 세부 조정을 진행하며 시간을 단축시켰다.
팀 커뮤니케이션을 위한 커뮤니케이션 툴 팀스페이스 빠른 생성
→ 타 프로젝트에서 공통적으로 활용되던 부분들을 재활용, 해당 프로젝트에 맞게 재구성하여 빠른 프로젝트 개발 랜딩을 위한 세팅
→ Notion SA로드맵 생성 및 팀구성원들이 사용 할 수 있는 기초 템플릿 생성 및 배포, 팀스페이스 초대
→ 팀 커뮤니케이션 용도 Slack 채널 생성 및 공지
→ 전체 스케쥴 및 로드맵 분석 및 일정 단계별 최소 목표 공지
기획 단계
→ 아이디어 창출을 위한 Gitmind를 통한 세션 생성 및 브레인스토밍 주도, 아이디어 수집 및 제안
→ 아이디어 구체화를 위한 사례 탐색 및 테스트
→ 팀 스펙을 고려한 프로젝트 규모 선정 회의 및 가능성 검토
→ API 명세서 기초 기능 구분 및 작성(팀)
→기획 및 DB 설계에 맞추어 지속적인 수정 필요
프로젝트 랜딩 단계
→ 원격저장소(팀프로젝트 협업형상관리위치) 생성 및 콜라보레이터 초대
→ README.md 기초 프로젝트 개요 작성
→ 기능 분배 전 기초 프로젝트 구조 생성 및 메인 프론트엔드 테스트
프론트엔드 테마 탐색 및 프론트엔드 코드 수정 가능성 테스트
→ 메인 테마로 활용 할 수 있는 테마 탐색
→ 제1안을 프로젝트에 적용했지만, 고급 javascript 동적 함수들을 커스터마이즈하기 어렵다고 판단하여
→ 제2안인 비교적 심플한 구조, 깔끔한 외관과 반응형웹구조가 반영되어있는 템플릿을 선정
→ 프로젝트에 이식 후 커스터마이즈 테스트 진행
→ 형상관리 마스터 기능 작업 분배 전 1차버전 팀에게 배포
