História do cliente | Processo preciso da NASA JPL para avaliação e seleção da ferramenta ESM

[0:05] Lynn: O Frank é um profissional de tecnologias da informação no Laboratório de Propulsão a Jato da NASA, onde se dedica à conceção de processos empresariais, programação web, conceção e desenvolvimento de bases de dados, programação SQL, engenharia de sistemas, recolha de requisitos e projetos de TI. A sua carreira começou há cerca de trinta anos como operador de computadores mainframe; a partir daí, progrediu para gestor de projetos técnicos, tendo criado bases de dados de empréstimos interbibliotecários. Alguns anos mais tarde, mudou-se para o JPL como responsável de tecnologias da informação. Antes que me desvie do assunto, vou passar o microfone ao Frank. Pode começar.

[0:51] Frank: Muito obrigado e sejam todos bem-vindos ao webinar. Estou muito entusiasmado por vos apresentar esta informação. Espero que a achem tão interessante quanto eu e vamos começar logo, está bem? A minha apresentação vai ser um resumo informal do processo que seguimos para procurar, encontrar e avaliar produtos de utilização, e vou apresentar-vos o processo tal como aconteceu quando o fizemos nós próprios.vou mostrar-vos como conduzi o estudo para a avaliação, na ordem em que o fiz, e vou mostrar-vos alguns dos documentos que criei como parte da elaboração do relatório final. Por isso, preciso de vos informar que o JPL tem uma política segundo a qual não endossamos produtos específicos e, como parte disso, quando estiver a apresentar informações sobre os fornecedores que avaliámos, não vou utilizar os nomes desses fornecedores. Então, vamosvamos falar sobre a agenda do webinar de hoje. Vou falar-vos sobre os objetivos que tínhamos quando iniciámos o estudo para encontrar um produto de utilização; vou falar-vos sobre os fornecedores que selecionámos e sobre o que aprendemos sobre esses fornecedores ao realizar o estudo; vou falar-vos sobre como fizemos a pontuação e como isso se relaciona com a forma como realizámos a avaliação efetiva dos fornecedores selecionados; eVou mostrar-vos como apresentámos os resultados das nossas pontuações, que incluirão o desempenho de cada um dos fornecedores; vou falar-vos sobre os resultados do estudo, incluindo em que ponto nos encontramos neste momento em todo o processo; e, no final, teremos algum tempo para perguntas. Preciso de vos informar que o processo de divulgação de informação do JPL é rigoroso e, por isso,terei de limitar as perguntas às questões relacionadas com o webinar que estamos a realizar neste momento. Assim, quando me referir aos produtos e aos fornecedores deste estudo que realizámos, quando falar de um fornecedor, estou a referir-me às empresas que fornecem soluções de utilização; e quando falar de um produto, estou a referir-me ao software que gerimos, mantemos e fornecemos aos nossos clientes — ou seja, os produtos que vocês gerem, mantêm e fornecem aos vossos clientesinterna, nós utilizamos esses termos de forma intercambiável; por isso, vou dar o meu melhor durante o seminário para me cingir a esses termos exatos e, se cometer algum erro, corrigir-me-ei.

[3:58] Muito bem, vamos começar com o cerne da apresentação. Vamos falar sobre os objetivos do estudo. O primeiro objetivo que tínhamos era aumentar a qualidade… desculpem, a quantidade dos nossos dados de utilização. Bem, descobrimos que, na nossa ferramenta interna que criámos para gerir a utilização, muitos dos produtos que temos geravam dados de registo e estávamos a utilizar esses dados para recolher os dados de utilização, geri-los e, posteriormente, apresentá-los na nossaferramenta interna para criar os nossos gráficos. No entanto, descobrimos que essa utilização dos dados de registo era realmente problemática: os registos por vezes falhavam quando os fornecedores não transferiam os dados do seu buffer para o registo. Verificámos que tínhamos de voltar atrás e reprocessar esses dados, o que criava problemas nos nossos relatórios de utilização, que tínhamos de corrigir regularmente. Por causa disso, as partes interessadas internas começaram a perder a confiança nos dados, porque, quandotínhamos de voltar atrás e reprocessá-los, achavam que a estabilidade do nosso sistema de recolha de dados não era tão sólida quanto poderia ser. Essa foi também uma das razões pelas quais realizámos este estudo: para determinar como poderíamos melhorar essa qualidade e reforçar essa confiança. Descobrimos que os dados não eram assim tão maus como as partes interessadas tinham percebido, mas essa perceção era, sem dúvida, algo que também precisávamos de gerir.

[5:36] Como parte deste processo, percebemos que queríamos aumentar a usabilidade da nossa ferramenta interna; queríamos torná-la mais orientada para uma arquitetura de serviços, em que os utilizadores dependessem menos de mim e dos meus colegas programadores para criar relatórios a partir dos dados de utilização do back-end, e pudessem aceder à ferramenta e obter esses relatórios por conta própria. Assim, como já dispúnhamos de umaque estava a funcionar para nós, no âmbito deste estudo, queríamos certificar-nos de que era essa a ferramenta que queríamos utilizar e continuar a utilizar. Quando criámos inicialmente a nossa ferramenta interna, não existia no mercado nenhuma ferramenta adequada que pudéssemos utilizar para obter os dados de utilização que pretendíamos e, por isso, criámos a nossa própria. A parte mais importante deste estudo consistiu, então, em elaborar o que designamos por «relatório de construir versus comprar», que consiste numa análise para determinar se a nossae os nossos recursos internos seriam a melhor solução ou se algo já existente e disponível no mercado seria mais adequado para satisfazer as necessidades do nosso estudo e as nossas necessidades internas.

[7:15] Muito bem, vamos fazer uma breve apresentação geral de tudo o que fizemos para realizar o estudo. Começámos, logo no início, por avaliar quais eram as nossas necessidades em termos de relatórios de utilização e definimos os nossos requisitos. O que é importante recordar é que não definimos os requisitos com base na nossa ferramenta interna atual, caso contrário, esta teria cumprido todos os requisitos; em vez disso, começámos do zero, do zero, e perguntámo-nos: «Se tivéssemos tudo o que queríamos, o que seria isso? O que é que estamos realmente à procura? Quais são as necessidades que nos faltam na nossa ferramenta atual e que precisamos de resolver para satisfazer as nossas necessidades de relatórios internos?» Depois, fui à Internet, pesquisei e fiquei surpreendido ao descobrir que, atualmente, existem bastantes fornecedores que oferecem relatórios de utilização. Assim, identificámos esses fornecedores, consultámos os seus sites, lemos toda a documentação online e ficámos com uma boa ideia sobre os fornecedores apenas a partir da sua presença pública. A partir daí, selecionámos alguns que considerámos candidatos para o tipo de relatórios que pretendíamos e enviámos-lhes pedidos de informação, incluindo os nossos requisitos. O importante nisso foi que, quando finalmente nos reunimos com cada um dos fornecedores e falámos com as suas equipas de vendas e técnicas, já lhes tínhamos enviado os nossos requisitos e já tínhamos realizado as reuniões iniciais. Foi ótimo porque estávamos realmente concentrados nas nossas questões específicas; conseguimos ir direto ao cerne das questões e dos requisitos individuais. Assim, as apresentações com cada um dos fornecedores consistiram num pedido para que respondessem a todos os conjuntos de requisitos e para que nos explicassem como cada um deles cumpria ou não esses conjuntos de requisitos.

[9:36] No que diz respeito aos fornecedores com os quais decidimos testar versões-piloto desses softwares, o nosso objetivo era não só ver as demonstrações que a equipa de vendas e a equipa técnica nos apresentavam, mas também verificar como esses produtos se comportavam com os nossos dados; isso também me permitiu gerar relatórios específicos em cada um dos produtos. Assim, como parte de todo esse processo, conseguimos avaliar cada um dos fornecedores com os nossos próprios dados e classificá-los nós próprios em função dos nossos requisitos e, por fim, a parte final do estudo consistiu na apresentação a todas as partes interessadas de todas estas avaliações e, posteriormente, dos resultados finais do nosso estudo «construir ou comprar».

[10:39] Como parte disto, também realizei o meu processo de engenharia de sistemas, o que incluiu a elaboração de documentos comuns de requisitos de engenharia de sistemas, tais como os documentos de requisitos, o documento de contexto e os resultados dos estudos; posteriormente, reuni tudo isto e entreguei-o num único relatório abrangente à minha gestão superior. Uma coisa que quero salientar é que considerámos extremamente valioso o facto de, aorecolher os nossos requisitos, conversar com todos os membros da equipa. Conversámos com a nossa direção, com o pessoal responsável pela gestão de licenças — aqueles que gerem as alterações aos ficheiros de licença e a prestação desses serviços —, com os nossos responsáveis de produto — que são as pessoas que apoiam especificamente os produtos individuais que fornecemos à nossa base de clientes — e, por fim, com os nossos responsáveis de área. Para nós, a área é o nosso grupo de partes interessadas, que inclui as equipas de gestão das nossas ferramentas mecânicas, os engenheiros mecânicos e as nossas ferramentas elétricas para os engenheiros elétricos e as nossas ferramentas de sistemas de software. Assim, reunimos toda a informação deles everão, tal como nós vimos, que todos procuravam um tipo de informação ligeiramente diferente. Um exemplo pode ser o facto de os gestores procurarem mais informações sobre a utilização ao longo do tempo: como é que as nossas licenças estavam a ser utilizadas? Temos licenças suficientes? Os responsáveis pelo apoio ao produto estavam mais interessados em saber como é que estas recusas estavam a ocorrer, quem as estava a receber e quais eram as causas dessas recusas. Isso determinou os nossos requisitos dentro da própria ferramenta. Por isso, recomendo que obtenham o vosso conjunto de requisitos de todos aqueles que têm interesse no que os relatórios de utilização lhes irão revelar.

[12:56] Assim, depois de termos recolhido os nossos requisitos, começámos a realizar os projetos-piloto. O estudo revelou que, no caso do produto que escolhemos, precisávamos de garantir que este suportasse um número significativo de produtos, o que está relacionado com o problema que estávamos a enfrentar: a nossaferramenta interna não suportava o software de entrega de licenças através dos registos, e queríamos que qualquer produto que escolhêssemos para substituir o nosso produto existente, caso fosse essa a nossa escolha, suportasse mais produtos. Aprendemos que, relativamente a qualquer um dos fornecedores que selecionássemos, teríamos de garantir que estes pudessem importar os dados de produtos nãonão suportados, e a importância disso reside no facto de querermos garantir que, para qualquer um dos produtos que estávamos a fornecer à nossa base de clientes, tivéssemos uma forma de introduzir dados de utilização na ferramenta do fornecedor; não podíamos afirmar que, para um produto específico que estávamos a fornecer, não houvesse forma de introduzir dados de utilização no produto do fornecedor, a menos que o produto que estávamos a fornecer não gerasse registos.

[14:32] Percebemos que precisávamos de muitos relatórios personalizados, o que se reflete no facto de termos tantas partes interessadas a analisar os dados de tantas formas diferentes; precisávamos de garantir que a ferramenta fosse suficientemente robusta para satisfazer todas as necessidades das nossas partes interessadas. Percebemos que as nossas partes interessadasnão queriam ter de aceder sempre à ferramenta para iniciar sessão e gerar um relatório; queriam que os dados lhes fossem enviados. Por isso, queríamos que, ao chegarem de manhã, recebessem o seu relatório agendado por e-mail — podendo ser um relatório diário; alguns deles preferem relatórios semanais —, pelo que essa foi uma das nossas necessidades mais importantes.

[15:24] Também queríamos garantir que os relatórios gerados pela ferramenta do fornecedor incluíssem as nossas informações de recursos humanos, e o que era importante nisso é que descobrimos que os relatórios que pretendíamos gerar envolviam analisar os dados do ponto de vista de, por exemplo, quais os grupos nos nossos recursos humanos e na nossa estrutura departamental, como é que estão a utilizar as ferramentas especificamente, e os dados de utilização, tal como são fornecidos em bruto,não incluem essa informação; por isso, precisamos de garantir que a ferramenta do fornecedor integrasse essa informação, para que possamos, posteriormente, produzir consultas e relatórios do ponto de vista institucional.

[16:13] Queremos garantir que temos relatórios de recusas realmente bons e que esses relatórios sejam direcionados, de modo que, como sabem, ao analisar as recusas, dependendo do produto e da forma como este regista as recusas, por vezes um produto pode registar recusas antes de avançar para a emissão de uma licença. Queremos garantir que os relatórios de recusas no produto do fornecedor consigam lidar com os diferentes tipos de recusas que ocorrem, e uma das nossas partes interessadas estava realmente interessada em obter informações em tempo realem tempo real sobre o que está a acontecer neste momento no sistema — quem está ligado neste momento — e, em seguida, cruzar essa informação com os dados de RH para saber a que grupo ou secção pertencem.

[17:18] Muito bem, nesta fase do estudo já reunimos os nossos requisitos, já falámos com os fornecedores, já selecionámos os fornecedores para os projetos-piloto e já temos os nossos próprios dados no sistema;revelou um conjunto inicial de informações sobre o que vamos precisar numa ferramenta de utilização e, por isso, quero falar-vos rapidamente sobre algumas das coisas que aprendemos sobre os fornecedores que estavam a realizar os projetos-piloto. O fornecedor A tinha uma interface muito simples e moderna; por isso, não vou abordar cada um destes aspetos, mas o que é importante é que tinham uma interface simples e moderna. Este produto não nos permitiu realizar um projeto-piloto no local, mas tinham umaconcebida, onde havia muitos dados sobre os quais podíamos gerar relatórios. O que aprendemos sobre o fornecedor A e que foi importante para nós é o último ponto: a apresentação dos dados era feita do ponto de vista do servidor e o que era importante nisso é que, para os nossos sistemas de tríade, não era possível gerar um relatório a partir das três tríades simultaneamente, pelo que havia um limite nessa perspetiva de relatório. Este fornecedor também tinha um problema com a capacidade de filtrar as suas recusas.

[18:58] E isso foi problemático. O nosso fornecedor B… eis o que aprendemos e o que era importante em relação a ele; assim, o produto do fornecedor Bera muito simples e limpo; não tinha muito JavaScript; as imagens que produzia eram muito simples, mas oferecia tudo o que precisávamos — estava tudo lá — e, em comparação com o fornecedor A, tinha a capacidade de filtrar as recusas, o que nos permitia limitar os relatórios; no entanto, o que era interessante no fornecedor B era que, precisamente por ser tão simples, isso levou-nos a ter de avaliar se o fornecedor B seria ou não capaz de cumprir o requisito do estudo de poder aumentar a quantidade dos nossos relatórios.

[20:01] Eis o que aprendemos sobre o fornecedor C: tinham uma interface de utilizador muito bem concebida. O que foi realmente importante para nós em relação ao fornecedor C foram os dados LDAP armazenados localmente. O que se destacava nisso era que isso libertava alguns dos recursos do nosso sistema LDAP institucional, pelo que o fornecedorestava constantemente a aceder ao nosso sistema LDAP para recolher informações; além disso, o fornecedor também armazenava essas informações de RH e as suas alterações ao longo do tempo, de modo que, se o número de pessoas, por exemplo, num grupo mudasse, essa informação também mudava, o que é importante para podermos ver como as tendências das informações do grupo também se alteram. O fornecedor C também suportava um grande número de servidores de licenças em comparação com os outros fornecedores; suportava 25 fornecedores de licenças diferentes e, além disso, o fornecedor C tinha uma funcionalidade que também tínhamos na nossaferramenta interna e de que também gostávamos: a criação de «pseudo-fornecedores». O que queremos dizer com isto é que, para quem trabalha com gestão de licenças, sabe que alguns fornecedores de produtos enviam um ficheiro de licença e agrupam os seus produtos num único ficheiro de licença; é necessário poder extrair esses dados e apresentar essa utilização como produtos separados que se fornecem à base de clientes. O fornecedor C tinha a capacidade de fazer isso, pelo que apreciámos essa funcionalidade.

[21:46] Então, avaliámos os nossos fornecedores, que têm vindo a recolher os nossos dados, e quando sentimos que estávamos numa fase em que podíamos comparar de forma competente as capacidades dos fornecedores com as nossas necessidades e requisitos, procedemos a um processo de pontuação e eiseis como decorreu o processo: a primeira coisa que fizemos foi atribuir um peso a cada um dos requisitos, com a escala a ir até 10. Optei por utilizar uma escala de 2 a 10 em vez de uma de 1 a 5, e fiz isso pessoalmente porque queria garantir que, quando os requisitos de nível 8 e nível 10 fossem cumpridos, isso conferisse um peso maior na escala a esses elementos importantes; e que os requisitos de menor importância — os de nível 2 e osquatro, caso não fossem cumpridos, fizessem a pontuação descer. Acho que esse foi o meu primeiro objetivo; o meu segundo objetivo era que isso produzisse, no final, uma pontuação final mais significativa para a minha direção e para as partes interessadas. Para cada um desses requisitos ponderados, avaliámos os fornecedores e atribuímos-lhes uma pontuação para cada um deles. Em seguida, multiplicámos essa pontuação pelo peso atribuído, e essa foi a classificação final de cada fornecedor para cada um desses requisitos.

[23:41] Eis um exemplo: o que estamos a analisar aqui é um dos artefactos que elaborei como parte do meu relatório global. Trata-se do requisito n.º 36 — TUR significa «relatório de utilização de ferramentas» — e, neste requisito, estamos a falar da capacidade do produto desse fornecedor de gerar um relatório personalizado. A nossa ferramenta interna cumpria esse requisito, e isso deveu-se ao facto de, uma vez que eu próprio concebi o sistema desde o início-end e as tabelas da base de dados, sabia como escrever as minhas próprias instruções SQL para o meu sistema, pelo que cumpra esse requisito. O fornecedor A afirmou que não cumpria esse requisito, mas, na verdade, atribuí-lhe uma pontuação mais elevada porque, durante a avaliação, descobri que dispunha de uma interface gráfica web para criar instruções SQL que podiam depois ser inseridas no sistema; por isso, atribuí-lhe uma pontuação mais elevada. Fiz o mesmo com o fornecedor B, atribuindo-lhe uma pontuação que indicava que cumpria parcialmente o requisito, porque consegui aceder à suae analisei o esquema da base de dados, e verifiquei que não era demasiado complicado. Senti que seríamos capazes de aprender a estrutura das tabelas da base de dados e, posteriormente, escrever as nossas próprias instruções SQL com base nos dados brutos diretos. O fornecedor C também cumpriu esse requisito e dispunha de um sistema robusto de relatórios pré-construídos no sistema. Olhando para trás, provavelmente deveria ter atribuído ao fornecedor C uma pontuação superior ao requisito, mas acabaram por ficar com 12 pontos; mas tudo bem.

[25:44] Aqui está um exemplo de outro relatório que elaborei; esta é a minha representação visual da pontuação, e fi-lo para que pudessem ter uma visão geral rápida e fácil da pontuação de cada um dos fornecedores. Reparem que estes são pesos de dez; reparem que estou a mostrar apenas o resumo, não o requisito propriamente dito — na prática, não se escreveria um requisito nessa linguagem —, mas podem ver que os fornecedores A e B não cumpriram alguns desses requisitos e, apesar de estarem na nossa lista de requisitos obrigatórios, as partes interessadas vão, na mesma, analisar isso e perguntar-se se esses são requisitos de que poderão prescindir, caso optemos por essa ferramenta.

[26:36] Então, aqui está uma escala com os resultados para todos os nossos requisitos com ponderação 10 — estes são os nossos requisitos obrigatórios, tínhamos 15 deles — e sinto que, entre os requisitos com ponderação 10, havia um conjunto de requisitos que se esperaria que todos os fornecedores do setor fossem capazes de cumprir; por exemplo, havia um requisito que dizia «ser capaz de produzir um relatório de horas extraordinárias de utilização» e, do ponto de vista da recolha de requisitos,é um requisito importante a ter; mas, por causa disso, significa que todos os fornecedores vão obter uma pontuação um pouco mais elevada nos requisitos com ponderação 10; no entanto, reparam que o fornecedor A não obteve uma pontuação tão elevada como eu esperava nestes requisitos com ponderação 10 e, olhando para o fornecedor A, acredito que isso se deveu ao facto de terem apresentado os seus dados do ponto de vista do servidor, o que nosnão conseguimos obter todos os outros relatórios para o conjunto dos nossos sistemas Triad. Por exemplo, a nossa ferramenta interna obteve uma pontuação muito elevada, e isso deveu-se ao facto de a termos desenvolvido nós próprios; por isso, obviamente que estávamos a satisfazer todas as nossas necessidades importantes, uma vez que os nossos requisitos com ponderação 8 — estes são os requisitos que eram altamente importantes, eram 14 no total —é interessante notar que, nesta fase, o fornecedor A ficou significativamente para trás na sua capacidade de cumprir esses requisitos; estes eram os que iam além do básico — são os requisitos em que começamos realmente a adicionar usabilidade e a satisfazer as necessidades da nossa instituição para além do básico; são estes os requisitos em que começamos a ver onde é que estão a satisfazer as nossas necessidades empresariais. É possível ver que, mesmo nestas áreas, a nossanão cumpria todos esses requisitos, e o que isso representa está exatamente no nosso relatório «construir versus comprar»; nessa parte do estudo, isso representa a área em que teremos de investir na nossa própria ferramenta para, então, cumprir esses requisitos. Aqui podem ver que o fornecedor C se saiu extremamente bem e até obteve uma pontuação superior à da nossa ferramenta interna.

[29:15] Aqui estão os resultados dos requisitos com ponderação 6 e, nesta área, o fornecedor B também ficou bastante para trás, e a nossa ferramenta interna também não teve um bom desempenho; há uma grande área aqui em que devemos optar pela solução de desenvolvimento interno, o que irá representar uma parte significativa do nosso investimento interno. No que diz respeito aos requisitos com ponderação 4, o fornecedor B ficou novamente para trás; o fornecedor C teve um desempenho melhor do que a nossa ferramenta interna. Existem sete destes requisitos com ponderação 4, que são requisitos de certa importância, e havia apenas dois requisitos classificados com ponderação 2, pelo que não incluí esse gráfico. Mas eis a pontuação final: podem ver que o fornecedor C obteve aqui uma pontuação mais elevada do que a nossaferramenta interna. Podem ver aqui que nenhum dos fornecedores nem a nossa ferramenta interna cumpriu todos os nossos requisitos; por isso, há uma área em que as partes interessadas terão de avaliar quais são os requisitos em falta e determinar o impacto desses requisitos em falta nos nossos processos internos. O que este gráfico de pontuação final vos mostrou é que vai realmente haver uma decisão a tomar entre a nossa ferramenta interna e o fornecedor C.

[31:11] Então, aqui está um mapa de calor de todos os requisitos, e o que isto vos mostra é uma análise muito rápida e de fácil leitura do desempenho de cada um dos fornecedores e da nossa ferramenta interna. Uma coisa que achei interessante foi que criei a categoria «excede os requisitos» enão tinha tantos como esperava. Espero que haja mais casos de «exceder os requisitos» e, claro, depois temos o verde para «cumpriu os requisitos», o amarelo para «cumpriu parcialmente os requisitos» e o vermelho para «não cumpriu os requisitos». Acho que o que também é importante neste gráfico é que se pode observar que, nos requisitos de nível 4, há aquele grande bloco vermelho tanto no fornecedor B como no fornecedor C, mas também na nossaprópria, onde não cumprimos os requisitos exigidos; o fornecedor A do setor cumpriu alguns deles, mas essa é uma área em que precisamos de voltar atrás, analisar esses requisitos e perguntar-nos: serão estas realmente as questões que devemos colocar, uma vez que estamos a constatar que as ferramentas do setor não estão a responder a essas questões?

[32:39] Muito bem, então avaliámos os produtos, atribuímos-lhes pontuações e agora é altura de realizar a parte final do estudo «construir versus comprar», que consiste em comparar os resultados da pontuação com o custo do investimento. Eis o resultado: a linha do gráfico de compra está em relação a si própria; eunão queria que pudessem olhar para a pontuação e, a partir daí, determinar qualquer custo; por isso, o custo está oculto — é relativo à escala —, mas é representado com precisão. Ao olharem para isto, podem ter uma noção real de qual seria o investimento para cada uma das ferramentas e o custo da nossarepresenta o custo que esperávamos investir internamente para satisfazer os requisitos. Gostaria também de vos informar que o custo aqui apresentado não inclui os custos de mão-de-obra de manutenção, porque esperávamos que esses fossem custos fixos e que fossem iguais para todas as ferramentas.

[34:13] Muito bem, então, a conclusão do estudo foi que determinámos que o fornecedor C, como podem ver no gráfico anterior, oferecia mais funcionalidades por dólar investido nessa área; determinámos que o fornecedor C iria proporcionar um melhor retorno do investimento para o nosso dinheiro do que até mesmo a nossaaprendemos que o fornecedor C possuía capacidades que nem sequer estavam previstas no nosso conjunto inicial de requisitos e, mais uma vez, o resultado final foi que não conseguimos justificar a diferença de custo entre investir e reconstruir a nossa ferramenta interna, em comparação com o que obteríamos ao efetuar a compra; assim, a decisão entre «construir» ou «comprar» foi a de comprar e adquirimos o produto do fornecedor C.

[35:17] Então, em que ponto estamos neste momento? Acabámos de concluir a primeira fase de implementação do fornecedor, o que incluiu a instalação de todas as nossas licenças compatíveis com o produto do fornecedor — o que, surpreendentemente, representou um número significativo das ferramentas que disponibilizamos à nossa base de clientes. Enquanto recolhemos os nossos dados neste momento, estamos a utilizar a nossa ferramenta interna e o fornecedor C em paralelo e, com o tempo, iremos retirar gradualmente a nossaà medida que continuamos a formar as partes interessadas internas sobre como utilizar a ferramenta e como encontrar e compreender os relatórios. Estamos também, neste momento, a passar pelo processo de geração dos relatórios personalizados que as nossas partes interessadas irão querer.

[36:29] O processo que seguimos aqui não foi inventado por mim; trata-se de uma prática padrão de engenharia de software. É possível encontrar uma referência a este processo neste livro, queé abordado especificamente no capítulo 22. Por isso, recomendo que se aprofundem no processo de avaliação de fornecedores no que diz respeito aos requisitos de software. Foi extremamente útil conhecer e utilizar um padrão da indústria para realizar a avaliação; aumentou a minha confiança na execução desta avaliação e saber que o relatório que estava a elaborar para a minha direção fazia parte das melhores práticas da indústria. Quero agradecer a todos por terem vindo hoje e por terem ouvido, e espero que tenham achado interessante. Espero que se sintam inspirados a experimentar este tipo de processo vocês próprios.