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

O relacionamento entre os analistas de negócio e desenvolvedores de software.

O problema mais difundido entre as “torres” na grande maioria dos casos está nos braços dos analistas de negócio, conforme estudo realizado pelo Phoenix Chapter of IIBA. Em 90% dos casos, os BA´s (business analysts) não conseguem comprometer os desenvolvedores de software com a real necessidade da área de negócios precisa.

Grandes organizações consideram os  BA´s, como o MAESTRO DA TI, mas o ônus de orquestrar uma área com alto valor agregado e com grandes e competentes elementos envolvidos, considero uma arte, pois lidar com toda a carga de responsabilidade em representar a área de negócios e sintonizar os Desejos x as Necessidades é seu maior desafio, e é aí que pecam os BA´s.

Os desenvolvedores de software com toda a sua expertise técnica tem uma importância ímpar no desenvolvimento das ações, sua competência sistêmica e vivência lógica agregam o devido valor quando a proximidade entre ambos é conquistada. Comparo o desenvolvedor de software ao violinista e a área de negócios à plateia, enquanto o BA ao elemento que transforma a música em arte, apenas colhendo de ambos os lados o melhor de cada um.

Segundo consultores do Phoenix Chapter of IIBA os BA´s são construtores naturais de relacionamentos. As partes interessadas no negócio tendem a valorizar suas contribuições e procuram envolvê-las nos projetos. Mas quando chega o momento de defender seu "direito" a um papel no projeto, em alguns casos os próprios membros da equipe questionam o valor que trazem à mesa.

Tudo isso me fez pensar sobre a relação dos BA´s versus desenvolvedores de software e como podemos melhorá-la. Embora gostaríamos de pensar (ou esperar) que os cuidados de desenvolvedores de software sobre a linha de fundo da organização, fosse olhar as coisas sob a perspectiva de como poderia ser melhor o contato com a área de negócios... Acrescento: Proximidade e bom relacionamento, integrando conteúdo e olhando sempre para o maior objetivo (que não são os das áreas e sim o da organização).  O de considerar que a TI é apenas um provedor de serviços, um grande fornecedor de soluções, esse sim deve ser o real sentimento comum entre de desenvolvedores e analistas de negócios.

Agora, segue o desafio:

Se eu fosse um desenvolvedor, por que eu me importaria?

Se eu fosse um analista de negócios, como eu me comportaria?

Se eu fosse da área de negócios, o que eu esperaria?

Se nós, como BA´s pudéssemos ajudar a reduzir o retrabalho, que, sem dúvida, deve ser feito, pergunto: Como mudar o sentimento da maioria dos desenvolvedores que somente é motivado por "horas trabalhadas", ou seja, dispender seu tempo em escrever e reescrever códigos, e quanto mais seu tempo é gasto no mesmo pedaço de código, menos intelectualmente interessante fica o trabalho.

Com isso, os pedidos de mudança sempre significam um cronograma de projeto ampliado, que mais frequentemente significam também horas extras de desenvolvimento, em suma o maior fator motivador dessa classe: Horas trabalhadas multiplicadas por X reais, resultando em FATURAMENTO.

Eu nunca conheci um desenvolvedor que gostava de participar de reuniões e de se integrar, muitas vezes ele está lá, envolvido em proporcionar um pouco de entrada na direção, mas realmente esperando a resposta exata de que necessitam para que possa construir a solução.

Naturalmente seu foco é perdido, e aí que mora o risco (o escopo desse post), pois exatamente nesse momento é que o MAESTRO DA TI, deve trazer a responsabilidade do momento e promover a sintonia do solicitante e do solicitado.

Como você planeja seu levantamento e processo de análise de requisitos? Você acha que um desenvolvedor de software, deve participar dessa ação? Outra pergunta a fazer é: você precisa de um desenvolvedor em uma reunião de kickoff de projeto?

Por fim, como numa orquestra o MAESTRO depende de seus músicos, esses que dependem de seus instrumentos e sua plateia, e essa que vê no MAESTRO o condutor da sinfonia, é como encaro o departamento de TI.

Deixo no ar, duas perguntas:

Você como analista de negócios, já enfrentou desafios semelhantes em ser respeitado como esse MAESTRO dentro de sua própria organização de TI?

Você como MAESTRO DA TI, já comunicou o valor de uma área de análise de negócios para um desenvolvedor de software?

Dedico este post em homenagem ao meu amigo Paulinho.

Fonte: http://www.infoq.com/

O que é Análise de Negócios?

Vídeo explica de forma simples e lúdica o que é a análise de negócios. 

Publicado por Fabrício Laguna, da Gigante consultoria.