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á 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,
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.