민첩한 개발에 대한 고객 참여를위한 모범 사례? [닫은

Question

우리는 고객 개발 파트너를 개발 프로세스에 참여시켜야합니다. 우리는 민첩한 방법론을 따르고 있습니다. 일부 고객 파트너는 멀리 떨어져 있고 다른 고객 파트너는 더 가깝습니다. 여행 비용을 최소화해야합니다.

우리의 고객은 의료 서비스를 받고 있으며 바쁘고 비싸며 일정이 어려워지는 경향이 있습니다.

고객 참여를 지원하기 위해 어떤 관행과 기술이 효과가 있었습니까? 우리는 전화, 전화 회의 및 이메일을 사용하고 있습니다. 우리는 위키 기술을 활용하는 것에 대해 궁금하며 다른 사람들에게 효과가있는 것을 듣고 싶습니다.

Answer 1

민첩한 방법에 대한 나의 경험은 주로 데스크톱 응용 프로그램을위한 것입니다. 고객이 멀리 떨어져 있으면 고객 사이트에 엔지니어를 데려 가서 데모 리그를 구성/설치하는 데 시간을 보냈습니다. 엔지니어는 고객과 함께 테스트 및 데모 설정/계획을 통해 고객이 배포 환경의 중요한 측면을 복제하지만 기존 인프라에서 데모 시스템을 격리시켜야 할 환경을 제공합니다 (필요할 때마다 업데이트 할 수 있도록 데모 시스템을 분리합니다. ). 또한 엔지니어는 애플리케이션을 제작으로 옮기기 위해 배포 시스템을 설정하여 현장에 있지 않고 "배포"할 수 있습니다. 당사의 응용 프로그램은 자체 업데이트 (각 릴리스 또는 각 빌드마다)를 사용할 수 있으며 릴리스를 신중하게 로그에 기기로 지적합니다. 모두 오류 및 모든 충돌을 버그 추적기에 버그로 제출하십시오. 이런 식으로 우리는 우리가 무슨 일이 일어나고 있는지 모르더라도 적어도 무엇이 잘못되었는지 알고 있습니다.

고객의 테스트 장비에 표시되는 각 릴리스/빌드에 대해 프로젝트 리드 또는 기본 개발자에 의해 설명 된 (짧은) 스크린 캐스트를 제공하여 새로운 기능을 데모합니다. 릴리스 노트에는 고객이 생각하기를 원하는 장기적인 문제 나 질문이 포함되어 있습니다 (즉, 전화 나 이메일로 즉시 해결할 수없는 문제), 응용 프로그램에는 사용자에게 이러한 메모가 표시됩니다.

마지막으로, 아마도 가장 중요한 것은 고객 및/또는 고객 연락 담당자에게 계정을 제공합니다. 우리의 캘린더 서버 및 해당 계정을 사용하도록 캘린더 앱을 구성하십시오. 그런 다음 두 가지 방법으로 진행됩니다. 고객과 시간 (현장, 전화, 이메일 등)을 예약 할 수 있으며 개발자와 동일한 작업을 수행 할 수 있습니다.

Answer 2

커뮤니케이션 지연을 제외하고 고객이 지구 주변의 동일한 칸막이에 있는지 또는 지구의 중간에 있는지는 중요하지 않습니다. 중요한 요소는 다음과 같습니다. 유효성.

며칠 동안 이메일에 응답하기에는 너무 바빠서 반복이 늦어 지거나 실패하게됩니다.

고객은 Agile에 대한 두 가지 중요한 약속이 있습니다.

1. 적시에 질문에 답할 수 있습니다
2. 반복 중에 마음/우선 순위를 바꾸지 않기 위해

고객 ~ 해야 하다 가용성, 예를 들어 1 시간 응답 시간 또는 24 시간 응답 시간 등에 대한 합리적인 서비스 수준 계약 (SLA)에 최선을 다하면 모든 견적 및 일정을 LAG 요소별로 조정해야합니다. 고객이 커밋하지 않거나 팔로우하지 않으면 반복을 취소하고 다시 계획하여 고객의 약속을 다시 최전선에 가져옵니다. 하다 ~ 아니다 고객이 원하는 것에 대해 "추측".

결론 : 고객의 약속없이 민첩성 작동 안 할 것이다.

Answer 3

한 가지 옵션 : "고객 파트너"사이트에 고객 프록시를 설치하여 고객을 사용할 수있을 때 필요한 정보를 추출 할 수 있습니다. 이러한 프록시가 고객의 견해를 나타낼 수있는 견고한 관계를 구축하도록합니다. 그들의 시간은 모두 당신의 것입니다. 그리고 대답 할 수 없다는 질문이 생길 때 커피 라인에 있어도 고객 파트너에게 액세스 할 수 있습니다.

Answer 4

Agile의 고객의 요점은 개발자와 개방적이고 무료 담론을 갖는 것입니다 (즉, 즉각적인 피드백). 실제 고객이이를 제공 할 수없는 경우이 역할을 수행 할 수있는 중개/프록시가 필요합니다. 당신은 그렇지 않습니다 필요 실제 고객은 고객의 요구를 충족시키기에 충분히 고객의 관심사를 대표 할 수있는 사람이 필요합니다.

Answer 5

몇 가지 아이디어 :

위키를 사용하기로 선택한 경우, 위키 전체의 "최근 변경"목록과 사용자에게 특정한 목록 전체를 지원하는지 확인하십시오. 개발 사람들과 먼 거리가 멀어 질수록 컴퓨터 사용에 대한 은유로 이메일을 가질 가능성이 높습니다. 그들이 언제 볼 수 있는지 즉시 알 수 없다면, 그들은 결코 그것을 탐구하지 않을 것입니다. 또한 문제에 대한주의가 필요하거나 CCS와 같은 변화를 치료할 것임을 신호 할 수있는 방법이 필요합니다.

나는 상호 작용의 비디오 화면 캡처 (나레이션)를 만들고 사용자에게 배포하는 데 큰 신자입니다. 실제 데모와 달리 고객은 방해가 필요하지 않다고 생각하지 않으며, 동일한 상호 작용을 반복해서 다시 전환하고 다시 전환하여 세부 사항에주의를 기울일 수 있습니다.

마지막으로 프로토 타입을 배포하는 경우 프로토 타입 사용 방법을 확인하려면 누군가 (또는 최소한 화면 공유 세션)를 보내야합니다. 맥락 디자인이 효과적입니다. 프로토 타입을 기대하는 방식과 다르게 사용하는 사람들을 의지 할 수 있으며, 문제가 어디에 있는지,보고하지 않더라도 문제가 어디에 있는지 이해해야하는 방법을 이해해야합니다.

Answer 6

당신은 같은 것을 고려 했습니까? logmein.

이를 통해 고객은 이미 애플리케이션을 실행하는 네트워크에서 PC에 로그인하거나 컴퓨터 중 하나에 응용 프로그램을 설치/업데이트 할 수 있습니다.

이는 원격 고객 문제를 해결하고 민첩한 프로세스에서 지속적인 지속적인 고객 피드백 요구 사항을 지원합니다.

기술 지원을 위해 이전 회사를 사용했지만 상황에 맞지 않을 이유가 없습니다.

또한 사용자가 실제로 응용 프로그램을 사용하는 방법을 확인하고 작동하는 것이 무엇인지, 그렇지 않은지 알아내는 좋은 방법입니다.

Answer 7

우선, 제품 관리자 나 제품 소유자가 개발자를 닫으십시오. 이 사람은 고객과의 관계를 관리 할 것입니다.

그런 다음 제품 관리자는 각 반복이 끝날 때 고객에게 제품을 시연하고 개발자가 사용자 스토리를 구현하기 위해 피드백이 필요할 때 고객에게 질문 할 수 있습니다.

고객이 참여할 때 고객으로부터 얻을 수있는 긍정적 인 피드백은 놀랍습니다.

우리는 Wiki를 사용하지 않았으며 대부분의 커뮤니케이션은 이메일, 전화 및 화면 공유 응용 프로그램을 통해 수행됩니다 (우리는 Gotomeeting을 사용하고 있지만 대안이 많이 있습니다).

Answer 8

한 곳에서 모든 사람과 한 번 킥오프를해야 할 것입니다. 대면 시간은 매우 귀중합니다. 여기에는 모든 개발자가 포함됩니다. 일부 Metaplan 질문을 준비 할뿐만 아니라 어울릴 수있는 충분한 시간이 있습니다.

Answer 9

나는 당신이 이미 "모범 사례"를 놓친 고객 참여에 높은 의존성을 가진 민첩한 프로세스의 대부분의 정의에 의해, 현장에서, 그리고 바람직하게는 "정상 내"고객이 항상 존재할 것입니다. 그래서 우리는 "가장 좋은 연습"을 찾고 있다고 생각합니다. :)

현장에서 "프록시 고객"을 소개 할 가능성이 있습니다. 프록시 고객의 가치에 대해 매우 회의적이라는 것을 인정해야합니다. 신호 대 잡음 비율이 높아지고 메시지에 대한 메시지의 잠재력이 높아짐에 따라 일종의 2 속도 및 불필요한 비즈니스 분석가 기능을 믹스에 도입 할 위험이 우려됩니다. 또한 바쁜 실제 고객이 프로세스 참여를 줄일 수있는 위험이 있습니다. 최근에 은퇴했으며 컨설턴트 로서이 역량으로 행동 할 수있는 좋은 도메인 지식을 가진 사람이 있는지 궁금합니다.

원격 고객과의 커뮤니케이션 대역폭은 대면보다 놀랍도록 낮습니다. 다른 국가에서 사용자를 다루기 시작할 때까지 완전히 실현하지 못했습니다. 비디오에서도 손실이 중요합니다.

반복은 얼마나 걸립니까? 반복 계획은 얼마나 어려운가? 더 긴 반복을 위해 가고 더 많은 계획을 덜 자주 수행하거나 반복 길이를 줄이고 더 작지만 더 빈번한 계획 세션으로 이동하는 것이 더 쉬울 수 있습니까? 둘 이상의 고객이 참여합니다

각 반복 끝에 사용 가능한 빌드가 있습니까? 참여하는 사용자가 다음 계획 세션 전에 실습 시간을 가질 시간이 있습니까? 배송으로 자주 참여하는 사용자를 유지하는 것이 좋은 아이디어 인 것처럼 보일 것입니다. 아마도 작은 자주 반복 (일주일? 2 주?)에 대한 입법이있을 것입니다.

위키 아이디어가 효과가있을 수 있습니다. 적합 프레임 워크? 그것은 일종의 통합 수락 테스트/위키로, 원격 고객으로부터 수락 테스트를받는 데 도움이 될 수 있습니다. 또한 일종의 (별도 또는 통합 된) "프로젝트 대시 보드"를 제공 할 것 같아요. 화이트 보드, 큰 가시 차트 등의 포스트트와 같은 것들을 대신하여 사용하십시오. 서비스를 제공 할 수있는 오픈 소스 또는 저비용 옵션이 많이 있습니다. 자신의 간단한 대안을 작성하는 것이 너무 시간이 많이 걸리거나 비용이 많이 들지 않아도됩니다.

무엇보다도 "Agile"은 민첩한 선언. 한 상황에서 "최고"로 간주되는 것은 다른 상황에서는 그렇지 않을 수 있습니다. 원칙을 이해하고 비판적 눈으로 방법을 정기적으로 검토한다면 상황에 대한 모범 사례 응용 프로그램에 충분히 가까울 것입니다.

나는 그것을 한동안 보지 않았지만 저자 목록에 Beck과 Fowler가 있으면 유용한 것이있을 것입니다. 극단적 인 프로그래밍 계획.

Answer 10

이전 직책 @drchrono.com에서 나는 전국 20,000 명의 임상의의 데이터/피드백/반복 요청을 집계했습니다. 이를 수행하는 가장 좋은 방법은 uservoice.com과 같은 사이트를 복음화하는 것입니다. 나는 때때로 50 ~ 100 명의 의사와 함께 "Daily Live Web 데모"를 개최했습니다 (의사가 웹 사이트에서 바로 가입했습니다). 이 데모에서는 현재 제품을 시연하고 사용자 음성을 복음하여 피드백을 개발 팀에 유용한 도구로 유도합니다. 이 모든 것은 원격으로 이루어졌으며 반복 매출 성장이 1,400% 증가했습니다.