낮은 마찰 최소 요구 사항 수집 [폐쇄

Question

우리 팀은 어떻게 "제품 소유자"로부터 가능한 한 적은 마찰이지만 가능한 한 사용할 수있는 방법으로 요구 사항을 어떻게 수집 할 수 있습니까?

이제 가이드 라인이 있습니다. 수행 할 수없는 게시물이 없거나 사업이 품질에 관심을 갖는 결정을 내려야한다는 게시물이 없습니다. 내가 일하는 제품은 몇 년 동안 성공한 소규모 그룹입니다. 나는 단지 그들이 노치를 올리도록 도와주고 싶다.

기본적으로 저는 한 제품 소유자가있는 6 명 또는 7 명 팀에 있습니다. 그녀는 훌륭한 일을하지만 몇 가지 다른 역할을 저글링하고 있습니다 (매우 작은 팀에서는 일반적이라고 생각합니다). 일반적으로 요구 사항은 산발적 인 시간 (전자 메일 컨버스, 대면 토론, 회의 등)에 제공됩니다. 그들은 시스템에 입력되지 않았으며 때로는 모든 사람이 필요한 기능을 잊어 버렸기 때문에 릴리스가 누락되거나 릴리스가 다시 밀려 나옵니다.

당신이 비슷한 상황에 있지만 이것을 극복 할 수있는 방법을 찾았다면, 나는 그것을 듣고 싶습니다. 이 상황을 완화하기 위해 코드를 작성하게되어 기쁩니다. 그러나 제품 소유자가 작업을 수행하기 위해 가야 할 웹 사이트가 될 수는 없습니다. 그녀는 매우 바쁘고 우리는 이러한 요구 사항을 수집하기 위해 팀으로 함께 일하는 방법이 필요합니다.

나는 현재 다음과 같은 것을 생각하고 있습니다. 개발자와 팀원은 대면 회의에서 논의 된 요구 사항을 수집하고 Wiki 페이지에서 논의 된 기능에 대한 빠른 메모를 작성합니다. 이 페이지가 업데이트 될 때마다 제품 소유자에게 알림을받은 다음 정확성을 보장 할 책임이됩니다.

장점 : 우리는 기능에 대한 레코드를 가질 것입니다. 단점 : 개발자들은 일반적으로 그렇지 않은 것에 대해 책임을지고 있습니다. 나는 여기서 괜찮아. 이 상황에서 그것은 팀워크라고 생각합니다.

물론 일단 우리 가이 작업을 수행하면, 우리는 제품 소유자가 기능 정확도를 보장하기에 충분한 시간이 없을 것임을 알게 될 것입니다. 궁극적으로 그녀는 과부하가 걸렸고 이것이 사실을 보여줄 수있을 것이라고 생각하지만, 나는 그 사실에 주목할 수 있어야합니다.

그래서 어떤 제안이 있습니까?

추신 그녀의 시간은 극도로 제한되어 있으므로 토론 후 요구 사항을 입력해야한다고 기대하는 것은 불합리한 것으로 간주됩니다. 그녀는 한 번만 토론하고 계속 나아갈 시간이 있습니다.

Answer 1

"제품 소유자"라는 개념은 나에게 모호한 littl이지만, 나는 매우 유사한 상황에서 일하고 있다고 생각합니다.

표면적으로,이 상황에서 우리가하려는 것은 매우 명백하고 간단합니다. 고객이 "읽기 전용 / 대화 전용"모드에 관여하도록 노력합니다. 글쓰기가 없습니다. 최소 독서. 대부분 이야기.

물론 악마는 세부적입니다. 따라서 다음은 우리의 프로세스에 대한 몇 가지 내용입니다 (특정 순서없이).

• 우리는 종종 시작합니다 녹음 문제 설명, 이것은 궁극적 인 요구 사항의 원천입니다. 사실, 때로는 문제 진술은 우리가 처음에 기록하는 모든 것입니다.

  NB : 문제 진술을 요구 사항과 구별하는 것이 중요합니다. 문제 진술은 때때로 일부 요구 사항을 명확하게 암시하지만 일반적으로 단일 문제 진술은 모든 요구 사항을 산출 할 수 있습니다 (각각 고유 한 심각성과 우선 순위). 또한, 때로는 주어진 요구 사항이 여러 문제에 대한 솔루션 (일반적으로 부분적인 솔루션)을 정의합니다.

  문제 진술을 기록하는 주된 이유 중 하나 (그리고 이것은 귀하의 질문과 매우 관련이 있습니다!)는 의미 적으로 그들은 "고객의 피부에 더 가깝고"파생 된 요구 사항보다 더 안정적입니다. 이러한 문제 진술은 개발 팀에 피드백을 제공 할 시간이있을 때마다 고객을 적절한 맥락에 빠뜨리는 것을 훨씬 쉽고 빠르다고 생각합니다.

• 우리는하다 기록 모두 요구 사항 (및 문제 명세서로 백 트랙), 우리는 언제 구현할 것인지에 관계없이. 우선 순위는 요구 사항이 구현되는 순서를 관리합니다. 물론, 그들은 또한 고객이 미완성 된 요구 사항을 검토하는 순서를 적용합니다.

  NB : 모든 요구 사항을 포함하는 단일 지방 문서는 절대적인 No-No입니다! 모든 요구 사항은 버그 보고서와 함께 "문제 추적 데이터베이스"에 배치됩니다. (버그는 우리 책의 특별한 문제 일뿐입니다.)

• 우리는 항상 최선을 다하려고 노력합니다 반복 수를 최소화하십시오 각 요구 사항 (또는 관련 요구 사항 그룹)을 "마무리"하는 데 필요합니다. 이상적으로는 고객은 요구 사항을 한 번만 검토해야합니다.

  첫 번째 리뷰가 불충분 한 것으로 판명 될 때마다 (항상 발생) 문제의 요구 사항은 많은 텍스트 및/또는 삽화를 요구할 정도로 복잡합니다. 고객이 처음부터 모든 것을 다시 읽을 필요가 없는지 확인하십시오.. 모든 중요한 이전 Reviwed 버전이 강조된 이후 변경/추가/삭제.

  문제 또는 요구 사항은 미완성 상태에 남아 있지만 모든 열린 문제 (대부분 고객에게 질문)가 문서에 포함되어 강조 표시됩니다.. 결과적으로 고객이 요구 사항을 검토 할 시간이있을 때마다 회의에 전화하여 팀의 질문을 요청할 필요가 없습니다. 대신 고객은 미완성 된 문서를 먼저 열고, 자신에게 정확히 무엇을 기대하는지 확인한 다음 열린 문제를 해결하기 위해 가장 좋은 방법과 시간 (그에게 가장 좋은 방법과 시간)을 결정할 수 있습니다. 때때로 고객은 이메일을 작성하거나 문제 문서에 직접 의견을 추가하기로 선택합니다.

• 우리는 최선을 다합니다 공식 도메인 어휘를 확립하고 유지합니다 (문서에 흩어져 있어도). 가장 중요한 것은 우리는 실제로 고객이 그 어휘를 고수하도록 강요합니다.

  NB : 이것은 프로세스에서 가장 어려운 부분 중 하나이며 고객은 때때로 "반란"을 시도합니다. 그러나 하루가 끝날 무렵 모든 사람들은 가능한 한 효율적으로 고객과 귀중한 회의를하는 유일한 방법이라는 데 동의합니다. 같은 페이지에 모든 사람을 데려 오기 위해 30 분이 지출 된 1 시간의 회의에 참석 한 적이 있다면 어휘를받는 것에 감사 할 것입니다.

  NB : 가능할 때마다 공식 어휘의 변경 사항은 소프트웨어의 다음 릴리스에 반영됩니다.

• 때로는 주어진 문제가 여러 가지 방법으로 해결 될 수 있으며 고객과상의하지 않으면 올바른 선택이 분명하지 않습니다. 그것은있을 것임을 의미합니다 고객이 선택할 수있는 "요구 사항 메뉴". 우리는 최종 선택된 요구 사항뿐만 아니라 그러한 "메뉴"를 문서화합니다.

  이것은 논란의 여지가 있고 불필요한 오버 헤드처럼 보일 수 있습니다. 그러나이 접근법은 고객이 (보통 몇 주 또는 몇 달이 지났을 때마다) 갑자기 "도대체 왜 우리가 그런 식으로 그렇게하지 않았지만 그렇게하지 않았습니까?"와 같은 질문으로 갑자기 뛰어들 때마다 많은 시간을 절약합니다. 또한 요구 사항 문서의 적절한 구성/형식을 사용하여 "거부 된 지점"을 숨기는 것은 그리 큰 문제가 아닙니다. 지루하지만 가능합니다. :-)

  NB : "요구 사항의 메뉴"를 준비 할 때는 과도하게 사용하지 않는 것이 매우 중요합니다. 너무 많은 선택 또는 너무 많은 선택 중첩 레벨 - 다음 검토에는 실제로 필요한 것보다 훨씬 더 많은 고객의 시간이 필요할 수 있습니다. 말할 필요도없이 정교한 가지에 소비 된 시간은 완전히 낭비 될 수 있습니다. 그렇습니다. 여기서 약간의 균형을 찾기가 어렵습니다 (그것은 항상 앞으로 나아갈 수있는 두 가지 이상의 단계를 생각하고 빠르게 할 수있는 고객의 능력에 크게 의존합니다). 그러나 나는 무엇을 말할 수 있습니까? 당신이 정말로 당신의 일을 잘하고 싶다면, 나는 얼마 후에 당신이 올바른 균형을 찾을 것이라고 확신합니다. :-)

• 우리 고객은 매우 "시각적"사람입니다. 따라서 중요한 사용자 인터페이스 요소에 대해 논의 할 때마다 스크린 모형 (또는 가벼운 프로토 타입조차도 종종 매우 도움이됩니다. 때때로 실시간 보호기!

  NB : 우리는 스크린 모형을합니다 독점적으로 고객에게는 토론을 용이하게하기 위해서만. 그들은 개발자들도 사용될 수 있지만 결코 사용자 인터페이스 사양을 대체하지 않습니다! 종종 서면으로 지정되는 매우 중요한 UI 세부 사항이 있습니다 (현재 - 주로 개발자를위한).

• 우리는 매우 기술적 인 배경을 가진 고객을 가질만큼 운이 좋다. 그래서 우리는 주저하지 않습니다 UML 다이어그램을 토론 원조로 사용하십시오. 모든 종류의 UML 다이어그램 - 고객이 적절한 상황에 빠지고 그곳에 머무르는 데 도움이되는 한.

  물론 요구 사항 수준 UML 다이어그램에 대해 이야기하고 있습니다. 구현 수준에 관한 것이 아닙니다. 기술자조차도 요구 사항 수준 UML 다이어그램을 조만간 파기 시작할 수 있다고 생각합니다. 인내심을 갖고 다이어그램에 무엇을 넣어야하는지 알아야합니다.

분명히, 그러한 프로세스의 비용은 팀의 분석 및 작문 기술과 물론 귀하가 처분 할 수있는 도구에 크게 의존합니다. 그리고 나는 우리의 경우이 과정이 상당히 비싸고 느린 것으로 보인다는 것을 인정해야합니다. 그러나 매우 낮은 버그 속도와 "증기 기능"의 낮은 비율을 고려하여 ... 장기적으로는 매우 좋은 투자를 얻는다 고 생각합니다.

fwiw :에 따르면 Joel의 소프트웨어 제품에 대한 멋진 분류,이 프로젝트는 "내부"프로젝트입니다. 따라서 고객이 처리 할 수있는만큼 민첩 할 여유가 있습니다. :-)

Answer 2

"개발자와 팀원은 직접 대면 회의에서 논의 된 요구 사항을 수집하고 빠른 메모를 작성합니다."

그것으로 시작하십시오. 메모를하지 않는다면 한 번만 변경하십시오. 필기를하다. 나중에 Wiki에 게시하거나 기능 백 로그를 만들거나 Scrum 또는 Bugzilla 등을 사용하여 시작할 수 있습니다.

그러나 먼저 작은 변화를 일으킨다. 물건을 쓰는 것은 당신이하지 않는 일처럼 들리므로, 그냥 그렇게하고 무엇을 개선하고 다음에 할 수 있는지 확인하십시오. 민첩해야합니다. 점진적으로 일합니다.

Answer 3

방의 하마를 조심하고 싶을 수도 있습니다. 가장 높은 유급 사람의 의견이 항상 좋은 것은 아닙니다. 우리는 개발자에게 훌륭한 도구와 지원을 제공하는 데 더 집중하는 경향이있었습니다. 이런 일은 올바른 발전에서 번거 로움을 벗어나 더 빠르고 재미있게됩니다. 그런 다음 개발자는 작업량 측면에서 더 유연하며 늦게 침해 변화에 더 적합합니다.

원 클릭 테스트 및 배포는 몇 가지 좋은 테스트입니다. 모든 개발자가 몇 초 안에 자체 소프트웨어 스택을 실행하고 아이디어를 직접 시도 할 수 있는지 확인하십시오. 그런 다음 개발자는 신속하게 개정을하거나 흥미로운 경로를 줄이면 이러한 경로가 가장 성공적입니다. 그리고 성공했다는 것은 시스템에서 바로 수집 된 실제 메트릭을 기반으로 측정 된 성공을 의미하며 모든 관련자가 쉽게 이용할 수있었습니다. 그런 다음 소유자는 요구 사항보다는 신경 쓰지 않고 정의에 대한 경험이없는 메트릭을 설정할 수 있습니다.

물론 그것은 소유자와 특정 상황에 달려 있지만, 우리는 측정 항목이 요구 사항보다 논의하기가 더 쉽고 개발자도 해석하는 데 능숙하다는 것을 발견했습니다. 일반적인 문제는 고객이 쇼핑 카트를 채우는 데 오랜 시간을 소비하는 것처럼 보이지만 결제를 계속하지 않는다는 것입니다.

1) 마케팅 요구 사항은 체크 아웃 버튼을 더 크고 빨간적으로 만드는 것일 수 있습니다. 2) CEO의 요구 사항은 어쨌든 한 번에 하나의 항목 만 구매하기 때문에 CEO의 요구 사항은 고객을 체크 아웃으로 바꾸는 것일 수 있습니다. 3) UI 디자이너의 요구 사항은 카트 상단에 두 번째 체크 아웃 버튼을 배치하는 것일 수 있습니다. 4) 개발자의 요구 사항은 화면 주변의 마우스 포인터를 따르는 웹 2.0 AJAX 위젯 일 수 있습니다. 누가 맞습니까?

누가 걱정 하는가 ... 고객은 아마도 말도 안되는 배송 비용을보고 도망 쳤을 것입니다. 그러나 문제를 요구 사항 대신 지표로 재정의하고 갑자기 개발자가 관심을 갖게됩니다. 개발자는 버튼의 빨간색 음영에 대해 CMO와 함께 10 라운드를 할 필요가 없습니다. 그는 일주일 내내 자신의 웹 2.0을 가지고 놀 수 있고 월요일 아침에 다른 3 가지 솔루션을 서두르 수 있습니다. 각각은 48 시간 동안 라이브로 배치됩니다. 장바구니-체크 아웃 속도 즉시 측정 및보고됩니다. 그 중 어느 것도 차이를 만들지 못했지만 개발자는 업무를 수행해야하며 비즈니스는 판매하는 엉뚱한 제품과 배송에 대한 가격에 초점을 맞추고 있습니다.

글쎄, 좋아, 그래서 예제가 고안되어있다. 프로젝트가 작고 팀의 경험이 풍부하고 핫 배포가 간단하고 즉각적인 롤백이 제공되며 모든 사람이 기내에서 제공되도록하기 위해 많은 작업이 있습니다. 우리가 가고 싶었던 것은 개발자의 잠재력이 낭비되지 않는 상태이므로 처음부터 성공했을뿐만 아니라 성공에 참여하는 주입니다. 등록하는 동안 클릭 수가 너무 높아서 설계위원회를 통해 실행하는 것과 같은 문제로 시작하여 클릭 수가 실제로 설계 사양에서 증가한 것으로 나타났습니다. 어쨌든 그것은 우리의 경험이었습니다. 그러나 개발자에게만 자유롭게 떠나십시오 클릭 수를 줄입니다 그리고 당신은 실제로 우리가했던 것처럼 특허받은 솔루션으로 끝날 수 있습니다. 개발자가 특허에 관심이있는 것은 아니지만 장점이 없었습니다. 클릭이 없었습니다!