Não Complica Minha Vida

A maior parte do sistema que estamos “evoluindo” foi escrita em C muitos anos atrás. O core não foi reescrito; apenas inchou. A interface gráfica foi refeita em Java/Swing, mas as integrações continuam presas aos grilhões do legado C e dos muitos scripts que deixam o software chumbado na plataforma em que executa.

Durante a manutenção de uma parte do sistema, vi um código mais ou menos assim (alteramos os nomes para não comprometer os culpados):

(...)
     for(int i; i < widgets.length; i++)
        lstWidgets.get(i).setStatus(widgets[i] == 1);
(...)

Os nomes das variáveis e outras coisas que vi estavam bem pouco inteligíveis. Falei um pouco sobre o tipo de trabalho que ando fazendo aqui.

Pensando em clareza, esse pedacinho singelo de código chega a ser pavoroso. Como não entendi a intenção do método, fui conversar com o pessoal do C. Me explicaram que eram enviados 4 bytes onde cada bit representava o estado de um “widget”: “1″ para ativado e “0″ para desativado. Eles argumentaram que poderiam enviar até 32 “widgets” mantendo essa estrutura. Uma solução típica de quem vive no e do passado.

Com as informações que colhi, fiz uma pequena alteração para que outras pessoas entendam o significado de “0″ e “1″ no contexto dos “widgets”:

     private boolean isActivated(int widgetStatusIndex){
         return widgets[widgetStatusIndex] == 1; // 1 para ativado e 0 para desativado
     }

Também melhorei um pouco e adicionei um comentário explicativo ao parser do “array de bits”. Poderia ter utilizado um tipo enumerado para dar mais significado aos números cabalísticos “0″ e “1″, mas achei que seria preciosismo. Como estamos finalizando uma fase do projeto, é o que dá pra fazer. Refactorings e, se possível, redefinição das interfaces, ficam para a próxima fase.

Ame Teu Código Como a Ti Mesmo

Nas últimas semanas, começamos um trabalho de levantamento do que ficou pendente – ou melhor, do que foi empurrado com a barriga desde o começo – para finalizarmos o projeto. As pendências incluem requisitos parcialmente atendidos e tarefas técnicas. Me surpreende – às vezes não – o tipo de código que vejo em certos módulos. Vendo o histórico das alterações nas linhas de um método, parece que todo mundo que já passou pelo projeto colocou a mão ali mais de uma vez, mas ninguém se preocupou sequer em fazer alguns pequenos refactorings que melhorariam a legibilidade daquele código.

Acho que um código limpo mostra comprometimento com a equipe e preocupação com a qualidade. Às vezes, basta alterar o nome de uma variável e já temos um bom ganho em clareza. Há ocasiões em que a aplicação de alguns patterns ajudariam bastante. Fico bastante chateado quando concluo que o que faltou foi um entendimento de orientação a objetos, fundamentos de programação ou conhecimento da API. Pouco conhecimento de negócio, dependendo do que for e da postura para procurar saber, é aceitável, pois essa aplicação é bastante complexa. Por isso, vou usar um exemplo fictício de outra área de negócio, mas que contém elementos que garimpei do nosso código:

private int calculateDiscounting(int c){
     // Se o cliente for uma pequena fazenda, não tem desconto
     int dis = 0;
     // Se o cliente for uma grande fazenda, tem um desconto especial
     if(c == 1){
         dis = 1;
     }
     return dis;
}

Esse método, mesmo sendo pequeno, apresenta vários problemas. Vale lembrar que para fazer um refactoring não é só o tamanho de um método que deve ser levado em consideração. A picada da aranha armadeira, um bicho minúsulo, pode te matar. O vírus da AIDS, invisível a olho nú, destrói o sistema imunológico e abre caminho para aniquilação do organismo. É assim que encaro um código ruim: um pequeno inimigo muito perigoso que precisamos combater.

Não vou fazer todas as alterações que gostaria de fazer nesse código. Vamos apenas aumentar a clareza. Se um dia surgisse um requisito que necessitasse de intervenção em código, partiríamos de uma implementação “refactoring friendly“.

Pelo nome, calculateDiscounting(…) afirma que faz um cálculo de desconto, mas o que vemos é uma decisão quanto à categoria de desconto. Os nomes do parâmetro e das variáveis também estão ruins. O que são “c” e “dis”? Vamos supor que pelo menos os tipos estão corretos e seus valores não podem ser alterados, pois são conhecidos fora do método. A propósito, o que são esses “números cabalísticos” testados? Outra coisa que chama a atenção são os comentários in-line. Esse é o chamado “mau cheiro de código” e geralmente marca pontos candidatos a refactoring.

public enum DiscountingCategory(){
     WITHOUT_DISCOUNTING,
     ESPECIAL_DISCOUNTING;
}

public enum CustomerType(){
    SMALL_FARM,
    BIG_FARM;
}

private DiscountingCategory findDiscountingCategory(CustomerType customerType){
     DiscountingCategory discountingCategory = WITHOUT_DISCOUNTING;
     if (customerType == BIG_FARM) {
         discountingCategory = ESPECIAL_DISCOUNTING;
     }
     return discountingCategory;
}

Sinal verde: os testes passaram e agora as coisas fazem mais sentido. Troquei as constantes por tipos enumerados e alterei os nomes do parâmetro e das variáveis. Os “números cabalísticos” podem ser recuperados de fora pelo ordinal() do enumerado, ou seja, não modifiquei a dependência para os valores 0 e 1. Isso fica para o próximo refactoring. Acho que vou parar por aqui.

Conclusão

Em A Melhor Solução é a Simples, citei uma passagem do livro Modelagem Ágil, de Scott W. Ambler. Nesse trecho, ele aponta os problemas decorrentes de se modelar demais para tentar resolver todos os problemas imagináveis. Portanto, não perca tempo inventando requisitos: pare quando a luz verde acender e seu código estiver claro o suficiente.

SSH Com Chave Pública

Recentemente, decidimos utilizar a classe Robot do AWT em associação com o fest para automatizar os testes da interface gráfica. Falarei sobre a implementação do teste automatizado em outro artigo. Nesse artigo falarei sobre um problema que tive com a autenticação do SSH e como resolvi utilizando chave pública e privada.

SSH

Alguns módulos do nosso sistema rodam em servidores remotos. Para que algumas ações possam ser realizadas por um usuário (no caso dos testes automatizados o usuário é o próprio Robot), outras ações – esplícitas, dependentes de terceiros ou dependentes de temporização – devem ocorrer nos servidores. Para simular as chamadas “ações de terceiros”, precisamos executar scripts nos servidores via SSH.

O SSH (Secure Shell) é um protocolo de rede que permite a troca de dados entre dois dispositivos de rede através de um canal seguro. Servidores SSH necessitam de usuário e senha. Como nossos servidores utilizam um usuário fixo e os scripts que rodam lá dependem de permissões atribuídas a esse usuário, não seria a melhor escolha criar um usuário para cada desenvolvedor em cada servidor. Para emular um login automático, decidimos utilizar chave pública e privada. De acordo com a wikipedia:

A criptografia de chave pública ou criptografia assimétrica é um método de criptografia que utiliza um par de chaves: uma chave pública e uma chave privada. A chave pública é distribuída livremente, enquanto a chave privada deve ser conhecida apenas pelo seu dono.

Basicamente, quem detém a chave pública – criada no mesmo momento que a chave privada – pode acessar o dispositivo de rede, que é o detentor da chave privada.

Abaixo, segue o processo para criação do par de chaves pública e privada. Não é necessário repetir esse processo para cada host remoto. Basta fazer apenas uma vez e copiar a chave privada para o diretório .ssh de cada host remoto. Detalhe: segurança não é nosso objetivo .

Passos Para Criação das Chaves Pública e Privada

1. Autenticar no ssh server

$ ssh -l [USER] [HOST_NAME]

2. Criar o par de chaves pública/privada

$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/atc/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/atc/.ssh/id_rsa
Your public key has been saved in /home/atc/.ssh/id_rsa.pub
$ cd ~/.ssh
$ cat id_rsa.pub >> authorized_keys
$ chmod 600 authorized_keys

Obs.: Não utilize passphrase.

3. Faça log out e crie, caso não exista, o diretório .ssh

$ cd ~
$ mkdir .ssh
$ chmod 700 .ssh

4. Copie o arquivo id_rsa gerado no servidor para o diretório local .ssh

$ cd ~/.ssh
$ rcp atc@[HOST_NAME]:/home/atc/.ssh/id_rsa .

5. Faça o login via ssh

$ ssh -l [USER] [HOST_NAME]

Agora não é mais necessário fornecer o password.

Resolvendo Problemas

Caso você enfrente algum problema, faça a autenticação em modo debugg para ter o mínimo de informações:

$ ssh -v -l [USER] [HOST_NAME]

Caso esteja tudo certo, algo assim será exibido no terminal:

debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: /Users/res/.ssh/res-rsa
debug1: Server accepts key: pkalg ssh-rsa blen 151
debug1: PEM_read_PrivateKey failed
debug1: read PEM private key done: type
Enter passphrase for key '/Users/res/.ssh/res-rsa':
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).

Enfrentei dois problemas na primeira vez em que tentei gerar as chaves: falta da permissão 700 no diretório .ssh do servidor e falta da permissão 600 no conteúdo do diretório .ssh. No processo para criação das chaves já coloquei os passos para alteração de permissão.

Referências

http://www.snailbook.com/faq/publickey-userauth.auto.html
http://magicmonster.com/kb/net/ssh/auto_login.html
http://www.linuxquestions.org/questions/linux-security-4/ssh-public-private-key-authentication-problems-454445/

Retrospectiva 2010, Segundo o WordPress

O WordPress.com me enviou as estatísticas de acesso do blog em 2010. Segue uma parte do relatório. O mais “interessante”, vamos dizer assim, foi saber que esse blog é fantástico porque 19 747s – provavelmente cheios de duendes graduados em estatística – “pousaram” por aqui no ano passado . Mas falando sério, agradeço a todos que me leem, pois sem ter pessoas com as quais compartilhar e discutir nossas ideias, acho que um blog perde seu motivo para existir.

Os números de 2010

Os duendes das estatísticas do WordPress.com analisaram o desempenho deste blog em 2010 e apresentam-lhe aqui um resumo de alto nível da saúde do seu blog:

O Blog-Health-o-Meter™ indica: Este blog é fantástico!.

Números apetitosos

Um Boeing 747-400 transporta 416 passageiros. Este blog foi visitado cerca de 7,700 vezes em 2010. Ou seja, cerca de 19 747s cheios.

O dia mais cheio foi 15 de março. O post mais popular desse dia foi Estimando Tarefas com a Ajuda dos Orixás.

Atrações em 2010

Estes são os artigos e páginas mais visitados em 2010.

1. Estimando Tarefas com a Ajuda dos Orixás julho, 2009
2. O Lado Sombrio do Código fevereiro, 2010
3. A Lição do Abacaxi setembro, 2009
4. Qualidade de Código agosto, 2009
5. Certificação de Analista de Sistemas dezembro, 2009

Adapte e se Adapte

Esse é um post do tipo não me orgulho disso. Acho que as experiências ruins são mais proveitosas que as boas para nosso amadurecimento como pessoas e como profissionais. Por isso, vou compartilhá-la com você.

Dificuldade de Adaptação

O mês que passou foi um dos mais difíceis da minha carreira. Com a troca da gerência do projeto, o processo definido por nosso time e para nosso time foi destruído, assim como o próprio time, porque fomos divididos em dois grupos com objetivos diferentes. A passividade de minha postura, motivada por alguns desentendimentos com a gerência, se tornou nociva para o projeto, pois adotei uma atitude mental do tipo “vou fazendo e não vou mais opinar; meu salário é o mesmo”.

Minha nova gerente percebeu que não comprei as idéias dela e que havia desistido, informalmente, de agir como um líder, pois não poderia quebrar a confiança que meus colegas tinham em mim; eu não estaria sendo sincero se tentasse convencê-los a aceitar algo do qual eu mesmo não acreditava. Depois de uma longa conversa com ela, prometi mudar minha postura e encontrar uma forma de adaptar o que fazíamos ao que ela me provou ser o mais  importante naquele momento do projeto, dessa forma aumentando a integração entre a equipe de desenvolvimento e a equipe de testes.

Era Tudo Estresse

Lendo bem por cima o artigo 5 Ways to Reduce Workplace Stress, me surpreendi ao entender que tinha vários dos sintomas do estresse no trabalho.

O autor chama a atenção para aquela sensação de que as coisas não estão indo bem; uma percepção de que há algo errado, mas temos apenas uma vaga idéia do que seja. Criamos, em nossa mente, um ambiente que nos faz sentir pouco ou nada importantes. Ele afirma que o estresse no trabalho é motivado por uma perda ou uma sensação de perda de controle, que acarreta graves consequências para o indivíduo:

• Pessoas estressadas não raciocinam bem
• Pessoas estressadas processam a linguagem com eficiência
• Pessoas estressadas não têm boa memória
• Pessoas estressadas não generalizam ou não adaptam velhos pedaços de informação a novos cenários tão bem quanto pessoas não estressadas
• Pessoas estressadas não conseguem se concentrar
• Estresse crônico abala nossa habilidade de aprender

A palavra estresse é utilizada hoje no sentido negativo para indicar desgaste físico ou emocional. Além dos aspectos psicológicos citados, o estresse também compromete nossa integridade física.

Do ponto de vista fisiológico, são necessários pelo menos um agente estressor (como responsabilidades, problemas cotidianos, etc) para exiger do indivíduo uma reação adaptativa; a essa reação se dá o nome de coping (lidar). Tais reações de coping podem ser funcionais ou disfuncionais, conforme cumpram ou não sua função na superação da situação na adaptação a ela.

A Síndrome Geral da Adaptação é uma teoria que afirma que:

O organismo reage à percepção de um estressor com uma reação de adaptação (ou seja, o organismo se adapta à nova situação para enfrentá-la), o que gera uma momentânea elevação da resistência do organismo

Uma reação de alarme é seguida de um estágio de resistência e por fim um estágio de esgotamento físico. Acho que cheguei muito perto do estágio de esgotamento não apenas físico, mas mental

Em Busca de Uma Postura Ágil

Meu estresse foi causado por uma dificuldade de adaptação às mudanças, o que faria com que qualquer iniciativa ágil caísse por terra. Dizem que para vencer o estresse, precisamos, dentre outras coisas, relaxar, nos alimentar corretamente e ter um hobby. De forma mais geral, precisamos nos encher de novos valores.

Para esse recomeço, fui buscar um pouco de inspiração na fonte, o Manifesto for Agile Software Development. Ele afirma que “responder às mudanças é mais importante do que seguir um plano”. Dois dos princípios do manifesto expandem esse valor:

Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adéquam a mudanças, para que o cliente possa tirar vantagens competitivas

Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo

O Manifesto for Software Craftsmanship parece ter uma síntese de alguns valores ágeis:

Não apenas responder às mudanças, mas também adicionar valor em um ritmo constante

Atualmente, estamos estabilizando uma versão (corrigindo bugs) para apresentação ao cliente, pois não podemos contar com sua colaboração como parte do time – o contrato foi fechado assim e não vai mudar. Nosso trabalho já era orientado a casos de teste, mas agora propus a adoção de dois kanbans justapostos: um para gerenciar atividades de teste e outro para gerenciar o desenvolvimento.

Esse processo é orientado a tarefas, o que é ruim para motivação da equipe. O que propus é apenas um paliativo enquanto penso em algo mais sólido e mais motivador, inclusive para mim. O Lean parece ser uma boa fonte, principalmente no que diz respeito à eliminar gastos, mais poder para o time, maximizar aprendizado e integridade conceitual do software.

Conclusão

Mais importante do que ter um processo bonito é entregar software funcionando o mais rápido possível para não abalar o valor transformativo do produto perdendo a vantagem competitiva que nosso cliente almejava.

Minha postura recente contradisse muito do que afirmo, reafirmo e ratifico nesse blog sobre postura profissional, por isso, peço desculpas a quem me lê e a meu time.

Rápido, Bonito e Barato: Escolha Dois

Nas últimas semanas trabalhei em uma “força tarefa” – novidade, né? – para entrega da primeira fase do projeto em que atuo. Havia problemas de performance, deadlocks, memory leaks e, para variar, descobrimos que existiam requisitos que não foram implementados. Os desenvolvedores trabalharam nos finais de semana e alguns noite a dentro. Também havia reuniões de status diárias que as vezes consumiam horas que poderiam ser melhor utilizadas para investigação de problemas.

Nosso maior problema foi a impossibilidade de reproduzir em nosso ambiente de testes problemas encontrados nas instalações do cliente, pois lá ocorrem situações quase impossíveis de simular. Tirei meu chapéu de líder da segunda fase do projeto e coloquei a mão na massa na primeira fase na iminência da entrega, como a tempos não fazia. Me senti um pouco enferrujado. Até pedi ajuda para fazer coisas que faria muito rápido poucos meses atrás, mas foi uma boa experiência.

Sempre que tenho que produzir sobre pressão, me lembro da frase de um professor da época da pós-graduação “rápido, bonito e barato: escolha dois, à vontade”. Trata-se de bom senso, não preguiça.

Como meio de aliviar o estresse do “desenvolvimento relâmpago”, também li dois livros do Stephen King que fazia tempo queria ler, o terceiro e o quarto volumes da série A Torre Negra: “As Terras Devastadas” e “Mago e Vidro”, o segundo com 800 páginas. “As Terras Devastadas” entra para a lista dos dez melhores romances que já li, mas “Mago e Vidro” é um pouco cansativo, não só pelo tamanho; lembra enredo de novela. O próprio autor afirma que começou a se perder lá pela página 600, mas enfim, recomendo a leitura dessa série para quem gosta de uma boa mistura de aventura, ficção e terror, mas terror de verdade e não bobeiras como Jason X.

Liderança: O Novo Desafio

Pela terceira vez em minha carreira passo por um momento de transição da liderança da equipe. Pela segunda vez passo a ser líder técnico. Na primeira vez, em outro projeto, não fiz um bom trabalho. Era pouco mais que um delegador de tarefas; uma espécie de Gerente de “Project”. Falhei em trabalhar as qualidades individuais do grupo e em entender e atender seus anseios. Enfim, era imaturo para exercer essa nova atribuição. Raras exceções, as pessoas não acertam em algo novo na primeira vez que tentam. O importante é querer acertar e extrair lições dos erros e, no meu caso, do fracasso. As responsabilidades só podem ser atribuídas aqueles que se comportam de maneira profissional.

Liderança Técnica ou Gerência Operacional

Líder Técnico é apenas o nome de um cargo caso esse tenha sido atribuído pela gerência. É a denominação de mais uma caixinha – por sinal uma das que ocupam as posições mais baixas – no organograma da empresa. Com essa prerrogativa, já tive líderes técnicos que não eram líderes e, por incrível que pareça, nem técnicos. Segundo a Wikipedia:

Técnica é o procedimento ou o conjunto de procedimentos que têm como objetivo obter um determinado resultado, seja no campo da Ciência, da Tecnologia, das Artes ou em outra atividade

Em vários líderes técnicos senti a falta da técnica. Alguns não tinham conhecimento da plataforma de desenvolvimento que a equipe utilizava. Outros mal sabiam desenvolver software. Como uma pessoa sem conhecimento pode ser consultada para resolução de problemas rotineiros e ajudar nas decisões técnicas? É quase como um padre dando conselhos sobre sexo. Nosso último líder era muito bom tecnicamente. Confiávamos nele para resolver problemas cotidianos e ajudar a tomar decisões técnicas.

Gerentes Operacionais não fazem muito mais que cobrar prazos diariamente (microgerenciamento), atualizar o MS-Project e delegar tarefas pelo Jira. Liderar pessoas é muito diferente disso.

A Autoridade do Líder

De acordo com a Wikipedia:

Liderança é o processo de conduzir um grupo de pessoas, transformando-o numa equipe que gera resultados. É a habilidade de motivar e influenciar os liderados, de forma ética e positiva, para que contribuam voluntariamente e com entusiasmo para alcançarem os objetivos da equipe e da organização

Liderança é uma conquista de um indivíduo em um grupo. Trata-se do reconhecimento dado pelo grupo a uma pessoa que as inspira e em quem elas confiam. O grupo lhe concede autoridade.

De acordo com Max Weber, um dos fundadores da Sociologia:

Autoridade é a habilidade de levar os outros, de boa vontade, a fazerem sua vontade

Em outras palavras, é o direito de influir sobre os outros. A autoridade é a essência da pessoa e está ligada ao seu caráter. Chico Xavier, por exemplo, exerceu autoridade moral levando palavras de esperança a pessoas desesperadas e utilizando sua própria vida como exemplo de paciência, humildade, perseverança e desapego material. Essas são as pessoas lembradas pela história com carinho e que realmente agregam em sua passagem pela Terra.

Enquanto a autoridade é uma conquista e é a essência da liderança, o poder é atribuído e é a essência do estilo de gerência tradicional. Segundo Weber:

Poder é a capacidade de obrigar, por causa de sua posição ou força, os outros a obedecerem à sua vontade, mesmo que eles preferissem não fazê-lo

Supervisores, Gerentes e Diretores, nos moldes das organizações militares, recebem poder sobre outras pessoas e esse poder é inerente ao cargo. Diferente da autoridade, o poder pode ser comprado e vendido, dado e retirado.

Nem Monge Nem Executivo: Apenas Colaborativo

O Livro “O Monge e o Executivo“ conta a história de um gerente que muda seu estilo de administração tradicional para um estilo servidor. Acredito nesse modelo, mas quero continuar desenvolvendo software. Porém, mais importante que isso é proporcionar condições para que o restante da equipe possa fazer o mesmo. Como quem faz é a equipe e não quem manda fazer, acredito no desenvolvimento colaborativo e nas decisões tomadas em conjunto.

Gosto de ouvir as pessoas e tentar entendê-las. Nesse ponto, acredito ser mais bem sucedido na vida profissional que na pessoal. Em nosso processo, atuo como mediador nas reuniões de planejamento para mantermos o foco, mas tenho participação ativa na escolha da meta da semana.

A saída de nosso líder causou grande impacto, pois ele detinha grande conhecimento. Para minimizar o impacto da saída de colaboradores, uma das primeiras ações que decidimos em conjunto foi instituir um wiki. Investiremos algum tempo todo dia ou sempre que necessário para documentar nosso conhecimento. Outras equipes gostaram da ideia e pretendem fazer o mesmo.

De Mente Aberta

Fui pego de surpresa em uma sexta feira à tarde com a notícia de que passaria alguns dias em Curitiba – já partiria no sábado bem cedo, mas o problema é que eu nem tinha mala para viagem – para acompanhar os testes em campo do software que estamos desenvolvendo. Relutei um pouco em aceitar, pois já havia feito planos para o final de semana, mas acabei aceitando pela equipe, pelo momento do projeto e pela empresa.

Durante o voo, que durou pouco mais de quarenta minutos, refleti sobre minha primeira reação. Em muitas ocasiões, não me mostro receptivo e nem flexível. Não sei porque minha primeira reação é negativa, mas isso é algo que preciso mudar. Precisamos ser pessoas acessíveis, confiáveis e estar disponíveis quando e onde somos necessários, seja para apagar focos de incêndio na aplicação ou para levar a sobrinha para brincar na piscina de bolinhas.

A viagem foi tranquila desde o Aeroporto de Congonhas até o Aeroporto Internacional Afonso Pena, na cidade de São José dos Pinhas, a poucos minutos de Curitiba. Passei alguns dias muito interessantes dentro das instalações do nosso cliente. Não agreguei muito: fiz uma ou duas pequenas correções, mas amadureci mais como pessoa e como profissional graças a essa experiência.

Entrei na equipe com o projeto em andamento, mas por mais que se fale ou melhor se tente especificar algo, nada se compara a estar na presença de um usuário, acompanhar a forma como ele trabalha, ver como é a operação normal, suas contingências e sentir as dificuldades que eles têm e que o software novo se propõe a minimizar. É incrível a expectativa que algo novo cria!

Terminada minha “missão”, voltei para São Paulo trazendo alguns suvenires – principalmente chocolates – para minha noiva para tentar me redimir pelo final de semana que passamos separados. Passados alguns dias desde minha volta, ainda estou me redimindo.

Muito Sal Na Sopa

Recentemente, li um artigo chamado Innovate the Future: Who Owns Your Customer Now?. O autor, David Croslin, também escreveu o livro Innovate the Future: A Radical New Approach to IT Innovation. Não li e não sei se lerei esse livro, mas a ideia contida no artigo é interessante.

O autor afirma que a causa do fracasso de algumas empresas em um curto período é achar que o segredo do sucesso é ter uma grande variedade de produtos sem levar em consideração o que o consumidor realmente deseja e precisa. Não se importam com o que faz com que uma pessoa seja leal a uma marca ou produto. Ele começa o artigo traçando a sequência lógica que leva um restaurante a abrir e fechar em apenas dois anos:

1. O restaurante abre. A comida é excelente. O atendimento é excelente, amistoso e rápido;
2. A clientela aumenta;
3. A variedade de itens no cardápio aumenta e o preço aumenta sensivelmente. O cliente fica inclinado a pedir sempre sua comida favorita;
4. A qualidade do serviço começa a diminuir;
5. Os preços começam a aumentar;
6. Os clientes passam a ir ao estabelecimento com menos frequência;
7. A qualidade da comida continua a mesma, mas a quantidade diminui;
8. Os preços continuam aumentando. O cliente vai apenas por seu prato favorito;
9. Os cliente não vêm mais ao estabelecimento;
10. O restaurante fecha.

Manter uma grande variedade de pratos é caro. É necessário manter muitos ingredientes diferentes – o que não acontece com fast foods, como o MacDonald’s – e investir em treinamento dos funcionários . Esse custo é transferido aos poucos para o cliente, que além de pagar mais caro aguarda muito tempo para ter seu pedido atendido.

Como exemplo, o autor utilizou um restaurante fictício que queria ser grande. Darei o exemplo de um restaurante real que se conforma em ser pequeno, ou melhor, “na medida certa”.

Liberdade Para a China

Costumo jantar com minha noiva em um restaurante chinês no bairro da Liberdade, daí o título acima – achou que fosse outra coisa? A fama dos restaurantes chineses não é das melhores, mas nesse aí a comida é muito boa. Basta não ficarmos pensando muito na procedência do alimento.

Desde que comecei a frequentar esse restaurante, a variedade de pratos, o preço e mesmo o gosto do tempero não mudaram. O restaurante foi inaugurado ali e lá persiste basicamente com a mesma estrutura e clientela a anos. Quando pensamos em culinária chinesa, esse é o primeiro restaurante que nos vem a mente e geralmente vamos até lá. Assim como restaurantes recém-inaugurados, esse restaurante atende a três prioridades das pessoas:

• Satisfação: As pessoas precisam comer e elas querem comer boa comida – mesmo que às vezes a procedência seja duvidosa . Elas também querem ser bem atendidas;
• Tempo: As pessoas querem utilizar seu tempo eficientemente. Elas não querem aguardar um pedido por horas e nem querem ser praticamente convidadas a se retirar assim que acabarem de comer;
• Dinheiro: As pessoas querem gastar seu dinheiro sabiamente.

Esse restaurante não quer ser grande, mas sim se manter bom o bastante, ou melhor, na medida certa. Dessa forma, sua clientela permanece leal e seu lucro é constante. Os estabelecimentos não precisam ficar para sempre com o mesmo cardápio. Acho que pequenas experimentações são válidas, mas desde que dentro das prioridades do consumidor e nunca se esquecendo do “bom o bastante”.

A Cabeça de Steve Jobs

Em Inside Steve’s Brain, o autor fala da trajetória de Steve Jobs desde o início da Apple, sua passagem pela Pixar e sua volta à Apple em um momento de crise. Jobs disse:

O que encontrei quando cheguei lá foi um zilhão e meio de produtos. Era espantoso. E comecei a perguntar às pessoas: por que recomendaria um 3400 e não um 4400? Quando é que alguém deveria fazer um upgrade para um 6500 e não um 7300? Três semanas depois continuava sem conseguir entender. Se eu não consegui entender aquilo…como é que nossos clientes poderiam entender?

Jobs iniciou um política de enxugamento extremo da empresa e da linha de produção:

Tudo precisava ser justificado. Será que realmente precisamos de uma biblioteca da empresa? Se a Apple quiser sobreviver, temos que cortar mais. Temos que ter um foco e fazer as coisas que fazemos bem

Após o declínio abrupto de 12 para 10 e em seguida para 7 bilhões de dólares ao ano, Jobs explicou que a Apple não poderia ser uma empresa lucrativa de 12 ou 10 bilhões de dólares ao ano, mas poderia ser uma empresa lucrativa de 6 bilhões de dólares ao ano. Ele limitou a grande variedade de produtos a quatro máquinas: dois notebooks e dois desktops destinados a usuários profissionais ou consumidores. Com essa e outras decisões radicais, ele fez com que a Apple voltasse a ter seu foco original: fazer computadores.

Conclusão

A forma como os clientes percebem um produto o torna competitivo ou inovador. Trata-se do valor ou impacto transformativo do produto. O valor transformativo é uma relação entre satisfação, tempo e dinheiro. Esse valor transformativo é a resposta da pergunta: como esse produto transforma a vida do consumidor?

Ao aumentarem descontroladamente a quantidade de produtos, as empresas criam uma cascata de eventos que destrói o valor transformativo e a experiência do usuário. É fácil transformar comida boa em ruim, mas é difícil transforma comida ruim em boa. Se você não tem um cozinheiro como Steve Jobs que ainda lembra como se faz um omelete, procure a medida certa para seu negócio e seja excelente dentro desses limites, pois os consumidores estão sempre procurando o equilíbrio entre satisfação, tempo e dinheiro e crescer demais afeta essa relação. Enquanto esse equilíbrio se mantiver ótimo, os consumidores continuarão tomando decisões de compra positivas.

Manifestação Ágil

Cheira Scrum, Mas Fede Waterfall foi escrito em um momento de transição do Scrum para algo mais próximo dos processos clássicos. O Scrum não suportou as constantes colisões com os objetivos de outras equipes e desmoronou, mas sob seus escombros estão as pessoas que formavam um time e que ainda anseiam pela volta daquela forma objetiva e participativa de trabalhar, pois uma vez expostas aos métodos ágeis, as pessoas ficam contaminadas para sempre.

Mais Um Processo

Em caráter interino, assumi a liderança técnica da equipe de desenvolvimento – nomenclatura condizente com o “novo velho processo” – até que nosso líder voltasse das férias. Conversando com um colega, enxergamos uma oportunidade de quebrar o processo instituído de delegação de tarefas, que formava especialistas em determinadas áreas do sistema.

Nossa idéia não era ressuscitar o Scrum, mas seguindo a filosofia ágil, queríamos apenas que o conhecimento das áreas sistêmicas fosse disseminado entre as pessoas através de um processo um pouco mais participativo.

A idéia do Scrum é entregar valor a cada sprint. Esse valor é um item de backlog devidamente priorizado pelo product owner e pontuado pela equipe. Dado que atualmente estamos trabalhando na correção de bugs oriundos da execução de casos de teste e nenhuma nova funcionalidade seria desenvolvida por enquanto, o maior valor que poderíamos entregar era um caso de teste passando sem erros, e não a correção pontual de um bug. Um caso de teste tem a vantagem de olhar os casos de uso na horizontal. Dessa forma, achamos interessante que os desenvolvedores também utilizassem esse documento para guiar seus testes de forma contextual.

Ressuscitamos, mas abduzimos, nosso velho e saudoso taskboard. Em princípio, nosso taskboard abduzido terá as seguintes colunas:

• Backlog: os casos de teste que falharam;
• Não Iniciado: artefatos implementáveis, ou seja, tarefas, melhorias e bugs relacionados a cada caso de teste;
• Em Execução: artefatos sendo implementados;
• Bloqueado: artefatos que não podem ser implementados devido a alguma dependência externa;
• Pronto Para Integração: artefatos implementados, mas cujo caso de teste ainda não foi executado;
• Entregue: todos os artefatos corrigidos e o caso de teste executado com sucesso.

Os post-its do backlog recebem um identificador sequencial que é copiado para todos os artefatos relacionados. Os artefatos são tratadas por qualquer desenvolvedor seguindo algum critério que ainda precisamos definir. O último que finalizar uma tarefa ou alguém que acabe de terminar uma tarefa qualquer fica responsável pela execução do caso de teste. “Então ninguém vai terminar a última tarefa”, um de nós brincou, mas creio que todos captaram a ideia e estão prontos para colaborar.

A execução do caso de teste pode apresentar prematuramente outros problemas tanto em nível de código quanto em nível de especificação. O desenvolvedor, com o auxílio do tester e até do analista, reescreve o caso de teste e aponta os erros em outros artefatos de documentação seguindo duas premissas básicas:

• O desenvolvedor não é tester;
• O desenvolvedor não é analista de sistemas.

Dessa forma, a convivência é pacífica e alinhada com as necessidades atuais do projeto. Nossa definição de pronto é:

Todas os artefatos entregues e o caso de teste passando sem falha.

Carências do Processo

Ainda precisamos definir:

• Uma forma de priorizar os itens de backlog ou alguém que o faça. Por enquanto, os casos de teste mais prioritários são aqueles que geraram mais pendências técnicas;
• Uma forma de estimar (artefatos ou casos de teste);
• Tamanho da iteração. Em princípio, serão duas semanas.

Conclusão

Reinserimos as pessoas no processo e elas responderam de forma positiva. Noto que elas abraçam as tarefas e os casos de teste até o fim. A gerência mostrou-se satisfeita com nossa iniciativa. Não é o tipo de processo no qual eu gostaria de trabalhar, mas é o melhor possível dentro da nossa realidade e, dessa forma, é possível produzir software dentro do CMMi.