일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- 클린코드
- 데이터유통
- 회고
- Raw-Request-URI
- spray
- 데이터야놀자
- 코딩인터뷰
- wait region split
- kafka
- 개발7년차매니저1일차
- 박종천
- 동시성
- coursera
- 켄트백
- 테스트주도개발
- 개발자
- 단위테스트
- 2017회고
- datalake
- hackercup2017
- 함수형 사고
- 알고스팟
- 실전사례
- clean code
- 데이터플랫폼
- 해커컵
- functional thinking
- 개발자로살아남기
- 2016년회고
- 데이터레이크
- Today
- Total
Software Engineering Note
프로젝트 리더, 그 첫걸음 본문
최근에 진행한 프로젝트에서 처음으로 프로젝트 리더를 맡았다.
끝나고 나니 뭐 특별한게 있었을까 싶지만 어쨌든 경험을 공유해보고자 한다.
내 상황은 다음과 같았다.
프로젝트의 성격은 전환성이었다. 기존에 있던 시스템을 새로운 시스템으로 전환하는일
직접 프로젝트를 진행한 참여인원은 나 포함 2명. 그런데 관련 시스템이 있어서 협업은 총 4명
나만 근무지가 판교였고, 나머지 인원은 모두 제주도였다.
프로젝트 리더의 역할
프로젝트 리더라고 해서 어떤 지위적인 우위를 의미하는건 아니다. (특히 kakao 같은 수평문화를 지향하는 조직에서는 더더욱)
주로 개발외에 다음과 같은 일을 담당했다.
주간회의 시간에 진행상황을 정리하고 공유한다.
기술셋을 정하고 전체적인 시스템 구조를 잡는다.
계획을 세우고 정리한다. (이번주기에는 무엇을 할지, 다음주기에는 무엇을 할지)
협업 관련해서 커뮤니케이션을 주도적으로 한다.
뭐든 결정 내려야할 일이 있으면 결정을 내리는 주체가 된다.
내가 생각하는 프로젝트 리더는 기술장벽을 허물면서 "갑시다" 하고 이끌어주는 존재다.
이건 관리만 하면 땡이 아니라, "뛰어난 기술력 + 관리는 덤" 이라는 의미다.
내가 그 역할을 잘 했는지는 모르겠지만, 어쨌든 설계부터 개발까지 전투에 주도적으로 참여했고 내 뷰에서 보이는 것들은 정리하고 진행해나갔다.
누군가를 신경써야 한다는 것
나 자신 이외에 다른 누군가에게 신경을 쓴다는게 은근히 신경 쓰이는 일이었다.
"상대도 같은 생각을 하고있을까? 이걸 어떻게 받아들일까?" 이런 고민들을 많이 했던것같다.
어떤 업무를 해야할지 나눌때, 나는 동료에게 무엇을 하고싶은지 먼저 물어보았다.
그리고 지금 우리가 어느시기에 접어들었는지, 어디에 집중해야 하는지를 정의하고 이야기 하려고 노력했다.
나의 바램이나 생각하는바를 전달할때도 동료가 어떻게 받아들일지 항상 신경이 쓰였던 것같다.
왠지 뭔가를 먼저 이야기 해야하고, 앞서서 생각해야 한다는 부담감? 항상 그걸 가지고 있었고, 가져야 한다고 생각했다.
리모트로 협업하기
거리가 떨어져있으니 직접 만나서 이야기하거나 바로 옆에서 함께 개발 하지는 못했다.
주로 아래와 같은 도구를 이용해서 협업을 했다.
아지트
- 사내에서 사용하는 커뮤니케이션 도구다.
- 주로 의사결정이 필요하거나, 정리된 내용을 다른 사람들과 공유하는 목적으로 사용했다.
(예를들면 오픈일정이라던가, 진행 계획이라던가, 도움을 요청한다거나, 함께 의사결정이 필요한 부분이라던가..)
메신져(카카오톡)
- 주로 여기서 많은 이야기가 오간다. 잡담도 포함.
- 일일미팅 비슷하게 편하게 이야기를 하는 도구로 사용했다.
- 급한 이슈가 있을때나, 궁금한 내용을 파악할때 주로 사용했다.
github
- 사내에 JIRA가 있긴하지만, 이전 프로젝트에서 github으로 이슈를 따서 진행한 경험이 괜찮아서 이번에도 그렇게 해봤다.
- 몇 가지 좋아하는 특징이 있는데, 커밋로그에 "#이슈번호" 또는 url을 남기면 알아서 이슈에 철썩철썩 달라붙는 것도 좋았고, 각종 이모티콘으로 격려를 하거나 유머를 하기에도 좋았다. (예를들면 엄지 척!)
- 개인적으로 일에 대한 기록을 딱딱하게 하는것보다 살짝 편한(?) 용어와 말투로 남기는걸 좋아하는데 왠지 github은 그렇게 사용하기에 좋았다.
(이건 개인취향일듯)
- 편하게 댓글을 달다보니 자신의 생각이나 어디까지 진행했는지를 부담없이 남길 수 있어서 일이 좀 투명하게 진행되지않았나싶다.
wiki
- 주로 시스템 구조를 그리거나(drawio), 진행계획을 정리하는 등 공식문서 느낌이 필요한 내용을 정리하는데 사용했다. 주간보고 포함.
개발자가 할일은 개발만이 아니다
아무래도 프로젝트에서 커뮤니케이션을 주도적으로 하다보니 느끼게 된 점이다.
기획팀이나 제휴팀과도 커뮤니케이션을 많이 해야하고, 필요하면 외부와도 해야했다.
이번 프로젝트를 진행하면서도 개발과 관련된 이슈는 직접 메일을 주고받기도 했다. (구글 번역기는 필수품)
개발자들이 실체를 만들어내는 역할을 하기 때문에 가장 많은 내용을 알 수밖에 없지않을까 하는 생각이 든다.
앞으로는 더더욱 역할이 커지지않을까? 아니, 어쩌면 이미
처음 리더를 맡은 프로젝트를 무사히 끝내서 다행이다. 함께한 동료들에게 감사를.
'개발자 다이어리' 카테고리의 다른 글
첫 번역 회고 (0) | 2017.07.05 |
---|---|
2016년 회고 (0) | 2016.12.31 |
Technical Development Guide (0) | 2016.06.05 |
2015년 회고 (0) | 2015.12.31 |
무엇이 개발자의 차이를 만드는가? (0) | 2015.06.26 |