Avslutning

No STF, a gestão de portfolio de projetos de software tem início no momento em que o demandante solicita à área de TI um serviço de consultoria. O serviço é solicitado por meio do Service Desk do Tribunal e o pedido é encaminhado ao consultor, que se comunica com o demandante para buscar uma compreensão inicial em relação à necessidade – normalmente referente a um problema a ser resolvido ou a uma oportunidade a ser aproveitada – em relação à qual se vislumbra a possibilidade de que a solução seja dada por meio ou com o apoio de um serviço de TI, que pode ou não abranger software.

Essa comunicação pode envolver um ou mais contatos e, a partir dela, o consultor – um profissional com amplos conhecimentos sobre os serviços e softwares de TI oferecidos – busca condições iniciais para indicar se a solução mais adequada ao caso exigirá um projeto de software ou se poderá ser resolvida com outros tipos de solução, como reengenharia de processos ou utilização de serviços/softwares existentes. Durante os contatos, o consultor procura conhecer os processos de trabalho envolvidos e aprofunda o entendimento por meio de questionamentos e investigações.

Nesse sentido, o comentário do consultor entrevistado citou exemplos de propostas de novos projetos que aproveitaram projetos de software já existentes no portfolio ou sistemas já implantados. Comentou também sobre a possibilidade de que soluções sejam implementadas por meio de ajustes nos processos de negócio, ou seja, de reengenharia de processos:

Já houve propostas que ‗pegaram carona‘ num projeto já existente. A Central do Cidadão, por exemplo, queria um sistema para gerenciar os documentos que entram no Tribunal por meio dela, separando os que têm vínculo com um processo judicial dos que

não têm. Os que possuem vínculo vão para os sistemas do processo judicial, já os outros, hoje, só podem ser tratados pelo sistema Correspondência, que fornece as funcionalidades para a área de protocolo administrativo do Tribunal, mas não possibilita a criação de um perfil específico para a Central do Cidadão. Tecnicamente, não se mostrou adequada a adaptação do Correspondência, que é muito antigo e desatualizado. Assim, inserimos a demanda em outro projeto que já se encontrava na fila do portfolio, chamado MPA-Web.

Os casos de ajustes em processos de negócio da área demandante são mais raros, mas há um exemplo recente. Trata-se de uma situação ocorrida na TV Justiça, que possuía uma demanda para desenvolvimento de um sistema de gerenciamento de acervo de imagens. Eles já contavam com um sistema, adquirido de terceiros, mas não estavam satisfeitos pelo fato de que o suporte estava deixando a desejar. Após algumas conversas e sugestões de ajustes na contratação, eles desistiram da demanda e resolveram pela promoção das adequações sugeridas, o que resultou na melhoria da gestão contratual e, consequentemente, dos serviços prestados. Também nos possibilitou direcionar os recursos para demandas prioritárias para o Tribunal.

A observação durante algumas das reuniões entre os demandantes e os consultores permitiu verificar que as conversas se dão de maneira bastante natural e que os demandantes sentem-se à vontade para expor a situação atual, inclusive quanto às fragilidades e aos problemas das áreas, e os desejos em relação à solução almejada. Normalmente, já vão aos encontros com uma proposta de solução, muitas vezes baseada em um software que viram, inclusive dentro da própria organização. A proposta é amadurecida durante as conversas com o consultor, a ponto de, conforme exemplificado acima, poderem ser até mesmo redirecionadas para outro tipo de solução.

Caso se indique pela necessidade de um projeto de software – que pode ser completamente novo ou a evolução de um software já existente na organização – o consultor solicita o preenchimento de um documento chamado „Formulário de Solicitação de Projetos de Software‟. O formulário é inspirado no conceito de business case, que, segundo Remenyi (1999), visa à composição de um documento que tem como objetivo capturar, de forma organizada e profissional, a razão ou a motivação de um investimento, ou seja, as informações necessárias à análise quanto à adequação ou não de se iniciar um projeto.

O consultor informou que, antes de solicitar o preenchimento do formulário, é feita uma análise prévia quanto ao tamanho do projeto em termos de duração. A ideia é que pequenos projetos, cujo esforço estimado não exceda ao prazo de 10 dias, não precisem ser submetidos ao processo normal de gestão do portfolio, ou seja, que não passem por todas as etapas de identificação, categorização, avaliação, priorização, etc. Esse tratamento foi definido em conjunto com os comitês descritos na apresentação do caso, que sugeriram a

reserva de um pequeno percentual da capacidade produtiva de cada equipe de desenvolvimento (Corporativo e de Negócio) para tal tipo de projeto.

São projetos pequenos, que se referem a pequenas correções ou evoluções simples e rápidas, muitas vezes relacionadas a melhorias de usabilidade ou criação de relatórios. A priorização em relação a eles se dá por um rito simplificado, no qual são avaliados apenas dois critérios de valoração: um referente ao objetivo do projeto e outro relativo aos beneficiados pela solução. Essa avaliação é feita pela própria TI, com base em informações coletadas pelo consultor durante os contatos com o demandante.

O primeiro, referente ao objetivo do projeto, pode ser enquadrado numa das seguintes opções, apresentadas em ordem crescente de importância: melhoria estética; promoção da ergonomia ou da produtividade; diminuição da quantidade de intervenções operacionais da TI; e acomodação de mudanças em regras de negócio. O outro, referente aos beneficiados, tem como opções, também em ordem crescente de importância: uma unidade; um grupo de unidades; o público externo ou os Ministros. Com base no enquadramento do pedido nesses critérios de valoração, resta definida a ordem de prioridade para execução dos projetos pequenos.

Já quanto aos projetos normais, a análise do formulário para proposição de projetos de software – um dos documentos identificados durante a fase de coleta de dados – permitiu verificar que a instituição coleta informações sobre o valor, os custos, os riscos e o contexto de negócio no qual o projeto se insere. Dentre essas informações, estão: o problema a ser resolvido ou a oportunidade a ser aproveitada; a ligação com as estratégias do negócio; os processos organizacionais afetados; as unidades de negócio beneficiadas; os benefícios a serem auferidos; e as possíveis implicações para o caso de a solução não ser fornecida.

Todos os projetos, tanto os pequenos quanto os normais, ambos apresentados nos parágrafos acima, são categorizados em função dos processos de negócio aos quais se referem, a fim de que componham o portfolio correto. Conforme exposto na apresentação do caso, a organização adotou uma categorização dos processos organizacionais que os divide em „primários‟ e „de apoio‟, a qual foi refletida na organização das seções que lidam com o desenvolvimento de software e na constituição dos dois portfolios, um para cada tipo de processo.

Tal categorização afeta as etapas posteriores de gestão de portfolio e de gerenciamento de projetos, pois as informações a serem coletadas e os critérios de avaliação são peculiares. As equipes também são divididas de acordo com a categorização, ou seja, os próximos passos de cada componente do portfolio dependerão de pessoas distintas, especializadas em função

dos processos de negócio em relação aos quais suas equipes trabalhem, inclusive quando entrarem na camada de execução, ou seja, na camada de gerenciamento dos projetos, onde serão desenvolvidos.

A partir das informações obtidas junto ao demandante, o consultor se reúne com as outras áreas da TI para discutir tecnicamente sobre as soluções possíveis e, ao final, indicar a mais adequada ao caso. Do ponto de vista da TI, as soluções que envolvam o fornecimento de um software – seja integralmente novo ou a evolução de um software existente – podem se dar por meio da aquisição de ferramentas de terceiros, do desenvolvimento com recursos humanos internos ou do desenvolvimento externo, por meio de uma prestadora de serviço continuado de desenvolvimento de software, conhecida na organização pelo termo fábrica de software.

Em se tratando do fornecimento de um software, então, no contexto da organização estudada, o próximo passo no processo se refere à elaboração, pelo consultor, de um documento denominado Documento Indicativo de Solução Preliminar (DISP), que apresentará a solução recomendada a partir do entendimento da necessidade junto ao demandante e da análise técnica promovida pela TI. Trata-se de um documento onde é apresentada à área demandante uma visão consolidada da solução proposta, com informações relativas à forma de provimento – que pode ser aquisição, desenvolvimento interno ou externo – aos prazos, aos custos, aos riscos, ao consumo de recursos, etc.

Excetuada a opção pela aquisição de ferramentas de terceiros, as outras duas envolverão interfaces entre o processo de gestão de portfolio e o modelo de desenvolvimento ágil Scrum, visto que, hoje, na organização estudada, tanto o desenvolvimento interno quanto o desenvolvimento por meio da prestadora de serviço fazem uso de processos inspirados nos métodos ágeis, mais especificamente no Scrum.

Apenas a título de contextualização quanto ao caso, convém informar que quando da opção pela aquisição de ferramentas de terceiros, a proposta de projeto seguirá normalmente as etapas da gestão de portfolio e, se aprovada, comporá a lista de projetos em ordem de prioridade, de forma que seja executada apenas quando chegar sua vez. Isso se deve ao fato de que as pessoas envolvidas na especificação da solução são as mesmas utilizadas em etapas iniciais do desenvolvimento de projetos de software, ou seja, são recursos escassos e pelos quais as demandas, mesmo que atendidas por meio de aquisição, concorrem.

A diferença está no fato de que, em vez de a aquisição fazer parte de um projeto de desenvolvimento de software, será elaborado um projeto básico – um documento padronizado com os requisitos da aquisição/contratação – que seguirá para a área administrativa do

Tribunal, responsável pelas compras. Como nesse caso não há interface com uma camada de gerenciamento de projetos de desenvolvimento de software, nem tampouco de um processo que faça uso de métodos ágeis, essa forma de provimento encontra-se fora do escopo da presente pesquisa.

Os processos de gestão de portfolio da organização estudada existem desde agosto de 2011 e foram definidos a partir de pesquisas na literatura, onde tiveram como inspiração modelos variados, como Moore (2010), Cooper (1999), PMI (2008) e OGC (2011). Como anteriormente dito, apesar das peculiaridades de cada um, há pontos e objetivos comuns entre os vários modelos, sendo que a presente pesquisa adotou como referência, conforme anteriormente dito, o modelo do PMI (2008).

Ao traçar um paralelo entre as atividades do estudo de caso já apresentadas e o modelo do PMI, verificam-se algumas correspondências, como os encontros e a triagem de componentes com duração menor que 10 dias, que integram a „Identificação de componentes‟, e a separação entre processos primários e processos de apoio, de forma que cada projeto seja encaminhado ao portfolio apropriado, que integra a „Categorização de componentes‟.

De volta ao caso do fornecimento de um software na organização estudada, para elaborar uma proposta de solução, que se materializará no „Documento Indicativo de Solução Preliminar‟ (DISP), o consultor, a fim de definir, com o devido envolvimento das demais unidades de TI, pela melhor solução aplicável ao caso, reúne-se com pessoas das áreas técnicas para discussões, indicação de necessidades de informações e coleta de informações. Na organização estudada, esse serviço tem um acordo nível de serviço que prevê o prazo de no máximo 10 dias úteis entre o recebimento do formulário de solicitação, enviado pelo demandante ao consultor, e a conclusão do DISP.

As informações do Documento Indicativo de Solução Preliminar (DISP) completo darão à área demandante a possibilidade de compreender como a TI pode auxiliá-la e de decidir quanto à continuidade ou não da proposta do projeto. A proposta pode vir a ser descontinuada se o estudo demonstrar que a solução terá um custo maior do que os possíveis benefícios entregues ou que não poderá acontecer num tempo adequado (time-to-market). Já a continuidade pode se dar com aprovação integral, pela área demandante, da solução proposta, ou após ajustes e refinamentos por meio de negociações entre a área demandante e a unidade de TI.

Para a prossecução de uma proposta de solução que se refira a um projeto de software, as informações coletadas e que comporão o business case – composto pelo „Formulário para

proposição de projetos de software‟ e pelo „Documento indicativo da solução preliminar‟ – serão utilizadas em etapas posteriores da gestão de portfolio, como a categorização, a avaliação, a seleção e a priorização dos projetos, bem como nas etapas que ocorrerão dentro do processo de desenvolvimento, que, no caso da organização estudada, utiliza métodos ágeis. Com isso, então, verifica-se no caso prático o primeiro grupo de interfaces, denominadas „Interfaces relacionadas à identificação de novos componentes‟, cujos três primeiros pontos de interação se referem à coleta de informações junto à camada de gerenciamento de projetos, que, no caso estudado, faz uso de processos inspirados no modelo de desenvolvimento ágil de software Scrum. Os pontos de interação encontram-se listados a seguir:

 Informações sobre recursos requeridos por um novo componente;  Informações sobre prazos de um novo componente; e

 Informações sobre riscos associados a um novo componente.

A contextualização feita nos parágrafos supra teve como objetivo possibilitar o entendimento a respeito de como o processo acontece na organização estudada e, assim, identificar os pontos de interação no contexto dos processos utilizados pela organização em estudo. Adiante, serão apresentados maiores detalhes a respeito de como se dão as interações entre os processos de gestão de portfolio e o Scrum a partir das interfaces identificadas e abordadas nesse tópico.

Conforme vimos, os três pontos de interação apresentados são relacionados a informações que integram o DISP, que é produzido mediante o envolvimento de todas as áreas necessárias ao desenvolvimento de um projeto de software. A definição de uma proposta de solução se dá por meio de encontros promovidos pelo consultor com o demandante, para definição da necessidade, dos objetivos e da solução, e com as áreas técnicas, para análise de viabilidade, identificação de necessidades de recursos, prazos e riscos, entre outros.

A organização estudada predefiniu um roteiro padrão para orientar quem deve participar dos encontros, quais informações cada participante precisará e quais cada um deverá fornecer, mas o consultor tem a experiência e a visão necessárias para promover encontros adicionais ou envolver outros interessados não previstos no roteiro básico. Neste, é prevista a necessidade de envolvimento com a equipe que atua no desenvolvimento dos projetos de software.

Assim, para possibilitar o fornecimento das informações que trafegam nos pontos de interação apresentados – sobre estimativas de recursos, prazos e riscos de um novo componente – se mostra necessário o apoio da equipe que atua no desenvolvimento dos projetos de software, que é detentora de conhecimento e de experiência em relação ao negócio, à velocidade da equipe, aos aspectos tecnológicos envolvidos e aos acontecimentos passados.

Para que a equipe técnica possa ter uma compreensão geral do projeto, a organização adota atualmente o conceito de estórias de negócio, que são pequenas declarações feitas pelo demandante a respeito do que a solução deverá fazer. Um exemplo simplificado, extraído dos dados coletados, consta a seguir:

Processo de negócio: Peticionamento judicial Demandante: Presidência

1) Descrição da necessidade:

- Cenário: a Secretaria Judiciária (SEJ) é a atual responsável pela autuação dos

processos;

- Problema: a responsabilidade pela complementação das informações fica a cargo

da SEJ, o que resulta em desperdício de tempo e esforço, em má utilização dos recursos humanos, bem como em risco de erros em função da comunicação ser direta com o advogado;

- Objetivo: eliminar o desperdício de tempo e esforço, minimizar os riscos e

melhorar a utilização dos recursos;

2) Áreas potencialmente afetadas: Gabinetes, SEJ, Central do Cidadão.

3) Solução: Construir uma solução de software que permita a inserção de todas as

informações necessárias à autuação pelo advogado, de forma que a SEJ apenas valide as informações.

4) Estórias de negócio:

Permitir ao advogado, em tempo de peticionamento, a inserção de todas as informações necessárias para a autuação;

Oferecer um meio para que a SEJ confira as informações, valide ou exija correções na autuação.

Um projeto pode conter uma ou várias estórias de negócio. No exemplo acima, há duas estórias de negócio. Elas são escritas durante as reuniões entre o consultor e o demandante, e podem envolver outras partes interessadas, quando for o caso. É a partir da análise das estórias de negócio e do objetivo do projeto que as equipes técnicas idealizam as macro ações e conseguem ter uma visão do trabalho, tanto do todo quanto das partes que o compõem, o que possibilita a determinação das tarefas necessárias e, consequentemente, dos recursos, do prazo e dos riscos envolvidos.

Essas informações são levantadas em encontros entre o consultor e o gerente de projetos de desenvolvimento de software, que pode requisitar o apoio de outros integrantes, mas, no caso da organização estudada, normalmente detém conhecimentos razoáveis sobre o histórico dos projetos já desenvolvidos na organização e sobre a velocidade da equipe, por isso, é habilitado a apresentar estimativas iniciais quanto a recursos, prazos, e riscos envolvidos. Os encontros são agendados sob demanda e as informações repassadas ao processo de gestão de portfolio para uso em etapas posteriores.

O levantamento de informações para o primeiro ponto de interação, referente aos recursos humanos e de produção necessários a um projeto de software, no caso da organização em estudo, é simplificado pelo fato de que as soluções são construídas mediante a observação de uma arquitetura de referência, a qual define padrões tecnológicos para a construção dos sistemas, e também porque normalmente se referem a um conjunto de processos de negócio já conhecido. Já houve, no entanto, projetos que exigiram recursos que a organização não possuía.

A seguir, o relato de um chefe de unidade de desenvolvimento de software em que se indicou o provimento da solução por meio da aquisição de software de terceiros, tendo em vista a limitação de perfil percebida nos recursos internos e da fábrica de software:

Houve um caso em que a TV Justiça pediu o desenvolvimento de um software que deveria trabalhar com conversão de formatos de áudio. Nas nossas equipes, tanto internas como externas, não tínhamos ninguém com essa expertise, por isso, recomendamos a aquisição de uma solução de mercado, pois são soluções normalmente mais maduras e que sofrem constantes evoluções. Não seria plenamente possível entregar esse tipo de característica no nosso contexto e com os recursos que temos.

Em outras palavras, o fato de serem projetos de software construídos sob um mesmo padrão arquitetural dá certa estabilidade quanto aos recursos necessários, pois evita variações que causem a necessidade de serem alocados recursos especializados em tecnologias ou ferramentas diferentes das que a organização já possua ou conheça. Também no mesmo sentido aparece a estabilidade quanto ao tipo de negócio tratado, pois normalmente os projetos tratam de um mesmo conjunto de processos organizacionais.

Os prazos para desenvolvimento dos componentes são definidos com base na leitura e na interpretação das estórias de negócio, com a posterior indicação do esforço (em horas) necessário para a respectiva realização. Tais estórias serão, se o projeto for à execução, melhor detalhadas em momento oportuno, por meio da conversão em estórias de usuário. Os prazos fornecidos nesse primeiro momento são estimados e podem sofrer ajustes, mas,

segundo relato do gerente de uma das seções que lidam com o desenvolvimento de software, a experiência promove o que eles chamam de „calibragem‟, ou seja, o ajuste da medição.

A calibragem torna as estimativas razoavelmente assertivas, a ponto de possibilitar a tomada de decisões durante as etapas de gestão do portfolio e o monitoramento e controle do projeto em tempo de execução, mas sem despender trabalho excessivo e que possa significar grande desperdício no caso do projeto não ser aprovado. Esse ponto é evidência da inspiração