Intercom의 제품 원칙: 최대의 고객 가치를 제공하기 위해 작은 단계에서 구축

큰 변경 사항은 이해하기 어렵고 디버그하기가 더 어렵습니다.

Intercom에서는 일련의 작고 제어되고 이해하기 쉬운 단계로 복잡한 변경 사항을 제공합니다. 작은 변경 사항을 더 쉽게 구축하고 더 빠르게 검토할 수 있으므로 고객에게 더 빨리 가치를 제공할 수 있습니다.

이것은 제품 원칙을 탐구하는 시리즈 의 일곱 번째 게시물입니다 . 여기에서 Aidan은 "작은 단계로 구축"이라는 엔지니어링 원칙에 대해 설명합니다.

아무도 그것을 항상 올바르게 이해하지 못한다.

실수는 전 세계 모든 팀, 모든 회사에서 발생합니다. 항상 올바른 결과를 얻을 수 없다는 것을 인정하면 다음 두 가지 방법 중 하나로 조정할 수 있습니다.

• 배송하기 전에 실수를 수정하고 작업을 확인하거나 확인하는 조치를 취하십시오.
• 자신이 틀릴 수 있는 여지를 허용하고, 실수로부터 배우고, 빠르게 수정하여 수정하십시오.

이미 몇 주 동안 변경 사항에 빠져 있었다면 종종 틀릴 여지가 적습니다. 이렇게 하면 변경 사항을 배송할 때 예기치 않은 상황을 피하기 위해 유효성 검사에 의존할 수 있습니다. 유효성 검사가 그 자리를 차지하고 있지만 실제로 배포하는 것에는 적합하지 않습니다. 배송 전에 수행해야 하는 검증이 많을수록 다음 기능을 반복하거나 다음 기능으로 넘어갈 때까지 시간이 더 오래 걸립니다. 결국 속도가 느려집니다.

변경 사항을 배송할 때 다음을 제어하는 ​​것을 목표로 합니다.

• 영향을 받는 변수의 수: 변경 중에 영향을 받는 변수가 많을수록 변경의 어느 부분이 문제를 일으켰는지 파악하기가 더 어렵습니다. 각 단계의 크기를 줄임으로써 피드백 루프를 강화하고 필요한 경우 훨씬 빠르게 학습하고 조정하도록 설정합니다.
• 변경의 크기: 변경 의 크기를 줄임으로써 각 변경의 폭발 반경도 줄입니다. 변경 사항을 테스트하는 것이 중요하지만 사전 검증으로 포착할 수 있는 부분만 있습니다. 작은 변경을 통해 점진적으로 목표를 달성하는 데 주의를 집중할 수 있으며 각 변경이 완벽한지 확인하는 데 너무 집착하지 않습니다.
• 어떤 고객이 변경을 경험하는지: 우리는 기능 플래그를 사용하여 프로덕션 변경 사항을 검증하고 점진적으로 고객에게 릴리스합니다.

이 기능이 고객의 손에 들어오기 전까지는 고객의 문제를 해결할 수 있는지 확실하지 않습니다. 소량의 반복 배송에 대한 이러한 약속은 또 다른 인터콤 원칙인 배웁니다.

복잡성 관리

복잡한 시스템 내에서 구축하는 것은 어렵습니다. 큰 변경 사항에서 버그가 발생하거나 부풀려진 기능이 표시를 놓치면 특정 문제를 정확히 찾아내기 어렵습니다. 작은 단계를 통해 더 쉽게 검증, 변경 및 계속 진행할 수 있습니다.

큰 변화에는 다음과 같은 많은 가정이 포함됩니다.

• 변경 사항이 고객의 워크플로에 미치는 영향에 대한 외부 가정.
• 변경 사항의 여러 부분이 상호 작용하고 서로 의존하는 방식에 대한 내부 가정.

외부 가정을 확인하기 위해 최선을 다할 수 있지만 변경 사항을 제공하고 검증하거나 조정하는 것이 더 빠르고 강력한 경우가 많습니다. 내부 가정은 복잡성이 침투할 수 있는 곳입니다. 변경 사항이 모두 서로 의존하는 여러 빌딩 블록을 포함할 만큼 커지면 함께 테스트하는 것이 위험할 수 있습니다. 이를 점진적으로 릴리스하여 다른 하나 위에 빌드하고 진행하면서 영향을 모니터링하는 것이 훨씬 안전합니다.

내구성 있는 속도가 추진력을 만듭니다.

속도는 훌륭하지만 내구성이 있으며 안정적인 속도는 판도를 바꾸고 있습니다. 대규모 변경을 제공한다는 것은 일련의 작고 빠른 반복과 비교하여 성공할 가능성이 훨씬 더 높고 놀라움의 위험이 더 높다는 것을 의미합니다.

" 작은 변화를 전달하고, 학습하고, 반복하는 타이트한 사이클이 강력한 모멘텀을 구축합니다."

작은 변경 사항을 전달하고, 학습하고, 반복하는 빡빡한 주기는 강력한 추진력을 구축합니다. 처음부터 옳을 필요가 없고 더 빠른 의사 결정을 장려하며 실수의 폭발 반경을 줄입니다. 또한 작업을 더 작은 단위로 나누면 엔지니어가 작업을 병렬로 진행할 수 있으므로 팀이 전체적으로 더 빠르게 이동할 수 있습니다.

작은 단계에서 구축하려면 올바른 팀 문화가 필요합니다.

작은 단계에서 구축하는 것은 우연히 발생하는 것이 아니라 의도적인 의도와 올바른 환경이 필요합니다. 우리의 팀 문화와 인프라 스택은 작은 변경 사항을 신속하게 제공하는 데 중요한 역할을 합니다.

팀이 작은 변경 사항을 신속하게 전달하는 것의 중요성에 동의하면 동료 검토의 우선 순위가 지정되고 더 빨리 완료됩니다. 작은 변경 사항은 이해하고 검토하기 쉽기 때문에 각 단계에서 버그가 포착될 가능성이 더 높습니다. 이러한 팀의 이해와 긴급성은 전체 프로세스의 속도를 높입니다.

" 변경 사항을 검토하고 마스터에 병합한 후 자동화된 테스트 및 스테이징 검증을 포함하여 프로덕션에 도달하는 데 15분 미만이 소요되도록 하는 데 상당한 투자를 했습니다."

배포 시간이 느려지면 엔지니어는 일괄 변경을 선호하므로 더 큰 변경 주기가 발생합니다. 변경 사항이 검토되고 마스터로 병합되면 자동화된 테스트 및 스테이징 유효성 검사를 포함하여 프로덕션에 도달하는 데 15분 미만이 소요되도록 하는 데 상당한 투자를 했습니다. 완전히 손을 떼지 않고 변경 사항이 적용되면 엔지니어가 자동으로 Slack 알림을 받습니다.

Intercom의 Salesforce 통합에 "작은 단계로 구축" 원칙 적용

작년에 우리는 Intercom을 Salesforce와 더욱 긴밀하게 통합하여 고객이 Intercom 대화에서 Salesforce 사례를 자동으로 생성할 수 있도록 했습니다. 우리는 복잡성을 빨리 이해했습니다. 대화와 사례가 항상 간단하게 매핑되는 것은 아니며 다대다 관계에서 데이터를 동기화하는 것은 엔지니어링 및 디자인 관점에서 모두 어려울 수 있습니다. 여기에 더하여 고객이 이 기능을 사용하기를 원하는 방식에 큰 차이가 있었고 고객이 크게 의존하는 기존 통합에 맞아야 했습니다.

많은 의미와 설계 절충안을 통해 작업한 후, 우리는 보다 안정적인 영향을 줄 수 있다고 생각되는 것을 선호하여 프로젝트를 보류했습니다. 일련의 작은 단계가 아닌 큰 변화로 접근했기 때문에 거의 구축하지 않았습니다.

우리는 다른 접근 방식으로 프로젝트를 다시 방문했습니다.

영업 팀이 이 기능이 고객에게 얼마나 중요한지 강조하기 위해 돌아오기까지는 그리 오랜 시간이 걸리지 않았습니다. 그리고 우리는 이 기능을 다시 살펴보기로 결정했습니다. 이번에는 가능한 가장 작은 버전부터 시작하여 고객이 진정으로 필요로 하는 것이 무엇인지 알 수 있을 때까지 복잡성을 일부 회피하는 다른 접근 방식을 취했습니다.

" 우리와 함께 작업한 고객들은 피드백에 따라 팀이 반복하는 속도와 기능이 매일 발전하는 방식을 매우 중요하게 여겼습니다."

2주 만에 다른 엔지니어와 저는 고객과 공유할 수 있는 이 기능의 가장 기본적인 버전을 구축했습니다. 고객이 이미 사용하고 있는 기존 워크플로를 중단하지 않도록 여러 작은 단계로 이 작업을 수행했습니다. 이를 통해 기능이 훨씬 더 가시적이었고 고객은 제품 격차 및 개선 사항에 대한 구체적인 피드백을 제공할 수 있었습니다.

고객이 이 기능을 사용하면 팀은 작은 단계를 반복하여 신속하게 기능을 보다 유연하게 만들었습니다. 유연성이 증가함에 따라 이를 사용하는 고객의 수도 증가했으며 베타를 빠르게 확장했습니다.

다대다 관계는 고객이 기능을 사용하는 것을 차단하지 않았으며 우리는 이 기능을 성공적으로 성공적으로 출시했으며 이러한 추가 복잡성 없이 작게 시작하고 빠르게 반복함으로써 발견한 것입니다. 우리와 함께 작업한 고객은 팀이 반복하는 속도와 피드백에 따라 매일 기능이 발전하는 방식을 매우 중요하게 여겼습니다.

작은 단계의 구축은 모두에게 효과적입니다.

고객 가치를 더 안전하고 내구성 있는 방식으로 더 빠르게 제공하는 데 도움이 되기 때문에 우리는 주로 작은 단계로 구축합니다. 하지만 그뿐만 아니라 엔지니어로서 더 좋은 작업 방식입니다. 처음에 옳고 그름이 많은 큰 변경 사항을 배송하는 것보다 스트레스가 훨씬 적습니다. 작업 중인 작업을 프로덕션 환경으로 배송할 때마다 정기적인 도파민 히트가 발생합니다.

따라서 이 블로그 게시물에서 위험 감소를 위해 최적화하고 증분 가치를 제공하도록 설득하는 내용이 없다면 더 재미있기 때문에 그렇게 해야 합니다.

Intercom에서 일하는 방식에 대해 더 알고 싶으십니까? 더 찾아 봐.