Para montar o roadmap de um produto, o prazo e custo de cada desenvolvimento pesa bastante. Às vezes não há profissionais com tempo disponível, ou o custo é mais alto que o orçamento disponível. Nessas situações o desenvolvimento é descartado.
Porém, tem situações que mesmo com profissionais disponíveis e custo dentro do orçamento, o PO deve recusar o projeto. Segue abaixo algumas delas.
Alto custo de manutenção
Por mais que o desenvolvimento esteja pago, é preciso pensar que o custo não termina por aí.
Adicionar mais linhas de código a um projeto gera mais complexidade. Cada nova alteração precisa manter coerente todo o código existente.
Com o tempo, o código pode se tornar cada vez mais complexo, deixando bem mais custosa qualquer alteração. Além disso, a probabilidade de acontecerem bugs aumenta.
Baixa generalização
Esta nova funcionalidade pode ser reaproveitada em outras situações?
Por exemplo, supondo que seu produto seja usado por alguns clientes. Um cliente específico está disposto a pagar pelo desenvolvimento de uma funcionalidade. Se essa funcionalidade não for útil para nenhum outro cliente, provavelmente isso será um tiro no pé. Ter funcionalidades muito específicas não é sustentável a longo prazo. O custo de manutenção acaba superando o valor orçado.
Produtos voltados para o usuário final também lidam com essa questão. Se uma funcionalidade puder ser reaproveitada em diferentes contextos, o desenvolvimento será muito mais eficiente.
Falta de alinhamento com o objetivo
Outra questão que deve ser avaliada é se a funcionalidade ajuda o produto a cumprir seu objetivo. Por exemplo, se seu sistema é de vendas, a funcionalidade ajuda a vender mais? Se seu produto é um sistema de transportes, ele ajuda o usuário a chamar mais facilmente seu veículo?
Há situações em que a funcionalidade não tem relação com o objetivo do produto. Isso é um ponto de atenção.
Mas também há situações em que a funcionalidade entra em contradição com o objetivo do produto. Neste caso, só se deve desenvolvê-la se não houver outra saída.
Pouco (ou nenhum) valor agregado ao produto
Uma funcionalidade pode não estar alinhada com o objetivo do produto, mas pode agregar valor de outra forma. Permitir que os usuários divulguem que estão gostando do produto, ou permitir que os usuário entrem em contato de forma mais fácil com o SAC são alguns exemplos.
Acontece que tem funcionalidades que podem trazer benefícios discutíveis, como por exemplo, a integração com redes sociais pouco utilizadas.
Num caso ainda pior, pode ser que a funcionalidade traga malefícios ao produto. Adicionar mais um elemento a uma página pode piorar a usabilidade, ou o tempo de carregamento. É preciso pensar nos efeitos colaterais de qualquer alteração.
Mas nem sempre é tão fácil
Na vida real pode não ser fácil convencer o cliente a não fazer a funcionalidade que deseja. É preciso argumentar de forma clara sobre o custo-benefício da customização, melhor ainda se forem apresentados números que embasem o ponto de vista.
Entretanto, o trabalho do PO envolve negociação e isso é natural. Às vezes pode ser preciso ceder, afinal, negócios são feitos através da relação entre pessoas. É preciso manter uma relação saudável e de confiança.
Piou 