개발자와 소통할 때, Do/don’t

이 글은 52g(GS Open Innovation) Studio에서 일하며 IT 백그라운드가 없는 현업 크루와 개발자가 원활하게 소통하기 위한 제언을 정리한 글입니다. 52g의 조직적 특수성에서 기인하는 내용을 제외하고 개발자와 일하는 누구나에게 해당하는 내용만 남겨 정리해봤습니다.

Do

• 무엇을 원하는지, 글이든 그림이든 정리해서 주면 좋아요.

  • 소위 말하는 ‘와이어프레임’을 기깔나고 멋지게 그릴 필요는 없어요. 개발자와 디자이너 모두 작업을 시작하기 위한 초기 설계 도면이 필요한 것 뿐이에요. 어떤 요소가 들어가야 하고, 그 요소가 어떤 의도를 가지고 어떻게 동작해야 하는지 알고 싶어요. 손으로 그린 그림이어도 좋아요.

• “왜”에 대해 잘 설명해 주세요.

  • 목표까지 도달하는 최적의 방법을 찾아내고 싶어도, 이 기능과 이 화면을 왜 만들어야 하는지 잘 모르면 최적의 방법을 찾아낼 수 없어요. “왜”를 명확하게 설명하고 공유해주면 동기부여도 더 명확하게 되기 때문에, 더 멋진 결과물을 낼 수 있어요.

  • 문제 해결의 관점에서 발견한 문제가 무엇인지, 어떤 것을 실행해야 하는지, 개발자의 관점에서 좋은 대안이 있는지, 개발을 진행하는 데 문제는 없는지 등 먼저 의견을 물어보는 형태로 접근하고 도움을 요청하는 형태의 대화를 시도하는 것이 좋다. - <오늘도 개발자가 안 된다고 했다>, 215p

  • 이를테면 이런 내용을 문서든, 구두 커뮤니케이션이든, 넣어주면 좋아요. “이 화면은 (어떤 사용자가) (이렇게 조작해서) (이런 결과를 얻었으면 한다.)”

• 필요한 Due date가 있다면 명확히 말해 주세요.

  • 변동이 없어야 한다는 이야기는 아니에요. 일정은 프로젝트를 진행하면서 얼마든지 바뀔 수 있지만, 반드시 지켜야 하는 due date가 있는 경우엔 미리 얘기해 주실수록 이에 맞추어 개발프로세스를 진행할 수 있어요.

  • “금방”, “오래”, “빨리” 같은 주관적인 시간산정에 대한 단어보다는 몇 시간, 며칠, 몇 주 등의 객관적인 단위로 소통할수록 좋아요.

• 개발 삽을 뜨기 전까지 최대한 명확하게 원하는 산출물에 대해 합의해요.

  • 한 번 개발을 시작하면 디자인~노코드로 만들 때보다 더 많은 리소스가 들 뿐더러, 개발 중간에 목표하는 산출물이나 목표가 바뀐다면 이른바 “컨텍스트 스위칭”이 일어나면서 많은 리소스를 낭비하게 돼요.

Don’t

• 구조에 대한 고려가 없는 요청은 힘들어요.

  • 개발은 건물을 쌓아올리는 작업과 비슷해요. 삽을 뜨기 전 결정한 큰 틀의 구조와 뼈대는 쉽게 바꾸기 힘들어요. 다 지은 건물을 옆으로 1m만 옮겨달라는 요청은 불가능한 것처럼, 이미 설계된 개발 구조를 고려하지 않은 요청은 반영하기 힘들어요.

  • 만든 프로덕트를 어떤 기술적 환경에서 어떤 사용자가 사용하느냐는 구조를 설계할 때 매우 중요한 정보이기 때문에, 이 정보는 최대한 변동 없이 미리 공유하면 좋아요.

• “어떻게든 빨리”

  • “어떻게든 빨리 일단 되게 해주세요”와 같은 요청은

  • 기간산정 없이

  • 최소한의 기술적인 안정성을 담보할 수 없고

  • 보안 이슈를 체크하기 어려운 상태로 프로덕트를 만들 수밖에 없어

  • 오류의 원인이 되기 쉽고, 현업에 이관하는 등 정보를 공유해야 할 때 매우 번거로워질 수 있어요.

• 테스트를 거치며 추가 요구사항이 생긴다면 바로 반영하기 힘들어요.

  • 우리는 여러 번의 이터레이션을 통해 만들고자 했던 것이 잘 만들어졌는지 확인하는 데에 집중해요. 추가 요구사항이 계속해서 늘어난다면 프로젝트 마무리를 짓기 힘들고, 모두가 “끝없이 늘어나는 프로젝트의 굴레”에 빠지게 됩니다.

  • 만약 이번 프로젝트, 혹은 프로토타입의 범위를 벗어나는 더 좋은 아이디어가 생각났다면 백로그로 정리해서 다음 페이즈에 실천해요.