Frederico António de Sousa Carvalho
Gestão do Produto de Software na região de
Braga: Análise e Avaliação
Dissertação de Mestrado
Mestrado em Engenharia de Informática
Trabalho efetuado sob a orientação do
A
GRADECIMENTOS
Esta dissertação não seria exequível, sem a interação de todos aqueles que de forma direta ou indireta a possibilitaram, motivando e apoiando o seu desenvolvimento.
Ao meu orientador, Professor Doutor João Miguel Fernandes, pela indicação de um tema, que visa dar importantes conhecimentos que dificilmente são abordados durante todo o curso, bem como por todo o apoio e aconselhamento dado ao longo do desenvolvimento desta.
À minha família, com especial carinho aos meus pais Joaquina e António e irmão Gonçalo, por possibilitarem e incentivarem o meu percurso académico, de forma a ir sempre mais além.
Aos meus amigos e colegas, que de uma forma ou de outra, sempre me incentivaram ou inspiraram a trabalhar mais e melhor pelos meus objetivos, não só profissionais, mas também pessoais.
Por último e não menos importante, a todos os que participaram neste estudo, abrindo espaço nas suas agendas por vezes preenchidas, constituindo a base para esta dissertação.
R
ESUMO
A Gestão do Produto de Software é um dos principais mecanismos a usar durante o desenvolvimento e a exploração de um produto de software. A forma como o produto é gerido durante o seu ciclo de vida, toma em conta várias áreas de negócio, que, infelizmente, nem sempre fazem parte da experiência do gestor de produto, devido também ao facto de ainda existir pouca formação para o exercício deste cargo.
Como forma de avaliar as práticas de Gestão do Produto de Software na região de Braga, é apresentada a Matriz de Maturidade para a Gestão do Produto de Software, como instrumento de avaliação das práticas implementadas pelas empresas. Uma análise individual e coletiva das empresas é realizada, com a finalidade de analisar a maturidade das empresas em cada uma das áreas de foco da Matriz.
Para tal, foram realizadas 13 entrevistas junto de colaboradores de empresas do ramo de software, que permitiram recolher dados essenciais na construção das matrizes de maturidade de cada uma destas empresas. A partir dos resultados obtidos destas matrizes, uma análise mais geral foi realizada, identificando pontos comuns de falha, bem como de áreas de foco nas quais as empresas direcionam mais os seus esforços. Foi possível concluir que apesar de existir uma grande diversidade de resultados dentro de cada uma das Áreas de Foco, bem como o facto de que por vezes o nível de maturidade atingido, não está diretamente relacionado com o número de competências implementadas em cada uma desta Áreas. Também se constatou que o uso de ferramentas e metodologias adotadas por estas empresas, facilitam a Gestão do Produto, o que se traduz no aumento do nível de maturidade para as empresas em determinadas áreas de negócio.
Palavras-Chave: Gestão do Produto de Software, Matriz de Maturidade, Análise e Avaliação, Área de Foco, Área de Negócio
A
BSTRACT
Software product management is one of the core mechanisms to use on the development and exploration of a software product. The way a product is managed during its lifecycle takes into account several business functions, which unfortunately not always are part of the product manager’s professional experience. This is due as well to the fact that there is little education and training for this role.
As a way of evaluating software product management practices in the Braga region, the software product management maturity matrix is presented, as an instrument to evaluate these practices implemented by the companies. An individual and collective analysis is performed, with the intent to analyse the maturity of each one of the company’s focus areas.
To do so, thirteen interviews were conducted together with employees of the software companies, which allowed to collect essential data to construct their maturity matrixes. With the collected results from these matrixes, a broader analysis was performed, identifying common points of failure, as well as focus areas that companies direct their efforts towards. It was possible to conclude that although there is a big diversity of results within each focus area and they reach maturity most of the times, they’re not directly connected to the amount of implemented capabilities in these areas. It was also found that the use of software platforms as well as methodologies adopted by the companies, facilitate the product management, which resulted in a maturity level increase in certain business functions.
Keyword: Software Product Management, Maturity Matrix, Analysis and Evaluation, Focus Area, Business Functions
G
LOSSÁRIO
Backlog: Terminologia utilizada em desenvolvimento ágil, que representa uma lista de funcionalidades
necessárias para terminar uma determinada Release.
Business Case: Documento estruturado que transmite a ideia de negócio, abrangendo todos os
requisitos deste, bem como os recursos essenciais à iniciação do negócio.
Cluster: Concentração de empresas do mesmo setor que possuem características semelhantes e com
localizações próximas.
Linha de Produto: Conjunto de sistemas intensivos de Software, que partilham um conjunto de
funcionalidades comuns, que satisfazem as necessidades de um segmento de mercado em particular ou missão, e que são desenvolvidas de uma base comum de ativos de forma prescrita. (Clements & Northrop, 2002)
Make or Buy Decision: Processo de decisão entre construir um produto internamente na própria
empresa, ou comprá-lo a um fornecedor externo.
Marketplace: Espaço onde um produto ou serviço é fornecido a outras entidades, geralmente
associado a um custo, onde as transações são processadas através da entidade que gere o Marketplace.
Outsourcing: Método de trabalho utilizado por empresas quando recorrem a outras entidades
exteriores à organização, geralmente especialistas na área, para realizar trabalho de forma mais eficiente.
Product Owner: Papel responsável por no ciclo de vida do produto zelar pelo sucesso do produto,
entender as necessidades do utilizador/cliente e do negócio, ser o proprietário do produto, responsabilizando-se por ele, tomando todas as decisões necessárias.
Project Manager: Papel responsável pela conceção do projeto, na vertente do seu planeamento e
execução.
Release: Processo de colocar no cliente um incremento de funcionalidades no Software.
Roadmap: Planeamento/mapa estratégico que visa organizar as metas de desenvolvimento de um
Software. Neste planeamento são contempladas datas, lançamento de versões, estratégias, etc. (Roadmap, 2016)
Sprint: Representa um ciclo de trabalho na metodologia Scrum. Esse ciclo pode ser de 2,3 ou 4 semanas. Num projeto as várias Sprints têm sempre a mesma duração. (Campos, 2011)
Stakeholder: Parte interessada ou interveniente com interesse em determinado projeto ou negócio.
Estes podem ser internos quando fazem parte da organização da própria empresa, ou externos quando não fazem.
Win or Loss: Processo que tem como objetivo analisar o ganho ou perda de um negócio/cliente ou
Í
NDICE Agradecimentos ... iii Resumo... v Abstract... vii Glossário ... viii Lista de Figuras ... xvLista de Tabelas ... xvii
Lista de Abreviaturas, Siglas e Acrónimos ... xix
1. Introdução ... 21 1.1 Motivação ... 21 1.2 Âmbito da Dissertação... 23 1.3 Gestão de Produto ... 24 1.4 Desafio e Objetivos ... 26 1.5 Metodologia de Investigação ... 27 1.6 Estrutura do documento ... 28 2. SPM Competence Model ... 29 2.1 Planeamento do Produto ... 30 2.1.1 Product Roadmapping ... 31
2.1.2 Core Asset Roadmapping ... 31
2.1.3 Roadmap Intelligence ... 31
2.2 Gestão do Portefólio ... 32
2.2.1 Product Lifecycle Management ... 32
2.2.2 Partnering & Contracting ... 32
2.2.3 Market Analysis ... 33
3. Matriz de Maturidade ... 35
3.1 Product Roadmapping ... 37
3.2 Core Asset Roadmapping ... 37
3.3 Roadmap Intelligence ... 37
3.4 Product Lifecycle Management ... 38
3.6 Market Analysis ... 39
4. Entrevistas ... 41
4.1 Product Roadmapping ... 42
4.2 Core Asset Roadmapping ... 43
4.3 Roadmap Intelligence ... 44
4.4 Product Lifecycle Management ... 45
4.5 Partnering & Contracting ... 46
4.6 Market Analysis ... 46 5. Entrevistas ... 49 5.1 Empresa A ... 49 5.2 Empresa B ... 56 5.3 Empresa C ... 63 5.4 Empresa D ... 69 5.5 Empresa E ... 76 5.6 Empresa F ... 82 5.7 Empresa G ... 89 5.8 Empresa H ... 95 5.9 Empresa I ... 102 5.10 Empresa J ... 108 5.11 Empresa K ... 114 5.12 Empresa L ... 121 5.13 Empresa M ... 128 6. Análise de Resultados ... 135 6.1 Product Roadmapping ... 135
6.2 Core Asset Roadmapping ... 137
6.3 Roadmap Intelligence ... 139
6.4 Product Lifecycle Management ... 140
6.5 Partnering & Contracting ... 142
6.6 Marketing Analysis ... 144
6.7 Considerações Finais ... 145
7.1 Conclusões ... 151 7.2 Trabalho Futuro ... 152 8. Bibliografia ... 155
L
ISTA DE
F
IGURAS
Figura 1 - Ciclo de vida do produto de Software ... 25
Figura 2 - Definição de Produto (Quora, 2015) ... 26
Figura 3 - Software Product Management Competence Model ... 29
Figura 4 - Tabela de posicionamento das competências ... 36
Figura 5 - Gráfico de Implementação de Competências de Product Roadmapping ... 137
Figura 6 - Gráfico de Maturidade Geral da empresa para Product Roadmapping ... 137
Figura 7 - Gráfico de Implementação de Competências de Core Asset Roadmapping ... 138
Figura 8 - Gráfico de Maturidade Geral da empresa para Core Asset Roadmapping ... 139
Figura 9 - Gráfico de Implementação de Competências de Roadmap Intelligence ... 140
Figura 10 - Gráfico de Maturidade Geral da empresa para Roadmap Intelligence ... 140
Figura 11 - Gráfico de Implementação de Competências de Product Lifecycle Management ... 141
Figura 12 - Gráfico de Maturidade Geral da empresa para Product Lifecycle Management ... 142
Figura 13 - Tabela de Implementação de Competências de Partnering & Contracting ... 143
Figura 14 - Gráfico de Maturidade Geral da empresa para Partnering & Contracting... 143
Figura 15 - Gráfico de Implementação de Competências de Marketing Analysis ... 145
Figura 16 - Gráfico de Maturidade Geral da empresa para Market Analysis ... 145
Figura 17 - Todas as Competências implementadas vs. Nenhuma Competência Implementada para cada Área de Foco ... 146
Figura 18 - Implementação da Área de Core Asset Roadmapping na empresa A ... 148
L
ISTA DE
T
ABELAS
Tabela 1 - Taxa de sucesso dos projetos de software ... 22
Tabela 2 - Mapeamento de Competências e Questões para Product Roadmap... 42
Tabela 3 - Mapeamento de Competências e Questões para Core Asset Roadmapping... 43
Tabela 4 - Mapeamento de Competências e Questões para Roadmap Intelligence ... 44
Tabela 5 - Mapeamento de Competências e Questões para Product Lifecycle Management ... 45
Tabela 6 - Mapeamento de Competências e Questões para Partnering & Contracting ... 46
L
ISTA DE
A
BREVIATURAS
,
S
IGLAS E
A
CRÓNIMOS
CEO Chief Executive Officer (Diretor Geral Executivo)
CTO Chief Technology Ofiicer (Diretor Geral de Tecnologia)
IT Information Technology (Tecnologia de Informação)
KPI Key Performance Indicator (Indicador-chave de desempenho)
NDA Non-Disclosure Agreement (Acordo de Confidencialidade)
R&D Research and Development (Investigação e Desenvolvimento)
SLA Service Level Agreement (Acordo a nível de Serviços)
1. I
NTRODUÇÃO
A cidade de Braga, distinguida como Capital Europeia da Juventude em 2012, é uma cidade inovadora, jovem, criativa e tecnologicamente qualificada. No panorama tecnológico, existem também menções, caracterizando Braga como sendo o “Silicon Valley português”. Esta caracterização, advém também, da forte componente tecnológica que o tecido empresarial Bracarense possui. O mote adotado ‘De Braga para o Mundo’, nunca fez tanto sentido como atualmente, uma vez que se verificam várias marcas e empresas de nome mundial a usarem produtos e soluções desenvolvidas por empresas desta região. Desde cedo e devido à forte interação com a Universidade do Minho, que empresas se começam a fixar em Braga, consolidando o seu trabalho na área da tecnologia. Mesmo apesar de Braga não possuir as condições que alguns críticos consideram as mais importantes para iniciar um negócio neste sector de atividade, estas empresas lutam por um nome no mercado global de Software.
O desenvolvimento de um produto de Software vai muito para além da codificação da solução final. Existe um processo por trás deste desenvolvimento que deve ser seguido. Este processo tem de ser estruturado e metódico, abrangendo várias áreas de negócio. Todas estas temáticas, são por vezes distintas, mas ainda assim completam-se formando o processo de Gestão do Produto de Software. É necessário dominar várias áreas de conhecimento para se ter um produto bem-sucedido. Fatores como o posicionamento de mercado, o acompanhamento da evolução do produto ou da concorrência são fatores que a longo prazo podem fazer a diferença na sobrevivência de um produto no mercado. Para fomentar e perpetuar o sucesso de um produto, atualmente existem várias métricas que permitem avaliar o processo de Gestão do Produto de Software que cada empresa ou organização segue. Estas ferramentas são extremamente úteis e que permitem às organizações corrigirem e melhorarem o seu próprio processo. Este estudo será focado no uso de uma delas, que será a Matriz de Maturidade da Gestão do Produto de Software.
1.1 Motivação
Quando confrontados com valores como o de que 70% das empresas dizem ter pelo menos um projeto que falhou no ano de 2010, verificamos que algo ocorre consistentemente mal na gestão desses processos. Isto ocorre sistematicamente não só dentro de uma organização, mas de um grande
intimamente relacionada com a Gestão do Produto, uma vez que quando uma destas componentes falha, a outra está automaticamente comprometida. A Gestão do Produto visa a recolha de requisitos, a definição o âmbito do Produto, planeamento do Produto, bem como ocupar-se de uma visão estratégica sobre esse mesmo produto e os seus recursos. A Gestão do Projeto ocupa-se de uma visão mais técnica do produto, tratando da execução deste após a definição do Produto.
No que diz respeito ao sucesso dos projetos, os dados relativos ao Relatório do CHAOS com dados que abrangem o ano de 2011 até 2015, são reveladas taxas de sucesso indicadas na Tabela 1 - Taxa de sucesso dos projetos de software. (Johnson, Crear, Poort, & Mudler, 2015)
Tabela 1 - Taxa de sucesso dos projetos de software
2011 2012 2013 2014 2015
SUCCESSFUL 29% 27% 31% 28% 29%
CHALLENGED 49% 56% 50% 55% 52%
FAILED 22% 17% 19% 17% 19%
Os projetos designados como Successful (bem-sucedidos) são projetos que são entregues a tempo e horas, dentro do orçamento previsto e com as funcionalidades que foram requeridas.
Projetos Challenged (cuja palavra que mais se adequa em português será “Arrastados”) são projetos entregues com atraso, custos acima do que foi orçamentado e/ou com menos funcionalidades do que aquelas que foram requeridas.
Por sua vez, projetos Failed são projetos que cancelados antes de serem concluídos, ou os quais foram entregues e nunca usados.
A partir dos dados apresentados é possível verificar que o sucesso dos projetos fica muito aquém do desejável. Mesmo com o passar do tempo, os números mantêm-se em linha com os dos anos anteriores, não sendo denotadas melhorias. A procura de valor para um produto encontra-se num projeto considerado bem-sucedido, uma vez que todos os outros resultam numa perda de valor para o cliente final ou para a própria empresa, seja esta perda em tempo, custo ou oportunidade. Para sustentar o que foi anteriormente referido, estudos mostram que em média, projetos grandes na área de IT vão 45% acima do orçamento previsto, 7% ultrapassam o tempo estimado de entrega, bem como entregam menos 57% do valor previsto. (Bloch, Blumberg, & Laartz, 2012)
A Gestão de Produto minimiza significativamente o risco de falha, servindo como modelo para a organização na gestão do próprio produto. No entanto, para minimização desse risco, os processos
inerentes à Gestão do Produto deverão ser bem implementados, processos estes que abrangem não só a Gestão do Produto em si, mas também outros departamentos tais como Marketing e Vendas. Muitas das vezes a maturidade destes processos não é elevada, ou nem sequer implementada.
1.2 Âmbito da Dissertação
O cluster de Braga é caracterizado por ter algumas das empresas de Software mais conhecidas do país. Algumas destas empresas possuem uma vasta experiência no desenvolvimento de produtos de Software, experiência esta resultante de vários anos de atuação no mercado das TIC. Além da experiência, estas empresas cada vez crescem mais, estando o seu portefólio de produtos a acompanhar o seu crescimento, através da criação de novos produtos ou de linhas de produto diversificadas para os produtos já existentes.
A preocupação em implementar uma Gestão do Produto adequada, não só às necessidades do mercado, mas também aos recursos que a empresa dispõe torna-se essencial. Muitas das vezes o crescimento desproporcionado das empresas no seu número de solicitações, para fornecimento de produtos ou serviços, faz com que nem todas as boas práticas na Gestão do Produto sejam implementadas. O Time to Market é de facto fundamental para o desenvolvimento da empresa, mas também uma Gestão de Produto sólida e racional também o é. No entanto, a pergunta que se coloca, é: como gerem as empresas esses produtos com a pressão do Time to Market, e farão estas essa gestão de forma adequada.
Para responder a este tópico, esta dissertação propõe-se abordar as práticas de Gestão do Produto em algumas das empresas no setor das TIC na região, tendo como base a Matriz de Maturidade desenvolvida no Departamento de Informação e Ciências da Computação da Universidade de Utrecht, na Holanda. Ao serem classificados os níveis de maturidade para cada uma das áreas, estas empresas conseguirão ter uma visão geral de como está o seu estado atual no que toca aos processos de Gestão de Produto no seu portefólio, como um todo.
A partir deste método de análise e avaliação, práticas corretas realizadas pelas empresas serão identificadas, bem como identificados pontos de melhoria, com a finalidade de serem aplicados. Através desta melhoria, a maturidade da Gestão dos Produtos irá incrementar, tornando o processo cada vez mais sólido e menos suscetível a falhas na colocação do produto no mercado.
1.3 Gestão de Produto
A Gestão do Produto de Software não tem apenas a ver com entregas a tempo e horas e dentro do orçamento estimado. Não que estes fatores não sejam importantes, pois o são, mas porque os esforços realizados nesses aspetos podem tornar-se desnecessários, quando a conjuntura, abrangendo os requisitos ou os mercados, onde o produto se insere não forem de encontro ao que foi desenvolvido.
Uma das melhores definições para Gestão de Produto bem-sucedida é proposta por Christof Ebert, quando caracteriza este sucesso pela entrega dos produtos certos, na hora certa e para os mercados certos. (Ebert, Software Product Management, 2009). Um produto consiste numa entrega ou conjunto de entregas, que visa trazer valor aos seus clientes ou utilizadores. Este produto pode ser uma combinação de entrega de sistemas, soluções materiais ou serviços. A gestão deste produto é responsável por dirigir o produto desde a criação do produto até ao momento em que este é entregue ao cliente final ou colocado no mercado, gerando o maior lucro possível ao negócio. (Ebert & Brinkkemper, Software Product Management - An industry evaluation, 2014).
A criação de valor para um produto envolve vários cargos e departamentos dentro da própria organização. São os departamentos de Vendas, Marketing, R&D e Gestor de Produto os responsáveis principais pelas tomadas de decisão no decorrer da Gestão do Produto. Com um leque de intervenientes das mais variadas áreas, a comunicação torna-se fundamental no decorrer do processo, dada a existência de uma grande interdependência entre estes papeis. Um dos principais fatores de sucesso na Gestão do Produto consiste exatamente na definição de um núcleo na Gestão do Produto, núcleo este que envolve todos estes papeis. (Ebert & Brinkkemper, Software Product Management - An industry evaluation, 2014)
Cada cargo ou departamento acima mencionado desempenha um papel diferente na definição do produto, apresentando-se de seguida a organização típica da Gestão do Produto. Cabe ao Gestor de Produto ser o responsável máximo pelo produto como um só, desde o seu inicio até à sua finalização, de forma a maximizar o seu valor de negócio, valor este que geralmente é económico. O Gestor de Projeto é o responsável pelo sucesso do negócio e do cliente num determinado projeto, gerindo o projeto e delineando a estratégia para realizar tudo aquilo que foi proposto. O gestor de Marketing tem de determinar de que forma será vendido o produto ou serviço, bem como os seus canais de distribuição, com a finalidade de criar uma experiência ao cliente. Por último, a proposta de valor é comunicada ao cliente e ao departamento de Vendas, departamento este, que se focará em encontrar formas de o produto vender mais.
A figura Figura 1 - Ciclo de vida do produto de Software, mostra as fases do ciclo de vida de um produto, desde o seu inicio, à sua entrega ao cliente ou mercado, e a posterior evolução que o produto terá para subsistir. A sua criação, é onde ocorre a definição da visão estratégia sobre o âmbito do produto, bem como as etapas que terão de ser tomadas para formar uma base que apoie o seu desenvolvimento. O desenvolvimento, como o próprio nome indica é já uma fase onde se insere a codificação da solução. Atualmente nas equipas de desenvolvimento está muito em voga o desenvolvimento ágil de Software, que visa a entrega faseada de partes funcionais do produto, diminuindo assim o “Time to Market”. Aqui se compreende o porquê de o “Market Entry” se realizar a par do desenvolvimento, estando estas duas etapas a ocorrer simultaneamente. A evolução acontece geralmente com a manutenção do produto ao longo do tempo e à medida que os requisitos se vão alterando. Esta evolução pode também focar-se no desenvolvimento de novas linhas de produto a partir de uma base já existente, permitindo o foco em múltiplos mercados.
Figura 1 - Ciclo de vida do produto de Software
Apresentando-se como algo complexo devido ao elevado número de Stakeholders, a Gestão de Produto é muito importante para determinar o sucesso de um determinado produto no mercado. A diversidade de Stakeholders envolvidos num produto é mostrada pela Figura 2 - Definição de Produto, descrevendo as várias interações entre os departamentos. Para completar o cenário de complexidade, não existe uma educação que seja considerada formalizada nesta área, que proporcione todos os conhecimentos necessários para formar Gestores de Produto. A existência de um papel bem estabelecido dentro de uma organização na área Gestão de Produto aumenta a taxa de sucesso de projetos em termos de previsibilidade cronológica, qualidade e duração. (Ebert & Brinkkemper, Software Product Management - An industry evaluation, 2014). Como exemplo de casos de sucesso podem ser apresentadas empresas como a Apple, Google ou SAP, embora sejam exemplos que passem por vezes despercebidos. Também são conhecidos casos de insucesso, como a Netscape, que em 1995 e com uma quota de mercado de 80%, abrandou o seu ritmo 2 anos depois, abrindo falência em 2003. O principal problema apontado foi a não existência de uma Gestão de Produto efetiva, mas a existência de apenas um conjunto de funcionalidades a implementar. Um dos casos mais recentes
considerados é o da Nokia, onde se aponta a falta de gestão de produto como um razão para a perda de mercado nos últimos anos.
Figura 2 - Definição de Produto (Quora, 2015)
Uma visão mais concreta sobre o que é a Gestão de Produto, bem como as suas práticas pode ser tida através da Leitura do SPMBOK – Software Product Management Body of Knowledge.
1.4 Desafio e Objetivos
Um dos maiores desafios na realização da dissertação trata-se da falta de um ensino e consequentemente aprendizagem formalizado na área de Gestão de Produto. Gestão de Produto é muitas das vezes associada erradamente a Gestão de Projeto, sendo por vezes difícil fazer ver aos intervenientes a distinção entre estas duas áreas. Outro dos principais desafios e dúvidas, é o de as empresas serem maduras o suficiente para fazerem parte deste estudo. Isto torna-se um desafio, uma vez que no cluster de Braga, muitas das empresas são sólidas a nível técnico, no entanto, descuram áreas como a de Gestão, Marketing e Vendas, parcerias, entre outros, sendo esta uma das principais distinções entre Gestão de Projeto e Gestão de Produto.
Dar a conhecer nas empresas as áreas abordadas pela Gestão do Produto de Software; Conhecer as práticas de gestão de produto implementadas pelas empresas;
Recolher sob a forma de entrevistas as práticas efetuadas pelas empresas no âmbito da Gestão do Produto de Software;
Verificar, sob a forma de Matriz de Maturidade, as competências implementadas e não implementadas pelas empresas de forma a conseguir determinar o seu nível de maturidade;
Avaliar as competências implementadas de forma a que possam ser sugeridas melhorias nos seus processos;
Recolher estatísticas sobre a Gestão do Produto de Software tendo por base a Matriz de Maturidade;
Identificar pontos de falha comuns que não se coadunem com as práticas referidas pela Matriz de Maturidade;
1.5 Metodologia de Investigação
Para alcançar os objetivos propostos na secção anterior, e tendo sido já definido o objeto de estudo, procedeu-se a uma revisão da leitura sobre a área de Gestão de Produto. Esta revisão, consistiu em aprofundar as Áreas de Foco caracterizadas pelo SPM Competence Model, bem como a Matriz de Maturidade, a qual serviria de instrumento de avaliação. Para uma melhor compreensão da Matriz de Maturidade, também os autores desta foram contactados com a finalidade de esclarecer dúvidas que foram surgindo, facultar material necessário à realização do estudo, bem como servindo de critério de desempate na construção das Matrizes de Maturidade para algumas situações encontradas.
A obtenção da informação para o estudo será realizada através de entrevistas presenciais nas próprias empresas, de forma a observar e analisar com experiência própria, tudo aquilo que é respondido, procurando obter uma maior fiabilidade nos dados recolhidos.
A interpretação dos resultados consistirá na construção de uma Matriz de Maturidade para cada uma das empresas, que para além de fornecer o nível de maturidade destas, também permitirá uma melhor comunicação, ao leitor desta dissertação, dos dados obtidos.
1.6 Estrutura do documento
O presente documentado está estruturado de forma a constituir um fio condutor sobre o tema, de forma a que o leitor tenha uma melhor compreensão sobre como foi conduzido estudo do estado da arte, recolha de dados, a sua posterior análise, bem como as conclusões que foram retiradas.
O capítulo 2 contém a descrição sobre Software Product Management Competence Model, onde o estudo da Matriz de Maturidade assenta. Todas as definições de Funções de Negócio e Áreas de Foco são abordadas e detalhadas nesta secção, com especial atenção nas que esta dissertação trata.
No capítulo 3 é feita uma contextualização sobre o que é a Matriz de Maturidade, passando pelas Áreas de Foco que foram avaliadas ao longo desta dissertação. É de salientar que existem mais Áreas de Foco abordadas pela Matriz de Maturidade que não foram aprofundadas nesta secção, por não constituírem parte integrante deste estudo.
Com a finalidade de recolher métricas que permitissem sustentar este estudo, o capítulo 4 descreve a forma como foram recolhidos os dados, em particular a realização de entrevistas presenciais. É também nesta secção que é descrito como foi elaborado um guião que permitisse chegar às informações necessárias.
As entrevistas, bem como a análise individual da Matriz de Maturidade de cada uma das empresas presentes neste estudo encontra-se no capítulo 5, onde após a transcrição das ideias chave presentes a cada resposta sob forma textual, se encontra construída a Matriz de Maturidade de cada organização, bem como algumas anotações sobre a sua maturidade.
No capítulo 6, serão analisados e discutidos os resultados como um todo, de forma a ser melhor percecionado o contexto da região no que diz respeito à maturidade dos processos que sustentam a Gestão de Produto de Software.
2. SPM
C
OMPETENCE
M
ODEL
Uma competência consiste numa aptidão para cumprir uma determinada tarefa ou função, numa qualquer área especifica. (Significado de Competência, s.d.) O SPM Competence Model, consiste num modelo que expõe nas várias áreas que determinam um produto de Software, as competências determinantes para o sucesso do produto no mercado. Estas competências abrangem diversas áreas de conhecimento, sendo também vasto o leque de intervenientes que atuam sobre estas, executando tarefas essenciais ao ciclo de vida de um produto de Software.
A finalidade deste modelo é ajudar as empresas de Software a organizar a sua Gestão de Produto, bem como fomentar o seu ensino e a sua investigação (Jansen, Peeters, & Brinkkemper), através da estruturação dos métodos de gestão de produto da própria organização, com as áreas e práticas definidas por este modelo. Uma visão geral deste modelo é apresentada na Figura 3.
Figura 3 - Software Product Management Competence Model
Este modelo assenta em 4 áreas específicas, designadas de Funções de Negócio, ou ‘Business Functions’, representadas na Figura 3, pelas 4 grandes caixas azuis claras no centro da figura. Estas 4 Funções de Negócio abrangem temáticas, que apesar de diferentes entre si, acabam por se interligar como um todo, consolidando a prática de Gestão de Produto. Estas Funções de Negócio abrangem
toda a gestão de portefólio de produtos de uma empresa, uma vez que partindo do principio que o Portefólio de Produtos de uma empresa é constituído por produtos, um produto é o resultado das várias Releases que ocorreram até ao momento, e cada uma das Releases é constituída por um conjunto de requisitos.
Como foi referido anteriormente, apesar de estas Funções de Negócio constituírem diferentes tarefas na Gestão do Produto, as Funções de Negócio adjacentes estão mais perto de se relacionarem e complementarem, algo representado na Figura 3 pelas setas.
Cada uma destas Funções de Negócio, agrupa áreas na Gestão do Produto de Software que lhe são relacionadas e que na Figura 3 estão representadas por caixas dentro de cada uma das Funções de Negócio. Áreas de Foco adjacentes, também elas têm setas entre si que representam a interação entre elas, sendo que as Áreas de Foco que se encontram lado a lado, têm interações mais fortes. O fluxo do processo é representado por essas mesmas setas, representando também a circulação de informação entre diferentes áreas de foco. Contudo, existe ainda liberdade para interações entre Áreas de Foco que não estão diretamente ligadas por estas mesmas setas.
Algo que também é tomado em conta pelo modelo, é o envolvimento dos Stakeholders nos produtos. Estes intervenientes podem ser internos ou externos à organização e embora para cada uma das Funções de Negócio, ou mesmo para as Áreas de Foco, haja um envolvimento mais acentuado de algum tipo de Stakeholder especifico, existe a preocupação em abranger todos eles durante o processo. Estes são envolvidos em todo o ciclo de vida do produto.
No âmbito desta dissertação, foi assumido que o estudo iria incidir apenas em 2 Funções de Negócio, sendo elas o Planeamento de Produto e a Gestão do Portefólio.
2.1 Planeamento do Produto
A Função de Negócio do Planeamento do Produto, não é uma função que esteja assente estritamente da indústria de Software. Em vez disso, advém da experiência adquirida em outros setores, onde mais habitualmente se recorre a técnicas como o planeamento, previsão e o suporte à decisão. Esta Função de Negócio está focada na recolha de informação para a criação de um Roadmap, linha de produtos e ativos principais de uma determinada linha de produtos, bem como a sua definição ao longo do tempo.
O Planeamento do Produto contempla três Áreas de Foco: o Roadmap Intelligence, o
Product Roadmapping e o Core Asset Roadmapping.
2.1.1 Product Roadmapping
O Roadmap de um Produto é nada mais nada menos do que uma visão estratégica desse mesmo produto. Os seus principais objetivos são o planeamento e a comunicação entre os principais Stakeholders num produto de Software. É um dos instrumentos responsáveis por descrever a evolução do produto, deixando todos os intervenientes esclarecidos sobre a evolução do próprio produto.
Esta área deve ser vista dentro da própria organização como um meio de comunicação e de consenso sobre a direção que o produto toma, constituindo um instrumento decisório. É também útil à sua finalidade, dotar entidades externas das etapas a serem tomadas, o que promove a colaboração das partes externas na construção do produto, bem como fazer antever determinados fatores que lhes serão úteis em cada uma das suas áreas de negócio.
2.1.2 Core Asset Roadmapping
Num produto de Software, existem recursos ou ativos que embora não estejam presentes no produto final, muitas das vezes são essenciais para a definição e construção deste. Estes recursos são também fundamentais para a definição de linha de produtos, uma vez que é a partir destes recursos, que assenta possibilidade de criar produtos que se insiram numa linha, que terão na sua base estes ativos. A partir destes ativos, será menos custosa a construção de cada produto que integra a linha, uma vez que já existe uma base reutilizável para o fazer. Exemplos de alguns destes principais recursos podem ser para além do seu código, a sua documentação, a sua arquitetura, testes, etc. Note-se que face à especificidade do nome “Core Asset” num produto de Software, a tradução mais adequada para caracterizar “Core Asset” foi Ativo Principal.
2.1.3 Roadmap Intelligence
Com o intuito de melhorar o poder decisório sobre a direção do produto, são fundamentais as preocupações com fatores de mercado, tecnologia, parceiros e própria sociedade.
Estas temáticas têm de ser tomadas em conta na definição do produto, para o sucesso deste, sendo esta a área responsável por averiguar se estas condições são reunidas, e tidas em conta durante o desenvolvimento e manutenção do produto. Esta área é uma das principais responsáveis por
identificar vantagens e limitações para o produto. A partir deste tipo de informações, o Product Manager pode não só tomar, mas também sustentar as suas decisões, baseando-se em aspetos sólidos e não só apenas no seu ‘know how’.
2.2 Gestão do Portefólio
Quando existe um produto ou um conjunto de produtos numa organização, pode considerar-se que a organização tem um Portefólio de Produtos. Para a definição dos produtos, existem vários aspetos que têm de ser tomados em conta. Estes aspetos vão desde a análise ao estado de vida do produto, à sua concorrência, canais de venda, tendências de mercado entre outros.
As suas quatro Áreas de Foco são o Product Lifecycle Management, Partnering &
Contracting e Market Analysis.
2.2.1 Product Lifecycle Management
Nesta área está acentuada a preocupação na análise sobre o ciclo de vida do produto. No ciclo de vida do produto podem ser dados como exemplo, a sua definição, o seu desenvolvimento ou a sua manutenção. Para além da fase de vida do produto, a preocupação com estratégias, mudanças no produto, assim como custos e benefícios sobre o que foi desenvolvido, é também abordada nesta área. A preocupação sobre o desenvolvimento de linhas de produtos também é tida em conta nesta Área de Foco, uma vez que o desenvolvimento de linhas de produtos é considerado como um fator que aumenta o desempenho, graças à reutilização de componentes e ao facto de se conseguirem fornecer soluções mais abrangentes e onde a soma dos seus custos foi menor do que a construção individual de cada uma dessas soluções. (Brownsword & Clements, 1996)
2.2.2 Partnering & Contracting
Um produto de Software nunca terá sucesso se não conseguir chegar aos seus clientes, ou se não chegar em número que satisfaça o custo de desenvolvimento. Esta Área foca-se no estabelecimento e avaliação de parcerias, processos de definição de preços e aspetos de distribuição do produto, permitindo assim a chegada e manutenção do produto no mercado, num contexto operacional.
2.2.3 Market Analysis
O sucesso do produto está também dependente da correta análise do mercado para o qual o produto se destina, bem como as ilações que se retiram, bem como os planos que se traçam para atacar o mercado. A forma como se analisam os mercados e como se atacam estes, bem como a análise à concorrência bem como a razão pela qual existiu uma perda de clientes para um produto concorrente é analisada nesta área.
3. M
ATRIZ DE
M
ATURIDADE
Existem vários modelos que permitem fazer a avaliação bem como melhorar a Gestão do Produto de Software. De entre estes modelos, os mais conhecidos são talvez o CMM (Capability Maturity Model), CMMI (Capability Maturity Model – Integration) ou o SPICE, também conhecido como norma ISSO/IEC 15504. Em todos os modelos são identificadas vantagens e desvantagens que determinam ou não o seu uso em diferentes ambientes. No caso deste estudo em concreto e tendo em conta as desvantagens destes métodos, que se apresentam como métodos bastante pesados de usar, demasiado grandes para implementar na janela temporal disponível e demasiado caros. (Bekkers, et al., 2012)
A Matriz de Maturidade apresentada nesta secção vem combater os inconvenientes anteriormente referidos, tratando-se de um processo mais leve para implementar nas empresas, mas ainda assim completo, sendo transversal a todas as áreas de negócio representadas na Gestão do Produto de Software, permitindo uma melhoria incremental das práticas exercidas pelas empresas de Software.
Este modelo tem como base o Software Product Management Competence Model apresentado no capítulo anterior, constituindo um guião para a implementação das melhores práticas de Gestão de Produto de Software. Esta Matriz de Maturidade foi criada na Universidade de Utrecht, tendo sido validada por um conjunto de especialistas na área da Gestão de Produto de Software, bem como por Gestores de Produto (Weerd, Bekkers, & Brinkkemper, 2010). Dois anos mais tarde, um novo estudo utilizando a Matriz de Maturidade foi realizado, tendo em vista uma nova validação desta, mas desta vez com uma amostra mais significativa de empresas participantes no estudo, tendo sido efetuada uma nova validação que resultou num número reduzido de mudanças, visando resolver algumas anomalias aí detetadas. Esta nova avaliação teve novamente em conta especialistas na área da Gestão do Produto de Software, bem como 45 Gestores de Produto foram integrados no estudo. (Bekkers, et al., 2012) Esta contextualização torna-se necessária para sustentar o esforço e o poder que conferem à Matriz de Maturidade uma base sólida de capacidades para assistir na avaliação da Maturidade da Gestão do Produto de Software, tendo também em conta o seu baixo custo e facilidade de implementação.
O principal objetivo da Matriz de Maturidade é que a partir dela, qualquer empresa consiga fazer uma avaliação das suas práticas, conseguindo identificar áreas passíveis de melhoramento, tendo em conta que a partir do melhoramento destas, resultará um aumento do seu nível de maturidade. Esta
matriz de maturidade pode ser utilizada por qualquer empresa, incluindo pequenas ou médias empresas, como é o caso da amostra principal deste estudo.
A Matriz de Maturidade de Gestão do Produto de Software, é uma matriz baseada em Áreas de Foco, onde para cada uma delas, existem competências representados pelas letras de A a F, que por sua vez estão compreendidas entre o nível de maturidade de 0 a 10. A Figura 4 - Tabela de posicionamento das competências apresenta o posicionamento das competências nessa Matriz. Mais uma vez é de salientar que no presente estudo, apenas são contempladas as Funções de Negócio
Product Planning e Portfolio Management.
Figura 4 - Tabela de posicionamento das competências
Cada competência está ligada a uma descrição que aborda as práticas que a organização terá de implementar para alcançar aquele nível de maturidade. A organização terá de revelar se pratica ou não esses procedimentos. Para cada uma das Área de Foco, quantos mais procedimentos a organização implementar, maior será o seu nível de maturidade, quer dentro da Função de Negócio respetiva, quer no âmbito geral da avaliação da maturidade da Gestão do Produto de Software como um todo.
Em baixo são referidos os procedimentos associados a cada competência, que na matriz são representadas pelas letras de A a F, tais como apresentados na versão melhorada da Matriz de Maturidade, no artigo ‘Evaluating the Software Product Management Maturity Matrix’. (Bekkers, et al., 2012), versão esta que será utilizada no estudo realizado.
3.1 Product Roadmapping
A. Roadmap a curto prazo - É desenvolvido um Roadmap que detalha os planos no curto prazo. Esse Roadmap abrange mais do que uma Release.
B. Identificação do Tema - Temas de Release são identificados e mantidos. Os temas são decididos em conjunto com Stakeholders internos. Isto resulta numa lista de temas de Release armazenada centralmente, de modo a que requisitos, ativos principais, tendências de mercado, etc, lhes possam ser ligados.
C. Consulta Interna - O Roadmap é criado recorrendo à consulta de Stakeholders internos. D. Roadmap a longo prazo – O Roadmap abrange um período de pelo menos 4 anos.
E. Variante de Cliente – Uma variante menos detalhado do Roadmap é criada especificamente para entidades externas, tais como, clientes, parceiros, investidores.
3.2 Core Asset Roadmapping
A. Registo Centralizado – Todos os ativos principais do produto são registados uniformemente e armazenados centralmente.
B. Identificação de Ativos Principais – Componentes/Funcionalidades (Ativos Principais) comuns são sistematicamente identificados entre os produtos da organização e as entregas à volta do produto.
C. Decisões ‘Make or Buy’ – Está em curso um processo para averiguar se o que será desenvolvido deverá ser feito internamente ou comprado a entidades externas – Make or Buy. Isto também inclui a decisão de recorrer a Outsourcing ou subcontratar o desenvolvimento. D. Construção do Roadmap dos Ativos Principais – É elaborado um planeamento para os
ativos principais, que mostra como estes são sustentados, melhorados e atualizados. Este planeamento contém tanto ativos principais que já foram desenvolvidos, bem como aqueles que ainda estão em desenvolvimento.
3.3 Roadmap Intelligence
A. Análise de Produto – É criado um plano mostrando os mercados que se irão procurar e como se planeia desenvolver os produtos para cada segmento. Por exemplo, no espaço de um ano pode estar planeado entrar no mercado automóvel, fazendo parceria com outra empresa,
ou pode pretender entrar no mercado Farmacêutico em um a dois anos, desenvolvendo produtos internamente, ou adquirindo produtos.
B. Tendências da Sociedade – É criada uma visão geral mostrando o panorama a nível de tendências na sociedade nos próximos anos. Esta visão contempla uma visão geral e especifica sobre os produtos da própria indústria.
C. Tendências Tecnológicas - É criada uma visão geral mostrando o panorama a nível de desenvolvimentos tecnológicos nos próximos anos. Esta visão contempla uma visão geral e especifica sobre os produtos da própria indústria.
D. Tendências de Concorrência – É criada uma visão geral mostrando o que os produtos concorrentes estão a fazer em termos de desenvolvimento do seu produto nos próximos anos. As principais tendências de desenvolvimento entre a concorrência são mostradas, e o desenvolvimento dos produtos concorrentes mais importantes são descritos com especial atenção.
E. Roadmap de Parceiros – É criada uma visão geral mostrando o que os parceiros irão desenvolver no próximo período. Podem ser considerados exemplos de produtos parceiros, sistemas operativos, ambientes de desenvolvimento, bases de dados, etc. A visão geral contempla o que acontecerá com a plataforma base de Software, assim como o que a empresa parceira irá desenvolver em termos do seu próprio produto e ferramentas de desenvolvimento, que a sua própria organização terá ou poderá necessitar para suportar os produtos/componentes parceiros.
3.4 Product Lifecycle Management
A. Análise do Ciclo de Vida do Produto – A fase de vida atual do produto é determinada, pelo menos uma vez por ano, para cada produto no portefólio da organização. Esta análise baseia-se tanto em aspetos técnicos como financeiros. A informação é então recolhida de todos os Stakeholders internos importantes, tais como o conselho de administração, departamento de vendas ou desenvolvimento.
B. Inovação de Portefólio – Está implementado um processo de decisão para decidir a incorporação de tendências num dos produtos atuais, ou em novos produtos a serem desenvolvidos.
C. Análise de Âmbito do Portefólio – É realizada uma análise de âmbito do produto para identificar falhas ou sobreposições entre os produtos do portefólio da organização.
D. Business Case – É realizado um Business Case para as principais revisões do produto (revisões abrangem múltiplas Releases), ou quando a estratégia do produto muda.
E. Linhas de Produto – São desenvolvidas linhas de produto. A arquitetura da linha de produto é documentada e o seu objetivo é claramente definido.
3.5 Partnering & Contracting
A. Acordos a nível de Serviços – São preparados a nível de serviços (SLAs) para os clientes. B. Gestão da propriedade intelectual – Estão implementadas medidas para proteger a
propriedade intelectual da própria organização e para gerir a propriedade intelectual de outras organizações.
C. Investigar canais de distribuição – Está implementado um processo para verificar periodicamente os canais de distribuição vigentes, bem como identificar canais de distribuição alternativos.
D. Estabelecimento e avaliação de modelos de preço – Está implementado um processo para estabelecer o modelo de preços, bem como para verificar periodicamente se este ainda se encaixa no mercado.
E. Monitorização da Rede de Parceiros – Uma rede de parceiros é monitorizada ou portais de parceria são utilizados para regular as parcerias. São recolhidos indicadores de desempenho que permitem avaliar o desempenho dos parceiros numa base diária.
3.6 Market Analysis
A. Identificação de Tendências de Mercado – Existe uma procura ativa por oportunidades de mercado, de modo a expandir os produtos já existentes, ou criar novos produtos. Esta procura é feita em mercados relacionados ou semelhantes aos mercados da organização, são visitadas conferências, entrevistados clientes, etc. Todos estes aspetos terão de ser documentados.
B. Estratégia de mercado – É criado um plano mostrando os mercados onde o produto se irá focar, bem como qual o planeamento para o desenvolvimento dos produtos em cada segmento.
C. Análise de ganho ou perda de clientes – É feita uma análise ganho/perda, para averiguar o porquê de um cliente optar ou não, por escolher um produto da organização. Esta competência analisa não só as funcionalidades do produto, mas também o canal de vendas. D. Análise de concorrência – É feita uma análise concorrencial a nível organizacional, de
forma a analisar o que a concorrência tem para oferecer, quais os seus pontos fortes, bem como aquilo que irão oferecer, comparado com a própria organização.
E. Identificação das tendências de mercado – Entidades externas à organização são utilizadas para realizar estudos de mercado, especificamente para o portefólio de produtos da organização.
4. E
NTREVISTAS
Para a recolha de informação foram procurados estabelecer contactos com empresas de Software que possuam produtos desenvolvidos no seu portefólio. Com a finalidade de pedir às empresas que participassem no estudo, os contactos foram efetuados via email, presencialmente nos escritórios destas mesmas, em eventos que as empresas estivessem presentes ou através de conhecimentos que o orientador da dissertação tem na área. Nestas duas últimas abordagens, ainda que fosse introduzido o tema de forma verbal, um email foi enviado posteriormente, com a informação necessária à empresa para ficar com algumas noções do tema abordado na entrevista.
No momento da entrevista, foi feita uma breve explicação sobre a temática da dissertação aos entrevistados, bem como levantada alguma dúvida que estes tivessem em relação ao estudo ou ao modelo de avaliação adotado. Posteriormente era esclarecido que a entrevista seria anónima no contexto da dissertação, ou seja, os nomes e práticas das empresas ficam salvaguardadas neste estudo, e nome fictícios serão atribuídos no decorrer da dissertação, com vista a garantir o anonimato. Algo que se tornou necessário também, foi solicitar a possibilidade de se as entrevistas serem gravadas, de forma a que quaisquer dúvidas que surgissem aquando do preenchimento da matriz de maturidade fossem esclarecidas fazendo uso da gravação. Foi também pedido, caso necessário, que se alguma dúvida surgisse também durante o preenchimento da matriz, e não sendo o conteúdo da gravação útil para satisfazer tal dúvida, se um contacto poderia ser facultado com vista ao esclarecimento dessa mesma dúvida.
O questionário foi elaborado, baseando-se em duas vertentes. A primeira foi de efetuar perguntas gerais sobre a organização, que permitissem recolher métricas que dariam maior conhecimento sobre a empresa, a sua história, organização e metodologias. Estes dados seriam úteis para compreender a razão de algumas competências serem implementadas, bem como segmentar as empresas com base em determinados aspetos, tais como o número de funcionários, volume de negócios, dimensões da equipa, etc. A segunda vertente consistiu em questões sobre as competências presentes no ‘Software Process Management Competence Model’, para cada uma das suas Funções de Negócio. Foi mapeado para cada Área de Foco dentro das Funções de Negócio, um conjunto de questões que determinam as competências implementadas em cada Área de Foco. As questões foram colocadas de forma a que as competências não fossem expostas diretamente ao entrevistado, de forma a este não se sentir tentado em dar uma resposta afirmativa a algo que não estaria implementado na empresa. Com o objetivo de evitar perguntas “Sim/Não”, sempre que possível, foi encorajado ao longo da entrevista que os
entrevistados detalhassem as suas respostas. Também para perguntas em que os entrevistados não dominassem o que estava a ser falado, foi encorajado a este procurar no momento ou à posteriori (e sempre que possível) alguém que conseguisse dar resposta à pergunta, evitando que respostas fossem dadas de forma errada, ou que o entrevistado voltasse a dar respostas positivas para competências que poderiam não estar implementadas na empresa.
Apresentam-se abaixo, para cada uma das Funções de Negócio, as questões realizadas durante a entrevista, bem como o seu mapeamento para cada Área de Foco.
4.1 Product Roadmapping
Para a Função de Negócio do Planeamento de Produto, foi estabelecido o seguinte guião de entrevista: 1. É elaborado algum planeamento/roadmap para os produtos que desenvolvem?
2. Por quem é realizado tal planeamento/roadmap? Stakeholders internos e externos? Pode enumerar alguns stakeholders?
3. Nesse roadmap, qual é geralmente o período de tempo abrangido? 4. Quantas releases estão geralmente contempladas nesse planeamento?
5. São criadas versões minimalistas desse planeamento/roadmap com vista a serem fornecidas a partes externas? Estas partes externas podem incluir clientes, parceiros, investidores, entre outros.
6. Como são identificados os temas de release?
7. Quais os stakeholders internos e externos que intervêm nesse processo de identificação? 8. Esses temas são convertidos numa lista de temas de release?
9. De que forma é mantido o registo desses temas? Papel, base de dados, etc? 10. Quem pode consultar esses registos?
11. Existe rastreabilidade nesses temas? É possível ligar ao tema aspetos tais como requisitos a ele associados, tendências de mercado identificadas, etc?
Foi estabelecido o seguinte mapeamento entre cada uma das Áreas de Foco e as questões que respondem à implementação ou não dessa mesma Área.
Tabela 2 - Mapeamento de Competências e Questões para Product Roadmap
Competência Questões
B 6,7,8,9,10,11
C 2
D 3
E 5
4.2 Core Asset Roadmapping
Para a Função de Negócio de Planeamento de Ativos Principais, foi estabelecido o seguinte guião de entrevista:
1. Os ativos principais são registados uniformemente? Exemplos de ativos principais podem ser documento de requisitos, esquemas de base de dados, documentação, testes, etc.
2. Estes ativos são armazenados ao longo do projeto? Como? Quem tem acesso?
3. Existe periodicidade na recolha destes ativos ou ocorre de forma inconstante? Qual a periodicidade?
4. É normal fazer uma análise ‘Make or Buy’ sobre o que é produzido? Ocorre ativamente? 5. É feito algum tipo de planeamento com estes ativos? De que forma são sustentados,
melhorados, atualizados?
6. Que tipo de recursos estão presentes neste planeamento? Desenvolvidos ou também aqueles que ainda estão em desenvolvimento?
Foi estabelecido o seguinte mapeamento entre cada uma das Áreas de Foco e as questões que respondem à implementação ou não dessa mesma Área.
Tabela 3 - Mapeamento de Competências e Questões para Core Asset Roadmapping
Competência Questões
A 1,2
B 3
C 4
4.3 Roadmap Intelligence
Para a Função de Negócio de Inteligência de Planeamento, foi estabelecido o seguinte guião de entrevista:
1. Como é delineada a forma como se atacarão os mercados? 2. É realizado um plano para cada segmento de mercado?
3. São elaborados relatórios mostrando o panorama do mercado/sociedade num futuro próximo? 4. São elaborados relatórios mostrando o panorama a nível tecnológico num futuro próximo? 5. São elaborados relatórios mostrando o panorama a nível de desenvolvimento de produtos
concorrentes num futuro próximo? 6. Qual o rigor desse detalhe?
7. É criada uma visão sobre o que os parceiros irão desenvolver num futuro próximo? Podem ser considerados exemplos de produtos parceiros, sistemas operativos, ambientes de desenvolvimento, bases de dados, etc. Esta visão é documentada?
8. É mostrado o que acontecerá com a plataforma base de Software e o que as empresas parceiras irão entregar a nível dos seus próprios produtos e ferramentas de desenvolvimento, de modo a que a sua organização possa suportar tais produtos ou componentes? É algo que seja documentado?
9. Estes relatórios contemplam uma visão geral das temáticas abordadas, ou uma visão mais concreta, dos produtos que estão a ser desenvolvidos?
Foi estabelecido o seguinte mapeamento entre cada uma das Áreas de Foco e as questões que respondem à implementação ou não dessa mesma Área.
Tabela 4 - Mapeamento de Competências e Questões para Roadmap Intelligence
Competência Questões A 1,2 B 3 C 4 D 5,6 E 7,8,9
4.4 Product Lifecycle Management
Para a Função de Negócio de Gestão do Ciclo de Vida do Produto, foi estabelecido o seguinte guião de entrevista:
1. Como é determinada a fase de vida atual de um produto? De quanto em quanto tempo é realizada esta análise?
2. Em que aspetos se baseia esta análise? (Técnicos, Financeiros, etc) 3. Por quem é realizada tal análise e que intervenientes tem em conta?
4. Como é delineada a decisão de que uma tendência previamente analisada será integrada num produto?
5. Como são identificadas falhas ou sobreposições entre produtos no portefólio de produtos da organização? São realizadas análises de âmbito?
6. É elaborado um ‘Business Case’ para as principais revisões do produto, ou para quando a estratégia deste muda? Estas revisões abrangem múltiplas releases? Nota de entrevistador:
‘Business Case’ é descrito como a comparação entre os custos associados com o produto ou
projeto e os benefícios económicos ou valor a ser entregue. Kittlaus & Clough, 2009
7. São desenvolvidas linhas de produto? Nota de entrevistador: Linha de Produto é descrito como o conjunto de sistemas intensivos de Software que partilham um conjunto de características que satisfazem as necessidades especificas de um segmento de mercado em particular, e que são desenvolvidas a partir de um conjunto de recursos numa forma prescrita. Clements & Northrop, 2002.
8. Como está documentada esta linha de produto e como é definido o seu objetivo?
Foi estabelecido o seguinte mapeamento entre cada uma das Áreas de Foco e as questões que respondem à implementação ou não dessa mesma Área.
Tabela 5 - Mapeamento de Competências e Questões para Product Lifecycle Management
Competência Questões A 1,2,3 B 4 C 5 D 6 E 7,8
4.5 Partnering & Contracting
Para a Função de Negócio de Parceria e Adjudicação, foi estabelecido o seguinte guião de entrevista: 1. São realizados algum tipo de acordos a nível de serviços com os clientes?
2. Estão implementadas algumas medidas para proteger a propriedade intelectual da empresa? 3. Estão implementadas algumas medidas para gerir o uso da propriedade intelectual da
empresa? Quais?
4. Que canais de distribuição existem para um produto?
5. Está implementado algum processo para verificar o desempenho desses canais de distribuição alternativos?
6. Como é estabelecido o preço de um produto? Existe algum processo que assista a esta definição de preço? Existem medidas para verificar se o preço de um produto se encaixa no mercado com o passar do tempo?
7. É mantida uma rede de parceiros? De que forma são reguladas as parcerias?
8. Esta rede de parceiros é avaliada de alguma forma tendo em conta o seu desempenho? Com que regularidade é efetuada tal avaliação?
Foi estabelecido o seguinte mapeamento entre cada uma das Áreas de Foco e as questões que respondem à implementação ou não dessa mesma Área.
Tabela 6 - Mapeamento de Competências e Questões para Partnering & Contracting
Competência Questões A 1 B 2,3 C 4,5 D 6 E 7,8
4.6 Market Analysis
Para a Função de Negócio de Análise de Mercado, foi estabelecido o seguinte guião de entrevista: 1. Como é feita a pesquisa por novos mercados para os produtos existentes no portefólio da
2. Estas pesquisas, bem como os seus resultados, estão documentadas?
3. É criado um plano de mercados a atacar? Qual o nível de detalhe desse plano?
4. É feita alguma análise para averiguar a razão pela qual um cliente optou, ou não, por um produto? Qual o tipo de análise? Nota de entrevistador: Não só as funcionalidades do próprio produto devem ser tomadas em conta para esta análise, mas também outros fatores como por exemplo o processo de venda, acompanhamento ao cliente, etc.
5. É feito algum tipo de análise à concorrência a nível organizacional? Que métricas são tentadas recolher?
6. É frequente recorrer a entidades externas para realizar análises de mercado?
Foi estabelecido o seguinte mapeamento entre cada uma das Áreas de Foco e as questões que respondem à implementação ou não dessa mesma Área.
Tabela 7 - Mapeamento de Competências e Questões para Market Analysis
Competência Questões A 1,2 B 3 C 4 D 5 E 6
5. E
NTREVISTAS
5.1 Empresa A
Características da empresa
Idade: Departamento de Software nasceu em 2015 apesar da longa idade da empresa. Localização do Mercado: Todo o mundo.
Número de colaboradores: 30 colaboradores. Metodologia de desenvolvimento: SCRUM.
Número de elementos por equipa: 4 a 8 elementos.
Product Roadmapping
1. É elaborado algum planeamento/roadmap para os produtos que desenvolvem? R: Sim.
2. Por quem é realizado tal planeamento/roadmap? Stakeholders internos e externos? Pode enumerar alguns stakeholders?
R: No início do projeto, pela equipa do projeto e pela equipa de aquisição do produto. 3. Nesse roadmap, qual é geralmente o período de tempo abrangido?
R: Até 3 anos.
4. Quantas releases estão geralmente contempladas nesse planeamento? R: Duas a três releases por ano.
5. São criadas versões minimalistas desse planeamento/roadmap com vista a serem fornecidas a partes externas? Estas partes externas podem incluir clientes, parceiros, investidores, entre outros.
R: Sim, para clientes e gestão afastada da fábrica. 6. Como são identificados os temas de release?
R: É variável e depende do roadmap estabelecido com o cliente.
7. Quais os stakeholders internos e externos que intervêm nesse processo de identificação?
R: Apenas o cliente.
9. De que forma é mantido o registo desses temas? Papel, base de dados, etc? R: Documento acessível à equipa do projeto.
10. Quem pode consultar esses registos? R: Equipa.
11. Existe rastreabilidade nesses temas? É possível ligar ao tema aspetos tais como requisitos a ele associados, tendências de mercado identificadas, etc?
R: Sim, mas é feito de forma ad-hoc.
Core Asset Roadmapping
1. Os ativos principais são registados uniformemente? Exemplos de ativos principais podem ser documento de requisitos, esquemas de base de dados, documentação, testes, etc.
R: Não de forma uniforme.
2. Estes ativos são armazenados ao longo do projeto? Como? Quem tem acesso? R: Sim. A equipa do projeto tem acesso.
3. Existe periodicidade na recolha destes ativos ou ocorre de forma inconstante? Qual a periodicidade?
R: Semanalmente.
4. É normal fazer uma análise ‘Make or Buy’ sobre o que é produzido? Ocorre ativamente?
R: Sim.
5. É feito algum tipo de planeamento com estes ativos? De que forma são sustentados, melhorados, atualizados?
R: Sim, sendo sustentados, melhorados e atualizados de projeto para projeto.
6. Que tipo de recursos estão presentes neste planeamento? Desenvolvidos ou também aqueles que ainda estão em desenvolvimento?
R: Mais os futuros.
Roadmap Intelligence
1. Como é delineada a forma como se atacarão os mercados? R: Não sabe.
2. É realizado um plano para cada segmento de mercado? R: Não sabe.
3. São elaborados relatórios mostrando o panorama do mercado/sociedade num futuro próximo?
R: Sim, mas num departamento afastado deste.
4. São elaborados relatórios mostrando o panorama a nível tecnológico num futuro próximo?
R: Sim, mas num departamento afastado deste.
5. São elaborados relatórios mostrando o panorama a nível de desenvolvimento de produtos concorrentes num futuro próximo?
R: Sim, mas num departamento afastado deste. 6. Qual o rigor desse detalhe?
R: É tudo bastante detalhado.
7. É criada uma visão sobre o que os parceiros irão desenvolver num futuro próximo? Podem ser considerados exemplos de produtos parceiros sistemas operativos, ambientes de desenvolvimento, bases de dados, etc. Esta visão é documentada? R: É criada e documentada.
8. É mostrado que acontecerá com a plataforma base de Software e o que as empresas parceiras irão entregar a nível dos seus próprios produtos e ferramentas de desenvolvimento, de modo a que a sua organização possa suportar tais produtos ou componentes? É algo que seja documentado?
R: Sim.
9. Estes relatórios contemplam uma visão geral das temáticas abordadas, ou uma visão mais concreta, dos produtos que estão a ser desenvolvidos?
R: Contemplam uma visão concreta.
Product Lifecycle Management
1. Como é determinada a fase de vida atual de um produto? De quanto em quanto tempo é realizada esta análise?
R: Não sabe.
