Melhores práticas para o envolvimento do cliente no desenvolvimento ágil? [fechadas]

Question

É preciso envolver os nossos parceiros de desenvolvimento do cliente em nosso processo de desenvolvimento. Estamos mais ou menos seguindo metodologias ágeis. Alguns parceiros clientes são remotas, outros mais perto. Precisamos minimizar os custos de viagem.

Nossos clientes estão em cuidados de saúde e tendem a ser ocupado, caro e difícil de programação.

O que práticas e tecnologias têm trabalhado para o envolvimento do cliente suporte? Estamos usando telefonemas, conferências telefônicas e e-mail. Estamos curiosos sobre alavancar técnicas de wiki e gostaria de ouvir o que funcionou para os outros.

Answer 1

A minha experiência com métodos ágeis é principalmente para aplicações desktop. Quando nossos clientes são remotas, nós gastamos tempo para obter um engenheiro ao local do cliente para configurar / instalar um equipamento de demonstração. O engenheiro trabalha com o cliente em um teste e demonstração setup / plano que irá proporcionar um ambiente que o cliente acredita que replica os aspectos importantes do ambiente de implantação, mas isola o sistema de demonstração da infra-estrutura existente (para que possamos fazer atualizações sempre que precisar ). O engenheiro também configura sistemas de implantação para mover as nossas aplicações em produção, para que possamos "deploy" sem ser no local. Nossos aplicativos pode auto-update (seja para cada versão ou cada build) e nós cuidadosamente instrumento os lançamentos para registrar todas erros e submeter todos os acidentes como bugs para o nosso bug tracker. Desta forma, pelo menos, saber o que deu errado, mesmo se não sabemos o que está acontecendo direito.

Para cada versão / compilação que aparece no equipamento de teste do cliente, nós fornecemos uma (curta) screencast, narrado pelo líder do projeto ou desenvolvedor primário, demonstração-ing quaisquer novos recursos. As notas de lançamento contém quaisquer questões de longo prazo ou perguntas que queremos que o cliente pensa sobre (questões isto é, que não podem ser resolvidos imediatamente por um telefonema ou e-mail), e o aplicativo exibe estas notas para o usuário.

Finalmente, e talvez o mais importante, temos o cliente e / ou de ligação do cliente uma conta no nosso servidor calendário e configurar seu aplicativo de calendário para fazer uso dessa conta. Isso, então, vai nos dois sentidos -. Podemos programar o tempo (no local, telefone, e-mail, etc.) com o cliente e eles podem fazer o mesmo com nossos desenvolvedores

Answer 2

não importa se o cliente está no mesmo cubículo ou do outro lado do planeta, com exceção de atrasos de comunicação -. O fator crítico é disponibilidade

Um cliente que está muito ocupado para responder a seus e-mails para vários dias vai causar a sua iteração se atrasar, ou não

o cliente tem dois compromissos essenciais para ágil:

1. disponível para responder a perguntas em tempo hábil
2. não mudar sua mente / prioridades durante uma iteração

o cliente deve comprometer com um acordo de nível de serviço razoável (SLA) na disponibilidade, por exemplo, tempo de 1 hora de resposta ou tempo de resposta de 24 horas, etc., e você vai precisar de ajustar todas as estimativas e horários pelo fator lag. Se o cliente não vai cometer ou não seguir adiante, cancelar a iteração e re-plano, trazendo comprometimento do cliente para a frente novamente. Faça não apenas "adivinhar" o que você acha que o cliente pode querer.

A linha inferior:. Sem um compromisso com o cliente, ágil não funcionará

Answer 3

Uma opção: Instalar um proxy do cliente no local "parceiro do cliente" que pode extrair a informação que você precisa quando os clientes estão disponíveis. Ter estes proxies construir os relacionamentos sólidos que lhes permitam representar o ponto de vista do cliente. Seu tempo é todo seu. E quando surgem questões que eles não podem responder, eles têm pronto acesso aos seus parceiros clientes -. Mesmo na linha de café

Answer 4

O ponto de todo o cliente em ágil é ter discurso aberto e livre com os desenvolvedores (IE feedback imediato). Se os seus clientes reais não podem fornecer este, então você precisa de um / proxy intermediário que pode preencher esse papel. Você não necessidade real clientes, você só precisa de alguém que possa representar os clientes interesses bem o suficiente para atender às suas necessidades dos clientes.

Answer 5

Apenas algumas ideias:

Se você optar por usar um Wiki, verifique se ele suporta uma lista à escala de todo o wiki "mudanças recentes", e de preferência um que é específico para os usuários. A menos distante das pessoas de desenvolvimento são, maior a probabilidade de ter e-mail como uma metáfora para o seu uso do computador. Se eles não podem dizer imediatamente quando há algo novo para eles para ver, eles nunca vão explorá-lo. Você também precisa de preferência formas de sinal para eles que você precisa de sua atenção às questões, ou eles vão tratar mudanças como CCs.

Eu sou um grande crente na criação de capturas de tela de vídeo de interações (narrados) e distribuí-los aos usuários. Ao contrário de uma demonstração real, os clientes não sentem que precisam interromper, e eles podem voltar atrás e re-assistir a mesma interação mais e mais, prestar atenção aos pequenos detalhes.

Finalmente, se você distribuir protótipos, certifique-se de enviar a alguém (ou pelo menos uma sessão de compartilhamento de tela) para ver como os protótipos são utilizados. projeto Contextual é eficaz. Você pode contar com as pessoas que utilizam o seu protótipo de forma diferente da maneira que você espera, e você tem que entender como eles usá-lo para realmente entender onde as questões são, mesmo se eles não relatá-los.

Answer 6

Você já pensou algo como LogMeIn .

Isso permitiria que clientes, quer log-in para um PC em sua rede já em execução a sua aplicação, ou, alternativamente, permitem instalar / atualizar o aplicativo em um de seus computadores.

Isso resolveria o problema do cliente remoto e também apoiaria a exigência feedback dos clientes contínua em curso no processo ágil.

Eu usei uma empresa anterior para suporte técnico, mas não há nenhuma razão (exceto talvez de custo) que não iria trabalhar para a sua situação.

É também uma ótima maneira de realmente ver como os usuários estão usando seu aplicativo e, portanto, descobrir o que funciona eo que não funciona.

Answer 7

Em primeiro lugar, certifique-se de que você tem um gerente de produto ou de um proprietário do produto perto os desenvolvedores. Essa pessoa vai ser a gestão do relacionamento com o cliente.

Em seguida, o gerente de produto pode demonstrar o produto ao cliente no final de cada iteração e também pedir clientes questão quando o feedback desenvolvedor necessidade de implementar uma história de usuário.

É incrível o feedback positivo que você pode obter de clientes quando você envolvê-los.

Nós não usar um wiki ea maior parte da comunicação é feita via e-mail, telefone, e um aplicativo de compartilhamento de tela (estamos usando GoToMeeting, mas há toneladas de alternativas lá fora).

Answer 8

Você provavelmente deve fazer um pontapé de saída uma vez com todos em um só lugar. Face-a-face tempo é inestimável. Isso inclui todos os desenvolvedores. Prepare algumas perguntas Metaplan, mas também ter tempo suficiente apenas para misturar.

Answer 9

Eu acho que pela maioria das definições de processos ágeis que têm alta dependência do envolvimento do cliente você já perdeu "melhores práticas", o que seria para um no local, e de preferência "in-time" presente ao cliente em todos os momentos. Então, eu suponho que está procurando um "next best-prática". :)

Há a possibilidade de introduzir um "cliente proxy" on-site. Eu tenho que admitir a ser muito cético sobre o valor de um cliente proxy. Estou preocupado com o risco de introduzir algum tipo de de segunda categoria e função analista de negócios de outra forma desnecessária à mistura, com o aumento da relação sinal-ruído e potencial para mensagens truncadas. Ele também traz o risco de permitir que os clientes reais ocupados para reduzir o seu envolvimento no processo, o que é susceptível de conduzir a insatisfação. Gostaria de saber se pode haver alguém com bom conhecimento de domínio que recentemente se aposentou e pode estar disponível para agir nesta capacidade como consultor?

largura de banda de comunicação com os clientes remotos é surpreendentemente menor do que face-a-face, algo que eu não havia percebido até que comecei a lidar com usuários em outro país. Mesmo com o vídeo, a perda é significativa.

Quanto tempo são as suas iterações? Quão difícil é planejar iterações? Poderia ser mais fácil ir para iterações mais longos e obter mais planejamento feito com menos frequência, ou reduzir iteração comprimento e ir para a menor, mas sessões de planejamento mais frequentes? São mais do que um involv cliente

Você tem uma compilação utilizável e disponível no final de cada iteração? Há tempo para os usuários envolvidos ter hands-on tempo antes da próxima sessão de planejamento? usuários mantendo contratado pelo transporte freqüentemente parece na superfície a ser uma boa idéia, que talvez legisla para pequenas iterações freqüentes (uma semana? duas semanas?)

O wiki ideia pode funcionar: você já olhou para o FIT Framework ? É uma espécie de aceitação integrado test / wiki, o que pode ajudar na obtenção de testes de aceitação de clientes remotos. Eu acho que eu também olhar para fornecer algum tipo de (separado ou integrado) "painel do projeto", possivelmente empurrou regularmente para clientes-chave, bem como disponível sob demanda. usá-lo como um substituto para coisas como post-its quadros diante, grandes gráficos visíveis e afins. Há uma série de opções de código aberto ou de baixo custo que podem servir -. Escrever a sua própria necessidade alternativa simples não ser muito demorada ou onerosos, tanto

Acima de tudo, lembre-se que "Agile" é um tipo-de catch-all rótulo para os desenvolvimentos que são realizadas com ênfase nos valores e princípios consagrados na Agile manifesto . O que é considerado "melhor" em uma situação pode não ser tão em outro. Se você entender os princípios e regularmente rever seus métodos com um olhar crítico, então você provavelmente vai estar perto o suficiente para a melhor aplicação prática para a sua situação.

Eu não olhei para ele por algum tempo, mas com Beck e Fowler na lista de autor, deve haver algo de útil em Planejamento eXtreme Programming .

Answer 10

Na minha posição anterior @ drchrono.com I Dados Agregados / feedback / iteração solicitações de 20.000 médicos em todo o país. A melhor maneira de fazer isso é para evangelizar um site como uservoice.com. Eu segurei "diárias demonstrações web ao vivo" com, por vezes, 50 a 100 médicos (médicos inscreveram direita do nosso website). Nestes demos eu iria demonstrar a nossa voz produto e usuário evangelizar atual para conduzir o seu feedback em uma ferramenta útil para a nossa equipe de desenvolvimento. Tudo isso foi feito remotamente e levou a um aumento global de 1.400% no recorrentes crescimento das receitas.