Rafa Nascimento

Software Product Studios: desenvolvendo aplicações inovadoras e profissionais competentes

Posted in cultura by Rafa Nascimento on 06/08/2013

No Brasil, a quase totalidade do mercado de tecnologia é composta por fábricas de software e consultorias de desenvolvimento de software. Nestes modelos, o principal foco é vender mão-de-obra. Há, basicamente, 2 formas de se fazer dinheiro nestes modelos: projetos de software e manutenção de software. As fábricas e consultorias dispõem de mão-de-obra (nem sempre) qualificada, e cobram às empresas pela utilização de sua capacidade de produção, relegando projetos de software e a manutenção dos mesmos a meros contratos de prestação de serviço de desenvolvimento de software.

O surgimento das fábricas e consultorias de software
Antes de revolução industrial, todo trabalho era realizado de forma manual. No máximo, com a ajuda de uma ou outra pequena ferramenta. Quando a demanda era muita, os trabalhadores organizavam-se em grupos para atender a necessidade. Com a competição cada vez mais acirrada promovida pela revolução industrial, estes trabalhadores viram seu trabalho ser industrializado e reproduzido em larga escala. Eles não precisavam mais se preocupar com os custos de matéria-prima, mas também perderam seus lucros para os donos de indústrias. O modelo industrial de produção em larga escala espalhou-se por todo o mercado de trabalho, firmando-se como regra. Para atender às indústrias surgiam, em paralelo, as grandes corporações para prestação de serviços administrativos.
Com o crescimento da tecnologia e a explosão da computação nos anos 70, as corporações e indústrias passaram a utilizar computadores para automatizar processos repetitivos e economizar em mão-de-obra, gerando a necessidade por profissionais que soubessem operar e programar os computadores. Surgia, então, o departamento de processamento de dados, que posteriormente viraria o departamento de TI. Porém, rapidamente o alto custo destes departamentos fez com que eles passassem por um processo de downsizing, que manteve nas empresas apenas gestores e analistas de sistemas à época. Como resultado deste processo, as empresas ficaram responsáveis apenas por manter seus sistemas funcionando e solicitar o desenvolvimento de novos sistemas à empresas terceiras, detentoras de mão-de-obra qualificada: as fábricas de software e consultorias de desenvolvimento de software.

Os problemas do modelo
Os problemas deste modelo de negócio são inúmeros. Tenho certeza que, com quase 15 anos de carreira, só conseguirei enumerar alguns de muitos outros que você pode apontar. É inegável que o modelo é lucrativo se pensarmos que o software pode ser montado como um carro. Pena que não é. Além disso, o modelo é danoso para o mais importante dos 3 pilares (produtos, processos, pessoas) de uma empresa: pessoas.
Neste modelo, o principal foco é o cumprimento de um contrato baseando-se em alocação de mão-de-obra especializada. Seja em um projeto, em uma equipe remota de suporte à produção ou diretamente no ambiente do cliente. Como os contratos, em sua grande maioria, são formatados em valor-hora, o cliente fica obrigado a garantir que o dinheiro está sendo bem investido. Ou seja, que as pessoas destinadas ao seu contrato estão produzindo cada minuto das horas contratadas, ou das horas que estão sendo pagas. Daí surge o primeiro problema: além de cobrar-se por um trabalho abstrato de forma exata e concreta, não há investimento na competência dos profissionais, e frases como “porque dar treinamento se as pessoas vão embora?” surgem. Com isso, gera-se a famosa rotatividade de profissionais nas fábricas e consultorias de software. É bom frisar que cada um é responsável pelas suas próprias competências. Também é bom frisar que uma empresa, um conjunto de pessoas, também é responsável por suas competências. Que reside nas pessoas. Principalmente quando falamos em trabalhadores do conhecimento. Junta-se a isso o fato de que, se considerarmos que todo software é composto de conhecimento sobre tecnologia e conhecimento sobre negócio, podemos dizer que metade do conhecimento do software vai embora com cada pessoa que busca uma recolocação no mercado. Invariavelmente, a insatisfação é a mesma: cobrança baseada em cronogramas ou em contratos e falta de investimento em competência.
O segundo problema é o foco no produto errado. Quando se trabalha com alocação de mão-de-obra no modelo homem-hora, o produto passa a ser as horas produtivas das pessoas. E, para os clientes, as horas produtivas dos profissionais das fábricas e consultorias são as horas que os desenvolvedores utilizam resolvendo problemas em produção através de uma linguagem de programação ou despejando código em um projeto, onde ele faz parte de uma “equipe”, porque em “equipe” o sistema não demora tanto para ser desenvolvido.
Segundo Julio Sergio Cardozo, professor e ex-CEO da Ernst & Young, no artigo “O Fim do Taxímetro”, o modelo de negócio utilizado nos últimos 200 anos pelas empresas de serviços profissionais pode ser expresso pela seguinte equação:

Receita = quantidade de profissionais x eficiência x taxa horária

Nessa equação, a quantidade de profissionais representa todo o contingente de profissionais que possa ser destacado para prestar serviços aos clientes; a eficiência corresponde à combinação de horas disponíveis e a taxa média de débito a clientes ou de utilização desses profissionais; e a taxa horária, ou taxa de realização, significa o valor médio por hora cobrado pela empresa.
No artigo, Julio sugere a aposentadoria do timesheet e um modelo de precificação por mérito ou benefício gerado, expresso pela seguinte equação:

Lucratividade = capital intelectual x preço x eficácia

Essa equação, quando comparada com a equação que representa o modelo tradicional, mostra alterações substanciais no modelo de negócio. A troca de receita por lucratividade como resultado da equação se deve ao fato de que a gestão sadia do negócio não busca o crescimento pelo crescimento, e sim a solidez financeira do empreendimento.
Outra troca igualmente notável é de taxa horária por preço, pois, afinal, o cliente não está comprando horas, o que, aliás, nada significa para ele, que busca soluções para suas necessidades. No novo modelo de negócio aqui proposto, a precificação está diretamente correlacionada com o valor entregue ao cliente, ao benefício que lhe é proporcionado. É uma quebra de paradigma para a qual os profissionais precisam estar mental e emocionalmente preparados e dispostos. E não é rápida.

Os 2 pilares do desenvolvimento de software
Há 2 pilares essenciais no desenvolvimento de software, que funcionam em retro-alimentação: produto e pessoas. Se você tem um produto, ou uma visão, relevante e inspirador o suficiente, você consegue boas pessoas trabalhando ao redor da causa. Se você tem pessoas cada vez mais competentes e autônomas trabalhando ao redor do seu produto ou da sua visão, ele pode se tornar cada vez mais relevante, útil e bem-sucedido. E é este equilíbrio que precisa ser atingido através de processos que maximizem as interações positivas e minimizem as interações negativas no ambiente de trabalho, criando um ambiente produtivo e próspero para o produto e para as pessoas envolvidas em seu desenvolvimento.
Felizmente, o mercado brasileiro vê, hoje, uma nova forma de trabalhar o software. Alguns já falam na “era da economia de software”. Ironicamente, uma forma bem-sucedida há décadas no Vale do Silício. Vemos o surgimento de cada vez mais startups com foco em um produto e que conseguem, na grande maioria das vezes, as melhores cabeças pensantes da indústria e investem pesado no desenvolvimento de suas competências. Não por acaso, muitos desenvolvedores, experientes ou não, estão migrando para as startups de produtos. Não é só a autonomia de uma empresa-bebê que seduz. É, também, o foco em um único objetivo que chama a atenção. Ainda mais quando é um objetivo com o qual você se identifica em seus valores.
Em uma fábrica de software, normalmente temos unidades de negócio (organizadas de forma hierárquica e, por conseguinte, errônea) atendendo cada uma a um cliente (ou “conta”) específico. Nesta unidade, há a disponibilidade de diversos desenvolvedores, que são alocados de acordo com o seu conhecimento em determinada tecnologia. Ou seja: há os profissionais que cuidam de sistemas em Java, há profissionais que cuidam de sistemas em .NET, há os que cuidam de Cobol, há os DBAs e assim por diante. Normalmente, estas unidades de negócio prestam serviços de desenvolvimento de novos sistemas e suporte a sistemas já existentes. Assim, há uma frequente alocação e desalocação de desenvolvedores em frentes diferentes de trabalho, fazendo com que os mesmos acabem precisando focar em mais de 1 sistema ao mesmo tempo, para garantir que suas horas estão 100% preenchidas em um dia de trabalho.
Já em uma empresa focada em produtos, é possível ter equipes mais homogêneas, focadas em 1 problema por vez e em problemas menores, possibilitando o crescimento da qualidade do produto que está sendo desenvolvido e disponibilizado aos clientes. Pode haver equipes focadas em produtos distintos (37 Signals), ou equipes focadas em partes distintas de um grande produto (Facebook), mas todas as equipes são orientadas a um aspecto de negócio, com uma grande mistura de tecnologias, e não são orientadas a determinadas tecnologias, gerando, assim, equipes verdadeiramente multidisciplinares.

Software Product Studios
Em um mercado cada vez mais focado em pessoas, há cada vez menos espaço para o modelo de fábricas e consultorias de software. Um modelo ainda industrial, de altos lucros e que acredita que o trabalho de desenvolvimento de software pode ser padronizado e replicado em larga escala através da contratação de mais e mais desenvolvedores. Teorias como Management 3.0, empresas como a Evernote e o Facebook, as experiências das agências digitais e dos estúdios de aplicativos móveis já nos provaram que a criatividade essencial para o desenvolvimento de softwares inovadores e realmente úteis está muito longe do modelo de fábricas e consultorias.
Trabalhar o software como produto, e não como serviço, pode ser a maneira mais eficaz de gerar inovação, por ser um modelo que depende e muito da autonomia, do conhecimento e da maestria de seus profissionais, fazendo com que as empresas invistam cada vez mais em suas competências em troca de ideias colocadas em prática para produtos com os quais seus profissionais se identificam e querem ver crescendo e ganhando mercado.
Em um mercado mais justo, onde um produto, em grande parte, é vendido através de sua reputação, e não através de esforço de vendas de analistas comerciais e seus contatos, há espaço para cada um desenvolver o seu melhor em nichos específicos, e competir em um formato onde o vencedor tem mais qualidade, e não o menor preço.

Back to the Basics: o poder das restrições

Posted in cultura by Rafa Nascimento on 09/06/2013

Serra

Neste sábado, dia 8 de junho, viajei até Nova Friburgo, atendendo a um convite para palestrar em um evento organizado pelo Serra do Silício, um movimento de alguns empresários e profissionais liberais da área de TIC (Tecnologia de Informação e Comunicação) da região que visa unir toda a categoria para alavancar negócios, gerando emprego e renda. Uma alusão ao Vale do Silício, nos EUA. Este grupo organizou um ciclo de palestras especificamente voltado para a disseminação de métodos ágeis para o desenvolvimento de software e das disciplinas ligadas aos métodos. Foi um evento bastante proveitoso, principalmente, pelo visto, para os profissionais da região.

Nova Friburgo é um município do interior do estado do Rio de Janeiro, localizado a uma altitude média de 985 metros, na região serrana do estado. Hoje com aproximadamente 200.000 habitantes, possui uma economia baseada na indústria de moda íntima, olericultura, caprinocultura e indústria (têxtil, vestuário, metalúrgica e turismo) e é a cidade mais fria do estado.

Em média, as empresas da área de TIC de Nova Friburgo são fisicamente pequenas, com uma média entre 15 e 20 funcionários e um faturamento médio em torno de R$ 20.000,00 mensais. O salário médio de um profissional da região, seja um desenvolvedor ou um designer, gira em torno de R$ 1.500,00, atingindo raros picos de R$ 2.500,00. Comparando-se com a cidade do Rio de Janeiro, onde o salário médio na área, hoje, gira em torno de R$ 5.000,00, é fácil prever para onde os profissionais de Nova Friburgo que se destacam vão. Isso inclui, obviamente, a troca de conhecimento, experiências e o poder de capacitação da cidade do Rio de Janeiro.

Os maiores clientes que as empresas de TIC da região podem ter (as grandes indústrias) importam tecnologia da capital, de outros estados e até mesmo de outros países. Isso faz com que o mercado local de médias e pequenas empresas e o comércio local sejam a maior fonte de renda destas empresas, dificultando a retenção de bons profissionais e estagnando o mercado. Uma das poucas opções que sobram para os empresários locais de TIC é unir forças para fortalecer o mercado local.

Ao chegar para o primeiro Serra do Silício Talks, tive, de imediato, uma grande surpresa: casa cheia. O que demonstrou, de cara, o grau de comprometimento não só dos empresários em relação ao seu mercado local, mas também dos desenvolvedores e designers que ali trabalham. Conforme observei, conversei e, principalmente, escutei as histórias durante o dia, pude compreender que eu não deveria ter ficado tão surpreso: o tamanho do mercado (algumas centenas de profissionais de TIC, contra dezenas de milhares de profissionais da cidade do Rio de Janeiro) permite uma sinergia muito forte entre os empresários e os seus funcionários, chegando ao ponto de não se conseguir identificar quem é empregador e quem é empregado. Ambas as partes, guardadas as devidas proporções de informação às quais cada parte tem acesso, possui uma visão político-econômica muito boa da sua região e do seu mercado. Ambas as partes possuem um conhecimento muito bom de tecnologia. O respeito entre os profissionais e empresários é grande, porque o mercado é pequeno.

Conforme o desdobramento das palestras, pude perceber a presença de diversos empresários locais. Competidores. Sinceramente, eu não me lembro de observar algo parecido na cidade do Rio de Janeiro. O movimento não é liderado por 1 ou 2 grandes empresas que dominam o mercado local. É um movimento de todos juntos. Grandes, médios e pequenos. Iguais. Empresários, desenvolvedores e designers. Todos participando juntos do evento, e discutindo de igual pra igual. Neste momento, pude perceber o quanto a quantidade de degraus em uma hierarquia é nociva para a colaboração entre profissionais e a saúde de seus produtos.

Impressionou-me, também, durante o evento e mais ao final dele, a dificuldade que tive em identificar quem era empresário, e quem era funcionário. Os discursos, as dúvidas, os questionamentos e as dificuldades, salvo algumas exceções, eram os mesmos. Em uníssono. Isso porque não há negligência de informação em um mercado tão pequeno. Todos têm o mesmo nível de informação sobre o seu mercado, e acabam, sim, discutindo sobre todos os aspectos do seu mercado a qualquer momento e em qualquer lugar: de contratos a deploy. Naquele mercado, profissionais extremamente especializados não são bem aproveitados. É mais do que comum encontrar um designer que trabalhe com front-end, um desenvolvedor que que faça o mesmo, desenvolvedores levantando regras de negócio, empresários trabalhando junto no levantamento do ambiente de produção e até mesmo desenvolvedores discutindo aspectos econômicos do seu mercado enquanto mexem no Git.

Mas o que mais me chamou a atenção foram os tipos de dificuldades que aqueles profissionais têm enquanto tentam trabalhar utilizando a filosofia Agile. Entre algumas dificuldades em comum com as que temos no Rio de Janeiro, e algumas que já superamos, algumas dificuldade que temos quase que em massa por aqui são praticamente estranhas por lá: a utilização de equipes legitimamente multifuncionais, participação dos funcionários em todo o processo decisório do software, responsabilidade pelo processo como um todo e a produtização do software, que é facilmente identificada por ali.

As restrições impostas pelo tamanho do mercado de TIC de Nova Friburgo obrigou aqueles profissionais a cultivar 2 valores que, na minha opinião, são fundamentais para que a filosofia Agile esteja presente em um ambiente profissional: simplicidade e humildade. Agradeço imensamente o convite do pessoal do Serra do Silício, a hospitalidade e, principalmente, a aula silenciosa sobre como os valores de uma comunidade fazem muito mais diferença e trazem muito mais benefícios e resultados do que metodologias e boas intenções, e permitem que um mercado se una em prol da sua própria sobrevivência, além da competição e do individualismo.

Para mim, foi extremamente importante voltar ao pequeno, voltar às dificuldades do restrito, e poder observar que, muitas das vezes, um banquete de opções não trará solução alguma, mas, sim, a falta delas.

Parabéns aos envolvidos. :)

Manifesto para Transformação Ágil

Posted in mudança by Rafa Nascimento on 19/05/2013

Imagem

Um dos maiores desafios de consultorias e departamentos de TI hoje em dia é a transição de um paradigma tradicional de gestão e desenvolvimento de software pautado no Waterfall para o paradigma Agile. Como já vimos em um post anterior, não há mudança rápida e fácil quando lidamos com a cultura corporativa. Em 5 anos de experiência e observação usando métodos ágeis para gerenciar projetos e desenvolver software, ajudando empresas a aprender métodos ágeis e a iniciar seus processos de transição para um paradigma de desenvolvimento de software mais ágil, apresento-lhes um padrão que percebi e eu mesmo venho aplicando recentemente para auxiliar no processo de transição de paradigmas e proporcionar uma transformação cultural mais consistente e menos dolorosa para consultorias e departamentos de TI, além de criar um mindset que permite espalhar o novo paradigma organização/cliente adentro. Abaixo, o Manifesto para Transformação Agile:

Cristalizar, para enxergar os problemas
Conscientizar, para identificar o impacto causado pelos problemas
Educar, para aprender novas abordagens de resolução dos problemas
Experimentar, para confrontar as novas abordagens com a realidade
Cristalizar, para enxergar os problemas
Adaptar, para adequar a teoria à realidade
Reagir, para sensibilizar e motivar a mudança
Estabilizar, para combater o status-quo
Cristalizar, para enxergar os problemas

Quando escolhemos mudar o paradigma da nossa equipe, departamento ou organização, o primeiro passo que precisamos dar é o de Cristalizar o ambiente, com o objetivo de enxergar os problemas que residem no processo e no ambiente. Sem saber que problemas existem no nosso ambiente, não há motivos para promover uma mudança. Independente das práticas que serão utilizadas para visualizar os problemas que queremos resolver (Kanban, enquetes, profiling de equipes, etc.), o objetivo deste passo é responder à pergunta: Que problemas existem no meu ambiente/processo?

Com os problemas à vista, ainda não é hora de promover mudanças. Isso porque há um status quo, uma zona de conforto que permite que os problemas sobrevivam. Permite que os problemas assumam o status de “normais” naquele ambiente e assumam um espaço importante entre os valores culturais da organização ou da equipe. É preciso, então, Conscientizar quem compartilha desta cultura e, assim, sensibilizar através do questionamento do status quo atual as pessoas que estão envolvidas na mudança, fazendo com que outros valores também existentes na cultura predominante tornem-se mais importantes do que aqueles que permitem a sobrevivência dos problemas. Isso gera um senso de urgência em prol da mudança. O objetivo deste passo é responder à pergunta: Que impacto os problemas causam às minhas cadeias de valor?

Neste ponto, convencidos de que a mudança de fato é necessária e benéfica, mesmo sem dados que comprovem tal convicção, muitas empresas e equipes optam por já promover a mudança, “na cara e na coragem”, e, obviamente, passam por inúmeros problemas pois não há conhecimento suficiente fundamentando o desenvolvimento de um novo paradigma. É preciso, agora, Educar os envolvidos lna mudanças para que eles agreguem o máximo de conhecimento possível relacionado ao novo paradigma e possam, assim, resistir à tentação de retornar à zona de conforto, onde o conhecimento já está enraizado, “no sangue”. O objetivo deste passo é responder à pergunta: Como posso melhorar meu processo e ambiente?

Quando todos os envolvidos na mudança possuem o conhecimento necessário para que possam seguir em frente com o movimento, é hora de Experimentar a nova abordagem. É hora de adotar novas práticas para resolver problemas, gerenciar projetos e desenvolver produtos. É hora de gerar novos dados que nos ajudem a avaliar como o nosso ambiente está se comportando frente à nova abordagem. O objetivo deste passo é responder à pergunta: As ferramentas que escolhi são as melhores para resolver os meus problemas?

Neste ponto, precisamos Cristalizar novamente o nosso ambiente. Isso porque novos problemas estarão presentes em nosso ambiente, e precisamos enxergá-los para que possamos mitigá-los, já com uma nova abordagem em mãos.

Com os dados colhidos durante a nossa experimentação e os problemas que surgirão frente à nova cristalização, é hora de Adaptar as novas práticas à realidade do nosso ambiente. Agora, todos os envolvidos na mudança tem o conhecimento teórico e prático que permitem que nenhuma abordagem seja deturpada, permitindo uma adaptação à realidade segura e resultados promissores. O objetivo deste passo é responder à pergunta: Como posso manter o valor das ferramentas escolhidas sem engessar minhas atitudes?

Após diversos experimentos e adaptações, que nos geram cada vez mais dados relativos às nossas diversas cadeias de valor, é hora de Reagir. Esse é o momento de confrontar os novos dados, colhidos durante a utilização de uma nova abordagem, e confrontar com os antigos dados colhidos enquanto cristalizávamos o ambiente em seu estado inicial. É o momento de expandir o senso de urgência e contagiar mais pessoas e departamentos perante os resultados provenientes de uma nova abordagem para desenvolver produtos e gerenciar projetos. O objetivo desta passo é responder à pergunta: Meu estado atual é realmente melhor que o meu estado inicial?

Se a reação é bem-sucedida, e há um contágio com a nova abordagem, a mudança ganha um caráter natural e um novo status quo começa a surgir, mas os valores que mantinham o antigo status quo vivo ainda existem e não descansam enquanto não trazem a zona de conforto de volta. Além disso, há o aspecto da “novidade” que começa a dissipar-se, abrindo mais espaço para a a volta do antigo status quo. Neste ponto, considero importante o trabalho de pessoas com um perfil mais controlador, porém, que também tenho o mesmo nível de conhecimento que os demais envolvidos na mudança, e sejam capazes de Estabilizar o novo status quo sem trazer de volta o antigo status quo travestido de novidade. O objetivo deste passo é responder à pergunta: Meu estado atual é realmente consistente?

Por fim, é necessário Cristalizar o novo ambiente e identificar os novos problemas, e passar novamente pelos mesmos passos que ajudarão a promover novas mudanças no ambiente e no processo, ajudando a germinar uma nova cultura de melhoria contínua, suave e indolor.

Você tem um propósito ou tem medo?

Posted in comportamento by Rafa Nascimento on 05/12/2012

Você tem um propósito? Ou tem medo?
Vou exemplificar:

  • Geralmente, startups têm um propósito.
  • Geralmente, empresas já consolidadas no mercado têm medo.

“Ok, então o que você me diz de Google, Facebook, Amazon e Thoughtworks, esperto?” – você perguntaria.

Eu digo que estas são algumas das pouquíssimas empresas já consolidadas que compreenderam a importância de se manter à beira do abismo no mercado de tecnologia, e conseguiram aprender a sua maneira de dominar o risco constante. Quando falamos em tecnologia, inovar é essencial. Quando falamos em inovação, risco é uma palavra que nunca ficará de fora. E, pasmem! Quando falamos em inovar, não falamos somente de tecnologia! :P

Certa vez, escutei uma mãe falar pro seu filho: “Temos que trabalhar! Trabalhar para ganhar dinheiro!”. Que desperdício! Temos todo o conhecimento do mundo disponível para nós, cada vez mais fácil e barato, e o que fazemos? Usamo-o em nosso próprio benefício, sem sequer devolver ao mundo e apenas ajudando as empresas para as quais trabalhamos (e seus donos) a enriquecerem. Em troca de uma parcela dessa riqueza para que possamos “nos sustentar”. Só isso.

Que diferença você quer fazer no mundo? Essa é a pergunta que deve pautar todos os nossos esforços em busca de conhecimento e na aplicação dos mesmos. Fazer a diferença, e não fazer o mesmo. Entregar nossas possibilidades de conhecer nas mãos das empresas é o pior caminho que podemos escolher. Mas o mais fácil, sem dúvidas. O problema é que fazendo isso apenas garantimos que não vamos passar miséria, e gastamos anos e anos de nossas vidas em prol desse propósito pífio. Fazer a diferença não é fazer algo grandioso e ser o próximo Zuckerberg. É apenas ter um propósito, ter uma visão.

Muitas empresas têm visões e missões. Poucas lembram, hoje, o que está escrito por lá. As que lembram e as mantém vivas, vou citar e vocês podem julgar seu grau de sucesso por si só:

  • Google: “Organizar a informação do mundo e fazê-la universalmente acessível e útil.”
  • Facebook: “Dar às pessoas o poder de compartilhar e fazer um mundo mais conectado e aberto.”
  • Amazon: “Ser a empresa mais orientada ao cliente da Terra; criar um lugar onde as pessoas podem encontrar e descobrir qualquer coisa que elas queiram comprar online.”
  • Thoughtworks: “Melhorar a humanidade através do software e ser um modelo para a nova empresa socialmente responsável do século 21.”

Estas empresas aprenderam a respeitar o seu propósito, e conseguiram desenvolver maneiras de balancear seus propósitos com a cobrança ferrenha do mercado capitalista. Posso apostar que não é nada fácil.

A boa notícia é que não são só empresas que podem ter missões! Pessoas também podem! :)
A minha está aqui:

“Desenvolver times disciplinados, auto-organizados, auto-gerenciados e bem-sucedidos.”

Muito trabalho aqui, né? Sim! A ideia é essa! Uma missão não é algo tão curto-prazo quanto um objetivo. É de um prazo muito maior. Eis as definições de visão e missão, segundo a Wikipedia:

  • Visão: ressalta o que uma empresa quer ser, ou como ela quer que o mundo no qual ela opera seja. É uma visão de longo-prazo e se concentra no futuro. Pode ser emotiva e é uma fonte de inspiração.
  • Missão: Define o propósito fundamental de uma organização, sucintamente descrevendo por que ela existe e o que ela faz para atingir sua visão.

É desanimador quando escutamos de empresas que deveriam ser referência em inovação e, consequentemente, em dominar os riscos, que “não é possível te ajudar porque temos uma imagem a zelar”. Para mim, proteger o status-quo em prol de uma “imagem que precisa ser zelada” não é inteligência, muito menos é ter um propósito. É medo. E medo não combina com inovação. Ousadia, sim. Que o diga Steve Jobs.

No futuro, gostaria de contar a meus filhos e netos que ajudei diversos times a atingirem uma maturidade e disciplina tamanha que foi possível gerar produtos maravilhosos e provocar mudanças substanciais na nossa realidade. E não que sou ou fui um coordenador ou gerente de projetos e tinha um monte de coisa chata pra fazer.

E você? Qual o futuro que você quer para o mundo onde você vive? Ou para o mercado onde trabalha? Ou para a sua empresa?
Qual o seu propósito?

Os 10 mandamentos da transição para Agile

Posted in cultura by Rafa Nascimento on 29/11/2012

Neste post, exponho a mentalidade que acredito que deva existir para uma transição para Agile seja bem-sucedida.

  1. Queira e informe-se
    O primeiro passo para a mudança é a vontade de mudar. E, fundamentalmente, a mudança pode acontecer porque a situação atual é ruim ou porque a situação visada é simplesmente mais agradável. De qualquer forma, a mudança só encontrará a vontade de mudar quando a mudança visada toca alguns de nossos valores e impulsionam a emoção necessária para a tomada de decisão e a ação. Ou seja, sem a consciência de que uma mudança é necessária e sem a vontade de passar pela transição, não há perspectiva de sucesso.
    Quando há a vontade de mudar, os próximos passos dizem respeito à informação sobre a mudança pleiteada. Informe-se e, mais importante, compartilhe as informações com as pessoas que querem mudar junto: livros, artigos, comunidades ágeis espalhadas pelo Brasil, conferências e cases de sucesso de líderes da indústria são excelentes fontes de informação. Saiba o que é Agile e, principalmente, o que não é.
  2. Capacite as pessoas
    Um dos equívocos mais comuns no contexto de uma transição para Agile é a falta de capacitação dos profissionais responsáveis ou envolvidos na transição. Mais importante do que simplesmente capacitar as pessoas é gerar nelas o senso de urgência pela capacitação dada a necessidade de uma mudança, de forma que elas mesmas queiram se capacitare não dependam somente as ações da empresa para que isso aconteça. É responsabilidade de toda empresa séria capacitar seus profissionais em busca de bons resultados. Porém, as fontes de capacitação oferecidas pela empresa não são as únicas pertinentes. Além disso, há um ponto importante em Agile: a importância do trabalho coletivo faz com que o perfil comportamental dos profissionais seja tão ou mais importante que o perfil técnico.
    Não buscar garantir que as pessoas estejam preparadas para a mudança de paradigma e querer que a mudança seja bem-sucedida é viver no “mundo de Alice”.
  3. Invista em coaching e gestão de mudança
    Raras são as empresas que tratam uma transição para Agile sequer como um projeto. A grande maioria trata a transição apenas como uma nova forma de desenvolver software. Porém, essa nova forma exige uma mudança de atitude em todos os envolvidos em um projeto ou produto de software. É uma mudança organizacional pesada, que precisa ser efetivada com consistência e precisa ser tratada, no mínimo, com a seriedade que qualquer projeto é tratado.
    Quando falamos em mudança organizacional e transição para Agile, coaches com experiência em ambientes ágeis, transições e mudança organizacional são mais do que necessários para apoiar os responsáveis pela transição, ajudá-los a potencializar os pontos fortes da organização em prol da mudança e a identificar e tratar os impedimentos para a transição em nível organizacional. Coaches, principalmente durante uma transição ágil, que demanda mudança organizacional, não são artigos de luxo. São uma necessidade.
    Tão necessária quanto um coach é a gestão de mudança, para que seja possível gerar senso de urgência nas pessoas envolvidas, realizar uma mudança consistente e de acordo com o contexto e capacidade da empresa, pautando-se em objetivos, como em um projeto.
  4. Assuma a complexidade e a incerteza
    A transição para Agile não é fácil, como já disse em um post anterior. Toda organização é um grande sistema humano complexo e dinâmico, repleto de subsistemas, igualmente complexos e dinâmicos. É importante assumir a existência de tal complexidade e as incertezas que a rodeiam e buscar métodos que ajudem a gerir e buscar os resultados perante essa complexidade, como o Management 3.0 ou Systems Thinking. Seja humilde e busque soluções originais para novos problemas.
  5. Não mecanize-se
    Sistemas complexos, como organizações, performam melhor regidos por princípios. Times são sistemas complexos. E Agile tem como um de seus fundamentos o trabalho coletivo de times auto-organizáveis. Só essas 3 frases deveriam ser suficientes para evitar a simples adoção de práticas sem o conhecimento dos princípios que as baseiam. Agile é um paradigma, não uma metodologia. É uma nova forma de pensar e agir, não um simples conjunto de práticas. Quando adotamos práticas ignorando os princípios que as fundamentam, corremos o risco de prejudicar a performance de nossos times, porque passamos a exigir uma boa execução das práticas engessadas e mecanizadas. Princípios servem para flexibilizar e impulsionar a performance dos nosso times, mantendo-nos focados nos resultados que queremos atingir e nos problemas que precisamos resolver.
  6. Seja o exemplo da mudança
    Acredite na mudança e seja você mesmo o exemplo para a mesma. Em tempos de gestão moderna, onde coaching e liderança servidor estão cada vez mais presente como fortes skills de gestores, simplesmente demandar a transição para Agile não é o suficiente. Para criar o senso de urgência necessário, é preciso que os líderes da empresa acreditem fortemente na mudança que estão liderando. Parece óbvio? É cada vez mais comum ver a transição para Agile ser tratada como uma demanda para a área de TI ou, quando não é demandada, ser constantemente posta à prova.
    Se você mesmo não acredita que a transição para Agile pode melhorar os processos organzacionais e os resultados, nem comece.
    Os maiores líderes que já existiram, como Hitler, Gandhi, Henry Ford, Steve Jobs e Bill Gates acreditavam piamente em seus paradigmas, mesmo que não fossem lá tão éticos.
  7. Transforme problemas em oportunidades
    Toda empresa tem problemas. São esses problemas que devem ser os motivadores para a adoção de métodos ágeis e, por consequência, de uma mudança de paradigma. Quando uma transição é pautada pela simples vontade de ter os métodos ágeis presentes na empresa, as chances de falha são enormes.
    Além disso, todos nós somos contratados para desempenhar determinados papeis. A adoção de práticas ágeis deve ser provenientes de um novo modelo mental que nos faz pensar em novas formas de resolver problemas do nosso dia-a-dia através de novos princípios. Para chegar ao ponto de uma transição para Agile, justifique-a. Faça o seu trabalho do dia-a-dia e resolva seus próprios problemas baseando-se em novos paradigmas nos quais você acredita. Mas não mantenha as melhorias lozalizadas em 1 ou 2 times. A maioria dos problemas que chegam aos times são partes de problemas organizacionais, maiores. Tenha sempre em mente a otimização global, que influenciará na tomada de decisão por uma transição.
  8. Desburocratize a comunicação
    Agile nada mais é do que desburocratizar processos e eliminar gaps de comunicação. Justamente o contrário do que existe em grandes e médias empresas, principalmente naquelas que têm seus processos regidos pelo CMMI. Em vez de primar pela excelente execução das práticas do Scrum ou do Kanban, procure observar como andam os níveis e burocracia e comunicação olho-no-olho na sua organização, não só dentro dos times de desenvolvimento de software. Utilize-se dos princípios de transparência, visualização, inspeção e adaptação, por exemplo, para liderar uma transição. E não deixe de ter uma visão muito bem comunicada, simples e disposta onde todos possam ver todos os dias.
  9. Meça
    Como disse em um post anterior, sem histórico não há melhoria. Todas as mudanças organizacionais em termos econômicos e administrativos são pautadas em mudanças comportamentais da empresa indicadas em gráficos de dados colhidos frequente e consistentemente. Para que as mudanças derivadas de uma transição para Agile sejam assertivas e efetivas, é necessário medir a produtividade dos times, para que os pontos de melhoria sejam revelados e as ações de melhoria provenientes da adoção de um novo paradigma sejam bem-sucedidas.
    Grande parte das transições para Agile são dogmáticas e não-contextuais, o que não funciona.
  10. Mostre competência
    Um dos pontos fundamentais para a geração de confiança é a competência. Nada melhor do que resultados para atestar a competência. Uma transição para Agile só começa a ganhar força, e os responsáveis pela mesma começam a ganhar a confiança da organização em prol da mudança, quando resultados positivos aparecem, e não quando teorias são bem defendidas. E como estamos falando de contextos distintos entre empresas e incretezas mil, a única fórmula mágica que existe para o sucesso é: inspeção e adaptação.
Tagged with: , , ,
Seguir

Obtenha todo post novo entregue na sua caixa de entrada.

%d blogueiros gostam disto: