Você deve prometer fornecer um recurso que não tem certeza se é implementável?

Em um artigo da HN , me deparei com os seguintes conselhos:

Sempre diga "sim" ao seu cliente / usuário, mesmo que não tenha certeza. 90% do tempo, você encontrará uma maneira de fazer isso. 10% do tempo, você voltará e se desculpará. Pequeno preço a pagar pelo maior crescimento pessoal

Mas sempre achei que se deveria fazer uma análise de viabilidade antes de fazer qualquer tipo de promessa a um cliente / usuário, para que não sejam enganados a qualquer momento. Em que circunstâncias, então, o conselho acima deve ser aplicável?

Esta é a segunda pergunta em curta sucessão desencadeada por esse artigo.

• Bom programador: eu otimizo o código. Melhor programador: eu estruturo dados. Melhor programador: qual a diferença?
  Há outro nome para isso: otimização prematura.

• Nunca use saídas antecipadas.
  Essa é a regra "ponto único de entrada / ponto único de saída". É uma correção sobre o problema real, que é o fato de sair mais cedo pode deixar uma bagunça. A regra certa é "limpar sua bagunça". Uma regra ainda melhor é usar construções de dados que limpam depois de si mesmas, para que o programador não precise se preocupar em limpar sua bagunça.

• E agora, sempre diga "sim" ao seu cliente / usuário, mesmo que você não tenha certeza. 90% do tempo, você encontrará uma maneira de fazer isso.
  Este também é um conselho incrivelmente ruim.

Às vezes, seu cliente precisa ser informado de que não, ou "em que milênio você deseja isso?" Não prometa algo que destruirá sua arquitetura, que custará muito mais do que o cliente está disposto a gastar ou que você não tem idéia de como alcançá-lo. Você conhece a tecnologia, não o cliente. Se você não sabe como fazê-lo, não diga que pode fazê-lo. Se você não tiver certeza, diga que precisa de tempo para pesquisar se é possível. É melhor ser honesto e evitar problemas.

Os clientes tornam-se rapidamente ex-clientes se você não puder cumprir suas promessas. Uma taxa de falha de 10% pode parecer pequena, mas é em 10% que seus clientes se concentrarão. Às vezes, eles processam quando você falha em cumprir o que prometeu. Você realmente não quer isso. Outras vezes, garantir que você cumpra uma promessa pode levá-lo à falência, à loucura ou à perda de seu cônjuge, porque você trabalha 18 horas por dia. Você também não quer isso.

Pense da seguinte maneira: o que você acha que aconteceria com o setor de aviação se 90% de todos os pousos em aviões fossem bem-sucedidos? Você acha que voltar e se desculpar pelos 10% que travaram resolveria alguma coisa?

Seria melhor dizer "eu acho que isso pode ser feito". ou "Vou verificar e retornar para você". Já tive momentos em que disse não ou opuseram algo. Se o cliente deseja "um aplicativo baseado em navegador que funcione sem nunca estar conectado à Internet e utilize feedback tátil", provavelmente é possível. Mas é caro e seria mais útil discutir quais são as necessidades reais.

O cliente o respeitará se você for honesto. Nos conselhos da pergunta, a pessoa está errada 10% do tempo. Se eu trabalhar com alguém que é rotineiramente errado uma em cada dez vezes, não vou confiar nele. Esse é um histórico horrível.

Prometer a lua e entregar uma pedra é uma espécie de abordagem de vendedores que não deve ser tolerada. Se você não sabe se é possível, pesquise. Ou dê a eles uma cotação sobre a quantidade de tempo que você precisará levar para analisá-la. Dessa forma, você não promete nada que não possa entregar, mas está sendo pago pelo tempo que leva para analisá-lo.

Esta questão foi estudada formalmente e é abordada pelo Código de Ética da IEEE Computer Society / ACM, produzido em conjunto .

2.01 Prestar serviço em suas áreas de competência, sendo honesto e direto sobre quaisquer limitações de sua experiência e educação.

3.04 Assegure-se de que eles estejam qualificados para qualquer projeto no qual trabalhem ou se proponham a trabalhar por uma combinação apropriada de educação, treinamento e experiência.

3.09 Garanta estimativas quantitativas realistas de custo, programação, pessoal, qualidade e resultados em qualquer projeto no qual eles trabalhem ou proponham trabalhar e forneça uma avaliação de incerteza dessas estimativas.

5.05 Garanta estimativas quantitativas realistas de custo, programação, pessoal, qualidade e resultados em qualquer projeto no qual eles trabalhem ou se proponham a trabalhar e forneça uma avaliação da incerteza dessas estimativas.

Certamente, há implicações comerciais e legais em prometer algo que você não pode cumprir. Geralmente, eles vêm do cliente indo a outro lugar, recusando-se a pagar ou processando sua empresa. Se você estiver em parceria com outras pessoas, elas poderão processar por danos se sua peça não for entregue. Ações judiciais podem até vir de concorrentes.

Há uma história dos primeiros dias dos supercomputadores em que Seymour Cray e uma equipe da Control Data Corporation estavam perto de lançar um produto, e outra grande empresa de computadores disse a seus clientes que também estava próximo do lançamento. A mentira custou ao CDC muitos negócios e se transformou em um processo em que a grande empresa não podia mostrar nenhuma evidência credível de suas reivindicações. O resultado foi o que na época era um grande acordo no valor de US $ 80 milhões em 1970 (cerca de US $ 223 milhões em 2012, ajustado pela inflação). Você pode ler sobre isso aqui:

http://en.wikipedia.org/wiki/Control_Data_Corporation#CDC_6600:_defining_supercomputing

Com tempo, recursos e flexibilidade em torno da definição de sucesso, tudo é possível. O exemplo branco da massa x é fácil se você deseja apenas uma precisão superior a 50% e possui a localização geográfica do usuário e um pouco de dados estatísticos.

A primeira questão real na maioria dos projetos não é se algo é possível, mas se é razoável, dado um determinado conjunto de circunstâncias.

O recurso agrega valor suficiente para justificar as despesas da tentativa?

Mesmo que a ideia seja incrível, se exigir um longo período de desenvolvimento ou a aquisição de algum hardware mais exótico, seria melhor que o cliente soubesse disso antecipadamente e, em muitos casos, direcionasse a conversa para objetivos mais razoáveis.

Se alguém é louco o suficiente para lhe dar um cheque em branco e sem prazo, diga-lhe tudo o que é possível, informe-o de que você precisa inventar e distribuir várias das tecnologias envolvidas para alcançar a meta ao longo do caminho.

Por outro lado, ao lidar com clientes razoáveis ​​com recursos razoáveis, às vezes não há nada pior do que dizer ao cliente que algum recurso deve ser cortado depois que você concordou, porque eles já podem ter fugido e gastado tempo / dinheiro / recursos promovendo ou documentá-lo e que 10% pode ter sido a coisa que deixou o projeto mais iluminado em primeiro lugar. Entre nessas situações e você acabou de perder um cliente e, mais do que provavelmente, ganhou uma referência ruim muito verbal em todo o mercado.

Brincando de advogado do diabo

Por terem uma mentalidade analítica, as pessoas técnicas tendem a supor que seu desempenho será julgado principalmente com base em um scorecard de solicitações concluídas x solicitadas, mas, na prática, não é tão simples assim.

Antes mesmo do desenvolvimento, os clientes começam a formar opiniões sobre o desempenho de uma equipe com base em seu nível de confiança e vontade de se comprometer.

Parte da razão para isso é que os clientes podem ter dificuldade em avaliar se a hesitação de um contratado em se comprometer é devido à dificuldade da solicitação ou à falta de capacidade do contratante.

Como não há critérios absolutos para medir a dificuldade de uma solicitação, geralmente o que é mais importante para o cliente é a confiança de que o contratado está dando 100% de esforço, em vez de 90% ou 100% das solicitações serem atendidas.

Suponha que o cliente tenha que escolher entre dois cenários:

Empreiteiro A :

• Confiantes de que podem atender a todos os pedidos
• Resultado: 90% dos pedidos entregues
• O cliente está satisfeito com o esforço da empreiteira
• O cliente percebe que as solicitações incompletas foram devidas a problemas imprevistos, que provavelmente fora do controle dos contratados

Empreiteiro B :

• Compromete-se a atender 90% das solicitações. Não confiantes de que podem entregar os 10% restantes
• Resultado: 90% dos pedidos entregues
• O cliente está desapontado por o contratante não ter tentado concluir os outros 10% de seus pedidos
• O Cliente assume que os 10% de solicitações não concluídas foram devido à falta de esforço ou capacidade do contratado

Nos dois cenários, o mesmo número de solicitações foi entregue; no entanto, o cliente considerou que o Empreiteiro "supercomprometido" estava se esforçando 100% e usou isso para validar que os pedidos restantes eram realmente difíceis, para crédito do Empreiteiro A.

Por outro lado, o cliente sentiu que o Empreiteiro B não estava dando 100% de esforço e sua incapacidade de concluir todas as solicitações foi devido à falta de esforço ou capacidade do Empreiteiro B.

Isenção de responsabilidade: não estou defendendo o comprometimento excessivo como estratégia; isso é apenas uma observação de uma possível situação do mundo real na qual o comprometimento excessivo pode ter resultados positivos.

Você deve dizer a eles para lhe dar tempo para criar uma "solução de pico" .

Uma solução de pico é um pequeno programa que, ao codificá-lo, permite descobrir como fazer, ou mesmo se é possível, algo que está criando incerteza em um projeto.

Por exemplo, suponha que você nunca envie SMS por meio de programação, mas de alguma forma você sabe que é possível. Uma solução de pico seria criar um pequeno programa que envie um SMS. Dessa forma, não é mais uma incerteza e você pode fazer estimativas adicionais de viabilidade.

Aqui está o que a documentação de programação do eXtreme diz:

Crie soluções de pico para descobrir respostas para problemas técnicos ou de design difíceis. Uma solução de pico é um programa muito simples para explorar possíveis soluções. Aumente o pico apenas para resolver o problema que está sendo examinado e ignore todas as outras preocupações. A maioria dos espinhos não é boa o suficiente para manter, então espere jogá-lo fora. O objetivo é reduzir o risco de um problema técnico ou aumentar a confiabilidade da estimativa de uma história de usuário. Quando uma dificuldade técnica ameaça atrasar o desenvolvimento do sistema, coloque um par de desenvolvedores no problema por uma semana ou duas e reduza o risco potencial.

De acordo com minha experiência, quando um usuário solicita algo, você deve solicitar uma especificação detalhada do que o usuário realmente deseja ou precisa. Mais frequentemente, você nunca mais ouvirá sobre a solicitação.