Se você não tivesse dinheiro nem prazo suficiente, o que você escolheria?! Um aplicativo pela metade ou a metade do aplicativo?!
Vamos começar explicando a diferença entre as duas alternativas.
1) Um aplicativo pela metade é aquele que deixa de lado algumas questões como segurança, velocidade e integridade dos dados, mas obedece ao escopo definido.
2) A metade de um aplicativo é quando seu aplicativo não faz tudo o que estava planejado, mas dá garantia do pouco que faz.
Dito assim, podemos pensar que fica um pouco mais fácil decidir. Mas nem sempre.
Vejamos as vantagens de uma e de outra alternativa.
1) Aplicativo pela metade
a) Atende ao escopo planejado. (Isso evita desgaste com a sua gerência)
b) O desenvolvimento estará terminado e já começará a fase de manutenção e ajustes.
c) As deficiências poderão ser detectadas e consertadas com o tempo.
2) Metade do aplicativo
a) Garante a integridade dos dados.
b) Por ser menor, é mais fácil de ser ajustado e menos sujeito a defeitos.
c) As funcionalidades faltantes podem ser adicionadas aos poucos.
É… se você está numa situação como essa, tem uma tarefa delicada e difícil pela frente. Você terá que apaziguar ânimos, negociar prioridades e flexibilizar metas. Mas aqui vai uma dica: escolha sempre que possível a alternativa número 2; a metade do aplicativo.
Deixe para segundo plano aquelas funcionalidades que parecem importantes, mas que podem ser deixadas para um pouco mais tarde. Aquelas, que não são fundamentais, apesar de serem bacanas.
Eu sempre costumo dizer que “se não puder fazer tudo, faça tudo que puder”. Sei que nem sempre o “tudo que eu posso” é o suficiente. Você realmente corre esse risco, mas não corre o risco de fazer um “completo” só de fachada. Tente negociar. Não brinque de faz-de-conta. Priorize a necessidade e não as vontades pessoais.
As pessoas preferem não ter uma coisa, do que tê-la e não poderem confiar nela. Vamos a alguns exemplos práticos?
a) Você prefere ter um relógio que vive atrasando ou não ter nenhum?
b) É preferível um computador lento e robusto ou um mais rápido que vive travando?
c) É melhor uma conexão à internet lenta e estável ou uma mais veloz que cai toda hora?
Percebeu? Fazendo apenas parte do aplicativo, mas tendo essa parte bem feita, preocupando-se principalmente com a integridade dos dados e dos processos, você não terá dor de cabeça para consertar muita coisa quando seu aplicativo entrar em produção. Essa estratégia lhe dará tempo para iniciar novas funcionalidades logo, ao invés de ter que se preocupar com quebra-galhos para acertar dados comprometidos.
Se você tiver que abrir mão de alguma coisa num aplicativo, abra mão de velocidade, de funcionalidades, de módulos inteiros até! Mas nunca abra mão da qualidade dos dados. Afinal de contas, é para isso que existe um aplicativo: para agir sobre alguns (ou muitos) dados.
Hoje seu escopo inicial não está totalmente atendido; mas em breve ele estará, pois você não gastará tanto tempo consertando defeitos. Afinal de contas, de que vale entregar o escopo completo e ter o cliente insatisfeito e pronto para mudar de fornecedor na primeira oportunidade? Se isso acontecer, o “tudo” que você entregou será transformado em nada.
Aqui vai uma ajudinha para você escolher quais funcionalidades devem ser retiradas ou mantidas: Não deforma, não tem cheiro e não solta as tiras
Faça pouco, faça rápido, mas faça bem feito. Portanto, “se não puder fazer tudo, faça tudo que puder”.
Autor: Vinicius Assef
