요구 사항이 커지고 변경됩니다. 나는 아무도 그것을 주장 할 수 있다고 생각하지 않습니다.

어떻게 수집하고 들어오는 요청을 처리합니다 .

내 경험상 새로운 또는 업데이트 된 요구 사항을 소규모 개발 계획자에게 전달하기위한 필터 역할을하는 단일 또는 매우 작은 고객 그룹이있는 경우 요구 사항을 수집 할 때 도움이됩니다. 어느 쪽이든 누구든지 제안하거나 작성할 수 있지만 배달은 아주 적은 수를 거쳐야합니다. 한 당사자에서 다른 당사자로 교환에 참여하는 사람이 적을수록 좋습니다.

소수의 사람들을 통해 걸러내는 목적은 표면에서 중복되거나 중요하지 않은 것처럼 보일지라도 다른 사람들이 쏟은 노력과 정보를 버리지 않거나 줄이는 것이 아니라 실패 지점, 즉 정보의 손실 또는 잘못 처리를 제한하는 것입니다. 캡슐화 및 인터페이스의 목적과 유사한 원칙을 따릅니다. 개인 데이터를 보호하고 유사한 요청을 처리하기위한 공통 프로토콜을 설정합니다. 다시 한 번 말씀 드리겠습니다. 중복 제출은 괜찮습니다. 기획자로서, 그들이 말하거나 제안하는 것이 중요하다는 것을 말해줍니다. 모든 것을 저장하거나 기록하십시오.

요구 사항을 추적하고 구성하는 방법

단기적으로는 기술이 부족하다

화이트 보드, 스티커, 포스터 보드 등 들어오는 요구 사항을 구성하고 추적하는 데 효과적 일 수있는 최첨단 솔루션이 있습니다. 이는 단기 계획에 유용 할 수 있습니다. 그것들은 눈에 잘 띄고 자유 형식 표기법을 수용하며 쉽게 재구성 할 수 있습니다.

장기적으로는 검색 가능하고 정렬 가능하며 링크 가능한 소프트웨어 도구를 사용하십시오.

더 긴 범위의 노력을 위해서는 어떤 종류의 소프트웨어가 유용 할 것입니다. 문, Clearcase / Clearquest 등 많은 요구 사항 관리 도구가 있습니다. 고도로 전문화 된 도구는 자신이하는 일에 능숙하지만 종종 과도합니다. 때로는 평범한 오래된 스프레드 시트조차도 충분하지 않습니다. 나는 개인적 으로이 문제를 해결하는 데 일반적인 문제 추적 시스템이 상당히 유용하다는 것을 알았습니다. 지금 당장 내가 좋아하는 것은 레드 마인이지만 다른 사람들도 괜찮을 것입니다.

이슈 추적 시스템을 사용하면 허용하도록 선택한 모든 사람이 ‘새로운 이슈’또는 요구 사항을 생성하고 포함 할 수있는 세부 정보를 추가 할 수 있습니다. 그들은 문제를보고 문제에 대한 조치를 취할 수 있습니다. 다시 분류하고, 우선 순위를 조정하고, 본문을 다시 작성하고, 보충 정보를 첨부하고, 다른 ‘문제’와 연관 시키거나, 상위 기능 또는 ‘사용 사례’또는 스토리 또는 시스템에 적합한 용어, 광고 구역으로 승격 할 수 있습니다. 즉, 문제를 통해 추적 가능하고 정렬 가능하며 우선 순위가 지정된 기록 인식 관련 요구 사항 목록을 작성하기 위해 많은 작업을 수행 할 수 있습니다. 또한, 툴이 내가 필요로하거나 원치 않는 것이 아니라면 즉시 구성 가능하고 오픈 소스로 구성 할 수 있으며 프로세스의 요구에 더 잘 맞도록 쉽게 변경할 수 있습니다.

도구에 대한 마지막 참고 사항으로, 내가 이야기 한 일부 사람들은 변경 관리 및 버전 관리 시스템에서 일반 텍스트 파일을 사용하여 많은 성공을 거두었습니다. 그들은 분명히 역사적 버전의 이점을 얻습니다. 또한 기본 운영 체제 및 보충 도구를 사용하여 요구 사항을 찾고 연결하고 카탈로그 화합니다. 그들은 구조화되고 관련된 메타 정보를 많이 추가 할 수는 없지만, 필요하다고 느끼지 않으며 그들의 노력으로 충분한 가치를 추가하지 못합니다. 그럴 수도 있고 아닐 수도 있습니다. 장점은 개발 스택에서 관리 및 유지 관리해야 할 소프트웨어가 적다는 것입니다.

계약 후 수상 / 후 프로젝트 개발 시작 요구 사항

문제의 마지막 측면은 노력이 시작된 후 요구 사항을 관리하는 방법입니다. 나는 이것에 대해 두 가지 주요한 생각이 있다고 생각하고, 그것을 처리하는 방법의 일부는 고객과의 관계의 성격에 달려 있습니다. 첫 번째로, 고정 된 가격으로 계약을 체결 한 경우 계약 상 이후에 요구되는 사항을 통합 할 수 있습니다. 이는 노력의 범위를 변경할 수 있으므로 추가 품목이 배달되고 수락 될 때 요율 또는 청구서가 높아질 것입니다. 수락 된 제안에서 동등한 노력이 제거되지 않는 한. 범위가 변경 될 경우 고객이 결과를 이해하고 수용하도록해야합니다. 그렇지 않으면 지연된 제출 내용을 표로 작성해야합니다.

둘째, 계약이 수여 된 후 들어오는 새로운 요구 사항에 대해, 계약은 시간과 물질적 노력에 중점을 두어야합니다 (작업 본문을 완료하는 데 걸리는 시간에 관계없이). 고객은 특정 이동 중에도 포함시켜야한다고 주장합니다. 당신이 말한 모든 것이 끝날 때까지 포함 여부에 관계없이 비용을 지불하게됩니다.

익숙하지 않다면 Kanban 방식과 Agile 방식을보고 싶을 것입니다. 이러한 기술은 장기적인 개발 목표를 놓치지 않고 즉각적인 문제에 초점을 맞출 수 있습니다.

‘가정 (what if)’시나리오로 옵션을 제시하고 고객에게 선택과 결정을 제공

두 경우 모두 ‘가정 (what if)’견적은 고객 및 팀과 협상 할 때 사용하는 좋은 전략입니다. 대체 접근 방식에 대해 동일한 정보를 표시하는 열을 사용하여 작업, 비용 및 계획된 일정을 나란히 비교하십시오. 매우 유사한 작업 집합을 기반으로 다른 추정치를 구성 할 수 있으므로 Microsoft Project가이 작업을 수행하기에 적합한 후보 일 수 있습니다.

그러나 특정 스프레드 시트 또는 포함이 비용 및 일정에 어떤 영향을 미치는지 보여주는 데 기본 스프레드 시트도 종종 효과적입니다. 이 경우의 목록은 아마도 트리가 차이점을 보여줄 수있는 것처럼 효과적 일 것입니다. 이러한 시나리오를 구성하기 위해 선택하는 도구와 방법은 프로젝트와 직원의 규모에 따라 크게 다릅니다 (그러나 MS 프로젝트와 같은 트리플 A 소프트웨어조차도 유용성과 능력의 한계가 있습니다).

내부 작업 항목으로 시나리오를 고려하여 프로젝트 기간 동안 저장하십시오. 그들은 의사 결정 및 협상 과정에서 중요한 시연이었습니다. 당신은 또한 그들을 다시 방문하거나, 만약의 경우에 대한 연속 라운드를 위해 그들을 반복해야 할 수도 있습니다.

가정 시나리오를 준비 할 때 기술 또는 구현 관점 (간단한 용어로)의 장단점에 대한 보충 설명은 한 대안이 왜 그렇게 큰 영향을 미치는지 정당화하는 데 도움이 될 수 있습니다.

답변