Como desenvolvedores podem aprender a linguagem dos stakeholders do negócio

Há mais de 15 anos tenho me interessado pelo que chamamos de "a magia das palavras e da linguagem". É algo que está estritamente relacionado a como as pessoas ao longo da história se comunicaram umas com as outras e como as verdadeiras intenções de comunicação foram distorcidas por palavras não compreendidas na tradução. Agora, quando tenho que me mover com fluidez entre os stakeholders e os desenvolvedores, vejo ainda com mais frequência como as mensagens faladas ou escritas podem ser ambíguas, se entendermos por meio de filtros incorretos.

Qual é a maneira mais fácil de aprender idiomas que não conhecemos? Conversando com pessoas que são fluentes nesses idiomas. Essa regra é aplicável para todos, cooperando e nos comunicando dentro do ambiente do projeto, mas permanecendo em grupos separados diariamente, como uma equipe de desenvolvedores ou operações.

Se olharmos para os diferentes grupos que participam do processo de desenvolvimento de software, podemos facilmente ver que se comunicam em diferentes níveis em termos de linguagem, usando diferentes "dicionários", conjuntos de palavras, significados e sentenças, dificultando a compreensão das pessoas que não são deste grupo.

Este artigo aborda esse cenário em áreas nas quais observei mais tensão, falando sobre impedimentos e bloqueadores, aprendizagem individual e em equipe, opções reais e gerenciamento de risco.

Impedimentos e Bloqueadores

Os stakeholders do negócio reconhecem os bloqueadores da mesma maneira que os especialistas e desenvolvedores, isto é, restringem os problemas e trabalham para resolvê-los, o que precisamos fazer é dar valor monetário a esses itens. Se afetam materialmente a posição financeira de uma empresa no final do ciclo de divulgação, temos que reconhecê-los nas demonstrações financeiras. Não basta apenas dizer "Estamos bloqueados, faça alguma coisa". Para permitir que as partes interessadas do negócio corrijam e priorizem eficientemente os problemas, devemos apoiar seu processo de tomada de decisões com informações que ajudarão na monetização dos problemas. Qual parte do trabalho está bloqueada e por quanto tempo? Como isso afeta o tempo de entrega? Existe algum tempo ocioso inesperado do desenvolvedor? Quais outros itens na fila dependem do item bloqueado? Esse tipo de informação apoiará não apenas o gerente do projeto, mas principalmente os donos do orçamento, na tomada de boas decisões.

O importante, do ponto de vista de um stakeholder do negócio, é um entendimento dos problemas que temos como desenvolvedor. É por isso que tento fornecer às partes interessadas situações paralelas para que possam aceitar e facilmente relacionar. Temos algum problema com o aumento do trabalho em andamento? Relacione-o ao gerenciamento de estoque ou ativos em construção. O projeto parece criar débitos técnicos? Compare-o com bicicletas fora de moda em seu armazém ou com o pagamento de um empréstimo necessário.

É possível ler mais sobre contabilidade de inventário para desenvolvedores de produtos no artigo, Bikes, bananas and work in progress.

Organizando um orçamento e planejando o tempo para que as equipes aprendam

Começaremos com algo óbvio, mas muito esquecido, se otimizarmos o processo de ocupação e trabalharmos com capacidade total, nunca deixaremos tempo para o aprendizado ativo de uma equipe. Uso intencionalmente a palavra "ativo", porque a aprendizagem passiva é algo que acontece quando repetimos o mesmo conjunto de tarefas, um fenômeno bem conhecido que foi estudado no século XIX. No entanto, isso se aplica principalmente à fabricação.

No trabalho baseado no conhecimento, que é o domínio em que estamos discutindo, ter tempo para a aprendizagem é crucial e é semelhante a encontrar tempo para melhorias.

É claro que isso não significa que devemos chegar na equipe e dizer: "a partir de agora, entre as 14h e 15h, todos aprenderão coisas novas e melhorarão as antigas." Em vez disso, precisamos dar espaço, conforto e segurança às pessoas para dizer "agora vou aprender. Agora vou ler. Agora farei o trabalho que mais tarde nos ajudará", dar a confiança de saber que, em caso de ociosidade, é possível usar o tempo para o autodesenvolvimento, o que nunca é um investimento perdido. Mas cada projeto, para ser sustentável, tem de dar espaço aos integrantes para aprender e melhorar, o que então se torna parte do orçamento regular do projeto, até que possa ser diretamente conectado aos objetivos do mesmo.

Quando estamos desenvolvendo o orçamento de um projeto, a parte de aprendizado se enquadra na categoria de despesas de pesquisa e não deve ser capitalizada, mas sim eliminada. É por isso que não é preciso contabilizá-la ou rastreá-la separadamente. No entanto, é possível fazer esse controle em um relatório do projeto, com base no nível de detalhamento exigido pelos interessados.

Os Benefícios do Aprendizado Individual e em Equipe

Vamos começar com a afirmação de que o trabalho do conhecimento é um processo de aprendizagem constante. Em qualquer momento de um projeto, executamos atividades utilizando o melhor do nosso conhecimento. Mas nunca devemos e nunca paramos de aprender. Quando desenhamos o fluxo de trabalho com uma equipe, uma das perguntas básicas deve ser, "Quais são as fases do aprendizado?" e não, "Quais são as etapas do processo?" ou "Qual fase precede essa?", porém para responder a essas perguntas nos concentramos puramente na aprendizagem.

O que procuramos mostrar aos stakeholders dos projetos é a relação de descobertas de trabalho versus trabalho planejado, a partir da visualização transparente e contínua do que tínhamos planejado quando o projeto começou e o que descobrimos durante a análise e o desenvolvimento. Isso os ajuda a entender como progredimos em relação ao orçamento e ao cronograma, e como tomamos decisões sobre o que continuamos a desenvolver e o que é não é tão urgente em qualquer fase do projeto.

Os stakeholders de negócios não são os inimigos, uma vez que tenham informação suficiente sobre onde estamos e o que esperamos que aconteça nos próximos passos, estão dispostos a aceitar pedidos ou decisões razoáveis, até mesmo tempo de aprendizado adicional que os membros da equipe possam solicitar.

É possível apresentar as oportunidades de aprendizado usando o efeito da curva de aprendizado, embora isso seja algo que não temos como evitar, muitas vezes observamos esse fato sendo ignorado ao planejar um projeto ou em um trabalho de previsão. Tendemos a traduzir as métricas e estatísticas do estado estável para as fases iniciais, quando a equipe ainda está sendo formada. Da mesma forma, isso se aplica à nova pessoa em um papel, que precisa aprender não apenas o seu lugar no projeto, mas muitas vezes é necessário aprendizado e adaptação às novas responsabilidades.

Vamos ter isso em mente ao planejar o trabalho ou identificar impedimentos. É possível ler mais sobre o efeito da curva de aprendizado no artigo Never stop learning - why is learning curve effect so powerful?

Opções Reais

O artigo publicado na InfoQ Opções Reais: um pilar para as práticas ágeis aborda como usar opções reais para adiar decisões até o último momento possível. Gostaria de esclarecer uma coisa aqui: o que é referido como uma "Opção Real" no artigo tem como base o modelo de Black-Scholes, que é um método para avaliação de opções, mas não cobre realmente quais são as opções reais.

O que reconhecemos na gestão financeira como opções reais são alternativas para projetos ou investimentos empresariais. E temos de fato quatro opções a considerar em nossos projetos: a opção de adiar, de expandir, de abandonar e de reimplantar.

Neste artigo não abordaremos a opção de atrasar, opção que é tratada com bastante profundidade no artigo que citamos anteriormente.

A opção de expandir existe quando uma empresa tem a possibilidade de fazer novos investimentos que aumentam o valor presente líquido de um projeto, que originalmente talvez não parecesse valer a pena.

A opção de abandonar, ou retirar é, na verdade, a opção de encerrar o projeto durante o ciclo de vida, uma vez que não se justifica, financeiramente falando, continuar o seu trabalho. A experiência diz que essa opção é a mais difícil de colocar em prática, considerando tanto os custos irrecuperáveis quanto o aspecto psicológico desse tipo de decisão.

A última opção é a de reimplantar, que é quando uma empresa decide, em vez de abandonar o projeto atual, usar o resultado do projeto para outro. Nem sempre é possível, portanto, não pode ser tomado como garantido, mas ter essa opção minimiza a sensação de perda que resultaria de um encerramento do projeto.

Cada uma dessas opções requer uma análise cuidadosa dos fluxos de caixa do projeto e das decisões das partes interessadas com base em projeções financeiras. Digamos que, se escolher a opção de atrasar ao invés de abandonar, será necessário garantir que o valor líquido do projeto (NPV ou net present value) ainda seja positivo ou que seja positivo após a alteração do curso. Qualquer decisão que afete negativamente o NPV seria rejeitada pelos stakeholders e patrocinadores do negócio.

Gestão de Riscos e Incertezas na Contabilidade

Vamos começar com a diferenciação que geralmente experimentamos entre risco e incerteza. Risco é algo que pode ou não ocorrer, mas podemos calcular estatisticamente sua probabilidade ou frequência, com base em registros passados. Eventos incertos são aqueles que não podemos prever com confiança estatística.

Para lidar com a incerteza, fazemos pesquisas de mercado que visam minimizá-la. Podemos usar pesquisas, coletar feedback e realizar retrospectivas.

A gestão de riscos, quando baseada em dados, oferece uma gama muito mais ampla de possibilidades. O mais comum é usar os valores esperados, que se concentram na probabilidade de resultados. A próxima é a análise de sensibilidade, que pode ser usada quando podemos estabelecer dependências entre as variáveis-chave do projeto. Geralmente, envolve a alteração de uma variável-chave para observar como as outras se comportam. Vamos imaginar que as partes interessadas nos perguntem qual é o impacto da mudança de um dos desenvolvedores para outro projeto. Devemos tratar esse desenvolvedor como uma "variável-chave" e analisar o impacto em outras variáveis. Por exemplo, um desenvolvedor a menos significa diminuir o custo total, mas em contrapartida aumenta o tempo de entrega. Outra possível mudança é a curva de aprendizado da equipe quando uma pessoa sai, provavelmente afetando o orçamento do projeto. Uma vez que todas essas variáveis ​​dependentes tenham sido conectadas e analisadas, é possível decidir se esse cenário é aceitável ou não do ponto de vista do projeto. O que adicionalmente nos apoia nesses casos são opções reais, e é assim que todos esses conceitos funcionam juntos.

Provavelmente algo muito bem conhecido pelos desenvolvedores são os diferentes tipos de simulação, incluindo a simulação de Monte Carlo, para entender melhor o impacto de um risco para o projeto. Este simulador depende de um grande número de dados e pode ser usado para analisar mais variáveis no mesmo momento. O que é importante para o método de Monte Carlo é a aleatoriedade dos dados de entrada para gerar uma distribuição de probabilidade mais confiável. Como esse método reúne muitos pontos de dados, é mais confiável na avaliação da probabilidade do que, por exemplo, na análise de sensibilidade, que é apenas da perspectiva de uma variável.

E falando sobre o impacto, é possível utilizar a matriz "probabilidade de impacto", e "frequência de severidade", com quatro opções para risco do projeto: aceitar, transferir, controlar/reduzir ou abandonar/evitar.

Finalmente, o que talvez não esteja diretamente estabelecido pela análise de dados, mas que vale a pena considerar, são os tipos de partes interessadas com as quais lidamos. As pessoas geralmente se enquadram em uma das três categorias: pessoas em busca de risco, neutras ao risco ou avessas ao risco. É importante ter em mente que tipo de personalidade os stakeholders representam. Vale a pena estar ciente dessa classificação, não apenas ao discutir os riscos do projeto, mas também ao tentar persuadir alguém sobre uma nova ideia ou ao criar um caso comercial. Enquanto poucos estão realmente pensando em preferência de risco pessoal, isso é algo que é relevante para a maioria de nós o tempo todo.

Mesmo falando sobre áreas difíceis como contabilidade ou desenvolvimento de produtos, ainda há pessoas por trás desses processos. A comunicação é a chave para entender os colegas e clientes, comunicação frequente ajuda a alavancar o conhecimento extensivo de ambos os lados, e todos podemos contribuir para esse entendimento, ou pelo menos aprender algo que nos enriquece como seres humanos.

Sobre a autora

Anna RadzikowskaACCA, KMP, product owner e gerente de projetos. Tem mais de 10 anos de experiência em finanças, treinamento e gerenciamento de projetos, trabalhando no setor público, com grandes empresas e administrando seu próprio negócio. Atualmente, é líder da equipe de suporte ao produto e product owner de soluções RPA aplicadas ao setor financeiro. Profissional de Gestão Kanban e membro da ACCA fato que ajuda a combinar conhecimento teórico e trabalho de projeto, com a aplicação prática nas atividades diárias, resultando em suporte contínuo, treinamento e melhorias mesmo após o término do projeto.