협업 모델 구축

잘 정의되고 구조화된 협업 모델은 Fusion Teams의 효율적인 운영의 핵심입니다. 이 섹션에서는 잘 정의된 역할과 책임, 구조화된 비즈니스 리듬, 안정적인 커뮤니케이션 채널 및 액세스 가능한 문서 포털과 같은 이러한 성공에 기여할 수 있는 요소를 고려합니다.

역할 및 책임 정의

효율적인 융합팀을 만들기 위해서는 먼저 명확한 역할과 책임을 설정해야 합니다. 핵심 접근 방식은 작게 시작하고 필요할 때만 더 많은 역할과 인력을 도입하는 것입니다. 더 야심 찬 프로젝트를 시도하기 전에 더 작은 목표를 사용하여 성공을 기반으로 하고 Fusion Teams 모델의 가치를 입증하십시오.

팀에는 최소한 다음과 같은 직원과 역할이 포함되어야 합니다.

  • 제품 소유자 – 일반적으로 프로젝트의 성공을 보장하는 임무를 맡은 사람입니다. 그 또는 그녀는 또한 명확하고 설득력 있는 목적을 정의하거나 나머지 팀과 그 비전을 공동 개발할 수 있습니다.
  • 도메인 전문가 – 과제와 솔루션을 모두 이해하고 명확하게 설명할 수 있는 비즈니스에 정통한 팀 구성원입니다. 심플함과 함께 Power Apps 로우 코드 접근 방식을 사용하는 경우 해당 솔루션을 만드는 방법을 대부분 얻을 수 있어야 합니다.
  • 전문 개발자 – '프로 개발자'는 도메인 전문가의 솔루션을 받아 필요한 경우 의도한 기능(및 그 이상은 아님)을 제공할 수 있도록 충분한 코딩 지원을 제공합니다.
  • 관리자 – 이 팀 구성원은 백엔드 관리 서비스를 수행하는 동안 통합 및 지원 시나리오를 용이하게 합니다. 핵심 팀이 필요로 하는 시간과 전문성 측면에서 추가 지원은 그룹의 영구 구성원이 아닌 유연한 기반으로 가져올 수 있습니다. 이 접근 방식은 Fusion Teams의 효율적인 운영을 보장하는 동시에 제품 소유자가 팀이 목표를 달성하는 데 필요한 더 많은 리소스에 대한 액세스를 제공합니다.

비즈니스 모델의 리듬 확립

Fusion Teams에서 앱 개발과 관련된 운영 리듬을 동기화하면 다음 구조에 맞춰 팀 효율성을 높일 수 있습니다.

  • 팀 동기화를 위한 반복 일정 이벤트를 정의합니다. 대부분의 팀의 경우 매주 또는 격주로 진행되는 상태 업데이트 회의가 좋습니다. 그러나 회의를 위해 회의를 예약하지 말고 마감일에 가까운 회의 빈도를 늘리는 것은 역효과를 낼 수 있으므로 피하십시오.
  • 합의된 근무 시간을 지키십시오. 이상적으로는 팀이 함께 배치되지만 Fusion Teams은 지역 및 시간대에 걸쳐 효과적으로 작업할 수도 있습니다. 근무 방식이 무엇이든 모든 사람이 근무 시간의 목적과 기간을 이해하고 그 경계를 존중하도록 하십시오.
  • 주간 리듬을 만듭니다. 팀의 주간 리듬에는 솔로 작업, 협업 상호 작용 및 필요한 경우 효과적인 회의가 포함되어야 합니다. 이러한 회의에는 다음과 같은 특정 목적이 있어야 합니다.
    • 범위 검토 – 새로운 이니셔티브에 대해 팀을 한데 모으기 위해.
    • 사용자 경험 리뷰 – 앱 디자인 및 모형을 검토합니다. 다른 회의를 계획하기 위한 회의, 이메일이나 인스턴트 메시지 대신 회의, 명확하게 정의된 목적이 없는 회의는 생산성 저하 요인입니다.
  • 효율적으로 작업하십시오. 팀은 가장 유용한 솔루션을 만들기 위해 내부적으로 조정해야 합니다. 이 정렬에는 다른 사람이 구축한 구성 요소를 재사용하는 기능이 포함되어야 합니다.
  • 목표를 향한 일관된 진행을 유지하십시오. 팀이 목표를 달성하도록 하려면 모든 사람이 그 결과를 달성하기 위해 함께 일하는 것이 중요합니다. Power Apps로 작업하는 Fusion Teams의 경우 이러한 진행 상황을 유지한다는 것은 사용자 피드백을 캡처 및 이해하고, 백로그의 우선 순위를 지정하고, 전체 프로젝트의 전체적인 로드맵을 설정 및 유지하는 것을 의미합니다.
  • 지원 매트릭스를 생성합니다. 지원 매트릭스는 팀의 전체 목표를 향해 나아가는 데 필요한 지원을 얻기 위한 구조화된 접근 방식을 제공합니다. 앱을 직접 구축하는 비즈니스 기술자에게 피할 수 없는 도전은 지식과 능력의 한계에 도달하는 것입니다. 이 시점에서 그들은 누구에게 연락하고 어떻게 합니까? 사용자 버그 보고서를 어떻게 처리합니까? 이 매트릭스는 문제의 심각도에 따라 문제를 해결하고 해결하는 데 적합한 팀을 참여시키기 위해 지원 티켓을 모으는 방법을 설명해야 합니다. 각 지원 시나리오에 대해 이 매트릭스는 에스컬레이션 및 문제 해결 경로를 설명합니다.

팀 커뮤니케이션 방법 정의

팀 커뮤니케이션을 표준화하는 것은 효율적인 운영을 유지하기 위한 또 다른 필수 구성 요소입니다. 모든 팀 구성원은 특히 시간대에 걸쳐 비동기 모드에서 팀이 연결하는 방법을 알아야 합니다. 커뮤니케이션 전략은 다음 영역을 고려해야 합니다.

  • 채널. 팀은 1차 및 2차 커뮤니케이션에 어떤 채널을 사용합니까? 각각의 장점과 단점은 무엇입니까? 선택의 세계에서 단순히 이메일을 채택하는 것은 최상의 솔루션이 아닐 수 있으며 Microsoft Teams와 같은 옵션은 더 나은 명확성, 개선된 추적 가능성 및 더 높은 응답률을 제공할 수 있습니다.
  • 알림 유형 조치가 필요한 업데이트 또는 이벤트를 팀에 어떻게 알릴 것인가?
  • 메시지 빈도 및 볼륨. 얼마나 자주 팀에 알립니까? 일일 커뮤니케이션은 그날 일어난 일에 대한 유용한 요약을 제공할 수 있지만 일부 메시지는 더 빠른 조치가 필요할 수 있습니다. 대부분의 지식 근로자는 이메일로 과부하가 걸립니다. 팀 구성원이 프로젝트 관련 메시지로 휩쓸리지 않도록 빈도와 양 사이의 균형을 유지해야 합니다.
  • 자동화. 커뮤니케이션 프로세스를 어떻게 자동화할 수 있습니까? 표준화된 이메일 템플릿, 봇 및 이벤트 알림이 모두 도움이 될 수 있지만 팀 구성원의 응답 능력에 과부하가 걸리지 않는 경우 책임감 있게 사용해야 합니다.
  • 훌륭한 의사 소통 능력. 팀의 모든 사람이 동일한 수준의 의사 소통 기술을 가지고 있는 것은 아니지만 누구나 더 나아질 수 있습니다. 이메일의 좋은 제목을 선택하는 것과 같은 간단한 접근 방식은 팀이 해당 메시지에 얼마나 잘 응답하는지에 극적인 차이를 만듭니다. 모든 커뮤니케이션에서 간단하고 효과적인 글쓰기를 권장합니다. 팀 구성원이 취해야 하는 조치가 있는 경우 구체적이고 제목 줄에 해당 조치를 호출합니다.

효과적인 의사 소통 기술을 사용하는 방법의 예는 여러 필드를 추가하는 것과 같이 Dataverse에서 테이블 정의를 변경해야 하는 경우일 수 있습니다. 이러한 의도된 변경에 대한 알림을 보낼 때 팀은 합당한 시간 내에 응답하지 않으면 이러한 응답 부족이 동의를 나타내는 것임을 이해해야 합니다. 표준화되고 논리적인 커뮤니케이션 프로세스는 효율성을 개선하고 예상 결과를 제공하는 데 도움이 됩니다.

문서 포털 게시

문서화는 프로젝트의 선택 사항일 뿐만 아니라 커뮤니케이션, 협업, 지원 및 지속적인 운영에 필수적입니다. 주석 처리된 코드는 좋은 코드이며 포괄적인 설명 및 교육 문서를 만드는 것은 모든 융합 프로젝트의 배포 및 학습 단계에서 필수적인 부분입니다.

  • 응용 프로그램 카탈로그. 애플리케이션 카탈로그는 특정 팀의 책임 내에서 모든 애플리케이션을 요약하고 조정하는 매트릭스 또는 테이블입니다. 카탈로그에는 역할 및 책임 섹션의 모든 해당 소유자가 포함됩니다. 핵심 기능은 팀이 누가 무엇을 소유하고 있는지 정확히 알도록 하여 특정 답변을 위해 적합한 팀원에게 연락하는 프로세스를 단순화하는 것입니다.
  • 기술적인 질문. 팀은 앱 작동에 대해 자주 묻는(또는 자주 묻는 질문이 아닌) 기술 질문의 저장소를 유지 관리해야 합니다. 이러한 질문은 합리적이어야 하며 답변을 잘 작성하고 접근할 수 있어야 합니다.
  • 방법 가이드. 방법 가이드는 일반적인 설정 및 작동 질문에 대한 간단한 답변을 제공하는 즉시 이해할 수 있는 일련의 절차입니다. 일반적으로 "새 앱 만들기를 시작하려면 어떻게 해야 합니까?"와 같은 특정 질문에 대답합니다.
  • 온보딩. 온보딩 지침은 새 팀 구성원을 돕기 위해 설계된 내부 전용 문서입니다. 이 문서에는 액세스 요청, 이메일 배포 목록 가입, 경고 설정 및 구독 등과 같은 정보가 포함됩니다.

모범 사례

다음 모범 사례는 Fusion Teams 내에서 효율적인 작업을 위한 경계와 접근 방식을 정의하는 데 도움이 됩니다.

책임

제작자 주도 개발 및 Fusion Teams이 신속한 애플리케이션 개발 및 배포를 가능하게 하지만 이러한 노력이 명백하고 IT 부서와 협력하여 수행되도록 하는 것이 중요합니다. 제작자는 IT에 책임을 져야 섀도우 IT 시스템의 성장과 관련된 문제를 예방할 수 있습니다.

결과적으로 제작자가 앱 구축을 시작할 때마다 IT 부서에 알려야 합니다. 이 알림은 IT가 제작자와 Fusion Teams에 적절한 지원을 제공하여 적절하게 보호되고 관리되는 잘 설계된 앱을 만드는 데 도움을 줄 수 있으므로 개발 프로세스를 용이하게 합니다.

자동화

잘 구현된 자동화는 생산성을 크게 향상시킬 수 있습니다. 솔루션 배포 성공을 높이는 방법의 예는 다중 솔루션 배포에서 필요한 검사를 자동화하는 것입니다. 이러한 자동 확인에는 다음이 포함될 수 있습니다.

  • 각 배포에서 업데이트된 버전 번호를 사용하여 문제 해결 시 문제를 방지하는 솔루션 버전 확인.
  • 연결 참조 중복.
  • 연결 참조 누락.
  • 구성 요소 중복.

PR 검사기 솔루션에는 이 자동화를 효과적으로 통합하는 방법의 예제가 포함되어 있습니다.

보고 중

Fusion Teams과 제작자가 개발한 앱은 데이터 우선 접근 방식에 맞춰야 합니다. 즉, 성공을 직접 모니터링할 수 있는 앱을 구축해야 합니다. 이 결과를 얻으려면 특정 앱의 효과에 대한 정확한 평가를 생성하기 위해 이 피드백의 분석과 함께 팀이 잘 하고 있는 것을 발견할 수 있는 기능을 제공하는 우수한 도구가 필요합니다. 이 결과를 얻으려면 다음을 수행해야 합니다.

  • 애플리케이션 모니터링 및 평가. 한 사람이 어떤 것이 유용하거나 좋은 아이디어라고 생각한다고 해서 자동으로 모든 사람이 그 가치를 찾게 되는 것은 아닙니다. 팀은 앱 사용성을 모니터링하고 기능을 평가하여 새로운 개발이 유용하고 적절하게 작동하는지 확인해야 합니다.
  • 좋은 판단을 격려하십시오. 다시 말해, 할 수 있다는 이유만으로 앱을 구축하지 말고 특정 비즈니스 요구 사항을 해결하기 위해 구축해야 합니다.