기술 프로젝트 관리자란 무엇입니까?

게시 됨: 2022-03-11

TPM(기술 프로젝트 관리자)이란 무엇입니까? 베테랑 IT 컨설턴트이자 비즈니스 운영 전문가인 Andi Blackwell은 대답은 누구에게 묻는가에 달려 있다고 말합니다. Toptal의 프로젝트 및 제품 관리 수석 이사인 Blackwell은 Toptal의 프리랜스 네트워크에서 고도로 숙련된 프로젝트 관리자를 특정 이니셔티브에 대한 최고의 인재를 찾는 조직과 연결하는 책임이 있는 팀을 이끌고 있습니다. 최근 몇 년 동안 그녀는 TPM에 대한 수요가 급증했습니다.

Blackwell은 "이 용어가 실제로 무엇을 의미하는지에 대해 기술 산업 전반에 걸쳐 확실히 논쟁이 있습니다."라고 말합니다. "엔지니어링 팀과 매우 긴밀하게 협력했거나 프로젝트 관리 관점에서 기술 팀을 이끌었기 때문에 스스로를 기술 프로젝트 관리자라고 부르는 사람들이 많이 있습니다. 하지만 우리가 원하는 것은 그런 사람이 아닙니다."

Toptal의 정의는 보다 구체적입니다. Toptal 네트워크의 모든 프로젝트 관리자는 범위 지정, 예산 책정 및 일정 관리와 같은 기존 프로젝트 관리 기술과 반복 제공 및 지속적인 개선과 관련된 애자일 소프트웨어 개발 관행의 전문가입니다. 그들은 변함없이 엔지니어들과 긴밀하게 협력했으며 요청이 있을 경우 스크럼 팀을 지도하고 안내할 수 있습니다.

그러나 TPM 자격을 얻으려면 Agile 프로세스를 관리하고 개발자와 협업하는 것 이상의 추가 경험이 있어야 합니다. 즉, 개발자 자신이어야 합니다.

소중한 조합

크고 작은 조직은 이러한 특정 기술 조합에 점점 더 관심을 갖고 있습니다. Blackwell은 "대부분의 신생 기업은 한 가지만 할 수 있는 사람을 고용할 수 없습니다."라고 말합니다. 대기업은 엔지니어링 프로젝트를 위해 고용하는 경우 후보자 프로필에 "개발자" 또는 "건축가"를 표시하기를 원합니다.

클라이언트가 기술 배경을 가진 프로젝트 관리자를 특별히 필요로 하지 않는 경우에도 "개발자" 확인란을 선택하는 것이 주요 판매 포인트입니다. 소프트웨어 프로젝트를 계획 및 실행하고 Agile 프로세스 및 코드를 구현 및 최적화할 수 있는 사람이 있습니까? 그것은 큰 혜택입니다.

그러나 실제로 TPM은 코딩할 것으로 예상되지 않습니다. 많은 사람들이 몇 년 동안 코딩하지 않았습니다. 그렇다면 프로그래밍 경험이 필요한 이유는 무엇입니까?

Blackwell은 TPM이 기술적인 결정을 내리는 데 필요합니다. 올바른 결정을 내리지 못할 가능성이 있습니다. 당신은 이전에 그런 것들을 사용해 본 적이 없기 때문에 클라이언트와 신뢰를 가지지 못할 것입니다.”

팀 작업

잠재 고객에게 신뢰성을 입증하는 것은 계약을 확보하는 데 중요한 요소이지만 첫 번째 장애물일 뿐입니다. 프로젝트에 할당되면 TPM은 신속하게 기술 팀의 신뢰와 존경을 받아야 합니다.

Michael Poythress는 십대 때 프로그래밍을 시작했습니다. 16세에 그는 아버지와 함께 시작한 부동산 광고 사업을 위해 상업 웹사이트를 만들었습니다. 그는 그 이후로 여러 스타트업의 CEO이자 설립자였습니다. 2018년에 그는 TPM으로 Toptal 네트워크에 합류했으며 현재는 엔지니어링 팀과 긴밀하게 협력하고 있습니다. “코딩에 대한 경험이 없었다면 프로그래머가 그 일을 했을 것입니다.”라고 그는 말합니다. “그들은 나와 함께 똑바로 쏘지 않을 것입니다. 하지만 내가 그들에게 도전하고 또래처럼 이야기한다면 존경심과 친밀감이 생깁니다.”

캘리포니아 주 오렌지 카운티에 있는 Toptal TPM인 Allen Takatsuka는 제목보다 더 중요한 것은 기술 경험이라고 말합니다. 그들은 회의를 정하고 스프레드시트를 작성하도록 요청하는 또 다른 프로젝트 관리자라고 생각합니다.”

그러나 일단 공통점이 확립되면 “상호작용의 맛은 매우 다릅니다. 엔지니어링과의 파트너십에 가깝습니다.”라고 그는 말합니다.

Takatsuka는 경력 초기에 수십 년 동안 엔지니어링 팀을 이끌었습니다. 그는 그 경험을 자신의 소프트 스킬을 향상시킨 것으로 인정합니다. "이것은 약간 다른 공감 기술입니다."라고 그는 말합니다. “당신은 당신이 그 언어를 말할 수 있다는 것을 보여야 합니다. 당신은 '진행되고 있는 기술적인 문제를 기반으로 왜 당신이 이러한 문제를 겪는지 알겠습니다.'라고 말할 수 있습니다.”

버지니아 주 비엔나의 기술 컨설턴트인 Dan Allen은 자신의 경력을 "건축가, 이사, 부사장, CTO, CIO로 기술 책임자로 거듭나는 설계사 프로그래머"라고 설명합니다. 2019년 TPM으로 Toptal 네트워크에 합류한 이후 그는 14개의 클라이언트 계약을 수행하면서 바빴습니다.

“저는 코드를 거의 읽지 않습니다. 나는 코드를 거의 작성하지 않습니다.”라고 그는 말합니다. “하지만 개발자가 막히는 상황이 있었습니다. 그들은 아키텍처를 통해 나를 안내할 수 있고 나는 그들이 하려고 하는 것과 논리를 정확히 볼 수 있습니다.”

그는 역학이 극단적인 경우뿐만 아니라 더 광범위하게 유용하다는 것을 알게 되었습니다. "당신의 팀은 그들이 당신에게 와서 이야기할 수 있다는 것을 알고 있고 당신은 그들이 말하는 것을 정말로 이해하고 있습니다."라고 그는 말합니다. “당신은 그들이 뭔가를 놓친 경우에 대비하여 모든 복잡성을 고려하도록 도울 수 있습니다. 당신은 공명판이 되어 피드백을 제공할 수 있습니다.”

승수 효과

그런 종류의 피드백과 통찰력은 관계 구축 이상으로 중요합니다. TPM은 조직에 다른 가치 제안을 제공합니다. 그것들은 정보를 전달하는 통로라기 보다는 지식의 원천으로서 더 많은 역할을 합니다. 예, 그들은 계획, 조정 및 의사 소통을 하지만 고객과 팀이 복잡한 기술 결정을 통해 작업하는 데 도움을 주기도 합니다.

Takatsuka는 "당신은 기술적으로 독단적인 능력을 가지고 있습니다."라고 말합니다. "그리고 이는 조직에 가치를 더합니다. 이제 단순히 조직하고 협업하는 것과는 대조적으로 더 많은 승수 효과를 얻을 수 있기 때문입니다."

Takatsuka는 TPM이 문제를 해결하기 위해 더 적은 수의 고리를 건너야 한다고 말합니다. 특히 대규모 조직에서는 비기술적 프로그램 또는 프로젝트 관리자가 관련 참여자 및 이해 관계자를 식별하고 컨텍스트를 제공하고 정보를 집계한 다음 결정을 내리기 위해 결과를 선별하여 기술적 문제에 접근할 수 있습니다. TPM은 자신의 지식을 활용할 수 있습니다.

도쿄에 기반을 둔 TPM인 Oana Ciherean은 "위험을 훨씬 더 효율적으로 해결할 수 있습니다."라고 말합니다. “그리고 그러한 위험은 많은 곳에서 올 수 있습니다. 그들은 팀의 잘못된 추정에서 올 수 있습니다. 그래서 당신은 '좋아, 나는 이 코드 조각을 작성하는 데 일주일이 걸리지 않을 것이라고 확신한다'고 말할 수 있다. 왜냐하면 그것은 정말로 이틀이기 때문이다. 따라서 실제로 사람들을 차단 해제할 수 있습니다. 당신은 그들이 갇혀 있고 그것이 5일이 걸리는 이유를 알아차렸기 때문입니다. 당신은 거기에 있었고 당신 자신이 갇혀 있기 때문에 그것을 압니다.”

균형 찾기

Ciherean은 개발자로 경력을 시작했지만 더 큰 그림에 참여하고 싶어 곧 프로젝트 관리로 옮겼습니다. 그러나 그 역할에서 그녀는 코딩을 놓친 것을 발견했습니다. 그녀는 기술 프로젝트 관리가 두 가지 장점을 모두 제공한다고 말합니다. "기술을 실제로 실습할 수 있을 뿐만 아니라 비즈니스와 고객, 기능에서 원하는 것을 이해하는 데 높은 수준을 제공할 수 있습니다."

Poythress 역시 자신의 장점을 찾았다고 생각합니다. “저는 아이디어를 갖고 있는 비전가와 그것을 구축하고 실현하는 방법을 알고 있는 기술적인 인재 사이의 번역가 또는 연락 담당자입니다.”라고 그는 말합니다. “저는 두 언어를 모두 유창하게 구사합니다. 나는 '보통 사람'을 말하고 '기술적인 사람'을 말합니다.”

미니 CTO

스타트업과 소규모 비즈니스를 위해 일하는 TPM은 비즈니스와 기술의 교차점에서 특히 중요한 자리를 차지합니다. 이러한 계약에서 TPM은 프로젝트 초기에 합류하는 첫 번째 직원인 경우가 많습니다. 그런 다음 그 또는 그녀는 제품 실행 가능성을 평가하고, 기술 범위와 요구 사항을 정의하고, 클라이언트(때로는 아이디어의 묘목을 가진 단일 창립자)가 기술 스택을 선택하고, 서비스 제공을 위해 공급업체를 평가하고, DevOps 모범 사례를 구현하도록 지원하는 일을 담당합니다. 올바른 팀을 구성하십시오.

Takatsuka는 이러한 계약을 TPM이 비즈니스와 기술 영역을 연결하여 일을 시작하는 "미니 CTO" 역할로 생각합니다. 일부 고객은 소프트웨어 개발에 대해 거의 알지 못한다고 그는 말합니다. 애자일에 대해 읽었습니다. 어떻게 해야 하나요?”

Poythress는 두 가지 역할이 겹치는 것으로 보고 특정 경우에는 서로 구별할 수조차 없습니다. "교차 수분이 많이 있습니다."라고 그는 말합니다. "소규모 조직의 CTO는 대규모 조직의 고위 기술 PM 역할로 매우 쉽게 이동할 수 있으며 집과 같은 편안함을 느낄 수 있습니다."

민첩성 활성화

애자일의 역학은 소프트웨어 개발 경험이 있는 거의 모든 프로젝트 관리자의 조타실에 있지만 기술 적성을 가진 사람은 프로세스 관리에 대한 보다 미묘한 관점을 가져올 수 있습니다.

Ciherean은 Agile 방법론이 이 책에서 엄격하게 구현되지 않는다는 것을 발견했습니다. 팀 및 프로젝트의 특정 요구 사항에 맞게 사용자 정의, 혼합 및 조정해야 합니다.

그녀는 "프로세스로 설계하는 것이 개발자의 작업을 방해하지 않고 실제로 더 효율적이거나 생산적으로 만드는지 확인해야 합니다."라고 말합니다. "때로는 GitHub 워크플로에 대해 자세히 알아보는 것을 의미합니다. 예를 들어 커밋을 수행하는 방법, 코드에 대한 분기를 생성하는 방법, 프로세스가 워크플로에 맞는지 확인하는 방법 등입니다. 그런 다음 프로세스를 수정하거나 워크플로를 수정합니다.”

TPM의 전문 지식은 또한 제품 백로그 및 상대적 크기 추정과 같은 특정 Agile 아티팩트 및 관행에 정보를 제공할 수 있습니다.

Takatsuka는 "기술을 이해하면 백로그의 대략적인 복잡성을 알 수 있습니다. “그렇지 않으면 당신이 가진 모든 것이 이 목록이고 1번이 2번과 비교하여 1번 티셔츠 사이즈 라지인지 여부를 알기 어려울 것입니다. 당신은 하나가 더 어렵다는 생각을 할 수 있지만 실제로는 그 이면에 있는 것이 무엇인지 모릅니다. 그는 "극단적인" TPM은 "팀이 합류할 때 자체 속도를 갖게 될 것이라는 경고와 함께 스스로 크기를 조정할 수 있습니다."라고 말합니다.

Poythress는 규모 추정에 대한 자신의 이해를 게이지로 사용하여 그가 프로젝트에 대해 고려하는 기술 리드와 엔지니어를 평가합니다. 그가 무언가를 작은 작업으로 기대하지만 다른 사람이 그것을 거대하다고 생각한다면 그것은 위험 신호입니다. 나는 '좋아, 그건 잘 맞지 않는군.' 우리는 이것을 정말 잘 이해하고 단순한 기능이어야 하는 것에 겁먹지 않는 사람이 필요합니다.”

TPM은 또한 비기능적 요구 사항에 대해 고객을 교육하는 데 도움이 됩니다. 고가용성을 어떻게 처리합니까? 재해 복구를 어떻게 처리합니까? Takatsuka는 "기술적인 이해가 없으면 어떻게 논의했는지 모르겠습니다. “스크럼 요구 사항 수준에서 멈추고 기술 인력이 올 때까지 하루라고 부를 것입니다. 글쎄, 당신은 이 거대한 틈을 가지고 있습니다.”