조직 변화: 조직 내 노동 분업과 협력에 관한 다양한 문제

1. 프로젝트 관리자와 제품 관리자 간의 갈등 및 문제 목록

새로운 비즈니스의 경우 회사의 일반적인 관행은 모회사 조직의 영향을 받지 않도록 비즈니스를 분리하는 것입니다. 구조와 인적 자원 모델은 물론, 현재로서는 금융 자원의 한계와 제약으로 인해 비즈니스가 과거의 경험과 관리에 의해 제약을 받고 있다는 것이 분명합니다. 거시적, 미시적 관점에서 보아도 평가 방식이 단순히 인터넷 기업의 논리를 따라가서는 안 된다. 이 싸움은 하드웨어 싸움이기 때문이다.

우선 회사의 전략이 제품을 중심으로 이루어지기 때문에 PM이 수행하는 제품 작업은 명확하고 가치 있고 칭찬을 받기 쉽습니다. 그러나 프로젝트 주기가 길기 때문에 많은 부분이 실패합니다. 일이 예고되기 때문에 PM의 노고는 상대적으로 작아서 보기 쉬운 반면, 프로젝트 관리자의 노고는 크고 보기 어렵습니다. 사업 초기 단계에서는 이런 평가가 합리적이지 않습니다. 우리는 "노력만 하고 공덕이 없는" 사람들을 버릴 수 있고, "노력했지만 결국 공덕이 있는" 사람들을 오해해서는 안 됩니다.

또한 현재의 차량 인터넷 비즈니스 모델은 전통적인 자동차 회사의 프로젝트 시스템을 채택하고 있으며 프로젝트 관리자의 역할도 개선되어야 합니다. 따라서 프로젝트 관리자 역할을 맡은 PM에 대한 평가 및 인센티브 조치는 한편으로는 일선 역량, 특히 자원 할당을 강화해야 하며 다른 한편으로는 인센티브를 조정해야 합니다. 개선됩니다. 하지만 현재로서는 업무량을 명확히 한다고 해도 줄일 수는 없기 때문에 효율성 향상을 위한 인센티브나 명확한 업무 분업 등 최적화가 필요한 부분은 업무 외적인 부분이라고 생각합니다.

2. 해결 방법(메커니즘을 통해 해결, 협력)

문제가 집중적으로 발생하기 전에 메커니즘을 통해 갈등을 노출해야 합니다.

B측의 다양성으로 인해 고객, 제품 관리자와 프로젝트 관리자가 하나로 합쳐지기는 어렵지만, 제품 관리자와 프로젝트 관리자의 책임과 권리가 명확하게 정의되어야 한다는 것이 본질적으로 제품 관리자가 구현하는 제품을 항상 지켜봐야 한다는 생각입니다. PM이 가져야 할 태도. 물론 현재의 비즈니스 형태를 고려할 때 모든 PM이 모든 프로젝트를 수행하는 것은 불가능합니다. 솔루션에는 다음이 포함될 수 있습니다.

1. 업무 분담: 업무 분담을 통해 업무 부담을 줄이고 효율성을 향상할 수 있습니다. PM이 프로젝트 진행에 있어 가져야 할 책임과 권한을 명확하게 규정하고, 필요한 경우 평가를 실시하여 제품 구현에 주의를 기울이고 시장 압력을 느낄 수 있도록 합니다. , 그리고 최종 제품 경험에 책임을 져야 합니다

2 , 인센티브: 모든 PM은 프로젝트로 인해 깊은 고민을 하며 프로젝트 관리자에게 동기를 부여하기 위한 정책이 수립되어야 합니다

3. 힘: 프로젝트 관리자는 특히 자원을 소집하는 데 큰 권한을 가져야 합니다.

참고: 기사에서 프로젝트 관리자는 PM도 프로젝트 관리자이기 때문에 특정 사람이 아닌 역할을 지칭합니다.

3. 기타 관찰

1. 목표관리에 대하여

인터넷 기업은 수준이 매우 낮으나 여전히 충분한 의사소통이 부족합니다. 더욱이 부하 직원의 목표 달성에 대한 어려움과 달성 상태에 대한 상사의 이해 차이가 크다는 것을 보여줍니다. 목표는 위에서 아래로 전달되지 않으며 목표 관리와 일치하지 않습니다.

2. 인센티브 및 평가에 대하여

첫째, 실제 프로젝트 수행에 있어 자동차회사의 프로젝트 수행을 인터넷 관점에서 이해하는데 문제가 있을 수 있다. 힘든 일과 위험이 더 많아지고, 소위 결과(SOP)는 멀리 떨어져 있고 단기적으로는 볼 수 없습니다. 프로젝트 관리자는 위험을 처리하거나 회의실에서 위험을 처리합니다. . 이것은 인터넷의 "작은 단계, 빠른 실행 및 시도"와 다릅니다. 조직 내에서는 성과를 평가하는 것이 맞고, 조직정신으로서 성과에는 문제가 없습니다. 그러나 이러한 눈에 보이지 않는, 무형의 노력은 바로 목표와 성과를 달성하기 위해 겪어야 하는 과정입니다. 즉, 프로젝트는 결과도 중요하지만 과정도 중요하며 그 과정이 피상적이고 뻔하지 않습니다.

둘째, 사람보다 문제가 더 중요하고, 사람이 '투쟁형'이어야 한다. 프로젝트는 압도적이고, 프로젝트의 우선순위는 현재 회사와의 관계에 따라 달라져야 한다. 구현 깊이에 따라 나누어야 하는지 논란이 있지만, 인센티브는 기여도에 따라 이루어져야 한다. 현재로서는 시장이 급속히 확장되는 시기이고, 제품을 다듬어야 한다. 최전방에서는 공격하는 동안 재장전하고(제품 연마) 후방의 지원(물질적 인센티브)과 인정(정신적 인센티브)이 필요합니다. 이것이 바로 화웨이가 "레이펑을 고통받지 않게 해준다"는 의미입니다. 자본 착취와 인센티브 평등주의는 직원의 열정을 해칠 것입니다.

따라서 시장 확대로 인해 작업량을 단기간에 압축하기 어렵기 때문에 분업과 인센티브를 고려해야 하며, 효율성을 높이기 위해 많은 측면을 표준화해야 합니다. 평상복.

3. 조직 내 두 가지 주요 모순

1) 수많은 프로젝트 간의 모순, 고르지 못한 우선순위 및 제품 연마

우선순위가 무엇인지 정의할 필요가 있습니다. ;

많은 프로젝트는 고위급 의사 결정과 시장 확장에서 나오는 반면, 제품 개선은 시장의 압력으로 인해 두 가지 힘이 충돌합니다.

2) PM과 프로젝트 관리자가 필요합니다. 고르지 못한 시장 압력에 비효율적인 조정의 모순

4. 프로젝트 관리자와 제품 관리자 간의 업무 분담에 대하여

1) 제품 관리자에 대한 압력은 시장에서 오는 것이 아니라 시장에서 옵니다. 프로젝트 관리자

차량 인터넷이라는 구체적인 사업에서는 제품 관리자와 프로젝트 관리자 사이의 노동과 권리, 책임의 구분이 불분명합니다. 프로젝트 관리자는 거의 모든 책임을 맡고, PM은 절대 압력을 가하지 않습니다. 시장 납품에 대한 가장 큰 압력은 PM에게서 나옵니다. 귀하가 담당하는 프로젝트가 모든 프로젝트의 모든 제품 모듈을 담당할 수는 없습니다. 근본적인 이유 중 하나는 제품 관리자가 시장과 직접 연결되지 않는다는 것입니다. 고객을 대면합니다. PM이 시장의 압박감이나 시장의 온도를 느끼지 못하고 이중 단열층으로 중간에 자동차 회사와 프로젝트 매니저가 있어야 한다면 이는 최종 제품에 해가 될 것입니다. PM은 프로젝트 관리자가 조장하는 시장 압력에 최대한 빨리 대응해야 합니다. 이는 필요하고 제품을 개선하려는 경우 담당 프로젝트로 인한 압력만 견딜 수 있습니까? , 양쪽 끝의 균형을 맞추는 작업량이 엄청날 것입니다. 각 프로젝트에서 제품 모듈의 압력을 인식한 후 문제의 핵심은 이러한 압력을 완화하는 방법, 즉 수많은 프로젝트 간의 갈등, 고르지 못한 우선순위 및 제품 연마의 필요성에 있습니다. 핵심 경쟁력 형성. "두 가지 측면을 모두 고려하는 것"은 조직의 전략적 문제로서 강조되어야 하지만 시장 압력에 대한 PM의 인식과 대응을 희생해서는 안 됩니다.

2) 조직 구조와 책임 분배에 주의하세요

우선 PM과 시장 사이에 절연층이 너무 많습니다. PM은 제품에 대한 피드백을 제공하므로 제품이 놀라움을 주는 경우가 많습니다. 따라서 PM은 프로젝트와 결과 사이에 단열층으로 포함되어 있으므로 직접 기술 커뮤니케이션에 참여하는 것이 좋습니다. 하지만 PM은 시장에 완전히 무관심합니다. 이러한 모호한 업무 분업으로 인해 서로가 서로의 발전에 장애물이 됩니다.

분업을 명확하게 구분하기는 어렵지만 사전 사양이 없으면 혼란이 더 많은 효율성을 소모하게 됩니다.

3) 계열 전도 압박에 문제가 있다

사실 많은 소통을 했고, 며칠째 소통이 성과가 없는 이유. : 기술이 하기 싫고, PM 대응도 느립니다. 결국 고객은 화를 냈고 기술과 PM 모두 그냥 순종적으로 해야 한다고 말했습니다. 프로젝트 관리자에게 압력을 전달하는 것만으로는 효과가 전혀 충분하지 않은 것 같습니다. .압력 때문에 계열이 아닌 병렬 조직 구조가 필요합니다.

4) 일선 프로젝트 관리자가 가장 큰 권한을 가져야 합니까?

프로젝트 관리자는 일선에 있지만 많은 자원을 동원할 수는 없습니다. 군인들은 시장을 가장 잘 알고 있지만 포격을 요청할 수는 없었습니다.

5) 프로젝트 관리자를 평가할 때 인터넷 회사의 논리를 사용하지 마십시오

전통적인 자동차 회사에서는 프로젝트 관리자가 큰 힘을 갖고 자원 동원 능력이 높은 반면 인터넷 회사는 인터넷 회사의 논리를 사용하지 않습니다. 기업에서는 PM을 매우 중요하게 생각합니다. 그러나 자동차 회사와의 연결 방식은 회사가 프로젝트 관리자에 대한 평가 방법을 바꿔야 한다고 결정합니다. 자원과 힘의 측면에서 어떤 기울기가 있는지 여부는 매우 중요한 문제입니다. 하드웨어 사고 대신 인터넷 사고를 사용하여 지능형 운전 전쟁에 맞서 싸우면 손실을 입을 수도 있고 완전히 실패할 수도 있습니다.

5. 의사소통 방법에 대하여

아래에서 위로 의사소통하고 각 계층에 보고하는 것은 관료주의 요구 사항에 부합하며 가장 간단하고 쉬운 방법이기도 합니다. 그러나 하향식입니다. 의사소통은 경영이다 학자들과 경영 실무자들은 관리자들이 최전선에 나서는 것이 점점 더 어려워질 것이라고 주장하고 있습니다. 관리자는 부하직원의 진행 상황과 애로사항, 지원 포인트를 명확히 해야 하지만 업무에 깊이 관여해서는 안 된다. 즉 사업을 하지 않을 때는 '통역커뮤니케이션 최고책임자'가 되는 것이다.

6. 우리는 스타트업 회사가 아니며, 새로운 비즈니스 개발에 적합한 경영 모델을 모색해야 합니다.

우리는 여러 측면에서 스타트업이 아닙니다. 하지만 사업이 새롭고 전쟁터가 험난하기 때문에 인센티브는 계속 유지되어야 합니다. "대기업 경영 + 신사업"의 조합은 "파괴적 혁신"에서 매우 위험합니다. 방법과 자원 배분 방법은 새로운 비즈니스의 성장을 방해할 것이며, 특히 새로운 기회를 놓칠 것입니다.

분업에 대한 몇 가지 생각

먼저 제안을 설명하고 그 근거에 대해 이야기하십시오. 전제 가정이 불합리하면 제안이 실현 가능하지 않습니다.

제안:

프로젝트 관리자의 위치를 ​​재정의합니다(큰 책임에는 큰 힘이 따른다): 특정 프로젝트에서(다른 시나리오에 관계없이) 프로젝트 관리자의 역할은 다음과 같습니다. 가장 중요한 것은 프로젝트 관리자의 역할이 핵심이어야 한다는 것입니다. 이론적으로 프로젝트 관리자의 권한은 기술, BD, PM보다 훨씬 커야 합니다. 그래야만 프로젝트를 홍보하기 위한 자원을 신속하게 동원할 수 있습니다. 그러므로 직위를 재정의하고 설계하는 것이 필요하다. (사람들이 그것을 할 수 있는 능력을 갖도록 하기 위해) 그리고 인센티브(사람들이 그것을 할 의지를 갖도록 하기 위해). ) 모두가 유능하고 의지가 있도록

2. 시리즈 A와 B는 등급 없이만 수행할 수 있습니다. 특정 프로젝트에서는 프로젝트 관리자가 내부적으로 PM을 찾고 있는 상태입니다. 대외적으로는 자동차 회사와 경쟁하고 있으며, 동료 간 홍보 효율성도 느립니다. 특정 프로젝트에서는 프로젝트 관리자의 권한이 PM보다 커야 하며, 동시에 프로젝트 관리자가 KPI를 담당하고 프로젝트 관리자가 주 역할을 하고 PM이 보조 PM이 됩니다. 프로젝트 관리자의 조력자이자 프로젝트 관리자는 PM의 시장 압력 전달자입니다. 두 사람 모두 동시에 시장에 직면하기 위해 결합하고 병행합니다.

3. 가장 중요한 일만 수행합니다. 프로젝트 관리자의 복잡한 업무를 분할하거나 아웃소싱할 수 있습니다. 예를 들어 차량과 기계의 조정은 BD에서 수행할 수 있고, 음성 테스트는 아웃소싱할 수 있습니다.

4. 제도화:

1) 특히 중복되고 모호한 작업의 경우 서로의 권리와 책임을 명확하게 정의해야 합니다. 또한 프로젝트 요구에 따라 지속적으로 업데이트해야 합니다. ;

2) 네거티브를 설정합니다. 피드백 메커니즘과 바인딩 KPI 규정을 위반하는 경우 폐쇄 루프 관리를 완료하기 위해 그에 따른 처벌이 있어야 합니다.

근거 및 가정:

1. 프로젝트 관리자의 중요성: 자동차 회사와의 연결로 인해 현재 차량 인터넷 프로젝트 관리자의 역할은 프로젝트에 더 가깝습니다. 자동차 회사의 관리자이며 인터넷과는 다릅니다. 프로젝트 관리자는 매우 다르며 직무 요구 사항(조직 능력, 자원 호출 능력, 의사소통 및 조정 능력 등)이 매우 높습니다. 따라서 이 역할은 매우 중요하며 업무입니다. 더 높은 전력과 더 많은 자원이 필요합니다. 무기를 잘 갖추고 있어야만 최전선의 공격자가 시장을 빠르게 점유할 수 있습니다.

2. PM은 시장을 이해하고 제품을 완전히 파악해야 합니다. 비즈니스가 새롭고 프로젝트가 많기 때문에 각 모듈의 PM은 특정 이해가 있어야만 제품을 완전히 파악할 수 있습니다. 각 프로젝트의 시장 상황, 즉 PM의 역할은 사용자에게 맡길 수 없습니다. 맞춤형 요구사항이든 복제 불가능한 요구사항이든 전체 제품 전략과 연결되어야 하며 PM이 무시해서는 안 됩니다. 순수 내부 및 외부 지점은 PM을 회사 내로 격리하여 사용자 요구는 물론 자동차 회사의 요구도 이해하지 못합니다.

3. 직렬 연결은 바람직하지 않습니다. PM과 시장이 프로젝트 관리자와 자동차 회사로 분리되어 시장 압력이 단계적으로 감소하는 반면 PM은 프로젝트 관리자와 자동차 회사로 분리됩니다. 프로젝트 관리자가 PM에게 도움을 요청하지 않고 직접 문제를 해결하면 더 빨리 결과를 얻을 수 있습니다.

4. 현실: 거의 모든 링크에는 프로젝트와 PM 간의 의사소통이 필요합니다.

숨겨진 위험:

이후 단계에서는 대부분의 사람들이 프로젝트가 증가함에 따라 프로젝트 관리자의 역할이 점점 더 스트레스를 받게 될 것입니다. 따라서 한편으로는 정의할 필요가 있습니다. 프로젝트 관리자의 역할을 알아보고 프로젝트 관리자의 중요성을 인식하며, 한편으로는 프로젝트 관리자의 인식을 바탕으로 분업 문제를 논의합니다.