Automação no cadastro, normatização, tombamento e fiscalização do patrimônio cultural
A humanidade desenvolve softwares há aproximadamente 50 anos. Desde então se vem tentando aprimorar as formas e metodologias de desenvolvimento, tais como modelo Cascata, CMMI, RUP entre outros. Em fevereiro de 2001, em uma “estação de ski”, 17 pessoas se juntaram para relaxar, conversar sobre o esporte e também sobre desenvolvimento de softwares, debatendo sobre os principais acertos e erros de projetos e os princípios e valores gerados aos clientes. Nesse contexto foi criado o manifesto Ágil, o qual tem como principais valores: a) mais ênfase nos indivíduos e interação entre eles do que em processo e ferramentas; b) mais ênfase no software em funcionamento do que na documentação abrangente; c) mais ênfase na colaboração com cliente do na que negociação de contratos; e d) mais ênfase em responder a mudanças do que em seguir um plano.
Aplicação no governo
A metodologia Ágil é uma realidade no mundo de desenvolvimento de softwares na iniciativa privada. Na Administração Pública, até meados de 2010, havia pouca iniciativa nesse novo paradigma de desenvolvimento, não por falta de vontade ou iniciativa dos servidores públicos, mas por possíveis restrições ou desconhecimento da compatibilidade dos princípios do Manifesto Ágil com os da administração pública, leis e normas que regem as contratações de empresas terceirizadas para desenvolvimento de softwares.
Entretanto, a má prática recorrente do não cumprimento de prazos nas entregas de softwares, ou até mesmo da entrega de artefatos de planejamento durante meses de projetos governamentais em detrimento do software integral, fez sucumbir a crença no sucesso de projetos de TI ou, no mínimo, forçou a comunidade pública a tentar novas técnicas ou metodologias, mesmo sem alterações no arcabouço jurídico.
No contexto do governo federal, o Instituto do Patrimônio Histórico e Artístico Nacional (Iphan), na busca por maior eficiência dos serviços prestados a partir da adoção de métodos e tecnologias inovadoras, optou, em 2010, pelo desenvolvimento do Sistema Integrado de Conhecimento e Gestão (SICG) a partir do uso da Metodologia Ágil, baseada no framework Scrum.
O projeto SICG iniciou em 2006 com a análise crítica dos procedimentos de identificação, reconhecimento e gestão dos bens culturais protegidos pelo Iphan. Os resultados apontaram para uma realidade institucional marcada pela ausência de automação nos processos de cadastramento, normatização, tombamento e fiscalização do patrimônio cultural, o que acarretava em uma elevada demora na produção de conhecimento e no seu uso para a gestão dos bens culturais, seja por meio de indicadores ou outros índices passíveis de monitoramento. Os processos de tomada de decisão nos mais diversos níveis eram pouco subsidiados pelos resultados dos investimentos realizados, sejam eles orçamentários ou não. Soma-se a este cenário a completa ausência de inteligência geográfica nos requisitos negociais da Instituição. Sob este contexto, o projeto SICG teve por objetivo geral abordar o patrimônio cultural de forma integrada e sistêmica e ofertar ferramentas de planejamento estratégico para a instituição. O alcance deste objetivo considerou inovação dos meios para o desenvolvimento de softwares e a adoção da inteligência geográfica como parte do negocio do Iphan.
Uma das etapas do projeto SICG foi o processo de automatização do processo de trabalho decorrente das atividades de identificação, reconhecimento e gestão envolvendo normatizações e parte do processo de fiscalização. O objetivo do desenvolvimento de softwares é centralizar, em uma única base de dados, todos os dados relativos aos bens protegidos ou em estudo, com dados relacionais e geográficos integrados. Estrutura-se em três módulos complementares: a) conhecimento, vocacionado para estudos territoriais amplos, com dados históricos, iconográficos, econômicos e geográficos; b) cadastro básico e complementar dos bens: vocacionados para dados gerais e refinados dos objetos e; c) gestão: voltado para automatização de processos de rotinas de fiscalização e fluxo de investimentos. Estes últimos fazem parte de outros sistemas corporativos que serão compartilhados por meio de webservices, permitindo a integração de dados das mais diversas naturezas em uma mesma plataforma com inteligência geográfica.
Para o projeto SICG, adaptaram-se alguns frameworks a fim de se adequar à legislação vigente e à realidade do mundo governamental, mas sempre seguindo os princípios do manifesto Ágil. Algo tinha que ser feito para que o governo deixasse de ser apenas um dos maiores demandantes de software do país e passasse a ser também um dos maiores entregadores de software para a sociedade.
Resposta A mudanças
O uso da metodologia Ágil no projeto SICG apresentou uma série de desafios para sua implementação e desenvolvimento. Em virtude de ser o primeiro projeto, tanto para o Iphan quanto para empresa contratada EGL (importante lembrar que o requisito de contratação não demandou experiência no uso do Scrum), o processo de aprendizado, principalmente nos primeiros quatro ciclos, foi intenso e de reformulações e adaptações à realidade institucional.
Por ser um framework, o Scrum não determina quais os documentos que devem ser elaborados durante os ciclos. No início do projeto não foi criada e nem utilizada documentação de requisitos para mostrar as funcionalidades ao cliente. Entretanto, isso se mostrou ineficaz, pois o Product Owner (P.O.) do projeto não conseguia ter um entendimento da funcionalidade e ser desenvolvida. Em virtude disto, foi necessária a criação de um documento básico de regras de negócio e wireframes para que o P.O. pudesse visualizar e priorizar, de forma mais segura, a funcionalidade e ser desenvolvida.
Em virtude de sua natureza incremental, o projeto foi inicialmente planejado vislumbrando as reuniões de planejamento (Sprint planning) e encerramento (Sprint review e Sprint restrospective). Durante o Sprint planning o objetivo era revisar/refinar os itens priorizados no Backlog, além de mensurar o esforço (planning poker) dos itens que entrariam naquele Sprint. Contudo, nos primeiros ciclos de desenvolvimento, observou-se que o tempo dedicado para o planning (8 horas) não era suficiente para revisar e refinar os itens do backlog do produto. Com isso, optou-se pela antecipação do levantamento e refinamento dos requisitos, levando em conta, no máximo, os dois próximos sprints de desenvolvimento, sendo assim, durante o Sprint planning, os requisitos já estavam definidos e revisados, ficando para esta etapa apenas a mensuração do esforço (planning poker).
Um dos resultados desta tática foi a ampliação da interação entre P.O., ScrumMaster e equipe. Num mesmo período de tempo eram desenvolvidas as funcionalidades aprovadas no Sprint planning, o levantamento de requisitos das próximas sprints e os testes dos produtos entregues no sprint anterior. Por exemplo, durante o desenvolvimento do ciclo 4, a equipe Iphan testava as funcionalidades entregues no Sprint 3 e levantava requisitos dos próximos dois ciclos. Por outro lado, a equipe EGL atuava no desenvolvimento do ciclo corrente e levantamento dos próximos, possibilitando à equipe uma melhor performance durante o desenvolvimento do Sprint e tornando as entregas mais eficazes.
Aceitação de mudanças
A fase de planejamento do projeto, marcada pela forte interação entre equipe Iphan e equipe EGL Ltda., indicou o desenvolvimento do software de forma bottom-up. Desta forma, a cada sprint, o P.O. tinha uma parte do sistema funcionando e pronto para ser testado. Em virtude deste caráter iterativo e incremental e em face do cuidado com os testes, diversas funcionalidades necessitaram de ajustes e/ou refatoração. Para dar conta desta situação, foram desenvolvidos alguns sprints técnicos, que tinham como objetivo ajustar as funcionalidades. As refatorações, que implicavam em mudanças de regras negociais ou na estrutura do sistema, corresponderam a apenas 12% do total de pontos de função pagos pelo Iphan.
Durante os 28 meses do projeto, o time parava em intervalos regulares para refletir sobre como ficar mais efetivo, para então se ajustar e otimizar seu comportamento. Ao longo do desenvolvimento foram realizadas diversas reuniões de marcos lógicos e de análises do estágio de desenvolvimento do software. Foi criado um ambiente de interação entre P.O. e ScrumMaster, onde se compartilhava, em tempo real, o backlog com as funcionalidades desejadas, com história do uso e as prioridades estabelecidas pelo P.O. Outro ponto de contato foi uma planilha de acompanhamento, em tempo real, dos testes realizados pelo P.O. e sua equipe, o que permitiu a incorporação dos ajustes nos ciclos seguintes e um melhor planejamento do esforço da equipe de desenvolvimento. O resultado destas análises culminaram com um relatório de “Lições Aprendidas e Pontos de Melhoria” elaborado pelo P.O., ScrumMaster e fiscal técnico, além dos tomadores de decisão do nível estratégico da Instituição. O acompanhamento utilizou-se de diversos instrumentos de monitoramento tais como o gráfico burn-down e o KanBan.
Pontos fortes e fracos
Os desafios foram “a mola mestra” para se ofertar ao setor público um software diferenciado, que atendesse às necessidades do cliente ao mesmo tempo em que avançasse no uso de metodologias ágeis para o setor público. Um dos principais desafios foi a adaptação da realidade institucional, seja em termos de marcos legais quanto de controle interno, para fazer frente ao ritmo e volume de trabalho demandados pelo Scrum. Pode-se afirmar que um ponto forte do projeto foi a entrega de valor para o cliente a cada Sprint, ou seja, o sistema funcionando em homologação, além de facilitar um maior controle na gestão dos pagamentos, pois o Iphan efetuava os pagamentos apenas de funcionalidades entregues e testadas, ou seja, homologadas pelo órgão. Destaca-se também o ciclo de planejamento (pré-game) com envolvimento de toda a equipe, o que permitiu o entendimento geral do negócio e dos processos que o Iphan queria automatizar. A interação entre a equipe de desenvolvimento, Scrum Master e P.O. durante todo o projeto permitiu a construção de um ambiente sustentável, o que se pode visualizar na baixa taxa de rotatividade da equipe, fortemente comprometida com o projeto. A facilidade de acompanhamento do desenvolvimento e pagamento devido a entregas em ciclos mensais permitiu relacionar o software funcionando com pagamentos, satisfazendo o cliente por meio da entrega adiantada e contínua de software de valor. Em termos de apropriação do cliente, a estratégia de disponibilizar, em rede intranet, o ambiente de homologação para todos os técnicos do Iphan, permitiu maior adesão institucional ao projeto em virtude do acompanhamento dos produtos entregues.
Um dos produtos derivados desta experiência foi o desenvolvimento da Metodologia Iphan de Gestão de Demandas de Desenvolvimento Ágil de Softwares (Midas). Trata-se de um guia corporativo que estabelece o fluxo de gerenciamento de demandas para desenvolvimento e manutenção de sistemas de informação no âmbito desta autarquia. O modelo é contextualmente baseado na metodologia ágil Scrum e em boas práticas de mercado. Possui cinco princípios norteadores: a) envolvimento do cliente; b) entrega incremental; c) foco nos resultados e não no processo; d) aceitação de mudanças; e e) manter a simplicidade. O objetivo é obter um produto funcional e que agregue valor ao usuário final a cada ciclo em um curto espaço de tempo. Um diferencial da Midas é que nela não existem atrasos na entrega. Se uma entrega não for realizada no dia, o ciclo é dado como perdido e só será aceita uma nova entrega no próximo ciclo. Outro ponto importante é que não gerencia atrasos nem defeitos; paga-se aquilo que efetivamente está funcionando. Outra premissa é a documentação é acessória à entrega do sistema; o importante é ter um software em funcionamento e com uma documentação mínima para que a manutenção seja realizada.
Conclusão
Em linhas gerais, a solução informatizada adotada e a metodologia de desenvolvimento cumprem o papel de agregar valor ao serviço prestado à população brasileira. O uso da metodologia Ágil no Iphan não foi apenas uma inovação no Governo Federal, mas também uma tentativa de retomar a confiança, com entregas rápidas de software funcionando e dos gestores públicos em voltar a apostar e investir em Tecnologia da Informação. É um aprendizado que mudou a forma como os tomadores de decisão olham para a área de geotecnologias e para as metodologias de desenvolvimento, além de trazer uma nova fronteira para a ação governamental no Brasil. Como valores agregados ao serviço público, podemos destacar o aumento na celeridade e qualidade do processo decisório da Alta Direção da Instituição, além de uma considerável redução do tempo e esforço para compilação, organização e disponibilização das informações aos técnicos do Iphan, aos parceiros institucionais e, em especial, à população brasileira. O projeto se destaca pelo ineditismo das soluções de integração adotadas e coragem de seus gestores e Alta Direção em garantir condições materiais, políticas e simbólicas como forma de se percorrer um caminho adequado para enfrentar as dificuldades e colocar o projeto SICG como paradigma para os gestores públicos da política de preservação do patrimônio cultural no Brasil e nos demais países da América Latina.
George Alex da Guia
Arquiteto e urbanista pela UnB. Analista de Infraestrutura/Ministério do Planejamento, Orçamento e Gestão em exercício no Iphan/Sede. Product Owner – Projeto SICG.
george.daguia@iphan.gov.br
Herbert Parente
Bacharel em Ciência da Computação pela Univ. de Fortaleza. Servidor público desde 2010 com formação em Gestão de TI, Licitações e Contratos.
herbertparente@gmail.com
Humberto Mattos
Bacharel em Ciência da Computação. Analista em Tec. da Informação do Min. do Planejamento, Orçamento e Gestão desde 2010. Responsável pelo desenvolvimento de Sist. de Informação no IPHAN.
humberto.carvalho@iphan.gov.br
Jamil Buzar Neto
Bacharel em Ciência da Comp. pela Univ. Católica de Brasília. Atua na gestão de projetos pela empresa EGL LTDA.
jamil.neto@gmail.com
Quadro demonstrativo da estratégia de desenvolvimento do software