|
애자일, 풀네임은 애자일 프로세스(Agile process)로 본래 소프트웨어를 테스트하고 피드백하기 위해 짧은 주기로 반복하는 방식을 일컬었으나 최근 변화하는 상황에 맞춰 빠르고 유연하게 일하는 업무 방식으로 그 의미가 확장되었습니다. 탁월한 유연성과 성과 향상 측면으로 인해 개발자 외 다른 조직에서도 애자일 프로세스를 적용하고 있는 추세인데요. 애자일이 대중화되는 것은 좋지만, 잘못 사용되지 않도록 애자일 본연의 가치를 제대로 아는 것이 중요할 것 같습니다. 특히 개발 조직에서 애자일 잘 쓰는 법, 플래티어 블로그가 알려드릴게요!
|
애자일에는 없는 '알잘딱깔센' 😶🌫️
2020년 실시간 검색어 1위에도 오르내린 신조어 '알잘딱깔센'은 '알아서 잘 딱 깔끔하고 센스있게'의 줄임말입니다. 이 신조어가 직장인들의 공감을 크게 산 이유가 있는데요. 고객사가 대행사에게 또는 상사가 부하 직원에게 흡사 궁예급 독심술에 기반한 결과물을 요구할 때 쓰는 전형적인 표현이었기 때문이에요. 무리한 요구를 하는 상대의 부조리함을 꼬집는 신조어였기에 다양한 밈으로 재생산되고, 여러 기업이 공감대를 노린 광고의 카피 문구로 활용했지요.
애자일 프로세스에서는 이 '알잘딱깔센'이라는 게 없습니다. 애자일은 고객과 매우 밀접하게 소통하며 결과물을 도출하는 업무 방식이기 때문이에요. 과거 개발자는 기획자와 주로 소통하고, 기획자를 통해 기획 의도만 파악하면 됐었는데요. 애자일에서는 개발자가 고객을 알아야 하고, 고객의 목소리를 직접 들어야 합니다. 고객 중심의 제품을 다른 누구도 아닌 바로 개발자가 만들어내야 하기 때문입니다. 일부 개발자들은 고객과 소통하는 것을 불편해하기도 하고, 더 나아가 고객과 협력하는 것이 불가능하다고 생각하는 경우도 있습니다. 특히 고객과 소통이 잘 되지 않아 시간과 노력을 낭비한 경험이 있다면 애자일 말고 예전처럼 기획자와 소통하는 게 더 좋은 성과를 낸다고 생각할 수 있는데요. '애자일 프로세스'에서 고객과 더 잘 협력하고, 더 나은 성과를 만들어 내는 방법 4가지를 알려드릴게요.
개발자 전용 : 고객 협력 레시피 🍔
① 더 좋은 질문하기
더 좋은 질문이란 무엇일까요? 고객에게 질문하되, 업무에 도움이 되는 답변을 얻을 수 있는 '질문'이 더 좋은 질문입니다. 예를 들어 볼게요! "무엇이 잘못되었다고 생각하세요?"라는 질문보다 "코어 타깃에게 더 설득적으로 다가가기 위해 어떤 점을 바꾸면 좋을까요?"라는 질문이 더 좋은 질문입니다. 단순히 무엇을 고치고 싶냐고 질문한다면, 고객사 담당자는 개인의 취향을 묻는 질문으로 잘못 이해할 수 있습니다. 처음 의도했던 바를 성취하기 위해 개선점을 묻을 경우, 고객사 담당자는 제품을 의뢰하며 목표했던 바를 상기하며 적절한 답변을 할 가능성이 높아집니다. 그래서 할 수 있다면 최대한 더 좋은 질문을 하세요. 답변의 정확도가 분명 높아질 거예요.
② 결정은 고객의 몫
의외로 결정 때문에 힘들어하는 경우가 많습니다. 이것은 우리가 '설계를 어떻게 할 지 결정'하는 것과 '프로젝트나 비즈니스에 대해 결정'하는 것을 혼동하기 때문인데요. 설계는 개발자의 것이지만, 결정은 고객의 몫입니다. 만약 개발자가 설계 이상의 것을 결정한다면, 그 책임도 개발자에게 돌아가는 것이죠. 서로 난처해지는 상황을 피하기 위해서는 개발자는 설계 단계에서 고객이 선택할 수 있는 옵션들을 상세히 설명해 줘야 합니다. 예를 들어 '빠르지만 기능 제약이 있는 개발'과 '시간이 더 걸리지만 더 많은 유연성이 확보되는 개발'이 가능할 때, 고객에게 이 두 가지 옵션을 설명하는 것입니다. 그리고 최종 결정은 고객이 내리도록 해야 합니다.
③ 개발자의 결정
개발자가 결정할 것은 '내가 결정하지 말아야 할 사항들을 결정하는 것'입니다. 프로젝트 내에서 발생하는 많은 일들 중 무엇이 나의 권한 밖의 일인가 확인하고 목록화하는 것입니다. 그리고 그 목록을 고객에게 전달할 수 있어야 합니다. 목록을 채우고 있는 다양한 항목에는 고객이 선택할 수 있는 옵션에 대한 내용도 필요합니다. 옵션별 장단점을 친절히 알려주세요. 그러면 고객은 직접 선택한 결과를 무리 없이 받아들일 테고요. 개발자의 애자일은 한결 수월해질 것입니다.
④ 코드 의심하기
위 ①~③ 과정을 통해 고객과의 소통이 시작되었다면, 마지막으로 할 일은 내 코드를 의심하는 일입니다. 고객의 피드백을 확인하는 과정에서 요구사항이 조금씩 변한다 해도 계속 구현이 쉬운 코드라면 좋은 설계입니다. 반대로 작은 요구에도 큰 혼란이 야기된다면 어쩌면 코드의 설계 자체를 개선해야 할지도 모릅니다. 애자일 프로세스는 변화에 대한 적응과 유연성이 중요합니다. 고객의 요구가 버겁고 스트레스로 다가온다면 그때는 이 설계가 적절한가 의심해 볼 시간입니다.
이어지는 다음 편 소개 ▶
[개발자를 위한 진짜 애자일] ② 번아웃 없이 생산성 높이는 법
[개발자를 위한 진짜 애자일] ③ 작업의 투명성 즐기는 법
