Feature Creep

Feature bloat, featuritis.

Feature bloat, feature creep ou featuritis são termos usados para designar a condição de produtos que apresentam um excesso insalubre de funcionalidades, dificultando seu uso.

O problema se origina no planejamento, após o levantamento de requisitos do sistema e o estudo de viabilidade técnica (feasibility), e é o papel do planejador ou gerente de produto evitá-lo.

Principais causas

O exagero de funcionalidades em um produto é comum na indústria de software, principalmente em modelos de gerência top-down (hierarquia bem definida) e de desenvolvimento em cascata (waterfall).

Em ambos os casos, pode haver deficiência na participação de usuários finais no processo, gerando distorções no levantamento de requisitos e casos de uso.

Em modelos tradicionais de gerência, há pouco aproveitamento do capital intelectual da empresa (técnicos envolvidos), centralizando decisões na mão de poucos. Estes profissionais normalmente possuem maiores habilidades em gerência e estratégia, uma visão ideal do produto que pode causar distorções nas definições do escopo.

Quando a equipe de desenvolvimento executa o projeto em cascata, aumentam os riscos de deficiências no planejamento serem descobertas apenas em etapas avançadas, quando a mudança pode ser  inviável, seja por prazos ou custos.

Há uma tendência ao feature bloat em empresas orientadas ao desenvolvimento, quando a tomada de decisões é papel de programadores ou analistas de sistema. Quando profissionais de design ou comunicação estão envolvidos, é mais comum o problema inverso, ou seja, a deficiência de funcionalidades.

Evitando o problema

Para minimizar os riscos do feature bloat, recomendo 3 práticas:

1. Faça o dever de casa – Benchmarking, Brainstorming e Briefing.
   • Benchmarking: Estude o mercado, seja a concorrência ou o consumidor.  Defina necessidades antes de requisitos.
   • Brainstorming: construa ideias, com um grupo relevante de envolvidos, quanto mais heterogêneo melhor. O objetivo não é eleger a melhor ideia, mas construí-la coletivalmente.
   • Briefing: Documente as descobertas de maneira objetiva, clara e direta. Este documento contém as diretrizes para os requisitos do sistema.
2. Evite modelos centralizados.
   Um gerente provavelmente possui qualidades para produzir grandes ideias, mas depender apenas de sua perspectiva é apostar no erro.
3. Produza em pequenos ciclos.
   Desta forma minimizam-se os riscos de super (ou sub) dimensionamento do projeto, pois há a possibilidade de avaliá-lo múltiplas vezes e em curtos períodos. Existem metodologias iterativas de design (UCD) e de desenvolvimento (agile). Para uma equipe mista, é adequado buscar o equilíbrio entre os dois mundos.

Para saber mais:

• Feature Bloat: The Product Manager’s Dilemma
• Wikipedia – Feature Creep
• Cooper – Blending Agile and UCD