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

Me chamaram para construir um software, mas não entendem de software

Olá, me chamo Jockson e não costumo escrever, mas aqui vai um tipo de desabafo

Ano passado em uns grupos no whatsapp que tinham a ver com meu emprego, comecei a compartilhar alguns programas de produtividade que tinha desenvolvido, sem pretenção, apenas para ajudar o pessoal. Tempo se passou e no meu privado apareceu uma pessoa com uma ideia de programa para criar.

Para fim de contexto, eu sou um estudante de ciência da comptação que nunca tinha trabalhado na área, mas já sabia algumas coisas de engenharia de software, continuamos.

A ideia do indivíduo era criar um programa que gera catálogos personalizados com itens que os usuários cadastrassem, até aí tudo bem, um programa normal, mas conforme o programa ia sendo desenvolvido ele ia aumentando o escopo do projeto, do tipo: "agora eu não quero mais um catálogo, quero vários personalizaveis", "Agora quero que o usuário descida as próprias cores", etc.

Tudo isso eu fui achando peculiar, mas possível de ser feito, até que um dia, ele me vem e fala: "Agora eu quero um programa desktop, 100% offline e 100% inhackeavel, sem sistema de login e sem complicações"

O que eu faço? hahahahaha

Carregando publicação patrocinada...
5

"Me chamaram para fazer X, mas não entendem nada de X"

Isso é a coisa mais normal do mundo, não é exclusivo da nossa área.

Por exemplo, eu não entendo nada de marcenaria, então contratei um marceneiro pra fazer os armários de casa. E claro que fiquei dando palpites e pedindo coisas que nem sabia se eram viáveis. Afinal, ele é o especialista, não eu. Eu sou o cliente e digo o que preciso, e ele me diz o que é e o que não é possível, e principalmente, quanto custa e quanto tempo demora cada coisa.

Ou seja, a esmagadarora maioria dos seus clientes serão pessoas que não entendem de software. É o normal, o padrão, a regra. Tentar lutar contra isso é dar murro em ponta de faca.


O seu erro, como já disseram, foi não definir o escopo e nem ter um processo para gerenciar as mudanças. Desde o começo tinha que deixar claro, de preferência formalmente (contrato), o que está no escopo, e como seriam cobradas as alterações. Cada coisa nova que o cliente pede é um trabalho a mais pra vc. E isso tem que ficar bem claro.

Claro que agora vai ficar mais difícil negociar, mas uma hora tem que mandar a real: se agora ele quer outra coisa, completamente diferente e mais complexa, tem que ser cobrado de acordo.

Voltando à analogia do marceneiro: se no meio do projeto eu peço mais uma prateleira, ele vai me cobrar a mais. Se eu mudo de ideia e peço pra mudar tudo, ou se agora eu quero um armário novo ou diferente, ele vai ter mais trabalho e vai me cobrar a mais. Com software não é tão diferente assim.

E se ele não gostar, sinceramente, que se dane. Se ele não quer pagar pelo que pede a mais, então ele só quer um otário pra fazer tudo de graça pra ele. Fuja de gente assim, isso nem dá pra chamar de cliente, é só um parasita mesmo.

3

Vamos lá, vou te passar o meu relato, de alguém que tenta estar por dentro da tecnologia, mas não programa.

No ano passado eu fui encarregado, de acompanhar um projeto que já estava em desenvolvimento por 4 anos, por conta do orçamento limitado, mas o desenvolvimento era baseado em horas mensais, um valor máximo, e correu tudo bem, mas foi crescendo com o tempo, e mudando, chegou um momento que o contrato de horas, já não era mais vantajoso pra empresa, o dev sempre estimou o total de horas de um determinado módulo, mas como existia um valor máximo de horas mensais, ele estimava quantos meses levaria pra ficar pronto.

Eu tive grande dificuldade, pois nunca existiu um roadmap, dos módulos, então foi uma das primeiras coisas que eu fiz, e mesmo assim, chega um momento em que as horas não fazem muito sentido, o ideal seria mesmo por módulo, por fase, que seja.

Resumindo, tudo isso aconteceu pois nós aqui na empresa, não entendíamos de software, não pelo menos da arquitetura, então sugiro que você crie um roadmap, algo explicando como funciona, e não sei como você mensurou o custo disso, mas agora é hora de sentar a mesa, e explicar que não são peças de lego que você encaixa, ou tira, você começou algo web, e pra ele se tornar desktop, melhor começar do zero.

1
2

Acho que primeiramente você tem que se impor, teve um contrato pra você desenvolver esse software pra ele? foi acertado o escopo do projeto e oque seria feito por tanto? foi combinado futuros módulos por um valor x?

Essas coisas são bem importantes para que você não seja passado a perna, que é oque ta me parecendo pelo que você comentou, é importante como prestador de serviço você ter a postura de especialista no que está fazendo, e fazer o seu cliente entender o porque certas coisas acontecem e decisões são tomadas.

Tem coisas que igual tu disse são fáceis de mudar, como a questão de o usuário escolher cor e outros, mas agora mudar totalmente o escopo do projeto para migrar de web pra desktop já é algo grande demais, tudo depende da stack que você ta usando e tals, mas isso dai já é pedir demais, se for js deve ser simples migrar pra electron mas acho que seu problema não é como resolver essa nova solicitação do cliente.

Mas sim definir melhor o escopo do projeto e explicar quando as solicitações podem ser inviáveis.

1

Dicas valiosas, muito obrigado!
A ideia que eu tinha quando ele começou a falar do projeto era um aplicativo simples em python que até desenvolvi até o final, mas assim q ele foi aumentando, tive q mudar pra algo mais rápido e estável, fui pra rust com react, sempre foi desktop aliás, mas a ideia inicial independia disso então eu não me preocuparia com coisas de sistema operacional e algo assim, pra questões de registro de software, ou algo assim.

2

Concordo com o kurt, sem contrato e escopo definido, fica complicado, mesmo sendo sócio se este for o caso, tem que ter contrato custo e tempo aproximado de entrega, período de garantia, custo de manutenção, etc...

Se ele procurar alguma empresa, vai ter tudo isso, mesmo que o projeto ja esta em andamento, faz um contrato que a partir de agora vai ser assim

Ponto sem contrato, ele tiver alguma transação de pagamento para você ka e suficiente para gerar um processo alegando que você nao fez o que foi combinado.

1
2
2

O kht disse tudo, e sem ofensas, mas é você quem estuda pra ser um profissional na área, não seu cliente/parceiro de negócios.
E a isso adiciono que o único software que não cresce escopo é aquele que não é usado. Todo software que "dá certo", terá um escopo cada vez maior (ou mudará conforme a necessidade de quem o usa). É a regra.
Agora, o que me parece ser a raíz da sua insatisfação não é o escopo aumentar, mas o fato de que você tinha um entendimento do acordo que havia feito com essa pessoa, e ela certamente tinha outro. Talvez seja o momento de oficializar tudo por meio de um contrato formal.
Bons negócios 🙏

2
2

se você não estiver sendo pago pra isso sai fora. se estiver ganhando você deve mostrar o que é possível ou não fazer. deve organizar as atividades de desenvolvimento e traçar um plano de entregas. a pior situação possível para qualquer programador é alguém te abordar com a proposta "eu tenho uma ideia , você programa e quando o sistema vender nós dividimos o lucro". isso é ruim de muitas formas . uma dela é que programador pode ter ideias até melhores do que algumas pessoas que não programam.

1

Pula fora, parece radical mas tem muitas pessoas que chegam assim, de mansinho e depois querem mansões como software e querem pagar o wue pagava no inicio. Se quiser continuar firme contrato e obedeca-o a ferro e fogo. Do contrário voce estara sendo explorado. Voz da experiência.