hmk run dev
팀을 위하는 개발자란? 본문
코딩은 개발자들이 해야 하는 많은 일 중 하나
개발자의 필요조건일 뿐, 비즈니스 목적을 달성하기 위한 도구일 뿐
그 외에 어떤 일들이 있는가?
1. 우선순위 선정하기
2. 개발 일정과 비용 산출하기
3. 주어진 여건에서 최적의 결정하기
4. 비기능적 요구사항과 계약 조건 검토하기
5. 지리적으로 분산된 팀들과 협업하기
6. 사업 목표 이해하기
7. 전체 비즈니스에 영향을 미칠 기술 선정하기... 등등
주위를 보면
존경받는 / 함께 일하고 싶은 / 팀에 큰 전력이 되는 개발자들은
코딩뿐만 아니라 위 역량이 뛰어남
주위 개발자를 보면서 수집한 행동들을 기반으로
크게 본질, 관계, 속마음 3개의 키워드를 선정해 팀에 기여하는 개발자란 어떤 모습인지에 대해
정리해 보겠습니다.
1. 본질
Situation 1
어느 날 PM이 말했다.
"신분증 인증에서 사용자가 많이 나가네요."
[내일 입력하기] 버튼을 추가하면 어때요?
나는 이렇게 대답했다.
"좋아요 :) 프런트 공수는 얼마 안 들어요~"
좋은 대답 혹은 해결방안이었을까?
결론적으로는 맞을 수도 있고 아닐 수도 있지만.
Don't
요구사항에 대한 1차원적(수동적인) 검토라고 생각이 든다.
팀플레이어다운 응답
"우리 인증서 활용동의"를 받으면
신분증 인증 자체를 스킵할 수 있어 보여요
법무팀 검토 부탁드려 볼게요.
Do
근본 문제 파악 -> 본인 전문성 더한 방안 제시
개발자가 기획안보다 창의적으로 풀 수 있는 문제의 예시
Learning
1. 맥락을 파악하고
2. 본질을 꿰뚫고
3. 나의 전문성을 더해 해결책을 보강한다.
코딩이 전부가 아니고, 위 작업이 업무의 일부.
Situation 2
개발 버그로
금액 장애가 빈번하게 일어나 손실이 크다.
대응
"실수했네요, 앞으로 더 신경 쓰겠습니다."
(앞으로 테스트 코드를 더 짜고 테스트를 더 해야겠다.)
Don't
문제상황 1차원적 검토
테스트코드가 문제를 실제로 해결해주지 않음
-> 문제 재발 시 개발자 역량 부족으로 비침
-> QA의 부족 등등 더 복합적 문제가 있음에도 원인 탐구기회 자체가 없어짐
팀플레이어다운 응답
"출시 후 1년간 제품 복잡도가 지수적으로 높아졌는데요,
이로 인해 기능 추가 비용이 커지고 수정에 취약한 코드가 되었습니다.
일례로 지난주의 버그는 자칫했다간 N억 원의 손실을 낼 위험이 있었습니다.
팀 차원에서 리스크의 심각성을 인지하고, 해결책을 논의해 봐요."
팀플레이어 동료들의 응답
일정 관점 - "공감합니다. 기능 개발과 코드 개선이 변행 되도록 일정을 잡아봐요."
최소 테스트 관점 - "금액 정합성 테스트만 넣어도 리스크를 줄일 수 있겠어요."
QA환경 개선 접근 - "음, 저는 손테스트조차 하기 어려운 환경이 원인인 것 같아요.
개발자 도움 없이도 기능테스트가 가능하도록 어드민을 만들면 어때요?"
Learning
겉으로 드러난 문제 이면의 원인 찾기
- 혼자 끙끙대지 말고
- 팀 차원에서 공감대 형성 후
- 목표 달성을 위한 최선의 방법을 찾아내자
1. 관계
Situation 1
어느 날 PM이 말했다.
"외부사 API 완료일이 또 늦어졌네요...
일주일 더 필요하대요. 저희 릴리즈 일정 괜찮을까요?"
응답
"저희 일정도 늦어지죠... 저희도 일주일 추가하면 될 것 같아요."
Don't
일정 지연이 유발하는 문제를 고민하지 않고 수동적으로 일정 미룸
일정의 불확실성 증가('또 미뤄지면 어떡하지?')
팀플레이어다운 응답
"외부사 API가 늦어도 X일까지 되지 않으면"
버퍼로 잡아둔 목표일정인 Y일이 불가해요.
스펙 줄여서 Y일까지 되게 만들던지, 아니면 일정을 조정해 봐요."
Do
일정의 의존관계를 명료하게 드러냄.
듣는 이가 궁금한 "목표일까지 되어야 하는데..."에 대한 해결책도 함께 전달
Situation 2
디자이너에게 받은 시간을 보니
굉~장히 복잡한 페이지 1개가 있다.
그런데 개발 리소스가 부족하다...
응답
"오... 꽤 기능이 많은 페이지네요. 2주 내로 배포 목표해 볼게요."
(그리고 일정에 쫓겨 야근한다.)
Don't
수동적으로 디자인 검토 후 긴 개발 일정을 잡았고, 이마저도 야근으로 끝냄
개발 비용도 크고 쫓기며 개발 -> 향후 코드 유지보수 비용도 증가
팀플레이어다운 응답
- 기능의 역학관계 파악
"2주가량 걸릴 큰 스펙이네요.
여기서 X, Y는 동일 목적의 기능으로 보이는데요, 어떤가요?"
- 개발 리소스 맥락을 더해 애자일 배포 제안
(디자이너 응답 듣고)"둘을 간소화해서 개발 및 운영 공수를 줄이면
이번 주 내로 빠르게 오픈할 수 있는데
오픈 후 데이터 보고 발전시키면 어떨까요?"
Learning
임팩트에 비해 공수가 큰 작업은
중요도를 파악해 적극적으로 스펙을 줄인다.
개발공수를 투명한 전파 -> 팀이 올바른 결정을 내리는 데 일조
한 번에 여러 기능을 개발해야 한다면,
각 기능의 의존관계를 파악하고 데이터 기반으로 끊어서 배포한다.
1. 말하지 않는 것을 알아낸다.
Situation 1
동료가 어떤 생각을 하는지 궁금하다.
지금 업무가 커리어에 도움이 된다고 생각할까?
팀을 옮기고 싶어 하진 않을까?
질문
"요즘 잘 지내세요?"
Don't
생각을 검열하고 답하게 됨,
요약해서 답변하게 되어 구체적인 이야기로 들어가기 어려움
팀플레이어다운 장치
위클리(혹은 원오원)에 [역량 체크인] 템플릿 도입.
1. 최근에 해본 노력
2. 못 하고 있어 아쉬운 것
3. 블로커
Do
회고를 통해 내 시도(긍정)와 욕구(아쉬움)를 마주하도록
나만 하는 고민이 아님을 알기
정기적 욕구파악 -> 성장할 수 있는 방향의 일을 하도록 돕기
Situation 2
요즘 성과가 잘 안 나는 것 같다...
내가 지금 하는 일 이상으로
팀의 성과를 폭발시킬 다른 일이 있을까?
거시적 관점이 있는 PM에게 물어보자.
질문
"요즘 XX 한 문제가 있는 것 같아요.
해결하기 위해 제가 더 할 수 있는 일이 있을까요?"
Don't
평소에 생각해 본 질문이 아니라면 의미 있는 답을 주기 어려움.
답변이 XX 문제에 집중됨(이상의 문제가 있을 수 있는데)
팀플레이어다운 질문
"요즘 일할 때 XX가 잘 안 된다고 느껴져요... PM님은 어떠세요?"
PM이 관련한 고민과 시도를 전달해 줌 ->
내 전문성을 더해 풀어낼 수 있을지 함께 고민
Do
내 고민 먼저 오픈 -> 상대방 최근 생각을 이끌어냄 -> 문제 공감대 맞추기
-> 각자 전문성을 발휘할 수 있는 최선의 해결책을 찾기
Learning
포괄적 질문은 -> 포괄적 답변을 이끎
상황을 쉽게! 떠올릴 수 있도록 질문
e.g 커뮤니케이션에 대한 철학을 말해주세요 (X)
지난 프로젝트에서 동료가 어려움을 겪었을 때 어떤 행동을 하셨나요? (O)
상황파악 전까지는 판단 유보 -> 진실을 찾아낼 수 있는 접근
정리
업무 전후에 다음 질문을 되물어보자
- 본질이 무엇인가?
- 어떤 관계가 얽혀있는가?
- 이들이 말하지 않은 속마음은 무엇인가?
-> 모두 본질을 찾는 여정
권할 수 있는 액션아이템
앞으로 1달간, 동료의 멋진 행동 3개 모아 보기
- 자주 들여다보지 않아도 됨. 관찰하고 적어 객관화하는 것만으로도 의미.
- 있어 보이게 쓸 생각 없이 막 적어보는 게 중요 -> 나중에 10개 모이면 정리
- 사례를 적고, 액션아이템을 끌어내자
사례 예시)
- 맥북 구매요청을 할 때 본인뿐 아니라 팀을 챙기고 수치적 근거를 제시하는 게 멋지다(성능으로 인한 시간소비 -> 내 자원 낭비 -> 논리적 근거)
Action Item
- 당연해 보이는 일이라도 수치를 들어 설득력 있게 말하자
- 나뿐이 아니고 팀의 문제임을 용기 있게 판단하고 뚝심 있게 해결하자
나의 Action Item
- 1년 뒤에 이불킥 하기
do, don't를 현재 제 뇌에서 짜낼 수 있는 가장 좋은 방법으로 적었지만,
1년 뒤에 다시 보면 이불킥 할 것 같기도.
다만, 이불킥 한다는 건 성장했다는 반증이니, 이불킥 하기를 바랍니다.
Reference
