Fronteiras da Engenharia de Software

Logo

um podcast de divulgação científica

[Host: Adolfo Neto (UTFPR)]{.mark}

[Co-host: Ingrid Nunes (UFRGS)]{.mark}

Equipe: Danilo Ribeiro (Zup), Leonardo Fernandes (IFAL), Fabio Petrillo (Univ. Quebec), Gustavo Pinto (UFPA)

Script do Episódio

Parte 1: Apresentação [5 min, estimativa]

[[ADOLFO] Hoje no Fronteiras da Engenharia de Software vamos conversar com César França, professor da Universidade Federal Rural de Pernambuco e da Cesar School. O tema do episódio de hoje será Motivação e Satisfação dos Engenheiros de Software.]{.mark}

[[ADOLFO] Tudo bem, César? Você pode se apresentar para as pessoas que nos escutam?]{.mark}

[CF] Olá Pessoal, tudo ótimo! Eu sou César França, como Adolfo falou, professor do departamento de computação da UFRPE, e também ocupo hoje a posição de Head of Research na Cesar School, que é a escola de inovação do CESAR, o instituto de inovação que é âncora aqui no Porto Digital do Recife.

Fui aluno de graduação, mestrado e doutorado no CIn, da UFPE, onde trabalhei desde sempre com o professor Fabio Silva, que é uma grande referência internacional atualmente na pesquisa empírica na Engenharia de Software, e especialmente na pesquisa sobre aspectos humanos de engenheiros de software. Fiz o doutorado Sanduíche na Open University, onde trabalhei com a profa. Helen Sharp que é muito conhecida no mundo da pesquisa qualitativa, e de métodos ágeis.

Na UFRPE eu atuo basicamente na graduação, no curso de Licenciatura da Computação, em disciplinas relacionadas a Design da Interação e a Aspectos Humanos e Sociais da tecnologia. E na Cesar School eu atuo nos programas de Mestrado Profissional em Engenharia de Software, no Doutorado Profissional em Engenharia de Software, em cursos de Extensão Executivos, e agora na coordenação geral de pesquisa e cooperação da instituição.

Inclusive, se preferirem, pra evitar a cacofonia com o CESAR e a Cesar School, podem me chamar só de “França”... que eu já tô me acostumando com isso.

Atualmente eu coordeno um grupo de pesquisa chamado GENTE - que é um grupo de estudos em GENTE em negócios de tecnologia, composto aí por alunos de mestrado, doutorado e alguns outros pesquisadores colaboradores.

Parte 2 - Tema do Episódio [20 min, estimativa]

[INGRID] César, existem trabalhos sobre fatores humanos na engenharia de software, entre eles a motivação e satisfação de profissionais na área. Motivação e satisfação são a mesma coisa? Qual a diferença entre uma pessoa motivada e uma pessoa satisfeita?

[CF] Pois é Ingrid, não são a mesma coisa não. Inclusive um dos maiores desafios de se fazer pesquisa sobre motivação e satisfação, hoje em dia, é que esses termos são tão populares, e tão fofinhos, que muita gente assume de partida que todo mundo sabe o que é que eles significam… e isso causa muita confusão na área. Objetivamente, motivação se refere a um comportamento de ativação para a ação - e é gerado por sensações internas associadas ao próprio fazer daquela ação… já satisfação é um estado emocional RESULTANTE da avaliação que a gente faz DEPOIS de uma ação… é o que o indivíduo sente quando olha pros resultados de uma ação e compara com as suas próprias expectativas.

Observe que, se você pensar em uma atividade bem atômica, motivação é o que acontece antes… e satisfação é o que acontece DEPOIS, da realização daquela ação atômica.

É claro que essas duas coisas estão conectadas… a experiência de um indivíduo é constituída, dentre outras coisas, pelas memórias que ele tem sobre resultados de coisas que aconteceram no passado, então… a satisfação passada meio que molda a motivação do futuro, como num ciclo, que a psicologia vai chamar de mecanismo de sistema de auto-regulação.

E essa sua pergunta é importantíssima Ingrid… porque embora, como eu falei, essas duas coisas sejam conectadas, as coisas que CAUSAM motivação no ser humano são diferentes das coisas que CAUSAM satisfação… e os EFEITOS da motivação também são diferentes dos EFEITOS da satisfação.

E compreender essas diferenças, entre esses fenômenos, fatores e efeitos, DEVERIA ser um ponto de partida básico pra todo mundo que lida com GENTE em mas infelizmente, como eu falei, como esses termos já são termos muito “gastos” no mundo dos negócios… todo mundo assume que eles são naturalmente compreendidos, e acabem ignorando a importância de se esforçar um pouco pra compreendê-los. E na pesquisa também não é muito diferente não… quer um sinal bem claro disso? A gente tem quase uma centena de história de pesquisa na área da psicologia organizacional sobre essas duas palavrinhas… e tem muito artigo que sequer cita uma única teoria de motivação ou satisfação. Ou pior, parte de teorias obsoletas… como a pirâmide de Maslow - que é um negócio que foi desacreditado até pelo próprio Maslow há mais de 50 anos atrás… mas continua ressoando até hoje.

Eu publiquei um livro em 2018, tá disponível lá na Amazon, só sobre teorias clássicas de motivação, e tem muita coisa boa que foi desenvolvida de Maslow pra cá… coisas muito mais consistentes e sofisticadas do que aquela pirâmide (que na real nem era de Maslow, vocês sabiam? Alguém criou e colocou o nome dele lá…). E um dos maiores avanços que tivemos nessa área foi justamente o alcance dessa compreensão de que motivação e satisfação são coisas diferentes!

[ADOLFO] E falando de motivação e satisfação no trabalho, por que falar disso especificamente no contexto de engenharia de software é relevante? Como isso se diferencia de outras profissões?

[CF] Adolfo, tem várias razões. A primeira delas é que Engenharia de Software é uma atividade executada, em boa parte, ainda, por GENTE! Por isso, compreender como as pessoas funcionam - de forma geral - e como podemos ajudá-las a alcançar um melhor desempenho naquela atividade ali é um ponto chave pra desenvolver bons projetos. O comportamento de engenheiros de software é algo que é estudado desde há muito tempo… tem um livro fundamental de 1970 do Gerald Weinberg - um cientista da computação americano, um dos fundadores da IEEE Transactions on Software Engineering, chamado A psicologia da programação de computadores… que aborda em diversas dimensões como aspectos psicológicos influenciam no desempenho de programadores. Depois, ali mais pros idos da década de 80, o Tom DeMarco popularizou o termo “peopleware” como o terceiro elemento necessário pra construção de um bom sistema de informática, além do software e do hardware né… o próprio manifesto ágil, de 2001, em um dos seus princípios sugere a construção de projetos em torno de pessoas motivadas! Mais recentemente, tem até um grupo de pesquisadores da suécia que vem empreendendo o termo “Engenharia de Software Comportamental” pra se referir a esses estudos de aspectos cognitivos e comportamentais de engenheiros de software. Então a primeira razão é essa: GENTE é um ponto chave na engenharia de software!

A segunda razão, e que é aí que a gente se diferencia de outras profissões, é que a engenharia de software é uma atividade fundamentalmente intelectual. Sabe aqueles quase 100 anos de pesquisa que nós temos na área da motivação e satisfação de pessoas, que eu me referi antes? Pois bem… quase todas as teorias e avanços significativos que tivemos nessa área, nesse tempo, foi através de pesquisas que estavam lidando com outros tipos de atividades… produção fabril na sua maioria… em ambientes que são culturalmente muito diferentes dos que a gente tem normalmente na engenharia de software. O Lars Wallgreen, que é um desses pesquisadores suecos a quem me referi antes.. Sugeria lá na tese de doutorado dele que a Engenharia de Software é como se fosse um protótipo do que serão as profissões do futuro… e de fato, vejam como são as coisas… a engenharia de software começou a desenvolver práticas de desenvolvimento distribuido e virtualização de equipes 20 anos antes da covid-19 forçar com que quase TODAS as outras profissões fizessem a mesma coisa… a gente já era naquela época um protótipo das profissões do futuro. E se isso for verdade, a melhor forma de se antecipar a problemas organizacionais do futuro, de QUALQUER ÁREA, é estudando a Engenharia de Software de hoje.

A terceira razão, e pra mim talvez a mais significativa e urgente, é a questão de que pesquisas que se propõem a avaliar ou medir o grau atual de satisfação de engenheiros de software nos seus trabalhos atuais pintam um retrato muito triste da realidade. A pesquisa do Stack Overflow, por exemplo, com gente do mundo inteiro, estima que algo em torno de 10% dos desenvolvedores entrevistados andam completamente satisfeito com os seus trabalhos… isso é uma questão extremamente relevante para o nosso mercado, uma vez que HOJE a gente já sofre da falta capital humano na área… Logo, o setor produtivo precisa sem dúvida melhorar a sua capacidade de satisfazer os engenheiros de software, primeiro pra manter os seus profissionais, e segundo pra atrair mais gente pra área. Tem um artigo bem interessante sobre esse fenômeno, mas é da década de 80, que evidenciava um fenômeno muito interessante: com a explosão do crescimento do mercado de software daquela época, muita gente foi atraída pra área com a promessa de que ficaria rico na profissão… gerando uma espécie de gold rush (corrida do ouro) e consequentemente uma frustração em larga escala, de muita gente… o que justificava esses índices muito baixos de satisfação dos engenheiros de software - que já eram baixos naquela época também. A minha impressão é que esse Gold Rush já vinha meio que se repetindo nos últimos anos, e agora - com a abertura da concorrência internacional por capital humano - pipocou de vez! Então isso é a outra razão, que a gente precisa ter muita atenção e muito cuidado...

[INGRID] Existem diferentes posições relacionadas com a engenharia de software, como por exemplo gerentes de projeto, desenvolvedores, engenheiros de requisitos, etc. Existem diferenças quando observamos pessoas atuando nessas diferentes posições?

[CF] Sim e não, Ingrid… haha vou tentar melhorar a minha resposta.

Falando na nossa linguagem, pra tentar fazer uma analogia, o sistema de processamento da motivação e satisfação de qualquer pessoa, em qualquer função, é o mesmo! Os métodos, funções, parâmetros são os mesmos… porém, dependendo de quem são essas pessoas, e do CONTEXTO - ou seja, o que estão fazendo, onde estão fazendo, quando, e com quem estão trabalhando - os argumentos que vão ser processados por aquele sistema de motivação e satisfação são diferentes.

O contexto aí faz toda a diferença. Kurt Lewin, que é um dos pais da sociologia moderna, descreve que qualquer comportamento humano é uma função resultante da combinação da identidade do indivíduo com o contexto.

Quer ver um exemplo? de uma situação que eu me deparo sempre, e me deparei bastante nas pesquisas de campo que fiz durante o meu doutoramento: pense um pouco sobre a atividade de testes de software. Enquanto algumas pessoas descrevem essa atividade como repetitiva e sem graça, outras pessoas descrevem a MESMA atividade como desafiadora e instigante! A diferença está na atividade? Neste caso não… nesse caso aí a diferença pode estar no perfil das pessoas. Um de meus alunos de mestrado agora anda estudando o que significa uma atividade ser “desafiadora” e ele está estudando especificamente testadores… dentre outras coisas, os resultados dele aponta justamente pra importância da existência de um fator “novidade” no trabalho. Esse fator “novidade” ou o que eu chamo de “aprendizado útil” é um elemento que influencia fortemente na motivação.

Tem outra situação em que isso fica bem claro: projetos de maior duração, especialmente aqueles que adotam metodologias mais tradicionais, são projetos bem desafiadores pra se manter altos graus de motivação por muito tempo. Isso porque no início do projeto, a gente percebe que os envolvidos estão aprendendo muita coisa, tem muita novidade relevante ali… mas ao longo do tempo, a novidade se esvai, e a gente entra em fases de maior trabalho repetitivo que dependem mais da disciplina do que da motivação pra se ter sucesso.

Então, nesse caso, a característica do projeto - e dos processos de desenvolvimento - vão pesar bastante. Processos ágeis - ágeis de verdade - sofrem menos desse problema, primeiro porque coisas novas são feitas a todo tempo. E segundo porque os desenvolvedores acabam ficando mais próximos do cliente, e compreendem melhor os seus problemas… Engenheiros de Requisitos e Gerentes de projeto têm naturalmente uma maior responsabilidade percebida sobre os projetos em que estão participando, e conseguem obter uma visão mais clara do resultado, do impacto, do seu trabalho. Esses dois fatores estão entre aqueles que são mais importantes pra desenvolver um alto grau de engajamento das pessoas… e engajamento é um dos sinais de motivação. Quanto mais o indivíduo percebe que o sucesso de determinado processo depende dele, que aquilo é responsabilidade sua, maior será a motivação dele, e maior também será a probabilidade dele alcançar os seus melhores níveis de desempenho, dentro do possível, é claro. Outro aluno de mestrado, há uns dois anos atrás, publicou um pôster no EASE em que coletou alguns dados e demonstrou que existem algumas práticas ágeis que são diretamente correlacionáveis com a motivação dos engenheiros. Não são todas, mas tem algumas, como as entregas constantes, que se destacam.

Então, no final das contas, quanto menos noção de responsabilidade e de significância do trabalho, e quanto menor for o feedback do trabalho, menor é a motivação do engenheiro. A lógica do sistema de motivação e satisfação é a mesma pra todo mundo! Nós temos o mesmo app instalado na nossa cabeça. Mas a posição em que os indivíduos estão em um processo de desenvolvimento influenciam sim no fato do indivíduo ter uma maior ou menor percepção dos fatores, dos ingredientes, da motivação. Estar em empresas pequenas ou grandes, ou no setor público ou privado, tudo isso dá diferentes argumentos de contexto para esse sistema de motivação e satisfação. Processos excessivamente burocráticos geralmente tendem a diminuir a noção de responsabilidade dos desenvolvedores, e afastá-los do significado do trabalho. E além de tudo, o desafio do gestor é garantir não só a sua própria motivação, mas também a motivação e a satisfação das outras pessoas envolvidas no projeto.

[ADOLFO] A pesquisa de motivação e satisfação é de interesse direto do empregado, que normalmente quer se sentir motivado e satisfeito com o seu trabalho. Mas e as empresas? Como elas se beneficiam quando os engenheiros de software estão motivados e satisfeitos?

[CF] Começando pela motivação: o principal benefício da motivação é o desempenho. Um indivíduo motivado consegue elevar o seu desempenho real ao nível mais próximo possível do seu desempenho potencial. Observe que isso não é uma frase simples ok? Vou até pedir pra os ouvintes menos atentos voltarem aí uns 5 segundos, e prestarem atenção denovo ao que eu falei…. E eu to reforçando isso, porque muita gente acha que pessoas motivadas produzem mais do que pessoas desmotivadas, e isso NÃO É VERDADE! Teoricamente, a gente só pode garantir que pessoas motivadas produzem mais e melhor do que elas próprias se não estivessem motivadas, certo? O resultado de ter pessoas motivadas, para as empresas, é que só assim elas vão poder aproveitar ao máximo o produto pelo qual estão pagando… imagina você pagar por um prato de comida em um restaurante, e só ser servido a metade. Isso parece ser um absurdo… mas quando você tem uma pessoa desmotivada na equipe, é precisamente isso o que acontece: o empresário está pagando pelo salário de uma pessoa que tem um determinado desempenho potencial, mas não está recebendo isso em troca. Nesse ponto, é importante eu ressaltar também que motivação NÃO É O ÚNICO PREDITOR DE DESEMPENHO, ok? Tem algumas empresas que já me procuraram achando que precisavam fazer um trabalho pra melhorar a motivação dos seus colaboradores, mas que acabamos descobrindo que elas não tinham NENHUM problema de motivação… e que os colaboradores produziam pouco por OUTRAS RAZÕES, relacionadas a infraestrutura ruim, pouco conhecimento sobre as tecnologias e ferramentas adotadas, excesso de pressão de tempo, e por aí vai! E nessas condições, a gente acabou evidenciando que aquelas pessoas estavam de fato dando o melhor de si!! Mas o problema é que dar o melhor de si… naquelas condições... não tinha como se transformar muito em um desempenho exemplar! Motivação também NÃO É uma bala de prata! E quando eu falo desempenho aqui, entendam como qualidade dos artefatos, quantidade de código produzido, poucos bugs, traduza aí da forma como quiser. Tem até um trabalho recente do grupo do Daniel Graziotin, da universidade de Stuttgart, que demonstra vários desses efeitos.

E de outro lado, os efeitos diretos da satisfação são a intenção de continuação no trabalho, e a saúde mental e física dos colaboradores. A satisfação é o que combate diretamente o Turnover, o que - em tempos de alta competição por capital humano - deveria ser considerado um fator estratégico pras empresas de software.

[INGRID] E falando de empresas, existem diferenças em como motivação e satisfação na engenharia de software aparecem em pequenas, médias, e grandes empresas? Ou mesmo, setor público ou privado?

[INGRID] De acordo com a literatura, é possível identificar sinais que Engenheiros de Software estão motivados e satisfeitos? E como promover a sua motivação e satisfação?

[CF] Sim, é possível. A motivação é observada a partir da combinação de dois sinais: o engajamento e o foco. O engajamento é percebido através da aplicação volitiva do esforço físico numa atividade, e o foco é a aplicação volitiva da atenção. Embora até o foco seja um aspecto mais cognitivo, um de meus alunos de mestrado defendeu uma dissertação há alguns anos atrás - em que ele coletou dados de auto-percepção de engenheiros de software sobre o seu foco em diferentes momentos do dia, e cruzou esses dados com a percepção de observadores externos - os seus líderes técnicos, e evidenciou que a diferença de percepção foi insignificante… ou seja, no final das contas, o foco é algo que pode sim ser observado externamente. E a gente conseguia fazer isso de uma maneira relativamente simples, quando o trabalho co-localizado ainda existia né! Rsrs

Pelo que deu pra aprender com o estudo que fizemos no meu Doutorado, é possível administrar a motivação através do design do trabalho. O design do trabalho diz respeito à forma como a gente organiza os processos, as atividades, as responsabilidades, a comunicação, e vários outros aspectos da dinâmica do desenvolvimento de software. Eu acho até que já adiantei alguns desses fatores, mas de forma resumida, características tais como criatividade demandada, variedade do trabalho, a percepção de desafio, o aprendizado útil e a percepção de impacto do trabalho são elementos que influenciam fortemente no engajamento dos engenheiros de software. De maneira recursiva, o engajamento dos colegas de trabalho também influenciam no engajamento de um indivíduo.

FAZER UM CORTE

Já uma boa definição sobre os processos de trabalho e a administração da carga cognitiva ajudam a garantir bons níveis de foco. Só pra dar um exemplo de intervenção interessante, uma tese de doutorado doutorado desenvolvida por outro aluno de Fabio - o Ronnie - investigou como a prática do Job Rotation, dentro de grandes empresas, pode ajudar a inserir artificialmente aspectos de variedade do trabalho e aprendizado útil… embora por outro lado causando alguns pequenos desafios na gestão da carga cognitiva dos desenvolvedores. Então dá pra fazer!

A satisfação, por outro lado, é observada basicamente pelo grau de felicidade das pessoas em estarem fazendo aquilo que estão fazendo. É… a felicidade é o principal indicador de satisfação. E a satisfação é alcançada quando as expectativas dos colaboradores a respeito do seu trabalho são atendidas… as expectativas em todos os sentidos, sejam expectativas econômicas, envolvendo por exemplo o salário, benefícios, cargos e carreira - sejam expectativas sociais - trabalhar com pessoas legais, se dar bem com supervisores, receber reconhecimento, ou mesmo expectativas em relação ao trabalho mesmo, como o exercício da sua motivação - fazer algo que gosta. Observe que são vários esses fatores… e eles concorrem entre si… por isso, SOMENTE pagar bem não é suficiente. SOMENTE ter boas relações não é suficiente… mas TODOS esses fatores são NECESSÁRIOS. A satisfação é o resultado de uma combinação disso tudo, com as expectativas dos próprios indivíduos. Então é importante manter-se observando o que a própria organização anda fazendo pra garantir a satisfação dos seus colaboradores, mas é importante também manter um olho no mercado, pra saber o que as outras organizações andam oferecendo… pra tentar manter uma equidade nessas ofertas, e também ajudar a administrar as expectativas dos colaboradores.

A área que estuda satisfação, na psicologia organizacional, inclusive, é bem mais bem desenvolvida do que a área que estuda motivação. Você vê que hoje existem produtos comerciais muito bem desenvolvidos nessa área, como o sistema do Great Place to Work, que são ferramentas maduras, flexíveis, e absolutamente replicáveis, pra ajudar a garantir altos níveis de satisfação a empresas de qualquer área, e ainda associado a um modelo de negócio sustentável e escalável. Em termos de satisfação, a área de Software não difere significativamente de outras áreas.

[ADOLFO] No início do episódio, falamos de fatores humanos na engenharia de software. Que outros aspectos foram estudados? O lado oposto - insatisfação de engenheiros de software - também é objeto de estudo?

[CF] Sim, sim! Excelente ponto Adolfo! Aquele grupo que falei antes, do Daniel Graziotin, tem alguns trabalhos bem interessantes demonstrando o efeito da insatisfação sobre diversos aspectos da produção de software. As bases teóricas do trabalho do Graziotin são levemente distintas das minhas… então ele acaba colocando motivação e satisfação, desempenho e felicidade, tudo no mesmo bolo… acho que se isso fosse melhor administrado nas pesquisas dele nós teríamos uma visão muito mais precisa da dinâmica de todos esses fenômenos, uma vez que as pesquisas dele são muito ricas em dados. Mas ainda assim, é uma excelente fonte de informação sobre o tema. Inclusive alguns professores aqui da Universidade Rural, liderados pelo Marcelo Marinho, vêm replicando alguns desses estudos no Brasil.

Nesse campo da engenharia de software comportamental tem muitos outros aspectos que são estudados. Estudos sobre a personalidade de engenheiros de software é um tema bastante recorrente nessa área… Comunicação e Colaboração em projetos de software é outro tema bem quente… de supetão são os mais presentes que consigo lembrar. Mas há pouco mais de cinco anos foi criado um evento satélite na Conferência da SBC chamado Workshop de Aspectos Sociais, Humanos e Econômicos do Software - o WASHES - que é um excelente fórum nacional sobre pesquisas nessa área. Em nível internacional, já tínhamos a um pouco mais de tempo o CHASE - Conferência em Aspectos Humanos na Engenharia de Software, que é talvez o principal fórum do tema, na nossa área.

No meu grupo de pesquisa, em particular, eu tenho desenvolvido algumas outras pesquisas relacionadas à dinâmica do trabalho em equipe - o que inclui aqui processos de onboarding, e processos de transição de equipes hierárquicas para equipes autogerenciadas, adoção de estratégia de gamificação em processos de desenvolvimento no setor produtivo - e é interessante ver como “gamificação” é basicamente uma capa para a implementação de técnicas de design do trabalho motivador, que trabalha num nível bastante operacional. Enquanto eu trago aqui todo um ferramental teórico para explicar como resolver o problema… a turma que vem trabalhando com gamificação está conseguindo resolver o problema sem entender muito bem o porquê! rsrs

O grupo GENTE trabalha também com o desenvolvimento de soft skills de engenheiros de software, o desenvolvimento de cultura de transformação digital em negócios de qualquer natureza - e mais recentemente eu venho mergulhando bastante no problema do Skill Gap, que tem muito a ver com o que a galera vem se referindo genericamente como “a carência de capital humano qualificado” no setor de TI.

[ADOLFO] Na sua opinião e com base no seu conhecimento, a motivação e satisfação profissional de engenheiros de software é um problema? Os devs hoje estão cansados? Existe até um podcast com esse nome - Devs Cansados :)

Parte 3: Pesquisa

[[INGRID]]{.mark} César, há 10 anos você publicou um estudo que fez uma revisão de literatura sobre a importância de compreender a motivação no campo da engenharia de software. Mais recentemente você publicou um estudo também sobre o tema na prestigiada TSE. Por que é importante entender os fatores que influenciam a motivação de engenheiros (as) de software? E alguma coisa mudou entre sua investigação de 2011 para essa mais atual?

[CF] Ingrid, as duas publicações foram parte do mesmo projeto. Em 2011, a gente na verdade atualizou uma revisão sistemática que tinha sido feita há uns anos antes pelo grupo da Helen Sharp, na Inglaterra. E foram poucas os incrementos que pudemos ver que aconteceram em quatro ou cinco anos de diferença de uma revisão para a outra. Os resultados das revisões sistemáticas nos incomodou um pouco - e aqui estou me referindo a mim e ao meu orientador na época, o Fabio. O nosso incômodo é porque a revisão basicamente juntava uma lista enorme de fatores que supostamente poderiam influenciar na motivação E na satisfação dos engenheiros de software, mas não conseguia explicar COMO.

Foi aí que desenhamos o que veio a ser o meu projeto de Doutoramento: realizamos pesquisas de campo com algumas empresas aqui de Recife, e o nosso intuito era tentar entender COMO aquele processo de influência acontece, ou acontecia, NA PRÁTICA. E era importante pra nós também que essa prática tivesse algum respaldo na teoria! Como eu falei no início aqui da nossa conversa, como pesquisadores, a gente não podia ignorar que existia aí quase uma centena de anos de pesquisas realizadas nessa área, marcadamente na psicologia organizacional… e a gente precisava beber dessa fonte. Foi nesse trabalho então que nasceu o que chamamos de Teoria de Motivação e Satisfação de Engenheiros de Software, a TMS-SE, que é o que está contado lá no paper aceito em 2018 na TSE. Então o que esse paper traz é uma explicação do COMO que faltava… a gente explica lá como TUDO acontece… é como se fosse a especificação completa do algoritmo que eu chamei antes aqui de nosso “sistema de motivação e satisfação”.

O projeto na prática encerrou-se em 2014, quando defendi meu doutorado, mas demorei um pouco mais pra transformar a tese em paper… e ele só foi efetivamente publicado no ano passado. A própria teoria em si também sofreu alguns refinamentos nesse processo. Mas como falei, isso tudo fez parte de um mesmo esforço.

[ADOLFO] [Aguarda o Feedback]... pegando o gancho de outra investigação que você fez. O layout do escritório pode influenciar a motivação?

[CF] Pois é… indiretamente sim! O layout de escritório é o hardware onde a gente instala o nosso peopleware… a nossa equipe de desenvolvimento! Então o layout pode ser mais ou menos propício a ajudar em aspectos como percepção dos resultados do trabalho, ou na administração da carga cognitiva dos engenheiros… Essa pesquisa dos layouts de escritório foi um caso muito interessante, porque aqui na CESAR School, nos programas de Mestrado e Doutorado Profissionais, a gente trabalha quase que integralmente com demandas reais do setor produtivo, trazidas na maioria das vezes pelos nossos próprios alunos - e a gente pareia os interesses dos alunos com os interesses de pesquisa dos orientadores. E esse foi um caso que me marcou bastante. Um dos meus alunos, o Victor, estava liderando uma equipe de desenvlvimento, e me lembro de ele ter citado que estavam discutindo sobre a remodelagem do ambiente de trabalho na empresa que ele estava atuando na época. Embora nós encontrássemos diversas referências da prática de empresas que tinham feito essa migração de layout, a gente não encontrou muitos trabalhos convincentes na Engenharia de Software que versassem sobre as vantagens ou desvantagens de um determinado tipo de layout sobre outros. Nós até publicamos uma revisão literária no VEM, em 2019, mostrando que não haviam muitos estudos sobre isso. No ano seguinte, o aluno fez uma pesquisa de campo, coletando dados de várias empresas de layouts variados, e viu que os Espaços Abertos eram efetivamente o layout que eram mais percebidos como facilitadores de vários aspectos do trabalho em equipe (colaboração, qualidade da comunicação, aprendizagem, dentre outros).

E como eu falei antes, a motivação não é o único antecedente do desempenho dos engenheiros. As condições de trabalho - e consequentemente o layout do escritorio - também influenciam.

[[INGRID]]{.mark} Além de estudar motivação e satisfação, você investiga times de alta performance. Primeiro, o que é um time de alta performance? E segundo, quais características individuais em de grupos esses times possuem?

[ADOLFO] Comparando com outros campos de trabalho, como médicos, advogados, engenheiros civis, etc. Existe alguma diferença nessa questão de alta performance de times?

Parte 4: Outras perguntas

[[ADOLFO]]{.mark} Qual a principal dificuldade que você encontra ao conduzir estudos científicos sobre um tema tão abstrato, ou que possui tantos fatores de influência como motivação e satisfação?

[CF] Pois é… esse é o primeiro desafio: transformar essas coisas abstratas em coisas mais palpáveis. Associado a este problema, está o segundo desafio, que é o de fazer as pessoas compreenderem o que são essas coisas abstratas…

Isso porque, quando estamos falando do estudo de aspectos comportamentais, de maneira mais ampla, nós temos poucas alternativas de métodos empíricos pra usar! Se estivermos falando de coisas que são observáveis, podemos conduzir observações… mas elas são trabalhosas, custosas, e nesses tempos de pandemia são quase que inviáveis. De outro lado, se estivermos falando de fenômenos mais abstratos, como a motivação e a satisfação, dependemos muito de entrevistas… e consequentemente da da capacidade de auto-percepção e auto-avaliação dos engenheiros pra alcançar alguma credibilidade… e cá pra nós, engenheiros de software não estão entre os públicos mais evoluídos em termos do domínio e da comunicação de aspectos socioemocionais desta natureza. Em resumo, o nó é o seguinte: eu posso perguntar para o engenheiro de software o que é que torna ele motivado, mas se ele não souber o que é motivação… a resposta para esta pergunta é potencialmente inválida! E como eu posso explicar previamente o que é motivação, para eles, sem influenciar na resposta seguinte? Isso é quase como um problema do ovo ou da galinha.

E pra deixar o meio campo ainda mais embolado, como eu falei lá no início da entrevista, “motivação” e “satisfação” são palavras fofinhas… são temas que todo mundo parece assumir que sabem o que significam… É igual a “liderança” ou “trabalho em equipe”... todo mundo acha que deveria ter um opinião sobre… e que a sua opinião é sempre a melhor de todas. Um de meus alunos de mestrado está desenvolvendo uma dissertação sobre “o que significa saber trabalhar em equipe?” É… porque você vê isso em um monte de anúncio de vaga, mas é difícil explicar consistentemente o que é isso! Ele andou conversando com gestores, com técnicos e com profissionais de RH, e de maneira não surpreendente, a gente tem visto que as respostas destes três grupos não coincidem em alguns pontos! Por isso, distinguir o que é efetivamente experiência fundamentada, do que são opiniões sem fundamento - nesse tipo de coleta de dados - é outro nó danado!

Por fim, nem sempre as pessoas QUEREM falar sobre essas coisas… a gente sempre precisa ter um cuidado muito grande com os conflitos de interesse que podem vir a surgir dentro das empresas. Imagina a gente coletar um monte de dados sobre satisfação das pessoas, e depois os chefes quererem identificar quem são essas pessoas… desenvolver essa relação de confiança com os entrevistados é importante, e não é fácil!

Por isso, encontrar métodos de coleta e de análise de dados que possam blindar esses problemas é um grande desafio. Por outro lado, foi precisamente esse desafio que me fez aprofundar e dominar métodos de análise, tanto quanti quanto qualitativos, extremamente sofisticados…

Sobre a quantidade de fatores, entendendo como eles funcionam, de maneira sistêmica, direitinho, é algo que dá pra lidar. Esse trabalho que publicamos no TSE, que descreve a Teoria de Motivação e Satisfação de Engenheiros de Software, simplifica muito o universo de fatores que são efetivamente relevantes pra gente continuar investigando e dirigindo o nosso trabalho.

[[INGRID]]{.mark} Saindo do forno, você publicou um artigo sobre obsolescência de engenheiros de software. O que exatamente é isso? E quais foram as conclusões deste trabalho?

Então, como eu mencionei brevemente, um dos interesses de pesquisa do meu grupo tem olhado para o fenômeno do Skill Gap: a dificuldade que as empresas sentem para contratar pessoal qualificado na área de TI. Aqui no ambiente do Porto Digital, nós estamos num lugar riquíssimo em conhecimento e em colaboração. Então é legal que temas dessa natureza são muito bem recebidos pelas empresas do parque tecnológico, e a gente faz bastante coisa juntos.

Esse trabalho sobre obsolescência é ums dos produtos dessa colaboração. Um de meus alunos de Mestrado, o Bruno Rocha, tinha o desafio de ajudar um grupo de engenheiros de software a encontrarem recolocação no mercado. E pelo que vimos do perfil de conhecimentos daqueles engenheiros, eles teriam dificuldade pra encontrar a recolocação. As grandes questões que a gente levantou, então, foram as seguintes: como é que a gente avalia a obsolescência daqueles engenheiros, e como é que a gente avisa pra eles que eles estão obsoletos, e devem se mexer, buscar proativamente conhecimentos que estão valorizados pelo mercado e determinado momento? Foi aí que a gente desenhou um algoritmo pra avaliação de obsolescência… que em termos de prontidão tecnológica, sabemos que ele ainda precisa evoluir um pouco mais, mas estamos bastante empolgados com os resultados preliminares dos testes de campo com esse algoritmo.

Só pra vocês terem uma ideia, em 2019, participei de um esforço do Núcleo de Gestão do Porto Digital que eles chamaram de Empregaço, em que juntamos 10 empresas médias e grandes, que juntas tinham mais de 200 vagas de trabalho em aberto. Eles fizeram uma grande chamada de currículos, e receberam em torno de 7 mil currículos, dos quais, na nossa triagem, uns 3 mil e 500 eram profissionais potencialmente aproveitáveis. No final das contas, após os processos seletivos, pouco menos de 100 foram contratados. Boa parte deles porque não tinham os conhecimentos necessários… e outra parte porque já estavam obsoletos. Entendem a dimensão do problema?

Ajudar os engenheiros obsoletos a se reencaixarem na área já ajudaria em alguma escala, a combater o problema do skill gap. Isso porque um engenheiro maduro, com experiência de lidar com projetos, mesmo que não domine uma determinada tecnologia, já é um asset de extremo valor, e escasso, no mercado!

Parte 5: Próxima Fronteira da ES [3 min, estimativa]

[[ADOLFO] Para você, qual é a próxima fronteira da engenharia de software? (pode ser algo que você acha que vai acontecer ou que você gostaria que acontecesse em nossa área)]{.mark}

[CF] Eu enxergo que uma grande fronteira que a gente precisa atravessar, é trazer o treinamento sobre aspectos humanos e sociais para dentro do currículo de formação básica dos engenheiros de software. O desenvolvimento socioemocional não é trabalhado de maneira sistemática nos currículos da computação, e mesmo nos programas que utilizam as metodologias ativas mais avançadas, são raros os casos em que o desenvolvimento socioemocional não é desenvolvido de maneira totalmente acidental.

Parte do meu esforço de pesquisa consiste em conversar muito, e continuamente, com profissionais da área de RH de empresas de TI, e uma das coisas que essas conversas vêm mais apontando é a demanda por habilidades sociais básicas, que como contratantes, estas empresas sentem falta nos engenheiros de software. Eu acredito que a gente pode desenvolver sim, sistematicamente, habilidade dos engenheiros de trabalharem em equipe, de conseguirem se comunicar de maneira efetiva, de exercitarem a colaboração como parte da sua rotina de trabalho e tudo mais, desenvolver a autogestão, a capacidade de tomar decisões, de gerenciar suas proprias prioridades, dentre vários outros comportamentos.

Inclusive, no grupo de pesquisa, hoje, temos colaboração de pesquisadores estrangeiros que vem experimentando isso, com algum sucesso, em empresas de software e universidades de fora do Brasil.

Parte 6: Encerramento

[Adolfo agradece e passa para o(a) entrevistado(a).]{.mark}

[Ingrid fecha o episódio.]{.mark}

Texto para divulgação

Neste episódio, conversamos com César França, professor do Departamento de Computação da Universidade Federal Rural de Pernambuco (UFRPE) e Head of Research na CESAR School, que é a escola de inovação do CESAR, instituto de inovação localizado no Porto Digital do Recife.

Sites de César

Links Citados

=======

Drafts

[x] Uma de suas linhas de pesquisa é educação, o que você pode dizer sobre estilos de aprendizado e hábitos de estudo dos Engenheiros de Software? Como eles se diferem/assemelham com outras áreas?

[x] Você está buscando entender mais sobre []{.mark}Qualidade para Pesquisas em Educação em Engenharia de Software, o que você pode adiantar para os ouvintes sobre essa questão? O que te levou a investigar isso?

[x] Nas suas investigações, quais eram os principais critérios de sucesso para criação de equipes de desenvolvimento de software?

César, se eu for dono de uma empresa de software e pagar bem meu funcionário, ele não já está motivado o suficiente?