앱 개발 프로세스에서 프로젝트 관리자의 역할과 가치
게시 됨: 2021-10-05앱 아이디어가 있는 소프트웨어 개발 회사에 오면 프로젝트 관리자가 배정됩니다. 이 사람은 당신의 어시스턴트이자 개발자에 대한 링크라고 합니다. 그러나 프로젝트 관리자는 구체적으로 무엇을 합니까? 정말 필요한가요? (스포일러 - 예, 그렇습니다.)
프로젝트 관리자의 몇 가지 특정 책임을 살펴보고 앱을 만들 때 전문가가 필요한 이유를 살펴보겠습니다. 우리는 그들이 중요한 역할을 한다는 것을 확신할 수 있습니다.
소프트웨어 개발에서 프로젝트 관리자의 역할은 무엇입니까?
프로젝트 관리는 아이디어를 가지고 개발 회사에 왔을 때 시작하는 첫 번째 프로세스입니다. 프로젝트 관리자(PM)는 개발자 및 디자이너 팀과 귀하 사이의 커뮤니케이션 채널이 되는 것 외에도 하는 작업이 있습니다.
아래에서 논의할 가장 기본적인 사항 외에도 PM의 책임은 다음과 같습니다.
- 앱이 사용자를 위해 해결할 문제를 결정합니다.
- 이 문제에 대한 해결책을 결정하는 것;
- 귀하의 아이디어를 검증하는 데 도움이 됩니다.
- 소프트웨어 개발 프로세스 로드맵;
- 귀하 및 팀과 함께
일정과 예산 내에서 프로젝트를 완료합니다.
다음은 특정 순서 없이 각 작업에 대한 몇 가지 개요입니다.
모바일 앱뿐만 아니라 모든 비즈니스 아이디어가 떠오를 때 이를 검증해야 합니다 . 우리는 곧 아이디어 검증에 대한 자세한 기사를 갖게 될 것이지만 지금은 이것이 없으면 실패의 위험이 있다는 것을 알고 있습니다. 수익을 내기 위해 기업은 고객을 위해 몇 가지 문제를 해결해야 합니다. 그렇지 않으면 그 제품이 필요하지 않으며 멀리 가지 않을 것입니다.
검증 프로세스의 일부는 제품(이 경우 모바일 앱)이 해결할 문제를 결정하는 것입니다. 피트니스 앱은 우리가 몸매를 만들고 건강을 유지하는 데 도움이 되며 음식 배달 앱은 쇼핑과 요리에서 우리를 해방시키며 데이트 앱은 우리의 연애 생활에 활력을 불어넣을 수 있습니다. 책, 영화 스트리밍, 요가, 교통수단, 예약 앱 — 이들 각각은 어떤 식으로든 우리의 삶을 더 쉽게 만듭니다. 이것은 앱에서도 수행해야 하는 작업입니다. 그리고 고유하거나 더 잘 구현된 일부 기능을 제공하여 다른 앱보다 더 잘 수행해야 합니다. IT 프로젝트 관리자와 브레인스토밍하는 것은 그 독특함을 찾아 전문 PM이 수년에 걸쳐 얻은 경험을 바탕으로 통찰력을 제공할 수 있기 때문입니다.
문제를 파악하고 솔루션을 찾은 후에는 프로젝트를 계획해야 합니다. 전략적 로드맵 은 프로젝트 관리자가 하는 가장 중요한 일 중 하나입니다. 로드맵은 각 스프린트 동안 완료해야 하는 작업 목록입니다. 적절한 계획이 없으면 프로젝트가 느슨해질 수 있습니다. PM은 클라이언트 및 앱 개발팀과 논의한 후 로드맵을 작성하고 이 로드맵에 따라 개발 프로세스를 모니터링합니다.
훌륭한 IT 프로젝트 관리자는 앱 개발 프로세스의 모든 부분에 대해 알고 있으며 위험을 완화하고 귀중한 의견을 추가하며 성공적인 시작을 위한 최상의 옵션을 조사할 수 있습니다. 이 모든 것이 추가 비용 이 거의 또는 전혀 없이 보다 원활한 개발 프로세스 를 가능 하게 하며 예상치 못한 문제로 인해 개발이 중단됩니다.
IT 프로젝트 관리자의 주요 책임
계획
시장은 빠르게 변화합니다. 앱이 수익을 올리려면 적절한 카테고리에서 적절한 시기에 출시되어야 하고 적절하게 보여야 합니다. 앱 생성은 여러 단계로 이루어지며 각 단계는 팀의 다른 부분에서 완료됩니다. 시장 분석, 각 단계의 복잡성, 각 단계에 할당된 팀을 기반으로 좋은 계획이 수립됩니다. 잘못된 계획은 기한을 놓치는 결과를 낳습니다.
로드맵은 소프트웨어 개발의 기술적 측면을 계획하는 주요 부분입니다. 하지만 그 이상의 과정이 있습니다. 아이디어 검증, 사용자 스토리 매핑, MVP/MLP 설계 — 프로젝트 관리자는 앱 개발 프로세스에서 많은 책임을 집니다.
의사 소통
대부분의 경우 클라이언트는 각 개발자와 연락할 시간도 없고 열망도 없습니다. 그래서 자체적으로 앱 개발 부서를 구축하는 대신 IT 아웃소싱 회사에 가는 것입니다. 그렇죠? 회사에서 앱을 주문하고 IT 프로젝트 관리자가 요구 사항을 디자이너와 개발자에게 전달할 것이라고 신뢰합니다. 적절한 의사 소통이 없으면 원하는 것과 다른 것을 얻을 위험이 있습니다.
PM의 역할은 클라이언트 및 팀과 계속 연락하고 메시지를 전달할 뿐만 아니라 여러 가지 방법으로 공통 언어를 찾도록 돕는 것입니다. 여기 Mind Studios 에서는 대부분의 디자이너와 개발자가 영어를 확실히 이해하고 잘 의사 소통할 수 있기 때문에 언어 장벽에 문제가 없습니다. 더 큰 문제는 종종 사고 방식에 있으며 PM은 개발 팀이 클라이언트와 같은 페이지에 있도록 이를 부드럽게 할 수 있습니다.
계획 변경 사항 소개
개발 중에는 변경이 불가피합니다. 이유는 다양합니다. "AHA!" 당신이 알고 있는 완벽한 아이디어가 당신을 App Store 차트의 정상으로 이끌 것인 순간; 새로운 플레이어가 귀하의 세그먼트에 진입하면 시장에 변화가 있을 수 있습니다. 제품에 필요한 새로운 기술이 출시될 수 있습니다. 당신과 당신의 개발 회사에 의한 테스트는 좋든 나쁘든 예상치 못한 결과를 가져올 수 있습니다.
대부분의 경우 프로젝트에서 즉시 아무것도 변경하는 것이 거의 불가능합니다. 변경 사항은 다음 스프린트 또는 그 이후 스프린트에 추가됩니다. 그러나 이러한 변경 사항이 잘 수행되면 제품에 가장 좋은 일이 발생할 수 있습니다.
개발의 모든 단계에서 무언가를 추가하거나 제거해야 할 때 이러한 변경 사항을 팀에 소개하고 계획을 조정하는 것은 소프트웨어 프로젝트 관리자의 역할입니다. PM은 프로젝트 중단을 최소화하고 비용이 급증하는 것을 방지하면서 변경 사항을 계획에 적용해야 합니다.
프로세스 제어
모든 단계에서 통제하는 것이 예상치 못한 문제를 관리하고 마감일을 놓치지 않고 변경 사항을 구현할 수 있는 유일한 방법입니다. 그리고 이 제어를 유지하는 것은 아마도 프로젝트 관리자에게 가장 중요한 작업일 것입니다. 아무도 개발의 맥박을 놓치지 않는다면 결과 응용 프로그램이 최선을 다할 방법이 없습니다. 더군다나 통제력 부족으로 인해 상황이 악화될 수 있습니다.
동시에 모든 프로젝트에서 균형이 중요하며 제어에는 한계가 있어야 합니다. 경험 많은 PM은 팀을 신뢰하고 세세하게 관리하지 않습니다. IT 산업은 상당히 젊고 유연하며 앱 개발 프로젝트를 이끄는 관리자도 유연해야 합니다. 여기서 프로젝트 관리의 중요성이 가장 두드러집니다.
좋은 PM과 나쁜 PM — 차이점을 구별하는 방법
협업의 초기 단계에서는 배정된 PM이 좋은지 나쁜지 확인하기가 쉽지 않습니다. 지구 반대편에 위치한 아웃소싱 회사와 일하고 있다면 더욱 어렵습니다. 그러나 찾아야 할 몇 가지 확실한 징후가 있습니다. 다음은 애플리케이션 개발의 초기 단계에서 주의해야 할 사항입니다.
좋은 PM: 질문을 많이 합니다.
물론 개발이 이미 진행 중인 경우 범위에 약간의 변경이 있을 것입니다. 그것은 사실상 주어진 것입니다. 그러나 이것은 예상치 못한 변경 사항이 발생했을 때 쌓이지 않도록 처음부터 필요한 기능 및 가능한 문제 목록이 포함된 매우 상세한 계획이 있어야 함을 의미합니다. PM이 "내일 생각해 보자"라는 말로 Scarlett O'Hara를 끌어들인다면 주의를 기울여야 할 첫 번째 작은 신호입니다.
나쁜 PM: 모든 것을 팀에 맡김
신뢰는 좋은 것입니다. 모든 사람이 자신을 위해 일하는 팀은 거의 수행하지 않습니다. 그러나 소프트웨어 엔지니어링에서 사물의 맥박을 파악하는 것은 프로젝트 관리자의 임무입니다. PM이 현재 단계에서 진행 중인 질문에 답변할 수 없는 경우 함께 작업 중인 사람을 다시 평가해야 합니다.
Good PM: 정직하고 투명합니다.
천재적인 아이디어가 있고 그렇지 않은 아이디어가 있습니다. 그다지 많지 않습니다. 프로젝트 관리자는 고객의 아이디어에 조정이 필요한지 알려줄 수 있어야 합니다. PM이 목표 지향적이고 프로젝트가 성공하기를 바라는 경우 해당 기능 또는 이 기능을 계속 진행해야 하는지 아니면 그냥 두는 것이 더 나은지 정직하게 말할 것입니다.
또한 팀이 프로젝트에 어려움을 겪고 있거나 관련 경험이 부족하고 일부 개념과 기술에 익숙해지는 데 추가 시간이 필요할 수 있는 경우에도 정직합니다. 좋은 PM이 항상 예라고 말하지는 않습니다.
나쁜 PM: 지나치게 낙관론자(또는 비관론자)입니다.
팀이 이전에 매우 유사한 프로젝트를 수행한 적이 없는 한, 아무 생각 없이 즉시 유쾌하게 "할 수 있습니다"라고 말하는 것은 나쁜 관리자의 표시입니다. 회사용 앱을 디자인하는 것은 복잡한 프로세스이며 신중한 평가가 필요합니다.
반면에 PM이 가장 작은 문제에 당황하는 것을 원하지 않습니다. 또는 이유를 제시하고 작동하게 만드는 방법을 찾으려고 노력하지 않고 "우리는 할 수 없습니다"라고 말합니다.
Good PM: 모든 것에 주의를 기울인다
팀 구성원 간의 문제든 프로세스 진행 방식에 대한 약간의 문제든 좋은 PM은 이에 대해 알고 있습니다. 상황이 요구하지 않는 경우 적극적으로 참여하지 않을 수도 있지만, 문제가 확대되지 않도록 제시간에 뛰어들 수 있는 능력과 능력이 있음을 알고 있기 때문입니다.
나쁜 PM: 마이크로매니지스
그것은 비즈니스이고 우리는 여기에서 모두 성인입니다. 그렇죠? 30분마다 직원의 목을 조르며 어떻게 지내는지 묻는 것은 나쁜 습관으로 간주됩니다. 그리고 팀 내 개인적인 문제에 관해서는 – 때로는 최고의 결정이 분쟁에서 나옵니다. (물론 유혈사태에 가깝지 않다면 말이다.)
Good PM: 팀의 의견을 묻고 클라이언트에게 전달합니다.
여러 관점에서 사물을 보는 것은 매우 중요하며 훌륭한 IT 프로젝트 관리자는 자신의 지식이 절대적이지 않다는 것을 알고 있습니다. 팀의 의견은 매우 소중하며 고객과의 브레인스토밍도 중요합니다.
나쁜 PM: 이메일로 당신을 공격합니다.
모든 사람을 루프에 유지하는 것은 한 가지입니다. 그러나 가장 작은 변경 사항이라도 알려주고 하루에 두 번 보고서를 보내는 사람이 프로젝트를 주도한다면 어느 시점에서 모든 것을 성가신 것으로 필터링하기 시작할 것입니다.
이는 다음 두 가지 결과로 이어집니다.
- 당신은 화를 내고 불만을 갖게됩니다.
- 실제로 중요한 것을 걸러낼 수 있습니다.
훌륭한 프로젝트 관리자는 무엇을 공유해야 하고 누구와 공유해야 하는지 알고 있습니다. 너무 많은 정보는 누구에게나 어지럽습니다.
프로젝트 관리자의 기여가 성공에 중요한 이유
보시다시피 소프트웨어 엔지니어링에서 프로젝트 관리자의 역할은 엄청납니다. 팀의 모든 사람이 자신이 하는 일과 방법에 대해 잘 알고 있어야 하지만 그들을 이끄는 것은 프로젝트 관리자입니다. 그리고 여느 리더와 마찬가지로 계획대로 일이 진행되도록 하는 것이 그들의 임무입니다. 여기에는 무엇보다도 영감을 주고, 밀고 당기고, 동기를 부여하는 것이 포함됩니다.
인게이지먼트 인스티튜트(Engagement Institute)에 따르면 업무에 참여하지 않는 직원은 회사에 수십억 달러의 비용을 발생시킵니다. 나쁜 PM은 당신과 당신의 프로젝트가 잠재적 이익에 대한 자신의 몫뿐만 아니라 모든 팀 구성원의 몫을 희생시킵니다. 그리고 관리 부실 때문에 제품이 제 시간에 완성되지 않으면 입게 될 손실은 말할 것도 없습니다. 좋은 PM이 전체 프로세스에 추가하는 입력은 과대평가될 수 없습니다.
Mind Studios의 프로젝트 관리자
이제 이 기사의 끝 부분에 도달했으므로 파트너로 적합한 프로젝트 관리자를 선택하고 앱을 성공적으로 출시하는 데 도움을 줄 수 있는 지식이 생겼습니다. 궁금한 점이 있으면 전화를 걸어주시면 축적된 경험을 바탕으로 도움을 드리겠습니다.