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