Como um desenvolvedor deve rejeitar requisitos impossíveis? [fechadas]

Aqui está o problema que estou enfrentando:

Olá Spark, estou atribuindo a você a tarefa de desenvolver uma estrutura que possa ser usada para muitos aplicativos iOS diferentes. Aqui estão os requisitos:

• Ele deve ser capaz de detectar a espessura do polegar ou dedos sendo usados ​​para manipular a interface do usuário.
• Com essas informações, todos os elementos da interface do usuário devem ser organizados e dimensionados automaticamente .
• Para um polegar maior, os elementos devem ser organizados mais perto do centro da tela.
• Para um polegar menor, os elementos devem ser organizados mais próximos aos cantos da tela.
• Para um polegar maior, todas as fontes devem ser menores. (Estamos assumindo um adulto neste caso.)
• Para um polegar menor, todas as fontes devem ser maiores. (Estamos assumindo uma pessoa mais jovem neste caso.)

Resumo:

Essa estrutura é necessária para criar interfaces de usuário fáceis de usar programaticamente. A estrutura deve ser desenvolvida de tal maneira que possamos usar para quantos projetos forem necessários, por isso também deve ser muito favorável ao desenvolvedor.

Sou o desenvolvedor que recebeu essa tarefa, portanto, minhas perguntas são as seguintes:

• Como posso explicar que esses requisitos são um pouco ridículos?
• Como posso explicar que seria melhor me concentrar no desenvolvimento de projetos reais?
• Como posso explicar que, mesmo que isso fosse possível, eu não recomendara o desenvolvimento de algo assim?
• Como digo NÃO a este projeto de forma educada, gentil e respeitosa?
• Como posso explicar que, mesmo para um desenvolvedor com 3 anos de experiência, isso pode não ser possível?

Se você receber um conjunto de requisitos que são fisicamente impossíveis de implementar, pois o dispositivo não suporta e não pode suportar a funcionalidade desejada, é necessário explicar isso à pessoa que está criando os requisitos.

Você deve ser respeitoso e explicar por que os requisitos não são possíveis de serem implementados (por exemplo, a tela sensível ao toque não pode distinguir entre polegar, dedo ou caneta. Ela não possui resolução suficiente para detectar a largura do dedo.) - mantenha as coisas reais , apontando para documentação existente, se houver.

Não entre em nenhum tipo de argumento emocional e mantenha-se calmo e profissional. Dizer a alguém que seus requisitos são tolos nunca é uma estratégia vencedora.

Veja se você consegue entender os objetivos reais do recurso - por que ele é visto como um requisito. Isso pode levar a um recurso diferente e melhor que resolverá a necessidade. (obrigado @spoike)

A @ DarkStar33 sugere nos comentários que faça a pesquisa e forneça uma estimativa real de quanto o projeto custará e quanto tempo levará, com a suposição de que o resultado será muito caro e demorado para valer a pena. Estar armado com números e os dados para fazer backup deles certamente pode ajudar o seu caso, embora eu ainda analise as metas de negócios para ver se elas podem ser cumpridas (mesmo parcialmente) de outra maneira.

Esses requisitos não são bobos, estúpidos ou ridículos. Na verdade, esse é um problema muito importante para os usuários de telas sensíveis ao toque, pois as pessoas com dedos maiores têm muita dificuldade em identificar o alvo, o que geralmente não é compreendido pelos dedos pequenos.

No entanto, se você achar esses requisitos impossíveis de implementar porque os sensores do dispositivo não podem medir o tamanho do dedo, basta escrever o seguinte: Infelizmente, os dispositivos atualmente disponíveis não suportam essa funcionalidade

Vou jogar aqui um pouco do Advogado do Diabo e dizer que acho que é tecnicamente possível medir o tamanho do polegar de uma pessoa. O iPhone é um dispositivo multitoque. Para a calibração, você pode instruir o usuário a colocar os polegares ou dois dedos na tela lado a lado e medir a distância entre esses toques.

É claro que isso exigiria testes e experimentação para ver quão viável é minha intuição. Talvez os polegares precisassem ser arrastados pela tela para obter uma melhor leitura.

Dito isto, existem sérios problemas de usabilidade e implementação.

• E se o dispositivo for compartilhado? Quando a calibração acontece?
• Como você pode determinar dinamicamente a posição dos elementos da interface do usuário arbitrariamente em todos os aplicativos criados com a estrutura? Obviamente, cada aplicativo terá uma interface diferente e um layout diferente.
• Uma pesquisa simples dos aplicativos iOS atuais mostra que os bem projetados usam todo o espaço horizontal disponível, e já espaçam elementos de modo que os botões importantes sejam tão grandes quanto possível e posicionados próximo às bordas. A largura total do dispositivo é usada para listas e layout, obviamente.
• Mesmo que fosse possível, qual é a análise de custo / benefício? Quanto seria ganho com esse sistema comparado aos controles padrão da interface do usuário? Não seria mais fácil ter um controle de alternância simples para o tamanho da fonte, como muitos aplicativos já usam?

O que você faz é tratá-lo seriamente e voltar com uma estimativa de quanto tempo levaria para fazer e garantir que a estimativa seja muito alta e muito detalhada para que eles não possam contestar os números altos. Depois de mostrar que não será econômico, eles o deixarão em paz. Certifique-se de apontar que tarefas específicas atualmente não são suportadas pelo hardware e podem ou não ser viáveis. Lembre-se de adicionar custos para qualquer tipo de especialista que você possa precisar para um projeto dessa magnitude.

As pessoas da Apple já pensavam profundamente em todas essas coisas e não criaram uma interface redimensionável, dependendo do tamanho do polegar / dedo.

Como usuário, eu odiaria alvos em movimento sob meus dedos.

Se você está preocupado em ter problemas por receber requisitos impossíveis, a melhor opção é dizer a eles imediatamente que isso é impossível. Quanto mais você permitir que eles criem um plano de negócios em um projeto impossível, maior a probabilidade de culpar você pelo fracasso do projeto.

Acima de tudo, tente não se preocupar com coisas que não são sua culpa, todos nós temos o suficiente para nos preocupar com o que temos a capacidade de controlar. Se alguém o responsabilizar por uma falha desse projeto, isso será injustiça. Você acredita em karma?

Uma maneira de desviar a solicitação não razoável é ajudar o cliente a entender a natureza do problema que está tentando resolver. Por meio de uma técnica de entrevista de planejamento coloquialmente conhecida como " popping the why stack ", você continua perguntando "why" recursivamente (de uma maneira educada e inteligente):

Uma ferramenta importante para impulsionar as comunicações e "ir direto ao ponto" de questões específicas é o que Barrett chama de estourar a pilha "por que". Isso é simplesmente para continuar fazendo a pergunta "por que isso é feito dessa maneira?" sobre os requisitos do projeto. Ele deu um exemplo arquetípico do que a técnica pode descobrir: "Certa vez trabalhei com um cliente em que havia um requisito de que os dados fossem impressos em um estágio específico do processo, então perguntei por quê", disse ele. "A resposta foi que o departamento que recebia os dados precisava digitá-los. Nunca havia ocorrido a eles que os dados pudessem ser transferidos para o aplicativo automaticamente".

O objetivo é chegar ao valor comercial principal do recurso:

• Proteger a receita
• Aumentar receita
• Gerenciar custo
• Aumentar o valor da marca
• Tornar o produto notável
• Forneça mais valor aos seus clientes

(Itens do wiki Pepino )

Se o recurso não se encaixar em uma dessas categorias, pode ajudar o cliente a perceber que há coisas mais importantes para se concentrar ou, por meio desse processo de pensamento, você poderá aconselhá-lo sobre como resolver o problema que elas ' está tentando resolver de uma maneira mais significativa. Geralmente, o problema real está em um nível de abstração mais alto do que o problema que eles solicitaram que você corrija.

Para usar seu exemplo de digitalização de tamanhos de polegar:

Cliente: queremos detectar a espessura do polegar ou dedos sendo usados ​​para manipular a interface do usuário.

Dev: Por que você quer fazer isso?

Cliente: Porque, quando tento tocar nesses botões pequenos, geralmente acerto a coisa errada, e nosso software é usado por muitos trabalhadores da construção civil com mãos grandes como eu. Se eles pudessem calibrar a interface do usuário para o tamanho do dedo, facilitaria o uso.

Dev: a facilidade de uso certamente seria valiosa para o cliente, mas por que eles desejam calibrar a interface do usuário? Se é sabido que as pessoas que usam isso têm grandes mãos, por que não ajustar o design para esse caso de uso?

Cliente: Eu nunca pensei assim, acho que um design mais limpo também funcionaria bem para pessoas com mãos pequenas!

Isenção de responsabilidade - não sei se sua solicitação é possível e, se for possível, você precisa determinar quanto tempo levaria e fornecer esse feedback ao seu gerente. Mas estou escrevendo esta resposta com a suposição de que não é viável, pelo menos usando a estrutura padrão - e estou estendendo minha resposta ao caso mais geral em que você realmente não pode ou não deve fazer algo.

Apenas diga não.

Há muitas respostas do tipo "nunca diga não" neste tópico, que acredito ser uma atitude suave e submissa. Pense dessa maneira: eu sou o especialista técnico dessa equipe e meus outros membros da equipe estão tentando fazer algo que considero inviável, complicado demais e potencialmente impossível. É minha responsabilidade dizer não.

Claro que posso e devo dizer não gentilmente; Eu posso "recomendar fortemente contra isso" enquanto ofereço "investigar se é possível" antes de dizer não. Mas no final vou dizer não, porque esse é o meu trabalho.

Existem muitas analogias para isso

• Meu contador, quero que você coloque meu jantar de Ação de Graças como uma dedução de imposto
• Senhor Chef, gostaria que meu frango fosse deixado no balcão durante a noite e servido cru, por favor.
• Meu advogado, quero processar meus filhos por não arrumar seus quartos
• Sr. mecânico, instale um turbocompressor no meu carro elétrico

Você pode pedir a todas essas pessoas que executem tarefas que eles sabem que são tolas, inúteis, perigosas ou erradas. E você esperaria que todos eles desaconselhassem essas ações e, em última instância, recusassem (pelo menos eu espero que sim). Se algum desses profissionais respondeu 'Hmm, tudo bem, acho que podemos fazer isso' - sem me dar uma direta "Esta é uma má idéia" - então, francamente, eu não gostaria de contratá-los de qualquer maneira.

Seus colegas valorizarão e respeitarão sua honestidade, e você economizará a todos muito tempo e dinheiro se fornecer feedback útil em vez de concordar com algo que sabe que não funcionará.

Não deve ser muito difícil dizer ao seu cliente que você não pode implementar algo que sua plataforma de destino não permite. Mas dê um passo para trás e pergunte a si mesmo: qual é a lógica por trás desses requisitos bastante ridículos? Pelo que sei, eles estão muito preocupados com a facilidade de uso. Em seguida, pergunte a eles, vá um pouco mais fundo até que eles digam o mesmo para você: "queremos uma interface amigável". Depois, guie-os para o que é factível e o que não é. Diga a eles que, se eles querem uma interface de usuário fácil, existem maneiras fáceis (e mais baratas), como permitir que o usuário defina o tamanho da fonte / ícone (presumo que seja possível na IoS). Talvez você possa permitir que o usuário controle o tamanho da fonte / tamanho do ícone e a organização do aplicativo por meio de uma guia de configurações? Isso deve ser mais fácil (e mais preciso!) Do que tentar adivinhar a idade de uma pessoa no tamanho do polegar! A última coisa que seu gerente deseja é um código desnecessário, inchado e difícil de manter que alcança a mesma coisa que o sistema operacional já fornece. Diga ao seu cliente que os usuários preferem controlar o aplicativo em vez de o aplicativo controlá-los de maneiras que possam irritá-los.

Minha resposta seria que eu começaria a examinar algumas dessas tecnologias não testadas e informaria se é possível. Com base nessas descobertas, um potencial plano de desenvolvimento pode ser iniciado.

Eu não acho que você será capaz de distinguir o polegar de outra pessoa, mas poderá obter dimensões suficientes dos dedos para saber quando eles estão usando o polegar. O verdadeiro problema é que, devido ao ângulo do polegar, ele pode não tocar mais espaço na tela do que outros. Ninguém nunca usa um telefone com o polegar e o coloca na tela como se estivesse tirando uma impressão digital.

Deixe a empresa. Descobrir como fazê-lo. Venda por muito mais dinheiro do que você está ganhando agora.

Quando se trata de requisitos, geralmente faço assim: tento estimar quanto tempo levaria para realizar um requisito específico.

No caso de requisitos impossíveis, peça alguns dias ou o tempo que for necessário para descobrir se é possível. No seu caso, a pergunta é: "É possível determinar a espessura do dedo do usuário?"

De fato, essa pergunta é ainda mais complexa: "É possível determinar a espessura do dedo do usuário após o primeiro toque em menos de 200 milissegundos para permitir uma interação imediata?" (substitua primeiro por 2º ou ...; e 200 ms por 300 ms ou o que for ...)

Talvez até responder a essa pergunta leve um mês. Talvez, mesmo que isso seja mais ou menos possível, é necessário um algoritmo super complexo que só funciona bem em 80% dos casos.

Você vê para onde estou indo?

As pessoas costumam fazer suposições erradas sobre as possibilidades porque têm pouca experiência e experiência em relação ao campo em questão. Portanto, você não pode argumentar com intuição, mas precisa de fatos.

Se as outras partes interessadas perceberem que esse recurso levaria 2 anos-homem e exigir que o iPhone 10 chegasse antes de 2014, haverá uma redução rápida dos requisitos.

Isso parece complexo, mas não é impossível; o ponto em que a tela de toque não consegue distinguir entre um polegar, um dedo médio ou uma caneta é discutível; na inicialização (inicialização da sessão, o que for), o usuário é solicitado a colocar um polegar, um dedo médio, etc. para calibrar os tamanhos (fazer algumas médias estatísticas) usando vários movimentos, etc.

Eu consideraria tentar resolver o problema raiz de outra maneira antes de dizer que não pode ser feito.

Por exemplo, se o usuário frequentemente tenta clicar em um botão pequeno e erra, você pode observar a área ao redor do botão e usá-la para recalibrar todos os outros cliques.

Apresentar uma solução criativa como essa é provavelmente o que eles procuram mais do que pedir para você descobrir magicamente a largura de um dedo (o que você pode informar que não está na API).

Ainda pode ser difícil - colocar uma área ao redor dos botões para detectar falhas -, então calcule mais horas.

Não diga não, pois isso machucaria seus sentimentos. Apenas deixe claro que, devido a restrições de tecnologia, 60% das vezes funcionará sempre.

E depois que ele perceber a impraticabilidade e os custos envolvidos em tal empreendimento, sugira uma abordagem mais prática dentro de seu orçamento, como ter uma configuração que permita alterar o tamanho do texto. E os russos levaram um lápis para o espaço.

Tente fazer com que ele indique o problema e os requisitos, e não a solução e o design para projetos futuros.

O que eu gosto de fazer é abordar o problema da perspectiva da equipe. Nesse caso, o gerente de projeto e eu precisamos encontrar uma solução. Também gosto de mostrar que tenho uma mente aberta. Se eu ouvir o que acho que está ouvindo impossibilidades, há uma chance de haver um mal-entendido entre mim e o gerente do projeto. Ou talvez não tenhamos chegado a esse momento.

Depois que decidimos dar um salto e ter uma conversa aberta, acho mais fácil tratar o problema como econômico. Na tecnologia, quase tudo é possível, dada uma quantidade infinita de recursos. Discutindo o que seria necessário fazer, muitas vezes é a maneira mais fácil de respeitosamente "dizer não". E essa seria a maneira de esclarecer possíveis mal-entendidos. Embora, para ser sincero, não estamos dizendo não. E qual é o propósito de dizer não de qualquer maneira. Se o trabalho não vale a pena, não importa se queremos fazer ou não.