모든 엔지니어링 팀은 중요한 제품 정보를 동료들과 소통하기 위해 어떤 종류의 문서 도구에 의존합니다. 작은 팀이 막 시작할 때는 Google 문서처럼 간단할 수 있고, 복잡한 제품을 가지고 있는 큰 팀의 경우에는 계층 위키 형태일 수 있습니다. 회사가 어떻게 구조화되어 있는지에 따라, 다른 팀(예: HR 또는 마케팅)도 이 위키를 사용할 수 있거나, 팀의 정보를 저장할 다른 공간이 있을 수 있습니다.
새로운 엔지니어링 팀에 합류할 때(내부나 외부에서), 온보딩 과정은 새로운 팀원이 기여할 준비가 얼마나 빨리 될지를 결정하는 데 중요합니다. 코딩 환경을 설정하는 것부터 기능 문서를 살펴보는 것까지, 새로운 작업을 맡을 준비가 되기 위해 필요한 것이 많습니다.
많은 엔지니어링 팀의 경우, 온보딩 과정이 다른 팀원에게 수고로움이 되며, 새로운 직원의 ‘친구’로 지정된 사람이 이 정보를 실시간으로 안내해야 합니다. 그러나 전문가가 검증하고 최신화된 Guru 내 카드를 팀에 제공함으로써, RS21의 엔지니어링 리더들은 새로운 직원이 자신의 속도로 온보딩할 수 있는 유연성을 제공합니다. 이것은 그들이 온보딩 ‘친구’와의 시간을 절약하여 더 많은 인간관계 구축이나 남은 질문에 대한 시간을 활용할 수 있게 합니다.
새로운 엔지니어가 RS21 팀에 합류하면, 그들은 Guru에 로그인하여 온보딩 자료 작업을 시작합니다. 그들은 '팀 정보' 보드를 살펴보며, 팀원들에 대해 조금 알 수 있고, 인프라 카드로 환경을 올바르게 설정하고, 팀의 코딩 표준을 읽어보며 새로운 동료들과 가장 잘 협력할 수 있는 방식을 파악합니다.
마찬가지로 Guru에서는 엔지니어가 새로운 팀에 합류하거나 이동할 때, 그들의 온보딩은 Guru에서 진행됩니다. 그들은 인생 이야기 카드를 사용하여 팀원들을 알아가고, 어떻게 함께 일할 것인지에 대한 안내를 보고, 새로운 팀의 컬렉션을 Guru에서 탐색하여 자신이 이제 책임지는 제품 특징과 영역에 익숙해집니다.
모범 사례 및 팀 표준
전체 팀이 온보딩을 마치면, 코딩 표준 및 문서 작성 모범 사례와 같은 지속적인 자원이 Guru에 보관됩니다. 작업 흐름에서 접근 가능하게 문서화될 경우, 이러한 자료들은 엔지니어들이 팀과 회사의 나머지 부분과 생산적으로 협력할 수 있게 합니다. 또한, 그들은 어떤 정책이나 절차를 암기할 필요가 없고, 심지어는 오래된 문서를 북마크 해두고 의존하는 것과 같은 불행한 상황을 방지할 수 있습니다.
RS21의 엔지니어링 컬렉션은 합병 코드, 배시 스크립트 작성, 코드 리뷰 요청 등에 대한 지침이 담긴 카드가 포함된 프로세스 지침 전용 보드를 포함하고 있습니다. 그들은 또한 팀의 동의된 코딩 구문 스타일, AWS 설정 지침, 시스템 관리 정보 등을 위한 보드를 가지고 있습니다. 그들은 심지어 자주 사용하는 코드 조각을 Guru 카드에서 쉽게 복사하고 붙여넣을 수 있습니다.
이러한 엔지니어링 전용 카드 외에도, Guru는 엔지니어가 팀 간 프로세스의 모범 사례 및 지침에 접근할 수 있는 훌륭한 장소입니다. 예를 들어, RS21 팀은 비동기식 논의를 Guru를 사용하여 팀원들에게 더 많은 반응 시간을 할애하고, 모두에게 공정한 플랫폼을 제공합니다. 이 논의를 설정하고 모니터링하는 방법에 대한 지침은 Guru 템플릿에 저장되어 있어, 누군가 필요할 때 쉽게 사용할 수 있습니다.
Guru에서는 제품 개발 조직 외부의 팀에 품질 보증(QA) 과정을 지원하는 작업을 맡깁니다. 보다 다양한 관점을 통해, 우리는 버그를 더 잘 식별하고, 잠재적인 고객 문제에 대해 탐구하며, 출시 전에 이를 예방할 수 있습니다. 그러나 QA처럼 기술적인 과정은 교차 기능 팀을 포함할 때 문서화된 지침과 절차를 필요로 합니다. 새로운 기능에 대한 QA를 시작하기 전에, 엔지니어링 팀 리드는 QA 프로세스 템플릿를 사용하여 팀과 이해관계자들이 엔드투엔드 QA를 위해 필요한 모든 것을 위한 원스톱 샵을 만듭니다. QA를 시작할 준비가 되었을 때, 이들은 이를 팀과 이해관계자에게 발표하고, 메시지에 활성 QA 날짜를 포함합니다.
프로젝트 계획 및 개발 문서
새로운 개발 프로젝트가 시작될 때마다, 모든 사람이 자신의 역할을 위해 필요한 완전한 맥락을 갖도록 하기 위해 많은 문서가 뒤따릅니다. 킥오프 회의 후, 엔지니어들은 제품 팀의 요구 사항 문서, UX 팀의 최신 기능 디자인, 마케팅 또는 카피라이팅 팀에서 제공한 카피 등 다양한 자료에 의존합니다.
물론, 그들은 자신들이 작업하고 있는 기능에 영향을 주는 모든 기술 문서나 나중에 업데이트해야 할 문서를 자주 참조해야 합니다.
Guru에서는 각 프로젝트의 엔지니어링 리드가 주관하는 활성 프로젝트 자원 카드에 제품 개발에 필요한 다양한 자원을 기록합니다. 이 카드들은 엔지니어링 팀이 제품 개발 수명 주기 초기 단계 동안 자주 사용하는 자료가 되며, 모든 변화를 반영하여 최신 상태로 유지됩니다.
개발 프로세스가 진행됨에 따라 엔지니어링과 디자인 간의 협업이 긴밀하게 이루어져야 합니다. 그러나 종종 비동기적이고 원격으로 일하는 특성으로 인해, 디자이너와 엔지니어가 Zoom 통화를 통해 문제나 피드백에 대해 이야기하기가 항상 가능하지는 않습니다. 설계 피드백을 요청하기 위한 우리 내부 프로토콜을 준수하도록 하기 위해, 우리의 엔지니어링 팀은 Guru에 문서화된 UI 변경을 위한 설계 피드백 워크플로우를 사용합니다.
미래 대비 문서
문서는 항상 엔지니어의 작업에 필요하고 앞으로도 필요할 것입니다. 한때 고통스러운 신음과 불만족스러운 한숨을 유도했던 것들이 현재 그들의 일상에 자연스럽게 통합이 될 수 있도록 하는 것이 이들의 일상으로 들어오면 가능합니다. Guru의 브라우저 확장 기능은 엔지니어가 필요로 하는 곳에 문서를 가져오고, 이를 가기 위해 맥락 전환을 하는 것을 강요하는 대신, 전문적으로 검증된 카드가 긴 글들을 작성하는 부담을 덜어줍니다. 그렇다면 이제 구식 문서로 기술적 부채를 쌓을 이유가 있을까요? 지금 당장 쉽게 미래를 대비할 수 있습니다. 지금 무료로 시작하세요.
모든 엔지니어링 팀은 중요한 제품 정보를 동료들과 소통하기 위해 어떤 종류의 문서 도구에 의존합니다. 작은 팀이 막 시작할 때는 Google 문서처럼 간단할 수 있고, 복잡한 제품을 가지고 있는 큰 팀의 경우에는 계층 위키 형태일 수 있습니다. 회사가 어떻게 구조화되어 있는지에 따라, 다른 팀(예: HR 또는 마케팅)도 이 위키를 사용할 수 있거나, 팀의 정보를 저장할 다른 공간이 있을 수 있습니다.
새로운 엔지니어링 팀에 합류할 때(내부나 외부에서), 온보딩 과정은 새로운 팀원이 기여할 준비가 얼마나 빨리 될지를 결정하는 데 중요합니다. 코딩 환경을 설정하는 것부터 기능 문서를 살펴보는 것까지, 새로운 작업을 맡을 준비가 되기 위해 필요한 것이 많습니다.
많은 엔지니어링 팀의 경우, 온보딩 과정이 다른 팀원에게 수고로움이 되며, 새로운 직원의 ‘친구’로 지정된 사람이 이 정보를 실시간으로 안내해야 합니다. 그러나 전문가가 검증하고 최신화된 Guru 내 카드를 팀에 제공함으로써, RS21의 엔지니어링 리더들은 새로운 직원이 자신의 속도로 온보딩할 수 있는 유연성을 제공합니다. 이것은 그들이 온보딩 ‘친구’와의 시간을 절약하여 더 많은 인간관계 구축이나 남은 질문에 대한 시간을 활용할 수 있게 합니다.
새로운 엔지니어가 RS21 팀에 합류하면, 그들은 Guru에 로그인하여 온보딩 자료 작업을 시작합니다. 그들은 '팀 정보' 보드를 살펴보며, 팀원들에 대해 조금 알 수 있고, 인프라 카드로 환경을 올바르게 설정하고, 팀의 코딩 표준을 읽어보며 새로운 동료들과 가장 잘 협력할 수 있는 방식을 파악합니다.
마찬가지로 Guru에서는 엔지니어가 새로운 팀에 합류하거나 이동할 때, 그들의 온보딩은 Guru에서 진행됩니다. 그들은 인생 이야기 카드를 사용하여 팀원들을 알아가고, 어떻게 함께 일할 것인지에 대한 안내를 보고, 새로운 팀의 컬렉션을 Guru에서 탐색하여 자신이 이제 책임지는 제품 특징과 영역에 익숙해집니다.
모범 사례 및 팀 표준
전체 팀이 온보딩을 마치면, 코딩 표준 및 문서 작성 모범 사례와 같은 지속적인 자원이 Guru에 보관됩니다. 작업 흐름에서 접근 가능하게 문서화될 경우, 이러한 자료들은 엔지니어들이 팀과 회사의 나머지 부분과 생산적으로 협력할 수 있게 합니다. 또한, 그들은 어떤 정책이나 절차를 암기할 필요가 없고, 심지어는 오래된 문서를 북마크 해두고 의존하는 것과 같은 불행한 상황을 방지할 수 있습니다.
RS21의 엔지니어링 컬렉션은 합병 코드, 배시 스크립트 작성, 코드 리뷰 요청 등에 대한 지침이 담긴 카드가 포함된 프로세스 지침 전용 보드를 포함하고 있습니다. 그들은 또한 팀의 동의된 코딩 구문 스타일, AWS 설정 지침, 시스템 관리 정보 등을 위한 보드를 가지고 있습니다. 그들은 심지어 자주 사용하는 코드 조각을 Guru 카드에서 쉽게 복사하고 붙여넣을 수 있습니다.
이러한 엔지니어링 전용 카드 외에도, Guru는 엔지니어가 팀 간 프로세스의 모범 사례 및 지침에 접근할 수 있는 훌륭한 장소입니다. 예를 들어, RS21 팀은 비동기식 논의를 Guru를 사용하여 팀원들에게 더 많은 반응 시간을 할애하고, 모두에게 공정한 플랫폼을 제공합니다. 이 논의를 설정하고 모니터링하는 방법에 대한 지침은 Guru 템플릿에 저장되어 있어, 누군가 필요할 때 쉽게 사용할 수 있습니다.
Guru에서는 제품 개발 조직 외부의 팀에 품질 보증(QA) 과정을 지원하는 작업을 맡깁니다. 보다 다양한 관점을 통해, 우리는 버그를 더 잘 식별하고, 잠재적인 고객 문제에 대해 탐구하며, 출시 전에 이를 예방할 수 있습니다. 그러나 QA처럼 기술적인 과정은 교차 기능 팀을 포함할 때 문서화된 지침과 절차를 필요로 합니다. 새로운 기능에 대한 QA를 시작하기 전에, 엔지니어링 팀 리드는 QA 프로세스 템플릿를 사용하여 팀과 이해관계자들이 엔드투엔드 QA를 위해 필요한 모든 것을 위한 원스톱 샵을 만듭니다. QA를 시작할 준비가 되었을 때, 이들은 이를 팀과 이해관계자에게 발표하고, 메시지에 활성 QA 날짜를 포함합니다.
프로젝트 계획 및 개발 문서
새로운 개발 프로젝트가 시작될 때마다, 모든 사람이 자신의 역할을 위해 필요한 완전한 맥락을 갖도록 하기 위해 많은 문서가 뒤따릅니다. 킥오프 회의 후, 엔지니어들은 제품 팀의 요구 사항 문서, UX 팀의 최신 기능 디자인, 마케팅 또는 카피라이팅 팀에서 제공한 카피 등 다양한 자료에 의존합니다.
물론, 그들은 자신들이 작업하고 있는 기능에 영향을 주는 모든 기술 문서나 나중에 업데이트해야 할 문서를 자주 참조해야 합니다.
Guru에서는 각 프로젝트의 엔지니어링 리드가 주관하는 활성 프로젝트 자원 카드에 제품 개발에 필요한 다양한 자원을 기록합니다. 이 카드들은 엔지니어링 팀이 제품 개발 수명 주기 초기 단계 동안 자주 사용하는 자료가 되며, 모든 변화를 반영하여 최신 상태로 유지됩니다.
개발 프로세스가 진행됨에 따라 엔지니어링과 디자인 간의 협업이 긴밀하게 이루어져야 합니다. 그러나 종종 비동기적이고 원격으로 일하는 특성으로 인해, 디자이너와 엔지니어가 Zoom 통화를 통해 문제나 피드백에 대해 이야기하기가 항상 가능하지는 않습니다. 설계 피드백을 요청하기 위한 우리 내부 프로토콜을 준수하도록 하기 위해, 우리의 엔지니어링 팀은 Guru에 문서화된 UI 변경을 위한 설계 피드백 워크플로우를 사용합니다.
미래 대비 문서
문서는 항상 엔지니어의 작업에 필요하고 앞으로도 필요할 것입니다. 한때 고통스러운 신음과 불만족스러운 한숨을 유도했던 것들이 현재 그들의 일상에 자연스럽게 통합이 될 수 있도록 하는 것이 이들의 일상으로 들어오면 가능합니다. Guru의 브라우저 확장 기능은 엔지니어가 필요로 하는 곳에 문서를 가져오고, 이를 가기 위해 맥락 전환을 하는 것을 강요하는 대신, 전문적으로 검증된 카드가 긴 글들을 작성하는 부담을 덜어줍니다. 그렇다면 이제 구식 문서로 기술적 부채를 쌓을 이유가 있을까요? 지금 당장 쉽게 미래를 대비할 수 있습니다. 지금 무료로 시작하세요.
Experience the power of the Guru platform firsthand – take our interactive product tour
.webp)
