O que fazer com um pedido de cliente estúpido?

Question

I venceu a licitação em um projeto e agora o cliente (que em si é do departamento de TI) quer que eu arquiteto / implementar a solução de uma maneira muito particular. Estou certo de que a aplicação irá falhar assim por problemas de desempenho. E não vai ser facilmente escalável.

Este cliente / usuário em particular não sabe nada sobre a plataforma e linguagem eu vou estar usando (ASP.NET / SQL Server). Seu único conhecimento é em Cobol e tentando fazê-lo entender o meu POV está apenas fazendo-o com raiva.

Ele contactou-me. Ele foi a pessoa que me selecionado como um vencedor na licitação. Ele é quem será aprovar meus cheques. Ele é meu único contato com esta empresa.

Eu não me sinto confortável com o fornecimento de uma solução Eu sei que vai falhar e eu não quero ser conhecido como o programador estúpido que fazê-lo falhar. Eu sei suas reais necessidades e padrões de uso para esta aplicação, porque eu tenho feito projetos para eles no passado.

Por outro lado, fazer isso em seu caminho só vai prolongar o meu contrato mais tempo (ganhos assim, mais financeiros), a fim de resolver os problemas, modificando o código.

Eu deveria demitir-se do projeto sabendo que provavelmente vou estar perdendo esse cliente para sempre?

Ou ...

Devo tomar a pílula e tomar vantagem financeira de um projeto estendida e simplesmente assumir a má fama como um custo?

Answer 1

Você está olhando para isso de uma perspectiva totalmente errado. Este não é um pedido estúpido de um cliente que não sabe nada sobre a tecnologia. É uma restrição de projeto que você acha que introduz risco para o projeto.

Então você faz o que você faz quando você encontrar risco em um projeto:. Defini-lo, avaliá-lo, e recomendar uma estratégia de mitigação

• Definir o risco. Dizendo que irá causar "problemas de desempenho" e "não será facilmente escalável" não está definindo o risco. Você precisa especificar exatamente o que você quer dizer. O que não está indo para executar, e por quê? O que muda em escala vai vai encontrar esses problemas?
• Avaliar o risco. Ok, então você acha que há um problema. Como é que é ruim? Como certa pode ser que esses problemas de desempenho vai realmente acontecer? Qual será o impacto sobre os usuários se eles fazem? Você diz que o programa não pode escalar: é o crescimento em escala que vai expor o defeito de concepção, mesmo nos cartões? Mais importante ainda, como você sabe isso? Aqui é onde tomar o tempo para construir e referência um protótipo pode poupar um monte de argumento sem sentido.
• Recomendar uma estratégia de mitigação. O que é a direito maneira de implementar isso? Por que é o caminho certo? Mais uma vez, como você sabe isso? Mais uma vez, a prototipagem é seu amigo.

Um par de coisas vai sair de fazer este exercício.

Em primeiro lugar, você pode descobrir que enquanto você está certo sobre cada particular, quando você colocá-los todos juntos não importa. Sim, este programa não vai executar bem ou escala bem, mas se nenhum dos seus casos de uso projetadas vão correr para esses problemas, ele poderia facilmente não valer a pena resolvê-los.

Em segundo lugar, há um mundo de diferença entre dizer a alguém "Isto não está indo para executar, eu sei disso" e dizendo-lhe "Eu aferido os casos de uso que esperamos, e parece que esta abordagem vai resultar no tempo de resposta de quatro ou cinco segundo por transação do usuário. "

Em terceiro lugar, se você sabe que condições fará com que o software falhar, e você articular essas preocupações para o cliente, eo cliente diz: "Nós realmente só quer que ele funcione desta maneira", você já descarregado a sua responsabilidade. Se isto falhar, porque os escolhe cliente não para mitigar o risco de ter identificado, ninguém pode apontar para você e dizer que foi culpa do programador.

Acima de tudo, evidência supera parecer . Você enquadrado toda esta questão como um caso de sua opinião contra o cliente de. Essa é uma proposta perdedora. O que você precisa fazer é quadro-a como "aqui é um problema que temos de resolver." E para enquadrar a questão dessa maneira, você tem que demonstrar a existência do problema, e para isso, você precisa de provas.

Em última análise, é o cliente que decide se deve ou não um risco deve ser mitigado, não você. É até você para dar-lhe a melhor informação que puder para apoiar sua decisão. E você precisa deixar claro, sem ser um pau sobre ele, que é a sua decisão.

eu encontrei, em mais de uma ocasião, que um simples e-mail se concentra a atenção perfeitamente:

Eu estive revendo o projeto, e eu acho que há um risco aqui que precisamos discutir. [Abordagem A] é muito sensível ao volume de transações, e eu estou preocupado que nós vamos ter número suficiente de usuários que vamos ter problemas com ele.

Eu corri um pequeno teste usando [Abordagem B], e é muito menos sensível; na minha simples protótipo, eu era capaz de conseguir transações X por segundo fora dele. Isso faz sentido, porque [comparação técnica de como as duas abordagens lidar com as coisas].

Estou especialmente preocupado com isso porque [descrever como programa irá falhar se ele executa mal].

Este parece ser um problema significativo para mim. Se fosse comigo, eu uso [Abordagem B], porque [descrever como esteabordagem irá mitigar o risco].

Mas você está muito mais familiarizado com [Approach A] do que eu sou, e eu vou alegremente adiar a sua orientação sobre este assunto. O que você acha que devemos fazer?

Esta mensagem muito claramente diz: "Se você ignorar o que eu estou dizendo a você, aqui está como o projeto vai falhar, e eu vou ter documentos que comprovam que você me disse para fazê-lo dessa maneira." Também não faz realmente dizer isso.

Answer 2

Eu acho que você vai precisar para se sentar com ele, e fazer algumas perguntas esclarecedoras.

Você vai precisar de ter o motivo pelo qual ele querer tê-lo implementado dessa maneira particular. Você precisa demonstrar que você está querendo para entregar uma solução de trabalho que atenda às necessidades de negócios.

É possível que exista algumas preocupações subjacentes, as questões que precisam ser abordadas, como você disse que ele não pode apenas estar familiarizado com suas tecnologias propostas e precisa de alguma tranquilidade.

Se isso falhar garantir que as coisas são totalmente documentado e assinado por diante.

Answer 3

Opção 1: A pé, você já tem um relacionamento ruim e é improvável para melhorar.

No entanto, não faça isso porque você quer prolongar um contrato, que é na melhor das hipóteses escondidas e, na pior desonesto, mas se você precisar o contrato ...

Opção 2: Peça-lhe para documentar suas escolhas de arquitetura e razões e assiná-las fora como um spec. Adicionar uma cláusula no contrato dizendo que você não garantem desempenho e / ou escalabilidade usando a especificação, ele produziu e, em seguida, implementá-lo seu caminho. Envie-lhe uma apresentação de sua abordagem favorecida e raciocínio.

Se o projeto falhar (ele poderia estar certo), então você sempre pode apontar que você disse isso a ele e ofereceu uma alternativa.

Certifique-se de que você implementar sua arquitetura de boa fé, ou seja, não fazê-lo falhar deliberadamente. Fazer testes iniciais que provam seu ponto e ter certeza que ele sabe que eles estão falhando. Dê-lhe limpar advertências escritas durante todo o ciclo de vida do projeto que está indo fora da pista.

O melhor de sorte. Considerar seriamente a opção 1. Um off-the-record de coração para coração com o cara vale a pena tentar.

Answer 4

É possível criar um pequeno protótipo como aplicativo para provar que ele está errado e você está certo? A conversa é muito mais fácil se você tem a prova sólida.

Answer 5

Eu odeio ser a polícia de atendimento ao cliente, mas falar sobre isso como uma "solicitação do cliente estúpido" é provavelmente uma má idéia a menos que ele realmente é (caso em que você deve ir embora, sem dúvida). Eu acho que um termo melhor seria "o pedido do cliente mal-informado".

Com isso levado em consideração, lembre-se de que seu cliente provavelmente tem uma necessidade genuína e você deve reconhecer que (verbalmente a eles). É apenas disfarçado por sua idéia (mal informados) para uma solução. Sondar um pouco e tentar obter o que eles realmente estão procurando, então, propor uma solução que você acha que seria melhor e explicar por seria melhor. E fazê-lo de uma forma tal que você não está chamando a competência do cliente em causa. Ninguém quer trabalhar com qualquer pessoa que os faz sentir estúpido.

Answer 6

É difícil sugerir medidas específicas a tomar desde que eu não sei os detalhes aqui, mas aqui estão meus pensamentos:

Se você construir o que ele quer (e não o que ele necessidades ) e você sabe que a solução é a pessoa errada, então você é cúmplice na falha de o projeto. Se você sei que não está indo para o trabalho e não escala e você construí-lo de qualquer maneira, então não se surpreenda se você acabar sendo o "bode expiatório" para o fracasso do projeto e não recebem mais dinheiro para fazer certo da próxima vez.

Se o cara está ficando com raiva, que poderia ser, por muitas razões, uma das quais pode ser que ele não entende a tecnologia e que o incomoda. Mas, eu não sei a situação, então quem sabe? Eu, pessoalmente, preferiria pegar o cara irritado e propor a direito solução e insistem na solução certa do que deixar suas emoções conduzir o barco.

Ele pode ser o cliente e ele pode segurar o cheque, mas isso não faz dele inteligente ou direita. Os clientes estão errados o tempo todo, apesar do velho ditado. Agora, você pode abordá-lo da maneira errada ou o caminho certo e ele pode reagir da mesma para ambos. Mas você quer se aproximar dele da maneira certa, independentemente.

Se, no final, ele insiste em que você faz o seu caminho e não pode suportar o seu caminho com nada, mas as afirmações e emoção, eu educadamente afastar do trabalho. O dinheiro não vale a pena, honestamente. Ele pode ficar com raiva de você, mas você pode dormir bem sabendo que você não perdeu dinheiro de sua empresa em uma má solução para o problema.

• Seja honesto.
• Ouça o que ele tem a dizer.
• Não deixe que suas emoções nuvem seu julgamento.
• No final, fazer a coisa certa.

Pelo menos, isso é o que eu faria.

Boa sorte!

Answer 7

Ouça e aprender . Tenha interesse genuíno sobre os prós e contras de seus clientes se aproximam.

Declare sua própria abordagem para o problema de forma que o cliente possa entender certifique-se de profissionais de documentos e contras de sua abordagem, também.

Em seguida, discutir os dois lados para fazer coisas com o cliente, mas não em um 'a sua abordagem é estúpido e eu sou direito' maneira, mas estar genuinamente interessado que beneficia sua abordagem pode trazer .
Se você ver um problema em sua abordagem, pedir-lhe . Mas não de uma forma 'este trabalho não vai', mas em vez disso ser curioso 'como é que esta escala'. Não basta adivinhar a sua ideia, em vez conhecer os fatos e números 'feito desta forma, não vai haver problemas com muito tráfego nestes e estes casos'?

Você pode até aprender alguma coisa. Tente difícil! No final, você pode ter que código-lo em seu caminho, e ele vai ser melhor se você realmente compreender as armadilhas !

Answer 8

Basicamente é só você que pode responder a esta pergunta. Você conhece o seu cliente e sua situação o melhor e se você pode encontrar uma maneira de fazer este trabalho, é a sua chamada.

Pessoalmente, eu iria recusar o projeto. Se eles querem mantê-lo, explicar por que você não pode levar o projeto de acordo com as exigências estabelecidas.

Diga-lhes que se quiserem você para implementar o projeto, em seguida, eles contrataram o experiência, não a experiência de sua cara no o departamento de TI .

Answer 9

Se você não se sentir confortável, em seguida, a pé. Nós estivemos sapato chifres em fornecer uma solução específica para os clientes antes que apesar de nossos melhores desejos e melhores recomendações e isso nos causou nenhum fim do sofrimento no futuro.

Se a sua uma questão financeira e você "necessidade" do negócio, então eu definitivamente aproximar o projeto a partir de um ponto de vista de tempo de boxe.

Diga-lhes o que é realizável em que tipo de cronogramas. Certifique-se que você é pago de forma modular que você bater diferentes marcos. Pelo menos dessa forma, dá-lhe oppurtunity para ir embora no futuro, se torna-se um não-vencedor para você.

Outra opção poderia ser a de mostrar a eles o quanto mais caro seria para fazê-lo seu caminho que o seu.

Answer 10

Se precisar o cliente, ele precisa de você assim (provavelmente mais). Afinal, ele é o único que você selecionou. Ele é o único que precisa de um problema a ser resolvido.

Tome uma posição que você não vai ser ditada por suas instruções em 'como' para fazer o trabalho - o que fazer é, certamente, a sua chamada. É provável que você vai ver alguns derretimento do gelo.

Answer 11

Eu recomendaria tentar algumas táticas misdirection com ele. Deixe que ele saiba o que são as suas preocupações com seus métodos, e oferecer-lhe alguma outra solução que irá atender às suas necessidades e seu. Tente evitar ser agressivo (não dizer que ele está errado), mas dizer que você acha que há uma solução melhor que integra ambas as opções.

Tente praticar "Judô Verbal". Sendo confronto não vai render-lhe quaisquer pontos com ele, e só vai torná-lo mais certeza de que você está sendo difícil. Concordo com ele, construir um relacionamento mais ideias comuns, e em seguida, delicadamente levá-lo para baixo o caminho para a sua solução.

Answer 12

Desenhar um contrato que contém as suas preocupações e que os torna pagar o dinheiro, mesmo em caso de falha devido à má decisão do cliente. Em seguida, torná-los assiná-lo.

Certifique-se de executar o contrato por um advogado experiente, porém, porque é fácil obtê-lo um pouco errado para que um tribunal através de você para fora, se o mau vem a pior e você precisa processar para o dinheiro.

Faça o cliente ciente de que parte no contrato antes de assinar, talvez eles vão reconsiderar.

Ou, em vez de atravessar todo este problema, como já foi sugerido: caução, a pé, ou melhor: correr. Tão rápido quanto você puder. A menos que seja realmente um monte de dinheiro, então ele não vai valer a pena para vender para fora para ele.

(Edit:. Danado, Simon me bater por alguns segundos)

Answer 13

Apenas propõem sua solução e explicar (com a ajuda de apresentações / documentação ) porque é o melhor. Ou até mesmo fazer um protótipo do mesmo.

Seu cliente deve compreender, se você provar isso, que você tem liderança técnica nesse campo, e confiar em você.

Answer 14

Eu fiança no projeto a menos que eu estava morrendo de fome. Como consultor de mim, eu me sinto o único valor eu trago para o cliente é o conhecimento que possuo (e que não o fizerem, ou então eles não estaria me contratando). Para trabalhar em algo que eu "saber" vai falhar violaria Código de Ética do consultor (se houver um).

Gostaria de tentar o meu melhor para convencer o cliente de que o seu caminho é provável que não, e então eu iria tentar o meu melhor para localizar alguém para fazer o trabalho para ele.