기술 및 제품 파트너
스프린트가 아니라 수년간 자체 팀 옆에 엔지니어링 팀이 필요한 소프트웨어 벤더와 제품 기업을 위한 모델입니다. 당사가 처음부터 끝까지 책임지는 모듈, 운영을 함께하는 플랫폼, 또는 귀사가 인력을 배치할 수 없는 로드맵을 맡는 두 번째 팀이며, 같은 인력이 도메인을 익힐 만큼 오래 머뭅니다.
프로젝트 구매와의 차이
프로젝트에는 끝이 있고, 인력 배치 방식도 모두 거기서 비롯됩니다. 인력이 배정되고, 끝낼 수 있을 만큼만 도메인을 익히고, 지식은 그들과 함께 떠납니다. 제품에는 끝이 없습니다. 외부 팀에 필요한 것은 연속성, 향후 2년을 견딜 아키텍처에 대한 관심, 지름길이 지금 아끼는 것보다 나중에 더 큰 비용을 치르게 할 때 반론을 제기하는 인력입니다.
이 페이지가 설명하는 관계가 바로 이것입니다. 계약 형태는 보통 전담 팀과 비슷하지만, 파트너십이 되는 이유는 당사가 티켓 목록이 아니라 귀사 제품의 성과에 책임을 지기 때문입니다.
당사가 주로 책임지는 영역
처음부터 끝까지 책임지는 모듈
제품의 경계가 분명한 한 부분입니다. 연동 계층, 보고 영역, 관리자 화면, 모바일 클라이언트가 해당합니다. 귀사의 코드베이스에서 귀사의 아키텍처에 맞춰 책임지며, 티켓 수가 아니라 결함에 대해 책임집니다.
로드맵을 맡는 두 번째 팀
만들어야 한다는 것을 알면서도 인력을 배치할 수 없는 모든 것을 맡습니다. 귀사의 저장소와 업무 방식 안에서 일하는 병렬 팀이 있어, 로드맵이 한 갈래로 우선순위가 줄어드는 대신 두 갈래로 진행됩니다.
기반이 되는 플랫폼
Terraform으로 정의한 클라우드 인프라, 파이프라인, 환경, 관측성, 데이터베이스와 보안 작업입니다. 제품 팀이 시간을 낼 수 없지만 없을 때마다 매주 그 빈자리를 느끼는 영역입니다.
오래된 제품의 현대화
판매는 되지만 더 이상 변경하기 어려워진 제품입니다. 지금까지 9건을 인수했으며 가장 오래된 것은 2008년에 작성되었고, 재작성 제안이 아니라 항상 읽기 전용 검토와 서면 위험 목록으로 시작합니다.
장기 파트너십이 성공하는 요건
계속 함께하는 인력
이곳의 협업은 스프린트가 아니라 수년간 이어지며, 도메인 지식은 같은 인력에게 남습니다. 파트너에게 최악의 결과는 같은 학습 곡선에 두 번 비용을 치르는 것입니다.
당사가 아닌 귀사의 아키텍처
당사는 제품이 이미 사용하는 기술을 당사가 아는 기술로 유도하지 않고 그대로 이어받는 데 익숙합니다. 재작성을 계속 제안하는 파트너 팀은 더 이상 도움이 되지 않는 파트너 팀입니다.
인수인계 후에도 유지되는 규칙
테스트는 기능과 함께 배포하고, 빌드는 경고 0건으로 끝나며, 보안은 기본 거부 방식이고, 인프라는 코드입니다. 이렇게 작성한 코드는 귀사 엔지니어가 그대로 이어받을 수 있는 코드입니다.
사실마다 하나의 소유자
파생 값은 한 번만 계산하고 모든 곳에서 사용합니다. 여러 팀이 참여하는 제품에서 중복된 정보는 6개월 뒤에 발견되어 고객에게 설명할 수 없는 버그가 됩니다.
별도 청구 없는 당사의 대체 인력
아키텍처 검토, 풀 리퀘스트에 대한 추가 검토, 휴가 중 업무 대체는 귀사의 예산이 아니라 BigTree108에서 제공합니다.
처음부터 끝까지 귀사의 지식재산권
모든 전문가는 접근 권한을 받기 전에 작업 결과물을 회사에 귀속시키고 이것이 다시 귀사에 귀속되므로, 장기 파트너십이 제품의 소유권을 복잡하게 만들지 않습니다.
당사도 자체 제품을 운영합니다
채용과 온보딩부터 근무 시간 관리, 계약, 청구까지 당사가 내부적으로 사용하는 모든 것은 파트너에게 제공하는 것과 같은 기술 스택의 하나의 플랫폼입니다. Azure Functions 위의 .NET, Angular, Azure SQL, Terraform입니다. 이는 포트폴리오용 작품이 아니라 회사가 의존하는 시스템이며, 자체 아키텍처 결정을 충분히 오래 운영해 보았기 때문에 그중 어떤 것이 잘못이었는지 압니다.
제품 파트너가 실제로 구매하는 것은 바로 이 판단력입니다. 사례 연구에서 시스템의 기능과 구축 방식을 설명합니다.
시작 방식
작고 되돌릴 수 있는 것으로 시작합니다. 백로그의 한정된 부분을 맡는 엔지니어 한 명, 또는 제품에서 가장 불안한 부분에 대한 읽기 전용 검토를 운영 영향 순서의 서면 위험 목록으로 전달합니다. 둘 다 당사가 귀사의 코드베이스를 파트너가 읽어 주기를 바라는 방식으로 읽는지 확인하는 저렴한 방법입니다.
그 이후의 일반적인 형태는 로드맵과 함께 커지는 전담 팀입니다. 결국 팀을 완전히 소유하고 싶으시다면 Build-Operate-Transfer가 같은 인력에 이전 조건을 계약서에 명시한 방식입니다.
제품에 두 번째 팀이 필요하십니까?
제품 정보, 계속 지연되는 로드맵 부분, 가능하다면 저장소 링크를 보내 주십시오. 영업일 기준 1일 이내에 당사의 추가 질문, 접근 방식, 견적을 받으실 수 있습니다.