Tão importante quanto escrever linhas e mais linhas de código
é você também fazer a gestão do seu projeto,
e, ao término, você criar o seu produto e entregá-lo documentado para o seu cliente.
Se você está pensando que hoje você vai escutar mais um podcast
falando sobre linguagem de programação,
que seja do front-end ou back-end, não, não é isso.
Nós vamos falar sobre a gestão,
que é a parte tão importante na entrega de um software.
Eu sou o Rafael Ronqui e estou aqui com dois convidados.
Vou apresentar para vocês o Alexandre.
Olá, Alexandre, tudo bem? Como você está?
Tudo bom, Rafael?
Obrigado pelo convite.
Eu trabalho hoje como responsável de operações Brasil da Softtek.
É um prazer estar aqui com você.
Show!
E aí, Eduardo, tudo bem? Como você está?
Se você puder apresentar para quem está nos escutando, por favor.
Claro.
Primeiramente, obrigado pelo convite, Rafael.
Bom, meu nome é Eduardo Floriano, eu trabalho há dez anos na Softex,
sou responsável por algumas verticais de negócio, pelo delivery,
então eu tenho que gerenciar alguns projetos aí,
ou melhor, algumas centenas de projetos.
Então o desafio é bastante interessante.
Legal.
Então eu acho que a conversa vai estar boa,
principalmente porque vocês tem a vivência na prática, no dia a dia, né?
Falar aqui que nem é só a visão, mas sim a vivência.
Para quem está nos escutando,
é legal setar o que é a gestão de projetos, uma definição.
Lógico, né, vamos seguir o PMI/PMBOK, início, meio e fim, né?
Fiquem à vontade, Alê ou Edu, para definir.
Na visão de vocês, o que é a gestão de projetos
dentro de desenvolvimento de um software?
Eu acredito que, antes de falarmos da gestão de um projeto,
temos que olhar para um cenário de governança...
Porque depende do tipo de projeto, depende do tipo de necessidade,
e também depende do tipo de apoio que você vai dar para a organização.
Você precisa estabelecer uma governança
sobre todo esse arcabouço de projetos que temos hoje
implementando na prática.
Quando falamos de um projeto, o projeto é uma atividade bem clara,
onde você tem um início, um meio bem-definido, e o fim.
Então isso caracteriza o projeto.
O projeto é composto de uma fase inicial,
onde é necessário planejamento,
porque em cima do planejamento você vai determinar esses recursos,
e esses recursos têm que estar ligados à sua estratégia de governança
dentro da implementação de qualquer tipo de projeto.
Terminou essa parte do planejamento, definiu bem essas atividades,
tem que colocar os recursos, que é a parte mais importante de um projeto.
Às vezes brincamos que temos a metodologia, temos o processo,
mas apesar de dizerem que 70% de um projeto
são a metodologia e os processos,
o mais importante é você ter o colaborador daquele projeto
endereçando a execução na prática do dia a dia.
Então, para mim, são esses os elementos importantes
quando falamos de um projeto.
E aí você vai ter projetos de diferentes dimensões,
diferentes tamanhos, e diferentes propósitos.
Melhorias evolutivas, projetos do zero,
onde você vai fazer um desenvolvimento completo,
uma implementação de um RP, que é a característica de um projeto.
É diferente de um projeto de desenvolvimento de software.
Você tem projetos ligados à parte de manter a empresa funcionando.
Então você tem o dia a dia da empresa que está funcionando.
Muita gente fala de ambidestria da empresa.
Você tem um lado que precisa desenvolver a empresa
e tem um outro lado que precisa manter a empresa.
Então, como que você lida com isso.
Por isso eu falo que a governança é um ponto importante
dentro das diversas estratégias que temos
para implementação de um projeto na prática.
É legal ouvir isso aí de você, Alê, principalmente porque essa brincadeira...
Eu sabia que você ia falar que esse projeto não é só o início, meio e fim, né,
mas tem todo um contexto por trás.
Por exemplo, se uma empresa quer implementar algo
sem fazer a gestão de projetos, faz sentido,
até porque tem uma governança sobre isso.
Exatamente.
E aí você trouxe uma sopinha a mais, porque às vezes você pega um aluno nosso,
que começou agora a desenvolver, e ele pensa: "Só vou desenvolver um e-commerce".
E não é só isso.
Às vezes vai ter um RP que você quer implementar
numa empresa de grande porte.
Exatamente.
Você trouxe toda essa sopa.
Edu, nós já estudamos junto aí, nós brincamos que,
quem sobe muito a regra complica para o próximo, né?
Não que você não consiga sair bem dessa, né?
E aí? O que você tem para complementar?
O que é a gestão de projetos aí?
Bom, Rafa, ainda bem que nós estudamos juntos.
Você me conhece um pouquinho aí.
E sorte a minha que ele deixou pouca coisa para eu falar, né?
Ainda bem que eu trabalho com ele, e é meu amigo também, né?
Então já nos conhecemos há um bocado de anos.
Faz mais de 15 anos que nós trabalhamos juntos...
Dez anos trabalhando juntos.
Então foi treinada essa conversa aí?
Não, não foi treinada.
Ele complicou. Ele sempre dificulta um pouquinho a minha vida.
Só para saber como você se sai.
Pois é. Mas vamos lá!
Eu vou tentar simplificar um pouco mais a abordagem que o Alexandre colocou,
que foi bem completa.
Mas eu colocaria o seguinte: quem quer gerenciar projetos
tem que ter em mente que é gerenciar crises e mitigar riscos,
ou seja, não vai ter projeto que você não vai encontrar problemas para serem resolvidos.
Tem riscos então?
Quase nada.
- Quase nada? - Quase nada.
- Só para saber. - Quase nada.
Você acha que vai acontecer?
Monitora porque pode acontecer.
Então eu acho que o principal ponto da gestão de projetos
é o monitoramento dos riscos, a mitigação dos riscos,
e a habilidade de gerenciar problemas,
porque problemas vão acontecer.
Então, esses são os principais requisitos que eu entendo no gerenciamento de projetos,
seja ele ágil, seja ele uma metodologia tradicional,
que é cascata, "whatever".
Então, já que você falou isso, de puxar outro tema,
nós tentamos definir o que é gestão de projetos,
sem falar a tal gestão do PMI, do PMBOK, ou ágil.
Será que conseguimos trazer essa sopinha para a mesa da conversa,
essa quantidade de coisas?
Antes até de falarmos de metodologia,
entrar na abordagem métodos, né,
eu acho que temos uma pessoa importante nesse cenário,
que é o gerente de projeto.
Em alguns contextos, o gerente de programa.
O que é um programa?
Um programa é uma coleção de projetos
que serão executados em paralelo, sendo administrados,
e que tem uma integração dentro de um contexto maior dentro da organização.
Essa é uma figura extremamente importante, o gerente,
Por quê?
Por mais que coloquemos metodologias, métodos, processos,
um fator importante é o fator humano dentro de um projeto.
E a gestão, aquele gerente que tem
a melhor habilidade na execução,
que consegue entregar um projeto...
Com qualidade, no prazo,
esse gerente geralmente tem uma habilidade fantástica em gestão de pessoas,
que é um dos elementos importantes quando falamos de projeto.
Porque no projeto, nós vamos ter lá o escopo, vamos ter o método,
vamos ter os recursos físicos e os colaboradores,
que são aqueles que executam o projeto,
e vai ter aquela pessoa que vai fazer a orquestração de tudo isso,
que é o gerente de projeto.
Então, a habilidade do gerente de projeto, para mim, 70% da habilidade do gerente,
está ligado ao relacionamento.
Como ele trata os colaboradores, como ele agrupa e gerencia aquele time,
como ele traz o time, engaja aquele grupo,
para entregar bem aquele projeto.
E aí podemos falar que, dentro de um cenário,
existem metodologias melhores para determinado tipo de problema.
Existe o ágil, que vai atender bem um determinado tipo de problema,
existem métodos em cascata, ou métodos orientados à implementação de RP,
que geralmente estão atrelados aos fabricantes.
São processos que o próprio fabricante coloca
para você poder desenvolver, poder seguir,
poder trazer dentro de uma implementação.
Porque não é só no desenvolvimento de software
que vamos ter uma gestão de projeto.
A gestão de projeto pode ter em diversos ramos de atividade.
Até numa construção, que se pegarmos a engenharia de software,
que ela é nova dentro desse cenário de desenvolvimento,
a própria construção já faz gestão de projetos,
faz a gestão da obra há muito tempo, aplica métodos e também faz gestão de pessoas.
Enfim, gestão completa de um projeto.
E a área de tecnologia se apropriou muito desses tipos de abordagem
de outras áreas em diversos...
Se falarmos em diversos ramos da tecnologia,
nos apropriamos de alguma área do conhecimento
e implementamos dentro do nosso processo.
E a gestão de projetos é isso, desenvolvemos melhor
para dentro das nossas atividades de engenharia de software.
Mas não é só um tipo de problema que temos que resolver
quando falamos de gestão de projeto.
Vai depender da necessidade.
E aí você vai ter a metodologia que melhor se adaptar a essa necessidade.
E, Rafa, até para complementar o que o Alexandre colocou,
eu acho que vale a pena colocarmos o viés do colaborador,
que é o participante do projeto.
Tem o gestor, mas também tem o executor, vamos dizer assim, do projeto.
E tem os executores que querem se tornar líderes,
querem se tornar gerentes dentro das organizações, gerentes de projeto.
O que eu acho que é superrelevante colocar,
e que corrobora com o que o Alexandre colocou,
é primeiramente a questão da comunicação, a questão de como lidar com pessoas.
Tanto a parte gerencial quanto a parte dos colaboradores, dos...
Não vamos falar colaboradores.
Dos executores, propriamente dito, dos desenvolvedores,
eles têm que ter hoje uma capacidade de comunicação muito alta,
muito bacana, entre todos os membros do time, inclusive com o gestor dele.
Então, se estamos falando de ágil, estamos falando com o Scrum Master.
se estamos falando de um projeto mais formal,
estamos falando de um gerente de projeto, propriamente dito.
Então eu acho assim:
aqueles que buscam a liderança,
seja ele como gestor, seja ele como Scrum Master,
tem que ter essa capacidade de comunicação.
Eu digo que gerenciar é 90% comunicar
e 10% você trabalhar com cronogramas,
trabalhar com Kanban, trabalhar com processos.
O principal é comunicação.
Além disso, ter atitude.
Para um projeto ser bem-sucedido, se as pessoas que estão nesse projeto
tiverem atitude positiva, atitude de realizar,
a grande probabilidade de sucesso é enorme nos projetos.
Legal ouvir isso, Edu e Alê,
porque eu fiz um MBA em 2011, "Gestão de projetos nas práticas do PMI",
e o meu TCC foi focado na gestão da comunicação.
Que foi o que você falou, é a habilidade de lidar com as situações.
Eu acho que foi o Ale que falou.
Nós já sabemos quais são os recursos, qual o escopo, qual o custo previsto.
Antes de começar, você já tem todo esse levantamento.
O projeto vai começar, quem vai fazer essa maestria de tudo andar bem sincronizado?
É uma pessoa com habilidade de se comunicar, de entender, de mapear o risco.
E é uma coisa que não vem pronta, né, Ale? Né, Edu?
- Não vem pronta. - Não.
Que legal o que vocês falaram, porque quando nós trazemos para o aluno,
eles acham que, na primeira aula, já vamos explicar o que é PI
e também o que é ágil e Scrum, por exemplo.
Nós falamos: "Não, calma!
Vamos falar primeiro que o projeto tem início, meio e fim.
Foi o que você falou.
Mas, antes, vamos falar algumas coisas, como você ter habilidade para participar do projeto.
E aí o aluno às vezes até fala para nós: "Professor, você está muito acadêmico.
Solta o mundo da vivência do profissional".
É por isso até que convidamos vocês.
E foi até provocativo.
Foi legal você quebrar.
Vamos falar do PMI, ou seja, em cascata, e vamos falar do ágil.
O Ale falou: "Não, antes, vamos falar dessa habilidade,
das coisas que acontecem antes do projeto".
E vocês tocaram no tema de percentual dentro do desenvolvimento de um projeto de software.
E os alunos às vezes acham que, 90% do tempo alocado em um projeto é código, por exemplo.
Vocês já quebraram com alguns percentuais aí.
Importante assim, né...
Código dentro de um projeto é 30%...
Quando você coloca dentro uma métrica.
Porque se você não definiu bem seu escopo,
se você não realizou uma entrevista, um levantamento, um mapeamento,
independentemente da prática ou o método que você utilize,
ágil ou processos unificados, que seriam mais voltados para a parte de cascata.
Então você tem a fase de análise...
Quando você faz a análise, você tem que ir lá no seu usuário
entender o problema dele, discutir com ele,
especificar o problema.
Depois que você especificou o problema, pensar como vai resolver o problema.
E aí, antes de ir para o código, você ainda vai ter que chamar um cara de arquitetura
e falar: "Cara, tem esse problema aqui.
Como vamos criar uma arquitetura que suporte solucionar esse problema?".
Para depois você falar: "Olha, pensei em tudo.
No escopo, na especificação, na arquitetura.
Criamos uma arquitetura para a organização
que pode ser implementada de forma coerente".
E aí você vai falar: "Puxa, agora vamos trabalhar o código".
Trabalhou código, aí você entra numa outra parte, que é a parte da qualidade do código.
Eu tenho que testar, eu tenho que verificar,
tenho que fazer uma validação,
e depois ainda tem que ter um aceite desse usuário para colocar em produção.
Então, um projeto não é código.
O código é uma parte dentro do projeto.
E se não você não pensar as outras partes desse projeto
de forma coerente, a hora que você implementar o código,
você pode desenvolver algo que, lá na frente, vai ter problema de performance,
você vai ter problema de integração,
você vai ter problema de lentidão da organização
porque não vai conseguir utilizar a ferramenta.
Você pode ter problema de usabilidade porque você não pensou
como que o usuário vai utilizar aquela ferramenta.
Então existem vários elementos importantes
antes de chegar no código.
Não é de agora que analisamos dessa forma.
Nós brincamos que hoje, com a transformação digital, todo mundo quer inovar,
sairdesenvolvendo soluções dentro das organizações.
Isso não é evento novo.
Na década de 1990,
existia um conceito chamado "reengenharia".
Todo mundo queria redesenhar seus processos
e aplicar tecnologia para resolver problema.
Na década de 1990.
Será que só mudou nome, ou monetizou?
O que você acha?
Nós temos alguns outros elementos que a transformação digital traz
dentro desse cenário da reengenharia, que, naquele tempo,
não tínhamos nem tantas ferramentas, nem tantos métodos,
e ainda nem tínhamos descoberto essa integração tecnologia/negócio.
Ainda estávamos engatinhando naquele tempo.
Então foi o tempo que começou a se criar, desenvolver.
Foi quando veio a internet, e aí o boom do crescimento tecnológico nas organizações.
... tecnologia, né?
Exatamente.
Só que hoje não é só código que você tem que pensar,
porque você pode estar desenvolvendo várias coisas dentro da empresa
e estar criando novamente um problema que no passado criaram.
Durante a reengenharia, existiam várias áreas
que começaram a querer desenvolver
as suas próprias ferramentas internas nas áreas,
e onde contratavam um profissional de TI.
Eu posso falar que eu trabalhei numa situação dessa,
onde eu trabalhava na área, não na TI,
para desenvolver diretamente para aquela área
onde perdeu-se o controle da tecnologia
que estava dentro organização.
E quando veio o advento do ano 2000
e com a chegada dos RPs, foi o gancho que teve.
Para quê?
Para que as empresas pudessem se reestruturar, se reagrupar,
reagrupar e centralizar novamente a tecnologia,
e pensar na arquitetura da empresa.
E se você pensar que arquitetura corporativa
também começou na década de 90 para cá,
arquitetura corporativa tem o primeiro grande artigo do Zackman,
que foi o cara que escreveu a arquitetura corporativa,
pensando o quê? "Cara, vamos estruturar a organização
e vamos criar uma arquitetura que integre tanto a TI como o negócio,
para que você possa aí começar a olhar
e sair desenvolvendo dentro da organização.
E o RP ajudou muito nisso, porque o RP,
por ser um software que já tinha sua própria integração, tinha seus elementos,
já tinha todas as boas práticas implementadas,
ajudou porque você já tem a arquitetura pronta ali.
É legal você falar da RP, Ale,
até para quem está nos ouvindo aqui,
RP é um sistema que você pode comprar, por exemplo,
empresas como o Tottus, como o SAP, e você compra por módulos.
Se você quer a área de RH, a área de logística,
você vai lá e compra, instala tudo de uma vez, o que não é adequado,
ou instala por módulos.
Eu vivi uma vez uma mudança de cálculo de frete para uma multinacional,
que lá era o SAP.
Abriu-se um projeto para isso.
Fizemos um levantamento de escopo, mapeamento, muitas horas alocado,
muitas pessoas para isso, e no fim, o desenvolvimento feito desse SAP
foi de horas, tipo 10%.
Vamos supor que foram 500 horas de projeto.
Se foram 40 ou 50 horas desenvolvendo, foi muito.
Mas qual é a parte boa?
Se foi bem levantado, bem documentado.
Nem estamos falando de tipo de gestão.
Entrou em ambiente de regression, prod...
Aí subiu.
E olha que legal o que você falou.
E deu certo.
Mas aí você vai me falar: "Qual que foi feito?".
Nós não fizemos nesse que talvez fosse um pouquinho mais rápido, né,
que daqui a pouco tentaremos definir.
E aí, Edu, você acha que dá para falarmos um pouquinho dessa definição?
Dá sim.
O Ale colocou um tema...
Está apimentando, hein? Está apimentando.
Eu acho que até extrapolou a gestão de projeto.
Ele colocou um tema estratégico, né,
falando de arquitetura corporativa aqui...
- Que as coisas tem que andar juntas, né? - Juntas, né, TI e negócio.
Já colocou um plus dentro da conversa.
Dificultou mais, né, mas eu acho que agrega mais
para todos nós aqui.
E aproveitando, Edu e Ale, vocês ajudam quem está nos escutando
a saber que, o que o Rafa e os outros professores trazem,
não é coisa acadêmica.
Obrigado!
Isso não foi treinado.
Você foi contou a verdade aí.
Não, não, é isso mesmo.
Não teve script prévio.
Não teve script prévio, não teve treinamento nenhum, tá?
- Saiu na raça aqui. - Fluido.
Fluido.
Que bom! Se não for, eu faço disclaimer aqui, tá bom?
Não, não, não. Está fluido.
- Pode ficar à vontade aí. - Vamos lá.
Eu acho que é importante...
Como o Ale, comentou, como você comentou,
o código é uma parte importante e significativa.
Mas antes de falar disso,
é também para tranquilizar o pessoal que está nos escutando,
não fiquem preocupados ou com medo de entrar na área de gestão de projeto, em projetos,
mas em qualquer outra profissão, qualquer outra atuação da sua atividade profissional,
vão existir desafios.
Eu vou falar para vocês que, projetos, para quem gosta de desafios,
é um excelente ambiente para se trabalhar.
Em projetos, vão existir diversos tipos de desafios a serem superados.
E eu gostaria de colocar, Rafa, o seguinte ponto:
estamos falando muito de metodologia, de processo,
da questão estratégica dentro da organização de mitigação de riscos.
Eu falei um pouquinho lá atrás de gestão de problemas.
Mas imagine assim: nós ainda não falamos do nosso...
Nós falamos que tem escopo, prazo, custo.
Mas imaginem vocês dentro...
Parece simples o projeto, né?
Mas imaginem vocês que o executivo separa um valor,
um montante de dinheiro, o budget, de 100 mil reais...
Eu vou colocar um valor hipotético aqui.
Supondo que é alto, né?
É, supondo que é algo, tá,
mas às vezes são projetos de milhões.
Em SAP, nós falamos em milhões.
Mas vamos colocar um número aí de 100 mil reais.
E que, durante o projeto, você identifique situações
em que você não vai conseguir atender àquele escopo,
e por não conseguir atender àquele escopo,
ao invés de custar 100 mil reais o seu projeto,
que você já informou à sua presidência,
você vai ter que informar que ele vai custar 200 mil reais.
Olha a complexidade que o gerente
do time que está sendo gerenciado
prover informações para convencer
o seu presidente, o CEO, que seja,
desse pequeno dobro de valor.
Então, são situações complexas como essa
a serem administradas dentro do projeto.
E aí existem aqueles velhos costumes.
Vamos identificar quem são os culpados.
E, na verdade, não funciona assim, gente.
Quando um projeto falha,
existem percentuais de falhas em diversos locais.
Não é só um local que falha.
São diversas falhas que aconteceram, e aconteceu uma falha grande.
Então tem que se trabalhar a causa raiz, identificar essas causas,
os efeitos que elas geraram, consequentemente os impactos,
trabalhar planos de ações, e contra argumentar com o presidente
e pedir mais dinheiro, o que não é fácil,
não é fácil.
É uma situação bem complexa e acontece no dia a dia.
A responsabilidade que tem um gerente nesse sentido é bastante alta, Rafa.
Eu gostaria de colocar esse ponto porque eu acho que vale.
Eu achei legal porque está vinculando a parte de levantamento de escopo, né?
Se você está fazendo a gestão, fez a previsão de 100 mil,
mas você faz ali um levantamento
que o budget não reflete devido ao que você levantou...
"Temos esse budget, mas baseado em todas as entrevistas,
o que nós conversamos e levantamos em x dias na empresa, não vai atender.
Não é que não queremos fazer o gourmet para vocês.
É que não vamos entregar conforme a necessidade".
Aí eles tentam muitas vezes diminuir o escopo.
Aí às vezes você pode falar que é melhor nem fazer, né?
Às vezes é melhor nem fazer.
Mas se tiver bons argumentos,
que seria essa documentação, essa conversa, tudo que você levantou...
Não foi você que levantou, não foi você que criou.
Foi a equipe da empresa que passou toda essa parte de escopo, né?
E aí vai muito na linha do que o Ale comentou,
da parte estratégica também, financeira.
Um projeto tem que trazer algum resultado para a empresa.
Normalmente é alguma otimização processual,
alguma otimização da produção, que traga venda, aumento de venda,
ou seja, que traga algum benefício tangível, normalmente financeiro, para a organização.
Se você conseguir provar que, de 100 mil para o projeto
passou para 200 mil, mas vai ter tais ganhos,
é uma maneira de você ?.
O famoso ROI.
É isso aí.
Vocês devem defender direto projetos, principalmente na parte de consultoria, né?
Essas conversas devem ser bem agradáveis, né?
Para nós, a defesa do projeto está mais ligada na abordagem
e na estratégia de entrega de como vai ser desenvolvido.
Esse convencimento de que o projeto vai dar retorno,
ou o projeto vai ter um benefício para a empresa,
geralmente parte da própria empresa, parte das pessoas que estão ali
integradas no dia a dia do negócio,
e que, dentro de uma solução, ou dentro de uma estratégia,
ou dentro de uma análise de problema que eles identifiquem,
eles vão trazer uma solução que vai envolver tecnologia,
e, dentro disso, eles vão aí abrir para nós, como consultoria,
oportunidade de participar de um processo de venda da solução.
Muitas vezes nós ajudamos, né, Ale?
E muitas vezes nós os ajudamos a construir a defesa.
Geralmente quem defende mesmo é a própria organização,
os próprios gestores da organização, que, dentro dessa estratégia,
vão levar para o board ou para um comitê
para apresentar quais seriam os projetos
e quais benefícios eles trariam para a empresa.
Mas geralmente são vocês, de consultorias,
que os alimentam com essas informações para eles levarem...
- Para o board da empresa, né? - Às vezes alimentamos...
Participamos de um projeto de...
- Levantamento. - Um projeto mais de consultoria.
Não seria nem um projeto de desenvolvimento nem de análise,
é um projeto mais consultivo,
e aí os ajudamos a desenhar a solução, a ideia,
e como resolver o problema.
Mas quem vai defender isso de fato
vai ser a própria própria empresa,
os próprios gestores perante a empresa.
É legal o outro tema que você trouxe aí, Ale.
Acabamos, falando de ROI, mas nem sempre um projeto de desenvolvimento de um sistema,
seja de implementação de um SAPI,
é só voltado para a parte do retorno financeiro.
Às vezes você está fazendo uma implementação para mitigar risco fiscal,
ou a operação parar.
Indiretamente, por trás, corre a parte financeira.
E aí, ter essa visão de processo
e até mesmo essa parte fiscal, ainda mais brasileira, é bem difícil, né?
E é importante também olharmos que às vezes um projeto
pode ser uma evolução tecnológica.
Muitas empresas demoram para investir em tecnologia.
E um dos problemas que as empresas têm hoje
é a obsolescência tecnológica, tanto de hardware como de software...
Porque é um ativo que, muitas vezes, já está...
Não tem uma reposição dentro da organização.
Na parte sistêmica e de software,
não tem uma evolução daquela ferramenta,
a evolução da própria ferramenta para uma nova tecnologia.
E aquela empresa acaba ficando com um parque tecnológico obsoleto.
Muitas empresas hoje que querem ir para um processo de transformação digital
encontram dificuldade porque a sua arquitetura
ainda é uma arquitetura monolítica.
Então ele precisa se atualizar em muitas coisas ainda
para poder começar a trazer novos elementos
de inovação, de transformação, para dentro do negócio.
Então, esse é um ponto importante que tem que ser pensado dentro das organizações.
É legal você falar, porque às vezes ele quer implementar uma tecnologia,
mas às vezes para implementar aquela nova tecnologia com aquele projeto, antes,
ele tem que tomar outras ações antes.
- - Ele tem que redesenvolver o seu sistema
para que esse sistema possa integrar com a nova tecnologia,
ou criar uma situação ali de convivência,
onde você convive com a sua situação atual
e o que você está trazendo para o futuro.
Só que sempre tem uma perda né,
porque o meio natural é a obsolescência da tecnologia
e você acaba perdendo algumas vantagens, dependendo da tecnologia.
Então, é isso que também é importante olharmos nesse cenário
quando vamos falar de criar novos projetos, fazer inovação, desenvolver novas soluções.
E até pegando isso, quando falamos no mundo corporativo, pessoal,
não é o país das maravilhas, tá?
As pessoas que estão iniciando agora, vocês que estão iniciando agora,
muitos na área, vão encontrar...
"Pô, vou lá, chegar e desenvolver?".
Não. Você vai desenvolver, você vai chegar a desenvolver,
você vai entender o projeto,
mas você vai ter que seguir algumas regras e padrões, inclusive de conformidade.
Os requisitos legais, né?
Hoje nós temos o LGPD,
que são as políticas de Cyber Security..
Plantar diretamente no código...
Pois é. Você tem as questões que você vai ter que seguir.
Não é sentar-se lá simplesmente e desenvolver e está pronto.
Não. Você vai ter uma documentação,
você vai ter que seguir essa documentação,
alguém vai validar, vai fazer um peer review...
"Pô, o que você está fazendo, está certo mesmo?".
Ou ter ferramentas para validar se aquilo que você está desenvolvendo
está em conformidade para garantir acessos indevidos,
para não ter violação de dados.
Então, assim...
Não existe país das maravilhas.
Tem que colocar a realidade aqui, certo, Rafa?
Tem que colocar... Pode colocar, né?
Pode. Você até trouxe um ponto,
porque às vezes o nosso aluno, quando corrigimos uma atividade...
"Pô, Rafa, você me tirou 10% da nota porque eu não segui a boa prática.no código...",
ou não fez a identação do código, ou não comentou código.
Estava escrito no exercício.
Se você entregar funcionando, mas não seguir a boa prática, perde tais pontos.
Aí ele pergunta por quê.
Porque dentro de uma governança, dentro de uma gestão de um projeto,
dentro uma empresa, você tem que segui-la porque você não está trabalhando sozinho.
Mesmo que estivesse trabalhado sozinho, você deixa esse código
e alguém provavelmente vai fazer reengenharia depois,
ou vai ter que analisar para criar um novo sistema.
E o exemplo clássico, né?
Porque, por exemplo, falamos de programação, né?
Eu já fiz várias entrevistas na época,
quando eu ainda cuidava dessa frente de desenvolvimento.
Eu perguntava: cara, o que acontece se você fizer
um select, asterisco, dentro da base?
Será que trava essa pergunta?
Você vai fazer?
Não, não faz não, espera aí!
Aí o cara olhava e falava: "Mas que pergunta é essa?"
Você sabe o impacto que você tem em colocar um select, asterisco?
Sem o para travar, né?
Pois é.
Porque se você colocar isso no seu código,
você vai ter o impacto lá na frente.
No quê? Em performance.
Dependendo do tipo de dado que você está acessando,
do tipo de tabela que você está acessando.
Então não é uma boa prática você utilizar isso dentro do seu código.
E geralmente as empresas têm os seus manuais
de boas práticas de programação, regras de programação.
Então são perguntas que eu fazia na entrevista
para já mapear o quanto aquele desenvolvedor
tinha habilidade para desenvolver determinado tipo de código,
ou para onde eu iria direcioná-lo para o desenvolvimento.
Você falou de um ponto que eu vivi.
Eu trabalhei numa multinacional e comecei como desenvolvedor,
e aí eu estava atendendo a área de vendas,
a área de vendas de uma multinacional com uma base muito alta,
e aí veio escalado da alta gerência, de um desenvolvedor júnior,
um e-mail falando por que temos que formar,
qual é o range de clientes que queremos enxergar.
Eu quero clicar e baixar toda a base de clientes.
Por sorte, eu, desenvolvedor júnior de muitos anos,
eu tive a maturidade de perguntar ao meu coordenador técnico:
olha, veio escalado da alta gerência de vendas.
Ele não tem culpa.
Mas eu entendo que, se eu atender e tirar o "where" daqui...
Foi o que você falou, rapidinho, tira sobe ali em teste,
aí não vai dar impacto para subir para a produção.
Só que, se eu subir isso daqui, o outro usa o relatório, se o sistema não cair.
Até explicar para essa pessoa, esse executivo da área de vendas,
que, se eu fizesse isso, ia atrapalhar a performance, ia dar stress.
Foram falar com ele, e ele falou: "Então comprem um servidor novo".
Nem se você comprasse ia resolver, ainda mais há um tempo atrás.
Bem interessante essa fala.
Mas, por alguns segundos, eu, como um júnior,
eu vou ser bem transparente, pensei em fazer.
Na hora que veio escalado, quase levando uma bronca,
eu, como desenvolvedor, falei: espera aí, isso não faz sentido!
Sorte que eu consultei.
E isso conta como maturidade, né, Rafa?
Existem passos, né?
Você pode ter uma excelente lógica de programação, que é fantástico, né?
- Select/asterisco lá, deixa rolar... - Vai embora, vai embora!
Vai travar tudo ali.
Mas você mede a senioridade inclusive sobre isso.
Mas que impactos que eu posso ter fazendo isso?
Então são etapas que você acaba adquirindo
não somente com o aprendizado da linguagem de desenvolvimento,
mas com a experiência, a vivência que você tem dentro dos projetos.
"Pô, eu fiz isso aqui, eu vi isso aqui...
Isso aqui pode impactar.
Pô, se eu fizer isso aqui, eu não sei o que pode acontecer,
mas deixe-me fazer uma POC aqui para ver se pode gerar impacto".
Mas vou te falar, Edu, que, na pressão, a hora que vi o e-mail...
- A vontade era fazer. - Tem a pressão, né?
Eu juro para vocês.
Até hoje eu lembro.
Serviu de experiência, crescimento mesmo.
Eu falei: espera aí, eu o atendo, mas o meu coordenador técnico aqui...
Vai dar ruim.
Aí eu falei: Sérgio, só uma pergunta:
se ele quer fazer, eu faço, mas vai parar tudo.
"Ainda bem que você não fez, meu amigo.
Me dá esse problema que eu vou falar com essa pessoa."
Não foi fácil.
Ele teve que lidar com uma situação de conflito.
Inclusive esse é o tipo de desafio que um gerente tem.
Determinar, identificar quem são esses colaboradores
que vão trabalhar com ele,
qual o nível de senioridade,
que tipo de desenvolvimento é melhor para cada um poder desenvolver.
Hoje nós falamos que tem o front-end e o back-end.
Isso já é um tipo de segregação de função para o desenvolvedor.
Tem profissionais que vão conseguir fazer melhor o front-end,
tem profissionais que vão fazer melhor o back-end,
tem profissionais que conseguem fazer as duas pontas,
Mas, no passado...
Hoje, por exemplo, você tem ferramentas que te ajudam a fazer auditoria no código
ou fazer uma expressão de código.
No passado, ainda não tinha.
E aí?
- Os legados estão aí, né? - Aí é onde...
Entravam as metodologias,
e em algumas dessas metodologias tinha uma etapa importante
que era fazer um peer review no código,
E aí, com a evolução da metodologia, com a evolução das ferramentas,
com a evolução das tecnologias, isso facilitou muito a vida.
Prega o desenvolvimento em pares, né, não seria um peer review.
Mas é basicamente isso.
E tem gente que não quer trabalhar nessa, que fala que é muito estressante.
Porque estressante?
Para mim, é até uma segurança.
Toda vez antes de eu mandar esse código para a QA, Quality Assurance , por exemplo,
passa pelo meu parceiro de revisão, que é o Edu,
para mim, é uma segurança.
Se eu sei desenvolver, não é um problema.
Com certeza!
E eu vou dizer uma coisa para você.
Hoje, a questão de código está tão....
A questão de tecnologia está tão crítica
que, para mim, nós deveríamos ter responsabilidade civil
sobre os códigos que desenvolvemos.
Penal e civil, né?
Ai ele já pegou...Tá vendo?
Por quê?
Porque hoje você desenvolve software para avião, para carro.
Você desenvolve software para...
Né?
Só que você não tem...
- Responsabilidade sobre aquilo lá. - Responsabilidade...
Sobre aquilo que você desenvolveu.
É diferente de você...
Do médico.
O médico não tem...
- Ele vai pedir dez consultas., dez exames... - O CRM dele?
Ele assina por aquilo ali.
Se o seu paciente tiver algum problema, ele é responsável sobre aquilo.
Para você fazer uma construção, não tem um engenheiro que assina embaixo
e vai o CREA dele naquele documento?
Então eu acho que falta na área de tecnologia
algo nesse sentido também,
para que as pessoas criem mais consciência quando desenvolverem um software
ou quando criarem um código, desenvolverem um código,
para algum programa, algum sistema.
Você não está falando em burocratizar, né, Ale?
- Não burocratizar. - Não é isso?
Não. É trazer a responsabilidade
para não ter esse tipo de coisa que você acabou de dar o exemplo.
"Ah, não, eu não quero trabalhar
porque vão fazer uma verificação sobre o meu trabalho."
Não, não estou fazendo uma verificação sobre o seu trabalho.
Eu estou fazendo um peer review para garantir que você não vai ter um problema
a hora que você implementar esse sistema.
Porque às vezes você não viu o que fizeram. Não é por mal.
O seu amigo vai dar um toque para você de como melhorar a performance.
Porque você tem código hoje, programas e softwares,
desenvolvidos em várias situações.
Numa hidrelétrica, você tem software,
você tem software no avião, você tem software no automóvel...
- Na área da saúde, na área de ensino. - Você tem software na área da saúde,
Hoje tem software em tudo quanto é área...
Do conhecimento.
Então, assim, você também deveria ter responsabilidade
sobre aquele código que você escreve.
É legal quando criamos um podcast
e vocês conseguirem trazer esse contexto para quem está nos escutando.
Porque se você achava que você ia ter uma resposta do que é um projeto,
de qual o melhor, a gestão de projeto ágil ou em cascata, ou PMI, ou PMBOK que seja,
em nenhum momento você iria dar uma pausa e fazer uma anotação breve.
Se é uma aula, às vezes o professor faz uma definição...
"Anota aí que vai cair na prova, tá?".
A ideia aqui era para trazer na mesa mais coisas aí, como o Ale e o Edu trouxeram.
E não é para te deixar confuso.
Na verdade, é para você entender que, quando você faz uma gestão de projeto,
não é só olhar o seu documento, pedir para alguém codar
80% do tempo do projeto, e está entregue.
Se for ágil, melhor ainda porque vai fazer a qualidade.
Nem sempre isso é uma verdade.
Se for PMA... "Ah, é um escopo conhecido".
Então depende.
Você negociou com seu cliente?
Então esse era o tópico da nossa conversa.
E aí eu trago para uma última, Ale e Edu.
Fiquem à vontade para quem quiser ser o primeiro.
Para fecharmos, o que você deixa de dica para quem está nos escutando?
Às vezes os alunos que estão nos escutando, alunos nossos da graduação,
já têm experiência, mas começam principalmente na área de desenvolvimento.
Eu comecei, e acredito que vocês também, né?
E aí? Larga a área de desenvolvimento porque é só 30%?
O que vocês deixam de dica para quem está nos escutando?
Uma frase de fechamento de cada um, por favor, um contexto.
Uma dica para quem é desenvolvedor
ou que está na carreira de engenharia de software,
tanto em teste, desenvolvimento, análise...
Migrar para um cargo de gestão, é o que nós colocamos aqui,
vai lidar com pessoas,
pessoas do projeto, pessoas da sua empresa,
usuários, e o cliente, os gestores do cliente.
A pessoa tem que avaliar o quanto ele está se desenvolvendo
em relação ao relacionamento com as pessoas, porque isso é fundamental.
É mais até que metodologia, é mais até que saber codificar ou não.
Então ele tem que definir bem para onde ele quer direcionar a carreira dele.
E hoje nós sabemos que não é preciso
tomar uma decisão de ir para uma carreira de gestor.
Tem pessoas que continuam na trilha técnica
e se transformam em especialistas,
se transformam em técnicos,
em líderes técnicos dentro das equipes,
se transformam em excelentes arquitetos,
e não necessariamente precisam estar num cargo de gerente de projetos
ou num cargo de Scrum Master.
Por quê? Porque grande parte desse trabalho é a habilidade de trabalhar a equipe,
a colaboração do time, para que se consiga,
naquele produto que você se pensou,
chegar ao final com ele concluído,
que entrem em produção e o cliente fique satisfeito,
ou a empresa fique satisfeita, com aquilo que foi feito.
Então, esse é o ponto importante que tem que ser avaliado.
Não pensar só em código ali?
Não pensar só em código.
Se ele tem a pretensão de ser um gerente,
de ir para uma carreira de gestor,
virar um diretor, crescer para um lado mais executivo,
ele vai ter que analisar e ver qual é o gap que ele tem
em relação à parte humana.
A soft skill ali, né?
Exatamente.
Eu queria falar isso, Rafa, eu estava guardando aqui.
Mas pode terminar.
Ele subiu a régua ali de novo!
- É, então, ele sobe a régua. - "Ah, eu soltei a palavrinha do soft skill..."
Deixa a dica aí então, Edu.
Deixa a dica para o pessoal.
O que eu ia falar é o seguinte: eu acho que muitos dos alunos, alguns, pelo menos,
já tenham escutado, né, que, muitas vezes,
as pessoas são contratadas pelos hard skills.
O que são os hard skills?
São os conhecimentos técnicos.
Então, quando você fala em engenharia de software,
você está ganhando conhecimento técnico, que são hard skills,
porém, elas são demitidas pelo soft skill.
O que são os soft skills?
É a capacidade de comunicação, é a capacidade de colaboração,
de como trabalhar em equipe.
Então, a dica que eu dou é: hard skill...
Você vai ser contratado pelo hard skill, por isso que temos que estudar.
Nós aqui, nós três aqui, estudamos muito.
Fazendo Doutorado agora, né, Rafa?
O Ale fazendo Doutorado, e eu parei no Mestrado.
Agora, quem sabe, eu vou no Doutorado.
Vamos ver.
Eu acho que vou.
Mas é superimportante trabalhar essa frente de soft skill,
independentemente da carreira,
se é carreira técnica ou se é carreira gerencial.
E para quem quer ser líder,
uma dica que eu digo é: liderança não é dada, se é conquistada.
Não é necessário você ter um cargo de gestor
para você se tornar um líder dentro da sua equipe.
A própria equipe consegue reconhecer o líder
quando ele existe dentro desse grupo de pessoas.
Então, gente, não precisa esperar virar gerente para se tornar líder.
Normalmente é o contrário.
Você vai se tornar um líder para depois você se tornar um gerente,
ou um executivo, ou um cargo de gestor.
Então vai pra cima sem medo de ser feliz.
Ousadia com responsabilidade...
E bora agilidade, né?
Show!
Eu gostaria de agradecer a sua presença, Ale,
a liberdade que você teve de trazer os temas, de uma maneira até polêmica.
Edu também.
Essa liberdade com certeza soma para os nossos alunos.
Sempre falamos: "Vá além dos nossos materiais
que deixamos disponíveis, onde o professor ensina.
Escutem também os profissionais de mercado que nós trazemos
para vocês verem que, o que cobramos às vezes,
não é porque somos chatos na hora de uma correção,
e sim porque queremos que você entenda que nem sempre o mercado trabalha
como está a cartilha do ágil, por exemplo, tá?
É isso aí!
Edu, eu também gostaria de agradecer a sua presença,
e, da mesma forma, a liberdade que você teve para trazer os temas,
e até mesmo somar para os nossos alunos.
Obrigado!
E você, aluno, deu para entender que, para você fazer uma gestão de projetos,
não basta apenas você saber fazer a gestão,
mas também tudo que tem envolvido.
Eu vou ficando por aqui, e até uma próxima.