Como uma pessoa não técnica aprende a escrever uma especificação para pequenos projetos?

Como uma pessoa não técnica aprende a escrever especificações para pequenos projetos?

Um amigo meu está tentando terceirizar algum desenvolvimento em um projeto estatístico.

Em particular, ele trabalha muito no excel e deseja terceirizar a criação de scripts para fazer o que agora faz manualmente.

No entanto, meu amigo é extremamente não técnico. Ele é pobre em escrever especificações técnicas.

Quando ele escreve uma especificação, ela é escrita da maneira que você descreveria como fazer algo no Excel (vá para esta célula e copie o valor para essa célula). Também é excessivamente detalhado e faz exemplos várias vezes. Não tenho certeza se ele descreve adequadamente os casos de canto.

O primeiro projeto que ele terceirizou foi um fracasso. Eu acho que ele descreveu demais alguns detalhes, mas subtraiu casos de canto. Aquele e / ou o codificador que ele contratou não pensou nas caixas de canto e fez as perguntas apropriadas. Não tenho certeza. Eu entrei em contato com ele e levei meia hora para descobrir uma descrição que deveria levar cinco minutos ou menos para ser descrita. Eu escrevi os scripts para ele no final, mas não examinei por que seu processo com o codificador falhou.

Ele me pediu ajuda. No entanto, eu me recuso a me envolver, porque pegar suas especificações e traduzi-las em requisitos claros é 10 vezes mais trabalho do que executar em uma especificação claramente escrita.

Qual é o caminho certo para ele aprender? Existem recursos que ele poderia usar? Existem maneiras de ele aprender com projetos práticos de baixa pressão com codificadores?

A maioria de seus scripts é estatística e orientada ao processamento de dados. por exemplo, pegue esta coluna e execute uma média sobre ela. Remova essas linhas nessas condições. Portanto, o desafio é diferente de especificar um aplicativo da web.

Vejo duas boas abordagens possíveis para esse problema. No entanto, é importante perceber duas coisas. Primeiro, a engenharia de requisitos é um trabalho árduo - transformar uma idéia em uma especificação formal suficiente para criar um sistema exige muito tempo, esforço e prática. Segundo, se você tiver bons requisitos (em qualquer formato, de uma especificação formal a histórias de usuários e casos de uso menos formais), será significativamente mais fácil, mais barato e mais rápido criar o software (e construí-lo logo antes).

Se seu amigo solicitar várias ferramentas de software a serem construídas ou pretender contratá-las, ele deve aprender a escrever requisitos de software, pelo menos no nível dos objetivos de negócios e do conceito de operações. Os dois principais livros sobre engenharia de requisitos de software são de Karl Wiegers - Requisitos de Software (2ª Edição) e Mais sobre Requisitos de Software: Problemas Espinhosos e Conselhos Práticos . Eu esperaria que a maioria das pessoas que ele contrataria gostaria de algum tipo de documento descrevendo o sistema, pelo menos em um nível de objetivos de negócios ou conceito de operações, e esses livros entram nisso. Eles também abordam o como e o porquê de outros aspectos da engenharia de requisitos que eu suspeitaria que um bom desenvolvedor passaria no início do projeto.

A segunda opção seria contratar alguém com experiência em desenvolvimento de software e engenharia de requisitos (e talvez até algum tipo de engenharia de sistemas ou arquitetura de sistema) para entender o espaço do problema e determinar onde as soluções de software são necessárias e onde as soluções de software não seriam benéfico, escreva os documentos e talvez até supervisione ou realize o esforço de desenvolvimento. No entanto, isso provavelmente seria mais caro e representaria a contratação de um desenvolvedor de software em período integral por um longo período de tempo para desenvolver não apenas o sistema solicitado, mas também os requisitos e a arquitetura necessários.

Honestamente, não acho que o que seu amigo esteja enfrentando seja incomum para alguém que não entende o processo de desenvolvimento de software. Também não acho que a culpa esteja inteiramente nele também. Se o primeiro projeto de software não tiver bons requisitos, o (s) desenvolvedor (es) para quem foi terceirizado deve ter esclarecido, refinado e documentado os requisitos. Francamente, não tenho certeza de que você é a pessoa certa para se envolver, se você não estiver disposto a dedicar tempo ou esforço para trabalhar com o usuário / cliente não técnico e desenvolver boas especificações técnicas (isso é um papel fundamental de qualquer pessoa que realize engenharia de requisitos em qualquer disciplina de engenharia).

Eu acho que a solução ideal é realmente uma combinação das minhas duas opções. Acho que seu amigo (e talvez você também) deve aprender sobre o que está envolvido na engenharia de requisitos e os benefícios que ter requisitos sólidos pode trazer para um projeto. Você, como desenvolvedor de software, também deve se familiarizar com a engenharia de requisitos e como obter, documentar, analisar e gerenciar requisitos conforme apropriado para projetos de software - é realmente uma habilidade valiosa para quem trabalha em qualquer parte do ciclo de vida do software.

Quando preciso de especificações de um cliente não técnico, geralmente peço que escrevam em linguagem simples o que exatamente eles desejam realizar. Como em "o aplicativo deve fazer de A a B quando pressiono C, mas somente se D". Bônus extra para "porque D significa que ...".

De fato, "pegue esta coluna e passe uma média sobre ela". é um passo na direção certa. Uma explicação melhor seria "A tabela contém isso e aquilo" (se a estrutura for predefinida); "Obtenha uma média de X". Basicamente, a maneira menos técnica possível sem perder os detalhes.

Em outras palavras, descreva a ideia, não a implementação.

Em seguida, um programador atencioso deve ser capaz de entender o real propósito do que ele foi contratado para fazer e escolher os passos certos, fazendo perguntas para qualquer coisa que não seja óbvia.

Se não houver alguém que se importa o suficiente e entende o processo, o projeto falhará em qualquer caso.

Ele pode tentar usar a abordagem de storyboard .

Peça que ele escreva uma lista de coisas ( histórias ) que o aplicativo precisará fazer e, dentro dessa lista, elabore ainda mais a funcionalidade de cada história.

Ele pode usar uma ferramenta como a Asana para detalhar o escopo e a funcionalidade do projeto e até interagir com o desenvolvedor.

Traduzir isso em requisitos claros é 10x mais trabalhos do que executar em uma especificação claramente escrita.

Um homem. Isso também explica o porquê:

o codificador que ele contratou não pensou nas caixas de canto e fez as perguntas apropriadas.

Entender os requisitos é a parte mais difícil (e mais cara) da maioria dos projetos de programação. Quando uma pessoa não técnica grava requisitos, geralmente documenta apenas a solução alternativa que deseja substituir ("abra o Excel, clique na célula B3 ..."). O melhor que eles podem esperar é uma duplicata exata de sua dificuldade atual!

A maneira mais produtiva que conheço para contornar isso é incentivar essa pessoa a escrever Casos de Uso ("use" rima com "loose"). Em vez de escrever requisitos, descreva como o sistema será usado. Isso deixa ao desenvolvedor alguma margem de manobra para sugerir uma solução melhor do que o que o usuário está fazendo agora.

Parece que esse problema é exacerbado pela falta de habilidades de comunicação escrita por parte do seu amigo. Ele / ela precisa colocar o trabalho em comunicação eficaz de suas idéias ou pagar ao programador para extrair as informações delas. Qualquer um dos processos é doloroso e demorado, mas fazer você mesmo é menos caro do que pagar alguém para fazer isso com você.

De qualquer forma, essa é uma dificuldade comum e frustrante em que as pessoas criativas têm uma ideia incompleta ou são incapazes de descrevê-la em menos de um milhão de palavras. Essa pessoa deve tentar encontrar um programador extremamente paciente e perspicaz que esteja disposto a entender o que realmente está tentando fazer e fazer com que isso aconteça.

o codificador que ele contratou não ... fez as perguntas apropriadas

Essa é uma receita para o desastre. Isso e também a expectativa que o programador perguntará. Os programadores gostam de codificar, não de se comunicar, esperando que eles quebrem seus hábitos sem um incentivo, é bastante irrealista.

Se seu amigo deseja fazer o trabalho, é melhor estabelecer um processo que envolve comunicação contínua com o codificador - e é seu amigo que deve desempenhar um papel ativo nisso, não o codificador. "Mostre-me o que é feito toda segunda-feira e configure duas horas para discutir isso toda terça-feira", coisas assim.

• Para uma introdução, forneça a eles algumas visões gerais leves das metodologias iterativas e de desenvolvimento Agile (artigos da Wikipedia o farão), para que eles tenham uma ideia de como deve ser.
   
• Para ajudá-los a entender as falhas do passado, forneça a eles algumas visões gerais leves do Waterfall / Big Design Up Front (aquelas que incluem críticas - novamente, os artigos da Wikipedia o farão) - normalmente fazem um bom trabalho explicando como normalmente é difícil especificar as coisas corretamente na frente.

Na minha experiência, a maneira mais confiável de obter o trabalho do software conforme desejado com clientes não técnicos era comunicar e iterar permanentemente as descrições dos recursos, sem tentar especificá-lo até a morte de uma só vez.

A maioria de seus scripts é estatística e orientada ao processamento de dados. por exemplo, pegue esta coluna e execute uma média sobre ela. Remova essas linhas nessas condições. Portanto, o desafio é diferente de especificar um aplicativo da web.

É diferente - parece muito mais simples do que especificar um aplicativo da web. É um processo lógico. Este é o material mais fácil.

Seu amigo simplesmente precisa anotar as etapas que ele executa quando executa esse processo. Ele pode fazer o que quiser, mas as principais coisas a serem focadas são precisão, concisão e clareza. Não há razão para que isso não possa ser feito puramente em texto como um manuscrito; se beneficiaria de alguma divisão lógica de componentes ou tarefas e provavelmente funcionaria bem como um fluxograma ou diagrama.

Agora, seu amigo deve encontrar um analista / desenvolvedor competente e envolver seus serviços, peça por peça. Ele precisa definir suas expectativas - diariamente ou pelo menos várias vezes por semana, seu amigo deve se encontrar com o desenvolvedor e ver uma demonstração prática do progresso. Seu amigo pagará o desenvolvedor pelo seu tempo durante essas demonstrações, mas valerá a pena garantir que o projeto esteja sendo executado conforme a especificação. Quaisquer alterações nas especificações - ou seja, coisas que seu amigo omitiu - precisam ser negociadas e provavelmente adicionadas ao preço cotado.

Observe que eu disse 'competente' - isso não é o mesmo que 'média', porque há muitos desenvolvedores 'médios' que não são competentes. Se o seu amigo obtiver o codificador mais barato ou encontrar alguém online, ele deverá esperar problemas. Para não sugerir que as pessoas que encontram trabalho on-line não são boas, mas você não contrataria alguém sem uma recomendação.

Seu amigo deve simplesmente encontrar a pessoa certa. Em qualquer projeto de software, são necessários analistas, programadores, administradores de sistema, testadores e gerentes de projeto. Quanto mais essas funções o seu amigo deseja terceirizar, mais habilidoso o provedor será e mais ele deverá pagar.

Desculpe ser o responsável por isso, mas não é tarefa de uma pessoa não técnica aprender a escrever especificações formais. O trabalho do desenvolvedor é entrevistar a pessoa não técnica, tentar destilar o que a pessoa diz a você sobre o que está buscando, determinar o que o cliente realmente deseja (em oposição ao que eles acham que querem, o que nem sempre é a mesma coisa), crie um documento de requisitos relativamente informal (que seja bem estruturado, mas tente evitar jargões que o cliente não entenderá) e revise esse documento com o cliente.

Quando o cliente estiver satisfeito com o documento informal de requisitos, você poderá usá-lo como base para elaborar uma especificação de requisitos mais formal que comece a entrar em mais detalhes técnicos sobre o que é necessário.

Todo esse processo é conhecido como "captura de requisitos" e constitui o primeiro passo no processo de engenharia de software. Na verdade, escrever o software é apenas uma parte relativamente pequena da engenharia de software, fato que infelizmente muitos desenvolvedores de software esquecem. Outra coisa que eles parecem esquecer é que há uma forte necessidade de se comunicar com o cliente e manter um diálogo durante todo o processo para garantir que as coisas continuem no caminho certo.

Quanto à comunicação com pessoas não técnicas, é de vital importância que você evite usar o jargão dos computadores e o desenvolvimento de software ao conversar com elas. Se eles usam termos de jargão de seu próprio campo, é importante entender o que esses termos significam; portanto, convém elaborar um glossário de projeto para obter definições formais para esses termos. Você está trabalhando para eles, afinal, por isso é importante entender de onde eles vêm.

em vez do jargão, você deve tentar usar maneiras não-intimidadoras de se comunicar com seu cliente, documentos escritos em inglês simples são uma ajuda, mas muitas pessoas no negócio de software estão acostumadas a escrever para computadores em vez de humanos e, portanto, podem achar isso difícil. Além disso, os clientes não gostam de ler grandes pilhas de papel, não importa quão clara seja a linguagem deles, portanto, convém recorrer a recursos visuais. Diagramas, wireframes e storyboards são ferramentas úteis aqui.

Em resumo, o ponto principal é que não é tarefa do seu cliente aprender o seu idioma, é seu aprender o idioma dele.