요약: 기업 간의 자원 동맹과 상호 보완적 이점을 실현하려면 사람들은 기존 체제 하에서 기업의 협력을 더 잘 실현하기 위해 기업 자체를 위한 협상과 협력의 의사소통 기술을 습득해야 합니다. 정책 조건, 사회를 발전시키고 봉사하기 위해서는 기업과 정부, 기업과 대중, 기업과 언론 등의 관계를 처리하는 것도 필요합니다. 이는 모두 경영 커뮤니케이션의 원칙과 기법을 숙달하고 적용하는 능력과 분리될 수 없습니다. _기업 간 효과적인 의사소통 방법
1. 각자의 책임을 명확히 한다
두 회사는 서로의 장점이 있기 때문에 협력하는 경우가 많고, 프로젝트 개발에 앞서 서로의 장점을 배우게 됩니다. 각자의 책임을 명확히 하세요. 이렇게 말하면 아주 간단하게 들리지만, 실제 과정에서는 여전히 모호한 점이 많습니다. 갈등을 피하기 위해서는 각자의 경계를 명확히 하는 것이 중요합니다.
예를 들어 한 회사와 다른 회사 간의 협력 과정에서 콘텐츠가 상대방의 플랫폼에 배치되기 때문에 콘텐츠 위험을 피하기 위해 상대방은 특정 요구 사항을 제공합니다. 요구 사항을 충족하는 것에 관해서는 전제하에 어떤 콘텐츠가 업로드되는지 통제하는 것은 회사의 몫입니다. 두 회사의 각자의 책임을 명확히 하는 것은 협력을 위한 전제 조건입니다.
2. 명사의 개념과 문서의 내용을 명확히 하세요
우리 둘 다 인터넷 업계에 종사하지만, 제품 등 업계의 일부 공통 명사에 대해서는 모두가 잘 알고 있습니다. , UI 디자인 등. 하지만 독선적이지 않도록, 더 많은 질문을 하더라도 서로에게 명확해야 합니다.
이런 손실을 입은 회사가 있는데, 직원들이 제품 요구사항 문서인 줄 알고 (보여주기 위해) 파트너사에 상세한 제품 설계 문서를 요청했습니다. 전문성을 바탕으로 직원이 제품 문서를 보냈습니다) 이전에도 일시적으로 검토 및 수정되었습니다. 결과적으로, 그들이 말한 "제품 설계 문서"는 실제로 기술 개발 문서를 의미한다는 것을 오해했다는 것을 나중에 알게 되었습니다. 이로 인해 잘못된 방향으로 시간을 낭비하게 되었고, 올바른 방향에 대한 기술 문서가 아직 작성되지 않아 시간이 낭비되었고 결국 원하는 결과를 얻지 못했습니다.
더 중요한 것은 이런 일에 직면했을 때 책임을 묻는 것이 불분명하고 불가능한 경우가 많기 때문에 이러한 문제를 피하기 위해서는 사전에 소통하는 것이 가장 좋습니다.
용어 개념을 명확히 하는 것 외에도, 협업 시 작성해야 할 문서와 문서의 내용을 미리 전달하는 것도 필요하다. 문서가 있으면 통신 비용을 줄이고 논쟁을 피할 수 있습니다. 문서에 있어서 가장 중요한 것은 어떤 내용이 포함되어 있는지 명확히 하는 것입니다. 문서의 내용, 특히 핵심 사항만 있으면 형식은 중요하지 않습니다.
3. 커뮤니케이션 방법 및 작업 프로세스 결정
커뮤니케이션 방법은 두 가지 측면으로 나누어집니다. 하나는 이메일, QQ, WeChat 등과 같은 커뮤니케이션 도구를 결정하는 것입니다. 다른 하나는 정기적인 회의 시스템을 구축하는 것입니다. 기존 요구사항을 어떻게 실현할지에 대해 논의하는 것 외에도 다음 단계에 대한 아이디어를 서로 소통할 수 있다는 점과 몇 가지 사항을 논의할 수 있다는 것입니다. 양측 관계자들에게 알려졌습니다.
회사마다 커뮤니케이션 방식과 업무 프로세스가 다르다. 인터넷 회사에서 제품 디자인, UI 디자인, 기술 개발, 테스트 등 일반적인 프로세스는 동일하지만, 구체적인 구현 및 출력 표준에는 여전히 약간의 차이가 있으므로 협력하기 전에 서로를 이해해야 합니다.
테스트를 예로 들어보겠습니다. 테스트 링크가 있더라도 구체적인 프로세스는 여전히 다릅니다. 일반적으로 회사는 내부 테스트 후 바로 온라인에 접속할 수 있지만 일부 회사에서는 내부 테스트가 있습니다. 테스트에는 공개 테스트와 A/B 테스트의 세 단계가 있으며 이를 통해 온라인 출시 시간이 연장됩니다. 사전에 원활한 의사소통이 이루어지지 않고 테스트가 내부 테스트일 뿐이라고 판단되는 경우, 양측 간의 예상 출시 시간 불일치로 인해 일부 오해가 발생하고 운영 활동 등 다른 작업 준비 시간에도 영향을 미칠 수 있습니다.
제품 관리자의 경우 요구사항 개발 시간이 지연되지 않도록 워크플로를 이해하는 것이 매우 필요합니다. 예를 들어, 자신의 회사에서 어떤 기능을 개발했다면, 그 기술의 개발 시기를 정확하게 파악하고 있기 때문에 괜찮습니다. 하지만 상대방의 개발이 필요한 경우 상대방이 다른 프로젝트를 할 수도 있기 때문에 미리 상대방에게 요구사항을 언급하고 타이밍을 파악해야 합니다. 그렇지 않으면 상대방이 요구사항을 늦게 제출하기 때문입니다. 그렇게 할 시간이 없어서 큰 문제가 발생할 것입니다.
4. 상대방의 의도를 악의적으로 추측하지 마세요
두 회사가 협력할 때는 분명 마찰이 있을 것입니다. 비록 관계만큼 가깝지는 않지만 신뢰는 있어야 합니다. 기지가 설립됩니다.
제가 매우 깊이 느낀 점은 상대방이 우리를 난처하게 하려는 의도가 있는지, 상대방이 우리 시스템을 공격했는지 등을 고의로 추측하는 것이 아니라는 것입니다. 이런 상황이 실제로 존재할 수도 있지만, 실제 검증을 거쳐 문제를 판단해야 합니다.
상대방에 대한 악의적인 추측은 어떤 부정적인 결과를 낳나요? 이는 팀의 사기에 큰 영향을 미치며, 특히 두 회사의 배경과 팀 강점이 매우 다를 때 약한 쪽은 실제로 코드 작성 표준과 같은 일부 측면에서 강한 쪽의 요구 사항을 받게 됩니다. 우리는 아웃소싱 회사는 아니지만 제품의 특성과 업계 내 다른 회사의 위치로 인해 시스템 안정성에 대한 요구 사항이 특히 높은 상황에 직면했습니다.
상대방의 요구 사항이 상대적으로 높고 그것을 이해할 수 없다면 시간이 지남에 따라 여러 번 마음 속에 많은 감정이 쌓이게 될 것입니다. 이렇게 되면 상대방의 의도를 추측하기가 더 쉬워질 것이고, 기존 회사의 위상에 격차가 더해지면서 직원들의 업무는 더욱 부정적으로 변하게 될 것입니다.
5. 자기 일을 잘하고 자신에게 엄격하라
양당의 협력 중에 부하가 부당한 대우를 받으면 리더는 그를 보호하기 위해 최선을 다할 것이다. 좋은 리더는 부하들의 이익을 보호해야 한다. 그러나 부하직원을 공정하게 대우하고, 부하직원의 업무태도와 산출결과를 정확하게 평가하고, 부하직원의 이익을 보호하면서 부하직원이 일을 잘했는지 판단하는 것은 여전히 필요하다.
일부 리더는 부하 직원의 이익을 맹목적으로 보호하면서도 부하 직원의 능력 부족을 무시합니다. 더욱이 일부 부하 직원은 리더의 사고방식을 이용하여 자신의 일을 성의 없이 수행하고 장애물에 직면할 때 리더에게 문제 해결을 요청합니다.
한 회사의 디자이너가 제작한 디자인 초안을 양측의 검토를 거쳐야 통과된 적이 있었는데, 다른 회사의 디자이너가 이에 만족하지 못했습니다. 우리가 디자인한 작품에는 언어에 문제가 있습니다. 그러한 행동을 접하게 되면 좀 더 강경하게 상대방에게 사과를 요구할 수 있지만 결국 결과는 여전히 이상적이지 않으므로 진정하고 문제를 해결해야 합니다.
디자인 초안의 검토는 기술적인 문제와 달리 주관적인 요소의 영향을 더 많이 받습니다. 이런 문제에 직면했을 때, 한쪽이 최선을 다한다는 전제 하에, 효과가 만족스럽지 않다면, 양측은 서로 구체적인 의견을 제시해야 합니다. 구체적인 의견이라고 하는 이유는 모호한 수사가 양측의 의혹을 불러일으킬 수 있기 때문이다. 더욱이 의견이 구체적일수록 문제 해결의 효율성도 높아지기 때문이다.