어릴 때부터 우리는 잠재력을 최대한 발휘하고 달성하려는 목표에서 성공적인 결과를 거두기 위해, “크게 생각하라”여 높은 기준을 세우라고 배웠습니다. 회사도 크게 생각하며 큰일을 좇고 “야심 찬 계획”을 세웁니다.
하지만 크게 생각하고 “크고 대담한 목표”를 해결하는 것의 위험은 팀이 너무 많이 일하고 가능한 것보다 더 많이 처리하려고 한다는 것입니다. 규범적인 이런 대규모 노력은 느리게 진전을 이루기 때문에 고객이나 사용자에게 점진적인 가치를 거의 또는 전혀 제공하지 않습니다. 아니면 아예 반대로, 너무 작게 일해서 장기적인 비전을 이해하지 못한 채로 너무 많은 작업을 처리하기도 합니다.
Atlassian과의 대화에서, Amplitude의 제품 연구 및 교육 책임자인 John Cutler는 팀과 회사가 성공하려면 크게 생각하고 작게 일하는 것 사이의 적절한 균형을 찾아야 하는 경우가 많다고 말했습니다.
너무 크게 일하고 있습니까?
“너무 크게 일하는 것”은 기본적으로 팀이 점진적인 가치 제공, 실험이 없고 통합이 드물게 이루어지는 대규모 프로젝트를 수행한다는 의미입니다. 팀이 대규모 프로젝트를 수행하면 작업을 진행하려는 노력이 매우 느려집니다.
팀이 너무 크게 일하고 있다는 징후로는 고객에 대해 충분히 알지 못하는 것과 지식을 현재 시장 또는 최신 기술과 통합하지 않는 것이 포함됩니다. 통합이 부족하면 회사는 제품이 제공될 때 시장에서 뒤처집니다. 사용 가능한 시간을 채우기 위해 범위가 확장되고 팀이 과잉 보상을 계획하는 데 어려움을 겪으면서 로드맵 작업이 커집니다.
그런데 회사나 팀이 너무 크게 일하는 이유는 무엇입니까? 고위 경영진을 만족시키고 재정 자원을 확보하려는 팀과 같은 여러 인센티브가 있습니다. 정의된 목표를 가진 대규모 프로젝트 계획은 실질적인 결과를 낼 수 있는 것처럼 보이기 때문에 경영진에게 매력적으로 다가갑니다.
너무 작게 일하고 있습니까?
스펙트럼의 반대편에서는 팀이 “너무 작게 일”합니다. 즉, 팀은 대규모 프로젝트의 더 작은 부분을 맡아 일하지만 작업이 더 큰 전략 및 사명과 어떻게 연결되는지 파악하지 못합니다. 이 접근 방식은 팀이 애자일을 채택하는 것처럼 보일 수 있지만 과도한 계획이 발생하면 반대 패턴이 나타나기 시작합니다. 예를 들어 백로그에 수백 개의 스토리가 있는 회사는 스토리를 분석하는 데 시간이 너무 많이 들 수 있습니다. 또한 팀은 작업에서 추진력을 느낄 수 있지만 6~12개월 후에 검토하면 작업이 비즈니스를 어떻게 진전시키는지 파악하기 어려워합니다. 그 대신 단절되고 사후 대응적인 작업을 보게 됩니다.
Cutler가 또다른 문제라고 생각하는 것은 큰 작업을 작은 조각으로 정의하는 팀입니다. 소규모 팀으로 일하는 경우 피드백에 응답하기가 어려울 수 있습니다. 레고 세트와 마찬가지로, 작은 조각을 조립하는 계획을 따라야 합니다. 하지만 작업의 20%가 가치의 80%를 차지한다면 어떻습니까?
크게 생각하고 작게 일하기
그렇다면 너무 크거나 너무 작게 일하는 것을 어떻게 피할 수 있습니까? Cutler는 “크게 생각하고 작게 일해서” 적절한 균형을 이룰 수 있다고 말했습니다. 즉, “일관성 있는 전략과 연결된 설득력 있는 사명”을 가져야 합니다. 팀은 회사의 비전을 이해한 다음 비전을 지원하고 이행하는 작업을 만들고 관리합니다. 그러기 위해서는 영향과 결과 측면에서 전략적으로 생각하고, 향후 6개월 또는 한 분기 너머까지 전략을 수립하는 동시에 실험 및 검증을 위한 충분한 공간을 제공해야 합니다.
크게만 일하는 경우, Cutler는 큰 목표에 적합한 컨텍스트를 가지고 작게 일할 것을 제안합니다. 작게만 일하는 경우, 전략적 이니셔티브를 정의한 다음 일을 하향식으로 조정하면 도움이 됩니다. 작게 일하고 큰 것을 규범적으로 정의하는 경우 규범을 완화하고 사명과 전략에 집중하세요.
Cutler는 팀이 작업 노력의 “이유”로 시작하는 학습 백로그를 만들 수 있다고 말했습니다. 배우는 “방법”보다는 새로운 정보를 배우는 것이 중요합니다. “이유”로 시작하면 각 작업에 컨텍스트를 가져오게 됩니다. 팀은 정기적인 백로그 그루밍을 통해 작업 백로그를 검토해야 합니다. 이렇게 하면 우선 순위가 올바르고 피드백이 통합되도록 할 수 있습니다. 또한 팀이 작업의 어려움에 대응적인 태도를 취하지 않도록 할 수 있습니다.
학습 백로그부터 시작하면 팀은 광범위한 연구 또는 개발 시간을 통해 학습해야 할 사항의 우선 순위를 지정하게 됩니다. 또한 작업 분류는 회사의 다양한 형태 또는 작업 유형을 더 효과적으로 설명할 수 있어 회사 전체에서 공유 언어를 구축할 수 있습니다.
결론...
