프로젝트 관리 - 우수 사례 검사 목록

AEM(Adobe Experience Manager)을 구현할 프로젝트를 관리하려면 프로젝트를 구현하기 전과 구현 중 동시에 해야 하는 문제 및 (관련) 결정을 인식하기 위한 계획과 이해가 필요합니다.

도움이 되도록 우수 사례는 다음과 같습니다.

  • 이러한 우수 사례로 진행 상태를 추적하고 모니터링할 수 있는 대화형 검사 목록입니다.

    • 단계, 이정표 및 페르소나에 따라 입력 및 결과물을 정의합니다.
    • 진행 상황과 프로젝트 상태를 나타내는 자동 개요(품질, 상태 및 완벽성)를 제공합니다.
  • checklist에 직접 기반을 두고 다음 내용을 자세히 설명하는 설명서입니다.

  • 특정 영역에 대한 자세한 내용을 제공하는 추가 참조 자료입니다.

프로젝트 하트비트 대시보드

프로젝트 하트비트 워크시트는 프로젝트에 대한 중요한 지표의 그래픽 개요를 제공합니다.

  • 위상 품질

  • 위상 상태

    • 프로젝트에 대한 높은 수준의 상태 표시기;위험 가능성이 있는 영역을 강조 표시하는 데 유용합니다.
  • 위상 완전성

    • 프로젝트 도중 어느 시점에서나 프로젝트의 각 단계에서 완료된 작업의 양을 나타냅니다.

역할별 상태

역할별 상태 워크시트는 상태, 품질완료​의 세부 분류를 단계모습​으로 표시합니다.

단계 및 마일스톤

프로젝트 계획은 서로 다른 상위 단계로 분류됩니다.

각 단계에는 고유의 이정표가 포함됩니다. 각 페르소나(또는 역할)에 대해 정의된 산출물을 만드는 데 필요한 문서와 함께 관련 이정표가 나열됩니다.

노트

개별 필수 문서와 결과물 간에는 직접적인 1:1 관계가 없습니다.

준비

프로젝트 준비는 전체 프로젝트의 기초가 된다. 다음과 같은 목표에 대한 명확한 목표와 기대치를 함께 주요 요구 사항을 정의해야 합니다.

  • 비즈니스 근거

    • 이 사업을 착수한 근본적인 이유와 정당성.
  • 범위 및 일정

    • 기본 범위와 개략적인 일정을 이용하여 필요한 사항과 일정 기간 내에 정의할 수 있어야 합니다.이 옵션을 사용하면 범위 밖에 있는 항목을 정의할 수도 있습니다.

프로젝트를 준비, 계획 및 실행하고 솔루션을 구현하는 방식은 고정 예산, 고정 타임라인, 컨텐츠 수량, 품질 요구 등과 같이 운영 중인 제한 사항의 영향을 받습니다.

언제나 그렇듯이, 어떤 요인들을 조정하면 다른 사람들에게 영향을 미칠 것이다. 예를 들어 시간을 단축하지만 동일한 수준의 품질을 요구하면 가격이 인상될 뿐만 아니라 원하는 컨텐츠의 양을 줄일 수 있습니다. 예산은 중요한 요소이기 때문에 그러한 관계를 잊을 수 없다.

4가지 요소:

projectphans_fourphans

마일스톤

  • 유효성 검사

    이 단계에서는 프로젝트의 목표를 검증하고 확인해야 합니다.예를 들면 다음과 같습니다.

    • 무엇을 성취하고 싶습니까?

    • 누가 이익을 볼까요?

    • 범위는 어떻게 됩니까?

      • 이러한 정보를 통해 상황을 명확히 할 수 있다면 범위 밖에 있는 항목을 정의할 수도 있습니다.
    • 성공을 어떻게 정의할 것인가?

    • 어떻게 성공을 측정할 것인가?

    • 비즈니스 및 기술적 요구 사항은 무엇입니까?

    • 교체할 기존 시스템이 있습니까? 그렇다면 마이그레이션할 데이터가 있습니까?

    • 누가 관여할 것인가?

    • 진행 상황을 어떻게 측정합니까?

    • 프로젝트 작업 중 진행 상황을 얼마나 자주 검토할 수 있습니까?

  • 예산

    프로젝트를 시작하기 전에 구현에 소요되는 비용에 대한 안정적이고 현실적인 평가가 필요합니다.

    • 검증 이정표의 정보를 추정의 기초로 사용합니다.
    • 당신의 추정에 현실적이어야 합니다.
    • 클라이언트가 적용될 수 있는 모든 클라이언트 지침, 프로세스 또는 제한 사항을 고려하거나 준수합니다.
    • 추후에 예산에 대한 검토 또는 개선이 필요한 비상사태나 검토 과정을 고려하십시오.
    • 비용은 많은 형태로 들어온다는 것을 기억하라.구매, 리소스 및 비용 이용

계획

프로젝트를 계획하면 준비가 통합됩니다. 여기에서 목표 및 기대를 명확한 의사 소통 및 진행 상황 측정에 대한 엄격한 검토와 함께 구체적인 작업으로 구성된 잘 정의된 로드맵으로 전환해야 합니다.

마일스톤

  • 인도

    깨끗한 인계는 프로젝트의 해당 개인/그룹이 책임을 인식하도록 보장합니다.

    로드맵, 범위, 목표, 요구 사항, KPI 등 모든 관련 사항을 완벽하게 파악할 수 있도록 전체 세부 사항을 제공/생성해야 합니다.

  • 위험 평가

    불쾌한 놀라움을 피하기 위해 위험 평가를 사용하여 잠재적 위험을 확인하고 영향과 확률을 함께 수량화합니다.

    이 작업은 프로젝트 수명 주기 초기에 수행되어야 모든 취약점이 식별되고 평가됩니다. 전체 요구 사항을 구현할 수 있는지 여부와 필요한 경우 적절한 조치를 취하거나 추적할 수 있는지 여부를 이해 관계자에게 보고할 수 있습니다.

  • 커뮤니케이션

    커뮤니케이션은 모든 프로젝트의 성공에 항상 중요합니다. 모든 사람이 다음을 수행할 수 있도록 명확하고 효율적으로 커뮤니케이션해야 합니다.

    • 동일한 기본 목표를 위해 작업
    • 동일한 정보 기반
    • 동일한 채널 사용
  • 시작

    킥오프 회의는 프로젝트가 시작되고 있다는 인식을 높이기 위해 사용됩니다. 이것은 좋은 기회이다:

    • 모든 이해관계자(또는 적어도 그룹 담당자)를 초대합니다.

    • 프로젝트에 대한 주요 사실들을 제시하라.

    • 질문에 답변합니다.

    • 모든 사용자가 동일한 기술 자료를 가지고 있는지 확인합니다.

    • 모든 팀원이 참여하도록 약속합니다. 그래야 합니다.

      • 프로젝트 시작 부분에 주요 사용자(예비 작성자 포함)를 참여시키면 프로젝트에 대한 헌신을 강화할 수 있습니다.

개발 준비

개발을 계획하는 것은 필요한 지식을 가진 팀이 프로젝트를 견고한 디자인을 기반으로 구축되도록 하는 데 중요합니다.

마일스톤

  • 개발 팀 인력 및 교육

    프로젝트를 시작하기 전에 개발 팀의 직원이 적절하게 채워지고 모든 팀 구성원이 해당 작업에 대한 교육을 받아야 합니다.

  • 컨텐츠 아키텍처

    콘텐츠 아키텍처는 컨텐츠의 향후 아키텍처를 정의하고 설명합니다.포함:

    • 컨텐츠 트리에셋 포함
    • 기본 구조;캠페인 등을 포함합니다.
    • 다중 사이트 및 다중 언어 구조(MSM, 번역 등)
    • 지원 컨텐츠(태그 및 태그 지정 개념 포함)
    • 캐싱 및 컨텐츠 재사용 전략
  • 시스템 아키텍처

    시스템 아키텍처는 시스템의 개념적 관점을 정의합니다.포함(다른 정보 포함):

    • 모든 필수 환경을 위한 시스템 구조

    • 하위 시스템

    • 제3자 시스템

    • 인터페이스;하드웨어, 소프트웨어 및 인간 상호 작용

    • 각 환경에 적합한 서버기술 요구 사항하드웨어 크기 조정 지침 참조

    • 각 환경에 대한 프로세스예를 들어 배포 및 유지 관리 요구 사항

    • 유지 관리 활동(데이터 저장소 GC, TarPM 최적화 등)

    • 🔗 Dispatcher 캐싱

    • 클러스터링 게시/Authorshare

    • 클라이언트측 성능(JS 미니화, 오목, css 스프라이트, 총 http 요청 수 및 기타)

  • 애플리케이션 아키텍처

    애플리케이션 아키텍처는 제안된 애플리케이션의 동작을 정의하고 설명합니다.

    주요:

    • 사용자와 상호 작용하는 방법
    • 내부 구조가 아닌 애플리케이션에서 사용하고 생성하는 데이터

    정의는 다음과 같습니다.

    • 프로젝트의 기본 코드 구조
    • 코드 아티팩트(번들, 패키지 등)
    • 템플릿/구성 요소 및 관계 분류
    • 필수 사용자 정의에 대한 높은 수준 세부 정보(특정 오버레이는 나중에 따르게 됨)
    • 솔루션에 필요한 워크플로우 디자인(예: 컨텐츠 작성, 승인, 출판, 변형, 가져오기, 내보내기 등)
    • MSM, Commerce, 제3자 통합과 같은 복잡한 모듈에 대한 특별 고려 사항
  • 시스템 통합

    시스템 통합을 사용하려면 다음을 계획(그런 다음 구현)해야 합니다.

    • 모든 하위 시스템과 솔루션 통합을 결합하여 하나의 일관된 시스템으로 운영하는 방법
    • 제3자 시스템을 통합하는 방법제3자 시스템이 다운된 경우 오프라인/온라인, 클라이언트측/브라우저 측 또는 폴오버 처리와 같은 특별한 고려 사항과 함께
  • 테스트 개념

    개발을 시작하기 전에 프로젝트에 대한 모든 testing 요구 사항에 대한 심층적이고 포괄적인 개념을 구성해야 합니다.

    여기에는 다음이 포함되어야 합니다(다른 항목 중).

    • 수행할 모든 테스트의 세부 사항
    • 이러한 테스트에 필요한 컨텐츠 준비
    • 사용할 테스트 도구의 정보
    • 테스트에 참여할 사람의 높은 표시특히 QA 팀 외부의 그룹
    • 테스트 자동화 세부 사항예를 들어 Selenium 또는 AEM Developer Mode에서
  • 경험 디자인

    XD(Experience Design)에는 솔루션에 사용할 사용자 경험을 디자인하는 작업이 포함됩니다.

    사용자 경험은 작성자와 웹 사이트의 최종 사용자 모두를 위해 분석 및 개발되어야 합니다.

  • 지원 설정

    개발 전에 배포, 릴리스, 테스트 및 보고서 문제를 진행하는 데 필요한 모든 지원 프로세스를 적절히 설정해야 합니다.

    Adobe 지원 포털도 참조하십시오.

작업 계획 및 작업

이와 유사하게 프로젝트 수명 주기의 모든 단계에서 필요한 환경을 유지하도록 작업을 적절하게 계획해야 합니다. 또한 유지 관리를 위한 적절한 프로세스가 필요합니다.

마일스톤

  • 권한

    솔루션을 사용할 모든 사용자/그룹에 대해 역할 및 권한 개념을 계획하여 구현해야 합니다.

    예:

    • 각 역할에 대한 read/ write 액세스 정의가 있는 역할 목록(예: 그룹)

    • 게시 환경에 영향을 주는 권한 사용에 대한 정의예를 들어 replicate

    • 최소한의 권한을 가진 사용자의 경우 워크플로우를 정의해야 합니다

    • editor 그룹의 사용자는 admin 권한을 가질 수 없으며 administrators 그룹에 속할 수 없습니다.

    자세한 내용은 사용자 관리 및 보안을 참조하십시오.

  • 모니터링 및 유지 관리

    모니터링 및 유지 관리는 솔루션 실행 시 원활한 운영을 보장하는 핵심 요소입니다. 이를 위해 다음을 정의해야 합니다.

    • 모니터링이 필요한 항목
    • 유지 관리 작업;일반 및 특수 경우

    자세한 내용은 모니터링 및 유지 관리를 참조하십시오.

  • 마이그레이션

    기존 시스템의 모든 컨텐츠는 마이그레이션 시 검토 및 검증되어야 합니다.

  • 복구 계획

    복구 계획이 적소에 있는지 확인합니다. 비상시에는 AEM의 생산 사용을 보장하기 위해 이것을 사용할 수 있어야 한다. 백업, 복원, 팔로우어 및 기타 등의 상황에 해당됩니다.

개발

개발은 단순한 코딩이 아닌 중요한 단계입니다.

마일스톤

  • 개발 환경

    다음을 비롯한 개발 환경을 계획 및 문서화합니다.

    • 아키텍처

    • 개발 툴

      • 일반적인 환경은 다음과 같이 구성됩니다.

        • 문제 추적 시스템;Jira 같은
        • IDE;예: Eclipse
        • 빌드 관리 도구;마벤 같은
        • 지속적인 통합을 위한 툴예: 젠킨스
        • 버전 관리 툴GIT/SVN과 같은
        • 빌드 아티팩트 저장소 관리자;아르키바/넥서스 등
    • 타사 소프트웨어 통합/종속성

    • 솔루션 통합/종속성

    • 배포 대상

  • 테스트 시스템

    다음을 포함하여 테스트 환경을 계획 및 문서화합니다.

    • 아키텍처
    • 개발 빌드에 대한 종속성야간 빌드 포함
    • 제3자 소프트웨어 통합/종속성 테스트의 가능성 또는 제한 사항
    • 테스트 툴
    • 자동화된 테스트 전략
  • 프로덕션 시스템

    다음과 같은 프로덕션 환경을 계획 및 문서화합니다.

  • 통합

    시스템 및 솔루션 통합의 모든 측면을 계획, 문서 및 테스트:

  • 마이그레이션

    컨텐츠 마이그레이션의 모든 측면을 계획, 문서 작성 및 테스트;포함:

    • 콘텐츠 아키텍처
    • 마이그레이션 전략
  • 커뮤니케이션

    모든 팀 구성원 및 프로젝트 구성원이 필요에 따라 최신 상태로 유지되도록 합니다.

  • 설명서

    솔루션 문서 작성;포함:

    • 작업 설명서
    • 업그레이드에 영향을 줄 수 있는 모든 사용자 정의
    • 릴리스 노트

성능 및 테스트

새 응용 프로그램을 사용할 수 있게 되면 기능과 performance 모두에 대해 엄격한 테스트를 거쳐야 합니다.

노트

모든 테스트 팀은 중립을 지키고 테스트 결과를 전달하도록 허용해야 합니다.

프로젝트 관리자는 결과에 미치는 영향을 평가하고 적절한 조치를 결정하는 것이 책임이다.

마일스톤

  • 최종 사용자 수락 테스트

    UAT(사용자 수락 테스트 )는 다음 사항을 확인해야 합니다.

    • 솔루션은 사용자/고객 요구 사항을 충족합니다.
    • 고객/사용자는 솔루션(함수, 디자인 및 성능)을 수락합니다.

    고객 전달을 위한 공식적인 확인 목록이 있어야 합니다.스냅샷 을 기반으로 야간 기반으로 자동화 및 실행할 수 있습니다. 결과를 프로젝트 관리자 및 개발 팀에 보내야 합니다.

  • 성능 및 로드 테스트

    성능 및 로드 테스트는 솔루션이 평균 및 최고 로드 시간에 필요한 성능 수준을 충족하는지 확인하는 데 사용됩니다.

    성능 테스트에 대한 자세한 내용은 다음을 참조하십시오.

    노트

    이 과정은 일반적인 AEM 사용 기간 동안 계속되어야 하지만, 이러한 초기 단계는 가장 중요합니다.

롤아웃

새 응용 프로그램을 롤아웃하려면 매끄럽게 Go Live를 수행할 수 있도록 신중하게 계획해야 합니다. 여기에는 높은 수준의 보안을 확인하고, 예비 사용자를 모두 교육하며, 모든 문제가 해결되었다는 것을 확인하기 위해 여러 개의 연습 과정을 수행하는 것이 포함됩니다.

마일스톤

  • 준비

    준비 및 계획은 원활한 롤아웃을 보장하는 데 도움이 됩니다.

  • 트레이닝

    모든 관련 직원이 교육을 받았는지 확인하십시오.

    강좌 카탈로그에서 Adobe Experience Manager을 참조하십시오.

  • 관리자 교육

    솔루션 관리자가 다음을 보유하는지 확인합니다.

    • 교육 받음
    • 해당 교육 자료를 받았습니다.
    • 해당 설명서를 받았습니다.
  • 교육 받은 사용자

    작성자가 다음 사항을 가지고 있는지 확인합니다.

    • 교육 받음
    • 해당 교육 자료를 받았습니다.
    • 해당 설명서를 받았습니다.예를 들어 사용 안내서
  • 침투 테스트

    침투 테스트는 잠재적인 보안 취약점을 식별하기 위해 컴퓨터 시스템에 대한 공격을 시뮬레이션합니다.

  • 침투/보안 테스트

    솔루션의 보안을 유지하기 위해 광범위한 보안 테스트를 실시하여 특정 보급률 테스트를 수행합니다.

    자세한 내용은 보안 검사 목록을 참조하십시오.

Go Live

Go Live를 가능한 매끄럽게 하기를 원하는 경우 마지막 단계에서도 클린 실행을 계획해야 합니다.

마일스톤

  • 준비

    준비 및 계획을 통해 원활하게 진행하십시오.

  • 보안

    내부 및 외부 사용자와 해당 컨텐츠 모두에 대한 솔루션의 보안을 확인합니다.

  • 폴백

    라이브하기 전에 대비에 필요한 모든 시스템, 절차 및 메커니즘이 제대로 작동하는지 확인하십시오.

  • 지원

    지원 서비스가 적시에 준비되는지 확인하십시오.

  • 전환

    프로덕션 환경과 사용자로의 전환을 계획 및 실행합니다.

  • 롤아웃

    연기 테스트를 준비하고 실행합니다.

모습

확인 목록은 개인 사용자에 의해 설계되었습니다. 이러한 역할은 프로젝트 라이프사이클과 관련된 중요한 역할을 합니다.

또한 특정 작업에 관련된 일부 다른 가상도 있습니다.

프로젝트 후원사

프로젝트 후원사는 다음과 같습니다.

  • 프로젝트에 대한 비즈니스 사례를 제공/제공하는 책임입니다.

  • 프로젝트의 범위를 구체화하고 정의하는 핵심 요소포함:

    • 성공의 정의 및 기준
    • 주요 KPI
  • 클라이언트 로드맵을 기반으로 주요 이정표를 제공합니다.

프로젝트 관리자

프로젝트 관리자는 다음과 같습니다.

  • 프로젝트 후원사가 제공한 요구 사항(예: 범위, KPI, 성공 기준 및 정의)을 기반으로 전체 프로젝트 전달을 담당합니다.
  • 예산을 정의하고 해당 예산을 바탕으로 프로젝트를 자원을 관리하는 책임입니다.
  • 프로젝트에 관련된 모든 사용자의 주요 통신 점입니다.

아키텍트

솔루션 설계자:

  • 솔루션 및 시스템의 고급 설계를 담당합니다.
  • AEM에 대한 구현 전략을 정의하는 데 도움이 됩니다. 예를 들어, 클러스터된 설치를 구현할지, 콜드 대기 모드를 구현할지 또는 컨텐츠 전달 네트워크(CDN)가 필요한 경우를 들 수 있습니다.
  • 또한 클라이언트 요구 사항을 기반으로 AEM 솔루션 아키텍처를 정의할 수 있습니다. 여기에는 사용자 역할(관련 권한 포함), 템플릿과 구성 요소 간의 관계 또는 다중 사이트 관리를 사용하는 시기를 포함할 수 있습니다.

비즈니스 애널리스트

비즈니스 애널리스트:

  • 높은 수준의 요구 사항을 수집 및 분석한 다음 이러한 요구 사항을 규격으로 변환해야 합니다.

    • 프로젝트 관리자가 개발을 계획할 때 사용할 수 있도록
    • 디자인 및 개발 과정에서 개발팀이 효율적으로 작업할 수 있습니다.
  • 요구 사항을 분석하기 위해 클라이언트와 긴밀하게 작업합니다. 다음과 일치합니다.

    • 성공의 정의.
    • 성공의 기준.
    • KPI(비즈니스 및 성과 기반 모두).

개발 리드

개발 리드:

  • 프로젝트의 기술적인 전달에 대한 책임이 있습니다.

  • 클라이언트 요구 사항을 준수하는 개발 방법을 선택하는 것은 책임입니다.

  • 개발 전략을 구성합니다.

    • 비즈니스 및 성능 KPI와 일치하는지 확인
    • 성공 기준 및 정의를 고려하다
  • 템플릿과 구성 요소 간의 관계, 제3자 응용 프로그램의 통합 전략 및 모든 특수 기능과 같은 측면을 정의하기 위해(특히 AEM용 개발 전략을 작성할 때) 설계자와 긴밀하게 작동합니다.

품질 리드

품질 리드:

  • 배달의 품질에 책임이 있다.성공 기준 및 클라이언트가 정의한 모든 KPI를 충족하는지 확인
  • 품질 측정 기준을 정의하고 모든 이해 관계자와 연계하여 테스트 계획을 작성하고 이를 실행에 옮길 수 있습니다.
  • 보고서를 만들어 프로젝트 이해 관계자에게 전달합니다.

시스템 엔지니어

시스템 엔지니어:

  • 프로젝트 인프라를 감독하는 책임입니다.

  • 다음 사항에 대한 책임이 있습니다.

    • 내부 개발 및 테스트 환경 설정
    • 클라이언트 시스템과 해당 시스템을 일치시키기 위해
  • 하드웨어 권장 사항을 제공하고, 다양한 구현을 모니터링하고, 라이브되거나 이후에 모두 작업을 지원할 수 있습니다.

보안 리드

보안 리드:

  • 솔루션의 전반적인 보안 개념을 책임지며 클라이언트의 모든 요구 사항 및 정책에 부합되도록 합니다.
  • 하드웨어 기반 보안 개념에 대한 보안 개념, 보안 작업 및 권장 사항을 제공합니다.영역 및 방화벽 등

기타 페르소나

  • 이해 관계자

    • 프로젝트의 성공에 대한 관심(지분)을 갖는 사람(주로 사업부에서)입니다. 그들은 종종 예산에 기여한다.
  • 법적

    • 계약을 협상할 때는 법률적 조언이 필요하다.
  • 트레이닝 전문가

    • 프로젝트의 규모와 특성에 따라 전문 트레이너는 관련 그룹에 대한 교육 세션을 개발하고 제공하는 데 사용할 수 있습니다.
  • 기술 작가

    • 사업의 규모와 성격에 따라 전문 기술 작가가 특정 그룹에 대한 지침과 매뉴얼을 작성하는 데 사용할 수 있습니다.예: 시스템 관리자를 위한 유지 관리 설명서 또는 작성자를 위한 사용 안내서
  • 시스템 관리자

    • 시스템의 지속적인 운영을 책임집니다.
  • 작성자 및 최종 사용자

    • 웹 사이트 컨텐츠를 만들고 유지 관리하기 위해 시스템을 사용하는 사람입니다.

필요한 문서 및 결과물

확인 목록은 각 이정표에 대한 필수 문서결과물​에 대해 설명합니다.

  • 이들 사이에는 1:1의 관계가 없다;예를 들어, 필수 문서 그룹으로 인해 하나의 결과물을 제공할 수 있습니다.
  • 동일한 이정표 동안 한 페르소나에서 산출할 수 있는 문서는 다른 참가자에 대한 필수 문서일 수 있습니다.

필수 문서

결과물을 만들 때 적절한 사람이 필수 문서​를 필요로 합니다.

필수 문서​에 대해 가상 문서는 다음을 나타내야 합니다.

  • Y/N:수신되었는지 여부.
  • 1-3:받은 문서의 품질표시.

결과물

각 이정표에 대해 해당 페르소나는 특정 문서를 전달하는 책임을 지고 따라서 특정 이정표에 대한 책임을 실현합니다.

결과물​에 대해 다음 내용이 표시되어야 합니다.

  • Y/N:완료 여부.

결과물은 종종 현재 또는 이후 이정표에 대해 필수 문서​로 사용됩니다.

배포, 관리, 개발 또는 작성에 대한 우수 사례를 보려면 다음을 참조하십시오.

주요 설명서 영역

이 페이지에서는

Adobe Maker Awards Banner

Time to shine!

Apply now for the 2021 Adobe Experience Maker Awards.

Apply now
Adobe Maker Awards Banner

Time to shine!

Apply now for the 2021 Adobe Experience Maker Awards.

Apply now