디자이너를 코드 검토 프로세스에 참여시켜 더 나은 협업

개발자와 디자이너 간의 원활한 협업은 모든 사람이 열망하는 것이지만 매우 어렵습니다. 그러나 오늘날의 고급 웹에서는 여러 분야의 협업 없이 진정으로 훌륭한 제품을 구축하는 것이 불가능하지는 않더라도 어렵습니다. 제품을 구축하는 데 필요한 기술의 범위 때문에 제품은 개발자 와 디자이너, 콘텐츠 제작자, 사용자 경험 전략가와 같은 모든 분야가 프로젝트 초기 단계부터 깊이 관여할 때만 진정으로 성공할 수 있습니다. 이런 일이 발생하면 제품을 만드는 데 필요한 모든 것이 자연스럽게 하나로 통합되어 훌륭한 제품이 됩니다.

이 때문에 아무도 더 이상 폭포수 프로세스를 실제로 홍보하지 않습니다. 그럼에도 불구하고 다른 사람들, 특히 다른 분야의 사람들을 일찍 참여시키는 것은 두려운 일입니다. 최악의 경우 "위원회에 의한 설계"로 이어집니다.

또한 디자이너와 콘텐츠 전략가 모두 독창적인 천재가 여전히 이상적인 분야에 대한 배경 지식을 갖고 있는 경우가 많습니다. 다른 사람이 당신의 작업을 증명하게 하는 것은 당신의 창의성에 위협이 될 수 있습니다.

그렇다면 어떻게 초기에 사람들을 참여시켜 폭포를 피하면서 동시에 위원회의 설계를 위해 자신을 설정하지 않도록 할 수 있습니까? 코드 리뷰에 대해 배울 때 답을 찾았습니다.

아하! 순간

2017년 7월에 저는 두 명의 개발자와 함께 Confrere를 설립했으며 첫 번째 엔지니어를 빠르게 고용했습니다(저는 개발자가 아니라 UX 또는 콘텐츠 디자이너에 가깝습니다). 우리의 협업은 놀라울 정도로 순조롭게 진행되어 회고전에서 되풀이되는 주제는 우리 모두가 "올바른 일을 하고 있다"는 것이었습니다.

나는 동료들과 함께 우리가 "올바른 일"을 하고 있는지 정확히 찾아내서 회사가 성장하고 팀이 확장되더라도 그 느낌을 유지하려고 노력했습니다. 우리는 전체 팀이 초기에 참여하고 서로에게 정직하고 명확하게 피드백을 주고 있다는 사실을 모두 감사하게 생각한다는 사실을 깨달았습니다. CTO Dag-Inge는 다음과 같이 덧붙였습니다. 당신은 꾸지람을 받고 있는 것이 아니라 단지 결함 목록을 받고 있을 뿐입니다.”

'동료'라는 단어는 나에게 순간을 준 것입니다. UX, 디자인, 콘텐츠 분야에서 일하는 사람들은 협업에 관해 개발자들에게 배울 점이 많다는 것을 깨달았습니다.

코드 리뷰 형태의 피어 리뷰는 소프트웨어 구축 방식에 필수적입니다. 나에게 코드 리뷰는 우리 자신의 분야 내에서 협업을 개선하는 데 영감을 줄 뿐만 아니라 여러 분야와 분야에서 협업하기 위한 모델이기도 합니다.

코드 리뷰에 이미 익숙하다면 다음 섹션을 건너뛰어도 됩니다.

코드 검토란 무엇입니까?

코드 리뷰는 다양한 방법으로 수행할 수 있습니다. 오늘날 가장 일반적인 형태의 코드 검토는 소위 pull 요청(git이라는 기술 사용) 방식으로 발생합니다. 아래 그림과 같이 pull 요청을 통해 팀의 다른 사람들은 개발자가 기본 코드 기반과 병합하려는 코드를 완료했음을 알 수 있습니다. 또한 팀은 코드를 검토할 수 있습니다. 개선이 필요한 경우 병합되기 전에 코드에 대한 피드백을 제공합니다.

pull 요청에는 명확하게 정의된 역할이 있습니다. 작성자와 검토자가 있습니다.

예를 들어 선임 엔지니어 Ingvild가 Confrere의 가입 절차를 변경했다고 가정해 보겠습니다. 기본 코드 베이스에 병합되어 배송되기 전에 그녀(저자)는 CTO Dag-Inge(검토자)에게 검토를 요청하는 풀 요청을 생성합니다. 그는 그녀의 코드를 변경하지 않고 주석만 추가합니다.

리뷰에서 받은 피드백에 대해 어떻게 행동할지는 Ingvild에게 달려 있습니다. 그녀는 적절하다고 생각하는 변경 사항으로 풀 리퀘스트를 업데이트할 것입니다.

검토자가 pull 요청을 승인하면 Ingvild는 변경 사항을 기본 코드 베이스와 병합할 수 있습니다.

왜 코드 검토를 귀찮게 합니까?

코드 검토를 한 번도 해본 적이 없다면 위의 프로세스가 관료적으로 들릴 수 있습니다. 의심이 가는 경우 코드 검토의 이점에 대한 수많은 블로그 게시물과 학술 연구를 참조하세요.

코드 검토는 우리가 하는 모든 일을 다른 사람들이 조사할 수 있도록 공개해야 하며 그러한 조사가 위협적인 것으로 간주되기보다는 워크플로에서 환영받는 부분이어야 한다는 회사 전체의 분위기를 조성합니다.

— Bruce Johnson, Full Story 공동 설립자

코드 검토는 위험을 줄입니다. 누군가가 당신의 작업을 증명하게 하고 누군가가 당신의 작업을 증명할 것이라는 것을 아는 것은 오류를 제거하고 품질을 높이는 데 도움이 됩니다. 또한 일관성을 보장하고 모든 팀 구성원이 더 많은 코드 기반에 익숙해지도록 도와줍니다.

코드 검토를 제대로 수행하면 협업과 개방성을 위한 문화도 구축됩니다. 다른 사람의 작업을 이해하고 비판하는 것은 훌륭한 학습 방법이며, 자신의 작업에 대한 정직한 피드백을 받는 것도 마찬가지입니다.

항상 두 명 이상의 사람이 코드를 살펴보게 하면 "내" 코드와 "당신의" 코드에 대한 아이디어가 줄어듭니다. 그것은 우리의 코드입니다.

이러한 장점을 고려할 때 리뷰는 코드에만 국한되어서는 안 됩니다.

강령뿐만 아니라 모든 분야에 대한 원칙 검토

리뷰에는 항상 한 명의 저자와 한 명 이상의 리뷰어가 있습니다. 즉, 위원회의 설계에 빠지지 않고 초기에 사람들을 참여시킬 수 있습니다.

먼저, 유익한 검토를 수행하는 팀의 능력에 영향을 미칠 두 가지 중요한 요소를 언급해야 합니다. 반드시 마스터할 필요는 없지만 최소한 다음을 열망해야 합니다.

• 당신과 당신의 동료들은 서로 그리고 서로의 규율을 존중합니다.
• 당신은 자신의 역할에 대해 충분히 자신감이 있어서 비판을 주고받을 수 있다고 느낍니다(이는 팀의 심리적 안전과도 관련이 있습니다).

코드를 검토하지 않더라도 기존의 코드 검토 모범 사례에서 배울 것이 많습니다.

우리 팀 내에서 검토할 때 다음 원칙을 준수하려고 노력합니다.

1. 작가가 아니라 작품을 비판하라.
2. 비판적이지만 친절하고 호기심을 유지하십시오.
3. a) 제안 b) 요구 사항, c) 논의 또는 설명이 필요한 요점을 구분합니다.
4. 토론을 텍스트에서 대면으로 이동합니다. (비디오 카운트)
5. 좋은 부분은 칭찬하는 것을 잊지 마세요! 영리하고, 창의적이고, 견고하고, 독창적이고, 재미있고, 좋은 등은 무엇입니까?

이러한 원칙은 우리의 협업이 잘 작동하는 이유에 대해 논의한 후에야 실제로 작성되었습니다. 우리 모두는 이미 질문하고 개선 사항을 제안할 수 있고 기대할 수 있으며, 우리의 동기는 항상 다른 사람을 비판하는 것이 아니라 함께 훌륭한 것을 구축하는 것이라고 생각했습니다.

어떤 피드백을 주고 있는지 명확하게 하고 서로의 좋은 점을 칭찬하는 것도 잊지 않았기 때문에 리뷰를 하는 것이 의욕을 떨어뜨리기 보다는 긍정적인 힘이 되었습니다.

예

우리 팀이 여러 분야와 프로세스 전반에 걸쳐 리뷰를 사용하는 방법에 대한 아이디어를 제공하기 위해 가입 절차를 만들 때 팀의 여러 구성원이 작성자와 리뷰 작성자의 역할 사이를 전환한 방법을 살펴보겠습니다.

1단계: 요구 사항 수집

저자: Ida (UX)

검토자: Svein(전략), Dag-Inge(엔지니어링), Ingvild(엔지니어링).

화이트보드 세션에 구조가 없으면 피곤할 수 있습니다. 생산성과 창의성을 유지하기 위해 화이트보드에서 브레인스토밍하는 것처럼 기본적인 것처럼 보이는 경우에도 작성자/검토자 구조를 사용합니다. 이 경우 가입 절차에 대한 요구 사항을 제시할 때 내가 작성자가 되었고 나머지 팀이 피드백을 제공하고 리뷰어 역할을 했습니다. 그들은 또한 내가 2단계에서 생각해낸 것을 검토할 수 있다는 것을 알고 있었기 때문에(조정, 제안 및 개선을 위한 더 많은 기회) 우리는 신속하게 작업했고 2시간 이내에 요구 사항에 동의할 수 있었습니다.

2단계: 현미경을 사용한 모형

저자: Ida (UX)

검토자: Ingvild(엔지니어링), Eivind(디자인), Svein(전략).

저자로서 저는 마이크로카피를 사용하여 가입 절차의 모형을 만들었습니다. 가입 절차가 사용자와 엔지니어링 관점 모두에서 의미가 있었습니까? 그리고 디자인과 프론트엔드 관점에서 어떻게 흐름을 개선할 수 있을까요? 이 단계에서는 모든 분야에서 피드백을 제공하기 쉬운 형식으로 작업하는 것이 필수적이었습니다(Google 문서도구를 선택했지만 InvisionApp과 같은 도구를 사용하여 수행할 수도 있음).

3단계: 가입 절차 구현

저자: Ingvild(엔지니어링)

검토자: Ida(UX) 및 Dag-Inge(엔지니어링).

우리는 흐름, 입력 필드 및 마이크로카피에 동의했으며 이를 구현하는 것은 Ingvild에 달려 있습니다. Surge 덕분에 코드를 읽을 수 없는 사람들도 이 단계에서 피드백을 제공할 수 있도록 변경 사항의 미리보기 URL을 자동으로 생성할 수 있습니다.

4단계: 사용자 테스트

저자: Ida (UX)

검토자: 사용자.

예, 사용자 테스트를 검토 형식으로 간주합니다. 새로 구축한 가입 절차를 실제 사용자와 직접 대면했습니다. 이 단계를 통해 우리는 많은 통찰력을 얻었고, 결과적으로 가입 흐름에서 가장 중요한 변화가 나타났습니다.

5단계: 디자인

저자: Eivind (디자인)

검토자: Ingvild(엔지니어링) 및 Ida(UX).

5단계에서 갑자기 디자인이 나타나면 폭포수 프로세스처럼 보일 수 있습니다. 그러나 우리 디자이너 Eivind는 이미 2단계부터 검토자로 참여하고 있었습니다. 그는 그 단계에서 유용한 피드백을 많이 주었고 기존 모듈을 넘어 가입 흐름의 디자인을 개선할 수 있는 방법에 대해 생각할 수 있었습니다. 우리의 디자인 시스템에서. 이 단계에서 Eivind는 사용자 테스트에서 식별한 몇 가지 문제를 해결하는 데도 도움이 될 수 있습니다.

6단계: 구현

저자: Ingvild(엔지니어링)

검토자: Eivind(디자인), Ida(UX) 및 Dag-Inge(엔지니어링).

그리고 다시 구현으로 돌아갑니다.

리뷰가 작동하는 이유

요약하면 항상 한 명의 작성자만 있으므로 위원회의 설계를 피할 수 있습니다. 초기에 다양한 분야를 검토자로 참여시킴으로써 폭포수 프로세스를 피할 수 있습니다.

사람들은 초기에 우려 사항을 표시하고 나중에 기여할 수 있는 방법에 대해 생각할 수도 있습니다. 명확하게 정의된 역할은 프로세스를 계속 진행합니다.

정기 검토 연습

코드 연습에서 영감을 받아 다음 원칙에 따라 다른 초점으로 정기적인 검토 연습도 수행합니다.

• 연습은 함께 수행 됩니다.
• 한 사람 이 검토 및 문서화를 담당합니다.
• 아이디어는 문제를 식별하는 것이지 반드시 해결해야 하는 것은 아닙니다.
• 가능한 한 많은 컨텍스트를 제공하는 형식 을 선택하여 나중에 결과에 따라 쉽게 조치를 취하십시오(예: 시각적 검토의 경우 InvisionApp, 텍스트의 경우 Google 문서도구 등).

접근성 감사, 기능 요청 검토, 디자인 구현 감사, 발견적 사용성 평가 수행과 같은 작업에 대한 검토 연습을 수행했습니다.

분기별 접근성 검토를 수행할 때 접근성 컨설턴트인 Joakim은 먼저 인터페이스와 문서를 살펴보고 공유 Google 시트에서 발견한 문제의 우선 순위를 지정합니다. 그런 다음 Joakim은 그가 식별한 가장 중요한 문제에 대해 설명합니다.

문제를 해결하기 위해 얼굴을 맞대고(또는 최소한 비디오로) 만나면 감독이나 세세한 관리를 받는 느낌보다는 학습 환경을 조성하는 데 도움이 됩니다.

출시 예정인 일에 항상 묶여 있거나 받은 편지함 상단에 있는 내용을 수정하는 경우 리뷰를 통해 문제를 해결할 수 있습니다. 이미 수행한 작업을 검토하기 위해 정기적으로 반나절을 할당하면 긴급한 문제가 되기 전에 문제를 식별할 수 있습니다. 또한 초점을 다시 맞추고 우선 순위가 올바른 방향으로 유지되고 있는지 확인하는 데 도움이 될 수 있습니다. 기존 기능이 표준에 부합한다고 확신하기 전에는 팀에서 새 기능 구축을 시작해서는 안 됩니다.

사용자 테스트는 검토의 한 형태입니다.

코드 리뷰의 중요한 동기는 위험을 줄이는 것입니다. 제품에 변경 사항을 도입하거나 새로운 것을 추가할 때마다 이 작업을 수행함으로써, 무언가가 수준에 미치지 못한다고 의심될 때뿐만 아니라 버그나 수준 이하의 기능을 제공할 가능성을 줄일 수 있습니다. 같은 관점에서 사용자 테스트를 봐야 한다고 생각합니다.

주요 사용성 문제가 있는 배송 위험을 줄이려면 사용자 테스트가 프로세스의 일부여야 합니다. UX 디자이너가 인터페이스를 검토하도록 하는 것만으로는 충분하지 않습니다. 여러 연구에 따르면 사용성 전문가조차도 모든 실제 사용성 문제를 식별하는 데 실패합니다. 평균적으로 전문가가 식별한 문제 3개 중 1개는 잘못된 경보였습니다. 실제로 사용자에게는 문제가 아니었습니다. 그러나 더 나쁜 것은 사용자가 실제로 겪었던 2가지 문제 중 1가지가 전문가들에 의해 간과되었다는 점입니다.

사용자 테스트를 건너뛰는 것은 코드 검토를 건너뛰는 것만큼 큰 위험이 있습니다.

검토는 창의성에 죽음을 의미합니까?

디자인, 사용자 경험 및 콘텐츠 분야에서 일하는 사람들은 종종 예술 학교나 문학에서 교육적 배경을 가지고 있으며, 유일한 창작자 또는 창의적인 예술적 천재가 이상형으로 환영받습니다. 역사를 거슬러 올라가면 이것은 개발자에게도 마찬가지였습니다. 시간이 지남에 따라 웹 개발이 더욱 복잡해짐에 따라 필요에 따라 변경되었습니다.

자신의 내면 깊은 곳에서 나오는 창의성에 대한 생각에 집착하면 검토라는 생각이 위협적이거나 무섭게 느껴질 수 있습니다. 누군가가 당신의 반쯤 완성된 일에 간섭합니까? 아야. 그러나 창의성을 대화, 협업 또는 모든 형태의 영감(외부에서든 내부에서든)을 포함하여 다양한 출처에서 나올 수 있는 것으로 생각한다면 검토는 자산이자 기회일 뿐입니다.

우리가 웹용으로 무언가를 구축하는 한, 우리 자신의 분야에서든 다른 사람들과 협력하든 다른 사람들과 협업하는 방법은 없습니다. 그리고 좋은 아이디어는 리뷰에서 살아남을 것입니다.

함께 멋진 것을 만들어 봅시다.