Gerenciamento

Vamos falar de negócios!

Um ponto bastante observado em diversos trabalhos que realizei por aí é a incapacidade da equipe técnica de perceber o seu trabalho como parte de um negócio. É intrigante ver esses desenvolvedores (e aqui incluímos todos os papéis que desenvolvem um produto, não apenas os programadores) buscando a pureza técnica, o estado da arte daquilo que estão fazendo no seu dia a dia. Essa busca do trabalho pelo trabalho leva a um perfeccionismo negativo, conduzindo seu artista a pensar que sua obra jamais estará acabada.

Por outro lado também temos times que não estão comprometidos com nada, apenas com as atividades para si alocadas. Tais times (ou membros em cenários melhores) se enxergam apenas como parte de uma engrenagem maior, como parte de uma linha de produção cujo o seu papel é transformar análise em código. Eles apenas trabalham ali e antes que você os amaldiçoe, lembre que tem um desse cara dentro de você, algumas vezes por dia.

Tanto no primeiro como no segundo cenário o resultado é o mesmo: desenvolvimento desconectado do negócio, trabalho sem um propósito claro. Tudo o mais que falo aqui é sobre isso, entender o quanto o time compreende do seu lugar no mundo e se realmente compreende o propósito daquilo que estão desenvolvendo.

Usualmente quando esse é o ponto mais fraco da uma avaliação, uso técnicas que aproximam cliente do desenvolvedor, buscando diminuir a quantidade de telefones sem fio no meio do caminho. Quanto mais pontos houver, pior a comunicação como a própria brincadeira homônima ensina. O que a brincadeira não passa é que a relevância de qual problema o time está resolvendo diminui inversamente proporcional ao aumento dessa cadeia. A causa é a despersonalização do usuário. Até o termo “usuário” é ruim. Usando personas e escrevendo os requisitos como histórias de usuário ajudam a reconectar o desenvolvedor ao negócio e consequentemente ao usuário final.

O que estou tentando explicar é que na maioria dos casos que vi, o problema não era primariamente do método escolhido. Os times eram bons em desenvolver software. O software errado, mas eram bons. Não adianta você ser o Usain Bolt e correr pro lado errado da pista. É preciso aceitar que não se conhece o software que resolve o problema do usuário e você só vai descobrir isso criando esse software. Em resumo, traga para a mesma mesa desenvolvedores e usuários finais e aproxime essa conversa tanto quanto possível. Os resultados são mágicos e você só tem a ganhar.

Como avaliar a agilidade da sua empresa?

Essa semana meus colegas e eu entregamos mais um trabalho de assessment ágil em uma grande empresa em SP. Foi muito interessante como sempre poder olhar para um outro ambiente diferente do seu, sem as paixões do dia a dia no intuito de ajudar outro a não cometer os mesmos erros que você já fez. Esses momentos sempre me fazem pensar em coisas que vi e coisas que vivi. Vou comentar algumas nesse texto.

Ah, como é bom fazer esse tipo de trabalho! Você se torna um avaliador, passando para aquela empresa contratada a sua visão sobre o seu processo atual. O quão legal é isso? É fantástico! Afinal é sempre mais legal ajudar os outros a resolver os seus problemas do que resolver os seus próprios. O modelo de avaliação que usamos eu criei baseado em outros que vi por aí, juntando um pouco de cada um que vi, colocando um pouco de meu próprio estilo e passando para o resto do time ágil validar. Considero um bom modelo, pois avalia quatro aspectos que considero importante para uma empresa possa ser considerada ágil: cultura, organização, técnica e negócio. O número quatro não é a toa e tem forte influência do manifesto ágil e como a empresa endereça cada um dos quatro valores ali presentes. Em textos futuros pretendo escrever um pouco mais sobre cada aspecto.

Um diferencial que a Objective tem sobre as demais empresas do mercado parece até meio contraditório porém depois que eu conto a história toda passa a fazer sentido. Não somos uma empresa de consultoria. Ou ao menos não éramos. A empresa nasceu como desenvolvimento e assim se mantém até hoje. Porém temos resolvido muita coisa, tivemos muitas dores no caminho é isso nos tornou mais fortes. Contando essas histórias de guerrilhas para os amigos, esses nos pediram para contar mais e então passamos a palestrar. As palestras nos aproximaram de pessoas que queriam saber de como resolvemos nossos problemas e então passamos a oferecer-lhes consultorias e assessments. Veja, todo esse empirismo não quer dizer que não estudamos e não buscamos conhecimentos de fontes externas. Muito pelo contrário. Estamos buscando conhecimento a todo tempo, lendo livros, blogs, conversando com outras referências e participando ativamente de eventos. Nós mantemos em constante evolução e gostamos disso. Porém, somos desenvolvedores como a maioria de vocês (eu particularmente trabalho com iOS) e compreendemos os problemas que vocês passam pois passamos por eles também em algum ponto da estrada. O Agile que falo não é algo que simplesmente li num livro ou vi numa palestra, mas sim algo que vivi e vivo a todo tempo, é como solucionei os meus problemas e como sanamos nossas dores. Enfim, falar de agilidade é um enorme prazer, contar meus casos é algo que realmente me fascina. Ser pago para isso é melhor ainda.

O processo de assessment é relativamente simples. Vamos até a empresa, conversamos com pessoas chaves no processo, observamos algumas evidências é baseado no que vimos e ouvimos redigimos um relatório mostrando os principais pontos de alavancagem, aqueles que com o menor esforço geram o maior resultado. Isso é extremamente pessoal e depende da avaliação de cada agilista. Tento ser imparcial e para isso sempre busco um par que me complete nesse trabalho. Minha visão pessoal busca sempre aspectos culturais e de negócio, por isso preciso de alguém técnico para me ajudar. Esse meu par tem o trabalho de olhar para onde eu não olhei, fazer as perguntas que eu não fiz, olhar os aspectos que eu deixei passar. É belo ver que o mesmo princípio do pair programming são aplicáveis aqui também. Já escrevi algo sobre isso por aqui, recomendo a leitura.

Após essa avaliação inicial vamos até a empresa e de posse do relatório, explicamos ponto a ponto da nossa visão sobre o processo para os membros da equipe e discutimos as diferenças de visão. Expomos então um plano de ação que consideramos ser o mais interessante. Esse é um aspecto que julgo ser um dos mais legais. Normalmente, quem trabalha com consultoria já faz isso como parte do processo. Você não chega numa empresa e joga um modelo pronto. Você avalia os pontos em busca da onde se pode atuar. A diferença é que numa consultoria isso funciona como uma venda casada, você coloca essas horas dentro do seu trabalho de consultor e as vende num pacote só. Gosto mais de como fazemos porque se você se sentir capaz de implementar essas melhorias propostas vá em frente! Se sentir que precisa de ajuda com alguma delas estamos aqui de qualquer forma. Nem precisa nos contratar para ajudar em todas, somente para os aspectos que sentirem que precisam de apoio. Isso sai muito mais barato para o cliente e logo estamos livres para pegar um próximo projeto e aprender e ensinar mais em um novo contexto.

Você pode estar pensando nesse momento que serviços assim devem ser caros e contratar profissionais de uma empresa de consultoria pode ser um passo grande em direção à melhoria contínua portanto, podemos deixar para depois. A parte legal é que caso queira começar com um modelo mais simplificado e auto aplicável o meu amigo Klaus Wuestefeld escreveu um template chamado os 9 registros da agilidade. Nesse trabalho, disponível aqui, você encontra uma planilha para compartilhar com sua equipe e tem 9 aspectos que vocês devem dar notas entre 1 e 5, dependendo de como a equipe se avalia. É importante que se visualize o modelo como sendo um grande cano é que os nove registros estão ao longo desse cano. Com esse modelo em mente pode se ter certeza que a vazão desse cano se limita pelo registro que está mais fechado. Assim se em vários aspectos a sua nota for 4, mas em colaboração por exemplo a sua nota for 1, então a nota final do seu processo é 1. O seu sistema se limita pelo elo mais fraco e esse é o ponto de alavancagem, pois ele desobstrui o seu sistema para crescer.

Querendo conversar sobre avaliações de sua equipe ou querendo conhecer um pouco mais sobre os modelos da torneira, me procure que terei o maior prazer em explicar.

Spice girl manifesto

Eu sou um cara casado. De casamento já se vão oito ótimos anos de vida juntos. Mas nos conhecemos antes disso, mais ou menos uns cinco anos antes. Somando tudo posso dizer que temos uma excelente convivência, uma vida compartilhada por assim dizer a pelo menos treze anos. Ainda assim, não posso dizer que a conheço completamente. Não sei de todos os seus anseios ou vontades, de todos os seus desejos e existem muitos momentos em que ela diz uma coisa querendo dizer outra. Embora isso possa parecer um lamento, é só um fato, que eu aceitei e levo a nossa relação tendo isso em mente. Mas é bem interessante de se pensar que pessoas que dormem e acordam juntos, que compartilham suas vidas de maneira tão intensa não sejam capazes de compreender as vontades um do outro por completo, não é mesmo?

Se mesmo com toda essa intimidade eu aceito o fato do desconhecido, porque você exige do seu cliente algo diferente quando vai iniciar um projeto? Sério, o paralelo não é tão distante. Vocês mal se conhecem, são pessoas em última instância, não empresas. E são desejos/necessidades de pessoas que precisam ser traduzidos em requisitos de software. O mal entendimento desses desejos e vontade pode sim decretar o sucesso ou o fracasso de um projeto. Assim como em casa eu uso várias técnicas para entender o que minha esposa espera de mim, aplico o mesmo pensamento no trabalho.

Outro problema, é a distância entre o desenvolvedor e o cliente. A começar pelo idioma. Enquanto o desenvolvedor entende profundamente o que acontece dentro do software é bem incomum ver esse mesmo profissional entendendo o que acontece no lado do negócio. Mais incomum ainda é ver o contrário, pessoas de negócio que entendem como o software funciona. Assim, esses profissionais falam idiomas diferentes e sua compreensão fica defasada por conta disso.

Só para fins de curiosidade, o título desse post veio de um treinamento de Kanban, ministrado pelo próprio David Anderson, no qual ele disse que mais do que o manifesto ágil, precisávamos agora de um manifesto spice girl. Vendo o espanto dos alunos, ele explicou: So tell me what you want, what you really really want… enfim, entender o problema, a necessidade, é metade da solução.

A seguir eu alguns métodos que usei em algum da minha vida. Não os estou julgando (ainda)…

Questionários
Uma técnica bem antiga, no qual o analista redige questionários e os entrega aos usuários chave do sistema. Muito útil com equipes mais tímidas ou para captar o máximo de respostas de todos os membros da equipe.

Entrevistas
Quanto os questionários se mostram muito frios, uma investigação mais profunda se faz necessária. Marcar entrevistas com os usuários, isolados ou em grupo, pode ajudar a esclarecer diversos pontos que outros métodos deixaram em aberto.

Observação
Nada mais simples do que, ao se automatizar algum processo, observá-lo e ver como o mesmo ocorre, sem depender da narração de outra pessoa. Nós temos o hábito de suprimir etapas, acreditando que são óbvias, ou que estão subentendidas no que já foi dito. Para evitar assunções, veja por você mesmo.

Análise de documentos
Verificar como as informações são registradas atualmente nos permite mapear muito de como o sistema deve ser e inferir quais mecanismos e processos o sistema deve ter para que possa atender àquela necessidade. Reconheço que usei muito dessa técnica no passado.

Essas quatro técnicas foram das que mais usei quando o assunto era automatizar/informatizar um processo que já existia, ou fora dos computadores ou mesmo dentro, em planilhas ou sistemas isolados, integrando tudo. Poderia usar a palavra “simples” para descrever esses sistemas, afinal, buscavam “somente” transformar o processo atual em algo mais dinâmico e seguro. Muito embora ainda exista demanda para esse tipo de sistema, a maior parte dos trabalhos que chegam até mim na última década está bem longe disso. As pessoas chegam com novidades, apps, webapps, enfim, soluções para coisas que não existem no mundo real. Esse novo tipo de aplicação exige uma nova abordagem. Mais do que buscar entender como um processo funciona, agora precisamos validar como o processo foi imaginado para entender se tudo é como se pensou. Assim, seguem os que uso nesse tipo de situação:

Brainstorming
O bom e velho “toró de parpite”. Aqui buscam-se todas as ideias possíveis e mais tarde nós a validaremos e pensaremos em qual rumo tomar. A proposta é muito simples: gerar o maior número de insights sobre o problema que o nosso aplicativo quer resolver.

Prototipação
Existem diversos tipos de protótipos. Desde usando ferramentas, frameworks até mesmo o bom e velho papel e caneta. Sério, isso já me salvou em algumas situações. O nível de realidade que se vai usar aqui depende somente do nível de abstração que seu cliente e você conseguem suportar. Enquanto existem pessoas que conseguem entender alguns rabiscos no papel e imaginar como a partir daquilo surgirá um aplicativo, muitos outros têm dificuldade e precisam de um detalhamento mais próximo do resultado final. Cabe ir avaliando isso ao longo do levantamento de requisitos.

Use cases
Como eu já ouvi gente batendo forte em use cases eu sou obrigado a citá-los aqui. Sim, eles são bons e são necessários. Eu acho bobo voltar àquele debate sobre a documentação, mas só para mencionar, sim, existem documentos que são necessários e precisam ser atualizados, mesmo na visão do mais fundamentalista dos agilistas. A parte boba disso é acreditar que isso (ou o oposto) se aplica a todo e qualquer documento. Tendo isso como posto, já tive processos complexos que precisaram não só de um use case, mas também de um diagrama de sequência para ficar claro para todo mundo. Depois que a tarefa foi cumprida o documento foi desprezado, mas para a sua execução esses documentos foram de vital importância.

e finalmente User Stories!
Como eu gosto muito desse modelo, eu vou deixar aqui só um gostinho, deixo para um outro post falar mais sobre o assunto. O que eu preciso dizer de imediato é que é uma das formas mais simples de coleta de requisitos, trabalhando com uma língua que desenvolvedor e cliente conseguem entender, dividindo o trabalho em unidades que agreguem valor ao produto/projeto, definindo critérios claros de validação para que todos os envolvidos saibam sem sombra de dúvida que o trabalho foi concluído.

Conclusão
Sem o menor preconceito, já usei todas as técnicas acima, umas mais ou menos, sempre buscando entender o que meu cliente precisava. Um bom desenvolvedor vai ter sempre uma boa caixa de ferramentas preparada para usar a certa no momento mais propício. Entender o problema é metade da solução.

Tem-gente-que-nao-sabe-pedir

Agile Tour 2014 – Missão cumprida!

LogoAgileTour2014Foi uma grande felicidade para mim. Esse foi o ano em que mais cidades tiveram o Agile Tour passando por elas. Em cada uma pude ver as pessoas felizes em receber um evento que fala de tecnologia, mas especialmente de pessoas e como trabalhar para que todas elas se sintam melhor em local de trabalho.

Iniciamos em Curitiba, depois São Paulo e então Campinas. Na sequência viajamos pelo interior do Paraná, para Cascavel e finalmente minha terra, Maringá. Outras cidades nos pediram eventos e vamos com certeza, com a força da comunidade (#AgilePower) fazer de 2015 um ano épico.

Em nome de toda a equipe organizadora, vai o meu muito obrigado a todos os participantes, palestrantes e patrocinadores que fizeram desse evento o grande sucesso que foi.

Todas as fotos, vídeos, grades e tudo o mais pode ser encontrado no site do evento.

Achamos um bug, o que fazer?

green_bug
Esse é mais um daqueles posts que eu vou só defender uma idéia. Não tenho a menor intenção de proclamar, como sempre, o que é certo ou errado. Deixo para vocês decidirem, depois de estudar um pouco o assunto, não só através dessa postarem, mas através de outras fontes também.

A história começa com a implantação de uma metodologia ágil, seja ela qual for. Todo o ciclo de desenvolvimento ágil se baseia na entrega de valor, através da entrega contínua e adiantada de software funcionando a nossos amados clientes. Tudo na mais alta qualidade, como todo profissional deve fazer. Acontece que nem sempre tudo ocorre como queremos. Como somos seres humanos, passíveis de erros, esses refletem no nosso trabalho e por conseguinte, em nosso código-fonte.

Mas como fazer? Aliás, quando fazer? Devemos contar o esforço desse nosso retrabalho como parte da nossa velocidade, ou como não estamos entregando valor algum novo ao cliente, não poderíamos contabiliza-los?

Em uma das empresas com as quais trabalhei, a consultoria que lá prestou o serviço antes de mim, instruiu o time de desenvolvimento a não contar os bugs. Afinal, em princípio esse trabalho não representa uma entrega de valor ao cliente, certo? Se pensarmos bem, os bugs em geral são trabalhos que, como não foram bem feitos no passado, voltaram para atrapalhar o presente e portanto são responsabilidade do time de desenvolvimento. Confesso que por muito tempo eu concordei com essa visão monocromática da coisa. Mas um dia me mostraram a luz e hoje vou partilhar com vocês.

Quando estive estudando a fundo os métodos ágeis, em especial o Scrum, descobri que eles são mais do que métodos para gestionar projetos ou equipes. Eles são modelos para gestão do conhecimento. Eles fomentam a colaboração entre os membros do time, entre os times e principalmente entre time e cliente. Todos partem do princípio que ninguém sabe o todo de um projeto e ao assumir isso, constroem o conhecimento dando um passo de cada vez. Lindo não? Um passo de cada vez, assim como é difícil planejar anos a frente por que muita coisa pode acontecer em nossas vidas, nós como seres únicos, imagine muitos de nós interagindo e criando pensando num objetivo comum, o projeto em questão. Cada pessoa que se soma ao time é um acréscimo infinito de complexidade. São novas idéias, novas habilidades, mas também novos egos, novas dificuldades. Em um cenário dessa complexidade, imaginar que se possa planejar mais do que algumas poucas semanas é um sonho muito distante. Por isso planejamos de maneira iterativa e incremental.

Esclarecida a parte do planejamento, vamos falar um pouco sobre as métricas que regem o nosso trabalho. Sim, somos ágeis e usamos métricas. Porque? Simples, vivemos no mundo real, das corporações, no qual os gestores precisam de métricas para avaliar se estamos indo bem ou mal em determinado projeto. Mas quais métricas são justas para o time e a gestão? Quais métricas fazem sentido? A coisa toda em cima dos bugs é que diretamente eles não agregam valor ao produto. Afinal não adicionam nada de novo e é algo que em algum momento alguém deixou de fazer certo, portanto devemos fazer certo agora, algo como pagar pelo débito que existe no projeto. Mas nem sempre é assim. Muitas vezes, muitas vezes mesmo, as empresas de software tem baixa retenção de funcionários/colaboradores e isso obviamente envolve os desenvolvedores. Assim a equipe que hoje mantém um produto pode quase nem ter mais alguém que faça parte da equipe original. Portanto puni-los fazendo com que suas métricas sejam desmotivantes não é o caminho.

Mas então, o que fazer com os bugs?

Simples, corrija-os. Mas e as estimativas? E os esforços? Respondo perguntando: a correção de um bug demanda esforço? Vai gastar tempo dos seus desenvolvedores? Poxa meu filho, se isso não vai se resolver magicamente, se as pessoas terão que gastar seu tempo e trabalho para resolver aquilo então isso merece uma estimativa de esforço. Não caia na armadilha de confundir métrica de esforço com valor de negócio. Realmente um bug não acrescenta valor nenhum ao negócio, ao produto e isso é fato, mas certamente vai demandar esforço do seu time.

Portanto, ao encontrar um bug, coloque-o no topo do seu backlog e lembre-se, ele vai te custar tempo, portanto deve ter a sua medida, em story points, homens-hora, pontos de função, o que seja. Embora realmente não isso não vai aumentar em nada o valor do seu produto.

Sobre martelos e pregos

Era uma vez um menino que fazia brinquedos, assim como eu ou você em nossa tenra infância. Sua ferramenta era a criatividade. Apenas ela.

Com ela, papel virava avião, galho virava varinha de condão e o mundo ficava mais divertido aos seus olhos. Digo aos seus olhos, pois qualquer adulto não entenderia a relação existente entre os objetos do mundo real e o imaginário daquele menino. Seu mundo não tinha limites. Sua capacidade de criar era infindável.

Um dia, seu pai resolveu que era hora de aumentar a sua caixa de ferramentas, até então só composta de imaginação, presenteando com um martelo velho que já não se usava mais.

A partir daí, seu mundo se abriu. Novos brinquedos surgiram, como pequenos robôs com retalhos de madeira, carrinhos com restos de rolamentos inúteis e por aí foi. Os brinquedos mais simples, como o papel e a varinha perderam a graça e seu gosto foi se afunilando por brinquedos mais elaborados, feitos com seu habilidoso martelo que ganhara de presente.
Conforme o tempo passou, outras ferramentas se somaram e com cada uma o menino descobria novas possibilidades.

Percebia que para criar carros melhores, precisava serrar aqueles retalhos de madeira e então veio o serrote. Percebeu que para que os movimentos de seu robô ficassem mais precisos, seriam necessários articulações parafusadas. Ao seu arsenal enfim se somavam então furadeira, parafuso e chaves de fenda.

Assim o menino cresceu feliz e se tornou um adulto versátil. Pois aprendeu que ter a ferramenta adequada para determinada situação é sempre o certo a se fazer.

Ok, o que quero dizer com essa história? Simples. Não é porque você aprendeu que existe o martelo, que tudo daqui para frente é prego. Não é por que você aprendeu sobre Java, que essa linguagem se aplica a todo projeto, não é porque você aprendeu Kanban, que o Scrum ficou ultrapassado ou ruim. Toda a ferramenta tem o seu valor e sua correta aplicação. Aprenda a usar todas e você saberá o momento certo de aplicar cada uma delas.