[MÚSICA] [MÚSICA] Olá a todos. Meu nome é Eduardo Guerra. Estamos de volta no curso Princípios de Desenvolvimento Ágil de Software. Hoje vamos falar sobre a colaboração com o cliente, o terceiro item do manifesto ágil. Então nessa aula a gente vai entender como é que essa colaboração com o cliente é importante, e como é que a gente pode deixar o nosso projeto mais produtivo, focado nas coisas certas e não ficar brigando com o cliente a partir ali dos contratos. Então, vou colocar aqui qual é que é o princípio que está lá no manifesto ágil é que a gente deve dar mais ênfase na colaboração com o cliente do que na negociação de contratos. Obviamente, eu não estou falando para ninguém não ter contrato nenhum com o seu cliente. Mas, talvez você ficar usando o contrato como escudo, ou como uma forma de às vezes, tirar vantagem do cliente no caso de ele pedir algum tipo de mudança, isso pode ser ruim, e às vezes você pode até ser que entregue o projeto, talvez não da forma exatamente que o cliente quer, mas aí por exemplo, aquele cliente nunca mais vai querer trabalhar com você, ele vai sair insatisfeito, porque às vezes o projeto não vai ser exatamente do jeito que ele quer. E não é esse o objetivo. O objetivo é que a sua empresa ou a sua equipe possa fazer o software e que consiga que o cliente saia satisfeito no final do projeto com aquilo que ele tem, e que aquilo seja útil para ele utilizar. Então, frases, que a gente escuta aí. "Ai, esses clientes nunca sabem direito o que eles querem, às vezes, eles pedem monte de coisas que não fazem o menor sentido, que não está na hora, que não tem lógica, e tudo o mais. E aí o que é que acontece? A gente vai, faz do jeito que eles pediram, e aí depois eles querem mudar tudo de novo, colocar novas coisas, sem que isso dê tempo para a gente trabalhar cima do software. Ou seja, ai, eu quero mais isso." Só que o tempo para você fazer não muda. Então toda essa questão, essa rixa aí dos desenvolvedores, das equipes com os clientes, muitas vezes fazem com que a gente considere os clientes ali uns inimigos, ali. "Pjew! Pjew! O cara está querendo mudar o requisito ali. Pjew! Pjew! O cara ali pediu negócio que não tem nada a ver. Pjew! Então, como se fosse o cliente querer atrapalhar tudo. E aí acaba sendo nossos inimigos, nossos adversários nessa história. E aí, que é que a gente faz? Qual é que é a nossa proteção? São os contratos. O pessoal acaba usando ali o contrato como escudo, de que na hora que o cliente falou "Olha, eu quero então isso daqui". O cara vai lá faz o contrato, de preferência com uma documentação enorme, como a gente falou na aula anterior, e aí faz o cliente assinar aquilo ali, que aquilo ali que o software tem que fazer e aí qualquer mudança, qualquer coisa que o cliente quiser fazer diferente daquilo, você tem o contrato. " não sei quê..." Pjew! Pjew! Pjew! vem ali o disco voador, aqui, né? Pjew! Pjew! Pjew! O cara acata o contrato. Pjew! Pjew! Pjew! Não, não pode mudar nada. Pjew! Pjew! Pjew! para se defender dessas alterações do cliente. Como se o cliente estivesse ali para atrapalhar o desenvolvimento. Olha que absurdo! Mas, espera aí. Esse cliente não é o maior interessado que o projeto dele dê certo? Que tenha sucesso? Será que logo no começo do projeto quando você está levantando os requisitos e tal, o cliente tem maturidade para definir aquele monte de coisas? Será que não é quando ele vê o software funcionando que vai cair a ficha de algumas questões, quando ele começa a usar o software que ele tenta simular o uso do software, que ele vai perceber que certas coisas não estão certas ou que certas coisas não vão funcionar na prática? Quem aí que já trabalhou com desenvolvimento de software que já não viu isso acontecer? Convido vocês aí que tiveram esse tipo de experiências para colocar no fórum, coloquem aí nas mensagens, compartilhem com os seus amigos as suas histórias. Eu tenho certeza. Comigo, eu já vi isso acontecer várias vezes. Exemplo que eu posso citar, por exemplo, eu tinha lá formulário enorme, o cara tinha que fazer uma configuração, aí o cara lá cadastrando digitava tudo, ok. E aí, o que acontecia? Ele percebeu que a segunda coisa que ele teria que cadastrar seria muito parecida com a primeira e aí seria pouco eficiente ele ir lá e digitar tudo de novo. Então ele poderia abrir o anterior e editar, mas ele estaria alterando aquele mas o que ele queria era o quê? Ele queria criar novo a partir de modificações do anterior. Ele só percebeu isso no momento que ele estava usando o software. Então, ele falou assim: "Será que não tem aqui uma forma de eu selecionar alguém e pedir para usar esse como modelo do próximo?" Opa, é uma nova funcionalidade. O cara percebeu depois, na hora que ele estava especificando os requisitos, aquilo não veio na cabeça dele, foi na hora de usar que ele percebeu. Então, eu deixo aí a última pergunta. Será que não é melhor trabalhar junto com o cliente ao invés de disputar com ele? Precisa de contrato? Precisa, principalmente se forem empresas diferentes. Mas será que tem que amarrar todos os requisitos? Será que não pode determinar uma forma de trabalho, determinar modus operandi para quando o cliente mudar de ideia? De repente, ao invés de ter uma entrega no final, ter várias entregas e ter mecanismo no próprio contrato que diga como fazer isso. Tem muito material aí sobre contrato para projetos ágeis aí na Internet. Muitas vezes há equipes de desenvolvimento da mesma empresa e às vezes não precisa dessa formalização toda, mas se faz, se cria documentos só para amarrar o cliente, só para evitar esse conflito. Então, a ideia do desenvolvimento ágil é você colaborar com o cliente, falar assim "Olha, é o seguinte, a gente quer fazer o software o melhor possível para você, só que a gente não sabe." Aqui, uma ou duas semanas de projeto, três semanas no máximo. "Está aqui, primeira versãozinha das primeiras coisinhas que você pediu. Será que é isso mesmo que você quer?" Aí o cara olha. "Não, isso é diferente, e tal". Mudança do cliente aqui, é lucro, principalmente quando é no começo do projeto quando é nas primeiras versões. Porquê? Porque essa mudança do cliente vai fazer com que aquele erro não tenha sido guardado para o final do projeto, quando o cara era para estar recebendo o projeto final. Então a ideia aqui é trabalhar junto com ele. Então, ao invés de tomar todas essas decisões, de obrigar o cliente a tomar todas essas decisões de requisitos no começo do projeto, ele vai dando feedback, vai acrescentando, vai priorizando aquilo que é mais importante, a ideia é que depois por exemplo, passado ano de projeto, pode ser que o que você entregue não é exatamente aquilo que ele chegou pedindo para você. Mas com todo o feedback que ele deu, vai ser o melhor produto possível que a sua capacidade produtiva permitiu você fazer aquele num ano. E o cara vai estar feliz. E aí junto com o cliente é possível você ir refinando o produto e chegar num objetivo que seria impossível sem ele. Como eu falei, ágil é você responder rápido às mudanças. É você reagir rápido, é você ver o que o cliente está achando e conseguir ter tempo para ir adaptando o software de acordo com as necessidades dele. Lógico que se o cliente começar a alterar demais isso é problema. A gente tem que sentar e acertar as coisas, mas sempre colaborando com o cliente, não ignorando os contratos, mas vamos dar preferência para sentar juntos e trabalhar juntos do que a manter a distância com o contrato como escudo entre a equipe e o cliente. Certo? Então, com isso a gente viu a importância de ter a colaboração com o cliente e vendo que às vezes focar muito contrato, você pode até ir lá e receber o que estava combinado, mas você não vai estar muitas vezes entregando aquilo que o cliente realmente precisa. Então é isso. Espero que tenha entendido e espero vocês na próxima aula com o último item do manifesto ágil. [MÚSICA] [MÚSICA]
