---

당신은 블루가 블루를 어떻게 구축하는지에 대한 내부 투어를 받을 준비가 되어 있습니다.

블루에서는 우리의 제품을 직접 사용합니다.

이는 우리가 블루를 사용하여 블루를 구축한다는 것을 의미합니다.

이상하게 들리는 이 용어는 종종 1980년대 마이크로소프트의 관리자였던 폴 마리츠에게 귀속됩니다. 그는 마이크로소프트 직원들이 회사의 제품을 사용하도록 장려하기 위해 *"자신의 제품을 사용하자"*라는 제목의 이메일을 보냈다고 전해집니다.

자신의 도구를 사용하여 도구를 구축하는 아이디어는 긍정적인 피드백 사이클로 이어진다는 것입니다.

자신의 도구를 사용하여 도구를 구축하는 아이디어는 긍정적인 피드백 사이클로 이어져 여러 가지 이점을 창출합니다:

• 실제 사용성 문제를 신속하게 식별하는 데 도움이 됩니다. 우리는 매일 블루를 사용하면서 사용자들이 직면할 수 있는 동일한 문제에 직면하게 되어 이를 사전적으로 해결할 수 있습니다.
• 버그 발견 속도를 가속화합니다. 내부 사용은 종종 고객에게 도달하기 전에 버그를 드러내어 전체 제품 품질을 향상시킵니다.
• 최종 사용자에 대한 공감을 강화합니다. 우리 팀은 블루의 강점과 약점을 직접 경험하게 되어 보다 사용자 중심의 결정을 내리는 데 도움이 됩니다.
• 조직 내 품질 문화를 촉진합니다. 모든 사람이 제품을 사용할 때, 그 우수성에 대한 공동의 이해가 생깁니다.
• 혁신을 촉진합니다. 정기적인 사용은 종종 새로운 기능이나 개선 아이디어를 자극하여 블루를 최전선에 유지합니다.

우리가 전담 테스트 팀이 없는 이유에 대해 이전에 이야기한 적이 있습니다 그리고 이것이 또 다른 이유입니다.

우리 시스템에 버그가 있다면, 우리는 거의 항상 플랫폼을 지속적으로 사용하는 과정에서 이를 발견합니다. 그리고 이는 우리가 블루의 주요 사용자 중 하나이기 때문에 이를 매우 불편하게 느끼게 되어 이를 수정해야 하는 강제적인 동기를 만듭니다!

이 접근 방식은 제품에 대한 우리의 헌신을 보여줍니다. 우리가 스스로 블루에 의존함으로써, 우리는 고객에게 우리가 구축하고 있는 것에 진정으로 믿음을 가지고 있다는 것을 보여줍니다. 이것은 우리가 판매하는 제품이 아니라 매일 의존하는 도구입니다.

주요 프로세스

우리는 블루에 "제품"이라는 이름의 프로젝트를 가지고 있습니다.

모든 제품 개발 관련 사항이 여기에서 추적됩니다. 고객 피드백, 버그, 기능 아이디어, 진행 중인 작업 등이 포함됩니다. 모든 것을 추적하는 하나의 프로젝트를 갖는 아이디어는 더 나은 팀워크를 촉진합니다.

각 기록은 기능 또는 기능의 일부입니다. 이것이 "이러면 좋지 않을까..."에서 "이 멋진 새로운 기능을 확인해보세요!"로 나아가는 방법입니다.

프로젝트에는 다음과 같은 목록이 있습니다:

• 아이디어/피드백: 이는 팀 아이디어 또는 전화 통화나 이메일 교환을 기반으로 한 고객 피드백 목록입니다. 여기에서 어떤 아이디어든 추가해 주세요! 이 목록에서는 아직 어떤 기능을 구축할 것인지 결정하지 않았지만, 우리는 정기적으로 이 목록을 검토하여 더 탐색하고 싶은 아이디어를 찾습니다.
• 백로그 (장기): 이는 아이디어/피드백 목록에서 블루에 좋은 추가가 될 것이라고 결정된 기능이 들어가는 곳입니다.
• {현재 분기}: 이는 일반적으로 "Qx YYYY" 형식으로 구성되며 우리의 분기 우선순위를 보여줍니다.
• 버그: 이는 팀이나 고객이 보고한 알려진 버그의 목록입니다. 여기에 추가된 버그는 자동으로 "버그" 태그가 추가됩니다.
• 사양: 이 기능들은 현재 사양이 지정되고 있습니다. 모든 기능이 사양이나 디자인을 필요로 하는 것은 아니며, 이는 기능의 예상 크기와 엣지 케이스 및 복잡성에 대한 신뢰 수준에 따라 다릅니다.
• 디자인 백로그: 이는 디자이너를 위한 백로그로, 진행 중인 작업이 완료되면 이 목록에서 항목을 선택할 수 있습니다.
• 진행 중인 디자인: 이는 디자이너가 디자인 중인 현재 기능입니다.
• 디자인 검토: 이는 현재 디자인 검토 중인 기능이 있는 곳입니다.
• 백로그 (단기): 이는 우리가 다음 몇 주 내에 작업을 시작할 가능성이 있는 기능의 목록입니다. 여기에서 할당이 이루어집니다. CEO와 엔지니어링 책임자가 이전 경험과 작업량에 따라 어떤 기능이 어떤 엔지니어에게 할당될지를 결정합니다. 팀원들은 현재 작업을 완료한 후 이를 진행 중으로 끌어올릴 수 있습니다.
• 진행 중: 이는 현재 개발 중인 기능입니다.
• 코드 검토: 기능 개발이 완료되면 코드 검토를 거칩니다. 그런 다음 조정이 필요한 경우 "진행 중"으로 다시 이동되거나 개발 환경에 배포됩니다.
• 개발: 이는 현재 개발 환경에 있는 모든 기능입니다. 다른 팀원들과 특정 고객이 이를 검토할 수 있습니다.
• 베타: 이는 현재 베타 환경에 있는 모든 기능입니다. 많은 고객이 이를 일상적인 블루 플랫폼으로 사용하며 피드백을 제공합니다.
• 프로덕션: 기능이 프로덕션에 도달하면 완료된 것으로 간주됩니다.

때때로 기능을 개발하는 과정에서 특정 하위 기능이 처음 예상보다 구현하기 더 어려운 것을 깨닫고, 고객에게 배포할 초기 버전에서 이를 수행하지 않기로 선택할 수 있습니다. 이 경우 "{FeatureName} V2" 형식에 따라 이름을 가진 새로운 기록을 생성하고 모든 하위 기능을 체크리스트 항목으로 포함할 수 있습니다.

태그

• 모바일: 이는 기능이 iOS, Android 또는 iPad 앱 중 하나에 특정하다는 것을 의미합니다.
• {EnterpriseCustomerName}: 이 기능은 특정 기업 고객을 위해 구축되고 있습니다. 각 기능에 대해 일반적으로 추가 상업적 계약이 있기 때문에 추적이 중요합니다.
• 버그: 이는 수정이 필요한 버그임을 의미합니다.
• 패스트 트랙: 이는 전체 릴리스 주기를 거치지 않아도 되는 패스트 트랙 변경 사항임을 의미합니다.
• 주요: 이는 주요 기능 개발입니다. 일반적으로 주요 인프라 작업, 큰 의존성 업그레이드 및 블루 내의 중요한 새로운 모듈에 예약됩니다.
• AI: 이 기능에는 인공지능 구성 요소가 포함되어 있습니다.
• 보안: 이는 보안 관련 사항이 검토되어야 하거나 패치가 필요함을 의미합니다.

패스트 트랙 태그는 특히 흥미롭습니다. 이는 전체 릴리스 주기를 요구하지 않는 작고 덜 복잡한 업데이트를 위해 예약되어 있으며, 고객에게 24-48시간 내에 배송하고자 하는 것입니다.

패스트 트랙 변경 사항은 일반적으로 핵심 기능을 변경하지 않으면서 사용자 경험을 크게 개선할 수 있는 사소한 조정입니다. UI의 오타 수정, 버튼 패딩 조정 또는 더 나은 시각적 안내를 위한 새로운 아이콘 추가와 같은 것들을 생각해 보세요. 이러한 변경 사항은 작지만 사용자들이 우리 제품을 인식하고 상호작용하는 방식에 큰 차이를 만들 수 있습니다. 또한 배송이 오래 걸리면 짜증이 날 수 있습니다!

우리의 패스트 트랙 프로세스는 간단합니다.

주요 브랜치에서 새로운 브랜치를 생성하고, 변경 사항을 구현한 다음, 각 대상 브랜치 - 개발, 베타 및 프로덕션에 대한 병합 요청을 생성하는 것으로 시작됩니다. 우리는 검토를 위해 미리보기 링크를 생성하여 이러한 작은 변경 사항도 품질 기준을 충족하는지 확인합니다. 승인되면 변경 사항은 모든 브랜치에 동시에 병합되어 환경을 동기화합니다.

사용자 정의 필드

우리는 제품 프로젝트에 많은 사용자 정의 필드가 없습니다.

• 사양: 이는 해당 기능에 대한 사양이 포함된 블루 문서에 링크됩니다. 이는 기능의 복잡성에 따라 항상 이루어지지는 않습니다.
• MR: 이는 우리가 코드를 호스팅하는 Gitlab에서의 병합 요청 링크입니다.
• 미리보기 링크: 주로 프론트 엔드가 변경되는 기능의 경우, 각 커밋에 대한 변경 사항을 쉽게 검토할 수 있도록 고유한 URL을 생성할 수 있습니다.
• 리드: 이 필드는 어떤 수석 엔지니어가 코드 검토를 담당하는지를 알려줍니다. 이는 모든 기능이 전문가의 주의를 받을 수 있도록 보장하며, 질문이나 우려 사항에 대한 명확한 연락처를 항상 제공합니다.

체크리스트

주간 데모 동안, 우리는 논의된 피드백을 "피드백"이라는 체크리스트에 추가하고, 기능의 주요 WBS (작업 분해 구조)를 포함하는 또 다른 체크리스트를 만들어 무엇이 완료되었고 무엇이 아직 남아 있는지 쉽게 알 수 있도록 합니다.

결론

그리고 그게 전부입니다!

우리는 때때로 사람들이 우리의 프로세스가 얼마나 간단한지에 놀란다고 생각하지만, 우리는 단순한 프로세스가 종종 쉽게 이해할 수 없는 지나치게 복잡한 프로세스보다 훨씬 우수하다고 믿습니다.

이 단순함은 의도적입니다. 이는 우리가 민첩하게 유지하고, 고객의 요구에 신속하게 대응하며, 전체 팀이 일치하도록 유지할 수 있게 합니다.

블루를 사용하여 블루를 구축함으로써, 우리는 단순히 제품을 개발하는 것이 아니라 그것을 경험하고 있습니다.

그러니 다음 번에 블루를 사용할 때, 기억하세요: 당신은 우리가 만든 제품을 사용하는 것이 아닙니다. 당신은 우리가 매일 의존하는 제품을 사용하고 있습니다.

그리고 그것이 모든 차이를 만듭니다.