Se há coisa mais difícil do que criar software para um cliente é explicar a esse cliente como o software é construído. Há algumas analogias que podemos utilizar. O Toggl escolheu uma das mais simples: com fotos e com carros.
Segundo o Toggl, um dos maiores problemas na criação de software é a lacuna entre a forma como os clientes veem o desenvolvimento de software e o modo como o desenvolvimento funciona na prática. Negociações sem fim sobre orçamentos talvez sejam o sintoma mais óbvio aqui, mas a divisão é mais ampla do que isso.
Desenvolvimento ágil: onde termina o envolvimento com o cliente?
O modelo Waterfall, em que o desenvolvimento segue um caminho linear desde a fixação de requisitos até a entrega e a manutenção, parece ter desaparecido nos dias de hoje. A menos que esteja a trabalhar em projetos de grande dimensão, o melhor é seguir uma metodologia de desenvolvimento ágil.
A mentalidade ágil está fundamentada no facto de que os clientes, muitas vezes, não sabem exatamente o que pretendem de um software. As equipas ágeis trabalham de forma transparente e mantêm o cliente envolvido no processo de desenvolvimento, para garantir que o resultado final corresponde às necessidades reais da melhor forma possível.
É mais ou menos como comprar um smoking numa loja em vez de o comprar online: nunca saberá se serve ou como fica até ao momento em que o testa. E, idealmente, terá um alfaiate para o ajustar às suas medidas.
Como proteger o seu tempo de desenvolvimento
Embora o desenvolvimento ágil esteja, sobretudo, relacionado com transparência e cooperação, ainda precisa de proteger o seu tempo. Estas são algumas expressões que os clientes costumam dizer:
- “Posso sentar-me com vocês para que possamos trabalhar em conjunto?”
- “Tenho um amigo que poderia fazer isso num dia, poderíamos fechar por metade do preço?”
- “Podemos voltar à primeira versão? Também não devemos pagar se não usarmos o código.”
Esses cenários podem custar muito tempo e dinheiro se não se mantiver firme. A sua primeira linha de defesa é um bom sistema de gestão de projetos. Se precisar de responder a problemas inesperados ou de manutenção, recorra a um quadro Kanban. Um quadro Kanban é, essencialmente, uma lista de tarefas que impõe um limite estrito de quantos itens de trabalho podem estar em andamento num determinado momento.
Trata-se de um ótimo sistema para evitar que a sua equipa fique sobrecarregada por interrupções. Se ocorrer um problema inesperado, poderá priorizá-lo, caso contrário, entrará na fila de espera.
Se não necessita de se preocupar com a manutenção ou se o seu projeto não é composto por muitas partes interconectadas, pode recorrer a um sistema Scrum. O Scrum limita a equipa a trabalhar num único objetivo altamente específico, em sprints, com duração entre 2 a 4 semanas. O objetivo é manter a equipa totalmente focada no seu objetivo.
Tanto o Scrum como o Kanban dependem da disciplina de trabalho, portanto, certifique-se de que o seu cliente saiba que não está a usar qualquer um destes métodos apenas para o aborrecer.
Como proteger o seu orçamento
Proteger o seu tempo é uma coisa, garantir que é pago é outra completamente diferente. O segredo passa por construir uma ferramenta de registo de tempo. Uma boa forma de permanecer lucrativo é colocar uma grande etiqueta vermelha com o preço do seu tempo.
Há vários benefícios no registo do tempo de desenvolvimento, mas os dois principais resumem-se à inteligência de negócio e à transparência. Traduzido por miúdos, isso significa que ganha a capacidade de fazer planos informados e mostrar aos seus clientes o quanto as “pequenas mudanças” custam em tempo de desenvolvimento.
O registo de tempo funciona devido à forma como os nossos cérebros funcionam. Na verdade, não temos uma noção exata do tempo, mas sim uma perceção bastante distorcida. Consequentemente, adivinhar quanto tempo demorará a implementar um projeto – especialmente aqueles projetos ágeis e em constante mudança – não é mais preciso do que prever o tempo com uma bola de cristal.
É verdade que isso pode não funcionar com clientes excessivamente ansiosos e que insistem em passar por cima de seus programadores ou designers, mas é muito, muito melhor do que entrar num projeto desarmado.