Fazendo com que não programadores entendam o processo de desenvolvimento

Ao iniciar um projeto para uma empresa que não é primariamente uma empresa de programação, uma das expectativas é que exista um produto final no final livre de todos os erros e faça tudo o que é necessário imediatamente. No entanto, isso raramente é o caso.

Quais são algumas maneiras de gerenciar expectativas e explicar aos não programadores como o desenvolvimento de software difere de outros tipos de desenvolvimento de produtos?

Quase todo mundo com um computador encontrou o conceito de "bugs" hoje em dia, então você pode começar por aí. "Qual a maneira mais irritante que um aplicativo já falhou com você? Multiplique isso por dez, e você terá a experiência de nossos usuários se não dedicarmos recursos suficientes para testes e manutenção".

E não subestime o valor de estabelecer uma boa relação de trabalho com os não programadores. Se você puder estabelecer que seu julgamento pode ser confiável, eles o levarão a sério quando você tocar o alarme de que X falhará espetacularmente se você não fizer o Y pronto, mesmo que eles não entendam completamente o seu raciocínio.

Uma abordagem que eu achei bem-sucedida é a seguinte:

Todos sabemos que um computador faz apenas e exatamente o que é solicitado a fazer.

A programação é a maneira como dizemos a um computador agora o que devemos fazer mais tarde .

Isso significa que a maneira como seu comportamento se comporta agora se deve às intenções combinadas de todos que escreveram qualquer código em execução na sua máquina. Quando você considera a complexidade do sistema operacional, drivers, ambiente de programação, bibliotecas e assim por diante, é fácil perceber que na maioria dos sistemas deve haver mais de 20 mil pessoas envolvidas e que pode haver mais de 100 mil.

O código escrito por cada pessoa reflete sua própria compreensão, motivação, intenção e capacidade. Dado que a operação sem falhas do sistema exige que todo o código escrito por essas 20 mil pessoas interaja sem erros - que todo o código deva concordar com o significado e a interpretação do comportamento necessário, o fato surpreendente não é que tenhamos erros, mas que temos tão poucos deles.

Na IMO, descobri que a transparência oferecida pelos processos ágeis (por exemplo, Scrum, Crystal etc.) ajuda bastante a mostrar como o desenvolvimento funciona para as partes interessadas médias.

A explicação por metáfora é uma abstração com vazamento, mas aqui estão algumas idéias que geralmente funcionam para mim:

Observe que nenhuma dessas explicações justifica trabalhos mal feitos.

Pense em um programa de computador como uma máquina, onde cada variável é uma parte móvel. Isso faz de um programa trivial uma máquina composta por centenas de partes móveis.

Quando isso falha, volto ao fato de que, embora seja matematicamente possível provar que um programa não possui erros, leva muito tempo e não valerá o esforço.

Por fim, pergunto se a Intel e a Microsoft não conseguem evitar bugs, como elas esperam que façamos isso?

Respondi a uma pergunta semelhante em mais detalhes , mas o essencial é: "A programação é como construir uma fábrica ou uma linha de montagem".

A maneira tradicional de afirmar isso é o Triângulo de Gerenciamento de Projetos: os três critérios concorrentes de escopo, custo e cronograma; normalmente expresso como "barato, rápido, bom - escolha dois".

No final de um processo de design, desenvolvimento e implantação, a expectativa de que um produto é relativamente livre de falhas de design e opera com uma funcionalidade especificada é perfeitamente razoável. A mesma expectativa é completamente irracional em relação a um projeto, processo ou profissão.

Qual profissional baseado em ciências, duro ou mole, não passa por um processo de exploração, formando conceituações imprecisas e imprecisas, seguindo táticas menos que ótimas (ou simplesmente erradas), descobrindo o que funciona por tentativa e erro e repetindo a processar repetidamente até que os recursos acabem ou que seja alcançado um nível suficiente de desempenho?

Nenhum processo está livre de falhas, embora possa se aproximar assintoticamente de níveis mais altos de qualidade.

Isso é verdade para a profissão médica, onde as táticas geralmente envolvem suposições e protocolos, e grande parte da atividade é basicamente depurar uma máquina principalmente de wetware. É o caso da engenharia civil e da arquitetura, nas quais as aplicações de novos materiais de engenharia precisam ser validadas em campo e podem falhar abruptamente após anos de serviço, apesar da estrita adesão aos padrões. É o caso do setor automotivo, onde a idade e as mudanças nas condições operacionais geralmente afetam o desempenho até o ponto de falha, sem culpa dos serviços de engenharia ou reparo aplicados. O desenvolvimento de software não é fundamentalmente diferente dessas profissões em tais aspectos, apenas tem uma maior parte de seu foco envolvido em criar máquinas inovadoras e intencionais.

Se você tiver alguma familiaridade com o desenvolvimento de software hi-rel, como controle de reatores nucleares, comunicações no espaço profundo ou dispositivos de implantes médicos (etc.), poderá explicar como a estrutura de custos e prazos de entrega para esse nível de gerenciamento de controle de qualidade e controle de qualidade podem ser magnitudes maiores do que as empresas comuns podem pagar por seus projetos de software.

Você pode compará-lo com algo que eles possam ver e, se possível, usar todos os dias.

Por exemplo, o automóvel. Os carros começaram com dispositivos muito menos refinados e confiáveis ​​do que temos hoje. Embora os carros sejam fabricados há mais de 100 anos, o software provavelmente tem cerca de metade desse tempo. Os carros estão disponíveis com personalização significativa, alguns incluídos no preço (como a escolha da cor), outros como tamanho do motor, tipo de transmissão, roda / pneu, nível de acabamento são fatores de custo significativos.

Existem muitos drivers de recursos, qualidade e custo para carros e software. Depois, você pode discutir como a tecnologia de software, a disponibilidade de conhecimento, talvez até onde ela é construída, fará uma grande diferença. Ciclos de desenvolvimento apropriados (por exemplo, modelos anuais com pequenas alterações, alterações de carroceria / motor / plataforma a cada três anos) são conduzidos por uma combinação de necessidades do cliente e um processo de design complexo. Alguns produtos começam com aparência pequena e sombria (pense no Honda Accord), mas são aprimorados a cada ano até serem mais bem classificados.

Os carros têm recalls (geralmente muito mais caros que as atualizações de software) e melhorias incrementais na forma de executar alterações em suas listas de peças (pense em correções de bugs), e geralmente precisam de suporte a longo prazo (pense em compatibilidade com versões anteriores / futuras). Grande parte do custo do seu carro vem depois que você o leva para casa. Grande parte do custo do software ocorre após o lançamento inicial do produto, à medida que você atualiza e atualiza os clientes.

Em alguns casos, você pode fazer referência a produtos conhecidos que incluem software ou outros produtos de software. Por exemplo, os telefones têm um ciclo de lançamento e atualizações e métodos para adicionar funcionalidade após a venda inicial para gerar mais receita. Os telefones são uma ótima ilustração da compatibilidade com versões anteriores / anteriores. Demais, e as pessoas não descartam o antigo para comprar um novo. Muito pouco e os clientes ficam desesperados por ter um telefone que não odeiam antes que o contrato termine.

Produtos como Windows, Microsoft Office, navegadores e páginas da Web são todos os softwares que podem ser usados ​​nas discussões. Eles foram atualizados em ciclos anuais ou trienais, mas podem ter atualizações automáticas com mais frequência. Eles têm bugs e falhas de segurança que afetam os clientes em graus variados, mas fazem parte do cenário, apesar dos nossos melhores esforços. Os clientes podem obter correções gratuitas, mas geralmente pagam por aprimoramentos, geralmente como um pacote, às vezes como um módulo individual ou por meio de uma chave de licença.

Líderes da indústria, como Microsoft, Apple, Google e Amazon, todos oferecem clientes relativamente baratos aos usuários. Mas eles têm enormes despesas que permitiram esses produtos. A experiência deles mostra que o software é caro, mas valioso e lucrativo. Eles geralmente comprometem a qualidade, possuem todos os recursos que desejam e entram no mercado quando é o momento certo. Nem todo produto que eles produzem é um sucesso, e às vezes transformam cães em vencedores renomeando, aprimorando o marketing e as vendas ou reduzindo suas perdas e usando o que aprenderam em produtos posteriores.

Talvez tente orientá-los individualmente ou em pequenos grupos, idealmente, nos casos de uso de software que você precisa desenvolver. Conforme eles descrevem os casos de uso, identifique pontos no caso em que coisas diferentes podem acontecer (casos inesperados, mas não irracionais). Comece a enumerá-los, peça alguns esclarecimentos e ilustre todas as decisões e instruções que precisam ser tomadas ou adotadas, e as compensações sendo feitas ao fazê-lo. Continue até eles ficarem perplexos e não conseguirem responder. Faça com que eles entendam que, o que você está fazendo agora com eles, é exatamente o que você faz o dia todo, provavelmente por conta própria, provavelmente com uma direção muito menos clara, tanto para decidir o curso quanto para escrever o código, para centenas ou milhares de pessoas. casos de uso que podem ou não ser definidos por ninguém. E quando houver caso você não tenha pensado em si mesmo, não pode garantir o que o programa fará. Talvez faça a coisa "certa", talvez note. E é isso que é um bug. E é por isso que escrever software leva tempo. Quanto menos tempo você tiver, menos casos você terá a chance de considerar e acomodar, e mais provável que o programa não faça a coisa "certa" em uma circunstância desconhecida.

Custo e tempo.

Tempo

Defina expectativas de que você entregaria X em Y por um período de tempo. Não terá nada mais, nada menos. Diga a eles o que a próxima versão terá em que horas. No início, eles podem se surpreender ao acreditar que a construção de X leva bastante tempo - é aqui que você explica o tempo gasto e as complexidades da construção de um software. Se eles não ficarem surpresos, você estimou muito menos tempo ou eles sabiam melhor do que pensa sobre a criação de software.

Custo

Isto é do livro Code Compete de Steve McConnel (citando de memória, então me perdoe se eu não conseguir transmitir o mesmo efeito) - É fácil para os clientes solicitar novos recursos. Como gerente de produto, você não deve dizer o que o cliente pede. Você deve estimar quanto esforço e custo são necessários para criar esse novo recurso. Eles vão entender lentamente que o novo recurso não vale realmente o dinheiro / tempo ou talvez nem sequer o exijam. Não estou sugerindo que você use essa arma para assustá-los, mas use-a honestamente e isso pode ajudar a levar o ponto para casa.

As metáforas são abstrações com vazamento, mas são um pequeno passo que o leva mais perto da compreensão.

Meu favorito é que a construção de software geralmente é um processo semelhante à arquitetura de uma casa. No entanto, é mais preciso pensar nisso como a criação de um sistema que imprime um projeto arquitetônico personalizado com base em alguns parâmetros e cria um diferente para cada um de seus usuários. Na conversa geek, isso é meta-arquitetônico.

Eu descobri que isso pode realmente ajudar quando você mostra o que significa escrever código. Mostre às partes interessadas a base de código com a qual você está trabalhando. Mesmo quando você escolhe bons nomes de variáveis ​​e métodos, a maioria das pessoas pensa que você está usando algum tipo de magia negra. Talvez eles entendam por que você precisa de mais do que "alguns dias" para implementar um novo recurso para o software deles.