신화 신화 맨 월

기술 회사의 제품 리더로서 저는 바닥이 없는 구덩이입니다. Mailchimp에서 최고 제품 책임자로서 제 직업은 경쟁이 치열한 분야에서 성공할 제품을 시장에 출시하는 것입니다. Mailchimp의 열망은 높으며 이를 실현하려면 상당한 양의 제품을 시장에 출시해야 합니다. 종종 회사의 많은 사람들에게 우리가 너무 많은 일을 하고 있다는 느낌을 받습니다. 우리는 항상 바퀴가 빠지는 가장자리에 있습니다.

그리고 당신이 너무 많은 일을 하고 있고 그 이상을 하기로 결정할 때, 당신은 필연적으로 Mythical Man-Month가 언급되는 것을 듣기 시작할 것입니다. 한쪽 끝을 쥐어짜면 다른 쪽 끝에서 신화적인 Man-Month 가 튀어 나오는 스트레스 해소 공 중 하나와 같습니다.

Frederick Brooks가 1975년에 출판한(1975년을 기억하시나요? 소프트웨어 개발이 2020년의 소프트웨어 개발과 100% 비슷했을 때?) 이 책은 소프트웨어 엔지니어들 사이에서 다소 유명합니다. 특히, 전체 책에서 유명한 한 가지 요점이 있습니다(사람들이 책을 전혀 읽었다면 이 점 외에는 아무 것도 읽지 않을 것이라고 확신합니다).

"...남자를 더 추가하면 일정이 단축되는 것이 아니라 길어집니다."

쉬운 수정. 나는 지금부터 프로젝트에 여성 직원을 고용할 것입니다(왕의 귀환 및 Angmar의 마녀 왕과의 싸움 참조).

그러나 문제의 소프트웨어 엔지니어의 성별 식별에 관계없이 Brooks의 주장은 유효하다고 가정해 보겠습니다. 요점은 다음과 같습니다. 소프트웨어는 복잡한 상호 의존성을 많이 가지고 구축하기 어렵습니다. 그리고 그것을 이루기 위해서는 모두가 함께 노력해야 합니다.

내가 팀에 사람들을 추가할 때, 그들은 온보딩되고 프로젝트에 접목되어야 합니다. 누군가는 그들에게 맞는 일을 해야 합니다. 팀은 모든 것이 함께 작동하는지 확인하기 위해 의사소통을 해야 하며, 추가되는 사람마다 의사소통의 복잡성이 기하학적으로 증가합니다. 그리고 어느 시점에서 사람을 추가하는 것은 이익이 아니라 프로젝트에 부담이 됩니다.

다음은 그 점을 보여주는 책의 그래프입니다.

이것은 절대적으로 정당한 지적입니다. 그래서 직장에서 많이 듣는다. 지친 개인 기여자들과 지친 리더들은 모두 그것을 버릴 것입니다. 우리는 더 빨리 갈 수 없고, 더 할 수 없고, 고용을 중단하고, 신화적인 Man-Month 를 읽고 절망합니다! 유일한 해결책은 성장을 멈추고 일부 프로젝트를 중단하는 것입니다.

내가 CPO로서 "우리는 이 일을 할 것입니다!"라고 말할 때 그러면 대답은 종종 "좋아, 그럼 우리는 무엇을 죽일 것인가?"입니다. Mythical Man-Month 는 제품 개발을 제로섬 게임으로 전환합니다. 우리가 한 가지를 원하면 다른 것을 멈춰야 합니다. 자, 그것은 실제 신화이고 저는 호그워시라고 부릅니다.

그리고 병리학적으로 잘못 해석된(우리는 이것에 도달할 것입니다) 결론을 내리자면, 이 책은 가장 빠른 기술 회사가 4 명 모두를 고용하는 회사라고 분명히 말합니다. 더 이상 모든 것이 느려집니다. 누군가는 아마존, 애플, 구글에 책의 사본을 보내 명백히 부풀려진 조직을 고칠 수 있도록 해야 합니다.

이 접근 방식의 유일한 문제는 경쟁이 증가하고 반복 및 실행(단순히 조직 성장을 방해하는 것)하는 공간에서 일치하도록 워크로드를 편집하고 집중하는 것이 멸종의 처방이 될 수 있다는 것입니다. 당신은 직장을 그만 둘 때까지 더 제정신이고 덜 스트레스를 받을 것입니다.

그리고 우리 회사의 제품 관리 책임자로서 나는 속도를 늦추고 집중해야 할 필요성에 동감하지 않습니다. 우리 는 무자비하게 우선 순위를해야합니다! 의심의 여지가 없습니다. 그러나 제품을 실행하는 것은 모순되는 운동입니다. 내가 가진 것의 우선순위를 정하는 동시에 더 많은 일을 하기 위해 계획을 세워야 합니다. 그러나 신화적인 만월 에 직면하여 나는 무엇을 해야 합니까?

놀랍게도 이 질문에 대한 답은 Brooks의 같은 책에서 나옵니다. 다음은 같은 장에 있는 또 다른 그래프입니다.

제품 개발을 확장하는 데 전쟁이 있습니다. 수행하려는 작업이 완전히 분할 가능한 경우 계속해서 사람을 추가하십시오! 작업이 모두 연결되어 있다면 어느 시점에서 사람을 추가하는 것은 잘못된 것입니다.

누군가 다른 프로젝트를 시작하려면 프로젝트를 종료해야 한다고 말한다면 그건 사실이 아닙니다. 두 프로젝트에 커뮤니케이션과 조정이 거의 필요하지 않은 경우 규모를 축소할 수 있습니다.

이것이 CPU에 코어를 추가하면 컴퓨터나 전화기의 경험 속도를 어느 정도 향상시킬 수 있는 이유입니다. 엔지니어가 모두 알아야 할 사항입니다. 물론 코어를 추가해도 복잡한 단일 스레드 계산을 완료하는 데 도움이 되지 않습니다. 하지만 많은 독립적인 작업을 실행하는 데 도움이 될 수 있습니다.

제품 경영진의 경우 확장과 무자비한 우선 순위 간의 갈등을 관리할 수 있습니다.

1. 단일 스레드(제품 팀의 백로그를 가정해 봅시다)인 위치에서 무자비하게 우선 순위를 지정합니다.
2. 독립적인 작업을 처리하기 위해 더 많은 코어 를 추가하여 확장합니다.

그러나 회사의 다른 모든 것들과 완전히 독립적인 것은 매우 드뭅니다. 최소한, 귀사는 병목 현상으로 이어지는 지원 기능(글로벌 IT, 법률, HR 등)을 중앙 집중화할 것입니다.

의존성 관리에 관한 모든 것

그러면 제품 경영자의 역할은 전략을 수립하는 것뿐만 아니라 처리량을 보장하고 상호 의존성 위험을 최대한 줄여 고객과 비즈니스의 가치를 극대화하는 방식으로 실행하는 것입니다. 여기서 핵심은 "가능한 한 많이"입니다. 그렇게 하면 회사를 전자가 아닌 후자의 그래프처럼 보이게 할 수 있습니다. 상호의존성은 치료법이 없는 질병 이지만 여러 치료법으로 증상을 관리할 수 있습니다.

한 가지 솔루션은 신중하게 선택한 이니셔티브 포트폴리오를 통해 종속성을 최소화하거나 제한하는 회사의 전략적 방향을 구성하는 것입니다. 여기서 재미있는 점은 많은 사람들이 이에 대해 반발할 것이라는 점입니다. 두 가지 옵션이 있다고 가정해 보겠습니다. 하나는 조정이 거의 없는 프로젝트 A, B, C를 실행할 수 있고( 다른 제품에 영향을 미친다고 가정해 봅시다), 다른 하나는 수많은 상호 의존성이 있는 프로젝트 D1, D2, D3입니다( 모두 동일한 제품에 영향을 미친다고 가정해 보겠습니다. Mythical Man-Month 가 후자보다는 전자에 반대되는 경우가 많습니다. 종이에는 더 많이 보이기 때문입니다.

실제로 "집중"이 덜합니다. 그러나 실제로는 종속성 관점에서 덜 어렵기 때문에 추가된 인력과 더 잘 맞습니다.

참고로 저는 관련이 없는 회사를 위해 많은 일을 선택하라는 것이 아닙니다. Mailchimp는 조만간 전자 레인지를 만들지 않을 것입니다. 모든 작업은 동일한 장기적 방향으로 진행되어야 합니다. 이 접근 방식은 고객 조사와 같은 글로벌 기능에 대한 부담뿐만 아니라 고객 경험 위험(나중에 논의할 것임)을 증가시킬 수 있습니다. 조심하세요.

또 다른 치료법은 필요 하지 않은 경우 조정으로 팀에 과도한 부담을 주지 않고 필요한 경우 종속성 조정 및 커뮤니케이션을 용이하게 하는 제품 및 프로그램 관리 프로세스를 만드는 것입니다. 때때로 우리 는 더 많은 일 을 할 수 있도록 조정을 관리하려고 할 때 더 적은 일을 하는 번거로운 프로세스를 생성하게 됩니다. 그것은 조각들이 상호 작용하지 않게 하는 너무 적은 조정을 하는 것과 우리 모두가 영원히 서 있기 때문에 조각이 만들어지지 않도록 하는 너무 많은 조정을 하는 것 사이의 균형입니다.

Mythical Man-Month 의 주장은 소프트웨어 프로젝트에 사람들을 추가함에 따라 커뮤니케이션이 기하급수적으로 증가해야 한다는 것입니다. 예를 들어, 프로젝트에 3명의 사람이 있는 경우 3개의 통신 라인이 있습니다. 그러나 4개가 있으면 6개의 통신 회선이 있습니다. 이 경우 한 사람이 추가되면 의사 소통이 두 배로 이어집니다! 재미있는. (물론 이것은 소프트웨어 개발 프로젝트에 대한 커뮤니케이션을 지나치게 단순화한 것입니다.)

다른 사람들은 다른 역할을 가지고 있으므로 다른 양의 자율성을 받습니다. 아마도 프로젝트 관리자는 팀의 모든 사람과 의사 소통해야 합니다. 하지만 API 작업을 하는 엔지니어가 제품 마케터와 소통해야 합니까? 아니면 마케터가 제품 관리자를 통할 수 있습니까? 좋은 프로세스와 회의 주기는 불필요한 의사 소통과 회의를 없앨 수 있습니다. 요점은 브룩스의 의사소통 공식이 사형선고가 아니라 조정의 상한선 이라는 점이다.

마지막으로, 도구, 원칙 및 프레임워크를 실제 협업보다 독립적인 작업과 결합하여 상호 의존성 증상을 퇴치합니다. 예를 들어, 두 팀의 핵심 성과 지표(KPI, 즉 성공 측정)를 조정하여 거의 같은 방향으로의 움직임을 장려할 수 있다면 그들의 독립적인 작업은 KPI는 직교 이동을 장려합니다. 이것은 모든 것이 완벽하게 맞물리는 것을 보장하지 않으며, 미래에 그것들을 서로 맞도록 하기 위해 내가 해야 할 일이 그렇지 않은 경우보다 적습니다. 다른 예에는 "짝수" 문, 설계 시스템 및 자동화된 테스트 사용이 포함될 수 있습니다.

시작이 있습니다. 그러나 상호 의존성은 코드를 넘어 다양한 형태를 취합니다. Mailchimp의 예를 들어보겠습니다.

고객 경험 위험: 방화벽 작업의 숨겨진(그러나 수용 가능한가?) 비용

Mailchimp의 고객은 마케팅 초보자인 소규모 사업자인 경우가 많기 때문에(전 세계적으로 수백만 명의 소규모 사업자 소유주가 마케팅 담당자가 됨) 완벽하고 즉시 이해할 수 있는 엔드 투 엔드 경험을 제공해야 합니다. 우리는 기업 플레이어가 할 수 있는 방식으로 인수를 통해 프랑켄슈타인의 클라우드 괴물을 조립하는 사치를 누릴 여유가 없습니다. 컨설턴트 및 계정 관리자와 제대로 통합되지 않은 소프트웨어에 대해 문제를 제기할 수 없습니다.

소비자 제품(인스타그램, 닌텐도 스위치, 룸바 등)으로서 우리는 즉시 사용할 수 있어야 합니다. 귀하의 비즈니스에 힘을 실어줄 올인원 마케팅 플랫폼은 어렵습니다! 이는 Mailchimp가 구축하는 모든 것이 경험의 관점에서 매끄럽게 연결되어야 함을 의미합니다.

그러나 프로젝트를 완벽하게 분할하면 경험 위험이 발생 합니다. 코드를 독립적으로 작성할 수 없다는 것은 아닙니다. 그것은 달성할 수 있지만 여전히 제품이 다른 팀에서 만든 것처럼 보일 위험이 있으며 이러한 경험은 사용자에게 정말 혼란스러울 수 있습니다. 우리는 Conway의 법칙에 부딪힙니다. 고객은 한 팀의 작업이 끝나는 지점과 다른 팀의 작업이 시작되는 지점을 구분할 수 있습니다.

따라서 백엔드뿐만 아니라 프론트엔드에서도 모든 사람의 작업을 연결하려고 합니다. Apple과 같은 플레이어의 탁월한 CX가 지배하는 생태계 시대에 이것은 소비자 공간에서 거의 테이블 스테이크가 되었습니다. 그러나 이것은 엔지니어링 관점에서 볼 수는 없지만 신화적인 Man-Month의 악몽입니다. 서비스 디자인 관점에서 입니다. 이 모든 "종단 간" 연결된 작업에 더 많은 사람을 추가함에 따라 모든 것이 협업 크롤링으로 느려집니다.

위에서 언급한 세 번째 수정 사항 외에 감시자와 무대 관문이 아닌 도구와 프레임워크를 사용하는 또 다른 릴리스 밸브가 있습니다 . 특히, 나머지 부분과 연결되지 않은 (즉, 수준 이하) 경험을 편안하게 출시할 수 있는 곳은 어디입니까? 위험을 감수하고 앞으로 나아가는 것은 제품 리더의 임무입니다. 따라서 몇 가지 기준을 사용하여 앱을 분류하고(아마도 앱의 트래픽이 적은 새로운 영역을 "캐시 카우"와 동일한 경험 표준으로 유지하지 않을 수도 있음) 결정을 내립니다(예: 인접 혁신). 물론 이것은 디자인을 넘어 확장됩니다.

완벽한 세계에서 방화벽을 사용해서는 안 되는 노력을 포함하여 방화벽 노력을 선택함으로써 항상 Brooks의 법칙을 단락시킬 수 있습니다!

"

내가 만든 소프트웨어는 아무도 죽이지 않는다고 말함으로써 이것을 경고할 것입니다. 내가 의료 기기를 만들고 있다면 이 접근 방식을 옹호하지 않을 것입니다. 그러나 마케팅 소프트웨어 회사에서는 인력을 늘리고 더 빠르게 움직이기 위한 절충안으로 비호환성 가능성을 높인다는 사실을 알고 의도적으로 팀을 격리할 수 있습니다.

Mythical Man-Month 가 우리 회사에서 현실이라는 사실을 인정하는 것이 슬프고 당신에게도 의심이 있습니다. 하지만 관리가 가능합니다 . 이것이 핵심입니다. 병렬화 및 종속성 완화는 Mythical Man-Month 의 신화에 가까운 상태를 제한하는 탈출구를 제공합니다. 따라서 다음에 회사에서 극명한 이분법이 제기될 때(더 천천히 가거나 열망을 포기하는 규모) 일을 정렬하는 방법에 대해 현명하다면 여전히 크게 성장할 수 있음을 기억하십시오.

스케일링의 부드러운 면을 잊지 마세요

Mythical Man-Month 를 관리한다고 해서 엔지니어가 암흑 마법처럼 그것을 호출하는 것을 막을 수는 없다는 점을 명심하십시오. 그들은 그 원칙에 진실을 담고 있을 뿐만 아니라 감정적, 인지적 관점에서 보면 스케일링이 (항상) 형편없기 때문에 이 원칙을 주장하고 있습니다. 코드를 작성하고 고객 문제를 해결하는 데 돈을 받는다고 생각되면 마지막으로 하고 싶은 일은 일상을 바꾸고 새로운 사람들 및 더 큰 팀과 함께 일하는 방법을 찾는 것입니다.

회사를 확장할 때 확장과 변화의 고통에 공감하는 것을 잊지 마십시오. 한 명의 구성원이라도 추가되는 팀은 신뢰와 문화적 관점에서 완전히 새로운 팀이 됩니다. 사람들은 이러한 변화에 지쳤습니다. 즉, Mythical Man-Month 를 관리하고 완화하는 동안 성장을 둘러싼 감정을 관리해야 합니다. 그것은 아마도 가장 중요한 작업일 것입니다.

팀 자체의 Mythical Man-Month 에 대한 강한 믿음은 그 자체로 결론을 현실로 가져올 수 있습니다. 그것은 기본적으로 피터팬에 대한 믿음과 동일합니다. 팀이 확장이 속도를 늦출 것이라고 믿고 변화를 받아들이지 않는다면 실제로 속도가 느려질 것입니다.

따라서 종속성을 관리하고 확장에 도움이 되는 도구를 도입할 때 관행 뒤에 숨은 이유를 명확하게 전달해야 합니다. 인력 문제를 완화하는 작업과 프로세스를 선택하는 데 사람들을 참여시키십시오. 변화의 일부가 되고 전망이 바뀌면 갑자기 확장이 최소한 문화적으로 가능해지기 때문입니다.