A verdade por trás das metodologias e de como elas podem arruinar seu projeto

A maior força das metodologias também é seu maior fraqueza. Elas resolvem problemas. Ou os problemas os que você tem, os que você terá.

Alguém, um dia, passou pelo mesmo processo que você está passando, enfrentou problemas, testou soluções, traçou um caminho “seguro” para seguir e colocou isso dentro do nome de uma metodologia. Isso é incrível! Por que não usar o conhecimento documentado por alguém que já percorreu os mesmos passos?

A resposta óbvia, mas muito pouco citada: é porque os caminhos quase nunca são iguais. Há sempre uma diferença de equipe, influenciadores, recursos, conhecimento, modelo mental e até mesmo de relacionamento entre as pessoas. Como um método pode ser capaz de se adaptar a todos esses cenários?

E, de fato, isso muitas vezes leva as metodologias a tentarem resolver problemas que talvez você não tenha, custando tempo, dinheiro, motivação e inspiração. A cada momento que você está trabalhando para resolver um problema que você não tem, você está perdendo seu tempo por completo. Você não está deixando de otimizá-lo para, ao contrário, perdê-lo por completo. Quem também nunca passou pela situação de estar seguindo um ritual de uma metodologia (essa é para você, SCRUM) e sentir que aquilo tinha muito pouco valor, só gerando atrito e burocracia para todos? Esse atrito pode ser determinante no sucesso de um projeto. E atrito é uma doença silenciosa, que mata aos poucos, lentamente e constantemente. Você só percebe dois anos depois, junto com uma intensa sensação de frustração. E acredite, isso pode destruir projetos e empresas por completo.

As metodologias são, então, ruins para meus projetos?

Definitivamente, não. Não sejamos maniqueístas. O que vai determinar se elas são boas ou ruins é a maneira com que nos relacionamos com elas.

O jeito mais interessante de se fazer isso é entendendo qual a proposta da metodologia. Quais são os grandes problemas que ela se propõe a resolver (e se isso não estiver claro provavelmente ela não deve ser tão boa), e depois como ela se propõe a fazer isso. Ou seja, qual o real resultado que a metodologia se propõe a trazer?

Peguemos o exemplo do Scrum. Antes de aplicar qualquer ritual da metodologia, devemos entender o que está por trás dela. No caso, o princípio de inspeção e adaptação para controlar complexidade e risco. Seu projeto precisa controlar complexidade e risco? Se sim, a maneira que a metodologia se propõe a resolver isso vai levar a esse resultado no seu caso?

A grande questão aqui é entender o grau de experiência que você e sua equipe têm para identificar, prever e resolver problemas. Um argumento inquestionável usado pelos grandes defensores de metodologias é que a maioria das pessoas não consegue identificar os problemas que tem e muito menos os problemas que virão a ter. Logo, seria mais seguro ir por um caminho pré-definido, mesmo correndo o risco de trabalhar em cima de problemas não existentes. Eu concordo com isso, para algumas equipes. Na verdade, me parece que quanto menos experiente uma equipe é, mais ela deveria se apoiar em metodologias existentes. O efeito colateral é que essas equipes raramente entendem o porquê estão fazendo isso e podem acabar desanimando do processo, pois não sabem porque eles existem e que dores estão solucionando. Além disso, o crescimento da equipe como um todo também fica prejudicado, pois nunca entrarão em contato com algumas necessidades que os criadores da metodologias vivenciaram dia-a-dia. A solução seria adotar inicialmente, mas rapidamente adaptá-la a realidade de contexto da equipe, evitando a maior parte dos efeitos colaterais.

O grande problema, contudo, está quando as equipes mais experientes cometem esse erro. Elas rodam lisas as metodologias, mas sem entender que gastar tempo e energia com processos desnecessários é um problema silencioso mas devastador. O efeito é ampliado pois essas equipes dificilmente abrem mão do processo aos quais estão acostumadas, mesmo quando os projetos tem características, objetivos e contexto diferentes dos quais estão familiarizados. É aí que você vê empresas rodando processos engessados em criações de protótipos ou processos muito soltos em produtos com baixa tolerância a risco. Se torna um problema cultural.

O efeito “metodologia pela metodologia”

É muito interessante também como algumas equipes adotam a metodologia como um fim, e não como um meio de se atingir certos resultados. Quem não conhece aquele sujeito antenado, que sempre está querendo implementar novos conceitos (AKA design thinkingholacracydesign sprintlean, Squads, burndown, etc) mas sem exatamente refletir o contexto e sobre quais objetivos finais queremos atingir?

Essa abordagem vai provavelmente trazer resultados medianos e, em alguns casos, catastróficos. Isso porque, na média, as metodologias funcionam bem. Alguém vai lá, documenta os processos que funcionam bem na maioria dos cenários e cria a metodologia. Logo, ela funciona para um grupo relativamente grande de casos, mas com resultados consistentes apenas na média deles. O problema é que, na média, as empresas e pessoas querem resultados acima da média.

Se considerarmos ainda os extremos, em contextos muito diferentes dos quais onde a metodologia foi criada, os resultados podem ser catastróficos.

Usando metodologias como diagnóstico

Um exercício interessante e muito construtivo é olhá-las como ferramentas de diagnóstico. Uma nova metodologia quase sempre é reativa a alguma mudança de contexto. Logo, ela pode nos dar boas dicas do quanto estamos adaptados a novos paradigmas como empresa e equipes.

Vejamos o caso da Burndown, proposto pela Drift. Ela tem como objetivo ter ciclos de desenvolvimentos ainda menores (no nível de funcionalidade) e mais proximidade possível com o consumidor final. O objetivo aqui é focar um pouco mais pra fora da empresa, e utilizar a aceitação de funcionalidades como medidor final de se as decisões de produto estão corretas. Veja o que está implícito dentro dessa metodologia:

  • Que montar o software corretamente e com menos risco não é mais o grande diferencial de mercado. Todo mundo já sabe construir software. Não é mais “como”, e sim “o que”. O diferencial é construir um produto que o consumidor final aprove.
  • Que, por mais que se tente, as funcionalidades planejadas têm risco elevado de não resolver corretamente os problemas dos usuários, logo, a interação rápida é extremamente importante para correção de rumos de produto.
  • Que as empresas tenham stacks de tecnologia que suportem entregas constantes e rápidas, além métricas de adoção. Leia: integração contínua, testes automatizados, analytics, escalabilidade de manutenção de código, etc.
  • Que você não tem mais um roadmap. Você tem uma visão de produto e uma série de funcionalidades que se adaptam a realidade de cada momento.
  • Que previsibilidade é menos importante que adequação de mercado.

Agora, analisando cada um desses pontos, você pode inferir como o contexto de mercado está mudando e diagnosticar se você entende e já está atuando nesse novo paradigma que está se formando.

Minha recomendação clara é essa: se você quer ter resultados acima da média, você deve ter uma atuação acima da média. Isso exige que você vá além de conhecer e implementar metodologias, mas saber o porque de cada decisão e julgar se a solução escolhida é a melhor para aquele cenário. Além disso, extrair o máximo do conhecimento trazido pelas metodologias. Vamos lembrar que, embora elas tragam resultados apenas medianos, elas são criadas por pessoas e equipes com uma visão muito acima da média. O grande valor está nos princípios que essas pessoas trouxeram, e não somente na sua implementação.

E quer se destacar de verdade? Crie sua própria metodologia.

Leave a Comment

A tirania da liberdade

Vivemos em uma época aparentemente muito mais leve, libertadora e cheia de novas possibilidades. Mas estamos realmente cientes das consequências de tudo isso ?

Há algum tempo, quando via empresas (startups), pessoas e famílias totalmente libertárias sempre tive um sentimento muito positivo, de que finalmente estávamos chegando a uma ordem social onde poderíamos ser nós mesmos e explorar todas nossas possibilidades. Hoje, vejo com certo receio. Receio de que não estamos plenamente preparados para tudo isso.

Isso porque liberdade gera insegurança. E para lidar com inseguranças precisamos de maturidade.

Se estamos em um ambiente totalmente livres, para fazer o que quiser, quando quiser, sem nada que nos conecte a nada, não estamos, senão, perdidos ?  Quantos de nós consegue realmente conviver com isso ?

Uma criança com total liberdade se sente não amada, desamparada e eternamente ansiosa. E quantos de nós viramos realmente adultos algum dia ?

Não estamos sempre buscando  nos conectar(e nos aprisionar) a pessoas, locais e atividades ?

Liberdade exige maturidade, você e sua empresa estão preparados para ela ?

Leave a Comment

A busca pela decisão perfeita

Buscamos sempre tomar as melhores decisões, com o máximo de informações possíveis, contemplando todos os cenários imagináveis. Errado.

Tomar decisões com a certeza de que são as melhores custa muito caro. Geralmente custa muito tempo e muita energia. E o principal: o custo de não tomar uma decisão é enorme.

Quando você não toma uma decisão você:

  • Está preso em cenários anteriores e em todas as possibilidades que ainda existem
  • Não consegue se dedicar a sua decisão
  • Transmite insegurança a si mesmo e a toda equipe
  • Não está coletando informações essenciais para as próximas decisões que aparecerão
  • Você está no limbo, perdido

O interessante é esse paradoxo no qual, ao entrarmos em um estado que precisamos tomar uma decisão, permanecemos nele por muito tempo, simplesmente pelo medo de não tomar a melhor.  Mas a decisão imperfeita geralmente não é tão ruim quanto o estado de limbo.

Tome decisões, mais rápido e mais frequentemente.  A decisão perfeita custa muito caro.  Ela pode nem estar correta. A  imperfeita geralmente é boa o suficiente.

Comments (1)

Por que remunerar a colaboração tem sido um fracasso

Assim que apareceram os primeiros sinais de que os serviços colaborativos teriam grande impacto sobre o modo com que se via e vivia a Internet, muita gente imaginou que poderia ir um pouco além: remunerar usuários para que eles estivesem mais dispostos a colaborar em alguns ambientes ao invés de fazê-lo em outros.

Na Wikipedia, por exemplo, as pessoas não ganham nada para postar e gerar conteúdo. Então, se eu criasse um serviço que pagasse o usuário por isso, ele preferiria contribuir em meu ambiente em detrimento de fazer isso na Wikipedia.  Faria sentido, parecia óbvio, mas foi um fracasso.

A principal razão aí é que não foi considerada a única grande variável que importa nessa questão: o comportamento humano.  Quando falamos de colaboração espontânea na web, estamos em uma esfera compotamental totalmente diferente de quando estamos sendo remunerados. Em geral, aceitamos perfeitamente realizar alguma tarefas gratuitamente simplesmente por um prazer social, como ajudar um vizinho em apuros, um desconhecido na rua. Isso nos torna “superiores” e de alguma maneira, torna a sociedade em débito conosco. Mas quando somos remunerados por isso, acionamos algum mecanismo que não nos permite fazer a mesma coisa sem que passemos por um filtro de avaliação de “trabalho vs remuneração”. O prazer, o senso de superioridade e débito desaparecem completamente e então entramos em um campo onde a remuneração de inexistente, passa a precisar ser alta o suficiente para que justifique nosso trabalho.

Em outras palavras, ou se paga muito, ou não se paga nada. E, de fato, a maioria dos serviços que tratam com remuneração da colaboração estão passando, de promessa inquestionável, ao fracasso inevitável.

Essa e outras idéias de como alguns mecanismos humanos funcionam, bem ilustrados, com diversos exemplos e experimentos, estão no livro de Dan Ariely: Previsivelmente Irracionail


Comments (1)

Como escolher nomes na Era das mídias sociais

Em um mundo cada vez mais fragmentado e interconectado, conseguir saber quando, quem e onde estão falando de você, da sua marca ou mesmo de seus concorrentes pode ser uma vantagem estratégica enorme. A grande vantagem dos sistemas atuais é a possibilidade de encontrar essas informações através de buscas. Entretanto, tal vantagem só pode ser considerada se você de fato consegue encontrar as informações.  A questão é que, se você escolher um nome muito comum para seu produto, campanha ou empresa, uma palavra que possa ser usada em muitos outros conceitos e situações do dia-a-dia, você terá muita dificuldade em encontrar as informações que realmente procura.

Por isso é tão importante escolher nomes que possam ser “tagueados” de forma única em campanhas, produtos e nomes em geral. Você nunca sabe quando precisará encontrá-los nas mídias sociais. E um dia você certamente irá.

Leave a Comment

Generalização é a alma do negócio

imgprodutocopias

No último Social Media Brasil falei sobre “4 erros estratégicos simples cometidos na criação de redes sociais” (corporativas) e um usuário, via twitter, questionou meu slide  “Não faça o usuário pensar. Ninguém gosta de pensar”, por estar generalizando a questão.  Achei ótimo, pois era exatamente disso que eu estava falando: generalização como estratégia para executar projetos de sucesso.

O que a maioria de empreendedores e criadores de produtos procuram é escala. Um modelo de negócios que tenha escala permite crescer o faturamento sem crescer a estrutura na mesma proporção.  Um produto é, em essência, uma tentativa de se conseguir escala, desenvolvendo-o apenas uma vez e replicando-o sem custos adicionais. E como se consegue escala ? Generalizando.

A generalização é o resultado da descoberta de padrões que são comuns a um grupo de pessoas ou processos. Aí você tem uma possibilidade de ganho de escala. E esse então deve ser seu foco, atender a essas pessoas. A quem eventualmente não se aplicar não importa.  Deixar de generalizar pode ser um erro muito grave.

Por isso, repito mais uma vez: não se deve tentar agradar a todas as pessoas a todo o momento. Pelo menos criando negócios e produtos de Internet.

Comments (5)

Case Blogblogs: a web colaborativa é perigosa

A liberdade e colaboração na web é como um megafone. Para ações bem realizadas, a colaboração funciona como um propulsor para levar sua mensagem ao número máximo de pessoas. O problema é quando as ações não saem exatamente como esperado e não são bem aceitas pelos usuários. Aí fica extremamente perigoso, pois o poder de destruição da web também é muito grande.

O caso BlogBlogs está ocorrendo exatamente nesse momento (10 Dez 2008, 11:30). Como estratégia de divulgação do novo site, foi colocada uma tela de manutenção que simulava o site hackeado, um aviso de que aquilo era brincadeira e um link que levava a um live stream do escritório da empresa.

O problema é que muita gente não gostou. Não vou entrar no mérito de julgar a ação, mas o fato é que muita gente não gostou nem um pouco. E aí começaram uma série de comentários no twitter e no livechat destruindo a credibilidade do Blogblogs. O negócio ficou feio. No chat, muitos xingamentos, brigas. No twitter, muitos criticando a ação e alguns até prometendo retirar os widgets dos seus blogs.

Diante disso, temos que repensar alguns fatos, antes de lidar com estratégias arriscadas na web 2.0:

1. Existem evangelizadores assim como existem “destruidores” (trolls). Reclamar não adianta, você deve lidar com o fato. Procurar fazer algo que incentive os evangelizadores e acalme os “destruidores”.

2. Ações não funcionam para todos os grupos de pessoas(usuários). A ação do BlogBlogs não foi bem entendida por todos que visitaram o site. Claro, pois quem mais acessa o site são leitores e não blogueiros. E o leitor em geral não entendeu. Então você atingiu a todos os usuários (eventualmente retirando credibilidade do serviço) e esperando atingir pequena parte deles.

3. Destruir é mais fácil que construir. Uma ação que tem um risco igual de ser destrutiva e construtiva, deve cair no lado destrutivo.

Comments (6)

Porque ter um “produto melhor” é irrelevante

A compra de um produto é uma decisão emocional. Depois racionalizamos e justificamos nossas escolhas, fazendo que pareça que tenha sido uma escolha racional. Por isso, o caminho comum: mais funcionalidades -> melhor produto -> mais vendas está errado. A única coisa que precisamos é que o produto tenha funcionalidades e qualidades suficientes(base) para que possamos justificar nossa escolha emocional.

Por isso que, em uma época em que os celulares estavam brigando por quem tinha mais funcionalidades, aparece um Iphone, com metade das funcionalidades e abocanha grande parte do mercado. Apple vende estilo e tem um ótimo produto, com um ótimo design, para justificar isso.

Reblog this post [with Zemanta]

Comments (4)

Porque a colaboração está virando uma bolha

Momentos de extrema euforia em torno de algum assunto ou tendência criam bolhas, ou seja, o otimismo se torna tamanho que o investimentos nessas iniciativas se torna irracional. Infelizmente isso está acontecendo em relação a colaboração na web2.0.

Todo mundo está acreditando na colaboração, de modo sistemático e cego, como se fosse algum tipo de mágica que, a partir do nada, coisas maravilhosas acontecem. Não é bem assim. Colaboração acontece em momentos e ambientes bem propícios e específicos. Não é uma das maiores facilidades, mas uma das maiores dificuldades da web 2.0.

Algums mitos da colaboração:
- colaboração dá lucro naturalmente.
- colaboração acontece naturalmente e cresce exponencialmente em sistemas desenvolvidos para isso.
- funcionalidades colaborativas = colaboração
- todas as pessoas vão colaborar, se puderem

Comments (2)

Comunicação, colaboração e agilidade

Se eu fosse resumir métodos ágeis em poucas palavras seria: “comunicação, colaboração e agilidade”. Isso que dizer: se você não está comunicando-se bem, está errado. Se não está colaborando, está errado. Se está lerdo, preso a processos, também.

Nas última década arquitetos e times de programadores de software têm entendido que para construir produtos realmente relevantes, é necessário uma abordagem diferente do que vinha sendo aplicado nas décadas anteriores. Produtos são organismos que precisam de constante mudança, colaboração e comunicação constante de usuários e time de desenvolvimento e, acima de tudo, serem funcionais. Em tempos onde as empresas precisam inovar, se adaptar e colaborar interna e externamente, entregando resultado, tem tudo a ver.

As 4 bases do manifesto ágil, que podem ser aplicadas a empresas:

Individuals and interactions over processes and tools

A criação, reflexão e visão vs Processos engessados.

Working software over comprehensive documentation

Entregar valor vs Plano de negócios e pesquisas de mercado.

Customer collaboration over contract negotiation

Engajar/Colaborar vs Contratar/Vender/Cobrar

Responding to change over following a plan

Responder às mudanças vs Seguir o plano original

Leave a Comment

Page 1 of 512345