O que fazer quando um cliente tem expectativas irreais? [fechadas]

Estou trabalhando em um projeto nos últimos seis meses no site do cliente, pois eles exigem sigilo de dados e não querem que trabalhemos em nosso próprio escritório.

Quando me mostrei sozinho neste site do cliente, disseram-me que precisava terminar o projeto em dois meses.

Como o cliente não é uma empresa de software e, devido a várias políticas, demorou cerca de 20 a 25 dias apenas para me dar direitos na minha máquina para instalar coisas como Eclipse, Tomcat, etc. Mesmo após o atraso na configuração do ambiente, eles ainda esperavam que eu concluísse o projeto no mesmo período de dois meses.

Eles não me forneceram nenhum documento de requisito, mas, como estou trabalhando no local do cliente, costumávamos nos reunir regularmente para discutir os requisitos.

Após seis meses, o aplicativo ainda não está concluído e todos estão me culpando, mas eles não percebem que adicionamos muito mais recursos do que aqueles discutidos nas primeiras reuniões.

Eu tive que refazer muitas coisas durante esse período, por exemplo, separar um formulário em duas seções; algumas semanas depois, eles me pediram para mesclar as duas formas novamente, pois é confuso e assim por diante.

O escopo do aplicativo está aumentando a cada dia, mas eles ainda acham que é um projeto de dois meses atrasado. Quando eu disse a eles que o escopo aumentou, eles perguntam por que eu não pedi requisitos no começo.

Eu já trabalho 11-12 horas todos os dias e viajo 3-4 horas, e agora eles esperam que eu venha aos sábados também.

Eu tenho que fazer tudo aqui: aceitar requisitos, design, código e teste.

Por favor, informe-me o que fazer nesse caso?

_{Detalhes adicionais: tínhamos uma lista de produtos a serem entregues, mas eles acrescentaram mais algumas coisas, dizendo que também são importantes. Eles também mudaram alguns resultados. Eles nem têm seu servidor UAT, eles testam na minha máquina de desenvolvimento por meio do endereço IP.}

Isso é uma falha do seu gerente . Você, como contratado, não deveria ter sido colocado em uma situação com um prazo tão curto por sua empresa sem um conjunto firme de requisitos, por escrito. Nada disso 'eles adicionaram recursos' depois sem sentido - cada vez que isso aconteceu, eles deveriam ter assinado um cronograma atualizado que você lhes deu .

Seu gerente, já que planeja se encontrar com ele, precisa obter do cliente um conjunto específico de requisitos - o projeto deve executar A, B, C, D e E. E depois disso, está concluído. A assinatura do cliente precisa estar nesse documento, concordando com essa lista. Você deveria ter tido isso desde o começo.

Se o seu gerente não apoiar e apoiar você nisso - e eu não digo isso com muita frequência - comece a procurar outro emprego. Porque você provavelmente acabará sendo o bode expiatório de toda a bagunça. E se você estiver disposto a trabalhar 11 horas por dia e 3 horas de viagem, é evidente que você é uma pessoa muito dedicada e que merece mais.

O importante em tais situações é construir uma trilha de papel CYA. Nada deve ser feito sem que seja escrito, especialmente em um relacionamento comercial complicado. Manter o cronograma inicial, embora precisassem de 20 dias para deixar você trabalhar, é uma grande bandeira vermelha de que isso se tornará complicado.

Você realiza uma reunião em que recursos adicionais são necessários? Anote depois, marque "+ X dias para a programação atual" em cada item e envie para todos os envolvidos. Se você usar apenas o sistema de correio interno do cliente, imprima-o adicionalmente, incluindo a lista de destinatários para :, cc: e bcc: e arquive-o com cuidado. Além disso, como GrandmasterB disse, o cliente deve assinar essas alterações nos requisitos originais.

Se a programação necessária não puder ser mantida, escreva-a. Se ocorrer alguma alteração, escreva-a, incluindo as consequências. E assim por diante.

Isto não é para "Eu te disse." quando a bagunça finalmente atinge a parede - eles não a escutam. Esse é o seu seguro quando o cliente o processa porque ele acha que você não cumpriu o contrato, ou quando sua empresa processa o cliente porque ele nega o pagamento.

Pelo que você descreve, parece que você está participando de um projeto clássico da Marcha da Morte :

No gerenciamento de projetos , uma marcha da morte é um dos vários tipos de projetos patológicos que envolvem uma analogia disfêmica e humor negro às marchas da morte reais, como ser sobrecarregado de trabalho exaustivo e (geralmente e mais especialmente) ser sobrecarregado de trabalho exaustivo por razões mal fundamentadas em um projeto que obviamente está em alto risco de maus resultados (por exemplo, falha do projeto e possivelmente ameaça de danos à reputação pessoal e do grupo) . Assim, o nome "marcha da morte" pode ser aplicado a um projeto que, em última análise, é bem-sucedido, mas envolve um trecho de excesso de trabalho insustentável, ou (talvez com mais frequência) a um projeto que qualquer membro informado e inteligente possa ver está destinado a falhar (ou é muito alto risco de fracasso), mas os membros são obrigados a agir de qualquer maneira por seus superiores ...

O fenômeno é bem conhecido e há muita literatura sobre como proceder - incluindo, é claro, o livro seminal de Edward Yourdon, Death March: O Guia Completo do Desenvolvedor de Software para o Projeto 'Missão Impossível' .

O artigo da Wikipedia citado acima é um bom ponto de partida para buscar mais informações, pesquisas e recomendações para os envolvidos / interessados ​​em projetos de marcha da morte .

Andando no seu lugar, a primeira coisa que consideraria seria passar uma referência ao artigo acima para o meu gerente.

Dessa forma, eles saberiam que estou ciente do que está acontecendo, e possivelmente até os ajudariam a me guiar nos termos da estrutura fornecida para essa noção, como "Veja, nosso estado atual é próximo ao descrito no capítulo Xem Yourdon. fora, junto com o capítulo intimamente relacionado Yetc ... "

No caso (não muito provável) de que o gerente não esteja ciente sobre esse campo de estudo, a referência poderia dar-lhes bastante alimento para ajudar a identificar a situação e decidir como lidar com ela.

Honestamente, se você puder fazer isso, a melhor solução é sair. Situações como essa são tóxicas para você e raramente melhoram com o tempo, por mais que você tente.

Melhor reduzir suas perdas e encontrar um show diferente. Mas reflita sobre sua experiência e siga os conselhos de outras respostas neste tópico.

Isso é sério issue in project management . Parece que você Project Managerdeve trabalhar na lista de entregas e priorizá- las com o cliente.

O mais importante é o seu gerente geral should discusse concorda com o cliente o prazo (incluindo o design e a análise do problema / solução) em suas estimativas.

Os clear estimation of your work loaditens entregues e entregáveis ​​do projeto o aliviarão do estresse, além de adicionar tranqüilidade e confiança ao seu trabalho.

Tente usar a abordagem ágil entregando seus itens no sprint (2-3 semanas) e fazendo UAT (teste de aceitação do usuário) com o cliente. Lembre-se, sempre faça seu planejamento do sprint antes de iniciar o sprint.

Edit: De comentários, é claro que isso é realmente falha do seu gerente de projeto . Não ter um ambiente de teste e / ou desenvolvimento adequado definido para um projeto sério como o seu é um grande buraco para o projectprocesso SDLC.

Embora eu concorde que seja uma falha de gerenciamento, também é uma falha de sua parte. Nesse estágio, será muito difícil de corrigir; portanto, o que você precisa obter disso é como lidar com projetos futuros.

Primeiro, você precisa insistir em um documento de linha de base dos requisitos no início do projeto. Não precisa ser chique ou formal, mas você não pode criar nada com êxito até que o cliente especifique o que é esperado. Se você não tiver isso por escrito, as chances de o cliente ficar satisfeito com o resultado final são de aproximadamente 0%. Então isso é extremamente importante. Também é seu trabalho procurar as ambiguidades deste documento e esclarecê-las o mais rápido possível. Quando você se deparar com um deles e não tiver certeza de como interpretá-lo, não adivinhe o que acha que isso significa, verifique se você e o cliente estão na mesma página sobre o que isso significa. Sim, isso significa mais conversas com as pessoas, mais reuniões e menos codificação. Mas leva muito menos tempo para esclarecer um requisito pouco claro do que codificá-lo errado e depois recodificá-lo. Além disso, muitas vezes você precisa dar a recodificação gratuitamente e isso não é bom para a empresa em que trabalha.

Em seguida, você diz a eles quanto tempo leva para fazer o trabalho e que define o prazo. Você nunca aceita um prazo que se baseia em nada além da quantidade de horas que levará para fazer o trabalho para atender aos requisitos. Se você fizer isso, estará em uma marcha da morte novamente. Mostre a eles como não é possível cumprir o prazo com uma explicação detalhada das horas que levará. Você não pode ajustar 200 horas de tempo de desenvolvimento em uma semana com apenas 1 desenvolvedor, não importa quanto o cliente queira. Nesse momento em que o prazo é inalterável, você pergunta quais itens devem ser movidos para a próxima iteração.

Não esqueça que o tempo de desenvolvimento é apenas uma pequena parte do tempo do projeto ao fazer estimativas de tempo do projeto. Você também deve contabilizar reuniões e comunicações por e-mail / telefone, testes, implantação, documentação, configuração física de servidores, estações de trabalho e software. Além disso, ao planejar o prazo, você só pode assumir 6 horas por dia disponíveis, e não 8. Isso é responsável por férias, luto, tempo de doença, atraso inevitável (como quando você precisou esperar por eles para obter permissões) na rede etc.), treinamento, trabalho não relacionado ao projeto (folhas de ponto, reuniões de RH etc.). Uma das maiores razões pelas quais as pessoas não cumprem seus prazos é que assumem que estarão apenas desenvolvendo e trabalhando 8 horas seguidas todos os dias. Isso simplesmente não é uma suposição realista.

E toda vez que eles adicionam outra peça, você diz a eles quanto tempo levará e quanto o trabalho adicional irá mover o prazo. Você não pede para mudar o prazo, diz a eles que está se movendo devido ao novo requisito. Agora você deve consultar seu gerente para isso, mas é antes de tudo sua responsabilidade garantir que ele saiba sempre que o requisito for alterado e quanto isso será adicionado ao projeto. Verifique se tudo isso está escrito, para que você possa se defender, se necessário.

Em seguida, não se deixe abusar dos dias úteis de 11 horas e fins de semana. Isso é bom em períodos curtos (menos de 1 semana a cada seis meses), mas a longo prazo isso simplesmente não é aceitável. As pessoas cansadas codificam mais devagar e cometem mais erros. Você pode fazer mais com qualidade superior trabalhando regularmente 8 horas do que regularmente 11 horas. e fins de semana.

Eu descobri que os gráficos de Gantt podem ser muito bons nesse tipo de situação. Eles podem ilustrar para os clientes a programação atual e podem ser úteis para ilustrar o efeito de adicionar novos recursos / alterações. Às vezes, dizer a um cliente que o recurso x afetará a entrega em y dias não será registrado com ele. Ao tê-lo claramente em um gráfico, eles podem entender melhor.

Idealmente, isso deve ser feito desde o início do projeto. Pode não ser tão útil explicar os " atrasos " até este ponto, mas pode ajudar no andamento do projeto.

Do Wiki :

Os gráficos de Gantt ilustram as datas de início e término dos elementos do terminal e os elementos de resumo de um projeto.