접수 양식이 취소됨: 최소 실행 가능한 프로세스 구축

최소 실행 가능 제품(Minimum Viable Product)이라는 작은 개념에 익숙할 것입니다.

제품을 테스트하기 위해 초기 버전을 대상 사용자에게 노출하고, 관련 데이터를 수집하고, 반복하기 위해 해당 데이터에서 학습한다는 아이디어입니다.

상식적으로 들리겠지만 Windows 98을 다시 생각해 보십시오. Windows 98은 설치하고 다음 업데이트를 위해 1년 이상 기다려야 했던 기존의 박스형 소프트웨어입니다. 소프트웨어의 다음 물리적 사본이 귀하의 손에 들어올 때까지 어떠한 개선도 경험하지 못했습니다.

그때는 전부 아니면 전무였습니다. 그러나 디지털 생활은 개발에 보다 민첩한 접근 방식을 채택하도록 우리를 움직였습니다.

최소 실행 가능한 제품이라는 아이디어를 조직의 비즈니스 프로세스에 적용할 수 있다면 어떨까요?

프로세스가 부풀려지고 과도하게 사용되며 환영을 받지 못할 수 있습니다. 따라서 최소한의 실행 가능한 프로세스 , 즉 눈앞의 문제를 지원하기 위해 가능한 가장 작은 솔루션을 찾는 철학을 심어 보는 것이 어떻겠습니까? 하나의 긴 계획을 세우고 깨지게 될 고정된 프로세스에 충실하기보다는 초기 버전의 연습을 통해 적응하시겠습니까?

누가 과잉 처리의 관료주의를 가장 두려워합니까? 고성장 조직. 특히 애자일 방법론이 대중적이지만 항상 헌신적인 방식으로 구현되는 것은 아닌 기술 분야에서. MVP 사고 방식이 도움이 될 수 있습니다.

새싹은 성장통에 낯설지 않습니다. 프로그램 관리 이사로서 저는 회사 규모가 두 배로 증가한 후 마케팅과 크리에이티브라는 두 부서 간의 협업을 내부적으로 재구성해야 하는 과제에 직면했습니다.

분대 생성 및 정렬, 커뮤니케이션 강조, 자가 치유 워크플로 개발, 매주 프로세스 개선 등 몇 가지 주요 측면이 우리를 현재 위치로 이끈 것입니다.

보다 민주화된 모델

최소 실행 가능 제품의 기존 응용 프로그램에서는 더 많이 생산하기 위해 반복하고 있습니다. 그러나 프로젝트 관리 기술로서 덜 무겁고 덜 혼란스럽고 더 적은 레이어를 생성하기 위해 반복하고 있습니다.

프로세스는 더 작아지지만 조직 전체에서 수행되는 작업에 관련된 사람들에게 더 많은 소유권을 부여하는 것과 같이 다른 위치에 있는 팀에 권한을 되돌려주고 있습니다.

최종적으로는 가장 작고 빠르면서도 가장 기능적인 협업 프로세스 버전이 만들어집니다. 작동할 때까지 계속해서 쉽게 테스트할 수 있는 것.

MV Process는 Wikipedia 페이지와 같다고 생각할 수 있습니다. 답은 거기에 있지만 시간이 지나면서 답은 진화할 것입니다.

자가 치유 팀

이 철학은 린 스타트업 운동에서 태어났습니다. 기업은 위험을 줄이고 조직이 과도한 지출과 과잉 건설을 방지하기 위해 제품과 프로세스를 반복적으로 그리고 작은 단계로 개발해야 한다는 전제에 의해 강조됩니다. 이것은 빠르게 성장하는 회사를 구축하기 위한 린 방법을 개발하기 위해 스타트업 세계에서 자신의 경험을 사용했던 Eric Ries에 의해 처음 제안되었습니다.

자체 구조 조정을 시작하기 위해 우리는 스쿼드 정렬부터 시작했습니다. 닫힌 문 뒤에서 작업하고 유토피아적인 워크플로를 완성하는 대신 새로 구성된 팀을 모아야 했습니다. 우리는 팀이 매일 문제를 제기하고 해결할 수 있는 포럼을 제공하는 빠른 직접 대면 방식의 일일 스탠드업을 설정했습니다.

일이 망가졌다는 것을 인정하는 것은 괜찮았다. 마케팅 팀과 크리에이티브 팀이 협업한 스프린트를 보면 새로운 프로젝트에 접근하는 것과 같았습니다. 새로운 역할, 새로운 팀, 새로운 이니셔티브, 그리고 여전히 동일한 오래된 프로세스가 있었습니다. 우리는 그것이 더 이상 의미가 없다는 것을 인정해야 했습니다. 만약 변화가 지속적이라면 논리적으로 왜 고정된 프로세스에서 작동할까요?

모든 새로운 프로세스와 마찬가지로 사람들은 질문을 했습니다. 스프린트를 수정하는 전술에 집중하는 대신 더 큰 문제는 사람들에게 이해를 주어 앞으로 나아갈 수 있도록 하는 것이었습니다. 모든 사람의 질문에 효율적이고 신중하게 답변해야 했습니다.

팀이 해결할 수 없다고 느끼는 문제를 추적하기 위해 문서를 만들었습니다. 그런 다음 프로젝트 관리자는 이러한 문제를 경영진에게 제기하여 개별 기여자가 서로 문제를 속일 필요가 없도록 관리 조정이 이루어지도록 했습니다.

관리가 강화되었습니다. 이제 우리는 매일 문제를 들을 수 있는 포럼을 가졌으므로 이전에 명확한 소유자 없이 묻힌 어려운 문제를 해결할 책임도 있습니다. 이것은 오래된 사일로의 벽이 무너지는 것을 보기 시작하면서 팀과 궁극적으로 신뢰를 구축하는 일종의 정렬을 강요했습니다. 팀 전체는 결정이 빠르게 내려지고 있다는 것을 알 수 있었고, 이는 구조 조정에 의해 촉발된 치유의 일부를 시작했습니다.

우리가 목표로 하는 것은 의사소통이 더 강하고 문제를 두려워하지 않는 팀입니다. 건설적이고 민주화된 커뮤니케이션을 강조하면 향후 더 큰 베팅을 할 수 있습니다. 당신은 그들이 진행하면서 해결할 자신감이 있기 때문에 위험을 감수할 단위를 만들고 있습니다. 매번 사람들이 무엇에 반응하는지 더 잘 이해하고 더 빠르게 가치를 제공합니다.

이것은 자가 치유입니다. 분대가 "부상"을 입거나 예상치 못한 일을 처리하면 이제 빠른 해결이 있을 것이라는 확신을 가지고 자체 문제를 해결하고 더 큰 항목을 에스컬레이션할 수 있는 모든 것이 준비되어 있습니다.

우리는 결코 도전을 피할 수 없습니다. 조직의 목표가 도전을 피하는 것이라면 결코 성장하지 못할 것입니다. 문제를 정면으로 해결하기 위해 팀을 구성하는 것이 좋습니다. 그리고 한 사람이 모든 문제에 어떻게 대응해야 하는지도 결코 고안해서는 안 됩니다. 팀을 민주화하고 각 기여자에게 목소리를 내는 프로세스를 수립하십시오.

섭취 형태에 의한 사망

섭취 형태에 대한 죽음 이 아니라 섭취 형태에 의한 죽음.

귀하는 접수 양식을 모든 프로세스가 원활하게 진행되기 위한 간소화되고 통합되고 유익한 요구 사항으로 생각할 것입니다. 이해가 됩니다. 그러나 진정으로 해부한다면 모든 팀에는 섭취 세부 사항과 함께 고유한 특수 프로세스가 있으며 문서를 퍼뜨리는 것은 기능하는 팀에게 좋은 출발점이 아닙니다.

스쿼드 모델을 개발하는 목적은 마케팅과 크리에이티브 간에 건전한 팀 간 협업을 장려하는 것이었습니다. 즉, 프로젝트에 관련된 모든 사람들이 한 공간에서 함께 일하게 하여 형식을 없애고 본질적으로 도로의 규칙을 수립하도록 하는 것입니다.

일방적인 프로세스 또는 더 나쁜 경우에는 영향에 전혀 연결되지 않은 사람이 프로세스를 설계하는 대신 프로젝트에 참여하는 두 명의 핵심 팀 구성원을 대면하고 다음과 같이 질문했습니다. 당신의 필요의?”

우리가 발견한 것은 이 문제 해결 방법이 합리적인 프로세스에 더 쉽고 효율적으로 도달한다는 것입니다. 그리고 형식에 대한 형식이나 임의적인 질문을 따르는 것이 아니라 실제 사람을 돕고 있다는 것을 알고 있기 때문에 따라야 할 동의가 훨씬 더 많습니다.

매주 도로 규칙을 개선하고 모든 단계를 문서화함으로써 우리는 말 그대로 배우고 성장하고 있습니다. 더 이상 필요하지 않다고 생각하는 회의가 취소되고 있으며 이는 모두 우리가 시행하고 있는 대면 커뮤니케이션 수준 덕분입니다.

항상 사람을 섬기는

지금까지 이 일을 계속했으므로 비밀 하나를 알려 드리겠습니다. 이 중 어느 것도 진정으로 과정에 관한 것이 아닙니다. 그것은 사람들에 관한 것입니다.

가능한 모든 문제를 해결하는 프로세스를 시도하고 만드는 것은 너무 쉽습니다. 모든 극단적인 경우를 해결하는 계획을 정의하고 문서화하는 것은 너무 복잡하고 너무 건조하며 회사가 계속 성장함에 따라 빠르게 구식이 될 것입니다.

완벽하고 체계적인 해결 방법을 생각해낼 수 있지만, 사람이 처리하도록 만드는 뉘앙스가 없으면 아무도 따라하지 않습니다.

조직은 애자일 접근 방식을 실천하지 않고 철학적으로 왁싱하는 것은 헛된 것임을 이해해야 합니다. 프로세스는 회사 문화를 반영합니다. 당신이 일하는 방식은 당신의 사무실 벽 안에 있는 사람들이 매일 같이 걸어갈 것입니다. 지속적인 피드백을 촉진하고 활용하고, 착수한 모든 프로세스를 다시 읽고, 새로운 팀 구성원의 마음에 자신을 두십시오. 그들이 당신의 도움 없이 당신이 만든 것을 탐색할 수 있습니까?

하루가 끝나면 얼마나 많이 해결했는지에 초점을 맞추는 것이 아니라 구축한 프로세스가 해당 프로세스를 통해 작업하는 사람들에게 얼마나 접근하기 쉽고 지원적인가에 관한 것입니다.

그리고 그것은 관료주의의 반대입니다.