답변.

질문 역사:

비표준 또는 막 형성되는 비즈니스 프로세스의 자동화는 명확하게 규정된 시나리오가 없고 변화가 크기 때문에 오랫동안 어려운 작업으로 여겨졌습니다. 전통적인 시스템 분석 접근법은 항상 적합하지 않으며, 보다 유연한 방법론이 필요합니다.

문제:

이러한 프로세스에서 작업할 때 가장 큰 문제는 그들의 동적 특성입니다: 시작 시 설명이 종종 일부 작업의 본질을 반영하지 않으며, 고객의 요구 사항은 작업 중에 빠르게 변경되거나 수정될 수 있습니다.

해결책:

요구 사항을 올바르게 식별하고 설명하기 위해 반복적인 접근법(Agile, Lean)을 사용하고, 관찰과 빠른 프로토타입을 통해 데이터를 수집하며, 사용자(예: 워크숍을 통해)를 적극적으로 포함시키고, 요구 사항을 user stories 형식으로 기록하며, Confluence, Miro, Figma 등의 생동감 있는 문서로 보완합니다. 접근법의 주요 특징:

• 사용자와 비즈니스 팀으로부터 지속적인 피드백 수집
• 불분명한 시나리오 구체화를 위한 프로토타이핑 및 빠른 MVP 사용
• 요구 사항의 점진적 уточнение: 실행 가능하고 반복 가능한 것만 기록

교묘한 질문들.

불안정한 프로세스 분석의 시작과 끝에서 요구 사항이 동일한가요?

아니요, 분석 결과에 따라 요구 사항이 변경됩니다: 일부는 구식이 되고, 일부는 실제 프로토타입을 적용한 후에야 형식화됩니다.

변화하는 비즈니스 프로세스를 즉시 모두 기록해야 하나요?

아니요, 검증된 작업하는 부분만 기록하고 나머지는 가설로 남기거나 발전하면서 수정해야 합니다.

오직 하나의 요구 사항 기록 수단만 선택해야 하나요?

아니요, 다양한 청중과 단계에 맞춰 여러 채널을 사용하는 것이 중요합니다: 스탠드업 보드, 전자 초안, 프로토타입 등.

일반적인 실수 및 안티 패턴

• 모든 측면을 미리 세부적으로 규명하려는 시도 (워터폴)
• 사용자 피드백 무시하기
• 생생한 예 없이 기정 승인된 문서나 구두 요구 사항만 가지고 작업하기

실생활 예

부정적인 사례:

회사가 아직 완전히 고정되지 않은 프로세스를 자동화하기로 결정했습니다. 분석가는 프로세스를 엄격한 схем에 따라 설명하고 직원들이 말한 모든 것을 기록했습니다. 프로세스가 시작된 후 신속하게 변경되었고, 시스템은 새로운 현실에 맞지 않았습니다.

장점:

• 기존 스키마의 신속한 통합이 수행되었습니다.

단점:

• 프로세스는 부분적으로만 자동화되었고, 대부분의 변경 사항이 반영되지 않아 비싼 수정이 필요했습니다.

긍정적인 사례:

분석가는 안정적인 단계만 부분적으로 기록하고, 최소 기능 세트를 가진 MVP를 구축했으며, 피드백을 수집하고 비즈니스와 함께 요구 사항을 반복적으로 다듬어 변화를 위한 공간을 남겼습니다.

장점:

• 새로운 요구 사항에 대한 빠른 적응, 재작업 비용 최소화

단점:

• 전체 작업 그림을 즉시 얻는 것이 항상 가능한 것은 아닙니다.