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.

Disciplina X Metodologia

É engraçado como em computação as pessoas se preocupam em usar os nomes corretos. Mesmo assim, alguns nomes são trocados o tempo todo. Um exemplo clássico é o de Disciplina e Metodologia que conceitualmente possuem o seguinte significado:

Disciplina: É como uma estrutura que fornece orientação, permite a análise mesmo para itens não previstos. (O que fazer).

Metodologia: Fornece direções especificas para lidar com situações conhecidas, consiste em um conjunto de métodos, sendo um método a abordagem passo a passo para realizar tarefas. (Como fazer).

Parecem coisas como água e óleo, mas funcionam muito bem quando combinadas, um exemplo, é o próprio RUP (Rational Unified Process) que é uma metodologia divida em disciplinas, ou seja, em níveis superiores é fornecido a forma de fazer e em níveis mais detalhados é uma orientação do que fazer.

As pessoas aprendem esses termos de diversas formas e utilizam como bem entendem, eu nem sei dizer se a descrição feita acima é a mais utilizada. Agora o que fica estranho é durante uma conversa você ouvir a mesma palavra com 4 ou 5 significados diferentes vindos da mesma pessoa. Eu acredito que em conversas técnicas o ideal seria procurar manter a semântica, pois esse é o propósito do uso de conceitos. Não é mais complicado quando é necesssário explicar o que você está tentando dizer?

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/

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”?