Blog do Samuel Diniz

De quem é a responsabilidade pelos buracos nas pistas de Brasília?

2012-01-11T15:51:00.000-02:00

A pergunta que não quer calar é: De quem é a responsabilidade pelos buracos nas rodovias de Brasília?

Não é fácil responder a essa pergunta. É do GDF? Das administrações regionais? Do DER-DF? Da Novacap? Da Terracap? E talvez a lista de suspeitos não pare por aí. Após pesquisar nos sites dessas instituições e com base também em algumas reportagens divulgadas pelo Correio Braziliense, podemos chegar à conclusão de que a responsabilidade é do DER-DF, no que diz respeito às vias de ligação (entre cidades satélites e dessas para o Plano Piloto, e das administrações regionais, no que diz respeito às vias internas de cada região. A Novacap e a Terracap entrariam nessa ceara apenas como executoras das obras. Em outras palavras, o DER-DF e as administrações regionais, que são responsáveis, fazem parcerias com a Novacap e a Terracap para executar as operações de conservação.

Todas essas operações chamadas "tapa buracos", como o próprio nome indica, são apenas paliativos. O problema aqui no DF (e talvez em outros lugares) é a má qualidade do asfalto (apesar de todos os especialistas dizerem o contrário), o péssimo escoamento das águas pluviais e, por fim, a má conservação.

Se você, cidadão, acha que não pode fazer nada, engana-se. O cidadão tem uma arma a seu favor: A ação civil pública. Como, então, proceder? Aqui vão alguns passos:

Protocole um requerimento no órgão responsável (administração regional ou DER-DF, conforme o caso) pedindo resposta e providências. Segundo a Lei do Processo Administrativo, a autoridade tem o prazo de 5 dias para tomar uma atitude. No caso, a autoridade será o administrador regional ou o Diretor Geral do DER-DF que, no momento da escrita deste artigo, segundo informações do próprio site oficial, é o Sr. Fauzi Nacfur Júnior (fone 3342 2101).
Se nesse prazo a autoridade não fizer nada, procure o órgão e peça uma cópia do processo. Pela lei, eles tem o dever de lhe fornecer (art. 3º, inc. II).
De posse do processo, vá até a Procuradoria Distrital dos Direitos do Cidadão e denuncie a omissão da autoridade ao Ministério Público do DF (endereço: Eixo Monumental, Praça do Buriti, Lote 02, Ed. Sede do MPDFT, 8º andar, salas 830/831; telefone: 3343-9656; fax: 3343-1021; e-mail: cidadao@mpdft.gov.br). Segundo a Lei da Ação Civil Pública, qualquer cidadão pode levar ao ministério público uma denúncia envolvendo interesse difuso. Com um pouco de sorte, o MPDFT vai dar início a um inquérito civil, para colher elementos que podem depois constituir objeto da ação civil pública.

Quem sabe quando esses administradores começarem a responder processos eles vão se tocar que o cargo não é só sentar na cadeira e receber o salário no fim do mês.

Vinho: Las Perdices - Bonarda 2008 - Luján de Cuyo - Mendoza

2011-12-11T14:28:00.001-02:00

A garrafa traz indicativos de ser um vinho de guarda, com embalagem em chumbo, rolha de cortiça e fundo bastante côncavo. O rótulo indica uma série limitada a 10 mil garrafas. A retirada da rolha revela aromas de um vinho intenso e complexo. A análise visual confirma isso, mostrando uma coloração bastante escura e líquido encorpado, exibindo a sua cor até nas lágrimas. A rápida passagem pelo barril de carvalho (imagino que no máximo 6 meses) suficiente apenas para amaciar um pouco os taninos, propicia um vinho bastante frutado para um tinto, com pouca madeira. Depois da uva, destacam-se as notas de amora, pimenta preta e chocolate (lembrando um pouquinho café e caramelo menos ainda). As notas de couro, muito comuns em vinhos tintos argentinos e brasileiros com nenhuma ou rápida passagem pelo carvalho, só se mostraram timidamente. A bonarda argentina me lembrou muito uma mistura de merlot e malbec, porém com taninos mais acentuados. No início se mostrou de baixa acidez, mas já a partir da terceira taça essa se revelou melhor, aparecendo um vinho muito agradável e sutilmente refrescante. Seus taninos são fortes, harmonizando bem com pratos mais gordurosos, como carne. Por ter se mostrado um vinho bem intenso, acredito que suporte uma guarda de uns 5 anos se bem armazenado. Retrogosto prolongado. Conclusão: Recomendo! Site oficial.

Amazon Kindle: Prós e contras, muitos contras!

2011-10-11T15:23:00.000-03:00

Recentemente adquiri um Amazon Kindle. Trata-se do antigo Kindle de 6" Wi-Fi + 3G. A Amazon atualmente chama ele de Kindle Keyboard 3G. Desde o lançamento do primeiro kindle tinha vontade de adquirir um. Mas como nunca precisei, fui adiando a compra. O produto e os serviços por trás dele foram amadurecendo ao longo do tempo até que finalmente decidi concretizar a compra. Entretanto, passada a euforia inicial, eis que me encontro muito decepcionado. Não me arrependo de ter comprado. Pelo preço que paguei, U$140,00, nenhum outro produto chegaria perto. Mas confesso que esperava mais. Se você está pensando em comprar um, sugiro continuar lendo esse artigo.

Vantagens

Vou começar pelo lado positivo. A tela do Kindle é sensacional. A tal da tinta eletrônica é realmente fantástica. Ler no Kindle não é cansativo como ler no computador. E a tela de 6" dá conta do recado. Parece pequena, mas é possível aproveitar bem o espaço e exibir bastante informação. Apesar de ser monocromática, imagens e fotografias são exibidas com boa definição utilizando os muitos tons de cinza. A interface é limpa e favorece a leitura dos textos. O dicionário também é excelente. Basta posicionar o cursor na palavra desejada e a definição aparece imediatamente. A conexão 3G funcionou perfeitamente aqui no Brasil. Ainda não percebi problemas de cobertura. A bateria é bem dimensionada. Vale destacar também o serviço de conversão de arquivos. Basta enviar o arquivo para o e-mail do seu dispositivo e após alguns minutos a Amazon envia automaticamente o arquivo já convertido para o seu Kindle. É possível até compactar diversos arquivos em um ZIP e enviá-los de uma só vez para conversão em lote. A leitura de textos, apesar de só funcionar em inglês, também surpreendeu pela qualidade.

Desvantagens

Não sei por onde começar. Vamos às mais críticas. O leitor de PDFs é medíocre! O Kindle não aproveita bem o espaço da tela, exibindo a página inteira do documento inclusive as margens brancas. A Amazon podeia ter incorporado um algoritmo de crop das áreas mortas. Em alguns casos, a leitura do texto fica impossível devido ao tamanho muito pequeno da fonte. Nem pense em utilizar o zoom que a usabilidade é péssima. Alterar para o modo paisagem também não resolve muito e ainda compromete o uso do teclado. A solução acaba sendo utilizar programas como o Briss para fazer o crop do documento, ou converter o PDF para MOBI -- mas isso estraga a formatação do texto.

Outro grave problema é a forma como as coleções foram implementadas. Coleções são como pastas que servem para organizar seus documentos. O problema é que quando você conecta seu Kindle ao computador tudo que se vê é uma pasta com todos os documentos. O Kindle não trata as coleções como pastas. E como a Amazon não disponibiliza um aplicativo para gerenciar seu Kindle pelo computador, fica difícil organizar seus documentos em coleções. Ao copiar um grupo de documentos para a memória do Kindle, todos eles vão direto para a home do sistema. E é preciso ir movendo os arquivos um a um para as coleções, o que dá muito trabalho.

Também não gostei do teclado, nem das posições das teclas de paginação. O teclado fica devendo a impressão dos números acima da primeira linha de teclas. Já as teclas de paginação estão mal posicionadas, provocando uso não intencional. Elas podiam estar acima, pois geralmente pegamos o dispositivo pelo meio, justamente onde elas estão.

Por fim, vai uma crítica ao marketing da Amazon. Na home do dispositivo, às vezes aparecem alguns anúncios. Ocorre que ao invés de o dispositivo te redirecionar para a loja, simplesmente é exibida uma mensagem dizendo que um e-mail foi enviado para você com o conteúdo da oferta. Ridículo! Acho que a Amazon não quer vender os produtos anuncionados.

Conclusão

A Amazon podia muito bem disponibilizar uma atualização de software para resolver esses problemas. Um aplicativo para gerenciamento também não ia fazer mal. Até a exibição dos números poderia ser resolvida com um adesivo, pois há espaço para tal. A única coisa que não dá para resolver é a questão dos botões de paginação. O jeito é se acostumar mesmo e evitar pegar o Kindle pelo meio.

Crise no Judiciário: Não se engane, ela pode afetar você!

2011-09-30T10:01:00.000-03:00

Ao contrário do que algumas pessoas ingênuas acreditam, o criminoso sempre está em vantagem. Mesmo em menor número, eles superam em muito a grande maioria de pessoas honestas. Um criminoso sozinho mas com uma arma na mão é capaz de prejudicar um sem número de pessoas. E isso vale também para os criminosos no poder. A arma deles é a posição de autoridade que eles ocupam.

Digo isso porque estamos acompanhando nos noticiários uma verdadeira crise no judiciário. E não se engane, esses problemas afetam a todos nós. Uma meia dúzia de desembargadores criminosos já é suficiente para acabar de vez com o judiciário. Imagine então se houverem 35 deles! É isso que o CNJ está indo a público dizer. Sem o CNJ, nada vai ser feito. O corporativismo impede que as corregedorias regionais sejam efetivas. Até porque alguns presidentes de tribunais podem estar envolvidos nos crimes investigados.

Ocorre que por causa de uma interpretação equivocada da lei, que perpetua o corporativismo, o STF está prestes a cortar as mãos do CNJ. A Min. Eliana Calmon, corregedora do CNJ, vai a público justamente para alertar a sociedade sobre isso. Se esses aparentemente poucos magistrados criminosos não forem combatidos, o judiciário vai sim se render à corrupção. Aí, adeus justiça no Brasil.

TI: O coração de cada empresa

2011-09-30T05:00:00.000-03:00

Em um artigo anterior, defendi a importância das organizações considerarem a área de TI como sendo estratégica e as implicações disso. Gostaria de trazer agora mais argumentos que deixam claro que a TI hoje é imprescindível para praticamente toda empresa.

As organizações são frequentemente comparadas a organismos vivos. Em um organizmo vivo, os órgãos trabalham em conjunto para a sobrevivência do ser. Entretanto, alguns órgãos são mais importantes do que outros. Pense no corpo humano, por exemplo. Pode-se abrir mão do baço, mas o mesmo não pode ser feito com o coração. Outro elemento vital para o corpo humano é o sangue. Nas organizações, podemos dizer que o sangue que corre em suas veias é informação. Sem um fluxo constante de informação a empresa morre.

Nos dias de hoje, quem é responsável por manter esse fluxo de informação? No corpo humano é o coração. Nas organizações é a tecnologia. Seja por meio de uma rede de dados, seja por meio da página impressa, lá está a tecnologia. Chegamos à conclusão de que o coração de uma empresa é a área de tecnologia. É ou não um órgão vital?

Gestão de Riscos de TI segundo a NBR 27005 - Parte 1

2011-09-29T05:00:00.000-03:00

É incrível como os especialistas gostam de complicar aquilo que é simples. Será medo de compartilhar o seu conhecimento e perder o emprego? Ou será que na verdade eles não entendem plenamente o assunto? Quem sabe apenas falta de didática? Seja qual for o motivo, o mundo está precisando de pessoas com a capacidade de simplificar as coisas, não de complicar. E isso vale também para a interpretação de normas e melhores práticas. A NBR 27005 é um bom exemplo disso!

Falar da NBR 27005 é falar de processo. Isso porque a 27005 oferece um modelo para o processo de gestão de riscos de TI. Mas o que é um processo? O conceito de processo é a coisa mais simples do mundo. Trata-se de uma sequência de ações dependentes entre si que devem ser executadas para alcançar um objetivo. No caso da gestão de riscos, o objetivo é reduzir o risco da organização. Cada ação faz uma parte do trabalho e entrega a sua parte para a ação seguinte (Figura 1). Assim, podemos dizer que uma ação recebe entradas, ou insumos, e transforma essas entradas por meio de algum trabalho gerando as saídas (Figura 2). Essas saídas, por sua vez, serão entradas na ação seguinte e assim por diante até que o objetivo final seja alcançado. Vale ressaltar que algumas ações podem ser executadas em paralelo e outras não. Além disso, os processos em geral não são estanques. Isso significa que para alcançar um dado objetivo, pode ser necessário repetir o processo diversas vezes. Quando isso ocorre, dizemos que o processo é cíclico. Processos cíclicos são muito comuns quando se busca o que chamamos de melhoria contínua.

Figura 1

Figura 2

Esse é justamente o caso do processo de gestão de riscos. Trata-se de um processo cíclico cujo objetivo é reduzir gradativamente o risco da organização e, por meio de sucessivas repetições na execução das ações, também manter esse risco dentro dos limites aceitáveis. Quem vai definir esses limites? Depende. No caso de instituições financeiras, por exemplo, esses limites são definidos por lei. No caso da iniciativa privada, esses limites variam conforme os objetivos definidos pela administração da empresa, as expectativas dos clientes e a concorrência.

É preciso dizer também que existem diversos modelos de processo para gestão de riscos. A NBR 27005 é apenas um desses modelos. Mas como o próprio nome indica, é apenas um modelo, não uma verdade absoluta. Esse modelo pode e precisa ser adaptado à realidade da sua organização. Falando claramente, é pouco provável que você seja bem sucedido se tentar seguir à risca tudo que é recomendado pela norma.

Considerando o acima, podemos agora entrar no processo de gestão de riscos propriamente dito. Porém, para entendermos claramente o que está envolvido, vamos falar mais sobre gestão e depois sobre risco. Precisamos ter esses conceitos bem claros na nossa mente, pois deles depende todo o processo(continua em um artigo futuro).

Faça compras na Internet com segurança

2011-09-06T13:17:00.000-03:00

Fazer compras na Internet está se tornando cada vez mais comum. As lojas e mercados na Internet têm atraído mais e mais usuários não só por causa dos preços baixos, mas também pela facilidade e conveniência. A grande vantagem de comprar pela Internet é a possibilidade de pesquisar sobre um produto em dezenas de lojas e mercados em alguns poucos minutos e sem sair de casa. E você ainda evita gastar combustível, pegar trânsito, se estressar com estacionamento e outras coisas mais.

É claro que nem tudo são flores. Pela Internet, você não pode ver o produto de perto, pegar nele, enfim, ter certeza que é aquilo mesmo que você procura. Mas muitas lojas na Internet já perceberam esse problema e agora oferecem recursos para suprir essa necessidade pelo menos em parte. Imagens melhores, visualizações interativas em 3D, avaliações de clientes, descrições detalhadas, são formas de ajudar os clientes na hora de decidir comprar ou não um produto.

Apesar de todas essas vantagens, algumas pessoas ainda têm receio de comprar na Internet. Muitas ficam preocupadas se de fato receberão o produto. Outros talvez fiquem desconfiados em fornecer dados pessoais e números de cartão de crédito. Se você está preocupado com essas coisas, este artigo é para você! Vamos ver agora algumas dicas para fazer compras na Internet com mais segurança.

O essencial

Quando o assunto é comprar pela Internet com segurança, quatro aspectos são essenciais: (1) a segurança do seu computar, (2) a conexão que você está usando, (3) a escolha da loja ou vendedor e (4) os procedimentos de pagamento. Existem outros aspectos a se considerar, mas esses quatros são essenciais em minha opinião. Vamos falar mais um pouquinho sobre cada um deles.

Proteger o seu computar é o primeiro passo para fazer compras na Internet com segurança. Se o seu computador estiver contaminado com algum vírus ou outra ameaça, os seus dados pessoais, inclusive do cartão de crédito, podem parar nas mãos de criminosos. Para evitar que isso ocorra, certifique-se que o seu computador possui antivírus e que ele está sempre atualizado. Outra medida importante é instalar as atualizações de segurança do seu sistema operacional e do navegador Internet – isso geralmente é automático. Além disso, verifique se o seu computador já tem um programa de firewall pessoal – alguns sistemas operacionais já incluem um programa assim. Um firewall pessoal basicamente protege o seu computador de conexões não autorizadas, dificultando o vazamento de dados pessoais através de programas maliciosos.

Outro aspecto tem a ver com a conexão com a Internet que você está utilizando. Ela vai indicar se os seus dados pessoais estarão vulneráveis a terceiros. Para ilustrar, imagine que você esteja abastecendo o carro em um posto de gasolina. Se no momento de digitar a senha do cartão alguém estiver do seu lado, a sua senha pode parar em mãos erradas. Similarmente, se na hora de comprar você utilizar uma conexão não segura, os seus dados pessoais podem parar na mão de alguém que esteja “olhando” essa conexão. Assim, é essencial evitar fazer compras na Internet utilizando conexões públicas, tais como aquelas disponíveis em cafés, restaurantes, shoppings e aeroportos. Se estiver em casa utilizando a sua rede sem fio, verifique se a conexão está configurada para utilizar criptografia.

A escolha da loja ou vendedor é outro aspecto crucial. Você compraria um celular de um vendedor ambulante que você por acaso encontrou na rua? Imagino que não. Da mesma forma, não podemos comprar de qualquer vendedor ou loja que aparece na Internet. A escolha da loja ou do vendedor vai determinar a nossa confiança em relação a quatro coisas: (1) a qualidade do produto, (2) o compromisso com a entrega, (3) a forma como os seus dados pessoais serão tratados e (4) a forma como eventuais problemas serão resolvidos. Assim, prefira comprar em sites conhecidos e com boa reputação. Alguns sites de pesquisa de preços, como o Buscapé, informam a reputação da loja. No caso dos mercados virtuais, como o MercadoLivre, também é possível verificar a reputação de cada vendedor. É possível também verificar a reputação de sites por meio de buscas no Google. Pesquisas usando o “nome da loja/vendedor” seguido de termos como “problema” ou “reclamação” podem auxiliar na investigação. O site ReclameAqui também fornece uma classificação da reputação de alguns sites e até de lojas físicas.

Por último, mas não menos essencial, existe a questão sobre qual procedimento de pagamento é mais seguro. A regra é simples: quanto menos dados você precisar informar, melhor. Evite digitar informações de cartão de crédito em formulários na própria página da loja. Digitar essas informações é perigoso porque você não tem como saber como aqueles dados serão guardados e utilizados. Nessas situações, é melhor optar pelo boleto bancário. Algumas lojas até dão descontos para esse tipo de pagamento. E se você prefere utilizar o cartão de crédito, dê preferência a sites que redirecionam o pagamento para uma página do seu banco ou da operadora do seu cartão. Alguns sites, por exemplo, após a confirmação da compra, redirecionam os usuários para uma página da própria Visa ou Mastercard. Utilizar os chamados concentradores de pagamento, como o PayPal, PagSeguro e MercadoPago, também é mais seguro do que fornecer dados para uma loja qualquer na Internet.

Evitando problemas com o cartão de crédito

Como já foi dito, é interessante minimizar ao máximo a divulgação dos seus dados de cartão de crédito. Fazer isso já vai te poupar muita dor de cabeça. Mas se você precisou fornecer os dados do seu cartão de crédito para alguma loja na Internet, é interessante trocar o número do cartão. Simplesmente destrua o seu cartão e peça um novo para a sua operadora. Se você compra na Internet com frequência, recomendo fazer isso semestralmente. Consulte a sua operadora sobre a cobrança de taxas e prazos para a emissão de um novo cartão. O custo de um novo cartão não é quase nada comparado com a dor de cabeça que você pode ter se seus dados pararem em mãos erradas.

E se você não costuma utilizar o seu cartão de crédito em lojas do exterior, recomenda-se desabilitar a utilização internacional do cartão. Isso é feito por meio da operadora. Após habilitá-la, desabilite novamente assim que efetivar uma dada compra.

Prepare-se para resolver conflitos

A vida na Internet não é perfeita, e conflitos podem surgir. Talvez você receba um produto diferente do que escolheu. Pode acontecer também de você ter se baseado em alguma informação errada e comprar algo que na verdade não é o que você procurava. Para se resguardar, é importante ter uma cópia de todas as informações disponíveis no site da loja. Mas não pense que imprimir a página vai adiantar muita coisa. A página impressa, nesses casos, não serve de prova (esse entendimento reforma o que publiquei em um artigo anterior). Se a compra foi pela Internet, de forma eletrônica, a prova também precisa ser eletrônica. Assim, ao invés de imprimir a página do produto, salve a página no seu computador. Na maioria dos navegadores você pode fazer isso clicando em Arquivo > Salvar como. Outra opção é fazer uma ata notarial em cartório, mas este é um procedimento trabalhoso e dispendioso.

Conclusão

Comprar na Internet não é um mar de rosas, mas com alguns cuidados é possível aproveitar muitas ofertas. Essas preocupações com segurança podem parecer algo muito difícil, porém com o tempo elas vão passar a fazer parte do seu dia a dia. Cuide bem dos seus dados pessoais e saiba escolher onde comprar. No mais, deixe a tecnologia atuar a seu favor. E boas compras!

Servidor público: Marajá ou guardião?

2011-08-10T14:15:00.005-03:00

Você acha que os servidores públicos são marajás?

Falar mal dos servidores públicos virou mania entre jornalistas do Brasil inteiro (e quem sabe no resto do mundo também). Criticam-se reajustes de salário e até novas contratações. Não é a toa que a opinião pública está sempre contra esses trabalhadores. E não estou me referindo a todos os servidores públicos, mas apenas àqueles que fizeram concurso público. É bem provável que você, caro leitor, tenha uma opinião ou atitude negativa com relação a essas pessoas. Mas antes de sair por aí como que apedrejando os servidores públicos, talvez seja interessante considerar alguns aspectos.

Primeiro, nem todas as pessoas que estão no serviço público são servidores concursados. Existem também os presidentes, ministros, deputados, prefeitos e assim por diante. Para fins didáticos, vamos chamar a todos esses de políticos. O fato é que esses políticos exercem forte influência sobre a forma como o dinheiro público é gasto. E infelizmente nem sempre esse dinheiro é utilizado nos melhores interesses da população. E isso ocorre por basicamente dois motivos: incompetência e má fé. Entenda que não sou eu quem está dizendo isso. A própria estrutura do governo admite a existência dessas características, do contrário não haveria órgãos de fiscalização nem a divisão dos poderes seria necessária.

Bom, adimitindo a existência da incompetência e má fé, resta saber se os políticos, sozinhos, conseguiriam fazer o que bem entendessem com o dinheiro. Felizmente, a resposta é não! Afinal eles são políticos e, com raras exceções, não tem o conhecimento técnico/burocrático para fazer tudo. Eles geralmente precisam da ajuda de outras pessoas. E é aí que entram os servidores públicos. Com isso vamos ao segundo aspecto. Políticos não conseguem fazer o que bem entendem sem a ajuda de alguns servidores públicos. Por isso é tão importante que o servidor público seja selecionado por meio de concurso público, seja bem remunerado e tenha estabilidade. Sem esses três fatores os servidores públicos seriam muito mais facilmente corrompidos.

Entretanto, você sem dúvida já ouviu notícias a respeito de crimes no governo envolvendo servidores públicos. Mas acredite, essas ainda são exceções. Dito isso, chegamos ao terceiro e último aspecto. Ruim com eles, pior (muito pior) sem eles! Os servidores públicos concursados são os verdadeiros guardiões da lei. Se a opinião pública cotinuar se voltando contra esses trabalhadores, a corrupção vai piorar muito, muito. Imagine um governo sem servidores concursados. No lugar desses, imagine milhares de pessoas indicadas livremente por políticos, trabalhando para políticos. Consegue prever as consequências? Consegue entender a forte pressão que essas pessoas sofreriam para concordar com os políticos no que eles bem entendessem?

Depois de algum tempo no serviço público, você acaba entendendo melhor essa questão. A realidade se torna mais clara. E qual é a verdade sobre os servidores públicos? A verdade é que o servidor público, aquele concursado, de carreira, é a última barreira que resiste à incompetência e má fé que já assola o nosso país. Isso é muito sério! Assim, caro leitor, considere bem tudo isso antes de sair chamando seu vizinho servidor público de marajá. Voltar a opinião pública contra os servidores públicos é como dar um tiro no próprio pé. Atacar os servidores públicos não é a melhor forma de promover a igualdade social, nem de evitar a corrupção. Não estou dizendo aqui que todos os políticos têm má fé e são incompetentes. Mas quando um assim surgir terá que vencer dezenas, talvez centenas, de guardiões!

E se você não concorda com nada disso que eu disse, deixe o seu comentário!

Planejamento estratégico: Cortina de fumaça?

2011-02-25T17:29:00.000-03:00

Planejamento estratégico é uma cortina de fumaça para a incompetência tático-operacional.

Você discorda? Participe com seus comentários.

PlayStation Move: Não compre!!!

2010-11-08T15:18:00.000-02:00

É isso mesmo. Não compre, pelo menos por enquanto. Uma coisa são esses vídeos que estão transitando pela web demonstrando o funcionamento dos novos controles como algo sensacional. Outra coisa é você comprar e usar na sua casa. Já estou com os meus a mais de um mês. Vamos agora analisar alguns dos problemas que detectei. Mas se você quiser polpar tempo lendo, aqui vai minha opinião sobre eles: uma porcaria!

Em primeiro lugar, os controle não são práticos. Em outras palavras, eles não são nem fáceis de instalar, nem de utilizar. Para instalar a câmera, por exemplo, você vai ter que passar mais um fio em cima do seu móvel. Se a sua televisão for uma LCD pendurada na parede, você corre o sério risco de a câmera ficar muito longe da televisão. Outro problema é que ela vai ficar ocupando uma USB e aí você não vai poder recarregar dois controles ao mesmo tempo e, acredite, com esses controles você vai precisar recarregar o tempo todo. A calibragem do dispositivo também não é clara e, durante o jogo, é comum ter que recalibrar (uma chatice!). Outro problema é o fato de que a dupla de controles, o com a bolinha e o direcional, aparecem como controles independentes. Não vou entrar em detalhes por que estou com preguiça de escrever, mas quem já utilizou sabe a confusão que isso provoca. Ainda mais se você for utilizar o Move em conjunto com um controle normal. Ainda outro problema são os botões. Ao invés de utilizar os mesmos botões e estabelecer correspondências exatas, a Sony inventou novos botões e complicou desnecessariamente a utilização dos controles. A correspondência entre os botões não é clara e alguns foram até substituídos por combinações de botões (é mole?). Joga Resident Evil 5 para você ver a complicação!

Em segundo lugar, a jogabilidade não é boa. Como já disse, alguns comandos que antes eram feitos com um único botão agora são feitos com dois. Imagine apertar dois botões e ainda ter que manter a bolinha apontada para um ponto fixo na tela: impossível! E eu vou ser bem sincero com você, se o jogo não foi feito para esses controles então a jogabilidade não vai ficar boa. Já vi até outros blogueiros falarem de Heavy Rain, por exemplo, que ficou muito bom. Não concordo! Eu também tenho esse jogo. A jogabilidade ainda é péssima, está longe de ser aceitável. Parece até que eles fizeram tudo às pressas para lançar os controles e os jogos antes do natal. Até a posição dos botões é ruim. Só tenho uma palavra: fiasco!

Bom, eu não tenho nada a perder nem a ganhar com este post. Só quero ajudar a você a não cometer o mesmo erro do eu, gastar dinheiro com esses controles, que ainda por cima são muito caros, e depois deixá-los encostados lá por serem ruins. Quer movimento? Compre um Wii! E faço aqui um apelo à Sony: no Playstation 4, por favor, faça algo bem feito!

TI é ou não uma área estratégica?

2010-11-03T10:37:00.001-02:00

A rede de lojas Americanas, a montadora de carros Fiat e o Tribunal Superior Eleitoral: O que essas três organizações têm em comum? Todas elas dependem da TI para entregarem seus negócios. Em outras palavras, hoje, sem TI, elas não existiriam como as conhecemos. Essa verdade, de que a maioria das empresas hoje dependem fortemente de TI, nos leva a duas perguntas fundamentais: Afinal, TI é ou não uma área estratégica e, se for, o que isso realmente implica?

Os administradores em geral confundem "área estratégica" com "área fim" e isso os tem levado a cometer erros no posicionamento de TI dentro da organização. Traduzindo em português simples, área fim é aquela ligada diretamente ao seu negócio e área estratégica é aquela imprescindível para a entrega do negócio. Consegue perceber que na prática haverá uma grande sobreposição de conceitos? Por exemplo, podemos afirmar que toda área fim é estratégica. Mas o problema é que muitos administradores acham que só é estratégica aquela área que é fim. E daí relegam a TI para segundo plano e esquecem de ouvi-la antes de tomarem decisões. Se a sua empresa não consegue entregar o negócio sem a ajuda da TI, então esta é uma área estratégica sim! E vamos combinar, isso já ocorre na grande maioria das empresas. Mas o que significa considerar a TI como sendo estratégica? Simples, significa basicamente três coisas.

Primeiro, significa que a TI não vai estar subordinada a nenhuma área fim específica, muito menos a uma área não fim. Fico horrorizado às vezes de ver áreas de TI inteiras subordinadas ao departamento administrativo, que nem fim é. Como uma organização assim quer que a TI contribua para o seu negócio? Nessa posição, a TI vai acabar fadada a cuidar da folha de pagamento e sistemas de gestão empresarial. O lugar da área de TI é no topo, ou ligada diretamente ao CEO, ou com a sua própria vice-presidência ou gerência, dependendo da terminologia adotada (veja o organograma acima). Segundo, se a área de TI é estratégica, então ele deve ter voto ativo na definição do orçamento. E dependendo do ramo da organização, como por exemplo o financeiro, a TI pode consumir a maior parte do orçamento. É o que justamente ocorre nos bancos. Terceiro, considerar a TI estratégica envolve participá-la de todas as decisões da empresa. Em outras palavras, o CIO deve ter acento fixo e direito a voto nas reuniões do comitê estratégico ou similar.

Bom, espero que este artigo tenha ajudado a ver as implicações práticas de considerar a área de TI estratégica. E na sua empresa? Como isso funciona? Participe postando abaixo o seu comentário!

ITIL na prática: É possível?

2010-10-27T17:54:00.002-02:00

Já passei por duas grandes empresas que tentaram implementar ITIL e não conseguiram. Também passo boa parte do meu tempo livre pesquisando grupos de discussão e trocando e-mails com pessoas da área. Na minha opinião, geralmente as discussões giram em torno de teorias e muita abstração. É raríssimo encontrar informações práticas. Tudo é muito filosófico.

Essa experiência me faz perguntar se realmente é possível implementar o ITIL. O que tinha que ser um livro de boas práticas, na verdade, é um livro de boas teorias, que de prático não tem nada. Tanto é que raramente se fala de ferramentas, nem todos os papéis estão definidos, a sequência da maioria das atividades não é clara e, para deixar tudo ainda mais teórico, as interfaces entre os processos mais parecem um quebra-cabeça. Me pergunto também se as empresas que dizem ter implementado o ITIL realmente o fizeram, já que não existe certificação. A pergunta que parece que ninguém tem coragem de fazer é: Será que o ITIL é viável?

Não estou me referindo a apenas um ou outro processo. Estou me referindo a todos. Tudo parece ser muito simples quando falamos de gerenciamento de incidentes, problemas e mudanças -- afinal, muitos centros de informática já fazem isso a anos de forma instintiva. A função da central de serviços também é algo simples de implementar: olha o helpdesk aí melhorado. Mas a coisa complica definitivamente quando o assunto é gerenciamento de configuração! Ainda mais complicado são as interfaces dela com os demais processos.

Acho elogiável a iniciativa de alguns grupos de discussão e até sites dedicados a ver o ITIL de forma prática. Mas, sinceramente, eles ainda não conseguiram. E, na minha opinião, todas essas iniciativas, inclusive o próprio livro do ITIL pecam nos seguintes pontos.

Primeiro, os papéis não estão bem definidos. Entenda que definir um papel não é só dar um nome para ele e dizer quais são as suas responsabilidades. As empresas querem saber quem vai exercer aquele papel, quantas pessoas devem ser, a quais estruturas da organização essas pessoas devem pertencer e, mais importante, em quais atividades elas vão atuar fornecendo exatamente que tipo de informação. Em outras palavras, essas pessoas serão responsáveis por quais entradas do processo? E exatamente quando elas vão ter que fornecer essas entradas?

Outro problema nas abordagens do ITIL que vejo por aí é aquela velha frase "você precisa escolher uma ferramenta que melhor se adapte à realidade da sua empresa". Isso é verdade, eu tenho que admitir. Mas concorda que é muito fácil dizer isso toda vez que alguém te pergunta qual ferramenta usar? Ou melhor, será que não poderíamos pelo menos dizer quais funcionalidades essa suposta ferramenta deveria ter? Vou mais além ainda. As pessoas querem saber como as ferramentas se integram ao processo. Em outras palavras, o desenho do processo deve prever em cada atividade os formulários utilizados para o fornecimento das entradas. Afinal, quando utilizamos uma ferramenta, os formulários preenchidos representam os próprios artefatos utilizados no processo.

Vou citar só mais um problema. Os textos que abordam ITIL são muito abstratos e raramente incluem exemplos ou estudos de caso para ajudar as pessoas a visualizarem a execução dos processos no dia a dia. O próprio livro do ITIL, na minha opinião, deveria fornecer um estudo de caso bem abrangente com o cotidiano de um centro de informática qualquer que demonstrasse na prática a aplicação da teoria. Os melhores livros de programação já fazem isso. Por que não fazer isso também para livros sobre processos?

E os problemas não param por aqui. Ainda existem uma avalanche deles, como a não definição da integração com outros modelos de processos. Os próprios livros ITIL são muito estanques. Existem uns poucos gráficos falando de integração. O livro que fala sobre desenvolvimento de software, por exemplo, é desconhecido da maioria das pessoas.

Assumo que é fácil criticar. Mas para propor soluções, primeiro precisamos reconhecer os problemas. Eu mesmo confesso ter sido muito abstrato em todas as vezes que falei de ITIL até agora. Aproveito para convidar aqui todos os blogueiros e escritores sobre o assunto a mudarem para uma abordagem mais prática, orientada a exemplos e estudos de caso. A viabilidade do ITIL pode estar dependendo justamente disso!

Google Toolbar para o Chrome

2010-10-25T14:12:00.000-02:00

Você também acha um absurdo a Google ainda não ter disponibilizado a Google Toolbar para o Chrome? Então faça a sua parte e sugira! A Google até criou uma página para isso. Acesse o link e clique no botão "Suggest It" ao lado da opção "Release Google Toolbar for Google Chrome".

Eu já fiz minha parte!
http://bit.ly/96QHlK

Censo do IBGE e o preconceito racial

2010-10-15T15:14:00.003-03:00

Norman Rockwell

Você já recebeu o recenseador do IBGE na sua casa? Há alguns dias recebi um lá em casa. Foi a primeira vez que tive a oportunidade de responder o questionário. Uma questão específica do formulário me motivou a escrever este post: "Qual é a sua raça?" Dei uma de joão-sem-braço e respondi: "Como assim?" O recenseador tentou ajudar dizendo algo mais ou menos assim: "O Sr. declara ser de qual raça; as opções são branca, parda, amarela, negro..." Enquanto o rapaz ia falando uma lista quase sem fim de cores, fiquei pensando no quanto aquela pergunta era ridícula. Explico.

A ciência já comprovou que não existem raças humanas. A variação genética é insuficiente para fazer qualquer tipo de distinção. Ou seja, do ponto de vista biológico, a cor da pele é só mais uma dentre as várias características que nos diferem uns dos outros, como a cor do olho, o tamanho da boca, do nariz, a estatura, o tom da voz e assim por diante. Ora, se do ponto de vista científico não existem raças, que dirá do ponto de vista moral! A diferenciação pela cor da pele é totalmente injustificável! Então porque cargas d'água instituições como o IBGE insistem em utilizar essa classificação?

Na minha opinião, classificações como essa só afastam as pessoas, só contribuem para que as pessoas se enxerguem como diferentes e não iguais. Perguntas como essa do questionário do IBGE fazem parte da propaganda preconceituosa à qual somos expostos diariamente para nos fazerem acreditar que não somos semelhantes.

Respondi ao rapaz: "Eu sou ser humano; mas o que você vai marcar aí é problema seu!"

E você? Acha que essa diferenciação contribui para o preconceito?

Reformar a casa e desenvolver software: Tudo igual

2010-08-11T11:25:00.002-03:00

Fonte: http://assessoriaemreformas.blog.terra.com.br

Dá gosto ver o resultado de uma boa reforma – ainda mais se teve um bom projeto de um arquiteto ou decorador. Do contrário, é um desgosto sem tamanho ver que, ao final, após tanto dinheiro, tempo e trabalho gastos, aquela reforma dos seus sonhos não ficou exatamente como você imaginava. Pior ainda é descobrir que para ajustar tudo talvez você gaste mais do que para fazê-lo.

Reformar ou construir uma casa é como desenvolver software. Inclusive, essa é a metáfora mais comum que se utiliza para racionalizar o desenvolvimento de um software. Você parte de uma idéia abstrata e depois se esforça para materializá-la. Como todo trabalho de engenharia, o resultado final depende de uma boa definição do escopo, comunicação, colaboração e controle.

Assim, se você nunca passou por uma reforma antes e está pensando em iniciar uma empreitada, ou pensa em desenvolver software :), aqui vão algumas dicas de quem conviveu com uma reforma bem abrangente, cometeu vários erros, quase morreu de desgosto, mas pelo menos aprendeu algumas boas lições para a próxima vez. Em cada dica, eu faço uma analogia com o desenvolvimento de software. Confira!

Tenha uma idéia MUITA clara do que será feito ANTES de iniciar a obra

Esta é provavelmente a dica mais importante: Só inicie a obra quando você souber exatamente o quê e como será feito. Estamos aqui falando de definição do escopo e levantamento de requisitos. Não pense que tudo se resume ao projeto do arquiteto ou decorador. Nem basta saber os tipos de materiais que serão usados. Você precisa saber EXATAMENTE o quê será feito. Qual será a cor do piso? Onde será utilizado? Como serão feitas as emendas e os recortes? Se algo der errado, quais as alternativas? Você verificou se as instalações hidráulica e elétrica propostas no modelo são realmente viáveis? Tem certeza que aquele registro importante ou o painel de disjuntores não vão ficar atrás de algum armário? O armário planejado vai mesmo comportar aquilo que você pretende guardar nele? Considerou o espaço para ventilação que alguns eletroeletrônicos precisam?

Analise bastante o projeto e confronte-o com o local. Cruze as plantas que você já tem com as do projeto. Estude os possíveis cenários de uso. Faça algumas simulações com recortes de papelão. Quanto mais tempo você gastar confirmando o projeto e tomando decisões, menos tempo, dinheiro e trabalho você vai perder contornando restrições durante a obra. Muito faz-desfaz será evitado com uma boa análise e planejamento e comunicação com aqueles que vão executar a obra.

Em desenvolvimento de software é a mesma coisa. O escopo precisa estar muito bem definido antes do início do projeto. E, uma vez iniciado, a coisa mais importante a fazer é definir os requisitos e promover o entendimento claro deles por todos os interessados. Entregar algumas funcionalidades logo cedo, como prega o desenvolvimento ágil, pode contribuir para esclarecer os requisitos no início do desenvolvimento, que é muito mais barato. Se isso não for possível, prototipar pode ser de ajuda. É claro que podem ocorrer mudanças no decorrer da empreitada. Mas quanto mais tempo de análise você gastar com isso no início, menores serão os aborrecimentos depois.

Não inicie a obra sem ter providenciado todos os materiais

Entenda que nem tudo em uma obra pode ser feito de uma vez só. Assim, é prudente providenciar todo o material necessário à obra, para o caso do pedreiro precisar aproveitar o tempo para fazer uma ou outra coisa enquanto espera ‘aquela massa’ ou ‘aquela tinta’ secarem. Providenciar com antecedência todos os materiais vai também possibilitar que você contrate a mão-de-obra por empreitada e o pedreiro, ao ver que todo o material está disponível, vai concordar com isso. Ganha você que provavelmente vai gastar menos dinheiro com mão-de-obra e provavelmente vai receber a obra antes, e ganha o pedreiro que vai poder aproveitar ao máximo o seu tempo e ganhar dinheiro ao assumir outra obra o quanto antes.

Em desenvolvimento de software os ‘materiais’ são informação e os programadores assumem o papel de ‘arquiteto’ e ‘pedreiro’. Escopo e requisitos são as informações que eles precisam para modelar e desenvolver o software. Não caia no erro de alocar essas pessoas sem ter essas informações prontas. No início do projeto, você não precisa alocar toda a equipe de programadores para levantar requisitos. A equipe de requisitos e talvez um programador mais experiente são, em geral, suficientes para uma boa análise de requisitos e definição da iterações. Deixe para alocar programadores depois, quando você tiver pelo menos uma iteração bem definida para ser construída, do contrário eles ficarão ociosos.

Essa dica também é importante por causa da próxima dica.

Não confie nos prazos de entrega dos materiais

A postura mais ingênua que você pode ter é acreditar que os prazos de entrega dos materiais prometidos serão cumpridos pelas lojas. Pode colocar o dobro ou, dependendo do caso, o triplo. Isso se a loja não te ligar para dizer que aquele piso que você contava para amanhã na verdade está em falta no depósito e só será entregue daqui a um mês ou mais. É por isso que é tão importante providenciar todos os materiais antes de iniciar a obra. Do contrário você corre o sério risco de deixar o seu pedreiro ocioso. Ele vai acabar assumindo outra obra para não ficar parado e isso vai dar início a um ciclo vicioso de enrola-enrola da sua parte e da parte dele. E aí, caro leitor, esqueça aquele prazo de um mês para terminar a reforma.

No desenvolvimento de software esse problema geralmente ocorre quando você terceiriza a construção do software. Se você contrata uma empresa para construir seu software, mas não entrega as informações de que ela precisa, essa empresa vai acabar assumindo uma outra construção – afinal ela precisa trabalhar para receber – e isso pode acabar gerando o famigerado ciclo vicioso de enrola-enrola. Percebe-se que os clientes, em geral, são rápidos para definir o escopo, mas muito lentos para ajudar na especificação de requisitos e homologar os entregáveis que muitas vezes ocorrem cedo no projeto. Assim, minha dica é: Não assuma compromissos se o cliente não estiver disposto a assumir compromissos (contratuais) para o fornecimento dos requisitos e prazos para homologação.

Não trabalhe no limite

Essa dica vale para todos os aspectos de uma construção ou reforma. Cuidado com tudo aquilo que parece estar no limite. Contar com o limite dos prazos, limite dos espaços, limite dos materiais, em fim, todos os limites. Pense nisso também quando pensar nos seus armários planejados. Criar aquela divisória que cabe ‘exatamente’ aquele microondas ou o receiver do seu home theater pode não ser uma boa idéia, afinal, esses eletroeletrônicos precisam de uma área de folga para circulação de ar e passagem dos cabos e tomadas. Quando o assunto é limites, é interessante trabalhar sempre com uma margem de tolerância de pelo menos 10% em todas as dimensões.

Os limites também devem ser evitados no desenvolvimento de software. Se você tem um prazo, por exemplo, não conte com o limite dele para entregar algum produto. Algo pode sair errado e aí você vai ficar mal visto. Planeje sempre com pelo menos 10% de folga. Evitar limites vale também para aspectos relacionados com recursos de processamento. Digamos que você precise desenvolver algum software que vai ficar no limite da capacidade de uma infraestrutura qualquer – rede, armazenamento ou processamento em geral –, muito cuidado! Trabalhar no limite não te dá margem para errar. E errar, caro leitor, é inerente ao ser humano (sem falar que algumas máquinas falham também!).

‘O gado só engorda com o olho do dono’

Essa frase é uma máxima que todos deveriam levar para o resto da vida. É como se diz: Se você quer um trabalho bem feito, faça você mesmo. Infelizmente, não podemos fazer tudo aquilo que precisamos. Mas em geral podemos pelo menos ver e acompanhar aquilo que está sendo feito para nós.

No caso de uma reforma, isso é importantíssimo. Como já foi dito no início deste artigo, há muitos detalhes que vão além do projeto. Por isso, é vital que você acompanhe de perto a obra. Caso você trabalhe o dia inteiro, converse com o seu chefe para flexibilizar de alguma forma o seu horário para que você possa passar pelo menos uma ou duas horas por dia acompanhando a execução da reforma. Você não vai se arrepender. Além de evitar muitos erros e supresas, esse controle vai diminuir a probabilidade de erros serem cometidos em cima de outros erros. Em outras palavras, menos retrabalho. Estamos falando aqui de boa comunicação e feedback constante.

Isso é evidente no desenvolvimento de software. O manifesto ágil deixa isso bem claro quando fala da colaboração com o cliente. Inclusive, alguns modelos ágeis sugerem que um representante do cliente ou usuário fique constantemente com a equipe de construção. A idéia é obter informações do cliente em tempo de execução (desculpe o trocadilho), evitar surpresas na hora de apresentar os entregáveis e, com isso, evitar retrabalho.

Entenda que refazer desmotiva

As pessoas em geral levam numa boa concertar seus próprios erros. Já quando o assunto é concertar erros dos outros... Ninguém gosta de refazer algo por culpa de outra pessoa. Em reformas isso é muito comum. Você diz para o pedreiro colocar a pia naquele lugar, depois muda de idéia e pede para ele refazer tudo e mudar a posição. A chance de ele ficar com má vontade e fazer pior é muito grande, pois isso é do ser humano. O que fazer nesses casos?

Mesmo com bom planejamento, é comum ter que fazer um ou outro ajuste. Assim, entender que refazer desmotiva é vital para o sucesso. Ao pedir que alguém refaça um trabalho por uma culpa que não seja dessa pessoa, explique com tato que entende que a culpa é sua (ou de seja lá quem) e que você reconhece que refazer aquilo pode acabar atrasando a entrega total e assim por diante. Talvez seja interessante até combinar um pagamento extra para esses casos – é justo!

Em desenvolvimento de software é a mesma coisa. Programadores em geral gostam de ‘escovar bits’ atrás de seus próprios erros, mas detestam refazer algo por culpa dos outros. Entenda que isso pode desmotivá-los a fazer a coisa com a mesma qualidade do original e reconheça de quem é a culpa. É interessante que esses casos estejam previstos em contrato com a devida compensação financeira.

Espero que essa dica ajude a todos que estão pensando em fazer uma reforma e também àqueles que lideram equipes de desenvolvimento de software.

E você? Tem alguma dica para nós?

O problema do software legado

2010-02-20T17:42:00.006-02:00

Fonte: Medusa Web Solutions

Antes de você pensar em dizer que software legado nem sempre é um problema, vamos esclarecer o quê se está considerando como software legado neste artigo. Segundo Ward e Bennett, no livro Formal Methods for Legacy Systems (1995), software legado pode ser informalmente definido como aquele que executa tarefas úteis para a organização, mas que foi desenvolvido utilizando-se técnicas atualmente consideradas obsoletas. Logo, nem todo software antigo é legado. A palavra legado, neste caso, traz um sentido pejorativo, similar ao adjetivo obsoleto. Em outras palavras, software legado é um software antigo que, apesar de ainda ser utilizado, foi desenvolvido sem preocupação com as boas práticas de desenvolvimento vigentes e, às vezes, utilizando uma plataforma já descontinuada. E isso é necessariamente um problema? Em geral sim, por três razões principais.

Portabilidade x disponibilidade

A primeira razão é a incompatibilidade com plataformas operacionais mais recentes. E atualizar as plataformas operacionais é uma realidade em qualquer empresa que queira garantir a disponibilidade da solução e os contratos de suporte. Software legado em geral não é portável para novas plataformas e mesmo que seja, geralmente demanda um grande esforço de adaptação. Esse problema não é lá tão impeditivo, ainda mais com as novas tecnologias de virtualização, mas o risco de não funcionar sempre existe e só piora com o tempo.

Boas práticas x manutenibilidade

A segunda razão está relacionada com o desenvolvimento propriamente dito. Para começar, o legado, em geral, ou não possui documentação, ou, se ela existe, não foi feita de maneira adequada. E sabemos que uma má documentação compromete a manutenção do software. Aliás, todos os problemas envolvendo o legado que veremos aqui compromentem principalmente a manutenção do software. Quanto pior a documentação, mais difícil será a manutenção. Além disso, existe o problema da arquitetura de software. A arquitetura de software legado compromete a manutenção, pois em geral não prima pela modularização e, com isso, aumentam os riscos de uma alteração refletir onde não devia. Isso é muito comum em sistemas concebidos de forma estruturada, mas pode acontecer em plataformas orientadas a objetos também. A falta de modularização é um problema especialmente para a área de testes, que vai ficar sobrerragada com testes de regressão, absolutamente necessários quando se está lidando com um software pouco ou mal modularizado. Como não existem interfaces bem definidas, não há nada que garanta que uma alteração "aqui" não vai afetar um código "ali". Por fim, existe o problema da linguagem de programação, que em geral é ultrapassada. As consequências óbvias são dificuldade em encontrar mão-de-obra qualificada e impedimento para usar ferramentas mais atuais e que poderiam facilitar a manutenção e o desenvolvimento de novos módulos, tais como IDEs mais modernas.

Usabilidade

A terceira razão é que o software legado em geral apresenta problemas de usabilidade. Usabilidade de software é uma disciplina em constante evolução. As interfaces touch estão aí para provar que usar um software pode ser muito mais fácil do que se imaginava. Imagine quando as interfaces hands free se tornarem comuns! A usabilidade de software têm duas importantes funções. Uma é diminuir a curva de aprendizado, tornando o software mais intuitivo para quem usa e, consequentemente, diminuir custos de treinamento e tempo de retorno e aumentar a satisfação dos clientes. A outra função é aumentar a produtividade. Sofware com boa usabilidade não é só mais fácil de usar, mas também mais rápido. E em geral o legado foi desenvolvido em uma plataforma que impede ou inviabiliza a utilização de interfaces mais evoluidas. Pensou naqueles sistemas com interface de terminal 3270? É isso mesmo! Mas muitos sistemas mais recentes também foram desenvolvidos em uma plataforma ou arquitetura que tolhe a evolução da usabilidade. Vamos falar mais sobre isso no decorrer do artigo.

Quanto custa manter o legado?

Se você colocar no papel todo o esforço gasto para manter o legado, verá que vale mais a pena substituí-lo por um novo sistema. Vários estudos já demonstraram que isso é verdade, em especial quando se opta por soluções baseadas em SOA, que primam por uma arquitetura de software altamente robusta, escalável e manutenível. Mas, se isso é verdade, por que a maioria das empresas prefere manter o legado? Por quatro motivos principais.

Por que manter o legado?

O primeiro motivo é erro no cálculo do custo do legado. O cálculo do custo de manutenção do legado em geral é equivocado, pois não leva em conta os riscos envolvidos na sua permanência. Várias empresas estão esquecendo-se de considerar o risco de perda de capital humano e, principalmente, o risco da solução parar de funcionar. Outro erro comum no cálculo é esquecer de considerar o custo de oportunidade de investir em novas tecnologias que oferecem um custo de manutenção menor e têm o potencial de agregar mais valor ao sistema, em especial no aspecto usabilidade.

O segundo motivo é medo. Muitos gerentes de TI têm medo de migrar para novas tecnologias ou por que não confiam na tecnologia ou por que não confiam no seu corpo técnico de pessoal. Qual é o gerente que vai se arriscar a investir em uma nova solução sem a garantia de que ela vai funcionar como a anterior? Minha sugestão é que esses gerentes de TI precisam conhecer melhor as novas tecnologias e tomar medidas para aumentar a sua confiança nas pessoas, tais como promover treinamentos e aprimorar os processos de recrutamento e seleção. As tecnologias de sistemas estão evoluindo para melhor. Dizer o contrário não passa de conservadorismo e desconhecimento do que é novo. Não caia nessa armadilha! Se todos fossem medrosos, ainda estaríamos usando o MSDOS.

O terceiro motivo é ignorância. Como já foi dito no último parágrafo, o medo pode muito bem estar associado com a falta de conhecimento. Assim, o primeiro passo para resolver esse problema é conhecer as novas tecnologias. Estudar sobre novas linguagens, novos servidores de aplicação e novas arquiteturas é vital para tomar uma atitude de acabar com o legado. Investir em treinamento do seu corpo técnico também é importante.

E o quarto é último motivo é incompetência. Vamos ser honestos, existe uma manada de gerentes de TI sem o menor perfil para gerenciar e tomar decisões que envolvam riscos. A maioria dos gerentes de TI atuais eram outrora bons analistas e programadores, que foram promovidos pura e simplesmente por questão de antiguidade. Fazendo assim, as empresas perdem ótimos técnicos e ganham péssimos gerentes. É o que a administração chama de princípio da incompetência máxima. Esses caras não têm as competências gerenciais necessárias para avaliar o custo de manutenção do legado nem para conduzirem um processo de migração. Trata-se, sem dúvida, de um problema difícil de resolver. Como é desejável que esses profissionais tenham um perfil misto de técnico e administrador, as empresas precisam investir em programas para formação de gerentes e treinamento em técnicas de gestão de TI. Empresas com o problema do legado devem capacitar seus gerentes em reengenharia de software, que é a disciplina por detrás de tudo que estamos falando aqui. Isso vai garantir não só que os gerentes tomem uma atitude em relação ao legado como também vai contribuir para uma execução eficaz e eficiente do processo de migração.

Como resolver o problema?

Vamos considerar que a sua empresa resolveu tomar uma atitude em relação ao legado. E agora? Vamos analisar alguns pontos chaves para resolver o problema do legado.

O quê significa migrar o software legado?

Antes de iniciar qualquer atividade de reengenharia, é importante entender o quê significa migrar o software legado. Uma migração pode ser parcial ou, em casos mais extremos, total. Por quê? Porque, às vezes, uma migração parcial já é suficiente para evitar aqueles três problemas que consideramos no início do artigo, envolvendo a portabilidade, a manutenibilidade e a usabilidade. Por exemplo, considere um sistema legado desenvolvido em Cobol rodando em uma ambiente operacional de grande porte, como o z/OS. Aparentemente, não há que se falar em problemas de portabilidade, pois os ambientes de grande porte ainda têm vida longa pela frente e Cobol é a linguagem apropriada para esse cenário. Mas talvez a arquitetura de um sistema assim seja pouco modularizada e a interface de usuário esteja funcionando em modo terminal. O que pode ser feito? Uma migração parcial, ajustando a arquitetura de sofware, e uma nova interface já poderiam resolver o problema do legado sem mecher no núcleo do sistema. Nesse mesmo cenário, a aquisição de algumas ferramentas de apoio ao desenvolvimento também poderiam contribuir para a melhoria do processo de desenvolvimento. Já existem algumas soluções que permitem que se desenvolva para grande porte utilizando o Eclipse, por exemplo, com todas as facilidades que essa IDE pode oferecer. Ainda nesse cenário, a arquitetura de software poderia aos pouco ser modularizada, com um esquema que primasse pela coesão. Quem conhece Cobol sabe que isso pode ser feito com a utilização de subprogramas e parameters. As parameters podem funcionar como verdadeiros contratos entre os subprogramas, tal como ocorre com as interfaces Java. Portanto, migrar o software legado nem sempre significa jogá-lo todo fora e, seja como for, tudo pode ser feito de forma gradual como veremos a seguir.

Faça o novo software de forma realmente nova

Infelizmente, muitas empresas baseiam os novos software em software antigo. Fazendo assim, elas estão se tornando verdadeiras fábricas de software legado. Por isso, para resolver o problema do legado, o primeiro passo é parar de produzir software legado. Parece óbvio, mas muitas empresas acabam perpetuando o legado por não tomarem esse primeiro passo. Levante a arquitetura de software do seu sistema e mapeie os componentes. Garanta que o quê for desenvolvido seja realmente novo. Durante um tempo, o legado e o novo vão ter que conviver juntos, talvez até em uma plataforma híbrida. Isso pode parecer complexo em um primeiro instante, mas vai mitigar os riscos envolvendo o legado e facilitar uma eventual migração total do legado no futuro.

Mapeie os sistemas e defina um cronograma de migração

O próximo passo para acabar com o problema do legado é mapear os sistemas e definir um cronograma de migração. Sistemas com um maior índice de manutenção tendem a crescer mais rápido. Por isso, esses são os sistemas que devem ser priorizados em qualquer cronograma de migração. Comece com aqueles sistemas que demandam mais alterações. Deixe os sistemas mais críticos por último para que você possa amadurecer o seu processo de migração.

Cuidado com as interfaces de usuário

Muito cuidado quando pensar em migrar as interfaces de usuário de um sistema legado. Antes de qualquer coisa, garanta o apoio dos gestores e usuários do sistema. Se não, você corre o risco de desenvolver um sistema inteiramente novo e ter que continuar usando o velho só por que o cliente prefere as antigas telas. Marque uma reunião e apresente os problemas do legado, os riscos para a disponibilidade do sistema e mostre quais benefícios as novas interfaces trarão. Se o cliente não se convencer, tenha o cuidado de registrar tudo, pois se amanhã ou depois a disponibilidade do sistema pipocar você terá condições de se eximir da culpa.

Conclusão

Esse é um tema vasto e muito mais poderia ser dito. Existem livros inteiros sobre o assunto. Mas os pontos apresentados aqui podem contribuir para acabar com o problema do legado. E você? O que pensa sobre o legado? Acha que a reengenharia vale a pena? Como a empresa onde você trabalha está tratando desse assunto? Participe com seus comentários. Até a próxima semana.

Qual é o papel de um consultor?

2010-02-08T10:25:00.000-02:00

Uma piadinha que já rola há algum tempo na Internet ilustra bem o que eu vou dizer a seguir.

Dizem que um sujeito, todo engravatado, parou o BMW ao lado de um pastor, na montanha, e perguntou:
- Pastor, se eu adivinhar quantas ovelhas há no seu rebanho, o Sr. me dá uma?
- Sim, responde o pastor.
Então o sujeito puxa o notebook, abre uma planilha, consulta a Internet, lê alguns documentos e atira:
- Pastor, o Sr. tem 313 ovelhas.
- Acertou, responde o pastor. Pode pegar sua ovelha.
O sujeito apanha um animal e volta para o BMW, quando o pastor retruca:
- Se eu adivinhar a sua profissão, o Sr. devolve meu animal?
- Sim, responde o sujeito duvidando que aquele humilde pastor soubesse de algo.
- O Sr. é consultor. Afirma convicto o pastor.
- Como adivinhou? Pergunta surpreso o consultor.
- Foi fácil. E nem precisei de nenhuma dessas parafernalhas que você usou. O Sr. se meteu onde não foi chamado, falou o que eu já sabia e não entende nada do meu negócio. Típico de um consultor. E devolva logo o meu cachorro!

Não raro, o papel dos consultores tem sido alvo de críticas e suspeitas. Muitas empresas não dispensam uma consultoria ao implementar um modelo de melhoria de processos, por exemplo. Ao mesmo tempo, alguns executivos são céticos em relação à real contribuição de consultores. Quem está certo? Por que as opiniões são divididas? Na minha opinião, isso ocorre por que não existe uma compreensão clara do papel do consultor. Os próprios consultores muitas vezes não entendem o seu papel e acabam extrapolando aquilo que eles deviam fazer. Compreender bem o papel do consultor pode ajudar a evitar esse problema.

Diferença entre funcionário e consultor

Existem pelo menos duas diferenças muito claras entre funcionário e consultor. O funcionário conhece bem a empresa e se preocupa com o entendimento do projeto pelos demais funcionários e com o impacto que eventuais mudanças terão no longo prazo. O consultor não conhece a empresa e, mesmo que se preocupe com isso, não tem condições ótimas de avaliar o impacto de eventuais mudanças no longo prazo nem de garantir que o projeto seja entendido por todos. Qual a consequência imediata disso? O consultor tem condições de dizer o quê tem que ser feito. Mas a forma de executar uma atividade ou processo deve partir de um funcionário.

Estudo de caso

Vamos considerar, por exemplo, a contratação de uma consultoria para auxiliar na implementação de um modelo de melhoria de processos. O que deve ser contratado? Na minha opinião, apenas treinamento e gerenciamento do projeto. Consultores são ótimos para ministrar treinamentos. Eles têm melhores condições de trazer novos problemas, de disparar novas idéias, de estimular a criatividade dos funcionários. Funcionários são péssimos para isso. Eles estão muito acostumados àquela visão de mundo fecharda e cultura adotados pela empresa. Que dizer do gerenciamento do projeto? Consultores são ótimos para trabalhar no gerenciamento do projeto. Não como gerentes de projeto, obviamente. Mas certamente como membros da equipe, em especial aqueles que trabalharão no planejamento e controle. Funcionários em geral ficam perdidos, sem saber por onde começar. Consultores já vivenciaram muitos cenários e têm melhores condições de propor uma direção. Também são ótimos para efetuar o controle, pois têm a independência e o arcabouço necessários para fazer o benchmarking e avaliar a execução do projeto.

Por outro lado, consultores são péssimos para produzir documentos, definir políticas e processos. Eles não conhecem profundamente o funcionamento da empresa, nem a linguagem adotada pela organização. Deixe esse trabalho para funcionários que, sob a orientação dos consultores, têm todas as condições para executar o projeto de forma que as mudanças sejam mais facilmente entendidas e assimiladas pela organização.

Por isso, nunca contrate a produção de documentos, como manuais ou políticas, nem a definição de processos. Contrate, sim, treinamento, diagnóstico de processos e revisão de documentos.

Resumindo

Consultores são ótimos para treinar, diagnosticar e orientar. Mas deixe que seus próprios funcionários ponham a mão na massa. Definição de políticas, processos e manuais devem ter a cara da sua empresa.

Dicas para economizar com TI em casa

2010-01-18T13:36:00.002-02:00

Em época de aperto financeiro, aqui vão algumas dicas para economizar com TI em casa e evitar que ela se torne um problema ao invés de ajudar o seu dia-a-dia.

Mude o celular para pré-pago

Antes do celular, a maioria das pessoas não sentia a menor falta dessa tecnologia. É claro que o celular facilitou muito a comunicação. Isso sem falar nos aparelhos, que trouxeram funções muito úteis para o nosso dia-a-dia como as de agenda e calendário. Entretanto, em geral falamos ao celular muito mais do que deveríamos. A não ser que você seja daqueles que passam o dia inteiro na rua, falar ao celular deveria ser algo reservado para ocasiões excepcionais. Assim, para nos ajudar a usar o celular apenas quando necessário, nada melhor do que mudar para o serviço pré-pago. Você vai economizar muito dinheiro sem ficar na mão. Minha conta era cerca de 200 reais mensais. Depois que mudei para o pré-pago passei a gastar cerca de 15 reais por mês. No início é mais difícil, mas com o tempo a disciplina é automática. Você vai aprender a usar o celular apenas se for realmente necessário. Funcionou comigo e funciona com a maioria das pessoas. Dependendo do seu caso, a economia pode passar de 100 reais por mês, ou seja, mais de 1.200 por ano!

Aproveite bem a TV por assinatura

São raras as pessoas que conseguem realmente aproveitar o que pagam pela TV fechada. As pessoas em geral passam cada vez menos tempo em casa. Trabalho, trânsito e outros fatores da vida moderna fazem com que muitos fiquem em casa apenas para dormir. Pensando nisso, que tal cancelar aquela TV a cabo que você só utiliza nos fins-de-semana? Aproveite o tempo para fazer algum esporte ou para visitar os amigos (e ver televisão na casa deles hehehe). Suspeito que você será muito mais feliz. Mas se você é daqueles que não dispensa uma TV por assinatura, pelo menos faça o possível para aproveitar bem os serviços. Como? Dê preferência pelos combos oferecidos por algumas empresas, com os quais você terá a chance de economizar na conta de telefone e banda larga. Também é uma economia que pode passar dos 100 reais por mês.

Economize nas ligações interurbanas com VoIP

Se você liga muito para outros estados e, quem sabe, até para o exterior, considere seriamente utilizar um serviço VoIP. O custo da ligação em geral é muito menor. Existem até equipamentos que simulam o serviço como se fosse um telefone fixo comum. Por baixo, vamos considerar uma economia também de uns 100 reais por mês.

Resista à tentação de comprar toda novidade tecnológica

A mídia diz que precisamos comprar um novo celular, um novo computador, uma nova televisão, etc. Se você é daqueles que faz questão de acompanhar as evoluções tecnológicas, cuidado! A tecnologia de hoje em dia evolui com muita rapidez. Um celular top de linha hoje está ultrapassado literalmente amanhã mesmo! Não adianta comprar a última novidade tecnológica achando que você estará em dia com a tecnologia por pelo menos algum tempo. Troque de aparelho apenas quando o seu deixar de funcionar. Se é um celular, espere a bateria dele ficar viciada para trocar. Se é um computador, experimente reinstalar tudo ou fazer um upgrade para prolongar a sua vida. Se é uma televisão, espere ela pifar. Entenda uma coisa de uma vez por todas: mesmo que você troque todos esses aparelhos todo mês você nunca estará atualizado. Ah, e sempre vai existir alguém mais atualizado que você! Assim, deixe o orgulho de lado e economize dinheiro. Dê preferência por adquirir uma tecnologia quando o "salto" tecnológico for maior. Por exemplo, entre uma televisão CRT para LCD. De uma televisão LCD para LED, perceba que o salto do ponto de vista do consumidor é muito menor! Só espere a tecnologia deixar de ser novidade, pois os preços costumam cair muito depois de um ou dois anos do lançamento.

Conclusão

Com um pouco de simplicidade e bom senso, é possível economizar muito dinheiro. A tecnologia deveria facilitar a nossa vida e nos fazer gastar menos e não o contrário. Seguindo essas dicas, você pode economizar bastante. Imagine que você consiga polpar cerca de 300 reais por mês. Em um ano você terá polpado quase 4 mil reais! Parece pouco, mas já é o preço de um pacote de viagem para passar uns 7 dias curtindo a praia em um bom hotel!

Atualizações do Windows Vista o tornam mais lento?

2009-12-28T14:09:00.001-02:00

Preste atenção ao título deste artigo. Repare que é uma pergunta e NÃO uma afirmação. E é bem provável que você também já tenha se perguntado o mesmo.

Lá em casa, já precisei reinstalar o Windows Vista diversas vezes, em especial este ano. O tempo vai passando, o sistema vai se tornando cada vez mais lento até que chega ao ponto de precisar ser reinstalado novamente. Sempre suspeitei que a instalação de outros programas estivesse, de alguma forma, contribuindo para essa lentidão. Da última vez, contudo, resolvi isolar o problema. Após reinstalar o Windows Vista, decidi não instalar nenhum software adicional. Qual foi a minha surpresa? Com o passar do tempo, o sistema continuou ficando mais e mais lento. Chegou um ponto que eu não conseguia sequer abrir um vídeo do YouTube. Mas como era isso possível se eu não havia instalado mais nada? Não sei. Porém suspeito das atualizações automáticas da Microsoft.

Reinstalei o Windows Vista novamente. Dessa vez fiz diferente. Logo no primeiro acesso, desabilitei as atualizações automáticas. Depois, reinstalei outros programas (antivirus, editor de texto, etc) como qualquer pessoa normal. Qual foi o resultado? Após vários dias, o sistema continua rápido, como se eu tivesse acabado de reinstalá-lo.

Não tenho provas nem condições de acusar a Microsoft de estar promovendo atualizações prejuciais ao desempenho do Windows Vista. Mas é muita coincidência o pico de lentidão do meu sistema ter coincidido com o lançamento do Windows 7. Outrossim, quem é programador como eu sabe o tanto que é fácil "esquecer" um trecho de código dentro de um programa que consuma processamento e recursos de memória. Afinal, a Microsoft não tem nenhum interesse em que o seu velho sistema continue funcionando perfeitamente. Ela tem quase um monopólio. Então motivos não faltam.

Se você também está na dúvida, faça como eu. Reinstale o seu Windows (XP ou Vista) e NÃO habilite as atualizações automáticas. Você não é obrigado a fazê-las e pode, quem sabe, dar uma sobrevida de um ano ou dois para o seu velho sistema. A não ser que você tenha percebido alguma melhora no sistema depois das atualizações. Eu, infelizmente, só percebi pioras. Deixe para trocar de sistema quando você tiver a fim de novidades, não simplesmente para resolver problemas de performance.

Como comprar na Internet com segurança e traquilidade

2009-12-18T13:21:00.000-02:00

Você costuma fazer compras na Internet? Com que frequência?

Comprar na Internet, além de cômodo, pode ser muito mais eficaz. Isso ocorre porque existem várias ferramentas para compararmos produtos e encontrarmos o melhor preço. Além disso, em geral as informações disponibilizadas pelas lojas da Internet são mais seguras do que aquele "papo de bom vendedor". Mesmo assim, muitos deixam de comprar na Internet porque têm medo de que seus dados, em especial os de cartão de crédito, sejam utilizados por criminosos. Para evitar que isso aconteça, eis algumas dicas muito úteis para você comprar na Internet com toda a segurança e tranquilidade.

Tenha um cartão de crédito especialmente para isso

Ao invés de ficar utilizando vários cartões, concentre suas compras em um cartão de crédito específico para isso. Muitos bancos oferecem cartões adicionais sem o menor custo. O importante é ter um número de cartão de crédito específico para suas compras na Internet. A grande sacada é cancelar esse cartão de tempos em tempos. O meu banco, por exemplo, cobra apenas R$10,00 para a emissão de um novo cartão. Esse valor não é nada comparado à "dor de cabeça" que você pode evitar. Simplesmente destrua seu cartão e peça um novo. Faça isso de vez em quando. Por exemplo, se você faz compras na Internet com muita frequência e não se preocupa muito com a segurança das lojas virtuais, cancele seu cartão de seis em seis meses. Caso faça compras de vez em quando, talvez um novo cartão a cada ano seja o suficiente. Destrua o cartão e ligue para o seu banco dizendo que perdeu e quer um novo. Simples assim. Não espere ter o seu número copiado por um criminoso para só depois fazer um novo. Simplesmente cancele de tempos em tempos.

Verifique a reputação da loja virtual

Grandes lojas conhecidas em geral se preocupam bastante com a segurança de seus clientes. O mesmo nem sempre ocorre com pequenas lojas. A dica é verificar a reputação da loja virtual antes de efetuar a compra. Como fazer isso? Sites de comparação de preços, como o Buscapé e o Bondfaro, já fazem isso por você. O Buscapé, por exemplo, mantém uma lista negra de lojas virtuais. E vale a pena consultar a opinião de outras pessoas em sites como o Reclameaqui e o Confiômetro. Outro bom indicador é o preço. Desconfie de preços muito baratos em relação à concorrência.

Evite lojas virtuais que armazenam seus dados de cartão de crédito

Algumas lojas, por razões de conveniência (ou não), armazenam seus dados de cartão de crédito para facilitar futuras compras. Apesar de conveniente, isso não é nada seguro. Quanto mais tempo esse tipo de informação fica armazenada no banco de dados da empresa, maior é a probabilidade de seus dados serem acessados indevidamente por criminosos em uma eventual invasão virtual da loja. Evite comprar em sites que façam isso, a não ser que você esteja prestes a cancelar o seu cartão conforme a primeira dica (hehehe!).

~~Imprima tudo~~

Uma das vantagens de se comprar na Internet é que tudo está escrito. Portanto, imprima tudo, tudo mesmo. Salve todas as informações relevantes que te levaram a efetuar aquela compra: descrição detalhada do produto, informações do pedido, recibo de pagamento, informações sobre o prazo de entrega e condições para troca, política de privacidade, etc. Se quiser economizar papel, salve tudo em PDF.Consulte este artigo.

Conheça seus direitos

O Código de Defesa do Consumidor estabelece o direito de arrependimento para compras efetuadas pela Internet. Isso é necessário para garantir que você possa se arrepender depois de ver o produto ao vivo e a cores. Portanto, compre com toda tranquilidade. Você pode se arrepender e devolver o produto! Consulte o código para verificar quais produtos e em quais situações isso é possível.

Boas compras!

Blog Action Day 2009 - Mudanças climáticas

2009-10-15T22:45:00.000-03:00

É preciso ser um imbecil para não perceber que o clima está mudando -- e para pior! Consigo perceber isso na minha cidade, nas cidades que visitei há anos atrás e que agora a elas retorno e até em cidades nas quais nunca estive -- afinal, as informações e notícias sobre o clima de qualquer cidade estão disponíveis a qualquer um que acesse a internet.

Mas aí vem a pergunta: O quê podemos fazer para evitar um eminente apocalipse climático? A resposta, caro leitor, é um enfático NADA.

Nada. Isso talvez lhe surpreenda em um primeiro momento. Mas deixe-me explicar melhor. Infelizmente, não vivemos em um mundo governado por cientistas, engenheiros, metereologistas, técnicos ou outro especialista qualquer que tenha condições de ajudar. A verdade é que somos governados por uma elite burra, que não enxerga o longo prazo, que não está preocupada com o futuro dos seus filhos -- por que muitos, inclusive, nem filhos têm -- e tampouco está preocupada com o futuro de gente que não conhece. Esses são os aristocratas, que sempre fizeram parte da elite ou que à ela venderam a vida para fazerem parte. O que essas pessoas querem? Dinheiro, mais dinheiro e mais dinheiro. Não estão preocupadas se um dia ainda vai existir um mundo onde se possa gastar tanto dinheiro. Afinal, a vida é curta e investir na melhoria de vida de outras pessoas a longo prazo é puro altruísmo.

E altruísmo é algo difícil de se encontrar hoje em dia. É mais fácil encontrar petróleo.

Futuro dos programadores, as interfaces touch e o reconhecimento de vídeo

2009-09-24T16:09:00.002-03:00

Já publiquei neste blog pelo menos dois artigos sobre o futuro dos programadores (se você ainda não os leu, talvez ache interessante dar uma olhadinha neles: artigo 1; artigo 2). Gosto muito de pensar sobre esse tema e vislumbro muitas mudanças na demanda por programadores. Não que eu esteja disposto a me preparar para isso. Já tive minha época de nerd que estava sempre atualizado com as novidades das linguagens de programação e seus respectivos SDKs. Mas gostaria de ajudar os milhares de jovens que estão entrando no mercado de trabalho a tomar um rumo na vida. E esse rumo da programação, meus amigos, está diretamente relacionado com as interfaces touch e o reconhecimento de vídeo.

Interfaces touch

Ninguém pode negar que as intefaces touch significaram um grande avanço tecnológico. Só que o sucesso delas não se deve à tecnologia touch em si (os dispositivos de entrada e saída), mas às novas interfaces. E a preocupação dos fabricantes agora é aproveitar o pleno potencial touch para melhorar a usabilidade e a percepção de valor por parte dos usuários. Nisso, os novos celulares estão cada vez melhores. Tirando a interface da Apple, que dispensa comentários, tenho notado que as demais interfaces estão cada vez melhores. A HTC, por exemplo, está oferecendo um Android muito rico. E agora é a vez da Motorola também entrar forte no mercado com o Dext. A Nokia, apesar de ter na minha opinião a melhor interface não-touch, infelizmente ainda não conseguiu abandonar certos paradigmas para aproveitar plenamente o potencial touch. Eu sei que esse meio é extramente competitivo e muitas melhorias por parte de um fabricante acabam esbarrando em patentes da Apple ou outra grande empresa. Mas a concorrência, já que está atrasada, precisa fazer um esforço de criatividade maior se deseja acompanhar a evolução desse mercado. Por tudo isso, prezado programador, é hora de abandonar aqueles tradicionais programinhas com interfaces baseadas em formulários e partir para o desenvolvimento de aplicações mobile com interface touch. Baixe os SDKs dos principais fabricantes e mergulhe de cabeça nesse mundo. Conhecimentos de design são extramente importantes. Emprego não vai faltar, pode acreditar!

Reconhecimento de vídeo

Outra coisa que estamos percebendo no mercado, é a crescente oferta de desktops com grandes monitores do tipo touchscreen. Alguns desses desktops já estão até sintonizando canais de TV, inclusive os digitais. Ao passo que a interface dessas máquinas for melhorando e elas forem se popularizando cada vez mais, uma nova mudança vai acontecer. Além do PC do escritório ou quarto, as famílias vão ter um outro desktop na sala também, no lugar da televisão. Só que, nesse ponto, a interface touch não será suficiente para o sucesso dessas máquinas. Afinal, ninguém vai querer ficar grudado no monitor da sala e sim sentado no sofá. Controle remoto, nem pensar. Essa porcaria, baseada em comunicação por infravermelho que vive falhando, já não é suficiente para comandar todos os recursos que são oferecidos por essas máquinas. Talvez até os fabricantes ofereçam verdadeiros iPods touch que sirvam como controles remotos baseados em bluetooth ou wi-fi. Só que não vai passar de um quebra-galho. A grande revolução será mesmo o reconhecimento de vídeo. Adeus teclados. Adeus touchscreen. Adeus controle remoto. Toda a interface com o usuário será baseada no reconhecimento de vídeo. Vídeo do quê? Dos movimentos das pessoas sentadas no sofá em frente da televisão, digo, do computador. Lembrou do Projeto Natal? É disso mesmo que estou falando.

Mais reconhecimento de vídeo

Na verdade, o reconhecimento de vídeo irá muito além de simplesmente controlar um computador ou vídeogame. Diversos outros avanços tecnológicos dependem de avanços contínuos nos softwares de reconhecimento de vídeo. Robores, carros com piloto realmente automático, sistemas de vigilância, sistemas analisadores de comportamento, tudo isso depende do reconhecimento de vídeo (e, obviamente, estamos falando também do reconhecimento do som do vídeo). Porque tudo isso ainda não faz parte do nosso cotidiano? Simplesmente porque ainda existem muitos problemas envolvendo reconhecimento de vídeo por serem resolvidos. Ou seja, precisamos de mais programadores pesquisando sobre isso e oferecendo soluções. Tratam-se de sistemas extramente complexos e pesados. Ainda estamos engatinhando nessa área.

Uma idéia prática para quem está desempregado: escolha um problema para resolver que esteja relacionado com interfaces touch ou reconhecimento de vídeo, monte um projeto e apresente-o a alguma instituição que queira investir nele. Tenho certeza que você será bem sucedido!

Aguardo os comentários de vocês sobre tudo isso.

Como escrever um bom artigo

2009-08-27T13:06:00.000-03:00

Não tenho conseguido atualizar este blog há algumas semanas. No momento, estou escrevendo um importante artigo para uma revista na área de TI, e isso tem tomado boa parte do meu tempo livre. Enquanto isso, aqui vai uma ótima dica para quem quer começar a escrever artigos e ainda está tendo alguma dificuldade. Leia este interessante artigo do Kanitz. Concordo em gênero e número com tudo que ele diz. Quem dera que eu também pudesse reler meus artigos as 40 vezes que ele recomenda. Boa leitura e bons artigos!

Twitter 101 for business - uso corporativo do Twitter

2009-08-01T18:56:00.000-03:00

Enquanto que os benefícios do uso do Twitter para uso meramente pessoal ainda são questionados, o uso corporativo do Twitter está se consolidando cada vez mais. Mas se você, ou a sua empresa, ainda está se perguntando sobre como o Twitter pode gerar resultados, talvez seja o momento de conferir o que os próprios donos do Twitter têm a lhe dizer. Eles mantém um sitem especialmente sobre isso, com dicas e estudos de casos sobre o uso corporativo dessa ferramenta: o Twitter 101. Vale a pena dar uma lidinha rápida. Bons negócios!

Este pendrive merece meu investimento

2009-07-29T12:56:00.000-03:00

Reparem neste pendrive:

Você está vendo um pendrive do tamanho de uma moeda que pode chegar até 32GB. Trata-se do Pico_C da Super Talent. No site da Newegg o modelo de 16GB está custando U$34,99. Me chamou a atenção a taxa de transferência desse pequenino - 30MB/s - que é relativamente muito rápida! Para vocês terem uma idéia, o pendrive mais rápido que eu conhecia até então era o OCZ ATV Turbo. Mas ele só vai até 4GB. Bom, acho que já sei qual será meu próximo pendrive. Só falta achar um amigo que esteja indo para os EUA.

Cartão BNDES = MPS.BR e CMMI

2009-07-29T10:15:00.000-03:00

O Cartão BNDES agora pode ser usado para financiar serviços de consultoria, implementação e avaliação do MPS.BR e CMMI (Fonte: Site Convergência Digital). Por um lado, isso representa o atendimento de uma demanda antiga de várias empresas brasileiras de software, especialmente aquelas que querem vender seus produtos e serviços de TI lá fora. Mas, por outro lado, o Governo pode estar sinalizando que em breve vai exigir essas certificações de empresas que queiram obter financiamentos públicos para a área de TI. Não acredito que essa iniciativa por si só vá aumentar a demanda por essas certificações. Entretanto, caso essa exigência do Governo se confirme, é importante que as empresas comecem a pensar na idéia se desejarem contar com financiamentos públicos no futuro. Mesmo que não se torne um requisito, pode ser que o Governo encare isso como um critério de priorização na hora de direcionar investimentos para a indústria de software. Precisamos estar preparados.

GPR x GRE

2009-07-28T13:56:00.001-03:00

Gostaria apenas de fazer alguns comentários adicionais sobre o meu artigo Desmistificando o MPS.BR - Gerência de Projetos (GPR). Lá nesse artigo, quando falei sobre o relacionamento entre os processos GPR e GRE, disse que "o escopo nada mais é do que o resultado do levantamento de requisitos". Bom, na verdade a coisa não é bem assim. Para fins didáticos, como estava falando da relação GPR x GRE, o escopo era o foco. Contudo, pensando na GPR como um todo, nós sabemos muito bem que o escopo do projeto pode ser (e geralmente é) muito mais do que apenas requisitos de software. Pode envolver infraestrutura, treinamento, manutenção, questões de garantia, manutenção, etc, etc e tal.

Desenvolvendo sua própria ferramenta de GPR para o MPS.BR

2009-04-17T23:17:00.001-03:00

No meu último artigo sobre a Gerência de Projetos do MPS.BR, fiquei devendo algumas dicas sobre como implementar uma ferramenta que atenda a esse modelo de melhoria. Estava pensando em escrever um artigo sobre isso somente no final da série “Desmistificando...”, mas recebi um comentário de um leitor perguntando mais sobre o assunto. Ele gostaria de saber ‘quais as funcionalidades básicas que uma ferramenta própria’ (desenvolvida inhouse) deveria ter para atender à GPR e, inclusive, gerenciar o portfólio de projetos, supondo ter vários projetos para uma mesma equipe.

Antes de tudo, vale ressaltar que, conforme citei naquele artigo, o MPS.BR não exige a utilização de um ferramenta para realizar o gerenciamento de projetos. Contudo, isso fica nas entrelinhas e, obviamente, é algo desejável!

Não vai ser possível esgotar aqui todos os aspectos necessários para que uma ferramenta suporte 100% dos resultados esperados pela GPR. Vou tentar cobrir apenas os principais. Aí vai.

1. Escopo

O primeiro resultado esperado da GPR tem a ver com escopo. Para isso, a ferramenta deve oferecer uma função para registro e manutenção do escopo do projeto. De acordo com o GPR 1 (leia-se: resultado esperado nr. 1 da GPR), basta que o escopo esteja definido. Contudo, é nesse ponto que a GPR se relaciona com a GRE (Gerência de Requisitos). Como falei no último artigo daquela série, o escopo de um projeto é formado pelos requisitos que foram levantados. E, de acordo com o GRE 5, mudanças nos requisitos devem ser gerenciadas, controladas. Assim, é importante que a sua ferramenta de projetos restrinja eventuais alterações no escopo após a aprovação do escopo pelos envolvidos. Caso seja necessário alterar o escopo, a ferramenta deve guardar um histórico das alterações. É desejável também que a ferramenta permita que o registro da aprovação por cada envolvido. Se a aprovação puder ser feita por um usuário externo – no caso de você ser contratado isso é muito comum – a ferramenta deve possibilitar anexar uma cópia eletrônica do documento formal de aprovação do escopo.

O escopo pode ser um simples campo texto ou, dependendo da sua realidade, algo mais estruturado. Aqui onde trabalho, estruturamos o escopo em funções a implementar. Cada função, na maioria dos casos, vai representar um caso de uso. Se quiser sofisticar mais um pouco, crie um atributo para priorizar essas funções.

2. Modelo e ciclo de vida do projeto

O MPS.BR não entra no mérito sobre qual modelo de gerenciamento de projetos você deve adotar – mas exige que você adote algum. A sua teoria se baseou muito no PMBoK. Por isso, na prática, é bom você adotar um modelo que utilize pelo menos algumas das “boas práticas” preconizadas pelo PMI. A ferramenta deve representar esse modelo e o ciclo de vida que ele propõe. Por exemplo, se o modelo adotado estipula quatro fases de gerenciamento – iniciação, planejamento, execução e encerramento – a ferramenta deve representar essas fases em algum atributo que guarde o estado do projeto (exemplo: “em andamento”, “planejando”, “em encerramento”, etc). Só uma ressalva, não confunda as fases de gerenciamento do projeto com as fases de desenvolvimento, ok? Em geral, as fases de desenvolvimento estão dentro da fase de execução do projeto.

3. Orçamento e cronograma

A ferramenta deve também permitir a definir do cronograma e orçamento. De forma simples, o cronograma trata-se de uma lista de atividades e suas respectivas datas de início e fim. Essas datas, claro, são apenas estimativas e podem divergir do realizado quando o projeto entrar em franco andamento. Já orçar significa dizer quanto você vai gastar em cada atividade. Um erro comum que encontro nas ferramentas disponíveis no mercado é adotar “quantidade de dias” para o orçamento de atividades. Essa medida não é prática, pois varia conforme os recursos que você vai alocar em cada atividade. Ao invés da quantidade de dias, utilize algo que represente melhor o esforço de desenvolvimento. Não use pontos de função, pois você não vai conseguir orçar as atividades de gerenciamento do projeto com essa medida. Ao invés disso, sugiro utilizar a quantidade de horas que você planeja gastar. Escolha uma atividade e imagine quanto tempo você gastará para realizá-la com o trabalho de apenas uma pessoa. Esse é o orçamento.

Ah, é importante permitir o agrupamento de atividades para facilitar o gerenciamento e definir os marcos do projeto.

4. Riscos

O GPR 6 exige que os riscos sejam registrados e gerenciados. Se você quer que a sua ferramenta auxilie nisso, implemente uma lista de riscos. A lista deve conter a descrição do risco, o impacto, a probabilidade de ocorrência e uma classificação de prioridade. Qual unidade de medida utilizar no impacto? Bom, recomendo que você utilize a mesma unidade de medida que você utilizou no orçamento. Por exemplo, se você utilizou horas, um risco vai impactar “n” horas no projeto, i.e., o projeto corre o risco de atrasar “n” horas. Indo um pouco além do MPS.BR Nível G, sugiro que a ferramenta ofereça também uma função para vincular atividades e riscos em uma relação “n:n”. Isso vai lhe permitir identificar e registrar quais atividades existem para tratar de algum risco que exiga uma ação mais específica que precise ser definida no cronograma – vai ser útil quando você for implementar outros níveis.

5. Progresso e monitoração

O GPR 13 define que o progresso do processo deve ser monitorado. Para realizar esse monitoramento, é útil definir indicadores que sejam calculados automaticamente pela ferramenta. Os indicadores devem mostrar, por exemplo, se o projeto está atrasado, quais atividades merecem atenção, qual foi o desvio sobre o planejado, etc.

6. Promover o envolvimento de todos os interessados

A ferramenta deve permitir definir os responsáveis por cada atividade do cronograma que serão encarregados de registrar o seu andamento. Como alguns projetos envolvem usuários externos, o envolvimento desses deve ser registrado na forma de atas e outros fatos de comunicação (e-mails, ofícios, etc). Por isso, a ferramenta deve permitir que se anexe documentos desse tipo também nas atividades.

7. Marcos do projeto

Por fim, o MPS.BR fala de revisões nos marcos do projeto. Para que você saiba em qual momento deve realizar essas revisões é necessário que a ferramenta lhe permita registrar os marcos do projeto. Para facilitar a coisa, sugiro que você crie “atividades marcos”. Pode ser um simples atributo na atividade dizendo se ela é um marco ou não. Essas atividades podem receber uma atenção especial e servirem como pontos de controle.

Conclusão

Com certeza não foi possível cobrir aqui todos os aspectos abordados pela GPR. Inclusive, deixei de fora os resultados esperados não exigidos no Nível G. Mas espero ter dado alguma idéia do que uma ferramenta deve oferecer para lhe auxiliar na melhoria dos seus processos. Se não, mande sua dúvida!

Alguns outros processos, como a Gerência de Configuração, afetam bastante a GPR e seus artefatos. Assim, se você quiser se preparar para o próximo nível de maturidade, vale a pena dar uma olhadinha no guia de implementação para observar o quê você já pode prever na ferramenta para evitar dores de cabeça no futuro.

Um abraço e até o próximo artigo!

Engenharia de Software Conference - 22 e 23 de Maio, Lapa, São Paulo

2009-04-12T11:37:00.002-03:00

Vou fazer um breve intervalo na série de artigos Desmistificando o MPS.BR para divulgar um importante evento. Nos dias 22 e 23 de maio, a DevMedia realiza, em São Paulo, a Engenharia de Software Conference. Serão três tracks simultâneos, onde os mais graduados especialistas do ramo discutirão os principais temas da Engenharia de Software atual, entre eles o MPS.Br. Uma metodologia de gerenciamento desenvolvida especialmente para as empresas brasileras.

As explanações vão desde o projeto até os últimos testes de um software, passando pelos diversos conceitos de gerenciamento. Serão 40 horas de conteúdo, distribuídas em 30 palestras. O evento conta com a presença de palestrantes renomados, como Ana Regina Rocha, que será a keynote da conferência. Ela foi uma das idealizadoras do Modelo Mps.Br (Melhoria de Processos do Software Brasileiro), além de ser implementadora e avaliadora credenciada pela SOFTEX e membro do grupo de pesquisa em Engenharia de Software da Universidade Federal do Rio de Janeiro.

Faço questão de divulgar esse evento por que a Engenharia de Software Conference não tem o patrocínio de nenhuma das empresas fabricantes. Isso garantirá uma maior imparcialidade, apresentando análise comparatória dos mais variados softwares do mercado. O evento pretende garantir aos profissionais da área excelentes oportunidades de aprendizado e network.

Mais informações:

www.devmedia.com.br/es_conference

e-mail: evento@devmedia.com.br

Tel.: (21) 3382-5025

Assessoria de Imprensa

Tel.: (21) 3382-5021

Kaline Dolabella
kaline@devmedia.com.br

Leandra Vianna
leandra_vianna@devmedia.com.br

Quem quiser conhecer melhor o trabalho da DevMedia sobre engenharia de software, pode postar um comentário aqui com o nome e e-mail que vou disponibilizar 10 assinaturas digitais da revista Engenharia de Software para os primeiros 10 comentários.

Desmistificando o MPS.BR – Gerência de Projetos (GPR)

2009-04-02T22:05:00.002-03:00

No meu último artigo desta série, fiz uma breve introdução sobre a estrutura do MPS.BR. Vimos que os processos propostos pelo modelo podem ser classificados em pelo menos dois tipos: (1) gestão e (2) engenharia de software. Apesar de não existir essa classificação, ela fica subentendida (no CMMI isso é explícito). Vimos também que a verificação da maturidade de um processo se dá pela observação de seus resultados. É importante lembrar que o AP 1.1 está relacionado com os resultados esperados específicos de cada processo. Ou seja, atender aos RAPs do processo é o mesmo que atender ao RAP 1 do AP 1.1.

A GRE é um processo aparentemente simples. Não é à toa que a grande maioria das empresas já executa atividades relacionadas com a disciplina de requisitos. Como se trata de um processo simples e não recebi perguntas sobre o meu último artigo, vou passar direto para a Gerência de Projetos (GPR).

Reaproveitamento de boas práticas

De cara, pode ser que você se assuste com a quantidade de resultados esperados para esse processo. A GPR tem 25 resultados esperados – muito, quando comparados com a GRE – que possui apenas 5. A boa notícia é que nem todos os resultados são exigidos no Nível G.

Na verdade, existe uma explicação para esse número de RAPs. Os teóricos do MPS.BR tentaram reaproveitar as boas práticas do PMBoK, do PMI. Inclusive, isso é explicitado no Guia de Implementação. Fica claro que o GPR é ineretemente um processo de gestão. E se você tem alguma dúvida de como chegar aos resultados esperados para esse processo, uma boa dica é estudar o PMBoK e tentar aplicar algumas de suas técnicas e ferramentas.

Falando em ferramenta, o MPS.BR não exige a utilização de nenhuma ferramenta para a gestão dos projetos. Entretanto, é interessante que a empresa adote algum programa para facilitar a vida dos gerentes de projeto. Aqui, faço questão de transmitir um pouco da minha experiência pessoal: muita cautela ao adquirir uma ferramenta de mercado. Elas prometem maravilhas. Na prática, são complexas, lentas (ou exigem uma infraestrutura cara), burocráticas e cheias de recursos que provavelmente você não irá utilizar (ou não precisaria utilizar). Uma boa ferramenta para gerenciamento de projetos deve ser simples. Sugiro que sua empresa desenvolva sua própria ferramenta – quem sabe na Intranet, utilizando uma interface web. É barato, simples e novos recursos podem ser adicionados conforme a necessidade e o orçamento disponível. Uma boa ferramenta não precisa ter gráficos nem fluxos muito complexos. Fico devendo um artigo para falar mais sobre o que uma ferramenta dessas deve ter para atender ao MPS.BR.

Tudo tem que ser projeto

Como já comentei em artigos anteriores, o MPS.BR parte da premissa que tudo é encarado como projeto. Ou seja, toda demanda, solicitação, pedido, versionamento, etc, , com exceção da manutenção, devem ser rotulados de “projeto”. Na prática isso não muda muita coisa pois, como veremos, para garantir a transparência e gerenciabilidade dos processos, teríamos de todo jeito que definir os trabalhos de forma bem clara, com início e fim planejados. Assim, rotular os trabalhos de projeto acaba sendo uma conseqüência natural e inevitável.

Isso pode envolver um certo grau de mudança organizacional. Mas os gestores devem enfatizar para as equipes que rotular os trabalhos de projeto não significa necessariamente aumento da burocracia. É possível gerenciar os projetos de forma ágil. Tudo depende de como a empresa implementará esse processo. Repito: a ferramenta de gerenciamento de projetos pode e precisa ser simples para garantir a agilidade das atividades.

Resultados esperados

Apesar de a GPR conter 25 RAPs, apenas os primeiros 17 são exigidos no Nível G. Os outros são alcançados conforme a organização vai amuderecendo e subindo de nível. Vamos agora dar uma olhada geral nesses 17 resultados.

É notório como algumas palavras se repetem na definição dos RAPs desse processo. Destaco as seguintes: plano, planejamento, planejar, planejado. Até aqui já é possível entender que a GPR é sobre planejar, planejar e planejar. Planejar o quê? Tudo! É necessário planejar as fases do projeto, atividades e tarefas. Orçamento, riscos e recursos humanos também precisam constar no planejamento.

Além de planejar, a GPR também exige que sejam estabelecidas atividades de controle para verificar o atendimento ao Plano do Projeto. Falando nisso, o Plano do Projeto é o principal artefato (documento) utilizado na GPR – praticamente tudo gira em torno dele. Assim, é importante definir padrões para a sua construção e normas para controlar o atendimento ao que foi planejado. A construção desse documento deve envolver todos os interessados no projeto. Indicadores e metas podem ser úteis para controlar os trabalhos e acompanhar a sua execução. Vale ressaltar que não basta criar o Plano do Projeto – ele precisa ser mantido. Em outras palavras, qualquer alteração no planejado precisa ser registrada no plano. Isso é importante, pois os planos de projetos passados servirão de base para a definição de planos de projetos semelhantes no futuro.

Como a GPR define basicamente atividades de gestão, algumas empresas têm preferido separar essas atividades do desenvolvimento de software propriamente dito. Como? Por criar "pools" de gerentes de projeto responsáveis por essas atividades. Essa estratégia é interessante, pois contribui para a unificação dos métodos de gerenciamento dos diversos projetos da organização. Essa unificação vai ser muito útil quando a empresa estiver implementando o Nível E em diante, quando a forma de gerenciamento de projetos vai precisar ser padronizada. Apesar disso, algumas empresas têm preferido manter pessoas responsáveis pelo gerenciamento do projeto espalhadas pelas equipes de desenvolvimento. A vantagem dessa abordagem é que ela possibilita um acompanhamento mais próximo da execução. A desvantagem é que ela pode perder a independência, que varia conforme a ingerência do gerente da equipe sobre o gerente do projeto, e dificulta a unificação dos métodos, como já mencionei acima.

Não vou comentar aqui cada RAP, pois o Guia de Implementação já contém informações suficientes para se chegar aos resultados esperados. Não há mistério em entender os RAPs da GPR. Todos se baseiam em práticas há muito tempo recomendadas pelo PMI. Material sobre isso é vasto e fácil de obter.

GPR x GRE

Como esses dois processos se relacionam? Bom, ainda não disse que umas das maiores preocupações da GPR, depois do planejamento, é gerenciar o escopo do projeto. O escopo precisa ser bem definido e quaisquer alterações devem ser controladas e registradas. E o escopo nada mais é do que o resultado do levantamento de requisitos. Perceba que tudo na execução do projeto gira em torno dos requisitos. Talvez você se pergunte: Se o escopo é resultado do levantamento de requisitos, como vou iniciar o projeto se os requisitos só serão levantados durante a sua execução? Simples. Não inicie o projeto sem antes levantar os requisitos.

É comum encontrarmos projetos com atividades de levantamento de requisitos no cronograma. Não faça isso! Um projeto só deve ser iniciado com uma idéia bastante clara do que se deseja desenvolver. E isso você só vai conseguir se o levantamento de requisitos já estiver concluído. Se preciso, inicie primeiro um projeto apenas para fazer o levantamento de requisitos. No segundo projeto, pegue os resultados do primeiro para a definição do escopo. É um erro iniciar um projeto de desenvolvimento de software sem que o levantamento de requisitos esteja concluído. Não há como planejar sem essas informações.

Entretanto, pode ser necessário refinar ou alterar alguns requisitos durante o projeto. Por isso, inclua atividades de reavaliação de requisitos antes de cada iteração. Se requisitos forem incluídos ou alterados, trate isso como alterações no escopo do projeto. E lembre-se que alterações no escopo em geral afetam o planejamento.

Conclusão

Assim concluímos a análise do primeiro nível do MPS.BR, o Nível G. Ao implementar esse nível, os projetos da organização estarão com o escopo bem definido e o planejamento estará sendo acompanhado para corrigir eventuais desvios. O gerente de projetos tem um papel importante no alcance dos resultados esperados.

Contudo, apesar de haver controle sobre o andamento e escopo do projeto, não há nenhuma garantia de que os produtos de trabalho tenham qualidade. É isso que veremos no próximo artigo, quando falarei sobre o Nível F.

Um abraço e até lá.

Desmistificando o MPS.BR – Gerência de Requisitos (GRE)

2009-03-07T00:10:00.002-03:00

Nos dois últimos artigos desta série, vimos alguns pontos chaves sobre esse modelo de melhoria de processo, o MPS.BR. Tentei mostrar que um processo realmente maduro é aquele que consegue os melhores resultados ao menor custo possível. Alguns talvez digam que essa é a definição de um processo apenas eficiente e não necessariamente maduro. Entretanto, qualquer madureza que venhamos a desejar com o desenvolvimento de software tem exclusivamente um único objetivo: lucro. Mas vale ressaltar que, quando digo “lucro”, estou pensando em algo que seja sustentável. Assim, um processo maduro é aquele que consegue os melhores resultados de forma sustentável ao menor custo possível. O MPS.BR se propõe a ajudar nisso de forma gradual, por meio de sucessivos níveis de amadurecimento. A intenção é tornar o processo de desenvolvimento como um todo mais transparente, gerenciável e menos arriscado para a organização.

Diferentes tipos de processos

Cada nível de amadurecimento implica na implementação de alguns processos (ou, podemos dizer, subprocessos) relacionados com o desenvolvimento de software. Alguns estão diretamente relacionados com o desenvolvimento. Já outros afetam mais a gestão dos demais processos do que o desenvolvimento propriamente dito. Ou seja, alguns processos são inseridos no desenvolvimento para dar-lhes transparência. Enquanto outros permeiam o desenvolvimento como um todo para garantir a sua gerenciabilidade. A redução de riscos é praticamente uma conseqüência disso tudo. E a produtividade também.

Esses diferentes tipos de processos ficam bem claros quando estudamos o CMMI, pois ele até mesmo os classifica.

Os resultados indicam a maturidade do processo

Os processos implementados em cada nível também vão amadurecendo ao passo que outros níveis de maturidade são alcançados. Esse amadurecimento é medido por meio de atributos do processo (AP). Em outras palavras, um processo no Nível A possui mais atributos que o mesmo processo no Nível F por exemplo. O quê esses atributos representam vai ficar mais claro quando analisarmos cada um dos processos separadamente. Mas ainda surge outra pergunta: Como saber se um processo está, ou não, apresentando certos atributos? Uma forma de saber isso é por observar a execução do processo e avaliá-lo. Mas fazer essa avaliação seria algo muito subjetivo. Sem falar que seria algo muito caro de se fazer. Para mitigar essa subjetividade e tornar o processo de avaliação mais barato, o MPS.BR estabelece alguns resultados esperados (RAP) para cada atributo. Isso facilita a avaliação de cada processo, pois agora não precisamos mais observar a sua execução – é necessário apenas verificar os seus resultados. E esses resultados se traduzem basicamente em duas coisas: normas e registros. A relação é mais ou menos assim: a área de TI define, através de normas, atividades para a realização de registros. Os registros são verificados por atividades também definidas em normas. Simples assim.

O Nível G

Dito isso, vamos agora prosseguir com a nossa análise dos níveis de amadurecimento. Neste artigo vou introduzir o Nível G e tentar desmistificar um de seus processos: Gerência de Requisitos (GRE). No próximo artigo, abordarei a gerência de projetos (GPR) e como ela se integra com a GRE.

O Nível G é o primeiro passo para iniciar o amadurecimento dos processos de desenvolvimento de software. Apesar de ser o primeiro passo, não é o mais difícil. Mesmo assim, talvez envolva alguma mudança organizacional que muito depende da forma como a área de desenvolvimento de software já trabalha. Para algumas empresas, vai ser mais fácil. Para outras, mais difícil.

Nesse nível, ainda não se exige muita maturidade dos processos – até por que, em muitos casos, eles terão acabado de nascer. Essa maturidade inicial é representada por dois APs.

O primeiro deles é o AP 1.1, o processo é executado. A verificação desse AP se dá por meio de apenas um RAP: o processo atinge seus resultados definidos. Em outras palavras, esse RAP diz que os resultados de um dado processo precisam ser previamente definidos e observados. Um processo terá o AP 1.1 se esses resultados forem observados durante ou após a sua execução. Aí vem a pergunta: Definidos de que forma? Obviamente em uma norma que descreva as atividades do processo. Mais quais resultados devem ser definidos? O MPS.BR também sugere. Além dos RAPs, o modelo define resultados esperados específicos para cada processo. Se esses resultados forem atingidos, podemos dizer que o processo apresenta o AP 1.1.

O segundo AP exigido pelo Nível G é o AP 2.1, o processo é gerenciado. Esse atributo é um pouco mais complexo que o AP 1.1. Esse atributo possui nove RAPs. Eu poderia listar aqui todos eles e explicar o que cada um significa. Mas prefiro resumir tudo em uma única frase: O AP 2.1 exige que sejam definidas atividades de gerenciamento para cada processo. Que atividades são essas? Ora, aquelas que são ensinadas em todo curso de administração. Lembra do “planejar-organizar-executar-controlar”? Pois é. Pegue isso e coloque uma boa pitada de comunicação e padronização. Pronto! Eis o AP 2.1.

Gerência de Requisitos (GRE)

Vamos agora olhar mais de perto um dos processos exigidos pelo Nível G. Como o nome já indica, trata-se de um processo diretamente relacionado com o desenvolvimento de software – afinal de contas, tem a ver com uma das disciplinas mais importantes da engenharia de software: requisitos.

É bem provável que sua empresa já possua diversas atividades relacionadas com requisitos. Mas será que vocês possuem um processo para gerenciar os requisitos? Que importância a sua empresa dá aos requisitos de um projeto? As estatísticas mostram que a maioria dos projetos que fracassam é devido a problemas de gerenciamento de requisitos. O MPS.BR tenta corrigir essa falha básica por exigir isso logo no primeiro nível de amadurecimento.

Para atender ao AP 1.1, esse processo precisa ser executado. Sabemos se ele está sendo executado através da observação de quatro resultados esperados.

O primeiro resultado esperado é um entendimento dos requisitos junto aos fornecedores de requisitos. O que é esse entendimento? Simples, um documento onde os requisitos devem estar registrados. E que são os fornecedores? Aqueles que estão te contratando ou, se for o caso de um projeto interno, aqueles que estão demandando o software.

O segundo resultado diz respeito à aprovação dos requisitos com o uso de critérios objetivos. Essa aprovação pode tão simplesmente ser uma assinatura no documento de registro dos requisitos. E que dizer dos critérios de aprovação? Bom, alguém precisa dizer que os requisitos foram registrados de tal forma que seja possível desenvolver o software. Estou me referindo a coisas como clareza, viabilidade, completude e assim por diante. Em suma, alguém precisa dizer que os requisitos estão ok. Pronto.

A rastreabilidade dos requisitos é o terceiro resultado esperado da GRE. Em outras palavras, a partir de um caso de uso, por exemplo, deve ser possível identificar os componentes que foram produzidos para atender a ele. Ah, a rastreabilidade deve ser bidirecional, ou seja, a partir de um componente, deve ser possível identificar os requisitos. O MPS.BR exige que essa rastreabilidade seja mantida. Na prática isso envolve manter algum registro de componentes e requisitos ou adquirir uma ferramenta que gere automaticamente esses registros para você – ferramentas de referência cruzada, por exemplo.

O quarto resultado esperado da GRE é a revisão dos produtos de trabalho para identificar e corrigir desvios em relação ao que foi requisitado. Essa revisão pode muito bem ser um teste do tipo caixa branca para verificar o atendimento dos requisitos. Outros requisitos não funcionais talvez precisem de verificações mais técnicas, como revisão de código, de arquitetura e de infraestrutura.

Por fim, temos o quinto e último resultado esperado. O MPS.BR define que qualquer mudança dos requisitos seja gerenciada ao longo do processo. O que isso significa? Significa que para qualquer mudança nos requisitos, você terá que verificar os resultados esperados 2, 3 e 4 descritos acima. Ou seja, toda mudança precisará de uma nova aprovação, que por sua vez vai gerar um requisito rastreável e que por sua vez vai precisar de revisões para verificar o seu atendimento.

Conclusão

Essa primeira olhada no Nível G pode parecer um pouco enfadonha. Mas prometo que alguns conceitos vão ficar mais claros quando analisarmos outros processos. Uma coisa que você não pode esquecer é que boa parte do MPS.BR vai se traduzir, no momento da sua implementação, em normas e registros. Normas e registros. Lembre-se disso. Essa é a parte concreta de tudo que é implementado. A parte abstrata são as atividades para fazer tudo isso acontecer.

No próximo artigo vou responder algumas perguntas que restaram sobre a GRE (e que você já deve estar se fazendo neste momento) e introduzir a Gerência de Projetos.

Um abraço e até o próximo artigo.

Desmistificando o MPS.BR – Adendo à Introdução

2009-02-21T23:48:00.002-03:00

No meu último artigo sobre MPS.BR, fiz uma breve introdução ao assunto na forma de perguntas e respostas. Tentei esclarecer alguns conceitos desse modelo de melhoria e enfatizar alguns objetivos chaves. Se você ainda não leu a introdução, recomendo que a leia antes de considerar este adendo (clique aqui). Se você achar a introdução muito longa, leia pelo menos a primeira parte e se concentre nas perguntas que achar mais relevante.

Na introdução, para deixar o texto simples, apresentei apenas uma versão simplificada do MPS.BR. Algumas coisas foram deixadas de lado a favor daquilo que, de acordo com a minha experiência, é mais importante: enfatizar que esse modelo é sobre tornar o processo de desenvolvimento de software mais transparente e gerenciável. Em outras palavras, o MPS.BR não diz “como” se deve melhorar o processo. Mas as implementações propostas por esse modelo, se observadas, permitem aos gestores avaliar a necessidade de melhoria e saber onde o processo deve ser melhorado.

Entretanto, mal acabei de publicar o primeiro artigo, já recebi mais algumas perguntas sobre o assunto. E percebi que algumas coisas precisam ser mais bem esclarecidas antes de partir para uma desmistificação de cada processo (como havia prometido, meu próximo artigo iria falar especificamente sobre o Nível G do MPS.BR). Sendo assim, vamos lá! Vou responder mais estas quatro importantes perguntas.

Se o MPS.BR serve apenas para mostrar SE o processo deve ou não ser melhorado com base nas medições, por que não ir direto ao ponto e corrigir logo o processo?

Pergunta interessante. Ela questiona a real necessidade do MPS.BR. Em outras palavras, ela quer saber se, já que eu disse que o MPS.BR apenas indica SE o processo deve ou não ser melhorado, por que não esquecer esse papo de maturidade e implementar de uma vez por todas um processo mais eficaz e eficiente?

Em primeiro lugar, menti quando disse que o MPS.BR apenas indica se o processo deve ou não ser melhorado. Na verdade, em um primeiro momento, omiti essa informação por razões didáticas. A transparência e a gerenciabilidade, no fundo, JÁ são uma melhoria de processo. Portanto, por simplesmente implementar o MPS.BR, a empresa já está conseguindo alguma melhoria, mesmo que pequena. Ocorre que, como disse no primeiro artigo, um processo REALMENTE maduro é aquele que obtém os melhores resultados ao menor custo possível. E isso vai muito além da transparência e gerenciabilidade. Só que menti quando disse que era só isso. Esses são os pontos chaves. Só que o MPS.BR vai mais além. A maturidade proposta por esse modelo contribui para a redução de riscos e, portanto, para diminuir a incerteza e a possibilidade de prejuízos dos processos. Logo, o MPS.BR por si só, no fim, também contribui para reduzir os custos dos processos.

Segundo. Se a sua empresa resolver ignorar o MPS.BR e ir direto ao ponto, pode ser que cometa alguns erros. E digo isso por diversas razões. Pode ser que o seu processo já esteja bom e nem precise ser melhorado, mas você não sabe disso por que ele não é transparente. Pode ser que você implemente ações de melhoria no ponto errado do processo. Por último, mesmo que o seu processo precise ser melhorado e você consiga isso, como garantir que ele vai continuar assim se não for transparente e gerenciável? Como você vai controlá-lo? Sem controle, pode ser que um processo bom hoje fique ruim no futuro. Se isso ocorrer, o investimento se perderá. O MPS.BR evita esses problemas, pois mostra se o processo precisa ser melhorado, em que ponto e garante que ele continue assim por meio de processos de controle e melhoria constante.

Terceiro. Você precisa ter números para justificar um investimento em melhoria para a direção de sua empresa. Eles vão querer saber qual o retorno sobre o investimento, dados da situação atual e da situação desejada. Sem a medição preconizada pelo MPS.BR, fica muito difícil conseguir esses números.

Em suma, ir direto ao ponto é arriscado e o barato pode sair caro.

Já que o MPS.BR não fala “como”, o que fazer para melhorar o processo?

Como você mesmo disse, essa pergunta foge do escopo do MPS.BR, que é um modelo de melhoria do processo. Mesmo assim, vou te dar uma dica. Para melhorar o processo DE FATO, utilize um modelo DE processo. Em outras palavras, para ir além da transparência e da gerenciabilidade, aplique um modelo de processo.

Existem vários à disposição: RUP, XP, Scrum, o método preconizado pela 37signals (que vou chamar carinhosamente de M37), etc. Qual é melhor? É difícil responder. Gosto muito do foco na arquitetura e nos casos de uso proposto pelo RUP, porém ele é muito burocrático. Acho legal a programação em pares do XP, mas ele deixa a arquitetura um pouco de lado. Já o M37, da 37signals, é interessante por focar na prototipação e no marketing – mas fica muito longe do MPS.BR. Assim, o melhor talvez seja aproveitar o melhor de cada um. Muito vai depender do que os números revelaram após a implementação do MPS.BR. Vou exemplificar.

Suponha que os números revelem que os produtos não estão satisfazendo os desejos dos demandantes e isso estiver provocando constantes alterações de escopo. Se esse for o caso, talvez seja o caso de adotar a prototipação do M37 que tem se mostrado útil para reduzir o risco de o produto final não ser o que o cliente queria.

Vale ressaltar que esses processos não são certificados pelo MPS.BR nem pelo CMMI-DEV. Ou seja, implantar esses processos não é garantia de atender 100% ao MPS.BR, mesmo em se tratando do burocrático RUP.

Bom. Já fugi demais do assunto. Vamos voltar ao MPS.BR.

Por que o MPS.BR?

Por falta de opção, talvez. Como mostrei no primeiro artigo, o MPS.BR é baseado no CMMI-DEV, que é um padrão internacionalmente aceito como uma boa prática. Mas existem diversas críticas a esses modelos de melhoria. Aconselho analisar bem essas críticas para saber se é isso que você realmente quer para a sua empresa. Como já disse, ninguém é obrigado a implementar um modelo de melhoria. Lembre-se que não existe nenhum estudo indicando que o valor de uma empresa aumenta com o MPS.BR. A não ser que sua empresa seja uma softwarehouse e o mercado esteja exigindo algum nível de maturidade para contratá-la, talvez seja o caso de ajustar o MPS.BR à sua realidade. Ou, quem sabe, inventar um modelo melhor.

O MPS.BR fala sobre o desenvolvimento de coisas novas – e a manutenção, como fica?

Antes de responder a essa pergunta, preciso deixar bem claro o conceito de manutenção que uso aqui. Manutenção é tudo aquilo que NÃO é REALMENTE novo. Ou seja, qualquer alteração de requisitos, funcionais ou não funcionais, não é manutenção. Manutenção tem a ver com manter o que já existe funcionando de acordo com os requisitos que foram considerados na sua criação. Em outras palavras, manutenção é basicamente correção de bugs de codificação ou erros relacionados com falhas de hardware. Para executar um trabalho de manutenção, teoricamente, não é necessário receber nenhuma solicitação. Afinal de contas, você está apenas cumprindo com o prometido: entregar algo que funcione de acordo com o que foi requisitado. Ficou claro? Espero que sim.

Apesar de não se meter muito na manutenção, o MPS.BR tem forte influência sobre ela. Como assim? Explico. Com a melhoria do processo, você vai ter melhores condições de entregar um produto com qualidade, que atenda realmente a todos os requisitos. E isso, conseqüentemente, vai diminuir a necessidade de intervenções, de manutenção. Em outras palavras, MPS.BR é igual a menos manutenção. Pelo menos em teoria.

Qualquer outra solicitação que envolver alteração em requisitos deve ser tratada como algo novo e, portanto, deve ser tratada na esfera do MPS.BR.

Quanto a garantir que esse produto continue funcionando, isso é assunto para outros padrões, como o ITIL. Fico devendo falar mais sobre isso em futuros artigos.

Conclusão

Em uma primeira análise, o MPS.BR pode parecer algo desnecessário. Contudo, quando analisamos o assunto com mais cuidado, percebemos que considerar a maturidade dos processos é melhor do que se imaginava.

Esse modelo de melhoria não é perfeito. Mas é o melhor que temos até agora.

Esclarecer esses pontos nos convence da importância do MPS.BR e isso é a base para prosseguirmos com a análise dos níveis de maturidade. Até o próximo artigo.

Desmistificando o MPS.BR – Introdução

2009-02-19T19:18:00.002-03:00

MPS.BR é a sigla de Melhoria de Processos do Software Brasileiro. Mas o que é isso afinal de contas?

O MPS.BR é uma adaptação para as empresas brasileiras – em especial micro, pequenas e médias empresas – de um modelo de maturidade de processos de desenvolvimento de software conhecido internacionalmente como CMMI-DEV.

Muito se fala sobre esses modelos. Mas, após pesquisar exaustivamente sobre o assunto, cheguei a uma triste conclusão: praticamente tudo o que existe escrito sobre o assunto carece de clareza. Parece que os escritores sofrem de uma terrível síndrome que chamo de “diz-muito-sem-dizer-nada”. Inclusive, os próprios guias de implementação desses modelos parecem ter sido escritos por pessoas de outro planeta.

Revoltado com isso e indignado com a manada de consultores e empresas que estão deitando e rolando de ganhar dinheiro com isso, se aproveitando da inocência de profissionais bem intencionados, resolvi tentar desmistificar esse assunto. Como estou no Brasil, nada mais lógico do que começar pelo MPS.BR – vou deixar o CMMI-DEV para um segundo momento.

Pensei em escrever esse artigo de diversas formas e cheguei à conclusão que a melhor seria por meio de perguntas e respostas. Não que você já se tenha feito essas mesmas perguntas (o material disponível sobre o assunto é tão obscuro que muitos não chegam nem no nível da dúvida). Mas as perguntas nos ajudam a raciocinar e esclarecer o assunto.

Este primeiro artigo é apenas uma breve introdução sobre o MPS.BR de forma geral. No próximo artigo falarei especificamente sobre a implementação do Nível G – o primeiro – e dos processos de Gerenciamento de Projetos e de Requisitos. Boa leitura!

01. O que é o MPS.BR?

É um modelo de maturidade de processos relacionados com o desenvolvimento de software. Esse modelo foi adaptado de um outro modelo conhecido internacionalmente como CMMI-DEV para a realidade das empresas brasileiras. Isso foi necessário por que o CMMI-DEV prevê o amadurecimento dos processos em apenas 4 níveis. E, com o tempo, percebeu-se que a coisa tinha de funcionar de forma mais gradual e lenta aqui no Brasil. Daí quebraram os 4 níveis do CMMI-DEV em sete, que vão do G ao A, e fizeram uns pequenos ajustes.

02. O que é um modelo de maturidade de processos?

Toda empresa ou indivíduo que desenvolve software já faz isso por meio de algum processo. Esse processo pode ser caótico, obscuro e até mudar constantemente, mas não deixa de ser um processo. E isso nada mais é do que uma seqüência de atividades. Mesmo que você não se dê conta disto, tudo que você faz no trabalho de desenvolvimento de software segue uma seqüência de atividades. Às vezes essa seqüência não é fixa. Às vezes essa seqüência não segue uma ordem lógica. Às vezes essa seqüência provoca algum retrabalho. Mas perceba que sempre existirá uma seqüência. Às vezes essa seqüência já é eficiente, mas ninguém mais além de você sabe como funciona. Um modelo de maturidade de processos serve para corrigir esses e muitos outros problemas.

O MPS.BR descreve um modelo de amadurecimento gradual dos processos de desenvolvimento de software. Ou seja, você não precisar melhorar tudo de uma vez. Pode fazer isso aos poucos, de forma gradual. É para isso que servem os níveis de maturidade.

Vale ressaltar que o MPS.BR é apenas um modelo. Ninguém é obrigado a segui-lo a risca. Mas...dizem que ele é uma coletânea das melhores práticas relacionadas com o desenvolvimento de software. Assim, talvez valha a pena considerá-lo se não no todo, mas em parte. Entretanto, como ele é uma adaptação do CMMI-DEV, essas melhores práticas foram coletadas em outros mercados, talvez nos EUA e Europa. E isso pode por em dúvida a aplicabilidade dessas supostas melhores práticas a nós, brasileiros. Essa dúvida, porém, só o tempo poderá dirimir.

03. O que é um processo maduro?

Ótima pergunta! Dizer que um processo é, ou não, maduro pode gerar muita polêmica. Na minha opinião, um processo é maduro quando atinge os melhores resultados ao menor custo possível. Espero que concorde comigo nessa idéia (se não, é melhor você parar por aqui). Mas a dificuldade é justamente medir os resultados e o custo.

Portanto, para saber se um processo é ou não maduro, precisamos primeiro conseguir medi-lo. E é justamente esse o objetivo final do MPS.BR: conseguir medir os processos. Na teoria, uma empresa no Nível A do MPS.BR é capaz de medir plenamente seus processos de desenvolvimento de software. Em outras palavras, toda essa história de modelo de maturidade NÃO serve para tornar o processo realmente maduro, mas para saber se ele é ou não. Ao descobrir que um processo qualquer não é maduro, cabe à empresa encontrar formas de amadurecê-lo DE FATO. Mas não fique decepcionado com o MPS.BR. Na prática, as empresas já terão subsídios para amadurecer os processos desde o Nível F. Ou seja, não se precisa esperar até o Nível A para tomar alguma ação corretiva. Que ações a empresa precisa tomar? O MPS.BR não diz. Ainda bem!

E para que um processo possa ser medido e corrigido ele precisa ser transparente e gerenciável. Esse é o ponto mais importante do MPS.BR, por isso vou repetir: para esse modelo de maturidade de processos, um processo é maduro quando é transparente e gerenciável. Tudo o mais gira em torno disso. Se um processo não é transparente, então não pode ser medido. Se não pode ser medido, então não temos como saber se os seus resultados são os melhores possíveis ao menor custo. Se um processo não é gerenciável, mesmo que se possa medi-lo, então não se pode corrigi-lo, melhorá-lo. Se não podemos melhorá-lo, não podemos amadurecê-lo. Essa é a lógica da coisa toda.

04. Maduro para quem?

Maduro para todo mundo, ora bolas!, mas especialmente para os seus superiores hierárquicos. Lembre-se: quando vir a palavra maduro, pense em transparente e gerenciável. Transparente e gerenciável. Nunca esqueça isso.

05. Porque meu gerente está especialmente interessado nisso?

Lembra do transparente e gerenciável? Pois é. Se o processo é transparente, o seu gerente sabe exatamente o que você está fazendo ou deve fazer. Sabe se você está enrolando o serviço. Sabe se você precisa de ajuda para cumprir o prazo. Pode até conferir o que você já produziu. Se o processo é gerenciável, o seu gerente pode aproveitar o que você já produziu e te substituir por outra pessoa. Pode colocar mais alguém para te ajudar. E pode até pedir para você refazer algo antes que seja tarde demais.

Quando o processo é transparente, ele deixa de ser aquela caixa preta que ninguém além de você sabe como funciona. Quando o processo é transparente, fica mais fácil saber quais são os bons funcionários e quais não são. Um processo maduro depende menos dos indivíduos. Afinal, tem muita gente aí fora precisando de emprego.

06. Ah, então devo me preocupar com o meu emprego?

Sim e não.

Se você é um mau funcionário, o MPS.BR vai deixar isso mais evidente pois, como já falei, os processos vão ficando cada vez mais transparentes. Mandar-te embora é uma decisão do seu gerente – o MPS.BR não obriga nenhuma empresa a fazer isso!

Acontecerá justamente o contrário se você for um ótimo funcionário. O MPS.BR vai deixar isso mais evidente e, talvez, você seja até promovido. Na pior das hipóteses, você vai continuar se destacando como bom funcionário. Note que o MPS.BR pretende tornar os processos menos dependentes de indivíduos. Repito: indivíduos. Todo processo sempre dependerá de uma boa equipe. E bons gerentes escolhem bons funcionários para as suas equipes. Ou seja, se é bom funcionário, está dentro!

07. Ok, mas onde entra a documentação nisso tudo?

Sabia que você ia tocar nesse assunto. Após a implementação do MPS.BR, seja qual for o nível, não é raro os desenvolvedores reclamarem da quantidade de documentação que eles precisam produzir. Esse problema, contudo, varia de empresa para empresa.

O MPS.BR não obriga nenhuma empresa a produzir os artefatos X, Y ou Z. Só que ele exige algum resultado para se provar que certos processos foram executados e para permitir o seu gerenciamento. Algumas empresas utilizam formulários de preenchimento manual. Outras utilizam ferramentas onde o preenchimento é quase automático. Se você não está contente com a forma como alguns artefatos são produzidos, procure a área responsável e sugira melhorias. O MPS.BR só é viável se todos se comprometerem com o modelo. Se isso não está acontecendo na sua empresa, a alta direção deveria promover isso com incentivos concretos. Só treinamento não basta.

08. Para que serve essa documentação toda?

Já que você insiste no assunto, vamos lá! Pessoalmente, também não sou muito fã desses artefatos. Nada é melhor que um código bem comentado, um diagrama de componentes e fluxogramas com as regras de negócios. Mas acredito que sempre há uma forma mais fácil e simples de produzir a documentação implícita no MPS.BR.

Vou falar mais sobre isso nos próximos artigos, quando estiver comentando sobre cada processo e seus resultados esperados. Mas em linhas gerais, essa documentação toda serve para tornar o processo mais transparente. Como assim? Explico.

Imagine que você costume anotar em um diário tudo o que fez e fará. Se em um dado momento do dia o seu gerente ler o seu diário, vai saber exatamente o que você fez e o que está por fazer. Se você fez algo e foi bem sucedido, o seu gerente pode entregar uma cópia do seu diário para outra pessoa e pedir para ela seguir os mesmos passos que você. Ainda bem que não se exige de nós um diário na vida real, mas, na prática, temos que registrar o que fizemos e o que pretendemos fazer com alguma freqüência. Tudo isso tem a ver com a transparência que o seu trabalho precisa ter para os seus colegas e seu gerente.

Se mesmo assim você continua achando que a documentação exigida não vale a pena, aguarde meus próximos artigos onde irei dar algumas sugestões práticas de como produzir a documentação com o menor esforço possível e falar um pouco sobre os benefícios de se fazer isso. Ou seja, não é tão ruim assim.

09. Ouvi dizer que tudo precisa ser um projeto; isso é verdade?

É verdade sim. Mas isso é um problema para você? Faz diferença a forma como rotulamos o nosso trabalho? É apenas um rótulo: projeto. Poderia ser demanda, solicitação, pedido, requisição, etc. Mas o pessoal resolveu escolher a palavra projeto. Simples assim.

O que é um projeto afinal de contas? Projeto é um trabalho com escopo, início e fim determinados. Dizem que um projeto só pode ser considerado como tal se o objetivo for desenvolver algo de novo. Mas isso é óbvio! E na verdade tudo que é desenvolvido é algo novo. Se não é novo, já existe e, portanto, não precisa ser feito. Logo, o que precisa ser feito é sempre algo novo em menor ou maior escala. Pense sobre isso. Tirando a correção de erros, TUDO é novo no desenvolvimento de software.

Assim, perceba que não faz diferença chamar o seu trabalho de projeto. Concordo que é um erro do MPS.BR exigir uma rotulação para os trabalhos. Mas, já que não faz diferença, o que custa atender?

10. Ah, mas um projeto é mais burocrático...

Pode até ser. Mas não necessariamente. Como já disse, tudo depende da sua empresa. Algumas atividades são necessárias não por simplesmente existir um projeto, mas por que o processo precisa ser transparente e gerenciável. Nunca esqueça disso.

Aguarde meus próximos artigos onde vou dar sugestões de como desburocratizar essas atividades de projeto.

11. Preciso de alguma ferramenta?

Não. Mas o uso de algumas fica implícito no MPS.BR. Ou seja, não é algo obrigatório, mas muitas vezes é desejável. Aguarde meus próximos artigos que falarei mais sobre isso.

12. O que a empresa ganha com isso?

Bom...não existe nenhum estudo que indique que o valor de uma empresa aumenta após a implementação de algum nível do MPS.BR. Como já disse, a aplicação desse modelo não amadurecerá os processos por si só. Mas dará subsídios para a gerência adotar ações de melhoria com base nas medições dos resultados dos processos.

Vale aqui uma palavra de cautela para aquelas organizações que buscam o MPS.BR: cuidado com a burocratização. Implementar esse modelo não significa necessariamente aumentar a burocracia. É preciso manter o pé no chão e achar formas inteligentes e flexíveis de implementar o modelo sem prejudicar a execução do serviço. É possível? Sem dúvida. Falarei mais sobre isso nos próximos artigos.

Conclusão

Este texto é apenas uma breve introdução ao assunto – o melhor está por vir.

Vimos que o MPS.BR (e por extensão o CMMI) não é esse bicho de sete cabeças que as pessoas imaginam. Isso vai ficar mais claro nos próximos artigos. A chave de tudo, na minha opinião, é a transparência e gestão do processo – com a conseqüente medição.

Contribua com seus comentários; vamos desmistificar esse assunto!

Futuro dos celulares

2008-12-02T16:05:00.002-02:00

Como serão os aparelhos celulares daqui a cinco ou dez anos? Não acho que seja uma previsão díficil de acertar. Mas também não é algo tão óbvio. Venho acompanhando as tendências dessa tecnologia a algum tempo e me arrisco a dar alguns palpites.

Tamanho

Como diz o ditado, tamanho não é documento. De fato os celulares pararam de diminuir. Finalmente perceberam que celulares muito pequenos são extremamente desconfortáveis de usar. Lembro de um celular da Samsung, que mais parecia um chaveiro e era horrível de acertar os botões. Acredito que a corrida por celulares pequenos acabou. O tamanho dos celulares atuais, com exceção do Blackberry (que é ridiculamente grande), parece adequado. Um bom celular não pode ser muito pequeno, nem muito fino. Exageros comprometem o manuseio.

Peso

O peso dos celulares atuais também parece estar adequado. Talvez fique um pouco mais leve, mas não há muito o que se fazer nessa área. Não que não exista tecnologia disponível. Mas simplesmente não é necessário. Um celular leve demais também facilita extravios.

Tela

A tendência da tela é crescer cada vez mais. Logo, logo teremos aparelhos com telas enormes, no estilo iPhone ou maiores. Se houver teclado, esse será embutido, tal como o G1 (nunca teclados tradicionais como o N96 -- estes serão substituídos pela tela ou comando de voz). Acredito também que quase todos os celulares terão telas sensíveis ao toque. Só que as telas serão mais resistentes e menos suscetíveis a riscos.

Teclado

Como já mencinei acima, o teclado tende a ficar embutido pois, em geral, os aparelhos serão sensíveis ao toque. Mas aposto muito mais que o teclado vai é sumir de vez. Com a evolução das telas sensíveis ao toque e dos comandos de voz, o teclado será cada vez menos necessário. Entretanto, como os celulares serão cada vez mais utilizados como computadores pessoais, acredito que logo teremos aparelhos com teclados do tamanho de teclados de notebook projetados sobre uma superfície plana.

Sistema operacional

Esta sim é a área onde acredito que veremos as maiores revoluções nos celulares. Os sistemas operacionais e demais aplicativos estão evoluindo cada vez mais. Percebo uma tendência semelhante ao que ocorreu com os computadores pessoais no século passado. Daqui a dez anos os celulares continuarão vindo com um sistema operacional. Mas será algo básico. Existirão empresas especializadas em sistemas operacionais e aplicativos para celular. Isso já ocorre hoje. Mas em breve as plataformas vão se padronizar e poderemos trocar de sistema operacional como fazemos com os PCs atualmente. Os softwares vão ficar cada vez mais intuítivos e pesados. Acredito que o Android, da Google, por ter sido o primeiro, vai se consolidar como o produto mais utilizado. O pessoal da Apple vai continuar teimoso como sempre foi (pelo menos até que o Steve Jobs morra). Outros sistemas operacionais também existirão. O Linux continuará sendo uma opção pouco utilizada. Haverá também uma versão do Windows para celulares, mas não será tão utilizada. Assim como ocorre hoje com os PCs, haverá uma corrida pelo software mais utilizado, seja um browser, um navegador GPS ou até uma agenda de contatos superinteligente.

Bateria

As baterias não vão durar mais do que duram hoje. Qualquer evolução nessa área vai apenas acompanhar o maior consumo de energia dos celulares do futuro. Isso por que eles serão cada vez mais devoradores de recursos, assim como os PCs de hoje.

Periféricos

No futuro, deverão existir periféricos compatíveis com os celulares. Impressoras e monitores poderão ser conectados aos aparelhos. Os usuários poderão imprimir documentos e imagens direto dos celulares. A integração com o computador também será maior, especialmente para backup e troca de arquivos. A integração com câmeras não será necessária, pois todos os aparelhos já trarão uma de BOA qualidade embutida.

Reconhecimento de voz

Eis um recurso que nunca vingou. Não vingou por que simplesmente não funciona. Mas acredito que logo, logo um iluminado vai finalmente resolver o problema do reconhecimento de voz. Aí, poderemos utilizar o aparelho celular tanto para fazer ligações, quanto para digitar (ditar) longos textos sem a necessidade de um teclado. O reconhecimento de voz também será cada vez mais importante para a indústria em torno dos GPSs.

Conclusão

Considerando tudo o acima, vejo que os celulares não vão evoluir muito do ponto de vista do hardware. A grande revolução virá por meio do software, especialmente com o reconhecimento de voz, touch-screen e integração com outros periféricos. Transformar REALMENTE o celular um PC vai resolver de uma vez por todas a questão da inclusão digital dos países menos desenvolvidos. E tornará a internet REALMENTE acessível a todas as pessoas.

Nova lei do call center

2008-12-02T14:27:00.001-02:00

Perdoem-me os ignorantes jornalistas que não se cansam de escrever sobre a nova lei do call center: essa nova lei não tem nada a ver com call center. A maior parte das mudanças que as empresas terão que fazer não será no call center e sim no resto da empresa. Convenhamos, os call centers não estão atolados de serviço só por que eles são ruins no atendimento(eu sei que são), mas sim por que as empresas são muito ineficientes na prevenção de problemas e distribuição de informações. Assim, eis algumas dicas que essas empresas deveriam seguir para se adaptar à nova lei. Se o que eu vou listar abaixo já fosse prática nas empresas, essa lei sequer existiria.

Melhore o seu site na internet

Os sites parecem até mais bonitinhos, mas estão longe de serem úteis. As empresas falham em colocar conteúdo relevante na internet e, quando colocam, esquecem de atualizar. E não basta colocar conteúdo relevante. As informações devem ser de fácil entendimento. Não adianta disponibilizar as cópias dos contratos, como costumam fazer bancos e empresas de telefonia. É necessário traduzir esses contratos e mostrar ao cliente aquilo que interessa. O básico é responder algumas perguntas. O que posso utilizar? O que NÃO posso utilizar? Quanto vou pagar por isso? Como utilizar? Essas são algumas das perguntas que os clientes se fazem e, como não encontram as respostas em outro canal, acabam ligando para o call center.

Promova a clareza nas suas faturas

As empresas precisam terminantemente abandonar os tradicionais modelos de faturas (contas) adotados atualmente. O cliente precisa ver claramente o que ele utilizou, o que ele poderia ter utilizado mas NÃO utilizou, quanto pagou por isso e como poderia pagar menos. As empresas não podem ser hipócritas. Precisam mostrar aos clientes como poderiam fazer para economizar mais e utilizar melhor os recursos de todos.

Disponibilize formas alternativas de atendimento

Esqueça o call center. A melhor forma de atendimento é a internet. E não basta apenas disponibilizar ferramentas para as pessoas se tornarem clientes. Precisamos de ferramentas para gerenciar nossos contratos. Mudança de planos e tarifas, contratação de novos serviços e cancelamentos devem estar disponíveis na internet e, quem sabe, no celular.

Melhore sua eficiência e promova a fidelidade real

Se as empresas deixassem seus clientes satisfeitos, eles não ligariam para o call center cancelando seus contratos. E, pelo amor de deus, fidelização, no marketing, não é apenas dar um desconto para o cliente e exigir que ele fique com você por mais dois anos. Fidelização envolve manter o cliente satisfeito SEMPRE. Para isso, as empresas precisam estar antenadas com o mercado e promover medidas preventivas. Se a concorrência está oferecendo descontos para novos clientes, ofereça o mesmo para os seus clientes antigos. Seja flexível. Não deveriam existir regras. Apenas uma: manter o cliente.

Promova oficinas

Heavy-users precisam de atedimento especial. E as vezes não basta disponibilizar um passo-a-passo na internet. Alguns recursos especiais devem ser ENSINADOS aos clientes. Afinal, ninguém quer pagar por um serviço que não sabe utilizar. Assim, promova oficinas (workshops). Por exemplo, vamos pegar os bancos. Em grandes agências, deveriam ser promovidos workshops para mostrar aos clientes o potencial da internet e celular. Já no caso das telefonicas, poderiam promover encontros para ensinar clientes a utilizar a internet e outros serviços avançados do celular. A educação é a chave para diminuir o número de ocorrências.

Conclusão

Há muito o que se fazer para diminuir o número de ligações nos call center. Aumentar a estrutura desses canais é apenas um paleativo, tapar o sol com a peneira. As empresas deveriam buscar a excelência naturalmente. Mas já que elas não fazem isso por bem, que façam a força. Parabéns para a nova lei do call center.

Você está em Brasília, cidade dos arrogantes; por aqui não costumamos dar passagem

2008-11-04T14:58:00.001-02:00

Vou começar já arrumando encrenca: Os brasilienses são muito arrogantes. É isso mesmo, você não leu errado. Dizem que o baiano é lerdo, que o mineiro é “mão-de-vaca”, que o gaúcho é muito macho, etc. E se existe algum estereótipo que valha a pena atribuir aos brasilienses, esse é o da arrogância. Os paulistas já perderam esse título para nós há muito tempo. Eu sei que existem pessoas arrogantes em todo lugar. Só que as pessoas daqui ganham com folga. E se você não é daqui, não fique se gabando. Logo logo vai ficar tão arrogante quanto nós. É só uma questão de tempo.

Talvez até seja possível justificar toda essa arrogância. Brasília é a capital do país...a maior renda per capita da nação...a maior proporção de carros por habitante...a sede dos magistrados...até a sede do Banco do Fulano é aqui. Chegaram até ao ponto de "instituirem" a arrogância. Autoridades e altos cargos têm elevadores exclusivos, entradas exclusivas e diversas outras preferências*. Aqui, quase todo mundo é “alguma coisa”. Experimente observar os motoristas que são parados em uma blitz qualquer. Você vai ouvir muita coisa do tipo “sou servidor do tribunal tal”, ou “trabalho no congresso”, ou “meu irmão é policial”, ou “trabalho na diretoria do Banco do Fulano” e assim por diante.

Não sei como isso tudo começou, mas as pessoas aqui acham que esses títulos as tornam melhores do que outros e que, por isso, podem desconsiderar certas leis ou ter preferência em algum direito qualquer. Resumindo: Acham que devem tratar os outros com arrogância.

Talvez você diga: “Ah, isso é verdade, mas EU não sou assim, sou exceção”. Espero do fundo do coração que sim. Mas será que você escapa? Note que essa arrogância afeta todo o nosso cotidiano. Na quadra onde moro, por exemplo, um dos prédios é famoso na vizinhança. E isso não se deve à linda fachada do prédio, nem à bondade dos moradores. Ele é famoso pela arrogância que predomina ali. Lá, de acordo com a convenção do condomínio, pasmem, os empregados são obrigados a baixar a cabeça e a tratar os moradores por doutor ou doutora. Faz alguns dias, um dos zeladores sem querer chamou um “servidor do tribunal tal” de senhor. Qual foi o resultado? Demissão, óbvio.

Claro que esse é um caso extremo. Então vamos falar de algo aparentemente mais sutil, como o trânsito. Preste atenção e você verá que no trânsito a arrogância dos brasilienses fica evidente. Se estiver engarrafado, então aí que o “bicho pega”. Eis os fatos. Em Brasília não se dá passagem. Se você está em uma faixa da pista que está prestes a acabar, os da outra aceleram para não te deixar passar. Se você se aproxima de um carro que está mais devagar, fatalmente ele vai acelerar para você não conseguir ultrapassá-lo. Reduzir para alguém entrar na sua frente? Por aqui não existe tal coisa. Criou-se até o costume de NÃO dar seta. Se você quer mudar de faixa é melhor fazê-lo de supetão, antes que o arrogante da outra faixa perceba e acelere para te bloquear.

Aquela placa na entrada do eixão que diz “Bem vindo à Brasília; por aqui não costumamos buzinar” devia ser substituída por algo como “Você está em Brasília, cidade dos arrogantes; por aqui não costumamos dar passagem”. É como se todos fossem pilotos em alguma corrida e ceder lugar fizesse alguém perder a posição no ranking. Na verdade, a única corrida que se pode imaginar é a corrida da arrogância.

E você? Também é piloto?

* Em países mais desenvolvidos, é comum os executivos compartilharem as mesmas entradas e elevadores dos empregados em geral. Eles consideram isso uma oportunidade para conhecer melhor seus subordinados e isso contribui para uma gestão mais eficaz.

Futebol ou religião? Tanto faz; ou quase

2008-11-04T14:50:00.000-02:00

Dizem que gosto, política, futebol e religião não se discutem. Será?

Para exemplificar, vamos falar dos religiosos. Mas dos religiosos praticantes. Quando digo ‘praticantes’, não estou me referindo àqueles malucos que vestem explosivos, nem àqueles que vivem enclausurados em um mosteiro, nem àqueles que sobem centenas de degraus para pagar promessas e assim por diante. Estou me referindo àquelas pessoas ‘mais normais’, que vão à igreja semanalmente, participam nas atividades que ela programa, fazem orações, caridade e às vezes até algum trabalho de evangelização. Não raro, essas pessoas são consideradas como fanáticas ou intelectualmente inferiores, desprovidas de alguma razão que as demais, não praticantes, supostamente têm. Quem está certo? Bom, não vou entrar no mérito. O que quero destacar é que essas mesmas pessoas que criticam tem cada uma o seu ‘deus’, ou ‘deuses’, só que de formas diferentes.

Como assim? Explico. Basta pegarmos, por exemplo, os ‘fanáticos’ por futebol. Esses são os religiosos mais praticantes que conheço. A freqüência dos ‘cultos’ é de dar inveja a qualquer protestante. Duas ou até três vezes por semana. E isso quando não ocorre o chamado ecumenismo, quando ‘adoradores’ de um time se reúnem com outros de outro time para assistir aos jogos destes. Alguém falou em dízimo? É o que mais tem. Além do ‘sacrifício’ que fazem para assistir aos jogos nos estádios, pagam por isso. Sem falar na compra de camisetas, bonés, bandeiras, canecas, chaveiros, etc. Ah, e tem também aqueles que são sócios do clube e pagam até mensalidades. E não esqueça das enormes quantias que são deixadas nos bares e afins. Não falta nem a evangelização. É isso mesmo! Ou você acha que o torcedor fica desfilando com a camisa do seu time adorado por que ela é mais bonita? Repare nas cores berrantes que andam usando por aí. É claro que o propósito é chamar a atenção para ‘pregar’ a imagem do time. E quando chegam no trabalho, a primeira coisa que fazem é discutir qual time é o melhor. Isso sem falar nos buzinaços, nas gritarias, nos fogos de artifício, etc. Quer saber, prefiro que um ‘pregador’ toque a minha campainha uma vez por mês do que aturar a gritaria do meu vizinho fanático por futebol todo domingo à tarde.

Mas, apesar de todas essas similaridades, existe uma diferença muito importante entre religião e futebol. Os religiosos praticantes esperam um dia ganhar a ‘salvação’. E os adoradores do futebol, o que esperam? Que o seu time seja ‘salvo’ do rebaixamento? Ganhar o campeonato? O que eles ganham com isso? Que razão há nisso? Se você quer diversão, então torça pelo melhor. Se você quer emoção, então torça para quem está na zona de rebaixamento, seja o time que for. Uma coisa é ter afinidade por um time que está bem tecnicamente. É gostoso assistir uma partida quando o time está jogando bem. Outra coisa é ser fiel ao brasão e defendê-lo com ‘unhas e dentes’. Para que a fidelidade? Nem os sacerdotes, isto é, nem os jogadores são fiéis. Por que você quer ser? Acha que vai fazer alguma diferença?

O futebol foi só um exemplo. Mas existem tantas outras ‘religiões’ por aí e cada qual com o seu grau de fanatismo. Aliás, parece que faz parte da natureza humana se apegar a esse tipo de devoção. Existem até os fanáticos por trabalho, que chegam a ponto de ignorar a família por isso! Portanto, antes de criticar a fé de alguém, reflita na sua própria vida. É bem provável que você já tenha sua própria religião e nem se deu conta disso. Amém.

Mudança de assunto

2008-11-04T14:41:00.001-02:00

A partir de hoje, o foco das matérias do blog deixa de lado a gestão de TI para adotar uma visão mais genérica. Continuarei publicando matérias sobre o mercado de trabalho na área de TI. Mas passarei a publicar também crônicas e artigos sobre trabalho de forma geral. Quando oportuno, não deixarei de fazer críticas à gestão de TI como vinha fazendo. Além disso, me permitirei publicar crônicas sobre o dia-a-dia. Dessa forma, espero atingir um público mais amplo e tornar as matérias mais interessantes. Um abraço e boa leitura!

Fumar ou cortar o cabelo? Tanto faz

2008-08-13T23:17:00.008-03:00

Vou deixar a TI um pouquinho de lado, para falar de um assunto bastante polêmico: controle do horário de trabalho. Cada gerente tem a sua própria teoria e estilo de liderança. Mas os administradores devem refletir mais sobre isso, pois podem estar fazendo caso de algo que não vai trazer nenhum resultado positivo. E pode ser que seja até negativo. Emfim, a crônica abaixo deixa isso bem claro. Espero que gostem.

O fim-de-semana se aproximava e a cabeleira estava enorme. Horrível. Precisava cortar o cabelo naquela sexta-feira ou seria tarde demais. Desci rapidinho do meu prédio e fui a um salão no prédio ao lado tentar agendar um corte no meu horário de almoço daquele dia. Perguntei ao cabeleireiro se havia disponibilidade. “Horário tem, mas por que não cortar agora?”, perguntou. Respondi que não podia, pois estava no meu horário de trabalho. Surpreso com a resposta, ele continuou: “Mas os seus colegas de prédio descem para fumar várias vezes ao dia, em algumas ocasiões ficando até meia hora fumando. Por que você não pode fazer isso ‘uma vez na vida’ por apenas vinte minutos? Se alguém perguntar, diga que está fumando, ora bolas!”. Apesar da insistência, mantive minha posição e voltei lá na hora do almoço conforme acordado. Mas aqueles comentários ficaram martelando na minha cabeça o dia inteiro. Peguei uma folha de papel e rascunhei alguns cálculos. Incrível! Uma pessoa que descesse duas vezes por dia, para fumar durante uns quinze minutos por vez, gastaria no final do mês cerca de 10 horas! Fiquei revoltado. Me senti um completo idiota. Por que alguns podem gastar tanto tempo fumando e eu não posso usar vinte minutos para cortar o cabelo a cada dois meses?! Há algo claramente injusto nessa história toda. Quase babei de raiva. Contei até 100 e, depois de me acalmar, comecei a raciocinar. Os intervalos para fumar são bem conhecidos e aceitos pelas empresas. Algumas até incentivam, criando áreas próprias para isso. Outrossim, a produtividade dos que fumam deve estar dentro do esperado: do contrário, estariam reprovados. Assim, podemos concluir que trabalhar 10 horas a menos não afeta a produtividade de forma geral. Logo, fazer caso de ‘mixaria’ no ponto eletrônico não faz o menor sentido. As empresas não ganham com isso. E os funcionários só perdem. O problema é que muitos gerentes usam a legislação como desculpa para a sua inflexibilidade. Ora, sabemos que a legislação trabalhista é muito antiga e, comparada com países mais desenvolvidos, totalmente antiquada. Além disso, quando trata de horário de expediente, a legislação serve para proteger os direitos do trabalhador – não para justificar o rigor dos administradores. Os conceitos hoje estão distorcidos. Quem é o louco que vai processar a empresa por que foi liberado uma hora mais cedo para ir ao médico? Se ganhasse, teria que devolver uma hora de remuneração com correção monetária mais honorários advocatícios. Um absurdo! Espero que um dia essa ‘economia de palito’ acabe. Um dia vou poder descer do prédio, dar uma ‘alozinho’ para os meus colegas fumantes e ir cortar o cabelo, ou ao médico. Ninguém perde. E alguns ganham. Melhor.

Futuro dos programadores

2008-08-11T20:01:00.005-03:00

No artigo do dia 26/07, sobre o futuro dos programadores, comentei algo sobre o Microsoft Surface. Essa tecnologia, na minha opinião, vai revolucionar as interfaces gráficas e permitir novas aplicações de software. Tive a curiosidade de visitar o blog da equipe de desenvolvimento desse produto e encontrei alguns vídeos que até então não tinha visto. Achei interessante o vídeo abaixo. Ele dá uma boa amostra sobre as possibilidades atuais e por vir.

Video: Microsoft Surface at the Rio in Las Vegas

Caia na real: sua empresa pode ser mais produtiva

2008-08-11T19:46:00.008-03:00

Menos pode ser mais. E quando o assunto é produzir software, primar pela simplicidade pode trazer ótimos resultados. E não é isso que toda empresa quer? A sua também? Então é hora de cair na real. Recentemente, uma empresa tem se destacado por pregar a simplicidade de software -- a 37signals. Eles publicaram um livro chamado Getting Real (Caindo na Real) que, apesar de muito polêmico, tem convencido gestores de TI do mundo inteiro a simplificarem seus processos de desenvolvimento e seus produtos. O livro pode ser lido on-line gratuitamente através do endereço: http://gettingreal.37signals.com/. Existe uma versão em português também que pode ser acessada nesse mesmo endereço.

Leitura obrigatória para desenvolvedores, supervisores e CIOs.

Boa leitura!

Ainda faltam programadores no Brasil...e no mundo!

2008-08-02T17:56:00.006-03:00

Em maio, no meu artigo "Faltam programadores no Brasil", comentei que a demanda neste mercado é crescente. Ainda fico devendo aquele roteiro para quem quer começar nessa área, mas aí vai uma dica para aqueles que ainda não encontraram emprego. A ferramenta de recrutamento da IBM agora está funcionando no Brasil. Trata-se doGlobal Opportunity Marketplace, ou simplesmente GOM. Mais informações podem ser encontradas nos sites

http://www.ibm.com/br/employment/send.phtml e

https://jobs3.netmedia1.com/cp/search.jsp.

Sucesso a todos!

Os programadores deixarão de existir? Quando?

2008-07-26T20:41:00.015-03:00

Não. Pelo menos até o surgimento de um programa com inteligência artificial suficiente para fazer outros programas -- e isso está um pouco distante da realidade considerando o grau necessário para a substituição.

Só que não faltam aqueles que profetizam o fim dessa profissão. Argumentam que assim como ocorreu com os digitadores, será com os programadores.

O fato é que a realidade indica que ainda existe muito esforço de programação a se fazer. Durante o seu dia-a-dia, pare e se pergunte: quantos processos de negócio ainda podem ser automatizados? O campo é vasto, muito vasto. Sabe aquele aparelhinho que todo mundo tem? É ele mesmo: o celular. Garanto que você tem pelo menos um. E não é só você. Crianças, idosos, pobres e ricos: todos podem ter um. Agora imagine a quantidade de processos que podem ser integrados ao celular: compras, dinheiro eletrônico, identidade eletrônica, controle de acesso, cinemas, reservas de restaurantes, avisos de trânsito, gps, catálogos etc... Percebeu como os programadores continuarão sendo tão importantes?

Contudo, não é isso que vai garantir emprego para a oferta de programadores do mercado. Na verdade, não consigo conceber que ainda se façam programas como são feitos hoje. Mesmo tirando o trabalho pesado que é feito em grande parte pelo middleware, ainda se perde muito tempo codificando regras de negócio. E isso é muito trivial. É sempre o mesmo blá-blá-blá: dados de entrada > processamento > dados de saída. Tudo é muito repetitivo. Praticamente tudo pode ser substituído por um fluxograma. Lembrou dos digitadores de antigamente? Pois é. Eu também. Mas acredito que uma onda muito forte vai balançar a tecnologia nos próximos anos. E essa onda tem a ver com usabilidade. Guarde essa palavra!

A preocupação com usabilidade não é de hoje. Contudo, desde o lançamento do mouse, não houve nada de extraordinário nesse campo. Janelas, menus, ícones, botões e as vezes um arrastar e soltar. Tudo não passa disso. Bem, tudo não passava disso. Até que chegou o iPod e o iPhone. A criativade do pessoal da Apple correu solta. O resultado foram grandes novidades na interface com o usuário. Não vou dizer que foram inovações. Mas que foram novidades, ah, isso com certeza! Alguns recursos visuais já eram largamente utilizados em jogos. Mas até então, pouco disso era explorado em interfaces com utilitários e outros aplicativos em geral.

Isso nos faz perceber que as interfaces estão muito longe da praticidade que se pode obter. A usabilidade poderia ser muito melhor. As interfaces poderiam ser mais parecidas com o mundo real. Outro dia estava olhando os vídeos do Microsoft Surface. É sensacional. Mas programar aquelas interfaces com o usuário não é nada trivial. Há que ter muita criatividade. E cada integração com o mundo externo é um caso à parte. Isso é o futuro! Usabilidade. Integração. Convergência. Quero resolver minha vida ou no celular, ou no monitor, ou na minha mesinha da sala de estar. Quero facilidade de uso. E todos querem isso também.

Programadores, atenção para as APIs gráficas!

Faltam programadores no Brasil

2008-05-14T10:18:00.004-03:00

Há alguns meses, li um artigo do Plantão Info (http://info.abril.com.br/aberto/infonews/) sobre a carência de mão-de-obra no setor de software brasileiro (http://info.abril.com.br/aberto/infonews/122007/18122007-1.shl). É um artigo interessante que confirma algo que já suspeitava: faltam programadores no Brasil. Por isso, é comum encontrarmos profissionais de outras áreas trabalhando com software. Já vi de tudo nessa vida. Administradores, advogados, teólogos e até médicos foram parar na área de desenvolvimento de sistemas das grandes empresas. Qual é o resultado disso? O resultado é que as empresas brasileiras gastam horrores com treinamento, perdem em produtividade e em qualidade. Além disso, não conseguem concorrer com as empresas lá fora.

No artigo citado, encontrei vários comentários de supostos profissionais desacreditando o artigo. Alguns desses profissionais, aparentemente bem qualificados, já estavam desempregados há meses e, por isso, acreditavam que a demanda por programadores não era tão grande como o artigo colocava. Não sei exatamente qual a situação dessas pessoas, mas percebo realmente uma demanda crescente por programadores. Basta olhar as ofertas de empregos. Aqui em Brasília, onde moro, esses profissionais são disputadíssimos. Os salários não são lá essas coisas, é verdade. Mas isso é assunto para os economistas. Por tudo isso, aí vai uma dica para aqueles que querem investir em uma profissão: seja um bom programador!

Formação superior na área é desejável. Mas você pode provar que dá conta do recado se tirar algumas certificações. Bom raciocínio lógico e matemático e gostar de se atualizar e de ler são essenciais para quem quer ser bem sucedido no setor de software. Se você está começando agora, um bom ponto de partida é estudar modelagem de dados. Depois disso, pode começar a estudar programação propriamente dita, mas não deixe de ler um pouco sobre análise e projeto de sistemas. Escolha uma linguagem (Java e Python estão em alta) e um ambiente (existem boas opções que utilizam software livre). O próximo passo é se certificar. Futuramente vou publicar um roteiro mais detalhado para quem quer se tornar um programador. Também estou preparando outro artigo sobre o futuro do desenvolvimento de software e como isso afeta a vida dos programadores.

Documentação de software: vale a pena?

2008-05-08T17:12:00.004-03:00

Hoje vou levantar um assunto polêmico: documentação de software. É incontestável a importância da documentação em quase todo processo de desenvolvimento de software. Documentar software traz diversos benefícios para a equipe de desenvolvimento. Mas não vou perder tempo aqui citando esses benefícios. Não faltam textos sobre esse tema. O que falta é bom senso na hora de decidir se um artefato de documentação deve ou não ser produzido.

Afinal de contas, para que a documentação serve? Serve para três propósitos principais: reduzir os riscos no início do desenvolvimento, facilitar a manutenção e, se for o caso, viabilizar a subcontratação. Na sua organização, talvez a documentação de software sirva a outros propósitos. Mas vamos nos concentrar nesses três, por enquanto. Vamos analisar cada um deles com um pouco mais de detalhe.

Reduzir os riscos no início do desenvolvimento

Quanto mais informação tiver sobre um sistema, menor é o grau de incerteza do desenvolvimento. Por exemplo, um levantamento de requisitos bem feito e com um razoável nível de detalhe vai evitar "surpresas" no meio do desenvolvimento. Mas a produção de artefatos de documentação tem um custo alto se comparada com outras abordagens para reduzir a incerteza de uma demanda de software. Cabe a cada equipe avaliar o seu custo de produção de alguns tipos de artefatos e decidir por aqueles que apresentam um menor custo e um benefício similar. Por exemplo, talvez uma lista de casos de uso seja suficiente e, ao invés de detalhar os fluxos de cada um deles, se possa adotar uma abordagem envolvendo técnicas de prototipação.

Facilitar a manutenção

Outro propósito da documentação é fornecer subsídios à pessoa responsável pela manutenção de um artefato de software. Ter em mãos um modelo de dados ou qualquer outro diagrama facilita a execução de qualquer alteração. Contudo, perceba que muitos artefatos de documentação são pouco ou sequer consultados diante da necessidade de uma alteração. Mesmo aqueles que poderiam ser consultados às vezes estão desatualizados – o custo de atualização é muitas vezes alto. E pode ser até que a documentação exista, esteja atualizada e seja útil para a manutenção. Mas neste último caso, a rastreabilidade dos artefatos de software pode não existir ou não ser confiável. O fato é: é alta a probabilidade de a sua documentação não servir simplesmente para NADA. Assim, vale a pena verificar com a sua equipe se a documentação está sendo atualizada e se ela é vista como útil pelos seus desenvolvedores.

Viabilizar a subcontratação

Subcontratação é um assunto delicado. Às vezes a empresa subcontratada estipula no contrato uma gama de artefatos de documentação que acabam por contribuir pouco para reduzir o grau de incerteza e aumentam o custo daquela que contrata. Às vezes é tão caro produzir a documentação exigida quanto desenvolver o software propriamente dito. Quer um conselho? Inclua no contrato um acordo de níveis de serviço e encontre uma forma de incluir a subcontratada desde o início do processo – de preferência já no levantamento de requisitos – e deixe que ela produza seus próprios artefatos.

Conclusão

É claro que falando assim tudo PARECE muito simples. Na prática você terá que ir substituindo seus artefatos de forma progressiva, sempre provendo o treinamento necessário para os membros da sua equipe. Sinceramente, acredito muito pouco em qualquer documentação. Na prática, as empresas acabam quase sempre dependendo das informações contidas na cabeça de cada pessoa. Mas não adianta ser tão radical – escrever sempre é bom para clarear as idéias. Pensando nisso, acho razoável considerar a produção dos seguintes artefatos de documentação:

- Lista de casos de uso.
- Modelo de dados.
- Protótipo de telas e/ou relatórios.
- Diagrama de componentes.
- Comentários de código (esse é o mais IMPORTANTE).

Faça o seu trabalho e deixe que os outros façam o deles

2008-05-07T12:33:00.003-03:00

Um dos erros que mais encontro na gestão de qualquer equipe de desenvolvimento é SEPARAR as pessoas na hora de distribuir demandas de projetos ou demandas de versionamento/manutenção (quando digo manutenção me refiro a correção de problemas de forma reativa ou próativa). É um erro separar pessoas para cada tipo de demanda e isso é verdade por diversos motivos. Vou falar um pouco do principal deles que tem a ver com o aproveitamento ótimo do tempo.

Em uma grande empresa, o trabalho de um desenvolvedor quase sempre "esbarra" na dependência de outras pessoas. São os gargalos que existem em quase toda fábrica de software. E esses gargalos são muito mais comuns nos projetos. É o modelo de dados que precisa ser aprovado pela área de administração de dados. É o ambiente que precisa ser criado pela área de infraestrutura. Esses são apenas alguns exemplos, mas com certeza o pior deles é o levantamento de requisitos. O tempo que se gasta "esperando" as definições dos clientes gera muita ociosidade. Todos esses gargalos deixam o desenvolvedor na espera. Como resolver isso? Simples: distribua demandas de versionamento/manutenção para TODOS. Essas demandas são geralmente mais simples, consomem menos tempo e esforço e muitas vezes não dependem de mais ninguém. Receber demandas desse tipo permite ao desenvolvedor aproveitar melhor o seu tempo.

Ah!, mas talvez você diga: "Se eu distribuir várias demandas para uma pessoa ela não vai saber administrar bem o tempo e cumprir com o planejamento do projeto". Corretíssimo! Mas quem disse que ela tem que saber administrar bem o tempo dela? Isso é papel do supervisor, gerente funcional ou sabe-se lá como essas pessoas são chamadas na sua empresa. A verdade é: não cabe ao desenvolvedor planejar e estabelecer prioridades -- esse não é o seu papel. Se você, GERENTE, trabalha simplesmente DISTRIBUINDO trabalho à sua equipe, acorde para a realidade. É hora de fazer valer o seu salário. É o momento de planejar e estabelecer prioridades. Não deixe isso na mão da sua equipe de desenvolvimento. Faça o SEU trabalho e permita que a sua equipe faça o dela usando 100% do tempo. E os benefícios vão mais além. Distribuir vários tipos de demanda para a mesma pessoa vai evitar que o trabalho se torne entediante e desmotivador. Contribui para a disseminação do conhecimento e diminui a dependência da empresa por certas pessoas. É claro que tudo isso tem um custo: o gerente precisa fazer o seu trabalho. Você está fazendo o SEU?

Desenvolvendo software em uma grande empresa

2008-05-06T22:02:00.007-03:00

Quero falar com você, programador, analista de sistema ou gerente de projetos. É bem provável que você, assim como eu, trabalhe em grande empresa onde os sistemas são críticos para os negócios da corporação. Em uma empresa assim, não é fácil manter a produção de software sob controle. É comum observarmos problemas de retrabalho, várias pessoas fazendo exatamente a mesma coisa, processos de desenvolvimento que não agregam valor e assim por diante. A lista de problemas parece não ter fim. E lá estamos nós no meio desse caos tecnológico. As vezes fico desanimado em ter que percorrer um emaranhado de soluções para resolver problemas tão simples. As vezes fico desesperado sem saber O QUÊ e COMO desembaraçar essa trama. E você? Também passa por isso no seu dia a dia?

Inauguro esse blog para publicar uma série de artigos sobre o CAOS que impera hoje nas áreas de tecnologia de grandes empresas. Espero contribuir para o pensamento crítico de todos os envolvidos, especialmente aqueles que tem o poder de mudar. Mas não me refiro apenas aos executivos e gerentes. Todo aquele que tem iniciativa também pode fazer algo para diminuir essa confusão. Boa leitura!