Esse post não é meu, encontrei-o quando procurava sobre o assunto no google. Achei tão interessante e relevante que tomei a liberdade de transcrevê-lo para cá. Mantive todos os links originais.

Faz um tempo que penso em escrever algumas coisas sobre produtividade e ambiente de trabalho e vou começar com um assunto bem legal e controverso: Faz sentido bloquear internet em uma empresa ou área de desenvolvimento de software?

É claro que já vivenciei inúmeras situações ridículas envolvendo esse assunto, mas o que me levou a escrever sobre isso foi um fato que aconteceu hoje e me deixou refletindo por alguns bons minutos. Vou resumi-lo pra vocês:

Um desenvolvedor do meu time, que está no cliente para realizar algumas melhorias num sistema que foi desenvolvido pelo cliente me chamou no msn (ele estava no celular) com uma dúvida sobre Linq. Ele queria saber algo sobre uma clausula de filtro em particular. Eu dei uma dica de como ele poderia usar o Linq pra resolver, mas não me lembrava da sintaxe exata. Então, expliquei pra ele o conceito (eu quase nunca passo somente uma linha de código sem primeiro discutir o porque e o conceito envolvido) e disse o caminho pra resolver. Sobre a sintaxe eu falei pra ele procurar no google e aplicar… fácil certo?

Nem tanto  pois a empresa em que ele estava bloqueia totalmente o acesso à internet. Nem o google é aberto pra pesquisa. E ele estava dentro de uma área de desenvolvimento de software e TI de uma gigante na área de comunicação e telefonia.

O pior é que tenho visto cada vez mais empresas do segmento de TI e desenvolvimento de software partindo para ações como essa. Podemos ver alguns níveis de bloqueio nessas empresas:

1. Redes sociais como Orkut e Facebook;
2. Sites de vídeos como youtube e cia;
3. Twitter;
4. Instant messaging como msn, G-Talk, Skype, etc;
5. Blogs e conteúdo de notícias;
6. Internet banking e emails pessoais;
7. Finalmente, bloqueio total de qualquer site inclusive google.

Pessoalmente, posso dizer que consigo “engolir” justificativas para os dois primeiros da lista. O primeiro porque eu não gosto e não vejo a mínima razão para utiliza-los no trabalho mesmo. O segundo porque em empresas onde a internet é compartilhada com muita gente (caso de onde trabalho), mesmo que a banda seja boa, streaming de video realmente quebra as pernas.

Agora, para todos os demais itens da lista eu só consigo visualizar uma coisa: Retrocesso Empresarial!!!

É interessante pensarmos em porque uma empresa chega ao extremo de bloquear todo acesso de internet de um time que desenvolve software ou trabalha com TI em geral. O que vemos pelo mercado é mais ou menos isso:

1. Internet diminui a produtividade e o foco do trabalho;
2. O profissional deve utilizar seu tempo livre para estudar e não o da empresa;
3. Não é preciso pesquisar sobre desenvolvimento na internet. Profissional bom é o que “domina” a sintaxe da linguagem;
4. Problemas de segurança, como por exemplo enviar um arquivo confidencial por email.

Vamos dar uma boa olhada em cada uma delas:

Internet diminui a produtividade e o foco do trabalho

Será? Depende muito do ponto de vista do qual se está avaliando. Como você enxerga produtividade na sua empresa quando falamos em desenvolvimento de software? Ainda é baseada na quantidade de horas que um profissional “lança” numa atividade ou numa timesheet? Se for isso, então talvez você tenha razão e podemos parar por aqui.

A verdade é que produtividade em desenvolvimento de software não é medida pela quantidade de horas que um profissional passa sentado na frente do computador ou em quantas horas ele lança numa atividade no seu sistema de controle. Esse controle é baseado na idéia de que desenvolver software é a mesma coisa de desenvolver produtos industriais – ver post sobre o termo fábrica de software – e isso não procede. Sobre isso, vou dedicar um post para falarmos, certo?

Se eu partir da premissa de que temos que trabalhar com profissionais adultos e responsáveis que saibam gerenciar seu próprio tempo e atividades e que temos que confiar nesses profissionais, vamos ver que é ridículo bloquear internet pensando em produtividade.

É claro que existem aqueles “profissionais” que aproveitam da empresa mais liberal e passa o dia todo vendo notícias de esporte, viagens, batendo papo, etc. Acontece que não dá pra punir 95% que faz certo, por causa de 5% que faz errado. O cara que faz isso não produz, se ele não produz é fácil aparecer. Se isso acontecer o que fazemos? Manda o cara embora e contrata outro adulto no lugar.

O profissional deve utilizar seu tempo livre para estudar e não o da empresa;

Essa é outra idéia que faz com que o índice de turnover de uma empresa bata picos do tamanho do Everest. Ora, quem disse que a empresa não deve incentivar o profissional a estudar em seu tempo de trabalho? Poxa, vamos ser sinceros: Se o cara quer enrolar ele faz isso com ou sem internet. Basta dar um elástico e/ou um clips pra ele e pronto. Não é melhor que o cidadão invista seu tempo ocioso em estudo e aprendizado?

E se não for em estudo também, qual o problema de ficar um tempo sem fazer nada? Existem estudos hoje em dia que mostram que profissionais que trabalham com atividades intelectuais precisam de um “break” para voltar a focar numa atividade. Quantas vezes já não passamos horas parados feito estátuas olhando para um código sem encontrar solução, alguém insistiu para tomar um café e depois de 20 minutos você voltou dando risadas altas pelas piadas contadas no café, sentou-se na frente da máquina e resolveu o problema na mesma hora?

Não é preciso pesquisar sobre desenvolvimento na internet. Profissional bom é o que “domina” a sintaxe da linguagem;

Nem vou me alongar muito neste tópico. Se você ainda acredita nesse tipo de coisa acho que já pode parar de ler o artigo (e o blog). Mais um pensamento totalmente baseado na idéia de que desenvolver software não é uma atividade intelectual e sim repetitiva e automatizada. #FAIL

Problemas de segurança, como por exemplo enviar um arquivo confidencial por email.

Se você trabalha em uma mega empresa do setor financeiro ou coisa do gênero, talvez pode ser possível usar essa desculpa. No geral, justificar bloqueio de internet com desculpas de segurança de informações é uma grande falácia. Tem empresa que bloqueia tanto a internet, messaging, etc, mas dá senha de banco de dados de produção pra consultor fazer deploy de madrugada. Segurança ? I don’t think so…

Hoje, algumas empresas partem para a estratégia de bloquear tudo e fazer com que cada um que precise acessar um determinado endereço (blog por exemplo), entre em contato com a área de infra ou segurança de informação e defenda o porque precisa daquele acesso. Depois de “10? dias, “30? assinaturas  e um caminhão de tempo perdido, o acesso é liberado e o profissional já não precisa mais daquele acesso. Lembra do primeiro item da lista: Produtividade? O que será que é mais produtivo não é mesmo?

E quem disse que é alguém da infra ou da segurança que é a melhor pessoa para ter esse controle? Acabo pensando que isso é justamente uma questão de controle mesmo. Do tipo totalmente territorial e injustificado. Se acontece na sua empresa, não se assuste 

Resumindo:

Somos trabalhadores do conhecimento. Trabalhamos com uma atividade intelectual e não industrial e repetitiva. Somos totalmente forjados com conhecimento e informação. Bloquear acesso à internet neste cenário é um completo absurdo.

A empresa que ainda possui esse tipo de postura é completamente atrasada e corre o risco de ser varrida do mapa.

E você, o que pensa a respeito?

Grande abraço.

André Nascimento

Permalink

O Scrum Master PRECISA ser um agente de mudança.

Naquele momento não me dei conta do tamanho peso que isso tem, assim como a maioria das coisas realmente importantes em nossas vidas. A realidade é que se a organização estivesse pronta para o Scrum, ela não precisaria dele. Ou apenas estaríamos dando um nome para aquilo de bom que a organização já faz. Assim, o Scrum Master é quase um mal necessário, que pode colocar a empresa toda na direção certa.

As áreas nas quais o Scrum Master (vou começar a abreviar para SM, tudo bem?) nem de longe se limitam ao time, embora esse seja seu foco. Após trabalhar o time, elevar suas capacidades, maximizar seus resultados e apoiar o time em um nível no qual o time já não precise mais de seu apoio, aí sim começa o verdadeiro desafio. Desenvolvedores são pessoas mais propensas a mudanças, afinal lidam com tecnologia e sinceramente, não conheço nada mais efêmero. Assim, o indivíduo que começou com Basic, rodou pelo Clipper, passeou pelo Delphi e hoje programa em Java, Ruby ou Python sabe que a única constante no universo é a mudança, nada é definitivo. Pessoas com essa bagagem, aceitam que o mundo vai mudar e já que elas mesmas evoluíram, por que não o processo de gerenciar seus projetos.

Mas isso não é suficiente.

Scrum trata da microgestão. De mecanismos para que a equipe consiga gerir o seu próprio trabalho, afinal, ninguém sabe melhor do que eles como fazê-lo. Mas como fazer isso funcionar se todo o restante da organização não compreende essa forma de trabalho? Como fazer uma empresa tradicional, formal, admitir que exista uma maneira mais adequada de gerir do que a Comando-Controle? É inefetivo mudar o nosso micro cosmo sem que nos preocupemos com o mundo que nos cerca. Mas a pergunta fundamental: como eu faço isso?

Para responder essa pergunta precisamos entender a cabeça dos gestores. Em sua grande maioria, eles querem máximo, entregando o mínimo. O mínimo de informação (só se diz o que se deve dizer), de requisitos (esperam que a bola de cristal esteja bem lustrada), de liberdade criativa (siga ao modelo), comunicação (top-down). Esses e outros fatores devem ser trabalhados na alta-gestão da sua empresa (ou na qual você está inserido) para fazer do seu novo processo de gestão um sucesso. Ou isso ou até mesmo Scrum vai falhar.

Ok, como podemos reverter esse quadro e transformar a empresa que estou atuando? Lhes dando resultados. Ok, mas quais? Usando o que está escrito no princípio de tudo. Sim, no manifesto ágil. Vejam que não há novidade aqui, apenas uma boa interpretação.

E o primeiro princípio nos diz:

Nossa maior prioridade é satisfazer o cliente através da entrega rápida e contínua de software de valor.

Só com esse princípio ágil podemos extrair diversas métricas que dizem algo interessante para a direção. Como por exemplo, Valor de Negócio Ganho, ou na abreviação em inglês EBV. Afinal como disse Heitor Roriz em uma de suas palestras:

Os membros da equipe gostam de entregar valor, pois os faz sentir que estão contribuindo para o sucesso da organização. Os stakeholders são motivados a prestar atenção ao EBV dos releases incrementais.

Esse é só um ponto. Perceba que nele você melhora tanto o animo da equipe quanto da direção. Empresários e outros gestores gostam de números e gráficos, portanto dê isso a eles e veja a mudança acontecer. Na primeira instância esses são os clientes da equipe de desenvolvimento. Trabalhe-os demonstrando o valor de cada uma das métricas que você conseguir extrair do manifesto e garanto que terá todo o apoio para guiar o seu micro cosmo, desde que esteja tudo em ordem no universo exterior.

Referências:
Princípios por trás do manifesto ágil
Heitor Roriz, CST, Massimus CT
Steve Denning, Radical Management

Em seguida, conduzindo-os pela mão, foi levando os cegos até o elefante para que o apalpassem. Um apalpava a barriga, outro a cauda, outro a orelha, outro a tromba, outro uma das pernas…

Quando todos os cegos tinham apalpado o paquiderme, o príncipe ordenou que cada um explicasse aos outros como era o elefante.

Então, o que tinha apalpado a barriga disse que o elefante era como uma enorme panela. O que tinha apalpado a cauda até os pelos da extremidade, discordou e disse que o elefante se parecia mais com uma vassoura.

“Nada disso”, interrompeu o que tinha apalpado a orelha. “Se ele se parece com alguma coisa é com um grande leque aberto.”.

O que apalpara a tromba deu uma risada e interferiu:

“Vocês estão por fora. O elefante tem a forma, as ondulações e a flexibilidade de uma mangueira de água…”

“Essa não”, replicou o que apalpara a perna, “ele é redondo como uma grande mangueira, mas não tem nada de ondulações nem de flexibilidade, é rígido como um poste…”

Os cegos se envolveram numa discussão sem fim, cada um querendo provar que os outros estavam errados, e que o certo era o que ele dizia. Evidentemente cada um se apoiava na sua própria experiência e não conseguia entender como os demais podiam afirmar o que afirmavam.

O príncipe deixou-os falar para ver se chegavam a um acordo, mas quando percebeu que eram incapazes de aceitar que os outros podiam ter tido outras experiências, ordenou que se calassem.

“O elefante é tudo isso que vocês falaram, explicou. Tudo isso que cada um de vocês percebeu é só uma parte do elefante. Não devem negar o que os outros perceberam. Deveriam juntar as experiências de todos e tentar imaginar como a parte que cada um apalpou se une com as outras para formar esse todo que é o elefante.”.

Moral da estória:
A experiência das coisas que cada homem pode ter é sempre limitada. Por isso, a sensatez nos obriga a levar em conta também as experiências dos outros para se chegar a uma síntese.

A pessoa, o ser humano, apresenta muitas facetas, Existe o risco de polarizar a atenção em alguma delas, ignorando o resto. Fazendo isso, estaríamos repetindo os cegos da parábola. Cada um ficaria com uma visão unilateral e parcial.

Para obtermos uma visão o mais integral possível do que é uma pessoa, devemos reunir, numa unidade, os numerosos aspectos que podem ser observados no ser humano. É o que devemos tentar fazer, cientes, porém, de que uma visão completa, como diria o príncipe indiano, é sempre impossível.

Recebido por e-mail

Graças a Deus, que resolveu esse problema para você.

Juro que me senti mal com a resposta. Afinal senti meu esforço reduzido a nada. Bastava que eu me sentasse, que uma divindade superior veria a minha dificuldade e solucionaria para mim o problema como mágica. Realmente me desagradei com aquilo, pois senti que o mérito daquilo tudo deixou de ser meu e passou a ser de alguém com quem eu não posso competir.

Nesse momento, me lembrei da parábola dos talentos, descrita no evangelho de São Mateus. Nela, um patrão vai viajar (imagino eu ser por um longo período) e deixa para seus três criados uma certa quantidade de talentos (que também suponho ser algo como a moeda da época). Ao retornar dois, que receberam mais talentos, os souberam multiplicar. O que recebeu menos, por achar pouco, escondeu e manteve a quantidade que tinha.

E com essas palavras me confortei. Afinal, eu tinha a minha parcela de mérito sim. Por mais que eu tivesse habilidades com as quais eu nasci, dadas por qualquer força superior, eu as desenvolvi, eu busquei ser melhor naquilo que faço e nessa semana resolvi um problema muito difícil, com os talentos que eu multipliquei.

Acredito ser esse o caminho da vida: evoluir. Jamais ficar parado. Se algo caiu do céu, já foi, já aconteceu, agora está na hora de correr atrás e multiplicar, crescer, evoluir. Por mais que se conheça o seu trabalho, mude, saia da zona de conforto. No meu contexto, aprenda uma nova linguagem, um novo paradigma, uma nova tecnologia. Isso pode nem ser imediatamente aproveitável, mas com certeza o tornará melhor naquilo que é seu foco.

Sou cristão católico, talvez por isso essas palavras pareçam um pouco carregadas de fé. Mas independente de sua crença, aceite uma verdade: você tem talentos (independente de onde vieram) e cabe a você, somente a você decidir o que será feito deles, enterrar ou multiplicar.

O que você escolhe?

“O Dilema” – Klaus Wuestefeld

Focar na qualidade do software ou na entrega imediata de novas funcionalidades?
A maioria das equipes de desenvolvimento ignora a qualidade, dia após dia, projeto após projeto, favorece a entrega imediata e detona sua própria produtividade já a partir do curto prazo. Por quê?
Nas palavras de Albus Dumbledore: “Logo, logo, Harry, todos teremos que escolher entre o que é certo… e o que é fácil.”

“Radical Management” – Heitor Roriz

O que Steve Jobs fez pela Apple dificilmente o seu substituto conseguiria: introduzir a visão e a perspectiva do cliente em todos os ambientes da empresa. Isso não é tarefa fácil tendo em vista a situação econômica global, cada vez mais levando as empresas a reduzir e cortar custos, tendo como protagonista a famosa contabilidade de custos. É com base nisso que as empresas vêm medindo progresso. Eliyahu Goldratt desenvolveu um conceito diferente, denominado contabilidade de eficiência, que conceitualmente procura aumentar a velocidade em que os produtos e serviços se movem através de uma organização eliminando os gargalos. Steve Jobs conseguiu que a máxima “delight the customer” estivesse por toda a organização, nos levando a repensar os conceitos de liderança e inovação, o que Steve Denning chama em seu livro “The leader’s guide to Radical Management” de Gerenciamento Radical, um conceito inovador, construído tendo como base os valores Agile! “Delight your ears” ouvindo essa palestra!

Alexandre Nodari

“Diga 33!”

Case de sucesso de um projeto puramente XP dentro da TIM-Sul

“Agile Evolution” – Objective Solutions

Um passeio pela evolução do desenvolvimento de software: do tradicional ao Kanban.
Case de sucesso de uma equipe (grande) que teima e se manter ágil.

Ter um exemplo concreto de que agile é uma questão de vontade, disposição e ação.
Concreto = Histórico/Processo/Números/Métricas
Mostrar que é possível se manter ágil “apesar” do crescimento, das crises, das mudanças de políticas, das entregas de projetos, enfim de tudo o que todos sabem que mais cedo ou mais tarde vai atrapalhar nosso mundo ideal.

Tirando o código a limpo:
um código de conduta para profissionais – Edson Yanaga

Você é um desenvolvedor de software? Você é “ágil”? Você cola uns post-its na parede, faz umas reuniões em pé e acha que isso é suficiente? Você gosta de ser “ágil” pois permite que você documente menos, programe menos e se esforce menos? (Afinal, os méritos e as culpas são todos do “time”.) Você gosta de estar na moda?

Nesta palestra vamos distinguir aqueles que programam daqueles que fingem. Vamos identificar os desenvolvedores profissionais e os que não merecem o nosso apreço. Vamos mostrar o que é necessário para que TODOS passem a respeitar essa profissão chamada “programador”. De qual lado você está? De qual lado você quer permanecer?

Apreciem…

O texto completo está no blog do Yanaga

As palestras foram ótimas, tanto as experiências que o pessoal da Objective mostrou para o pessoal, quanto os grandes “safanões” (direitos autorais da palavra à minha mãe) dados por Yanaga e Klaus na galera de desenvolvimento.

Enfim, não posso estar mais satisfeito de estar no meio de tanta gente fantástica por um dia inteiro.

Bom, vejam por vocês mesmos algumas fotos. Em breve devo colocar alguns vídeos.

Trata-se de um evento mundial, o qual contou com a presença de David I e Jim Tierney da Embarcadero Internacional e várias presenças de referências nacionais.
A grande novidade é a substituta da biblioteca VCL, o Firemonkey, que abriu a possibilidade para um ambiente multi-plataforma. Atualmente o novo RAD Studio é capaz de gerar aplicações para Win32, Win64, MacOS e iOS (iPhone). As novas versões devem contemplar outras plataformas como Android e Linux. Outra coisa que agregou um enorme valor ao produto são os LiveBindings, recurso que permite tornar qualquer componente consciente de dados ou ser container de outro.

No final eu não aguentei e pedi pro David I dizer: Ho ho ho…

Como tive a oportunidade de participar de dois cursos de CSM (Certified Scrum Master), um ministrado por Alexandre Magno e outro por Heitor Roriz (mestre e amigo), ambos CSTs, nos quais adquiri a bagagem que julgo adequada para executar esse treinamento. Agora posso usar o selo da Scrum Alliance em meus e-mails.

Os tópicos abordados tratam desde a estrutura do framework de gerenciamento de projetos, mas deu o enfoque principal nos valores que a prática do Agile influem no dia-à-dia da equipe. Algumas práticas pontuaram as teorias apresentadas, mostrando como auto-gestão, desenvolvimento iterativo e como as cerimônias são importantes para monitorar os projetos e extrair lições para os projetos futuros.

Precisamos transformar esse tipo de “Teoria” em prática.