Team Ramp Up은 향상된 기능 속도를 보장합니까?
게시 됨: 2020-03-28릴리스 속도를 높이기 위해 팀을 강화하는 동안 핵심 요소 중 하나는 명확성을 제품 팀에서 스프린트 팀으로 이전하는 것입니다.
원활한 스프린트 실행은 제품 및 스프린트 팀 모두의 주목할만한 기여의 결과입니다.
'최초의 권리(FTR)'의 철학은 모든 팀원이 공통의 목표에 일치하도록 돕습니다.
스타트업이 초기 단계에서 성장 단계로 이동할 때 우선순위가 크게 바뀝니다. 다른 무엇보다도 기능 속도는 우선 순위로 두드러지며 성장을 추구하는 데 중요한 역할을 합니다.
최근에 시리즈 A 라운드를 진행한 시드 펀딩 스타트업의 설립자는 6개월 안에 새로운 기능을 출시하기 위해 엔지니어링 팀을 두 배로 늘려달라고 요청했습니다. 그러나 이것이 사이클 시간을 줄이는 유일한 관련 요소입니까? 이에 답하기 위해 저는 이 만연한 '오해' 뒤에 숨어 있는 무시된 측면을 다루기로 결정했습니다.
리소스 용량은 빈번한 생산 릴리스를 이끄는 중요한 요소 중 하나이지만 이것만으로는 주기 시간 단축을 보장할 수 없습니다. 16개 이상의 스타트업을 위한 제품을 구축하면서 초기 단계에서 성장 단계로의 전환을 여러 번 목격했습니다. 이 경험에서 내가 공유하는 몇 가지 중요한 요소는 스타트업 창업자가 고려해야 할 사항입니다.
명확한 전달: 하향식 필수
릴리스 속도를 높이기 위해 팀을 늘리는 동안 핵심 요소 중 하나는 명확성을 제품 팀에서 스프린트 팀으로 이전하는 것입니다. 스프린트가 모호하게 시작하거나 시작할 스토리가 충분하지 않으면 스프린트 전달 비율이 부정적인 영향을 받습니다. 모호하게 정의된 스토리나 작업의 중간 스프린트 포함은 속도를 늦추고 결과적으로 스프린트 팀이 계획한 대로 제공하지 못합니다.
원활한 스프린트 실행은 제품 및 스프린트 팀 모두의 주목할만한 기여의 결과입니다. 제품 팀은 팀이 그에 따라 결과물을 계획할 수 있도록 최소한 분기 동안 로드맵을 준비하고 스프린트 팀에 공유하여 역할을 수행할 수 있습니다.
반면, 스프린트 팀은 제품 팀이 제품 백로그를 가져오도록 지속적으로 압박하고 집중적인 배송을 보장하기 위해 매주/격주 단위로 정리해야 합니다.
'버그 프리' 출시 자동화
“효율성은 일을 올바르게 하는 것입니다. 효율성은 올바른 일을 하는 것입니다." – 피터 드러커
자동화라고 하면 후자 범주의 예입니다. 기능 개발이 속도를 내는 순간, 올바른 프로세스가 마련되어 있지 않으면 생산이 중단될 가능성이 높습니다. 제품이 새로운 기능 개발을 처리할 만큼 충분히 안정적이지 않은 경우 팀은 새 기능을 구축하는 것보다 문제를 해결하는 데 더 많은 시간을 할애합니다. 결과적으로 엔지니어링 속도가 떨어집니다.
여기서 CI/CD(지속적 통합 및 지속적 배포)가 필요합니다. 여기에서 철저한 장치, 통합 및 자동화 테스트 범위는 배송되는 모든 것이 시스템을 손상시키지 않도록 합니다.
당신을 위해 추천 된:
인도에서 핀테크를 혁신하기 위해 RBI의 Account Aggregator Framework를 설정하는 방법
기업가는 'Jugaad'를 통해 지속 가능하고 확장 가능한 스타트업을 만들 수 없습니다: Cit...
메타버스가 인도 자동차 산업을 어떻게 변화시킬 것인가?
인도 스타트업에 대한 반 영리 조항은 무엇을 의미합니까?
Edtech Startup이 인도 인력의 기술 향상 및 미래 준비를 돕는 방법...
이번 주 새로운 시대의 기술 주식: Zomato의 문제는 계속되고 EaseMyTrip은 Str...
더 많은 것을 구축하지 마십시오. 그렇지 않으면 더 많은 것을 깰 수 있습니다.
재작업은 생산성을 크게 떨어뜨리는 요인이며 모호하게 정의된 스토리, 개발 테스트 부족, 테스트 커버리지 부족 등과 같은 다양한 요인의 결과일 수 있습니다. 재작업은 테스트와 퇴행에 QA 엔지니어, 디버깅에 개발자, 재출시에 릴리스 관리자의 시간과 노력을 소모하기 때문에 생산성을 저하시킬 수 있습니다.
속도를 약간 늦추면 팀이 더 빠르게 제공하고 가치를 추가하는 데 도움이 될 수 있습니다. 효과적인 속도는 항상 속도보다 훨씬 더 큰 보상을 제공하기 때문입니다.
'최초의 권리(FTR)' 철학은 모든 팀 구성원이 처음에 강력하고 안정적인 코드를 제공한다는 공통 목표에 맞출 수 있도록 도와줍니다. 서두르고 재작업에 매달리기보다는 코드의 품질을 결정하기 위해 약간의 추가 시간을 보내는 것이 항상 건강합니다.
FTR 비율을 개선하기 위한 검증된 방법 중 일부는 정기적인 백로그 정리, 반복되는 이야기, 제품 관리자에 대한 정기적인 데모입니다. 스프린트 팀은 요구 사항을 수집하는 대신 FTR 비율을 개선하기 위해 요구 사항을 설명하는 데 더 집중해야 합니다.
병렬 스프린트를 위한 팀 구성
스타트업에 소규모 제품 팀이 있는 경우 모든 사람이 대부분 동시에 하나 또는 두 가지 기능에 대해 작업합니다(일반적으로 4-6명으로 구성된 팀에 적용 가능). 그러나 여러 기능을 제공할 것이라는 기대가 높아지므로 초점 영역이 뚜렷한 여러 하위 팀을 구성하는 것이 좋습니다. 이러한 방식으로 모든 하위 팀은 스프린트를 실행하고 로드맵을 정의하게 됩니다.
하나의 큰 팀과 비교할 때 '논리적 분리' 프레임워크에서 탄생한 소규모 팀이 더 효과적이며 더 나은 결과를 산출합니다. 마이크로 서비스, 다양한 제품 라인 및 다양한 구성 요소를 위한 개별 팀은 '논리적 분리' 접근 방식의 몇 가지 예입니다.
구조 조정 중에 DNA를 유지하기 위해 이러한 각 하위 팀에 이전 핵심 팀의 구성원을 최소 한 명 이상 포함시키는 것이 항상 중요합니다. 배송을 위한 팀 간 조정에는 추가 오버헤드가 수반되지만 이는 정당한 절충안입니다.
속도와 함께 기능 사용 추적
사용자 경험은 새로운 기능 릴리스의 성공을 측정하는 가장 중요한 지표입니다. 여러 기능을 빠르게 제공하기 시작하면 사용자 경험이 뒷전으로 밀려나는 경우가 많습니다. 제품에 제한된 기능이 있는 경우 사용자 상호 작용은 끊김 없는 부드러운 곡선을 계속 유지합니다.
그러나 새로운 기능을 출시하기 시작하면 사용자가 압도되고 경험이 영향을 받을 가능성이 높습니다.
더 나은 사용자 채택을 달성하기 위해 기능 속도와 함께 사용자 참여를 추적하는 것이 가장 좋은 방법입니다. 철저한 사용자 조사가 입증된 방법 중 하나이지만, 다른 중요한 방법은 모든 새 릴리스 이후에 기능 플래그, AB 테스트 및 사용자 여정 추적(진폭 또는 유사한 분석 도구를 통해)을 통해 선택된 사용자에게 초기에 롤아웃됩니다.
핵심 구성원을 잃지 마십시오
이것은 매우 일반적으로 무시되는 측면일 수 있지만 매우 중요한 측면으로 확고합니다. 소규모 팀은 반드시 프로세스가 필요한 것은 아니며 민첩한 구조를 가지고 있으며 모든 사람의 목소리가 들립니다. 이러한 팀이 프로세스가 설정되고 새로운 엔지니어링 및 기능 구성원이 추가되는 상태로 이동할 때 혼란을 피할 수 있는 유일한 방법은 건전한 관리입니다.
엔지니어링 팀이 성공적으로 확장됨에 따라 유능한 제품 팀은 엔지니어링 팀을 지속적으로 공급하는 데 필수적입니다. 팀 구성원에게 중요한 업무가 없을 때 이탈이 불가피하지만 어떤 스타트업도 핵심 구성원을 잃고 싶어하지 않을 것입니다. 이 경우 고위 경영진이 사람들과 좋은 관계를 유지하고 역학을 잘 이해하는 열쇠를 쥐고 있습니다.
제가 여기에서 공유한 교훈은 수년 동안 여러 신생 기업과의 경험에서 나온 것입니다. 나는 그것이 바퀴를 재발명하지 않는 방식으로 이미 많은 것을 가지고 있는 스타트업 창업자들에게 유용할 것으로 기대합니다.