차례:
소개
프로젝트 이해 관계자의 요구 사항을 수집하는 것은 종종 이빨을 당기는 것처럼 느껴집니다. 그리고 프로젝트에서 개발을 시작하기 전에 모든 요구 사항을 구체화하기 위해 작업을하지 않으면 테스트 중에 요구 사항으로 캡처해야하는 매우 긴 문제 목록이 생성됩니다. 사용자 스토리 수집, 브레인 스토밍 세션 설정, 프로세스 흐름 다이어그램 등 프로젝트의 일부로 모든 요구 사항을 캡처 할 수 있도록 대화를 유도하는 다양한 방법이 있습니다. 프로젝트 관리자이든 비즈니스 분석가이든이 기사에서는 프로젝트를 올바르게 시작하기 위해 프로젝트 요구 사항을 수집하는 몇 가지 표준 접근 방식을 안내합니다.
사용자 스토리는 종종 요청자의 역할, 원하는 내용, 원하는 이유를 중심으로 구성됩니다.
디자인 모도
사용자 스토리
완전히 새로운 것을 구축하든 기존 애플리케이션을 업데이트하든 상관없이 첫 번째 요구 사항은 항상 사용자 스토리를 통해 포착되어야합니다. 이러한 이야기가 최종 사용자 또는 이해 관계자의 이야기인지 여부는 중요하지 않으며 누구 에게서나 수집 할 수 있습니다. 목표는 무엇을 구축 할 것인지에 대한 기대치와 원하는 방식에 대한 세부 사항을 포착하는 것입니다. 사용자 스토리를 캡처하는 데는 다양한 형식이 있지만 일반적으로 모두 요청자와 관련된 역할, 그 사람이 원하는 것과 원하는 이유를 캡처합니다. 이러한 이야기는 프로젝트 프로세스에서 더욱 구체화되어야합니다.
브레인 스토밍 세션
브레인 스토밍 세션에는 일반적으로 확인 된 모든 이해 관계자와 일부 잠재 최종 사용자가 한 방에 모여 프로젝트 요구 사항에 대한 아이디어를 던졌습니다. 목표는 토론을 계속하고 사람들이 계속 이야기하는 것입니다. 이미 언급 된 요구 사항이나 요구 사항에 대한 해석 사이에 불일치가있는 경우 그룹이 시작될 수 있도록 거기에 배치하십시오. 이러한 세션은 종종 엄청나게 빠르게 진행되기 때문에 대화를 녹음하거나 전담 서기를 두는 것이 가장 좋습니다. 그러면 모든 것을 캡처하는 데 묶이는 것보다 적극적인 참여자가되는 데 집중할 수 있습니다. 이 길을 가면 모든 것이 논의되도록하기 위해 이러한 세션 중 하나 이상을 갖는 것이 드문 일이 아닙니다.
브레인 스토밍 세션은 공개 된 모든 요구 사항을 파악하고 주변에서 대화를 나누는 데 유용하지만 정보의 양을 고려할 때 이러한 회의 중 하나 후에 모든 것을 분류하는 것은 고통 스러울 수 있습니다.
PM 얼라이언스
세션 검토
계속해서 프로젝트 이해 관계자들에게 요구 사항을 검토하도록하고, 그룹이 프로젝트의 모든 요구 사항에 대해 합의에 도달하는 데 걸리는 시간을 과소 평가하지 마십시오. 작은 프로젝트에 대해 논의하는 데 몇 주가 걸리는 것은 드문 일이 아닙니다. 한 가지 접근 방식은 모든 사람이 요구 사항에 대해 구두로 서명 할 때까지 기다린 다음 모든 사람과 함께 백업하기 전에 며칠 동안 기다렸다가 공식 문서에 서명을 받아 다시 살펴 보도록 요청할 수 있습니다. 안전한 편입니다. 또 다른 접근 방식은 비즈니스에서 수행중인 작업에 대한 지식을 가진 다른 사람이 요구 사항을 검토하여 모든 것이 가능한 한 밀폐되어 있는지 확인하는 것입니다.
주간 프로젝트 상태 보고서에 포함 할 내용
프로세스 다이어그램
프로세스 다이어그램은 전체 팀을한데 모아 프로젝트의 일부가 될 식별 된 각 프로세스의 흐름을 안내하는 곳입니다. 이로 인해 이해 관계자는 요청 된 응용 프로그램의 모든 단계에 대해 생각하고, 이전에 아무도 고려하지 않았던 새로운 요구 사항이 종종 드러납니다. 이 세션의 출력은 와이어 프레임을위한 환상적인 입력 역할도합니다.
이유를 계속 물어보세요
요구 사항 대화 중에 왜 강력한 동인이냐고 묻는 질문은 더 이상 그 질문을하는 것이 합리적이지 않을 때까지 구체적이고 명확한 요구 사항이 확실하게 구체화되지 않습니다. 이는 이해 관계자가 초기 요구 사항의 세분화 된 구성 요소를 고려하도록 강요하며, 이는 고통스럽고 시간 소모적 일 수 있습니다. 또한, 때때로 지속적으로 묻는 것은 결국 요구 사항이 될 필요가없는 요구 사항으로 처음에 생각되었던 것을 궁극적으로 드러 낼 수 있습니다.
© 2017 Max Dalton