Executando verificação de segurança...
1

🤔[Dúvida] Requisitos mínimos para descrição de projeto em site de freelancers

Olá todos! Gostaria da avaliação de qual seria o nível de detalhe mínimo na descrição de um projeto para contratação de freelancers.

Publiquei pela primeira vez um projeto na plataforma Workana e me surpreendi com a quantidade de problemas simples que o desenvolvedor contratado não tratou.

Então, além de comentar sobre a descrição mínima necessária, peço que também avaliem se a descrição que ofereci foi suficiente ou não. Segue o texto:

Descrição do Projeto

Aplicação contendo as seguintes características:

  • Tela de autenticação (frontend) em Next.js com captcha e 2FA com Google Authenticator e token JWT
  • Autenticação da api com jwt
  • middleware graphql em node.js (PostGraphile)
  • Backend com functions no PostgreSQL expostas pelo PostGraphile
  • Tela CRUD para cadastro de usuários, grupos e permissões.

Para fins de desenvolvimento poderá ser criada uma estrutura de banco de dados qualquer. Para autenticação, devem ser utilizados colunas de nome de usuário e senha, sendo a senha criptografada com hash + salt aleatório.

O ambiente de desenvolvimento / produção utilizará containers Docker.

  • Um container servindo de proxy reverso (NGINX)
  • Um container para o banco de dados PostgreSQL
  • Um container para servir o frontend (Next.js)
  • Um container Redis para cache e gerenciamento de sessão.
  • Um container para o middleware (Node.js + PostGraphile + Socket.io + REST etc)

Problemas encontrados

Entre as falhas na entrega destaco as seguintes:

  • Ao cadastrar um usuário não é feita a validação dos campos do formulário, permitindo inserir um registro com todos os campos em branco.
  • Ao salvar as permissões de um grupo, as permissões (rotas) existentes no formulário são inseridas novamente todas as vezes, crescendo exponencialmente o número de permissões.
  • Não eram exibidas mensagens de feedback para o usuário, informando que o registro foi salvo, excluído ou inserido.
  • Ao clicar no botão "Search", a busca funciona apenas com a correspondência exata da palavra. Exemplo: ao buscar pelo usuário teste, se digitar apenas tes nenhum resultado será exibido. Se houver 02 ou mais usuários iniciando com teste, exemplo, teste1 e teste2, somente será exibida a correspondência exata da pesquisa. Outro problema é que após clicar no botão "Search" não há uma forma de limpar a busca. Então se a pesquisa não encontrar nenhum resultado a tela fica sem registros não há uma forma de exibir novamente todos os usuários.
  • Ao clicar em "Add user" ou "Add group", as informações preenchidas no cadastro anterior permanecem no formulário.
  • A verificação de permissão de acesso a uma rota ocorre por meio da verificação da última palavra. Neste caso, se houver duas rotas como /recursoX/editar e /outroRecurso/editar e houver uma permissão para rota chamada "editar", o usuário teria permissão nas duas rotas mesmo sendo para recursos diferentes.

Bem, esses foram alguns dos erros que ocorreram durante o desenvolvimento do projeto. Então... esses erros se devem mais a falhas na descrição do projeto ou devido a experiência / comprometimento do desenvolvedor (que se identifica como sênior)?

Carregando publicação patrocinada...
3

Um dev que se identifica como sênior deveria no mínimo fazer uma análise e te alertar sobre os pontos citados para saber se seriam tratados ou não.

De toda forma é sempre bom passar o máximo de informações para o dev, afinal quem sabe o que um software precisa é o cliente. No meu dia a dia recebo muita coisa "mastigada" onde um analista de requisitos já levantou 99% das tarefas. Nessas tarefas existem os critérios de aceite para que ela possa ser homologada pelo cliente.

Exemplo:
Tarefa: Cadastrar Cliente

Critérios de aceite:
[ ] Ao acessar o menu Clientes o sistema deve exibir o botão "Novo Cliente"
[ ] Os campos nome, cpf, e-mail são obrigatórios
[ ] Ao clicar em salvar, verificar se o cliente já está cadastrado com o cpf, se estiver, exibir uma mensagem de feedback "bla bla bla"
[ ] Se houver falha na comunicação, exibir uma mensagem de feedback "bla bla bla"

...e assim por diante.

Esse tipo de levantamento me ajuda muito e evita que erros sejam transportados para produção.

No mais, esperto ter ajudado.

1

Confesso que a descrição do projeto poderia ser mais detalhada, mas também não houveram mais questionamentos por parte do desenvolvedor durante a negociação.

Já fiz documentações bem completas, chegando ao nível do desnecessário, com Casos de Uso, Diagramas UML, protótipos não funcionais etc.

Observei a publicação de outros projetos na plataforma do Workana e nenhum entra muito a fundo nos detalhes.

2

No caso do seu projeto, a descrição é bastante detalhada, mas amplamente focada em requisitos não funcionais e com poquissimos requisitos funcionais, que são os mais importantes para descrever o comportamento do sistema. O ideal é cada função implementada em codigo seja rastreavél a pelo menos um requisito funcional, assim se você tinha a necessicidade de fazer validações nos formularios, deviriam existir requisitos claros para tais, ou que a busca não deveria exata. Muito simples.

O nível de detalhe de que a especificação de requisitos não deve chegar é em como fazer as coisas, então não faz sentido ter um requisito que diz que deve usar %like% na busca, mas faz todo o sentido um requisito que explicite o que fazer na busca, inclusive com exemplos concretos de o que retornar em cada caso.

Muitos dos problemas que descreveu aqui são na verdade requisitos que deveria ter escrito. Assim deveria ter requisitos para como a validação funcionaria, como a busca funcionaria. O que deveria acontecer ao clicar no botão "Add user" e etc.

Em alguns casos é até injusto dizer que é um erro ou falta de comprometimento do desenvolvedor, como ele deveria saber que após clicar no Botão "Add User" as informações não deveriam mais aparecer no formulário? Bem isso era um requisito seu, mas que aparentemente nunca foi comunidado ao desenvolvedor.

Ao contrário do que muita gente pensa programadores não são bruxos.

Caso não tenha tempo ou interesse para investir na construção de uma especificação de requisitas detalhadas o que recomendo é contratar um profissinal para fazer este documento, antes de contratar alguém para implementar as funcionalidades que deseja.

1

Obrigado pela contribuição! De fato detalhei mais questões de arquitetura do que os requisitos funcionais. Talvez pelo fato de que a arquitetura, na minha visão, tem maior impacto sobre o background técnico exigido para o projeto e é um aspecto essencial para integração com outras partes da solução.

Também sou desenvolvedor e utilizei os meus pressupostos de que o profissional, na dúvida sobre estes requisitos funcionais, iria me perguntar ou sugerir alguma boa prática com a qual está familiarizado.

1
1

Conforme a plataforma, 3 a 5 anos de experiência em React.js e de 5 a 10 anos em Node.js. Paguei 60% do escopo do projeto. Estou testando o restante da entrega e levo em consideração que a descrição poderia ser mais detalhada e, por isso, faço "vista grossa" para algumas questões que considero de baixa qualidade.