Dez passos para a implantação de projetos de Business Intelligence

É essencial aprender com os erros de outros para que um projeto não falhe.

No passado, as companhias gastavam muito dinheiro com BI, mas nem sempre conseguiam alcançar os resultados pretendidos. Prova disso, as reclamações dos usuários sobre a falta da qualidade dos dados e a dificuldade de utilização dos sistemas e ferramentas de BI, assim como relatórios incompletos ou dados imprecisos que impactam a tomada de decisões. Estas debilidades são causadas por fraquezas funcionais e organizacionais na implementação de projetos de Business Intelligence.

Particularmente para novos projetos de BI, é essencial aprender com os erros de outros para que o projeto não falhe. A Information Builders compilou 10 regras de ouro para a implementação.

1. Definir os requisitos funcionais.

Comparações por indicadores de desempenho (KPI – Key Performance Indicators) são o centro de qualquer aplicação de BI. A equipe do projeto, composta por colaboradores do departamento de TI e de outros departamentos especializados, deve determinar que informação deve ser disponibilizada pelas aplicações de BI, quando é necessário estar disponível e em que formato.

2. Definir os grupos de utilizadores.

A equipe do projeto deve definir quem são os utilizadores da solução de BI. Existem geralmente três grupos de utilizadores: utilizadores gerais de relatórios; os produtores e analistas que avaliam os dados; e finalmente os gestores que decidem os objetivos.

3. Envolver os utilizadores numa fase inicial.

Na fase inicial, o departamento de TI deve criar um protótipo simples da solução. Desta forma, pode ser feita uma revisão para assegurar que os requisitos essenciais serão incluídos desde o início. Na implementação de um projecto de BI, os colaboradores dos departamentos especializados devem sempre ser incluídos paralelamente, uma vez que são esses indivíduos que, no futuro, irão trabalhar com as aplicações. Quando se testar o protótipo, esses colaboradores podem determinar se o projeto segue o escopo.

4. Ter apoio da Gestão.

A equipe do projeto deve ter apoio da gestão. Esta é a única forma de garantir que os objetivos corporativos a curto e longo prazo sejam incorporados. A implementação é monitorizada pela comparação de indicadores de desempenho (KPI) permanentes dos rácios operacionais mais importantes.

5. Identificar os Indicadores de Desempenho (KPI) requeridos.

São necessários valores operativos para a gestão dos processos de uma companhia. A equipe de projecto deve defini-los em conjunto com o departamento especialista. No manuseamento e produção de materiais, por exemplo, indicadores de desempenho tais como “custo do material por cada componente” ou “volume de negócio por colaborador” são variáveis provadas. Isto torna mais fácil determinar se os objetivos foram alcançados ou não.

6. Garantir a integração e qualidade dos dados.

Integração dos dados é um fator decisivo para o sucesso de um projeto de BI. A equipe deve identificar os sistemas operacionais nos quais a informação requerida está disponível e como os dados devem ser acessados. Para informação atualizada, o acesso direto é a melhor opção. Se a qualidade dos dados brutos não for suficiente, isso deverá ser melhorado com as ferramentas de software apropriadas para acessar todas as fontes de dados.

7. Descubra que ferramentas de BI já estão disponíveis na empresa.

Quando um novo projeto é iniciado, é necessário determinar se as ferramentas existentes para os usuários finais devem continuar a ser utilizadas ou se devem ser substituídas completamente. Na maioria dos casos, a padronização num único sistema de BI é preferível para garantir consistência na disponibilização da informação dentro da empresa.

8. Escolher o Software de BI correto.

Com uma Proof-of-Concept (PoC), a equipe de projeto decide o software mais adequado, baseando-se geralmente  em um briefing específico. Este procedimento permite à equipe de projeto garantir com maior grau de certeza de que o software se adequa ao seu negócio.

9. Limitar o tempo de execução do projeto.

Aqui aplica-se a velha regra: “Tudo o que dure mais que seis meses deixa de ser um projeto e passa a ser um problema.” Quando se implementa um novo projeto de BI, os departamentos especializados devem estar centrados e proceder em claros passos definidos. Os subprojetos devem ser desenvolvidos para que os primeiros módulos executáveis e operacionais estejam disponíveis depois de dois ou três meses.

10. Um projeto de BI é um processo constante.

Os requisitos das companhias mudam constantemente e o mesmo se aplica a uma aplicação de BI. Todas as soluções de BI têm de ser continuamente desenvolvidas e otimizadas em uma base permanente. Esta é a única forma que têm de cumprir os requisitos.

“O BI é, antes de tudo, uma tarefa de controle, compras, marketing e vendas. Os departamentos de negócio estão familiarizados com os requisitos individuais em termos de gestão da performance funcional e sabem que parâmetros e dados necessitam para controlar os seus processos de negócio”, afirma Klaus Hofmann zur Linden, Technical Manager Germany da Information Builders em Eschborn. “O departamento de TI deve construir a infra-estrutura para as aplicações de BI e assegurar uma operação de confiança”.

Fonte: CIO

Manifesto das Regras de Negócio

Os princípios da independência da regra

por Business Rules Group

Artigo 1. Requisitos como elementos principais, nunca secundários

1.1. As regras são um cidadão de primeira classe no mundo dos requisitos.

1.2. As regras são essenciais para os modelos de negócio e para os modelos de tecnologia, sendo uma parte separada e específica dos mesmos.

Artigo 2. Independentes dos processos, não contidas neles

2.1. As regras são restrições explícitas de comportamento e/ou proporcionam suporte ao comportamento.

2.2. As regras não são processos nem procedimentos, pelo que não devem estar contidas em nenhum deles.

2.3. As regras aplicam-se transversalmente a processos e procedimentos. Deve existir um corpo coeso de regras, que se aplique de forma consistente a todas as áreas relevantes de atividade de negócio.

Artigo 3. Conhecimento explícito, não um sub-produto

3.1. As regras constroem-se sobre fatos, e os fatos sobre conceitos que são expressos por termos.

3.2. Os termos expressam conceitos de negócio; os fatos constituem asserções sobre estes conceitos; as regras restringem e suportam estes fatos.

3.3. As regras devem ser explícitas. Nunca se deve assumir nenhuma regra sobre nenhum conceito ou nenhum fato.

3.4. As regras são os fundamentos que definem o que o negócio sabe de si mesmo – isto é, são o conhecimento base do negócio.

3.5. As regras necessitam de ser alimentadas, protegidas e geridas.

Artigo 4. Declarativas, não procedimentais

4.1. As regras devem ser expressas de forma declarativa em frases de linguagem natural, perceptíveis pela audiência conhecedora do negócio em causa.

4.2. Se algo não pode ser expresso, então não é uma regra.

4.3. Um conjunto de enunciados só é declarativo se não contém uma sequência implícita.

4.4. Todo o enunciado de regras que precise de outros elementos para além de termos ou fatos, requere assunções sobre uma implementação de sistema.

4.5. Uma regra é distinta de qualquer medida definida para o seu cumprimento. A regra e a forma do seu cumprimento são questões distintas.

4.6. As regras devem definir-se independentemente de quem é responsável pelo

seu cumprimento, e de onde, quando e como se fazem cumprir.

4.7. As exceções às regras são expressas por outras regras.

Artigo 5. Expressões bem formadas,não Ad Hoc

5.1. As regras de negócio devem ser expressas de forma a que os especialistas do negócio possam validar a sua correção.

5.2. As regras de negócio devem ser expressas de forma a permitir verificar reciprocamente a sua consistência.

5.3. As lógicas formais, como a lógica de predicados, são fundamentais para a expressão formal, bem formada, das regras em termos de negócio, assim como para as tecnologias que implementam estas regras.

Artigo 6. Arquitetura baseada em regras, não uma implementação indireta

6.1. Um sistema baseado em regras de negócio é construído intencionalmente para permitir a mudança constante das regras de negócio. A plataforma sobre a qual o sistema é executado deve suportar esta evolução contínua.

6.2. Executar diretamente as regras – por exemplo através de motores de regras – é uma estratégia de implementação melhor que transcrevê-las de forma procedimental.

6.3. Um sistema de regras de negócio deve ser sempre capaz de explicar as razões pelas quais chega a uma conclusão ou toma uma ação.

6.4. As regras baseiam-se em valores de verdade. A forma como se determina ou mantém o valor de verdade de uma regra é mantida oculta dos usuários.

6.5. A relação entre eventos e regras é geralmente de muitos-para-muitos.

Artigo 7. Processos orientados às regras, não programação baseada em exceções

7.1. As regras definem a fronteira entre uma atividade de negócio aceitável e não aceitável.

7.2. As regras requerem frequentemente um tratamento especial ou seletivo das violações detectadas. Qualquer atividade derivada da violação de uma regra constitui uma atividade como qualquer outra.

7.3. Para assegurar a consistência e a reutilização máxima, o tratamento de atividades de negócio não aceitáveis deve separar-se do tratamento das atividades de negócio aceitáveis.

Artigo 8. Ao serviço do negócio, não da tecnologia

8.1. As regras tratam de práticas e orientações do negócio; portanto, as regras são motivadas pelas metas e os objetivos de negócio, e são moldadas por diversas influências.

8.2. As regras implicam sempre um custo para o negócio.

8.3. O custo da aplicação das regras deve ser valorizado e balanceado, tendo em consideração os riscos assumidos pelo negócio, e as oportunidades perdidas no caso de não as aplicar.

8.4. “Mais regras” não é necessariamente melhor. Normalmente é preferível ter poucas mas “boas regras”.

8.5. Um sistema eficaz pode basear-se num número pequeno de regras. Posteriormente,podem adicionar-se regras mais específicas de forma que ao longo do tempo o sistema se torne mais inteligente.

Artigo 9.“De, por e para” as pessoas do negócio, e não “de, por e para” as pessoas de TI

9.1. As regras devem provir das pessoas conhecedoras do negócio.

9.2. Os especialistas do negócio devem dispor de ferramentas que os auxiliem a formular, validar e gerir regras.

9.3. Os especialistas de negócio devem dispor de ferramentas que os ajudem a verificar consistência recíproca entre regras de negócio.

Artigo 10. Gerir lógica de negócio, não plataformas de Hardware/Software

10.1. As regras de negócio são um ativo vital do negócio.

10.2. A longo prazo, as regras são mais importantes para o negócio que as plataformas de Hardware/Software.

10.3. As regras de negócio devem ser organizadas e armazenadas de forma que possam ser facilmente redistribuídas para novas plataformas de Hardware/Software.

10.4. As regras, e a capacidade de as alterar de forma eficaz, são fatores chave para melhorar a adaptabilidade do negócio.

Fonte: Copyright, 2003. Business Rules Group. Versão 2.0, Novembro 1, 2003. Editado por Ronald G. Ross.
www.BusinessRulesGroup.org

Cresce a demanda por profissionais de TI com visão de negócios

Ter conhecimento do negócio facilita a conversa com o gestor e a administração de projetos

 O número de empresas que planeja contratar profissionais de tecnologia continua crescendo. É o que revela a pesquisa Previsões para 2013, realizada pela COMPUTERWORLD nos Estados Unidos, com 334 executivos de TI.  Mais de 30% deles (33%) disseram que planejam aumentar seus quadros nos próximos 12 meses. Este é o terceiro ano consecutivo que a percentagem de respondentes com planos de contratação aumenta. Em 2012, o incremento foi de 29%, 23% em 2010 e 20% em 2009. Todos comparados aos anos anteriores.

O mercado está aquecido também no Brasil, em razão da expansão de muitas empresas, especialmente impulsionada pela proximidade dos megaeventos esportivos que serão sediados em solo nacional [Mundial de futebol e Olimpíadas]. Cenário, portanto, favorável para quem busca uma oportunidade. Mas as chances não são para todos. É necessário ter as habilidades corretas, que estão na mira de CIOs e executivos de TI. 

Segundo Mariana Horno, gerente sênior da divisão de Legal, RH e TI, da Robert Half no Brasil, consultoria especializada no recrutamento de talentos, por aqui os profissionais de TI devem apresentar conhecimento técnico aprofundado e certificações correlatas a esse conhecimento específico.

“Além disso, o perfil comportamental tem sido importantíssimo. É necessário, na maior parte das vezes, boa comunicação, ser mão na massa e dedicado”, garante. A executiva diz perceber atualmente uma movimentação corriqueira, demandando profissionais no segmento de meios de pagamento, e-commerce e indústria farmacêutica.

“O primeiro trimestre do ano costuma ser mais moroso no processo de contratação, por conta das férias de verão e do Carnaval. Porém, é bom buscar oportunidades e a possibilidade de conseguir um emprego é alta”, relata, acrescentando que é preciso ter paciência, pois pode ser que o tempo de processo demore um pouco mais por conta do número reduzido de dias úteis no período.

“Hoje, temos, em média, entre 20 e 25 vagas de TI por mês. Esse número é um pouco variável, pois há algumas em andamento e outras que chegam durante a semana”, avisa.

De acordo com Cristiani Martins, diretora comercial da Atlantic Solutions, consultoria da área de TI, percebe-se hoje forte demanda por profissionais especializados em web. “Os chamados desenvolvedores Java cloud estão em alta”, afirma e destaca que para o crescimento na carreira, hoje é necessário ter capacidade para gerenciar projetos, conhecimento de processos (ITIL) e, especialmente, visão de negócios. “Treinamos muitos profissionais e eles costumam buscar especialização em governança de TI e em Java Mobile.” 

“Quando você olha para qualquer tendência de pesquisa ou de mercado, TI é sempre um dos dois primeiros ou três tópicos mencionados como ponto brilhante no mercado de trabalho, e é muito simples o motivo”, diz John Reed, gerente-executivo sênior da Robert Half nos Estados Unidos. Segundo ele, é porque ela define os rumos da empresa, visto que melhora a produtividade e acelera a realização de melhores decisões de negócios. “Portanto, as empresas estão investindo nisso, e você tem de ter pessoas experientes nessa tarefa”, recomenda.

Para o diretor de TI do Grupo Fleury, Claudio Laudeauzer, quando se fala em habilidades de profissionais de TI no grupo, leva-se muito em conta a paixão pelo que faz, trabalho em equipe, simplicidade de ações, criatividade e visão ampliada.

“Damos preferência a quem possui MBA, porque tem visão focada em business. Além da técnica, teve a oportunidade de trocar ideias e experiências com os colegas”, destaca. “Aqui, a tecnologia não é por tecnologia.”

Laudeauzer diz que, no atual mundo digital, são necessários profissionais antenados com tendências como aplicativos móveis e mídias sociais, que tragam oportunidades para o Fleury. “O mundo está mudando e precisamos fazer o melhor para o cliente e surpreendê-lo.”

O Grupo Fleury planeja fortalecer a equipe em 2013 e conhecimentos em mobilidade e segurança da informação são algumas das exigências. “Mas teremos de treinar esses colaboradores para o novo cenário, contudo, dentro da corporação. Não adianta impor regras, temos de educar”, ensina. E alerta: “Temos de transmitir a paixão pelo trabalho. O ambiente estará seguro com a conscientização.”

Para as contratações no próximo ano, o executivo diz que as competências técnicas vão depender das necessidades internas, mas existe demanda para profissionais especializados em BI, BA, CRM, e tudo o que aprimore o relacionamento com o cliente. “É preciso ter capacidade de transformar dados em informação. Em qualquer tipo de negócio.”

O momento na Spaipa, fabricante e distribuidora Coca-Cola, também é de crescimento. Por isso, há busca por talentos, segundo Claudio Antonio Fontes, Cio da companhia.

“O perfil técnico passa por algumas áreas. Mas recrutamos profissionais especializados em diferentes tecnologias para bancos de dados e ERP, por exemplo. Isso porque a ideia é abrimos o leque para conhecimento em outras plataformas, incluindo sistemas operacionais”, revela.

Fontes destaca que o profissional deve ter formação técnica muito forte e conhecimento profundo nos diversos níveis. “De júnior a sênior, tem de ser bom no escopo que ocupa, compondo as habilidades necessárias para cada uma das funções”, diz.

Inglês e espanhol são requisitos padrão no setor, segundo Fontes. “Alguns colegas já pedem também o alemão”, relata, acrescentando que preferencialmente busca candidatos em polos de formação como universidades federais e estaduais e particulares de maior reconhecimento nacional.

“Estamos de olho no profissional disposto a fazer trabalhos colaborativos. Quanto mais ele estiver preocupado com o outro, nos interessa bastante”, revela, brincando que está à procura dos “arquitetos” de “alguma coisa”. “Virou a palavra da moda.” 

Ele afirma que busca perfis que se alinhem aos projetos eletrônicos da empresa, que envolvem portabilidade ou mobilidade. “Eles têm de ter conhecimento de processos, um mix de analista funcional, com conhecimento técnico e das ferramentas aplicáveis a eles, para facilitar as tomadas de decisão, além de capacidade para gerenciar projetos”, aponta. “E, claro, com visão de negócios.”

Com estratégia diferenciada e de tradição, o Bradesco colhe seus frutos na Fundação Bradesco, sintetiza Aurélio Boni, vice-presidente-executivo de TI do Bradesco. “Nosso sistema de carreira é bem fechado e a fundação forma nossos profissionais.”

Segundo ele, a unidade recebe não somente parentes dos funcionários do banco, mas também reserva uma parte para o público externo. “Lá, é possível começar bem cedo. Meus dois filhos ingressaram na Fundação com quatro anos de idade, formaram-se e tiveram a oportunidade de trabalhar na instituição”, conta.

Boni afirma que o perfil que o Bradesco quer hoje de seus profissionais da área de TI é bastante moderno e reúne habilidades que possibilitem perfeito entendimento e desenvolvimento em um mundo dependente de aplicativos móveis. “Porque essas tecnologias são facilitadoras de atendimento ao cliente. Hoje, são uma exigência”, alerta.

Ele engrossa o coro unânime dos CIOs sobre a visão de negócios, que considera vital no atual cenário. “E isso não se aprende da noite para o dia. Ter conhecimento do negócio facilita a conversa com o gestor, fica mais fácil até mesmo direcionar os projetos”, relata.

Ele revela que com essa habilidade, é possível o gestor endereçar cada tipo de projeto para um profissional específico. “Promove mais segurança ao chefe da equipe, na certeza de que o trabalho será entregue. Gera confiança. É preciso ainda trabalhar em colaboração e, fundamentalmente, ter visão globalizada e muito clara do negócio”, categoriza.

Para Tania Nossa, CIO da Alcoa, atuante na área de minério de ferro, a empresa busca nos profissionais características como pensamento ilimitado, preferência pelo risco, inovação, determinação, capacidade de aprendizado, orientação para mudanças, foco em resultados e entusiasmo pelo trabalho. “E, além disso, saber compartilhar dos valores da Alcoa”, destaca a executiva que também se prepara para os novos desafios que surgirão com a chegada do novo ano e a prática de tudo o que está planejado para acontecer.

Fonte: CIO

A vantagem de um Analista de Negócios para um Arquiteto de Negócios

O deserto entre TI e negócio é o nosso reino. 

Temos que lutar com a semântica linguística e expulsar definições. Começamos como Analistas e podemos avançar para Arquitetos.

Nós não somos estritamente técnicos e não estamos estritamente funcionais. A definição do que fazemos normalmente é escrever em linguagem semi-tech (requisitos). Mas como é que vamos escrever esses requisitos, o que nos torna diferentes? Como podemos ver as coisas e por que vê-las da maneira que nós fazemos? 

Qual é o potencial da profissão de Analista de Negócios? 

O que fazemos para os supervisores, gerentes, diretores e acionistas nos ouvir? 

Como é que vamos passar de Analista de Negócios para Arquiteto de Negócios? 

É o que queremos?

Deixe-me definir a diferença entre um analista e um arquiteto, elas são sutis, mas vou descrever apenas alguns pontos críticos que percebo:

- Um analista de negócios gera relatórios para desenvolvedores ou gerentes de projetos de TI, quando digo relatórios, considero os insumos semi-tech que traduzem as necessidades mandatórias e não-mandatórias de uma solução. O arquiteto de negócios reporta aos gestores ou alta direção insumos que podem ser de negócios ou de TI, mas são independentes do projeto.

- Alguns documentos do analista de negócios são em parte, requisitos definidos e desenvolvidos pelos usuários. Documentos gerados por um arquiteto de negócios podem definir uma estratégia de negócio usando requisitos previstos pelos usuários.

- O analista de negócios opera dentro dos limites de uma arquitetura pré-determinada técnica. Arquiteto de negócios é uma parte do processo de decisão para definir a arquitetura técnica.

Algumas coisas mais:

- Um arquiteto é considerado uma voz neutra e por isso em alguns casos toma decisões mais críticas do que um analista de negócios.

- Um arquiteto deve ter a capacidade de pensar tanto na forma estratégica e táctica enquanto um analista é normalmente tático.

- Um arquiteto deve estar ciente das estratégias empresariais enquanto um analista é normalmente preocupado com projetos específicos independentes da estratégia da organização.

Assim, vemos que cada tipo de "BA" é necessário. 

Agora, como você pode se tornar o melhor BA que pode ser? 

Ou como você passar de analista de arquiteto? 

Acredito que muitos analistas de negócio tem competência técnica e estrutural para assumir esses 2 "papéis", aliás conheço muitos profissionais que tem essa habilidade.

Comentem...

Fonte: http://www.businessanalyst.com/

Product Owner no Scrum: a Alma do Negócio

O trabalho do Product Owner (PO) é possivelmente o menos compreendido e o mais subestimado entre os praticantes mais novos do Scrum. É ele quem transmite uma visão de negócios e prioriza os objetivos de forma a entregar valor. O PO é quem dá a direção e o propósito a um produto, envolvendo a equipe para a criação, desenvolvimento e evolução. Por isso está diretamente ligado ao sucesso (ou não) de um projeto de tecnologia.

Tendo isto em mente, o primeiro grande fator para o sucesso de um Product Owner é a coragem. Pode parecer clichê, mas não há como fugir disso. Como o PO é o responsável por equilibrar os vários interesses sobre determinado projeto, ele pode ficar tentado a atender apenas aos mais bem posicionados na hierarquia da empresa ou àqueles que mais diretamente se relacionam com ele. Sem coragem, o PO pode inconscientemente abrir mão da oportunidade de sucesso, parando de ouvir os clientes finais ou até mesmo idealizando um produto grande demais com resultados inferiores.

O PO e o cliente

Para gerenciar um produto, em particular um software, é preciso entender que mesmo um especialista precisa do feedback do usuário final. É o cliente, e apenas ele, quem poderá validar o que o há de inovador em um sistema. Aquilo que já é conhecido, ou que já foi medido anteriormente, pode até dar certo sem a validação do cliente, mas o que for o diferencial competitivo do seu produto, não. Fica no diferencial, em suas características únicas, o maior potencial de geração de valor; por isso, ouvir o cliente o tempo todo é fundamental.

A sintonia com o cliente é o que permite que o PO consiga capturar e transmitir a direção correta para os outros stakeholders e para a equipe de desenvolvimento. O contato entre a equipe e os stakeholders com o cliente final sempre será limitado, se comparado ao do PO. Por isso, o PO não deve se privar de "estar na rua", falando com seu público-alvo. Para manter essa sintonia viva e constante, precisa orientar a equipe na direção de entregas pequenas e frequentes. O produto deve ser criado de forma incremental e a cada passo as funcionalidades produzidas devem passar por um ciclo de feedback envolvendo os usuários finais. É importante observar que, quanto antes uma funcionalidade estiver em produção, sendo utilizada por usuários verdadeiros, melhor será o produto.

Qualidade relativa e qualidade absoluta

Outro ponto que pode desviar o caminho de sucesso dos gestores de um produto de software é a qualidade. Discussões intermináveis sobre este assunto são frequentes entre a equipe e o PO, com ou sem a participação de outros stakeholders. Tais discussões, além de improdutivas, podem crescer e se transformar em antagonismo, o que as tornam destrutivas para o produto, e também para a união e a motivação dos envolvidos.

O principal motivo de divergência reside em uma sutileza sobre o que é qualidade em um produto de software. Como em qualquer outro produto, qualidade é um conceito relativo. Os padrões de qualidade e os custos de se fazer um novo produto são variados e dependem de fatores como regulamentos, leis e o público-alvo. Para usar um exemplo do dia-a-dia, a qualidade exigida em um carro popular não é a mesma que a de um carro de luxo.

Podemos dizer que o PO entende qualidade como o nível de aceitação de seus clientes enquanto consumidores daquele novo produto. Este tipo de qualidade está, de certa forma, sob o controle do PO, e influencia suas decisões. Muitas vezes, a equipe não entende este parâmetro; apenas quer fazer o seu trabalho bem feito. Na verdade, é comum que a equipe leve em consideração outro tipo de medida: a qualidade no seu ciclo de desenvolvimento. Apenas para citar um exemplo, no caso de uma indústria automobilística, o PO estaria preocupado com a aceitação de determinado veículo pelo público, sendo que a equipe está mais comprometida com a qualidade do fluxo de produção.

Neste caso, ainda que as fábricas (ou unidades de fabricação) dos carros populares e luxuosos também tenham suas diferenças, elas são de fato bem mais parecidas do que a distância que existe entre os dois produtos finais: um carro pode ser desenhado para não dar defeito nunca, enquanto outro, se durar cinco anos, já estará ótimo para o fabricante. Para construir as fábricas destes carros é um pouco diferente, no entanto; ambas, é claro, foram feitas para durar e entregar vários modelos por muitos anos. Em software, não podemos abrir mão da qualidade, já que ela é determinante para a aceitação de um produto.

A qualidade do ciclo de desenvolvimento deve ser vista como absoluta, e é essa qualidade que a equipe luta para manter, enquanto muitas vezes os stakeholders não sabem do que a equipe está falando. A falta de qualidade no ciclo de produção gera um acúmulo de dívida técnica, que funciona como uma dívida de juros altos e compostos, ou seja, quanto mais postergamos o valor da dívida, maior será, e com crescimento exponencial.

A dívida técnica, quando acumulada, diminui a capacidade de mudar de direção e de se adaptar às necessidades dos negócios, que surgem em todo momento. Acaba com a agilidade. Em pouco tempo, a equipe começa a perder a velocidade de desenvolvimento e o tempo de vida útil do sistema se reduz, com crescentes custos de manutenção e evolução e capacidade de inovação seriamente limitada. É do interesse do PO manter a agilidade e a velocidade do seu projeto, então não criar dívida técnica é fundamental para todos.

Portanto, o PO deve conseguir explicar bem se a cada entrega estamos fazendo o carro popular ou o carro de luxo. E a equipe também deve deixar claro se o foco está no carro em si ou na fábrica que faz os carros.

PO, equipe e produto

A tentação de ir além do produto mínimo viável (MVP, na sigla em inglês) deve ser combatida a todo momento. É o óbvio: "o produto mínimo deve ser mínimo". O PO terá mais chance de sucesso se conhecer muito bem os seus clientes e, ao mesmo tempo conhecer muito bem o produto e a equipe responsável pela criação efetiva do software. Ser um PO significa conhecer em detalhes cada funcionalidade do produto que lidera e ser capaz de explicar aos stakeholders o que está acontecendo a qualquer tempo.

Com este entendimento nos detalhes e o feedback constante, o PO ganha embasamento para perceber novos e melhores caminhos, estabelecendo hipóteses que necessitam de um curto ciclo de entrega e feedback. Com uma boa equipe, o PO poderá validar tais inovações de forma rápida e eficaz.

Ao mesmo tempo, é necessário cuidado para não confundir o conhecimento dos detalhes com o microgerenciamento. A equipe de desenvolvimento tem capacidade e conhecimento técnicos para entregar o software pedido, e o PO se beneficia quando evita dizer à equipe como fazer o seu trabalho. O PO, em primeiro lugar, deve falar de negócios! Ele passa para a equipe suas necessidades não em termos técnicos, mas do ponto de vista do cliente, da empresa. Quando o PO permite à equipe com conhecimento técnico tomar as decisões que lhe cabem, não só a solução técnica é melhor; ele também poderá contar com uma equipe muito mais motivada e envolvida com o resultado do projeto. E assim, todos ganham.

Conhecer bem a equipe significa entender do que ela é capaz, especialmente saber traduzir as demandas de negócio para as técnicas e vice-versa . Quanto mais se estabelece este conhecimento mútuo, melhor é a comunicação e o PO se torna mais eficiente para planejar.

Deixe de empurrar funcionalidades

Com isso, chego ao ponto final: o planejamento. Planejar um produto de software é algo realmente complexo. É fundamental para o PO entender que, a partir do seu orçamento, ele não deve acreditar em um plano pré-determinado, com um conjunto de funcionalidades já estabelecidas. Ele gerencia seu orçamento semanalmente, mensalmente. Isso significa que, ao invés de uma lista de funcionalidades, o PO deve entregar objetivos de negócios.

Como e por meio de quais funcionalidades tais objetivos serão alcançados, não é conhecido no início do projeto. É apenas a execução do projeto que poderá responder. A visão prescritiva é o maior inimigo da inovação, de um produto de software e, consequentemente, do PO.

É preciso olhar além da imagem inicial que se tem do papel do PO. Pensar em uma lista de funcionalidades é menor que pensar em uma lista de objetivos. Aprovar uma funcionalidade é menor que o uso do seu cliente e um objetivo de negócio alcançado. Olhando com mais calma, o PO é mais que um papel, é a Alma do Negócio.

Fonte: INFOQ