No mundo corporativo e em empresas de tecnologia, apesar da evolução de diversas metodologias de desenvolvimento de software, um grande desafio ainda é a definição de requisitos. Por influência da onda Lean, incluindo o conceito Lean Startup criado por Eric Ries e também a partir de conceitos de desenvolvimento rápido de software (Agile), as empresas de tecnologia tem desconstruído os métodos e procedimentos tradicionais e suas respectivas documentações se valendo de diferentes formatos (user stories, canvas, diagramas de caso de uso, protótipos, mapas mentais, etc.). Mas ainda assim, até hoje, é um consenso que qualquer formato de documentação é passível de erros, torna-se rapidamente desatualizado e com frequência não consegue expressar os reais objetivos de negócio que motivaram o projeto de desenvolvimento.
Requisitos de software existem?
É neste ponto que o desafio se torna real e concreto. Mark Schwartz, Enterprise Strategist na Amazon Web Services, em seu livro “A Seat at the Table: IT Leadership in the Age of Agility”, declara que requisitos de software simplesmente não existem, pois são meramente um formato criado para “empacotar” a comunicação entre os negócios e a área de TI da empresa, totalmente suscetíveis à dificuldade de comunicação existente entre estas áreas. Schwartz cita alguns exemplos em seu livro, entre eles os requisitos de software que não são tão necessários, ou seja, incorporam características (features) que não trazem real benefício ao processo-alvo da solução, tornando-a “inflada”, em outras palavras, requisitos solicitados que não precisariam ser desenvolvidos.
Startups versus mundo corporativo
Mais recentemente, esta consciência de fragilidade dos documentos de requisitos popularizou as metodologias ágeis de desenvolvimento e estimulou práticas de integração entre equipes de desenvolvimento de software, operações e áreas de negócio (DevOps) - estratégia bem-sucedida em startups de tecnologia ao redor do mundo. O desafio é que, no mundo corporativo, a abordagem colaborativa de DevOps não é de fácil implementação, pois, mais do que sinergia, exige uma atuação conjunta de Product Owners, desenvolvedores, usuários-chave das áreas de negócio e profissionais de infraestrutura.
Tem que haver uma maneira melhor de entregar
Justamente pela busca de soluções práticas para estes dilemas, Mark Schwartz indica o livro “Impact Mapping: Making a big impact with software products and projects”, de Adzic Gojko, consultor especialista em projetos de software. Em um livro de apenas 86 páginas, Gojko propõe um formato para visualização do escopo de um projeto bastante simples e trivial, mas que pode fazer a diferença em projetos de desenvolvimento de software no mundo corporativo. Segundo Gojko, em tradução livre: “Atualmente, o software está em toda parte, mas inúmeros produtos e projetos de software morrem de forma lenta sem causar qualquer impacto. O resultado é uma enorme quantidade de tempo e dinheiro desperdiçados devido a pressupostos errados, falta de foco, má comunicação de objetivos, falta de compreensão e desalinhamento com as metas gerais. Tem que haver uma maneira melhor de entregar!”
Frameworks não resolvem cultura
O desabafo de Gojko encontra eco em cada profissional de tecnologia que sofre com grandes projetos em que os entregáveis não atingiram as expectativas das áreas de negócio. Antes de apresentarmos o método proposto por Gojko, considero fundamental levar você leitor deste artigo a uma importante reflexão, citada por um amigo e PMO, ele me disse: “os frameworks muitas vezes fazem contribuições importantíssimas mas não para questões culturais e políticas, que na maioria das vezes são as principais causas de falha na mudança de processos”.
Em outras palavras, de nada adianta a tentativa de adoção de qualquer método ou procedimento se o ambiente organizacional, a cultura atual, incluindo interesses, expectativas e a competência dos profissionais responsáveis não tenham sido levadas em consideração no projeto de implementação de uma nova metodologia ou organização de atividades. O sucesso de uma nova estratégia está vinculado à correta inserção da mesma nos procedimentos organizacionais de uma empresa, em plena sinergia com os anseios dos profissionais que a compõe. Se este ambiente organizacional não estiver preparado, com as pessoas certas nas posições corretas, o framework não será utilizado de forma adequada e logo será esquecido ou se tornará mais um item de burocracia, em seu sentido pejorativo.
Um estudo da McKinsey mostrou que a maioria dos fracassos não está relacionada à ausência de um bom plano ou de recursos, mas sim à falta de engajamento da organização, seja dos colaboradores ou da própria liderança. A organização não “comprou” a mudança.
“Organizações perdem muito tempo e esforço construindo o software errado.” — Adzic Gojko
O Mapa de Impacto
O livro de Gojko traz uma abordagem relativamente simples - chamada de Mapa de Impacto - que me pareceu útil para ser aplicada em apenas um uma ou duas reuniões no início de qualquer projeto. Este deve responder, de forma visual, a respeito do problema que está sendo confrontado na solução a ser desenvolvida, baseado em apenas quatro perguntas: Por quê, Quem, Como e O quê. A abordagem proposta por ele busca distribuir responsabilidades e maximizar a eficácia da comunicação, principalmente entre as áreas de TI e de Negócios. Um Mapa de Impacto também é um storyboard de nossa compreensão conceitual em como abordar as metas a serem alcançadas no projeto. Segundo Gojko, estas questões são importantes demais para serem deixadas sob responsabilidade apenas do “cliente” ou do Product Owner. A seguir, um resumo e minhas considerações a respeito dos quatro pilares do Mapa de Impacto proposto por Gojko:
Por quê?
O centro de um Mapa de Impacto responde à pergunta mais importante: por que estamos fazendo isso? Qual o objetivo que estamos tentando alcançar? Pode soar um pouco óbvia a pergunta, mas é frequente equipes de desenvolvimento tomarem decisões sem claro conhecimento dos objetivos a serem alcançados. Saber por que estamos fazendo algo é a chave para tomar boas decisões sobre custo, escopo e prazos, tanto no início do projeto quanto diante de mudanças de escopo. Por outro lado, se entregarmos exatamente o escopo solicitado e o projeto não atingir os objetivos, ele será considerado um fracasso.
Quem?
Quem são os atores que devem influenciar o produto final a ser entregue em um projeto de desenvolvimento de um software? Alguns modelos de requisitos se preocupam apenas com “o que o software deve contemplar” e esquecem completamente dos usuários que serão beneficiados com ele! Principalmente em soluções que visam aumento de eficiência operacional, é fundamental que os usuários finais sejam priorizados. Segundo Gojko, “…a maioria dos modelos de requisitos ignora completamente isso - eles se concentram no que o software deve fazer e não em quem será beneficiado depois de sua entrega. Então, em algum momento no meio do projeto, um novo ator surge do nada e tudo é alterado, ou alguém com influência suficiente na tomada de decisões apenas interrompe a entrega no meio do processo.”
Gojko sugere a cautelosa definição dos atores de um projeto na seguinte ordem:
- Indivíduos específicos
- “Persona” do Usuário
- Papéis ou cargos
- Grupos ou departamentos
Infelizmente, Gojko explora pouco este tema em seu livro, apenas expondo os quatro grupos e apresentando alguns exemplos práticos para definição dos mesmos. A dica aqui é que, não apenas no exercício inicial deste Mapa de Impacto mas, principalmente no processo de revisão dos requisitos de software definidos, é fundamental para o projeto, que estes requisitos sejam revisados em conjunto e sob a perspectiva de cada um destes grupos! Destaco especial valor ao exercício para definição da “persona” do usuário, conceito usual em agências de publicidade, mas que raramente vejo aplicado no desenvolvimento de softwares, costumo dizer que nós de TI (e me incluo nisso) sempre achamos que sabemos mais do que os usuários finais.
Como?
Como o comportamento destes atores vai mudar? É necessário prestar atenção às atividades que os usuários executam no dia a dia, ao invés de simplesmente ouvir suas ideias a respeito de um produto ou serviço. Esta clara visualização permite decidirmos quais funcionalidades melhor contribuem para os objetivos definidos - permitindo priorizá-las. Visualizar as atividades dos usuários finais nos processos que serão aperfeiçoados a partir do software a ser desenvolvido pode trazer insights valiosos para a construção da solução ideal e também para o mapeamento de riscos que possam comprometer a implementação do software desenvolvido, incluindo mudanças culturais necessárias e a melhor abordagem para capacitação dos usuários ao novo software.
O quê?
Segundo Gojko, depois que as três primeiras questões forem respondidas, finalmente podemos conversar sobre o escopo do projeto. Sem um claro mapa de entregáveis para os objetivos do projeto e a justificativa através dos impactos a serem alcançados, se torna difícil tomar decisões de investimento e priorização. Em grandes corporações, com muitos interessados, é usual surgirem requisitos de software motivados pela “vontade” de alguma parte interessada, mas sem nenhuma correlação com os objetivos definidos.
Abaixo um dos exemplos apresentados no livro – as metas para um sistema de transações financeiras.
O exercício na construção de um Mapa de Impacto, como sugerido, além de ser valioso para a justificação do projeto - componente fundamental para um Business Case de uma solução a ser desenvolvida - deve ser revisitado ao longo do projeto de desenvolvimento e servir de trilha para o processo de conclusão das atividades, implementação do software desenvolvido e a validação dos resultados atingidos - benefícios alcançados nas áreas de negócio.
Independentemente do contexto, porte do projeto ou metodologia adotada para a organização dos processos de desenvolvimento, o conceito de Mapa de Impacto proposto pode facilmente ser aplicado.
Referências
- A Seat at the Table: IT Leadership in the Age of Agility — Mark Schwartz (IT Revolution Press, 2017)
- Impact Mapping: Making a big impact with software products and projects — Gojko Adzic (Provoking Thoughts, 2012)
- O segredo das transformações empresariais que funcionam — McKinsey & Company