제품이 점점 더 복잡해짐에 따라 모든 것이 함께 작동하는 방식을 완벽하게 파악하는 것이 점점 더 어려워졌습니다. 또한 성장 속도를 유지하기 위해 모든 기능 사양에 대한 최신 소스를 유지 관리하는 방법을 찾아야 했습니다. 이 문서에서는 이전에 사양을 처리한 방법, 해당 접근 방식에서 발견한 문제, 완전히 새로운 사양을 생각해 낸 방법에 대해 설명합니다.

"기능별 사양"의 문제점

사양에 대한 우리의 전통적인 접근 방식은 제품 관리자가 새 화면과 기존 화면에 대해 예상되는 동작 목록을 컴파일하는 각각의 새로운 사양에 대한 전용 페이지를 갖는 것이었습니다. 이 접근 방식은 제품이 더 복잡해질 때까지, 특히 새로운 기능이 기존 화면의 일부를 무시할 때까지 잘 작동했습니다.

결과적으로 화면이 어떻게 작동하는지, 특정 요소를 업데이트할 때 앱의 다른 곳에 잠재적인 영향이 무엇인지 정확히 이해하는 것이 어려웠습니다. 코드베이스는 유일하게 신뢰할 수 있는 진실의 출처가 되었고 제품 관리자는 화면이 어떻게 작동하는지 반복적으로 설명하기 위해 엔지니어에게 의존해야 했습니다. 이것은 엔지니어의 집중을 방해하여 재작업, 낭비, 리드 타임 증가 및 좌절로 이어지는 빠르고 대략적인 답변을 제공하도록 했습니다.

프로토타입 만들기

이 문제를 해결하기 위해 우리는 사양과 디자인에 대한 신뢰할 수 있는 소스의 프로토타입을 개발해야 했습니다. 각 화면에는 고유한 소스가 있어야 합니다. 따라서 화면에서 수행된 모든 업데이트는 다른 전용 페이지가 아닌 해당 정보 소스에 반영되어야 합니다. 우리의 디자인은 Figma에 있었기 때문에 그대로 두었습니다. Notion에서 스크린샷 옆에 사양을 작성하는 것은 실제로 Figma에서 직접 사양을 작성하는 것보다 더 많은 작업이었습니다. 개발자는 동일한 Figma 파일에서 제안된 변경 사항 바로 옆에 있는 기존 사양과 함께 사양이 있는 고충실도 디자인을 즉시 볼 수 있습니다.

우리의 사양이 포괄적인지 확인하기 위해 우리는 이전 접근 방식에서 새 프로토타입에 포함하기 위해 놓친 네 가지 핵심 영역을 식별했습니다. 첫째, 조건에 상관없이 화면의 모든 요소에 대한 가시성이 필요했습니다. 둘째, 엔지니어에게 코드베이스를 역설계하도록 요청하지 않고도 요소가 어떻게 작동하는지 알아야 했습니다. 셋째, 한 화면에서 변경 사항이 다른 화면에서 원치 않게 업데이트되는 것을 방지하기 위해 요소가 여러 화면에서 공유되는지 여부를 알아야 했습니다. 마지막으로 한 화면에서 다른 화면으로 이동할 수 있는 모든 조건과 함께 화면 흐름에 대한 명확한 그림이 필요했습니다.

프로토타입 개선 및 확장

모든 디자이너를 온보딩하기 위해 우리는 그들이 인식하고 정기적으로 사용하는 플랫폼에서 특정 요구 사항에 응답하는 명확한 표준을 제시해야 했습니다. 이제 Figma에는 팀이 아닌 테마별로 폴더가 정렬된 하나의 "시각적 사양" 작업 공간이 있습니다. 모든 화면은 한 팀이 아닌 모두의 것입니다. 특정 범위를 담당하는 팀이 앱의 다른 부분에 영향을 미칠 변경 사항을 만들면 적절한 위치에서 올바른 화면을 업데이트할 수 있으며 모든 사람이 변경 사항을 자동으로 볼 수 있습니다. 이러한 방식으로 사양에 대한 현재 접근 방식은 이전보다 더 포괄적입니다. 각 테마 폴더에는 각 사용자 스토리당 한 페이지가 있습니다.

사용자 스토리의 콘텐츠는 사용자 여정의 수평적 진행을 보여줍니다. 수직적으로 각 키 화면의 가능한 모든 변형(오류 상태, 로딩 상태, 빈 상태…)이 있습니다. 사양 카드는 요소의 가능한 모든 동작을 설명하는 각 요소에 대한 완전한 허용 기준입니다. 키 화면에는 대부분의 사양이 표시되며 변형에는 특정 사양만 표시됩니다.

이제 새로운 기능을 개발할 때마다 Figma에서 새 분기를 만들고 새 요소 옆에 고유한 색상으로 새 사양 카드를 추가합니다. 기능이 완료되면 이러한 사양 카드는 "라이브" 상태로 전환되고 분기는 기본 항목과 병합됩니다. 이렇게 하면 모든 것이 깨끗하고 최신 상태로 유지되며 최상의 조건에서 새 기능을 시작할 수 있습니다.

전체 마이그레이션 수행

기술 및 제품 부서에서 일하는 방식을 업데이트하는 것은 어려울 수 있습니다. 이것이 Qonto Way가 시작된 곳입니다. 지속적인 개선은 우리 문화의 핵심입니다. 우리는 팀의 하위 집합과 함께 새로운 방법을 시도하고 유용하다고 판단되면 전체 팀에 구현합니다. 그렇지 않은 경우 폐기합니다. 사양 접근 방식을 개편할 때 우리 팀 수준에서 시작했고 사용에 직접적으로 관련된 제품/디자인/기술 팀원의 지원을 받아 이니셔티브를 완전히 주도했습니다. 이상적으로는 결국 작업하게 될 다음 기능을 다루기에 충분한 화면과 사양을 리버스 엔지니어링하기를 원합니다(저희 팀의 전체 범위를 리버스 엔지니어링하여 어떤 새로운 기능이 나오든 준비할 수 있도록 했습니다).

이 새로운 기능에 대한 귀하의 (긍정적인!) 경험을 입증하고 기술 및 제품 경영진의 동의를 얻을 수 있도록 주저하지 말고 다른 사람들에게 이 기능의 이점을 크게 홍보하십시오.

공을 굴리면 대규모로 작업하는 방식을 업데이트해야 했습니다. 우리는 기술, 제품 및 디자인과 같은 서로 다른 팀을 대상으로 각 스택에 대한 소유권을 명확하게 설명하는 검토된 표준 세트를 작성했습니다.

이 단계에 도달하면 시각적 사양에서 새로운 기능을 구축하여 기능 후 지식 기능을 통합할 수 있습니다. 그러나 모든 마지막 동작을 매핑한 후에만 이러한 방식으로 작업함으로써 얻을 수 있는 모든 이점을 얻을 수 있습니다. 상황에 따라 본격적인 매핑을 시작하는 두 가지 방법이 있습니다(각 팀에서 하나의 접근 방식을 채택할지 결정할 수 있음).

• 각 기능 팀에서 며칠 동안 생산을 중단하고 기술 팀과 디자이너에게 기존 전체 범위를 역설계하도록 요청하십시오. 이 방법에는 몇 가지 이점이 있습니다. 관련 팀은 새로운 참여자를 포함하여 전체 도메인 지식을 얻고 모든 것이 어떻게 작동하는지 100% 명확하게 알 수 있으므로 더 이상 사각지대가 없습니다.
• 새 기능을 생성하기 직전에 업데이트할 부품만 레트로 엔지니어링합니다. 이렇게 하면 누락된 것이 없으며 이 새로운 정보 소스 위에 새로운 요소를 구축할 수 있습니다. 이 접근 방식의 단점은 전체 그림을 매핑할 수 없다는 것입니다.

우리의 새로운 사양 프로세스는 작업 방식을 혁신하여 코드베이스 "동굴 다이빙"에 작별을 고했습니다. 사양 및 디자인에 대한 단일 정보 소스를 생성함으로써 우리는 사용하기 쉽고 모든 팀원이 액세스할 수 있으며 모든 화면과 사용자 스토리에서 정확한 최신 정보를 제공하는 작업 공간을 만들었습니다. 우리는 시간을 절약하고, 재작업을 줄이고, 신규 참여자의 온보딩을 가속화하고, 모든 것이 함께 작동하는 방식에 대한 보다 포괄적인 그림을 제공했습니다.

Qonto 는 Steve Anavi와 Alexandre Prot가 2016년에 설립한 중소기업 및 프리랜서를 위해 설계된 금융 솔루션입니다. 2017년 7월 출시 이후 Qonto는 350,000개 이상의 기업을 위한 비즈니스 파이낸싱을 쉽게 만들었습니다.

비즈니스 소유자는 Qonto의 간소화된 계정 설정, 무제한 거래 내역을 통한 직관적인 일상 사용자 경험, 회계 내보내기 및 실용적인 비용 관리 기능 덕분에 시간을 절약할 수 있습니다.

그들은 실시간 알림과 사용자 권한 관리 시스템을 통해 팀에 더 많은 자율성을 부여하면서 제어권을 유지합니다.

스마트 대시보드, 트랜잭션 자동 태그 지정 및 현금 흐름 모니터링 도구를 통해 향상된 현금 흐름 가시성을 활용할 수 있습니다.

그들은 또한 공정하고 투명한 가격으로 뛰어난 고객 지원을 누리고 있습니다.

도전적이고 판도를 바꾸는 회사에 합류하는 데 관심이 있으십니까? 채용 정보를 참조하십시오 !