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 não é 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 já 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 tem 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 a 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 sistema e-commerce".
E não é só isso.
Às vezes você já tem 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ó o desenvolvimento de software
que vamos ter uma gestão de projeto.
A projeção de projeto tem 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 Ale,
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ê 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, 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é falar 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 provocativo.
Foi legal você quebrar.
Vamos falar do PMI, ou seja, em cascata, e vamos falar do ágil.
O Ale falou: "Não, 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á fluído. Vamos lá!fica a vontade.
Lá é assim, eu acho que
que é importante
Como? Como alguém comentou.
Como você comentou, o código é uma parte,
uma parte importante e significativa.
Mas antes de falar disso
e também tranquilizar o pessoal que está escutando a gente que é assim,
não fiquem com preocupados ou com medo de entrar na área de gestão, de projeto
ou em projetos,
mas que em qualquer outra profissão ou qualquer outra alta atuação
da sua atividade profissional, vão existir desafios.
Vou falar para vocês que projetos.
Quem gosta de desafios é um excelente ambiente para se trabalhar projetos.
Vão existir diversos tipos de desafios a serem superados
e eu gostaria de colocar.
Rafa, o ponto seguinte a gente está falando de metodologia de processo.
Já a questão estratégica dentro da organização de mitigação de riscos.
Falei um pouquinho lá atrás de gestão de problemas,
mas imagine assim a gente não falou ainda do nosso.
A gente falou que tem escopo, prazo, custo, mas imagine vocês lá dentro.
Parece simples o projeto, mas imagine vocês que
o executivo separa um valor,
um montante de dinheiro, mas o budget budget de 100.000 R$.
Vou colocar um valor hipotético aqui porque é alto
e alto, mas são projetos que são de milhões e app.
A gente fala em milhões, mas vamos colocar um número, um número
aí, 100.000 R$ e que durante o projeto você identifique situações
que aquele escopo que você está fazendo não vai atender
e que você não vai atender àquele escopo.
E ao invés de custar
100.000 R$ o seu projeto que você informou hoje à sua presidência,
você vai ter que informar que ele vai custar 200.000 R$.
Olha a complexidade que tem
do gerente do time que está sendo gerenciado.
Provêem informações para convencer
o seu presidente que seja o CEO dessa pequeno broker
desse mundo, o dobro de valor de valor.
Então, são situações como essa que são complexas
em ser administradas dentro do projeto.
E aí vão existir aqueles velhos ou velhos costumes.
Vamos identificar quem são os culpados e na verdade tem quem identifique os nomes
e não funciona assim.
Gente, um projeto Quando um projeto falha,
existe 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
e trabalhar planos de ações e contra argumentar com o presidente.
Pedir mais dinheiro 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.
Rafael, gostaria de colocar esse ponto que eu acho que
eu achei legal, até vinculando a parte de levantamento de escopo.
Se você está fazendo
a gestão, fez a previsão de 100.000, mas você faz ali um levantamento
que o budget não reflete devido ao que você levantou.
Vocês tem esse budget, mas baseado em todas as entrevistas,
o que a gente conversou, levantou na empresa em x dias
o não vai atender não é que a gente não quer.
Fazendo o volume aqui para vocês, a gente não vai entregar conforme a necessidade.
Aí eles tentam muitas vezes diminuir o escopo.
Esse falar deles é melhor nem fazer, né?
Às vezes é melhor nem fazer, mas se tiver bons argumentos,
que seria essa documentação, essa conversa,
você levantou que se não foi você que levantou, você que criou,
foi a equipe
da empresa que passou a toda essa parte do escopo.
E aí vai muito na linha do que ela é.
Como em toda a parte
estratégica, também financeira, um projeto,
ela tem que trazer algum resultado para a empresa.
Normalmente é alguma otimização processual,
alguma otimização
da produção que traga algum venda, aumento de venda, ou seja, que traga
algum benefício tangível, normalmente financeiro, para a organização.
Se você conseguir provar o projeto estava 100.000,
vai passar 200.000, mas você vai ter tais ganhos totais, ganhos.
É uma maneira de você encontrar o ROI aí que seja bom ou ruim.
É isso aí.
Você deve defender direto projetos, principalmente vocês.
A parte de consultoria, essas conversas devem ser bem agradáveis.
O fato, acho que para nós, assim,
a defesa do projeto está mais ligada na abordagem
que é na estratégia de entrega de como vai ser desenvolvido
esse convencimento de que o projeto vai dar retorno.
O projeto vai ter
um benefício para a empresa,
geralmente parte da própria empresa ou 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 pra gente não é algo como consultoria,
oportunidade de participar de um processo de
de de venda, da solução.
Às vezes a gente ajuda e muitas vezes a gente ajuda eles a construir
a defesa mais.
Geralmente quem defende o 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 que benefícios eles trariam para a empresa.
Mas geralmente são vocês de consultorias que alimentam ela com essas informações
para eles levarem para as vezes a gente alimenta assim, participa
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í a gente ajuda eles a desenhar
a solução, a ideia é como resolver o problema, mas de fato
é quem defende isso
vai ser a própria própria empresa
pelos próprios gestores perante a empresa.
É legal o tema que você trouxe aí a gente acabou falando de ROI, mas
nem sempre um projeto de desenvolvimento de um sistema de implementação do
s API aí não é só voltada para a parte do retorno financeiro.
Às vezes você está fazendo uma implementação para ter um mitigar risco
fiscal ou a operação parar diretamente.
Ele só trazem qual é a parte financeira e aí tem essa visão de processo
e até mesmo essa parte fiscal ainda mais brasileira.
É difícil
e é importante a gente também olhar que às vezes
um projeto pode ser uma evolução tecnológica.
Muitas empresas demoram
para investir em tecnologia.
É um dos problemas que as empresas têm
hoje é a obsolescência tecnológica, tanto de hardware como de software,
porque é um ativo que já está,
muitas vezes, já está e
não tem uma reposição
da organização na parte sistêmica
e de software, não tem uma evolução daquela ferramenta, daquele
e 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 uma dificuldade.
Por quê?
Porque a sua arquitetura
ainda é uma arquitetura monolítica.
Então ele precisa se atualizar
e muitas coisas ainda para poder começar a trazer novos elementos
e 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 de negócio. Elas.
Se ele quer implementar uma tecnologia, mas às vezes para implementar
aquela nova tecnologia, aquele projeto antes,
ele tem que tomar outras ações, até que ele desenvolveu 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 na mão, porque
o meio natural é a obsolescência da tecnologia
e você aí acaba perdendo algumas vantagens aí, dependendo da tecnologia.
Então é isso que é importante também olhar nesse cenário, quando a gente
vai falar de criar novos projetos, fazer inovação, desenvolver novas soluções
e até pegando isso.
Quando a gente fala no mundo corporativo, a gente não tem, não é?
País das Maravilhas.
Tá no ar as pessoas que estão iniciando agora, vocês que estão iniciando agora,
muitos na área vão encontrar.
Pô, vou lá, eu vou chegar a desenvolver, Não, você vai desenvolver, você vai,
você vai chegar, desenvolver, você vai entender o projeto,
mas você vai ter que seguir algumas regras e padrões, inclusive de conformidade.
As padrões, os requisitos legais.
Hoje a gente tem o LGPL, o LGPD,
que são as políticas de saber Security Security,
plantar diretamente no código, pois você tem as questões que você vai ter
que seguir, Não é sentar lá, simplesmente lá você 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 perceber 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 realidade aqui, certo?
Rafael Tem que colocar, pode colocar, pode ser até um ponto nesse gancho
que às vezes o nosso aluno com a gente corrige uma atividade, acontece.
O Rafa tirou 10% da nota porque no código algum professor aqui eu não segui boa
prática ou não fiz a identação do código ou não comentei código.
Foi sim, estava escrito no exercício.
Se você entregar funcionando, mas não seguir, boa prática, perde três pontos
ali. Fala porque?
Porque dentro de uma governança, entre uma gestão, de um projeto,
de uma empresa, você tem que segui las, porque você não está trabalhando sozinho.
Mesmo que tivesse trabalhado sozinho.
Depois você desse esse código
e provavelmente alguém vai fazer reengenharia
ou vai ter que analisar para criar o novo sistema.
Não é o exemplo clássico, porque, por exemplo, a gente falou de programação
e um eu já fiz várias entrevistas na época,
quando ainda cuidava dessa frente de desenvolvimento,
eu perguntava Cara, as perguntas que eu fazia.
O que acontece se você fizer um select asterisco dentro da base?
Será que você pergunta, fala não sei, você vai fazer ou não faz?
Não, pera ai o cara olhar?
Eu perguntei Mas que pergunta é essa?
Você sabe o impacto que você tem?
Colocar um asterisco sem um lugarzinho para travar?
Pois é.
Porque se você não criar, se você colocar isso no seu código,
você vai ter o impacto lá na frente, que em performance, dependendo
de que tipo de dado você está pensando, de que tipo de tabela você está
acessando, então não é uma boa prática você utilizar isso
dentro do seu código.
Ah, e as empresas geralmente tem seus manuais de
de 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 e aquele desenvolvedor
tinha habilidade para desenvolver determinado tipo de código.
O para onde eu ia direcionar ele para o desenvolvimento.
Você falou um para um ponto que eu vivi isso.
Eu trabalhava multinacional, eu comecei como desenvolvedor
e aí estava atendendo a área de vendas, área de vendas, uma multinacional base
muito alta e aí vez escalados da alta gerência, um desenvolvedor júnior,
um e-mail falando por que a gente tem que formar, qual é o range de clientes
que a gente quer enxergar?
Eu quero clicar e baixar toda a base de clientes.
Nossa, por sorte, eu, Júnior, desenvolvedor, muitos anos atrás,
eu tive a maturidade de perguntar ao meu coordenador técnico houve escalada
que da alta gerência de vendas ele não tem culpa, Mas oh,
eu entendo que se eu atender e tirar o era aqui, o que você falou
rapidinho tira sobra em testes, aí não vai dar impacto para subir a produção.
Só que se eu subir isso daqui, o outro não uso o relatório, se o sistema não cair
até explicar para essa pessoa se executivo da área de vendas,
que se eu fizer isso atrapalha a performance, vicia, dá stress.
Foram falar com ele, falou Então compra o servidor novo,
nem se você comprar mais muito tempo atrás e resolver.
Bem interessante essa fala,
mas por alguns segundos eu como um júnior vou ser bem transparente.
Eu pensei em fazer hora que fez calado, quase levando uma bronca.
Eu falei Pera aí, eu disse não faz sentido.
Eu como desenvolvedor, só que eu consultei não é bom isso,
mas conta que a maturidade na Rafa existe em Passos, né?
Não adianta, você pode ter uma excelente lógica de programação que não
Será que essas teorias vai rolar?
Vai travar tudo, mas a senioridade você mede 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 que você tem a vivência dentro dos projetos.
Pô, eu fiz isso aqui, o vício aqui posto aqui pode impactar.
Se eu fizer isso aqui, eu não sei o que pode acontecer,
mas deixa eu fazer uma ponte aqui para ver se pode gerar impacto.
Mas vou te falar que a dor na pressão eu confirmei.
Eu voltei a professora.
Essa história que hoje eu lembro, Júnior,
serviu de experiência, crescimento mesmo.
Pera aí, eu atendo ele, mas meu coordenador técnico aqui vai dar ruim.
Aí eu falei Serjão pergunta ele quer fazer, eu faço, mas vai parar.
Tudo bem que você não fez. Onde dar esse problema?
Eu vou falar com essa pessoa.
Não foi fácil.
Ele teve que lidar com situação de conflito.
Mas enfim, esse é o tipo de
desafio que
inclusive um gerente tem de terminar em identificar
quem são essas esses colaboradores que vão trabalhar com ele,
qual nível de senioridade,
que tipo de desenvolvimento
é melhor para cada um poder desenvolver.
Hoje gente fala que tem o front end e o back end,
então isso já é um tipo de segregação de função para o desenvolvedor.
Tem profissional 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 Legacy é onde tinha,
aí é onde entravam as metodologias
que algumas dessas metodologias tinham.
Uma etapa importante que era fazer um peer review no código,
então 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ão seria um pegar, viu?
Mas é basicamente isso.
E tem gente que não quer trabalhar nessa, que fala que é muito estressante
porque é estressante até pra mim é uma segurança.
Toda vez antes de eu mandar esse código para hackear, por exemplo, eu te ajudo.
Se passa pelo meu parceiro de revisão, que é o Edu,
é uma segurança, eu sei desenvolver é um problema.
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 a gente deveria ter responsabilidade civil
sobre os códigos que a gente desenvolve
penal e civil.
Ai ele já pegou. Tá vendo por que?
Porque hoje você desenvolve software para avião, para carro,
você desenvolve software para.
Só que você não tem
responsabilidades, não sabe lidar com aquilo que você desenvolveu.
É diferente de você,
do médico, o médico, ele não tem.
Ele vai pedir dez consulta pra MD, 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 também.
Acredito que
algo desse sentido para que as pessoas criem mais consciência
quando desenvolverem um software ou quando criarem um código
de desenvolver um código para algum programa, algum sistema.
Você não está falando em burocratizar, não é isso,
não é isso é trazer a responsabilidade legal
para não ter esse tipo de coisa que você acabou de dar.
Exemplo Não, eu não quero trabalhar porque eu vou fazer uma verificação
sobre o meu trabalho.
Não, não estou fazendo uma verificação de sobre seu trabalho.
Estou fazendo um peer review para garantir que você não vai ter um problema
a hora que você implementa sistema quer dizer o que você está fazendo.
Você não viu que se fizer por mal só vai dar um pouco não sei o que melhor
a perform, porque você tem código hoje, programas e software
desenvolvido em várias situações
você tem numa hidrelétrica, você tem software,
você tem software no avião, você tem software no automóvel,
na área da saúde, você software na área da saúde,
você 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 você cria um podcast.
Vocês conseguiram trazer esse contexto, porque para quem está nos escutando,
Porque se você achava que você ia ter uma resposta O que é um projeto?
O que é?
Qual o melhor gestão de projeto ágil ou em cascata ou permite in box?
Seja, você não ia nenhum momento dar uma pausa e fazer uma anotação breve.
Isso não 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í que ele trouxe o Edu aí.
E não é para te deixar confuso na verdade, é você entender
que quando você faz uma gestão de projeto, não é só olhar o seu documento,
pedir pra alguém 80% do tempo do projeto rodar, tá entregue.
Se for ágil, melhor ainda que vai fazer.
A qualidade nem sempre se move. Verdade.
Se for poema, o escopo conhecido, então depende.
Se negociou com seu cliente, então é isso que era o tópico da nossa conversa.
E aí eu trago para uma última, leia duas e fica a vontade pra
quem quer ser o primeiro, para quem está nos escutando, nos.
O que você deixa de dica primeiro que a gente está falando
é que os alunos que estão escutando é um aluno do nosso da graduação.
Às vezes ele já tem experiência ou não, mas principalmente
isso, começaram o desenvolvimento.
Eu comecei, acredito que vocês também.
E aí largar o desenvolvimento, porque só 30% vocês deixam de dica
para quem está nos escutando.
Uma frase de fechamento de cada um, favor, um contexto,
uma dica para quem
é desenvolvedor ou que está na carreira de engenharia de software.
Aí tanto em teste, desenvolvimento, análise,
migrar para um cargo
de gestão
é o que a gente colocou 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 vai,
o quanto ele está se desenvolvendo
em relação ao relacionamento com as pessoas,
que isso é fundamental.
É mais até do que a metodologia,
é mais até do que saber codificar ou não.
Então ele tem que definir bem
para onde ele quer direcionar a carreira dele.
E hoje a gente sabe que eu
não preciso tomar uma decisão de ir para uma carreira de gestor.
Tem pessoas que continuam na trilha técnica.
Esses jovens formam um super.
Isso se transforma.
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 de Scrum Master.
Enfim, por quê?
Porque grande parte desse trabalho é a habilidade de trabalhar a equipe,
a colaboração do time, para que consiga naquele
produto que você pensou.
Eu cheguei no final com ele
concluído e entra em produção e o cliente fica satisfeito
ou a empresa fica satisfeita com aquilo que foi feito.
Então, esse é o ponto importante que tem que ser avaliado.
Eu não pensar só em código, não pensar só em organização.
Se ele tem a pretensão de ser um gerente, de ir
uma carreira, de gestor,
virar um diretor, crescer para um lado mais executivo,
ele vai ter que analisar e ver qual é,
qual é o gap que ele tem em relação à parte humana.
A soft skill ali, exatamente.
Falar é um software já preparado para guardar, aguardando aqui.
Mas eu tenho medo
de não entender só essa palavrinha do do que eu tomo essa dica aí.
Tá bom, deixa a dica pessoal.
É o seguinte eu acho que muitos dos alunos, alguns pelo menos,
acredito que já tenho escutado que muitas vezes
as pessoas são contratadas pelos hard skills,
que são os ar de skills, são os conhecimentos técnicos.
Então quando você fala engenharia de software você está boa,
ganhando conhecimento técnico, que são hard skills,
porém elas são demitidas pelo soft skill, que são os soft skills.
É a capacidade de comunicação, é a capacidade de colaboração
de como trabalhar em equipe.
Então o recado a dica que eu dou é o Hard Skill.
Você vai ser contratado rádio.
Por isso que a gente tem que estudar, a gente vive nela, a gente
aqui, nós três aqui estuda muito.
Doutora fazendo doutorado, agora
sofrendo, está mais à frente ela ler, fazer doutorado.
Eu parei no mestrado
ou doutorado, vamos ver.
Acho que vou então assim.
Mas é super importante trabalhar essa frente de soft skill,
independente da carreira, se a carreira técnica
ou se é carreira gerencial, é 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
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 conquista 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.
XO agradecer aí a sua presença
e a liberdade que você teve de trazer os temas até de uma maneira até polêmica.
Edu Também nessa liberdade é com certeza soma para os nossos alunos.
A gente sempre fala, vai além dos nossos materiais
que a gente deixa disponível, que o professor ensina, escuta
e também os profissionais de mercado que a gente traz
para vocês verem que o que às vezes a gente cobra,
porque a gente vê um dizer chato na hora de uma correção,
e sim porque a gente quer que você entenda
que o mercado trabalha nem sempre como tá a cartilha do Agile, por exemplo.
Isso ai Edu, agradecer também a sua presença e da mesma forma e
a liberdade você teve para trazer os temas e até mesmo somar para os nossos alunos.
Obrigado!
E você aluno, deu pra entender que para você
fazer uma gestão de projetos não basta apenas você saber
fazer a gestão, mas também tudo o que tem envolvido.
Vou ficando por aqui e até uma próxima.