É bem comum conversarmos com amigos, familiares ou parceiros sobre o assunto logo após iniciarmos o desenvolvimento de uma ideia ou um projeto e isto é muito saudável. Isso faz nos sentirmos bem e nos traz sensação de contribuição social e muitas vezes possibilidades de aumento do potencial financeiro. Porém, em muitos casos, muitas "ideias filhas" surgem destas conversas e trocas de ideias, e disso surge um desejo quase que incontrolável de adicionar, remover ou alterar funções do projeto inicial. Ocorre que as consequências destas alterações, muitas vezes tidas como pequenas ou de pequeno impacto aos olhos do cliente, podem ter impactos significativos no tempo, recursos e habilidades bem como no custo total do projeto já definido ou até mesmo em raras vezes impactos estruturais.
Considere, por exemplo, que o desenvolvedor receba uma solicitação para colocar um mapa para rastreamento em um aplicativo que faz troca de moedas para saber onde está o cliente, após o projeto ser iniciado. Isso requer contratação de serviços de terceiros (API de Mapas com diversas formas de cobranças e planos) gerando demandas ao cliente, elevando os custos do projeto tanto para o cliente como para o desenvolvedor, bem como pode ser necessário a indicação de utilizar outra linguagem de desenvolvimento para este fim. Por isso, é muito importante verificar os requisitos fundamentais anteriormente, e não incluí-los após o desenvolvimento ser iniciado. Aos olhos do cliente, pode ser apenas aquela sensação de “ ah, mas é apenas uma tela de rastreamento simples”, porém, aos olhos de profissionais experientes, é algo bastante profundo e causa sérias alterações de rota comparando com a ideia inicial.
Vamos pensar: Se você fosse um mecânico, como seria se você recebesse um pedido para instalar uma quinta marcha em um fusca, ou uma sétima marcha em um carro com câmbio automático que só tem seis marchas? É apenas uma marcha a mais, não? Tenha em mente que o projeto inicial dele não foi concebido para isto, logo, não é recomendável, mesmo que às vezes seja possível. E leve em consideração que existem motivos para o fusca não ter 5 marchas.
Claro que algumas melhorias ou alterações não têm impacto significativo ou estrutural e podem ser objeto de propostas de alteração ou ainda substituídos por alguma função anterior de menor utilidade no produto inicial, contudo, tenha em mente que o mundo não acabará após a finalização e entrega do produto, e as sugestões podem ir se acumulando ao longo do tempo para lançar uma versão 2.0 do produto inicial ou, se for urgente, em pouquíssimo tempo. Ainda assim, esta alteração precisa ser discutida, compreendida, validada e transmitida para os profissionais de desenvolvimento. Isto certamente consumirá, no mínimo, tempo, energia, reuniões e alguns profissionais que poderiam estar focados no desenvolvimento do produto inicial.
Mas afinal, quem tem a palavra final para dizer se uma alteração do projeto terá impacto ou não, se é possível ou não? A resposta é simples, quem tem conhecimento e experiência nisso.
Não se trata de negar toda e qualquer requisição de alteração, mas compreender que toda alteração após o desenvolvimento iniciado traz consigo consequências, e a questão central é aceitar ou não as consequências de tais alterações, seja em aumento de prazo, escopo e possivelmente em custos.
Toda melhoria é bem vinda e merece ser discutida, mas é preciso muito cuidado ao inserir ou remover funcionalidades após o início da jornada de construção de um produto digital. E não estamos falando aqui de alterar algo que não ficou do agrado do cliente tais como botões, campos, telas, cores, enfim, mas somente do universo de adicionar ou remover funcionalidades não previstas inicialmente.
Principais Causas:
-
Não conhecer de fato o processo de produção de um produto digital achando que tudo é bem simples;
-
Achar que todas as melhorias precisam estar lançadas na primeira versão;
-
Ouvir demais as " Dicas" de amigos e conhecidos e não confiar na sua ideia inicial e possibilidades;
-
Não fazer um bom processo de Discovery antes de iniciar o Projeto;
-
Não acolher os aconselhamentos de profissionais experientes na área;
Principais Consequências:
-
Atrasos no projeto devido à discussão de novas possibilidades durante a construção;
-
Sensação de perda, por não inserir novas funcionalidades;
-
Desvio de rota de construção;
-
Perdas por custo de oportunidade (Momento do lançamento);
-
Perdas financeiras pelo consumo de mais horas de desenvolvimento;
Soluções Possíveis e Boas Práticas:
-
Confie mais na sua ideia e no motivo principal que o levou a levantar a possibilidade de construir um produto digital para transformá-la em realidade. Pense em quem vai recebê-la e que é mais importante o usuário receber os benefícios da sua ideia central do que os “Perfumaria” que podem ser adicionados posteriormente;
-
Eleve ao máximo o tempo investido em investigação sobre o projeto antes de iniciá-lo;
-
Mesmo que você pense que o produto não sairá como o previsto inicialmente, ele sairá, pois quem está construindo sabe que ele não se parece como o produto final durante a construção;
O Intuito deste post não é para desencorajar o melhoramento de um produto digital e de desenvolver todo o seu potencial, mas trazer consciência para que esta prática seja feita no momento de Discovery do produto ou seja, antes de o desenvolvimento ser iniciado e todas as tarefas serem distribuídas, e não depois. Ainda assim, caso isso ocorra, que a proposta de alteração seja avaliada por profissionais capacitados com melhor visão dos impactos possíveis e suas consequências para que o cliente tome as suas decisões da forma mais consciente possível.
A Plathanus é um parceiro de confiança que trabalha para entregar a melhor experiência aos seus clientes no processo de desenvolvimento de um produto seja qual ele for, garantindo resultados satisfatórios.
FAQ: Alterações de Escopo durante o Desenvolvimento de Produtos Digitais
- Por que é importante evitar alterações de escopo durante o desenvolvimento de um projeto digital?
Evitar alterações de escopo é fundamental para garantir o sucesso do projeto, minimizar atrasos e manter o orçamento sob controle. Cada alteração pode ter impactos significativos no tempo, recursos e habilidades necessários, afetando a qualidade e a entrega final do produto.
- Quais são as principais causas que levam a alterações de escopo durante o desenvolvimento de um projeto digital?
As principais causas incluem falta de compreensão do processo de produção de um produto digital, a crença de que todas as melhorias precisam estar presentes na primeira versão, influência excessiva de opiniões externas sem confiar na ideia inicial, falta de um processo de Discovery antes do início do projeto e resistência em acolher os conselhos de profissionais experientes na área.
- Quais são as consequências de realizar alterações de escopo durante o desenvolvimento?
As consequências podem incluir atrasos no projeto, desvio de rota de construção, perda do momento ideal para o lançamento no mercado, sensação de perda por não inserir novas funcionalidades, perdas financeiras devido ao consumo de mais horas de desenvolvimento, entre outros.
- Quais são as soluções possíveis e boas práticas para evitar alterações de escopo?
Algumas soluções incluem confiar mais na ideia inicial, investir tempo suficiente em investigação antes do início do projeto, e avaliar propostas de alteração por profissionais capacitados antes de tomar decisões finais.
- Como a Plathanus pode ajudar a evitar e lidar com alterações de escopo durante o desenvolvimento de um projeto digital?
A Plathanus é um parceiro de confiança que trabalha para garantir a melhor experiência aos seus clientes no processo de desenvolvimento de um produto digital. Nossa equipe está preparada para ajudar a evitar e lidar com alterações de escopo, garantindo resultados satisfatórios e mantendo o projeto dentro do prazo e orçamento estabelecidos. Entre em contato conosco para saber mais sobre nossos serviços e como podemos ajudar no seu projeto!
