Quanto vai custar e quando vai ficar pronto meu sistema?
Olá pessoal, atualmente trabalho como Gerente de Projetos em uma fábrica de software aqui no Sul do Brasil (grande Maringá) e gostaria de falar um pouco de uma situação que ocorre no meu dia a dia e que penso pode ajudar a muitas pessoas. E a situação é a seguinte:
Quando um cliente necessita de uma solução sistêmica para resolver um determinado problema, um dos pontos que ele pensa é: Quem vai me ajudar no desenvolvimento dessa solução? Se ele possui uma equipe de TI interna e disponível, naturalmente repassará tal demanda para esse time, caso contrário ele vai ao mercado para contratar uma empresa de software para ajudá-lo e ai que mora o grande problema. Muitas vezes, o cliente não sabe como pedir/solicitar essa contratação e no geral, o instinto é enviar um documento "pobre/macro" a várias fábricas e pedir um orçamento de custo e prazo e fazer uma comparação simplista para eleger qual empresa irá executar a demanda.
Baseado nessa situação cotidiana, qual deve ser a postura de uma fábrica de software responsável? Ler o documento, fazer uma reunião de 10 minutos com o cliente e estimar por ordem de grandeza e enviar ao cliente? Sinceramente, não vejo que seja o melhor caminho, pode até funcionar para sistemas pequenos, mas ainda assim não acho o melhor caminho e porque?
- O cliente com base nessa informação, que pode ter muita variação, vai cravar esse número não confiável para a sua diretoria e isso gerará uma expectativa alta em todos os interessados. Número não confiável x Expectativa Partes Interessadas Alta. Hmmmm, não me parece um bom caminho.
- Ser contratado como escopo fechado para um projeto onde os requisitos são pouco detalhados faz com que alguém perca nesse negócio ou até mesmo ambos percam.
Nessa etapa de formação de um novo projeto e relacionamento, penso que a fábrica de software deve ser hábil o suficiente para encantar o cliente fazendo justamente o que a maioria não faz, sugerir alternativas relevantes ao cliente para que o projeto comece com o pé direito. E quais são as principais alternativas:
- Mostre ao cliente os impactos que um requisito pouco detalhado pode causar no futuro do projeto. Que cliente quer pagar mais do que deveria por um produto?
- Sugira uma etapa especifica para uma melhor elucidação dos requisitos funcionais/não funcionais. Um profissional competente nisso pode orientar o cliente sobre qual é o melhor caminho a ser seguido. Muitas vezes isso já diminui e muito o escopo do produto, fazendo com que o cliente valide se o que ele quer realmente vai resolver o problema. Um MVP aqui é sempre bem vindo. Imagine você construir um sistema durante 6 meses e o cliente descobrir que o sistema não vai de fato resolver o real problema.
- Questione o cliente se o que ele precisa já não existe no mercado. Muitas vezes, a solução que ele busca já tem n produtos que podem ajudá-lo, não reinvente a roda.
- Envolva pessoas competentes tecnicamente (GP e Líder Técnico) para avaliar o "terreno" onde o produto vai rodar, isso vai facilitar muito a criar uma estimativa mais próxima da realidade. Os requisitos não funcionais devem ser bem mapeados para evitar surpresas desagradáveis no futuro.
Mesmo depois de todo o seu esforço em mostrar para o cliente as vantagens de se seguir por esse caminho, não houve um convencimento, então a solução da Ordem de Grandeza deve ser bem pensada com muitas ressalvas. É importante esclarecer para o cliente que durante a fase de detalhamento do escopo, essa estimativa será refinada e que pode haver grandes variações. Isso deve estar claro para todas as partes interessadas do projeto. Como isso é um risco alto de se ocorrer e que todos aceitaram esse risco, é importante já definirem o que fazer caso se torne um fato. Faça isso com TODAS as partes interessadas relevantes do projeto.
Se você é um Gerente de Projetos e que está sempre envolvido nesse contexto, seja extremamente transparente e ético. As vezes é melhor perder um projeto do que manchar a imagem da empresa que você representa. É importante ter em mente que nem todo cliente é maduro para realizar uma contratação como essa.
E ai, gostou das dicas? Esse tema é bem profundo e tem muita coisa que dá pra falar a respeito. Se você ficou com alguma dúvida, ou tem alguma sugestão, por favor, não hesite em fazê-la.
Esse é meu primeiro artigo, então releve ae qualquer deslize. :-)
Forte abraço a todos.
Desenvolvedor Fullstack - falou código, estou lá.
1 aÉ o texto que está faltando sobre o assunto. Por onde quer que eu perambular, falo sobre a necessidade do cliente, pessoal de negócio, SENTAR A BUNDA NA CADEIRA e estudar a fundo o seu caso. Entender o problema, a dor, as soluções pensadas do ponto de vista do negócio, para ter insumo para se comunicar com os desenvolvedores de software. Ficar jogando requisitos vagos e esperar "devs, resolvam meu problema" é a receita para o retrabalho, tempo perdido, acúmulo de débito técnico (o problema não fica claro mas o prazo está ali, não é?), frustração de todos os lados e azedamento da relação.
Chief Executive Officer (CEO) <🧡/> at ANYMARKET
7 aParabéns Edoil R. Barros, PMP! Curti. Muito bom e verdadeiro. Excelente texto!
Consultoria em processos administrativos e industriais
7 aSimples e direto. Parabéns pelo texto.
Líder técnica | Consultora
7 aOtimo Texto Edoil!!! Parabéns
Líder em Agilidade | Agile Coach na AMcom Sistemas de Informação | Facilitação, Pensamento Lean
7 aParabéns Edoil, ficou muito bom .