Reflexões sobre Apps

O software sempre me impressionou pela transformação que pode infligir às pessoas.

O software do tipo conhecido como App é um exemplo extraordinário. As pessoas são apresentadas a eles por boca a boca, e passam a adota-lo pelo benefício que trazem para o seu cotidiano. A maioria destes Apps não tem custo, e o impacto é gigante em milhões de pessoas. 

Não raro me perguntam como pode haver um investimento tão significativo numa solução como o Waze ou o WhatsApp, e estes não custarem nada. Os entendidos dizem que é justamente o fato de terem uma comunidade fidelizada a razão de seu sucesso. E que o dinheiro vem em seguida, em decorrência desta fidelização. 

É difícil de compreender mas é inegável o valor destes aplicativos. Minha mulher diz que não consegue viver sem o Waze. Meu cunhado diz que só se comunica pelo WhatsApp. Por telefone, nem pensar, não vai atender. Dizem que até pagariam por ambos. Quanta generosidade!

Os investimentos nestes projetos são enormes em decorrência da possibilidade de mercado que podem alcançar. Gestores de capital de risco vão em busca destes campeões de audiência, numa corrida frenética para identificar e chegar primeiro no próximo sucesso.

Esta cadeia de valor tem participantes em vários níveis, do nascimento à maturidade. Hoje são reconhecidos quase como deuses os profissionais que conseguiram enxergar um sucesso no momento da concepção da idéia. Tem tanto valor quanto o pai da idéia.

As start-ups querem se associar a estes profissionais. É um círculo virtuoso. São os novos donos do mundo. 

Amigos me contam que na California não há nada que não seja regido por um App. Pensou em algo? Tem um aplicativo. Para estacionar na frente de um restaurante você aciona o aplicativo e, de repente, surge o manobrista vindo de skate para levar o seu carro. Na hora da saída o procedimento se repete e  o carro chega com o skate devidamente acondicionado na mala.

Antes que você pergunte, sim, o serviço tem seu custo. As pessoas se esquecem que serviços custam, mesmo os que aparentemente não custam...

Minha Concepção de Projeto - Parte V

A entrega ao cliente deve ser feita com pompa e circunstância.

Trata-se de um marco fundamental e representa o fim de uma etapa. Neste momento, o prazo de realização do projeto pode ser apurado. É a parcela do tempo que dependeu quase que exclusivamente da equipe do projeto. Deve ser motivo de alegria e regozijo. Principalmente quando o prazo foi cumprido ou com atraso justificado com antecedência.

A entrega representa a versão 1.0 do projeto. Também a versão 1.0 do banco de dados. Tanto o código produzido quanto a estrutura do banco de dados precisam de controle de versão. São controles independentes mas que se interrelacionam. O software deve reconhecer com que versão de dicionário de dados é compatível. Evita-se um milhão de problemas.

A entrega implica em colocar o projeto em funcionamento no ambiente do cliente. No ambiente de homologação do cliente, para ficar bem claro. Precisamos que o cliente também realize a sua validação e dê o seu parecer. Sempre sou favorável a capacitação do cliente. Pode ser uma apresentação mais detalhada seguida de um acompanhamento de prontidão para qualquer dúvida durante a homologação.

As vezes, produzimos um documento de auxílio a esta apresentação. Não me refiro a um manual completo e detalhado. Este é sempre complicado. Muito difícil de manter atualizado e muito duvidoso o seu uso pelos usuários. De qualquer forma, se estiver no escopo acordado entre as partes, precisa ser feito. Acho um recurso jogado fora.

Durante a homologação podem surgir ajustes. Aliás erros poderão ser identificados ao longo de toda vida útil do projeto. Não é nenhum demérito e deve ser coberto por uma garantia num período inicial de uso e por um contrato de manutenção após este tempo. Não é possível oferecer garantia vitalícia, mas é crível acreditar na estabilidade de um projeto se nada for alterado.

Voltando a homologação, parte deste ajustes apontados pelo cliente podem ser mudanças de escopo. Sim, me refiro a mudanças em relação ao que foi descrito no projeto. É preciso trabalhar este tema junto ao cliente para não criar frustrações. Devemos estar prontos a ajuda-los com estas mudanças mas também precisamos que reconheçam se tratar de novidade no projeto e que requerem esforço e custo adicionais. Tudo às claras, transparente. O cliente obterá o que deseja e o prestador do serviço será devidamente remunerado, como é justo e equilibrado.

Finalmente, o projeto vai para produção. É o início de uma nova etapa.

Um projeto que representa um novo processo de trabalho para a empresa tende a constantes evoluções e mutações, que precisam ser acompanhados por mudanças no projeto. Nada mais natural. E desejável.

Infelizmente, nem sempre o que se pede é evolução.

É preciso estar atento para demandas de pessoas conservadoras que tentam voltar aos processos anteriores, como se nada tivesse acontecido. É a aversão a mudanças, como dizia Maquiavel.

O antídoto que conheço e recomendo é o cliente manter o seu ponto focal original do projeto à frente para evitar que o projeto seja deformado por estas demandas. Pelo menos por um ano de uso. Às vezes, até mais. Para mim, isto se chama governança.

Minha Concepção de Projeto - Parte IV

Temos um projeto a cumprir. Me parece lógico que alguém deva verificar se o protótipo foi respeitado e se as condições descritas no cenário foram realizadas.

Isto é tão importante que deveria ser realizado pelo presidente da empresa. Igual a bater "penalty". Minha recomendação é que sempre seja feita uma dupla checagem: pelo gestor do projeto e pelo contato com o cliente.

Certa vez perguntei a uma colaboradora nossa, nascida e formada nos Estados Unidos, qual era na sua opinião a principal diferença entre o profissional americano e o brasileiro. Respondeu de bate pronto, como se esperasse há muito tempo pela pergunta. "Nós entregamos o que prometemos".

Simples assim. O mínimo que alguém espera é receber o que foi prometido. Se mudamos alguma coisa, precisamos explicar bem explicadinho. E, de preferência, tão logo identifiquemos a necessidade da mudança. Passa a fazer parte do cenário e, evidentemente, da entrega.

Esta são condições necessárias mas não suficientes. É preciso homologar o projeto. Homologar é realizar um teste extenso e minucioso. Teste de funcionalidade, teste de resultado, teste de volume, teste de compreensão e de comunicação. Precisa de uma massa de dados,  que cubra todas as possibilidades previstas no cenário. E, se não passar no teste, é preciso corrigir.

Digo para meus colaboradores que sempre vamos ajustar o que não está correto. Porque criar um desconforto com o cliente e esperar que ele aponte o erro se podemos nos antecipar e entregar algo melhor? Projetos com erros fáceis de encontrar são um convite a derrocada de qualquer empresa. O cliente fica tão aborrecido que mesmo que seja acertado, a opinião dele não muda. É o que chamamos de percepção inelástica de valor. A relação fica desgastada. É o início do fim.

É importante diferenciar o que o cliente aponta como erro do que é situação não prevista no projeto. A fronteira é tênue e tanto o cenário como o protótipo são os instrumentos certos para dirimir as dúvidas. Está escrito, tem que fazer. Não está escrito, sinto muito, é fase 2.

Minha Concepção de Projeto - Parte III

As tarefas do desenvolvimento devem ser acompanhadas de perto.

É importante saber se os prazos estão sendo respeitados, mas igualmente importante checar a qualidade do que se produz. Melhor descobrir cedo que alguém não está na mesma página do projeto e ajustar expectativas do que ter que retrabalhar lá na frente.

Nós usamos o SOL, que tem uma funcionalidade para acompanhar as tarefas do projeto. A regra é rever semanalmente com cada analista o andamento do seu trabalho. Se alguém "empaca" é preciso ajuda-lo. Seja na implementação do código, seja no entendimento do processo. Ambos ocorrem mais do que desejamos. São surpresas totalmente previsíveis.

No desenvolvimento sou favorável ao máximo possível de padronização. Na TI há facilidades e dificuldades sobre este tópico. No final das contas somos nós mesmos que vamos manter e evoluir o produto final e, raramente, será quem fez o projeto o responsável pelas novas solicitações. Não se trata de engessar a criatividade dos desenvolvedores, mas evitar devaneios que prejudicam o resultado final.

Mais uma vez temos de ficar de olho na comunicação. Sou muito chato com este tema e insisto para que o projeto saia agradável aos olhos de quem vai usar. Além disto acredito que a pessoa que usa deve ser capaz de entender o que precisa fazer no preenchimento da tela. Adotamos o recurso da explicação "in loco", ou seja, um ícone responsável por explicar o que não é autoexplicativo.

Na Pix os projetos são sempre acompanhados de um web designer. O desenvolvedor não desenha tela. Tem funcionado melhor. Até porque o web designer participou do protótipo e, espera-se, sabe que pode implementar o que planejou.

Na Pix todos os nossos colaboradores podem potencialmente participar de todos os projetos. Chamamos isto de colaboração contínua. Afinal, após algumas centenas de projetos, já passamos pela maioria das situações. Incentivamos a ajuda entre equipes. Funciona maravilhosamente.