태그 보관물: use-case

use-case

고객으로부터받은 비정형 요구 사항을 관리하고 추정하는 방법 적절한 사용 사례로 결정화 할

프로젝트 입찰 단계에서 많은 시간을 나는 우리의 잠재 고객으로부터 다양한 소스 (이메일, 워드 문서, 엑셀)로부터 매우 구조화되지 않은 형식의 소프트웨어 시스템 요구 사항을받습니다. 일반적으로 고객 측에서 비즈니스 제안에 대한 이러한 “제안 된 솔루션”을 제시하는 많은 “제품 개발”담당자입니다. 이들은 비즈니스 영역의 전문가이지만 많은 경우 솔루션이 적합하지 않습니다.

결과

  • 동일한 요구 사항의 여러 버전
  • 두 가지 요구 사항을 하나로 혼합
  • 나중에 요구 사항의 몇 가지 버전, 함께 결합 된 요구 사항이 다시 분리되어 각각 새로운 추가 사항을 취합니다.

이러한 요구 사항을 어떻게 처리하고 개발을 시작하기 전에 적절한 사용 사례로 분류합니까? 특정 요구 사항 이력을 처음부터 처음부터 적절한 사용 사례로 결정화 할 때까지 추적하기 위해 어떤 도구를 사용할 수 있습니까? 그러한 방식으로 받아 들여진 요구 사항에 대한 작업을 추정하는 것은 요구 사항을 올바르게 이해하고 그에 대한 노력을 정확하게 예측하는 데 실수를하게되는 악몽입니다.

프로젝트가 완료되면 고객은 요구 사항에 대해 더 많은 생각을하고 올바르게 설명 할 수있었습니다. 이 경우에 발생하는 일은 일부 기능이 삭제되고 일부 기능은 완전히 새로운 방향으로 전환됩니다. 이것은 기본적으로 프로젝트가 승리하기 전에 이루어진 일부 작업 항목의 추정치를 무효화 할 수 있습니다. 특정 요구 사항의 트리를 구축 할 수있는 시스템이 있는지와 각 지점의 결과가 어떻게 다른지 알고 싶습니다.

이 활동을보다 관리하기 쉽게 만드는 팁, 도구, 요령이 있습니까? 요구 사항 관리 및 노력 평가보다 경험이 많은 사람으로부터 통찰력을 얻으려고합니다.



답변

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


답변

나는 이것을 반복적 인 과정으로 볼 것이다. 1 단계는 요구 사항을 수집하는 것입니다. 2 단계는 정렬하는 것입니다. 3 단계는 우선 순위를 정하는 것입니다. 4 단계는 노력을 추정하기에 각각 작은 비트로 분할하는 것입니다. 5 단계는이 비트를 글로벌 노력 버킷으로 통합하는 것입니다 (84 명). 6 단계는 노력을 자원에 매핑하는 것입니다 (84 명 / 2 명 = 42 일).

따라서 현재 1 단계와 2 단계 사이에 갇혀 있습니다. 요구 사항이 있지만 필요한 형식이 아닙니다.

동일한 요구 사항의 여러 버전이 있다고 가정하십시오. 이것들은 본질적으로 동일합니까? 그렇다면 가장 명확한 것으로 보이는 것을 선택하여 사용하십시오. 세부 사항이 다양하면 가장 논리적으로 보이는 것을 선택하여 사용하십시오. 그런 다음 요구 사항을 확인하라는 메시지를 클라이언트에게 보냅니다. 요구 사항을 올바르게 충족하려면 앞뒤로 여러 번 이동해야 할 수도 있습니다. 포기하거나 낙담하지 마십시오. 요구 사항이 좋지 않아 많은 프로젝트가 실패했습니다.

Microsoft 프로젝트를 사용하여 변화하는 요구 사항에 맞춰 작업 및 일정을 유지하십시오. 클라이언트가 변경을 요청하면 추가 작업을 지정하고 모델에 연결 한 다음 새 날짜에 대해 알려주십시오. 새로운 개발자를 무작위 간격으로 가져 와서 여유를 잃을 수 있다고 믿지 마십시오. 새로운 자원이 추가 될 때마다 스케줄은 램프 업 시간을 고려해야합니다. 각 프로젝트에주의를 기울이고 배우면이 모델을 올바르게 모델링 할 수 있습니다. Bob이 프로젝트 X를 4 개월 동안 이탈 한 후 보드에 올렸다고 가정 해보십시오. 첫 달에 그는 얼마나 생산적 이었습니까? 셋째?

매주 프로젝트 모델을 다시 방문하여 필요할 때마다 업데이트하십시오. 변경 사항에 대한 기록을 유지하십시오. 이를 통해 향후 더 나은 견적을 제공 할 수 있습니다.

더그


답변