빈번한 요구 사항 변경을 처리하는 방법은 무엇입니까?

현재 직장에서 스트레스가 많은 상황 (내 의견으로는)을 다루고 있습니다.

우리는 새로운 프로젝트를 개발하기 시작했고, 몇 가지 요구 사항을 얻었고, 구현 한 다음 '비즈니스 조언자'(비즈니스 요구 사항을 알고 있지만 프로그램을 사용하지 않는 사람)에게 전화 할 수있는 사람에게 보여주었습니다. 그 사람은 고객의 관점에서 응용 프로그램을 평가하고 테스트해야합니다.

'프로세스'모양은 다음과 같습니다.

1. 윈도우 메신저에서 한 두 시간 동안 상사와 저녁에 비즈니스 고문 대화
2. 다음날 나는 그 대화의 사본과 함께 이메일을 받는다. 나는 그 중에서 작업을 선택하고,보고 된 버그를 검사해야합니다 (종종 버그가 아니며 테스트가 잘못되고 과거 시설을 잊어 버립니다)
3. 변경 사항을 구현하고 구현이 수락 된 후 1 ~ 2 주 안에 원치 않는 것으로 나타났습니다 (5 분 동안 소프트웨어를보고 변경 사항을 제안한 일부 잠재 고객과 대화를 나)습니다)-새로운 변경을 수행해야합니다

잘못 이해하지 마십시오. 요구 사항이 변경 될 수 있음을 이해합니다. 나를 화나게하는 것은 직장에서 변화가 얼마나 자주 발생하고 '관리'가 얼마나 쉬운 지에 따라 새로운 요구 사항이 생기거나 때로는 기존 기능에 근본적인 변화가 생기는 것입니다.

마찬가지로 우리는 촉박 한 마감일을 지키고 있으며 소프트웨어를 계속 사용하는 대신 우리는 원을 운영하고 있다는 인상을 받았습니다.

이 상황에 대처하는 방법에 대해 조언을 구하고 있습니까? 이 정상적인 상황이며 나는 그것에 대해 과민 반응을합니까?

가능하다면 이메일로받은 대화를 가져 와서 요구 사항 문서로 바꾸십시오. 수집 할 수있는 작업을 나열하고 우선 순위 인 것으로 인식 한 순서대로 정렬하고 각각에 견적을 할당하십시오. 그런 다음 다음 릴리스에 어떤 기능을 원하는지 묻습니다.

기본적으로 경영진이 구축하려는 대상을 인식하는 피드백 루프를 강제 실행하십시오. 메시지를받을 때까지 자신의 요구 사항 문서를 작성하십시오.

스토리 카드

귀하의 상황이 사용자 사례 를 소개하는 데 적합하다고 생각합니다 . 관리자가 우선 순위를 설정할 수있는 지속적인 대화식 방법을 제공하는 데 실제로 도움이되며 일주일 후 아이디어로 돌아와서이를 실행할 수없는 경우이를 버릴 수도 있습니다.

실제로는 요구 사항이 일상적으로 변경됩니다. 장점은 소프트웨어 제작을 마치고 배송하기 전에 소프트웨어에 대해 알아내는 것입니다. 소프트웨어 직접 사용자의 긴밀한 피드백주기가 있습니다.

여기서 가장 큰 문제는 변경을 관리하는 매우 임시적인 방법 인 것 같습니다. 애자일 / 스크럼은 피드백을 제공하는 "제품 소유자"로 간주하지만 프로세스가 제대로 문서화되지 않고 제대로 고려되지 않았습니다.

다음 단계를 알리기 위해 Scrum 의 모델 과 효과적인 제품 소유자 가 무엇인지에 대한 관점 을보고 싶을 것입니다 .

따라서이 임시 프로세스를 수행하는 대신 "비즈니스 어드바이저"와보다 밀접하고 유용한 관계를 맺고 있으며 논의중인 변경의 결과에 대해 모든 사람이 같은 페이지에있는 세상으로 이동하십시오. .

현재 프로세스는 이러한 사람들이 소비 할 자원과 돈을 보호하지 않고 아이디어를 브레인 스토밍하는 것을 너무 쉽게 만듭니다. 이 모든 기능을 원한다면 "게임에서 스킨"을 얻어야합니다.

대화의 이메일을 가져와 스프레드 시트 일지라도 일종의 기능 / 버그 추적 응용 프로그램에 넣습니다. 새로 추가 한 내용을 비즈니스 고문에게 다시 보내고 각 항목에 대해 사인 오프하거나 수정하도록 요청하십시오. 사인 오프와 함께 우선 순위를 정해야합니다 (먼저 어느 쪽을 원하십니까?).

그들이 승인 한 후, 시험을 위해 언제 품목이 완성 될 지에 대한 일정을 다시 보내고 시험 / 완료 승인을위한 시간을 갖도록하십시오.

이 유형의 문서를 작성하는 것이 프로그래머가 된 이유는 아니지만 이러한 목록을 버릴 수도 있고 어려운 코드를 계속 버릴 수도 있습니다.

뒤로 밀어 담당자는 이러한 요청의 비용이 얼마인지 확인해야합니다.

요구 사항 변경이 항상 나쁜 것은 아닙니다. 중요한 것은 고객을 기억하는 것입니다. 이 경우 귀하의 상사가 귀하의 고객 일 수 있습니다. 이러한 지속적인 요구 사항 변경으로 인해 자신에게 가장 유용한 제품을 생산할 수있는 능력이 제한된다는 사실을 상사에게 알려야합니다. 비즈니스가 변화에 끊임없이 반응함으로써 이익을 얻는 것은 전적으로 가능합니다. 그렇다면, 그것은 그들의 비즈니스 모델이고, 당신은 아무 잘못도하지 않습니다.

요구 사항 변경에 좌절하는 사람들은 종종 각 변경 사항을 얼마나 잘 관리 하느냐에 따라 평가를받습니다. "충분히 처리 된 변경 수"에 대한이 메트릭은 실제 문제의 원인 일 수 있습니다. 상사와 더 나은 통계를 논의 해보십시오. 끊임없이 변화하는 요구 사항에 직면 할 때 끊임없이 변화하는 요구 사항에 적응할 수있는 콘텐츠를 작성하려고 노력합니다. 시뮬레이션을 실행하고 매일 데이터를 분석하는 대신 시뮬레이션을 실행하고 데이터를 더 저렴하게 분석하고 시간이 지남에 따라 보상을 얻는 도구를 작성합니다. 그래도 여전히 미쳤다면 도구를 작성하는 도구를 작성할 수도 있습니다!

프로세스는 반복 반복과 같은 몇 가지 민첩한 원칙을 활용할 수 있습니다. 빠른 속도의 변화에 ​​대해 일주일이 적당하다고 생각합니다. 2 주가 결국 더 잘 작동 할 수 있습니다.

중요한 요구 사항이 충분히 파악되면 Project Owner역할을 수행 하는 사람이 서명 한 후 일주일 동안이를 잠금 상태로 유지하십시오. 바쁠 때 자신에게 충분한 작업을 할당하고 할당량을 알 수있는 권한을 부여하십시오. 즉, 주당 16 포인트의 작업을 생성 할 수 있고 16 포인트의 작업이 있으면 해당 주에 완전히 활용됩니다. (포인트 개념은 민첩한 작업 흐름에서 비롯됩니다)

주중에 변화가 오면 다음과 같은 마법의 단어를 말하십시오.

[이 새로운 기능], [이 새로운 변경 사항], [etc] 등을 수행 할 수 있지만 무엇을 원하지 않습니까?

즉, 당신은 제한된 자원이므로 많은 일을 할 수 있습니다. 새 작업 항목이 들어 오면 제한된 자원이되어 새 항목에 포인트를 할당하고이 새로운 변경 대신 다른 항목을 삭제 / 변경할 수 있습니다. 프로젝트 소유자와 함께 반복 목록의 우선 순위를 다시 지정하면 변경을보다 잘 처리 할 수 ​​있습니다.

요구 사항이 그보다 자주 변경되면 환경에서 더 많은 안정성을 협상해야 할 수도 있습니다.

"요구 사항 변경"이라는 문구는 때때로 IT 담당자가 남용합니다. 당신이 묘사하는 것은 실제로 요구 사항의 변화이지만 이것은 다음 중 하나 이상 때문일 수 있습니다 (귀하의 사건에 대해 충분히 알지 못하므로 다음이 적용될 수도 있고 적용되지 않을 수도 있습니다).

1. 최종 사용자를 최대한 빨리 만족시키고 빠른 진행을 보여 주려는 경영진의 야심.

2. 자세한 분석 부족. 분석가는 왜뿐만 아니라 왜에 대한 질문을해야한다는 것을 기억하십시오. 분석가는 주문을받는 것뿐만 아니라 "솔루션"에 대해 최종 사용자와 "생각"해야합니다.

3. 요구 사항 검증 및 확인을위한 공식적인 프로세스 부족, 승인

4. 잘못된 사람에게 Business Analyst 또는 Systems Analyst 역할과 같이 반드시 교육을받지 않은 하나 이상의 역할을 수행하도록 요청하십시오.

5. 제한된 프로토 타입.

6. IT의 책임이 아닌 경우가 아니라면 신속하게 수행해야한다는 가정 / 공포.

위의 모든 사항을 올바르게 해결하지 않으면 IT와 비즈니스 / 최종 사용자 간의 관계가 스트레스를 받게됩니다. 이것이 위의 사항이 결정적인 것을 의미하지는 않습니다. 귀하의 상황과 유사한 스트레스 상황을 유발하는 다른 요인들이 있지만,이 목록이 귀하에게 도움이 될 것이라고 생각합니다.

몇 가지 방향에서 접근해야한다고 생각합니다.

1. 모든 이해 관계자 (전체 개발 팀 포함)가 비즈니스 고문과 만나고 (오프라인 / 온라인) 도메인, 비전 및 요구 사항을 함께 이해하도록 노력하십시오.

2. 요구 사항 / 사용자 사례를 정식화하여 다음 사항을 평가
   합니다. 우선 순위 (긴급 / 중요성)
   b. 성숙도 (얼마나 잘 정의되어 있는지-이해 관계자 대다수가 이해하고 합의함)
   c. 복잡성 (추정치)
   
   다음에 수행 할 요구 사항 / 사용자를 선택할 때 세 가지 요소를 모두 고려했습니다. 요구 사항의 성숙도가 낮은 경우 모든 이해 관계자에게 연락하여 요구 사항에 대한 추론을 조사하고 요구 사항을보다 잘 정의 (사용 사례 작성 및 / 또는 와이어 프레임 생성 및 제시)하기 전에 조사 미션을 추가하십시오. 올라가서.

3. 각 구현 전에 설계하는 동안 몇 가지 단계를 미리 생각해보십시오. 변경 사항을 수용 할 수있는 유연한 아키텍처를 설계하십시오.

4. SCRUM 또는 Kanban과 같은 민첩한 개발 프로세스를 조정하십시오. 그러면 요구 사항이 변경되는 제품을 개발하기위한 툴킷이 제공됩니다.

또한이 질문이 여기에 맞더라도 중재자가이 질문을 PM.stackexchange.com (플래그 지정)으로 옮기도록 요청하는 것이 좋습니다.

(*) 계약의 이해 관계자 : 비즈니스, 마케팅, 프로젝트 관리, 개발 및 QA.