주고받기: 엔지니어와 제품 관리자가 서로를 도울 수 있는 6가지 방법

엔지니어와 제품 관리자 간의 경쟁에 대해 들었던 모든 것을 잊어버리세요. 이것은 사라져야 할 패러다임입니다. 오늘날의 기술 세계는 너무 빠르게 움직이며, 앞으로 나아가는 유일한 방법은 주고받는 협력을 통한 것입니다. 이 기사는 엔지니어와 PM이 머리를 맞대고 집중할 수 있는 여섯 가지 방법을 공개합니다.

1. PM: 큰 그림을 공유하라; 엔지니어: 기술적 제약을 공유하라

주기: PM은 프로젝트 뒤에 있는 비즈니스 목표와 고객의 필요에 대한 명확한 이해를 제공함으로써 엔지니어를 도울 수 있습니다. 이것은 엔지니어가 특정 기능이나 마감일이 왜 중요한지 이해하는 데 도움이 됩니다. 맥락을 일찍 공유하면 엔지니어가 그들의 작업을 더 넓은 목표와 일치시킬 수 있습니다.

받기: 반대로, 엔지니어는 프로젝트에 관련된 기술적 제약과 복잡성을 솔직하게 소통해야 합니다. 비교적 작은 기능이 큰 백엔드 변경을 요구할 경우, 이를 사전에 설명하면 PM이 우선순위와 타임라인에 대해 더 나은 결정을 내리는 데 도움이 됩니다.

예시: PM이 특정 기능이 주요 고객을 확보하거나 경쟁 위협을 충족하는 데 핵심이라고 설명하면, 엔지니어는 이를 우선시하는 데 도움이 됩니다. 마찬가지로, 엔지니어가 기능이 확장성 문제로 인해 추가 시간이 필요하다고 공유할 때, PM은 기대치를 조정할 수 있습니다.

자료

PM을 위해: "Product Management in Practice" by Matt LeMay – 제품 목표를 이해하고 소통하는 방법에 대한 종합적인 가이드.

Where the World Designs Electronics

Break down silos and enhance collaboration across all aspects of electronics development

Find Out More

엔지니어를 위해: "The Pragmatic Programmer" by Andrew Hunt and David Thomas – 개발 과정에서의 소통과 기술적 의사결정을 강조하는 책.

2. PM: 마이크로매니지먼트 피하기; 엔지니어: 아이디어 과정에 참여하기

주기: 제품 관리자는 제품 실행의 모든 세부 사항을 통제하려는 욕구를 억제해야 합니다. 엔지니어가 기술적인 측면을 처리하도록 신뢰하고 문제를 그들의 방식으로 해결할 수 있는 공간을 제공하세요. 지나치게 규정적인 관리는 창의성을 억제하고 참여도를 떨어뜨릴 수 있습니다.

받기: 엔지니어는 아이디어 과정에서 주도적으로 나서야 합니다. 물어보기를 기다리지 말고 제품을 개선할 수 있는 제안이나 아이디어를 제공하세요. 많은 엔지니어는 제품의 기능, 성능 또는 디자인을 향상시킬 수 있는 귀중한 통찰력을 가지고 있습니다. 적극적인 태도는 단순히 코드를 작성하는 것 이상으로 제품의 성공에 투자하고 있음을 보여줍니다.

예: PM이 비즈니스 목표를 개요하고 기능을 구현하는 방법을 말하기보다는 입력을 요청합니다. 한편, 엔지니어는 기술적 해결책을 적극적으로 제안하고 브레인스토밍 세션에 기여합니다.

자료

Design Better, Together

Experience flexible controls for team management and project visibility.

Explore Solutions

PM을 위해: "Empowered" by Marty Cagan and Chris Jones – 이 책은 팀이 제품 실행의 주인공이 되도록 권한을 부여하는 방법을 탐구합니다.

엔지니어를 위해: "Creative Confidence" by Tom Kelley and David Kelley – 제품 아이디어에 창의적으로 기여하고자 하는 엔지니어를 위한 훌륭한 자료입니다.

3. PM은 너그럽게 칭찬하라; 엔지니어는 공개적으로 제품 결정을 지지하라

주기: 엔지니어들 사이에서 흔히 나오는 불만 중 하나는 PM이 프로젝트 성공의 공을 독차지한다는 것입니다. 왜냐하면 그들이 종종 리더십에게 프로젝트를 발표하는 사람들이기 때문입니다. PM은 엔지니어링 팀과 공을 나누고 엔지니어들에게 그들의 작업을 발표할 기회를 제공함으로써 신뢰를 구축할 수 있습니다.

받기: 반대로, 엔지니어는 다른 팀이나 이해관계자들에게 발표할 때 PM의 결정을 지지할 수 있습니다. 일부 측면에 동의하지 않더라도, 제품 결정을 공개적으로 지지하는 것은 단결을 보여주고 협력적인 문화를 조성합니다.

예: 성공적인 출시 후, PM은 엔지니어들이 기술적 성과를 발표하도록 초대합니다. 엔지니어들은 반대로, 이해관계자 회의에서 PM의 제품 결정을 공개적으로 지지합니다.

자료

PM을 위해: "Radical Candor" by Kim Scott – 강력한 관계를 구축하고 마땅히 칭찬을 하는 방법에 대한 통찰을 제공하는 책입니다.

엔지니어를 위해: "중요한 대화들" 알 스위츨러, 조셉 그레니, 론 맥밀란 저 - 동료 및 리더십과 효과적이고 지원적인 대화를 나누는 방법을 배웁니다.

4. PM들: 기술 부채 논의에 열려 있어야 함; 엔지니어들: 타임라인에 대해 현실적이어야 함

주기: PM들은 기술 부채와 유지 관리에 대한 대화에 열려 있음으로써 엔지니어들을 도울 수 있습니다. 새로운 기능을 우선시하는 것이 유혹적이지만, 기술 기반을 소홀히 하면 더 큰 문제로 이어질 수 있습니다. 필요한 코드 리팩토링이나 인프라 개선에 시간을 할애하는 것은 장기적인 제품 건강에 대한 이해를 보여줍니다.

받기: 엔지니어들도 일이 얼마나 걸릴지 현실적으로 평가해야 합니다. 너무 보수적인 추정을 제공하면 PM들이 타임라인을 미루도록 압박받을 수 있습니다. 정확한 타임라인을 제공하고 지연을 조기에 소통하는 것은 PM들이 효과적으로 계획할 수 있도록 돕습니다.

예: 엔지니어들은 기술 부채의 위험을 소통하고 PM들은 리팩토링을 위한 시간을 허용하는 동안, 엔지니어들은 기대 관리를 위해 현실적인 시간 추정치를 제공합니다.

자료

PM들을 위해: "기술 부채 101" ThoughtWorks 저 - 기술 부채를 이해하고 관리하는 방법에 대한 훌륭한 입문서입니다.

엔지니어를 위해: "피닉스 프로젝트" 저자: 진 킴, 케빈 베어, 조지 스패포드 - 기술 부채와 비즈니스 우선순위의 균형을 맞추는 것의 영향을 보여주는 소설입니다.

5. PM들: 고객 피드백에 엔지니어 포함하기; 엔지니어들: 비즈니스 우선순위 존중하기

주기: PM들은 고객 피드백을 직접 공유함으로써 엔지니어들을 도울 수 있습니다. 엔지니어들은 고객들이 제품을 어떻게 사용하고 있는지, 어떤 문제에 직면하고 있는지, 어떤 기능을 좋아하는지 들을 때 제품과 더 연결되어 있다고 느낍니다.

받기: 반대로, 엔지니어들은 PM들이 균형을 맞추고 있는 비즈니스 우선순위를 존중해야 합니다. 완벽하지 않은 기능을 출시하는 것이 때로는 경쟁력을 유지하는 데 중요할 수 있으므로, 이로 인해 좌절감을 느낄 수 있습니다.

예시: PM이 엔지니어들을 고객 피드백 세션에 참여하도록 초대하고, 엔지니어들은 일부 측면이 더 다듬어져야 한다고 느끼더라도 특정 기능 출시의 중요성을 이해합니다.

자료:

PM들을 위해: "린 제품 플레이북" 저자: 댄 올슨 - 고객 피드백을 이해하고 이를 실행 가능한 제품 개발 전략으로 전환하는 실용적인 가이드입니다.

엔지니어를 위해: "The Mythical Man-Month" by Frederick P. Brooks – 이 고전적인 책은 소프트웨어 개발 일정과 비즈니스 기대에 대한 도전을 다룹니다.

6. PM들: 명확하고 달성 가능한 목표 설정하기; 엔지니어들: 해결책 중심으로 생각하기

주기: PM이 엔지니어를 위해 할 수 있는 가장 가치 있는 일 중 하나는 명확하고 달성 가능한 목표를 설정하는 것입니다. 모호한 요구사항이나 지속적으로 변하는 우선순위는 좌절을 야기할 수 있습니다. 성공이 무엇으로 보이는지 정의하고 그 매개변수에 따라 PM이 엔지니어가 집중하고 효율적으로 일할 수 있도록 도울 수 있습니다.

받기: 엔지니어는 해결책 중심의 마인드셋으로 문제에 접근해야 합니다. 무엇인가 할 수 없다는 이유를 나열하는 대신, 대안이나 우회 방법을 제시하세요. 건설적인 태도는 PM과 팀이 기술적 장애물에 막히지 않고 전진할 수 있도록 돕습니다.

예시: PM은 프로젝트에 대한 명확한 성공 지표를 제공하며, 엔지니어는 기술적 제약이 생겼을 때 실용적인 해결책을 제시합니다.

자료

PM을 위해: "Measure What Matters" by John Doerr – 팀의 노력과 일치하는 명확한 목표와 측정 가능한 핵심 결과 지표(OKRs)를 설정하는 방법을 배웁니다.

기술자를 위해: "데이터 집약적 애플리케이션 설계" 마틴 클레프만 저 - 기술자들이 확장 가능하고, 신뢰할 수 있는 시스템을 구축하는 방법에 대해 생각하게 도와주는 기술 자료로, 제품 요구사항의 균형을 맞추는 것을 돕습니다.

실제 사례: 일론 머스크의 내부 관료주의를 줄이기 위한 5단계 알고리즘

일론 머스크는 테슬라와 스페이스X에서의 대담한 경영 스타일로 잘 알려져 있습니다. 내부 관료주의를 통과하기 위한 그의 탐구에서, 머스크는 월터 아이작슨의 최근 전기에서 자세히 설명된 5단계 알고리즘을 개발했으며, 이는 프로세스를 간소화하기 위한 실행 가능한 틀을 제공합니다.

1. 모든 요구사항에 의문을 가지세요: 머스크는 "똑똑한 사람"이 제시한 요구사항이라도 도전하라고 조언합니다. 각 요구사항에 이름을 붙이고, 계속해서 필요한지 물어보세요. 필요 없다면 제거하세요.
2. 과정의 어떤 부분이든 삭제하세요: 머스크는 단순함이 핵심이라고 강조합니다. 불필요한 단계를 삭제하세요—생각보다 더 나아가세요. 적어도 10%를 다시 추가하지 않아도 된다면, 충분히 삭제하지 않은 것입니다.
3. 단순화하고 최적화하세요: 불필요한 단계를 제거한 후에만 남은 것을 단순화하고 최적화하세요. 원래 존재하지 않아야 할 프로세스를 간소화하는 실수를 피하세요.
4. 사이클 시간 가속화: 프로세스가 간소화되면, 그것을 가속화하는 데 집중하세요. 머스크는 불필요하거나 중복되는 프로세스 부분을 가속화하는 데 시간을 낭비하지 말라고 경고합니다.
5. 마지막으로 자동화하기: 머스크의 마지막 단계는 자동화지만, 프로세스를 철저히 질문하고, 삭제하고, 단순화한 후에만 해당됩니다. 너무 이르게 자동화를 시도하면 불필요한 복잡성을 초래할 수 있습니다.

머스크의 방법은 PM들과 엔지니어들이 비효율성에 도전하고, 워크플로우를 간소화하며, 생산성을 최적화하는 방법의 강력한 예가 될 수 있습니다. 가정을 지속적으로 질문하고 프로세스를 단순화함으로써, 제품 개발 팀은 내부 장애물을 크게 줄이고 협업을 강화할 수 있습니다.

스트레스는 줄이고, 열정은 더하기

사이먼 시넥이 현명하게 말했듯이, "우리가 관심 없는 것을 위해 열심히 일하는 것은 스트레스라고 불리고, 우리가 사랑하는 것을 위해 열심히 일하는 것은 열정이라고 불립니다." 이것은 엔지니어와 PM들 사이의 관계에도 적용됩니다. 서로에 대한 상호 존중과 열정으로 함께 일할 때, 위대한 일이 일어납니다. 이러한 주고받는 정신이 여러분 팀의 다음 큰 제품 출시를 이끌게 하세요.