Vai estudar meu filho!

Depois de um longo período sem posts, lá vai um post leve. Me certifiquei em ITIL V3 Foundation e gostaria de compartilhar a experiência. Já faz algum tempo que me interessei por ITIL, seu conteúdo, processos, termos e conceitos. Ao começar a trabalhar em uma empresa onde existem áreas buscando aplicar cada dia mais esses conceitos, conhecer esse conjunto de boas práticas se tornou uma necessidade para mim.

Plano de estudos: o livro oficial de introdução possui conteúdo mais do que o necessário para estudar para o certificado. Li o material apenas uma vez fazendo um resumo e revisei esse resumo. Para facilitar o estudo assisti algumas aulas em um curso online e fiz alguns simulados, em torno de uns 7.

A prova foi tranquila, em geral as questões foram a respeito das definições dos termos. O tempo é suficiente para fazer a prova e revisar tudo sem pressa.

Espero que esse post possa ajudar alguém. Boa sorte para quem for fazer a prova.

Sourcing + Comunidade = Crowdsourcing

Novamente lendo alguns textos sobre ITIL me deparei com a descrição dos tipos de fornecimento de serviços. Logo, se você tem um trabalho para ser feito, é necessária a decisão de qual a melhor estratégia para realizar esse trabalho. Essas opções apresentam vantagens e desvantagens, algumas descritas no livro Service Design são:

Insourcing: Utiliza os recursos internos da organização.

Outsourcing: Utiliza os recursos de outra empresa através de um acordo formal (contrato).

Co-sourcing: Combinação da utilização de recursos internos e externos.

Multi-sourcing: As atividades são dividas entre várias organizações (parcerias).

Business Process Outsourcing (BPO): O fornecedor gerencia por completo processos de negócio.

Application Service Provision (ASP): Fornece serviços compartilhados, como infra-estrutura por exemplo.

Knowledge Process Outsourcing (KPO): É a evolução do BPO, onde o fornecedor conta com competências de alto nível, para interpretação de dados para a tomada de decisão.

Existe uma opção não listada aqui, considerada por alguns, que é o Crowdsourcing, envolvendo vários recursos, muitas vezes voluntários, as pessoas participam porque gostam e dedicam seu tempo livre para isso. Um bom exemplo são as comunidades open source, que resultaram em produtos como o Linux.

A utilização dessa forma de recurso não é simples, e tem desvantagens como tornar muitas informações púbilicas e não ter o controle da entrega sem um time interno, por outro lado, o custo é baixo e se tira proveito da inteligência coletiva. Uma variedade maior de soluções são propostas e os testes são executados em ambientes diferentes.

Essa forma de trabalho é considerada por muitos como não aplicavel ao ambiente corporativo. Porém, muitas grandes empresas investem em comunidades como apoio ao desenvolvimento dos seus produtos. Alguns poucos já fizeram fortunas baseadas nos produtos do trabalho de milhares de anônimos espalhados na internet, e muitas dessas pessoas continuam contribuindo por considerar que os beneficios que o produto traz para si é recompensador. Há alguns que acreditam que essa é uma das formas de aproveitar melhor os conhecimentos da humanidade que sempre foram extremamente dispersos.

Do bit ao dinheiro

Bom, talvez eu esteja “chovendo no molhado” mas, mesmo assim, queria comentar sobre um aspecto da dicotomia entre a vida acadêmica e a profissional. Quando estamos na graduação, somos doutrinados a ter um pensamento técnico, buscamos nos tornar especialistas em tecnologia, seja ela qual for. Isto fica bem claro quando conversamos com estudantes e recém-formados. Porém, esse tipo de pensamento não serve para os cargos de decisão.

Com o tempo esses profissionais se tornam executivos de TI, sendo que muitos deles tendem a se focar no know-how, assim como aprenderam, e se esquecem que no ambiente corporativo é importante conhecer bem o modelo de negócio da empresa para se concentrar no know-why.

Imagine uma reunião de diretoria onde são apresentadas propostas sobre a expansão da empresa, a necessidade de redução de custos, aumento das vendas e outras. Obviamente que para apoiar essas estratégias é solicitado a participação da área de TI que, rapidamente com sua forma de pensamento equivocado, surge com vários “planos bem elaborados” para converter todos os sistemas para SOA, incluir mais relatórios, implantar governança baseada em ITIL e Cobit, migrar sistemas para as tecnologias atuais, virtualizar máquinas do datacenter ou implantar outra tendência atual. Será que esses planos estão realmente alinhados com as necessidades do negócio?

Em geral tais planos devem passar por aprovação e é ai que acontece o inverso, executivos que por sua vez não têm conhecimento em TI aceitam as idéias sem criticá-las, ou seja, ambas as partes erram, a primeira por não pensar nos resultados reais para o negócio e a segunda por não exigir argumentos claros sem o costumeiro "tecniquês". Isto acontece muitas vezes de maneira silenciosa nas empresas, faltou o tão comentado “alinhamento entre TI e negócio”, desta vez por ausência de competência dos gestores de TI que não perceberam que o conhecimento técnico que possuem deve guiar as decisões ao invés de ser o foco delas.

As conseqüências disso são projetos fracassados, baixos resultados, investimentos literalmente jogados fora. Esse é um dos motivos pelo qual a TI continua ocupando o lugar da “área de serviço”, quando poderia ser a “vitrine” das empresas.

Utilidade X Garantia, simples?

Estava lendo um material sobre ITIL e me deparei com um conceito relativamente simples:

Utilidade (Utility): É o que o cliente precisa, caracteriza o que o serviço faz.

Garantia (Warranty): É como o cliente precisa, caracteriza como o serviço é entregue (entenda entrega como o serviço em produção).

Na prática também parece simples, a “Utilidade” é descrita pelos requisitos funcionais e a “Garantia” é descrita pelos requisitos não-funcionais.

No entanto é ai que começam alguns dos problemas. Em geral, os requisitos não-funcionais (usabilidade, confiabilidade, desempenho e suportabilidade) são descritos de forma incompleta e nesse “deslize” as promessas feitas para o cliente e para si mesmo dizendo que, dessa vez, nesse novo projeto, “tudo vai ser diferente”, devem tomar mais tempo para acontecer.

Existem desculpas para os requisitos mal escritos. Um argumento padrão é aquele “Não há como ter uma boa estimativa de carga”, mas e quanto a estimativa de capacidade do sistema? Que tipo de profissional não conhece o resultado do seu trabalho!?

Como um sistema pode ser entregue sem ao menos um conjunto de testes de confiabilidade e desempenho? Isso parece um absurdo mas é a realidade em muitas empresas no Brasil. Depois de pronto, o sistema é implantado e aos poucos os problemas surgem. O diagnóstico em produção é mais dificil do que no ambiente de testes e, em muitos casos, o cliente paga para arrumar o que ele já pagou para não estar “quebrado”.

O conceito “tão simples” do efeito da combinação de Utilidade e Garantia exige bem mais trabalho do que parece para ser posto em prática. A habilidade de entrega de um serviço com determinado nível de garantia é realmente um grande diferencial competitivo.

Links:

• http://www.baguete.com.br/blogs/post.php?id=3,246
• http://itilblues.wordpress.com/2007/12/14/itil-v3-utility-and-warranty-two-sides-of-the-same-coin/

ITIL - O que vou dizer lá em casa?

Como estou estudando para a certificação ITIL V3, um amigo me recomendou um blog chamado ITIL Blues para esclarecimento de dúvidas e curiosidades. Lá encontrei um post entitulado “Seven “ITIL is not” statements” que lista sete coisas que o ITIL não é. Veja o post original em inglês aqui e a tradução abaixo:

1. Não é tecnologia – É gerenciamento de serviço de TI.

2. Não é a palavra final – É uma referência, um bom começo.

3. Não ensina como fazer nada – É um norte sobre o que fazer.

4. Não é uma ferramenta – São responsabilidades, atividades, resultados… que precisam de ferramentas.

5. Não é instantâneo – É gradual (para humanos!).

6. Não é mágica – Apenas re-uso de senso comum.

7. Não é pacífico – Sempre aponta para mudanças organizacionais.

Esta lista me serviu para esclarecer o que era ITIL para pessoas que nunca tinham ouvido falar nisso e para aqueles que ouviram e entenderam errado. Como quando somos crianças e aprendemos o conceito de certo ouvindo nossos pais nos dizerem de forma incansável a palavra "não". E não é que funciona? :)

Referência: http://itilblues.wordpress.com/

Termos que se repetem - DSL

É engraçado como alguns nomes e termos se repetem em computação e, o mais engraçado ainda, são as conversas de profissionais das diferentes áreas da TI. Imagine uma conversa de um Arquiteto de Soluções, um Especialista de Telecom e um Analista de Suporte, durante a conversa, sem o contexto necessário, alguém cita a sigla DSL. O que será que vem no primeiro momento na cabeça de cada um? Temos as seguintes opções:

1. Domain Specific Language: É uma linguagem que tem um foco em um domínio específico, diferente de linguagens de propósito geral, como o Java, elas buscam facilitar o desenvolvimento de algum aspecto no sistema. Alguns dos exemplos mais comuns são: SQL, CSS.
   
   
2. Digital Subscriber Line: É um conjunto de tecnologias baseadas na rede de telefonia convencional para transmissão digital de dados em uma faixa diferente da voz.
   
   
3. Definitive Software Library: Definido dentro do ITIL como uma biblioteca para o armazenamento das versões definitivas e autorizadas de todos os itens de configuração. Foi substituído pelo termo DML (Definitive Media Library) no ITIL V3.
   

Provavelmente, se você está familiarizado com o termo, deve ter pensado em alguma dessas coisas, ou será que você pensou em algo bem diferente como “Dynamic Silverlight”?