Os punidos foram os brasileiros ou WhatsApp?

Na mesma semana em que o país foi rebaixado pela agência Fitch, o Supremo Tribunal Federal (STF) faz um julgamento para definir o rito do Impeachment, nós vemos um juiz decretar o bloqueio do WhatsApp em um processo que corre em segredo de justiça. Existem membros da corte do STF que participaram do julgamento do Collor de Melo. Como a constituição e a lei do impeachment é a mesma do julgamento do Collor não seria o caso de repetir o mesmo rito usado e poupar tempo e dinheiro dos brasileiros?

Parece que o poder judiciário brasileiro quer viver em um universo paralelo e ficar discutindo o mesmo assunto dezenas de vezes. Porque perder tempo debatendo um rito que já foi usado no Brasil nos anos 1990s. O poder do desperdício é tão intenso que no começo do ano de 2015 um juiz decretou o bloqueio do WhatsApp e no final do mesmo ano um outro juiz coroou o Brasil com a mesma decisão. Nos dois casos a decisão de bloqueio foi revogada em pouco tempo. Também nos dois casos a alegação foi a mesma. A empresa recusou quebrar o sigilo do seu usuário e optou por cumprir a lei dos estados unidos.

Quem na realidade foi punido com a decisão de bloqueio? Foi a WhatsApp ou foram os brasileiros? Para a WhatsApp as perdas foram nulas ou mínimas. No entanto para os brasileiros donos de pequenos negócios as perdas foram intensas. O artigo Sem WhatsApp, profissionais "apelaram" para ligações e SMS para comunicação (http://tecnologia.uol.com.br/noticias/redacao/2015/12/17/sem-whatsapp-profissionais-usaram-telefone-e-sms-para-retomar-atividades.htm, acessado em 21/12/2015) revelou o tamanho destas perdas.

Muitos podem na sua completa ignorância digital imaginar que a truculência é um caminho sem reação na Internet. Estas pessoas não poderiam estar mais erradas. Em poucos minutos após o bloqueio passou a circular notas na Internet revelando como usar o Virtual Private Network (VPN) para burlar o bloqueio do WhatsApp (“Veja como driblar o bloqueio do WhatsApp no Brasil”, http://olhardigital.uol.com.br/noticia/veja-como-driblar-o-bloqueio-do-whatsapp-no-brasil/53783, acessado em 21/12/2015) ou como instalar um outro programa de mensagem (Telegram ganha 1,5 milhão de usuários brasileiros após queda do WhatsApp, http://olhardigital.uol.com.br/noticia/telegram-ganha-1-5-milhao-de-usuarios-brasileiros-apos-queda-do-whatsapp/53786, acessado em 21/12/2015)

A Internet é um canal onde existem reações para as ações. Ela não é o território que muitos brasileiros estão acostumados em que uns poucos mandam e o restante tem que pagar o pato da Contribuição Provisória sobre Movimentações Financeiras (CPMF).

Para os que passaram a usar o VPN, o bloqueio foi rompido imediatamente, pois o roteamento dos pacotes foi feito pela rede internacional. Para os que optaram por usar um outro aplicativo como o Telegram o bloqueio também foi rompido instantaneamente. Enfim apenas os usuários menos avisados é que sofreram com o bloqueio do WhatsApp. Em pouco tempo, estes usuários também vão instalar o VPN nos seus equipamentos e medidas como o bloqueio de aplicativos não vão ter efeito prático algum.

Será que não seria mais fácil e efetivo que o judiciário do Brasil firmasse um acordo com o judiciário dos Estados Unidos para resolver em definitivo o problema de quebra de sigilo? O artigo “O affaire do WhatsApp” publicado no jornal Folha de São Paulo na sexta-feira dia 18 de dezembro de 2015 (http://www1.folha.uol.com.br/colunas/helioschwartsman/2015/12/1720541-o-affaire-do-whatsapp.shtml, acessado em 21/12/1015) expressa uma das poucas vozes nacionais que estão clamando pelo correto entendimento de como funcionam os serviços através da Internet e a importância de estabelecer acordos de colaboração entre os judiciários dos países.

As perdas impostas pelo bloqueio para a combalida economia brasileira que sofre uma recessão próxima de 4% são imensas. Até quando o país vai viver com tais perdas? Já passou da hora de ser arrogante. O momento exige medidas mais inteligentes e acordos internacionais. É o caso de estabelecer um fórum internacional para tratar das questões jurídicas da internet.

Também é preciso maior transparência nas ações. Até agora não foi revelado como o bloqueio do WhatsApp foi realizado. Será que os pilares da privacidade e da neutralidade da rede do Marco Civil de Internet não foram derrubados para a execução deste bloqueio? Eu gostaria muito que a Anatel divulgasse como o bloqueio foi realizado.

Tradicional x Moderno - Realidade contra Falsidade

Recentemente eu li um artigo que comparava o ITIL (Information Technology Infrastructure Library) e CMMI (Capability Maturity Model Integration) em relação ao DevOps. O autor apresentou com ênfase diversas vantagens do DevOps. Infelizmente, o texto estava impregnado de desconhecimento sobre o que foi chamado pelo autor de métodos tradicionais. Vários dos benefícios atribuídos ao DevOps em relação aos métodos tradicionais não são benefícios reais. São apenas e tão somente erros. Os erros cometidos não eram consequência dos processos dos métodos tradicionais, eles eram o resultado da falta de capacidade e conhecimento dos profissionais envolvidos no planejamento dos projetos.

Para ficar mais claro vou pontuar cada um dos benefícios atribuídos ao DevOps. O primeiro é muito citado em diversos artigos e diz que métodos ágeis como o DevOps são capazes de oferecer entregas frequentes de pacotes menores e por causa disto mais rápidas. Este estratagema dos métodos ágeis assegura um ciclo permanente de evolução da entrega e prazos menores. Na prática, basta que o gerente de projeto ou portfólio planeje o projeto em unidades funcionais enxutas onde as entregas são rápidas, frequentes e evolutivas para o que o planejamento enderece a necessidade de velocidade e flexibilidade do negócio.

Tal planejamento é possível de ser executado em qualquer metodologia existente na face terrestre. Não é uma vantagem dos métodos ágeis. É uma vantagem da contratação de profissionais qualificados para o planejamento do projeto. A segunda vantagem atribuída ao DevOps é que o mesmo não segura a equipe de testes parada enquanto o desenvolvimento faz o seu trabalho. Novamente não estamos falando de uma vantagem do DevOps em relação ao ITIL ou CMMI. Se em um projeto de ITIL ou CMMI a equipe de testes ficava parada esperando o desenvolvimento, isto é um erro do planejamento. O profissional que planejou o projeto não tinha conhecimento e capacidade para gerir o mesmo. Não existe um único processo nestas ferramentas que exija que a equipe de testes fique parada esperando o desenvolvimento.

O autor cita como vantagem para o DevOps em detrimento das técnicas tradicionais a pequena quantidade de funcionalidades novas que são transportadas para o ambiente de produção. O que ele descreveu foi um erro de planejamento do projeto. O envio de muitas funcionalidades novas para a produção não é uma característica intrínseca do modelo ITIL ou CMMI. Os dois modelos permitem o envio de apenas uma nova funcionalidade para a produção. A quantidade de novas funcionalidades para a produção é escolhida pelo gerente do projeto. Profissionais capacitados sabem o que podem fazer em um projeto e qual é o impacto das suas decisões.

No próximo item o autor do artigo comete dois equívocos simultâneos. Quando ele afirma que uma grande entrega consome muito processamento por conta de trabalho duplicado ele assume erradamente que o ITIL e o CMMI geram obrigatoriamente pacotes grandes para entrada na publicação. Em nenhum destes dois métodos existem determinações ou especificações sobre o tamanho do pacote a ser publicado. É o gerente do projeto que vai decidir o tamanho do pacote que será publicado. Além disto, um pacote grande só gera o desperdício de retrabalho quando existem erros de planejamento. Um gerente de projetos capacitado não comete estes erros em qualquer modelo que ele esteja utilizando. Novamente não é um benefício gerado pelo DevOps.

No quinto item o autor apontou benefícios do DevOps para o inventario. Novamente ele aponta o problema de um pacote de publicação grande. Por conta disto, o benefício apontado é um equívoco. Em nenhum momento o ITIL ou CMMI exige ou obriga que os pacotes publicados sejam grandes. Quem define isto é o gerente do projeto. No texto, o autor afirmou que o inventário mais afetado era o de Work In Progress (WIP) que são os materiais ou componentes que estão na fase de transformação para o produto acabado. Foi afirmado erradamente que uma publicação grande tem muitos itens em WIP e por causa disto o desenvolvimento é um gargalo e que os envolvidos nas próximas etapas ficam em compasso de espera por muito tempo gerando desperdício de recursos, tempo e dinheiro. O equívoco da afirmação está na dimensão que estas perdas são consequências de um pacote grande de publicação.

O problema do tempo de espera elevado é consequência de um planejamento falacioso não do tamanho do pacote. Isto significa que não devemos atribuir ao DevOps a virtude da solução da eliminação do desperdício da espera. Um planejamento adequado para a entrada de um pacote grande na produção impede que existam gargalos e perdas de recursos, dinheiro e tempo por causa de espera. Um gerente de projetos qualificado é capaz de identificar todos os gargalos do projeto e encontrar soluções compatíveis com o negócio. Estas soluções são independentes dos modelos adotados.

O sexto item apontado foi o movimento, onde várias funcionalidades estão sendo desenvolvidas por diversas equipes. A sexta vantagem do DevOps sobre o ITIL e CMMI apontada pelo autor foi a movimentação, ou seja, as várias funcionalidades que estão sendo desenvolvidos pelos diversos times estão navegando entre as raias dos processos. Os responsáveis pela qualidade estão neste caso recebendo informações de diversos times sobre a mesma funcionalidade. Mais um equívoco é cometido pelo autor. Em nenhum momento o ITIL ou CMMI determina a quantidade simultânea de funcionalidades desenvolvidas. Este é mais um caso onde o gerente do projeto é o responsável pela decisão. No desenvolvimento do cronograma ele define quantas funcionalidades serão desenvolvidas simultaneamente.

No sétimo e último benefício do DevOps apontado pelo autor que uma entrega grande aumenta a probabilidade de defeitos após o lançamento. O propalado benefício é apenas e tão somente mais do mesmo equívoco. Em nenhum momento o ITIL ou CMMI determina o tamanho da entrega. O responsável pelo tamanho da entrega de um projeto é o gerente do projeto. Ele escolhe o que será entregue e quando será no desenvolvimento do cronograma do projeto. Infelizmente o artigo que li revela que existe um profundo desconhecimento sobre as ferramentas de governança disponíveis no mercado. Tem-se a pretensão de identificar benefícios que em geral são inexistentes por ouvir falar. Em nenhum momento é colocado o dedo na ferida e apontado que as decisões pobres dos gerentes dos projetos estão comprometendo o seu desenvolvimento. Estas decisões pobres são tomadas quer o modelo em uso seja o ITIL, CMMI ou DevOps. Simplesmente trocar de modelo como proposto pelo autor de ITIL para DevOps não vai resolver o problema brasileiro de desenvolvimento. Aliás os números de 2015 mostram que os resultados continuam tão pobres como sempre foram. É preciso evoluir a honestidade intelectual e afirmar que o real problema do desenvolvimento é a falta de capacitação do gerente de projetos. As certificações de gerenciamento de projetos existentes no mercado brasileiro são claramente insuficientes para aferir o nível mínimo de qualificação que um gerente de projetos tem que ter para gerar resultados aceitáveis.

O desenvolvimento é pobre não por causa dos modelos utilizados, mas sim por causa da falta de conhecimento do gerente do projeto. No Brasil, muitos querem ser gerentes de projetos. Este trabalho é para profissionais experientes que são capazes de identificar os desafios e elaborar um plano de projeto capaz de gerar um resultado positivo. Existem no mercado profissionais que acham que o fato deles não conseguirem resolver um problema isto significa que o problema é insolúvel quando na realidade os profissionais qualificados estão resolvendo este problema. É por este motivo que o Brasil ficou na rabeira no mercado de software.