하나의 작은 작업 단위도 애자일 방법론을 적용해보면
[커뮤니케이션]을 잘 하기 위해 생각해보는 과정
1. 재질문을 통해 요구사항을 높은 수준으로 이해하기 (팀장님 생각==내생각)
2. 상대방이 작업의 맥락을 충분히 이해할 수 있도록 설명.
3. 작업물을 꼼꼼히 확인하고, 필요한 수정 사항 즉시 전달.
보통 어떤 요청사항을 전달하면
그래서 제가 뭘 해드려야 해요?
왜 해야돼요?
이 질문이 나올 확률이 높음. 추가로 언제까지 해야돼요. 가 있겠음.
[상황 예시: 요구사항]
A 에 대한 이미지를 디자인팀에 요청 할 것.
이런 요청을 받았을 때, 아무 생각 없이 "넵"하고 넘어가면 나중에 난감한 상황이 발생함.
1. 재질문을 통해 요청사항 구체화
(1) 왜 그 업무가 필요한지 질문 드리기
업무 받는 사람들이 물어볼 확률이 높은 질문임
일해야 하는 목적.
(2) 기준/범위를 구체화하는 질문 드리기
"A에 대한 이미지"라는 말을, 기준을 명확히 하는 질문을 던져야 함.
상대방이 떠올리는 것 == 내가 생각한 것. 이 되어야 함.
예를 들어, 차라리 자율성이 높아서 아무거나라면 상관없을수도 있는데
그렇지 않다면 딱 정해줘야 함.
옷 이미지 라고 했을 때, 사람이 입고있어야 하는지, 그냥 옷 사진만 있으면 되는지, 상의인지 하의인지..
그래서 윗분에게도 이 기준으로 말씀하신 것이 맞는지 재질문도 해보기. 보통은 그림이나 이미지로 전달하면 편함.
그런데 이 질문들은, 연차 쌓이신 분들에게는 너무 당연한거라 질문 받으시는게 귀찮은 것일수도 있음. 왜냐면 .. 당연하니까?? ㅋㅋ 근데 내 입장에서는 모를수도 있음. 그냥 그럴땐 질문드리는게 속편함.
어쨌든 이렇게 기준이나 범위에 대한 질문을 던져야
작업의 범위를 확정 짓고, 작업을 설명하는 과정에서 아차 하고 다시 확인해보고 오겠습니다. 하는 경험을 줄일 수 있음.
(3) 마감일 확정하기
- 내가 생각한 마감일 또는 윗분의 마감일
이 이미지가 형상관리 툴에 업로드, 배포되고 다른 이들에게 선보일 시점을 역으로 계산하기
2. 일의 목적에 대해 설명드리기
이렇게 재질문하여 정리한 후, 어떻게 해주세요 만 전달하는게 아니라,
어떤 이유에서 이 업무를 해야 하는지 함께 설명하면 상대방이 질문을 하시기도 한다. 여기서 변경 사항이 발생 가능함(애자일 떠올리기)
그러면 내가 결정하기 어렵다면 윗분들에게 공유드리기.
그래서 일은 최대한 빨리 진행하는 편이 낫다. 언제 예측하지 못한 일이 눈앞에 벌어질지 모름.
3. 요구사항 충족 여부 확인 및 그 외에 차이점 확인
생각보다 뭘 어떻게 해주세요 해서 받은 작업물이 요구사항 충족되어있지 않거나 요구사항 범위를 벗어난 경우도 있음.
이는 작업하는 사람도, 결과물을 받은 사람도 잘 발견하지 못하는 경우가 있음.
예)
오타가 있거나
뭐가 빠졌거나
뭐가 더 들어갔거나..
(1) 그래서 정확하게 요구사항이 충족 됐는지도 확인해야 하는 동시에
(그래서 앞서 말한 것처럼 정확하게 요구사항애 대한 기준이 필요함. 나는 뭘 확인해야 하는지에 대해)
(2) 요청하지 않았지만 확인 가능한 다른 세부사항을 확인해봐야 한다.
말이 이상하긴 한데, 보통은 프로젝트에 반영 할 때 발견되기도 함.
예를 들면 개수가 다르거나 오타가 있거나 확장자가 다를수도 있고, 파일명이 컨벤션에 맞지 않는 부분이 있을수도 있음.
그래서 최대한 전 과정이 빨리 진행되어야 함. 수정사항 요청 드릴 때 덜 민망함.. (다시한번 애자일 떠올리기)
회고해보며 떠오른건데, 애자일 자체가 .. 빠른 피드백 이라면 이런 요구사항 하나에도, 적용되는 것 아닌가
최대한 능동적인 커뮤니케이션이고.
앞서 정리한 내용을 다시 얘기해보면
1. 재질문을 통해 요구사항을 높은 수준으로 이해하기 (팀장님 생각==내생각)
2. 상대방이 작업의 맥락을 충분히 이해할 수 있도록 설명.
3. 작업물을 꼼꼼히 확인하고, 필요한 수정 사항 즉시 전달.
그래서 (이 JD 해석한 내용을) 면접에 대입해 본다면,
면접관의 질문에 여러가지 답변이 떠오르는 경우, 어떤 대답을 원하시는지 질문을 해볼 수 있고(답이 정해지지 않은 문제라면 더욱)
그 과정에서 좀 틀려도 주체적으로 답을 찾아가려는 사람으로 느껴지지 않을까 싶음.
.. 근데 면접관마다 다를 수는 있겠음.ㅎㅎ
주체적으로 정의하고 일하는 사람이란 이런 내용도 포함될 것 같음.
'주니어 개발자 시리즈' 카테고리의 다른 글
| 일이 어려워지고 생각이 복잡해지는건 "기준"이 없어서 라고 생각해(주니어 개발자 시리즈) (2) | 2026.01.27 |
|---|---|
| 복잡한 코드베이스, 빠르게 분석하기 (주니어 개발자의 JD 읽기) (0) | 2025.12.28 |
| 개발 외 업무를 프로그래밍적으로 생각하기 1편 (주니어 개발자 시리즈) (0) | 2025.12.04 |
| 주니어 개발자의 기본 1(주니어 개발자 시리즈) 12.04 18:00 수정본 (3) | 2025.12.03 |
| 자료 만들 때 내용 구성에 있어서, 문서를 보는 사람이 궁금해 하는 것을 꼭 넣어야 한다 (주니어 개발자 시리즈) (0) | 2025.11.21 |