Agilidade = Produto + Processo + Engenharia
Antes de querermos “transformarmos” alguma coisa, sejamos responsáveis e honestos em reconhecer onde estamos, o que temos e o que nos falta para evoluirmos tanto como pessoa e como empresa, e só assim caminharemos para um amadurecimento e maior profissionalismo de nossas atividades.
Abaixo trechos de uma reflexão de Junho deste ano, durante a montagem do curso “Agilidade 360” que ministrei em Julho como um spin-off da minha disciplina de “Métodos Ágeis” da pós-graduação em Engenharia de Software da Pontifícia Universidade Católica de São Paulo.
Essas duas “frases da moda” (buzzwords) são atualmente o menu de entrada de qualquer palestrante ou consultor que atue no mercado de tecnologia, tendo se tornadas inclusive nomes de cargos em empresas, ou ao menos termos de auto intitulação no LinkedIn, como “transformador digital” ou “transformador ágil”.
Em uma reunião de planejamento estratégico nenhum executivo ou líder de tecnologia iria se opor a alguém que os oferecesse tais coisas para sua empresa como promessa de trazer maturidade e crescimento. É quase como oferecer uma bala de prata a um Caçador de Lobisomens [1], só que sabemos que não existem Lobisomens, não é?
Quando falamos principalmente em “agilidade” e tudo o que essa palavra traz consigo em nosso atual contexto, acredito que nos falte um tripé apoiador e não somente nos lembrarmos dos princípios em um manifesto, mas uma visão do todo e o seu impacto no resultado final em nosso ecossistema.
Agilidade = Produto + Processo + Engenharia
Essa simples equação (pois suas componentes são incógnitas que precisamos definir) resume a minha visão de como devemos alinhar o que esperamos e até onde podemos ir em relação a expectativa do que iremos alcançar.
No curso que montei (e também ofereço na pós-graduação em uma versão mais aprofundada) começo formalizando o que é um processo e principalmente qual a função de sua existência, no entanto não apresento nenhum “método ágil” ou coisa do tipo. Apenas a definição e um breve histórico dos processos de software até o início da década de 90.
Dado esta introdução, começo olhando para a primeira incógnita de nossa equação PRODUTO.
A ideia desta primeira etapa é trazer a sensibilidade e o reconhecimento da importância de se ter uma área de produtos (ou um PO ou PM) bem estruturada.
Começamos entendendo o que é um processo de desenvolvimento de produtos genérico [2] e seguimos para o bom e velho MVP [3] da moda. O foco desta etapa é: aprender a construir rápido e testar rápido, mas principalmente entendendo a importância de se ter métricas atreladas ao que se está testando. Coisas como pensar em seu produto, no seu usuário (persona e afins), quanto vale, custo de aquisição do cliente, performance, SEO, valor do tempo de vida do cliente, Métricas Piratas e entre outras.
Qual o motivo de tudo isso? Antes de pensarmos em agilidade, devemos saber minimamente o porquê das coisas que estamos desenvolvendo, justificá-las com números, ao menos com estimativas do potencial de valor que elas podem nos trazer ou do que esperamos que elas tragam. É minimamente entender que o trabalho que cabe a uma pessoa de produtos não é apenas priorizar coisas e escrever histórias de usuários (seja lá o que for isso), mas compreender e justificar toda uma evolução de algo que deve ter uma real motivação para ser desenvolvido ou evoluído.
Seguido de Produto, apresento uma a importância do porquê jamais podemos deixar a ENGENHARIA de lado.
Como condição fundamental para a construção de bons produtos, a engenharia nos traz a visão prática de ferramentas, sua utilização e como devemos nos orientar através destas práticas.
É muito fácil alguém ler um livro sobre SCRUM, ou fazer um curso e acreditar que já está minimamente apta para proporcional a tal da “transformação”.
Sempre fui contra a iniciação de pessoas em “agilidade” através de SCRUM.
Minha opinião é de que, pelo fato de ser pouco prescritivo, o SCRUM deixa algumas lacunas que a depender do desconhecimento de quem o interpreta pode o levar a acreditar que basta seguir suas “cerimônias” e produzir seus “artefatos” que estará no santo caminho da agilidade.
E é neste ponto que a maioria de nós é enganado.
Antes de sequer falar sobre SCRUM, começo com os princípios, práticas e valores da Programação Extrema (eXtreme Programming — XP).
E o motivo é simplesmente pelo fato da XP abordar diretamente questões relacionadas a Engenharia: qualidade do código em relação a design e arquitetura, testes (em geral), processo de integração e processo de implantação de software (vale a discussão sobre cada um destes pontos no futuro).
Antes de você se propor a fazer software, caso esse seja o produto final de seu produto, você precisa entender quais as variáveis estão relacionadas a construção do seu objetivo final. E não estou aqui dizendo que são coisas fáceis, tenho e vivo problemas até hoje com cada uma destas questões em meu ambiente de trabalho, mas você precisa estar ciente de todas elas e de preferência saber algum caminho para que possa atuar em sua melhoria.
Resumindo este ponto, pense em um Engenheiro Civil (odeio analogias com esta engenharia, mas fica mais compreensível), ele sabe as etapas de construção de uma casa, mas não basta a ele saber apenas suas etapas, ele precisa saber avaliar e conduzir se cada etapa está de acordo com o esperado e se está minimamente lidando com as melhores práticas para que o objetivo final possua qualidade real, essa é a ideia de entender a engenharia da atividade em que se está propondo a efetuar.
E finalmente, após passarmos por Produto e Engenharia podemos entender a componente que unificará tudo isso, o PROCESSO.
Agora sim, após entendermos minimamente sobre produtos e sobre a importância do papel da engenharia na construção de produtos baseados em software podemos olhar para o processo.
Este terá papel em direcionar cada um destes esforços (minimamente representados por ADIT — Análise, Desenho, Implementação e Teste) e mais, nesse momento que entenderemos onde Tecnologia e Produtos terão sua intersecção entre uma priorização baseada em métricas ou na expectativa da obtenção de resposta sobre uma hipótese, ou sobre a decisão de produzir algo “completo” ou apenas um “MVP”.
É importante pessoas desenvolvedoras de tecnologia serem capazes de olharem para o todo e serem capazes de contribuírem com seu time de produtos através de sua visão do que pode levar mais ou menos trabalho, ou melhor ainda, como construir boas soluções com baixo investimento para validarmos hipóteses sobre nossos produtos.
É a velha questão de CUSTO, TEMPO e QUALIDADE, sua missão é escolher dois, conscientemente abrindo mão de um terceiro.
E claro, a expectativa é de que no futuro você seja capaz de sanar suas dívidas (NÃO DÉBITOS, use as palavras corretas para dar significado ao que quer dizer, débito é diferente de dívida), sejam elas técnicas ou de produtos.
Neste momento, você pode trazer o sabor de processo ou método que melhor se encaixar, e aqui finalmente trazemos SCRUM, KANBAN, XP, FDD, CRYSTAL, seja lá qual sua equipe tenha melhor fluxo de trabalho.
Sabemos que times atuam melhor com composição de práticas e não estritamente seguindo um método específico. Composição de práticas de diversos métodos traz o melhor de cada método para a atual realidade e cultura de uma equipe/empresa [4].
Em suma, apenas compreendendo a importância de uma compreensão sobre o seu produto, esteja ele ainda sendo definido e compreendido ou já descoberto, compreendendo suas responsabilidades quanto a engenharia em termos de qualidade, design de código, processo de integração, implantação e monitoramento (pode chamar de DEVOPS que fica mais chique) e costurando tudo isso com um processo que encaixe e dê visão de nossas responsabilidades com cada uma destas etapas é que podemos alcançar certo grau em “agilidade”.
Segundo o pesquisador Philip Krutchen “agilidade é a capacidade de uma empresa se adaptar a mudança a uma taxa maior que a sua ocorrência”, parece simples, mas para que um alto grau de “agilidade” seja alcançado devemos ser responsáveis e reconhecermos nossas incompetências e problemas.
Sejam eles culturais, estratégicos, técnicos ou humanos, sim, humanos, perfis específicos podem impactar diretamente as capacidades de um time atingirem pleno ritmo ou engajamento e comprometimento.
Uma “transformação” vai muito além um processo ou ferramentas, é uma questão que deve ser olhada ponta a ponta. De nada adianta gastar seu tempo pensando em um produto se sua empresa é direcionada por uma área comercial que consome todo o esforço de seu time vendendo pastel. Isso talvez pague os boletos no final do mês e talvez até bata as metas da empresa, mas no longo prazo não é algo saudável e sustentável.
Pense nisso e compartilhe sua visão nos comentários ;)
Referências :
[1] Brooks, Fred P. (1986). “No Silver Bullet — Essence and Accident in Software Engineering”. Proceedings of the IFIP Tenth World Computing Conference: 1069–1076.
[2] ROZENFELD, Henrique; FORCELLINI, Fernando Antônio; AMARAL, Daniel Capaldo; TOLEDO, José Carlos de; SILVA, Sergio Luis da; ALLIPRANDINI, Dário Henrique; SCALICE, Régis Kovacs. Gestão de Desenvolvimento de Produtos: Uma referência para a melhoria do produto. São Paulo: Editora Saraiva, 2006.
[3] Ries, E. (2011). The lean startup: How today's entrepreneurs use continuous innovation to create radically successful businesses. New York: Crown Business.
[4] SILVA, Marvin Ferreira; LAGO, Lucas S. M.; SPINA, Edison. An analysis of Agile practices in Brazilian startups: the identification of initial practices adopted by startups. In: CONTECSI — 15th International Conference on Information Systems and Technology Management, 2018, São Paulo. FEA-USP, 2018. p. 2319. DOI 10.5748/9788599693148–15CONTECSI/PS-5755.
Disponível em: <https://www.researchgate.net/publication/327855661_AN_ANALYSIS_OF_AGILE_PRACTICES_IN_BRAZILIAN_STARTUPS_THE_IDENTIFICATION_OF_INITIAL_PRACTICES_ADOPTED_BY_STARTUPS>. Acesso em: 10 de Abr. 2020.
