Não existe verdade mais nua e crua que esta. Quem disser o contrário, está definitivamente enganando seus próprios clientes:
Três Tipo de Trabalho
Alguém sabe quando foi meu último post? É, este aqui. O que eu havia dito neste outro post mesmo? Post semanal né!? Esqueçam. Postarei quando tiver boas idéias e cases para mostrar. É mais produtivo.
Então, este mês de Janeiro completou 1 ano que estou em um projeto freelancer e desde o início eu pretendia fazer um experimento. E que risco! Eu explico: A princípio, meus serviços seriam para dar manutenção em um sistema que já existia, desenvolvido em VB6. O sistema era até grande. Mas as negociações acabaram levando estes serviços de manutenção para nível de projeto. Resolvemos criar um novo software, importanto o que tinha no outro, melhorando e inclusive criando coisas novas.
Na negociação, eu prometi tentar entregar um bom software, com retorno rápido, em pacotes (eram para ser pequenos sprints, mas na época eu não entendia muito bem como negociar projetos Scrum). Mas apliquei vários dos seus conceitos no projeto e o destaque vai para o que eu pretendo relatar neste post. Quando comecei a desenvolver o software, eu decidi não criar nenhum sistema de validação de formulário até que uma solicitação fosse feita pelo cliente.
O sistema hoje comporta de 20 a 30 usuários, 2 locais físicos distintos e acessos esporádicos de alguns fornecedores. Hoje são 42 tabelas em um banco de dados relacional e aproximadamente 30 telas e uns 15 relatórios e gráficos. O máximo que foi criado para telas com formulários foram máscaras nos campos, e mesmo assim, não com o objetivo de validar, mas sim de melhorar a usabilidade.
O sistema está há 1 ano em produção e em constante mudança, sem nenhum sistema que valide os formulários. Alguns podem me cruxificar agora, principalmente por fazer um experimento deste porte em um cliente, mas eu consigo justificar fácilmente. Vamos lá:
Este gráfico mostra uma realidade relacionada ao uso das funcionalidades desenvolvidas e entregues para o cliente. Explorando esta realidade eu busquei com este experimento evitar gasto de esforço e investimento em algo que o cliente nunca ou raramente iria utilizar. A moral da história é que para este cenário, o cliente nunca utilizou, pois não fez falta ter um sistema complexo que validasse cada formulário de cada uma das aproximadas 30 telas.
A economia do cliente após 1 ano de trabalho e o retorno do software já é justificativa suficiente para o que fiz. E por favor, para concluir, não interprete este post como uma afirmação global para “Não faça validação em seus formulários, é inútil!”. Muito pelo contrário, validadores são importantes.
A moral da história é: “Ei, isto que estamos fazendo agora é realmente importante para o cliente e o retorno que ele precisa ter no tempo que nós estimamos?”.
Antes de mais nada, me desculpem por não terminar o post (alguns momentos atrás). Ontem foi noite de Poker com amigos e como já havia começado a escrever, deixei agendada a publicação. Ma vamos lá!
Por mais impressionante que pareça, a conclusão desta história teve um final feliz e ao contrário do que muitas pessoas pensam, não foi difícil conseguir isto. Acho que nós como fornecedores de serviços e produtos de softwares é quem educamos mal (e muito mal) nossos clientes e por consequência, sofremos com isto.
Veja você mesmo as mudanças que enviamos como contra-proposta ao cliente:
E adivinhem só qual foi o único elemento que ele pediu para mudar?
Conclusão: Ele não reclamou do fato de nós criarmos uma proposta onde basicamente dizemos: Cliente, não sei quanto vai custar, não sei quanto tempo vou gastar, mas eu vou fazendo e você vai me pagando, ok? Ah! E confie em mim, vou dar o máximo para que seu investimento valha a pena!
Lindo isto! Hehehe.
Logo após a inauguração do blog eu fiquei pensando sobre como eu faria para mantê-lo. Já tive um blog pessoal onde escrevia sobre tecnologias e novidades (mais especificamente sobre desenvolvimento de software), mas manter o falecido era bem complicado, ainda mais quando não haviam tantos leitores quanto gostaria e a desmotivação é natural. Com o Filosofia Ágil, vou manter um post semanal. Provavelmente eu crie um post antes mas sempre será agendado para 4:22 (madrugada mesmo) de segunda-feira (o mesmo horário de lançamento do primeiro post).
O interessante é que depois que lancei o blog, eu não parei de procurar assuntos para opinar aqui e o dia-a-dia vem sendo bem produtivo neste sentido. Já mandei 2 emails para mim mesmo com próximos conteúdos para o blog. Este post em específico é de um caso real onde um amigo está negociando um projeto com um cliente e eu resolvi ajudar. A questão era deixar claro no contrato do projeto o modelo de processos de desenvolvimento e como cobrar pelo trabalho. Senta que lá vem história…
Primeiro, quem elaborou o contrato do projeto foi o cliente. Achei estranho, mas enfim, peguei para ler. A princípio estava indo tudo muito bem, definindo os papeis da CONTRATANTE e da CONTRATADA, mimimi, etc, até que chegou o momento que realmente importa: Prazo e preço. Vamos lá:
Pronto! Temos um projeto complexo: É um projeto que está sujeito a mudanças de escopo e que se trata do desenvolvimento de novos recursos e manutenção de um sistema que já está em produção.
Está claro para mim que neste modelo, o cliente quer o ideal do mundo imaginário que não existe (é sério) e vai continuar não existindo (muito sério): Travar preço, travar tempo e travar escopo. Este modelo se encaixa perfeitamente no popularmente conhecido: Waterfall. Como temos um projeto de um sistema complexo, vai dar merda 02. Problemas que estamos cansados de saber vão surgir:
Projetos complexos exigem um modelo muito mais maduro de desenvolvimento, capaz de se adaptar a um cenário quase caótico como este. É aí que entram tantos frameworks de desenvolvimento ágil que temos por aí. A exemplo vou citar o Scrum, que se encaixa perfeitamente no caso. Mas a questão agora é: Como negociar com este cliente um modelo de trabalho que muito provavelmente vai trazer mais resultado para este cenário?
Primeiro passo é identificar o principal problema, e este foi fácil: Confiança. Este cliente está acostumado a ter o pé atrás e muito provavelmente com razão, afinal de contas todos os projetos de software que ela investiu devem ter dado errado (fora do previsto), sem exceção. Isto é perfeitamente normal e é compreensível que tenha inserido tantas e tantas camadas de controle em seu processo, afinal de contas, é uma empresa que já está “calejada” com a falta de transparência e confiança do mercado.
Após identificar este problema, eu e meu amigo modificamos o contrato baseando os processos no Scrum. Semana que vem eu vou postar o resultado de como foi o comportamento do cliente perante esta mudança. Sei que vai ser difícil. A princípio eu acho que haverá um sentimento de que nós queremos levar vantagem, e apesar da ironia, tenho certeza que o contrato ficou bem honesto.
Para inaugurar o blog, vou descrever a minha visão do Scrum Master no Brasil. Para todos os efeitos, esta é uma opinião pessoal baseada em inúmeros fatos. Vale uma historinha:
No início deste mês, eu fiz um treinamento de Scrum Master pela Adaptworks, empresa autorizada a aplicar estes treinamentos pela Scrum Alliance. Um treinamento de 2 dias (recomendo a todos) onde eu tive a oportunidade de conhecer outros profissionais e sair de lá com outro nível de pensamento. Tudo o que eu pensava de Scrum foi jogado no lixo. E olha que já palestrei sobre o framework em uma ou duas universidades e espero imensamente que as pessoas que ouviram a palestra, me perdoem.
Após o treinamento eu conversei com amigos e colegas de profissão sobre o assunto, o que rendeu horas e horas de trocas de informações. Conversa boa. Dá para notar que eu estava (e ainda estou) extremamente motivado, o que é natural. Visto esta motivação, eu decidi que gostaria de abraçar a complexidade e me especializar em metodologias ágeis de desenvolvimento, Scrum, XP, enfim, processos.
Mas quando comecei a procurar vagas de emprego para assumir o papel de Scrum Master (em todo Brasil), sabe o que é encontrado? Olha só:
Dentre outros, mas enfim, segue minha pergunta: Qual a primeira impressão sobre papel do Scrum Master numa empresa? A resposta é simples né: Ele tem que ser o profissional com mais experiência, maior poder de decisão e com uma carga de responsabilidade muito grande. Resumindo numa expressão popular bem comum: “O Pica Grossa”.
Mas para nós que estamos estudando e entendemos o que é o Scrum, sabemos que isto tudo não passa de uma grande bobagem! O modismo do Scrum no Brasil é tão grande que as empresas anunciam vagas de emprego pedindo que um profissional assuma um papel completamente absurdo. O que elas estão pedindo é um profissional certificado PMP e CSM para ser Gerente de Projetos e Scrum Master, ou mesmo um programador certificado MCPD e CSM para ser um Líder Técnico e Scrum Master. Não faz sentido. Dá para perder as contas (na verdade não, mas enfim) de quantos pilares dá para derrubar com o que as empresas estão querendo fazer.
Empresas, meu recado para vocês é: Vocês estão fazendo isto errado. Isto não é Scrum. Tirem o Scrum Master do requisito da vaga e eu prometo que vocês irão encontrar um profissional que atenda muito bem. Ou então, encontrem pessoas que saibam o que é Scrum e sejam capazes de fornecer uma consultoria. Ou mesmo façam o curso que eu fiz (lá no início do post) e entendam o que é Scrum e qual o real papel do Scrum Master. Vocês precisam ajudar vocês mesmas na luta contra o modismo e à banalização dos processos de desenvolvimento ágil de software.