엔지니어링 전략 수립

13장. 반복적 개선을 위한 전략 테스트

이 작품은 AI를 사용하여 번역되었습니다. 여러분의 피드백과 의견을 환영합니다: [e-mail]

기술 전략에 대한 한 가지 아이디어만 대중화할 수 있다면, 그것은 바로 전략을 너무 일찍 출시하면 전략이 효과적인지 평가할 수 없다는 것입니다. 압박은 사람들의 행동을 심오한 방식으로 변화시키며, 사람들은 종종 현상 유지에 대한 변화를 최소화하거나(경영진인 경우) 전략을 폐지(경영진이 아닌 경우)하면서 전략을 준수하고 있다는 인상을 주기 위해 이러한 변화를 시도합니다. 어느 쪽도 특별히 도움이 되지 않습니다.

처음부터 잘못된 전략도 분명히 있지만, 합리적인 전략이 사소한 세부 사항을 제대로 파악하지 못해 실패하는 경우가 훨씬 더 흔합니다. 조급증은 보다 일반적인 현상의 일반적인 증상 중 하나로, 대부분의 전략은 폭포수 모델로 개발되어 현실에서 전략을 시도할 때 현실이 가르쳐주는 교훈을 통합하기 전에 접근 방식을 확정합니다.

폭포수 전략의 함정을 피하는 효과적인 방법 중 하나는 전략을 명시적으로 테스트하여 세부 사항을 구체화하는 것입니다. 이 장에서는 전략 테스트의 메커니즘에 대해 설명합니다:

• 전략을 테스트하는 것이 중요한 경우(그리고 그렇지 않은 경우)

• 전략을 테스트하는 방법

• 테스트를 중단해야 할 때

• 전략 테스트의 역할

• 전략 테스트를 위한 메트릭 및 회의

• 테스트되지 않은 전략을 식별하는 방법

• 전략이 테스트 없이 너무 많이 진행되었을 때 해야 할 일

이 장에 나오는 많은 아이디어는 제가 카르타 엔지니어링에서 Shawna Martell, Dan Fike, Madhuri Sarma 및 다른 많은 사람들과 함께 일하면서 얻은 것입니다.

전략을 테스트해야 하는 시기

전략 테스트는 전략이 기꺼이 지불할 수 있는 비용으로 의도한 목표를 달성할 수 있는지 확인하는 것입니다. 즉, 전략이 구현되기 전, 즉 일반적으로 초기 개발 단계에서 수행해야 합니다.

다음은 일반적인 전략 주제를 언제 테스트해야 하는지에 대한 몇 가지 예입니다:

• 최근에 인수한 기업을 통합하는 경우에는 전체 접근 방식을 마무리하기 전에 단일 API 통합을 작동시키는 데 중점을 두고 테스트할 수 있습니다.

• Python 코드베이스를 입력해야 하는 개발자 생산성 전략의 경우 숙련된 팀원에게 중요한 모듈을 입력하게 하는 것으로 시작할 수 있습니다.

• 서비스 마이그레이션의 경우, 더 광범위한 롤아웃으로 이동하기 전에 하나의 간단한 구성 요소(마이그레이션 툴링 테스트)와 매우 복잡한 구성 요소(통합 복잡성 테스트)를 마이그레이션하려고 시도할 수 있습니다.

모든 경우에서 가장 중요한 두 가지 요소는 전략을 확정하기 전에 테스트하는 것과 접근 방식의 기본 메커니즘에 중점을 두고 좁게 테스트하는 것입니다. 채택 동기 부여나 상충되는 인센티브 해결과 같은 광범위한 문제 해결에 얽매이지 마세요.

모든 전략을 테스트해야 한다는 말은 아닙니다. 전략을 테스트하지 않아도 되는 몇 가지 일반적인 ...