Projetos de automação, tais como a construção de grandes equipamentos industriais para linhas de produção, tipicamente seguem processos de desenvolvimento tradicionais muito mais próximos do modelo cascata do que de métodos ágeis. Essa realidade desse tipo de projeto ocorre em função das características que os permeiam, onde, diferentemente de um software, mudanças de requisitos ao longo de sua execução podem representar o completo descarte de tudo o que foi feito e um prejuízo que facilmente ultrapassa a casa R$ 2.000.000,00 somente com materiais utilizados em seu desenvolvimento. 

Contudo, contentar-se esse status quo representaria, provavelmente, uma estagnação na forma como tais projetos eram conduzidos, o que seria inaceitável para uma empresa com tradição em práticas ágeis na Região Norte e que serviu de inspiração e cases de sucesso para outras organizações. Além disso, também seria negar ao time técnico o direito de vivenciarem a conquista de serem autogerenciais, com liberdade de proporem soluções, experimentarem, falharem e corrigirem o rumo do projeto.

Foi nesse contexto, que houve a decisão de se desenvolver esse tipo de projeto utilizando o framework Scrum e práticas do Kanban. Por que não? Tinha tudo para dar certo. Afinal, funcionava tão bem com os times de software.

Bom, os primeiros cases não saíram bem como o esperado. E o grande erro foi acreditar que tudo o que funcionava para os projetos de software funcionaria também para os projetos de automação. Esse erro foi originário da falsa ideia que as pessoas que dominavam agilidade na empresa saberiam como introduzir essa nova cultura em times que vinham desenvolvendo seus projetos tranquilamente usando cascata. Essas pessoas eram de software. Não entendiam a fundo como os projetos de automação eram desenvolvidos. Isso, inicialmente, acabou gerando, inclusive, um pequeno conflito: de um lado os times de software e do outro lado os times de automação (formados em sua essência por engenheiros). E um achando que sabia desenvolver projetos melhor do que outro.

A partir dessa primeira lição aprendida, partiu-se para a estratégia de imergir alguns profissionais, que conheciam e vivenciavam agilidade, nos times de automação para compreender onde seria viável utilizar práticas ágeis e realmente contribuir para o sucesso dos projetos, sem procurar impor “verdades” que eram válidas para outros cenários. E assim foi feito.     

Após alguns anos de experimentos e lições aprendidas, foi possível chegar a um cenário em que (pasmem) conseguimos conciliar práticas ágeis com práticas tradicionais de desenvolvimento, chegando a um método concebido sob medida para os projetos de automação da empresa.

Atualmente, temos dezenas e dezenas de equipamentos industriais totalmente projetados e executados pela FPF Tech e em funcionamento nas linhas de produção de indústrias multinacionais na cidade de Manaus, bem como outras dezenas em desenvolvimento em nossos laboratórios de engenharia. E todos seguiram ou estão seguindo o método proposto e o melhorando constantemente.

Essa palestra tem por objetivo apresentar um pouco dos desafios que enfrentamos ao longo dessa jornada, além de mostrar onde as práticas ágeis e tradicionais são empregadas nesses projetos sem entrarem em conflito.

Nosso intuito não é aparecer como uma empresa que desenvolveu um método de desenvolvimento revolucionário e inovador. Mas sim, mostrar o que vem funcionando para nossos times e que, talvez, possa ajudar outros times também.      

 Carla Oran: Estou na área de desenvolvimento de software há mais de 20 anos, já tendo atuado como desenvolvedora, analista de sistemas, PO e, atualmente, como gerente de projetos. 

João Hidaka: Formado em Engenharia Elétrica pela Universidade Federal do Amazonas, possui quase 10 anos de experiência em desenvolvimento de projetos de hardware e automação.