Gestão 2.0

Sem Relatório de Horas vs. Utopia

por Fabio Akita

A- A+

Tweet Comente!

Pesquisando sobre relatórios de horas e o sistema de horas bilhetáveis e taxas-hora, cheguei ao site da VeraSage. Não tenho idéia de quem são, mas seus argumentos e linha de pensamento são idênticas às minhas. Mais, eles complementaram tudo que me afligia há anos sobre o assunto. Resolvi traduzir dois de seus artigos (há mais em seu site). O primeiro “traduzi no artigo anterior” e aqui traduzo o segundo, entitulado “No Timesheets vs. Utopia”, de 02/09/2007, por Ron Baker, que começa abaixo.

Imagine que sua casa está pegando fogo. Você conseguiu tirar sua família de lá a tempo, até conseguiu pegar algumas fotos preciosas pelo caminho. Agora sua unidade familiar abalada está de pé no meio da rua observando o Sonho Americano ir embora em brasas.

Os bombeiros chegam, eles pegam todas as mangueiras e tão logo estão se preparando para apagar o inferno, você corre até o líder dos bombeiros e grita: “ESPEREM! ESPEREM! COM O QUE VOCÊS VÃO SUBSTITUIR ISSO?”

Horas Bilhetáveis é o Ópio das Profissões

por Fabio Akita

A- A+

Tweet 4 Comentários

Pesquisando sobre relatórios de horas e o sistema de horas bilhetáveis e taxas-hora, cheguei ao site da VeraSage. Não tenho idéia de quem são, mas seus argumentos e linha de pensamento são idênticas às minhas. Mais, eles complementaram tudo que me afligia há anos sobre o assunto. Resolvi traduzir dois de seus artigos (há mais em seu site). O primeiro é o texto “Hourly Billing is the Opium of the Profession”, de 30/03/2006, por Ronald J. Baker, Founder VeraSage Institute, que começa abaixo.

Nós chegamos, portanto, a esta conclusão. Um commodity tem um valor, porque é a cristalização do trabalho social. A grandeza de seu valor, ou seu valor relativo, depende da quantidade maior ou menor dessa substância social contida nela; isso quer dizer, na massa relativa de trabalho necessário para sua produção. Os valores relativos de commodities são, portanto, determinados pelas quantidades respectivas ou porções de trabalho, implementadas, realizadas, fixadas nelas. As quantidades correlativas dos commodities que podem ser produziadas no mesmo tempo de trabalho são iguais. Ou o valor de um commodity é para o valor de outra commodity assim como a quantidade de trabalho fixo no primeiro é para a quantidade de trabalho fixo no outro.
- Karl Marx, Valor, Preço e Lucro, 1865

Trabalhadores do mundo … me perdoem.
Karl Marx
–Graffiti num estatuto, Moscow 1991

O único lugar onde o Marxismo não foi desacreditado – fora das universidades americanas – são as empresas profissionais de serviço.
–Ronald J. Baker

A Língua Portuguesa-Brasileira é Péssima: Standard vs Pattern

por Fabio Akita

A- A+

Tweet 9 Comentários

Meu último artigo de tradução sobre “Padrões: Excelência vs. Mediocridade” gerou uma discussão separada interessante especificamente sobre “Design Patterns”.

Para quem não é de programação, nos anos 70 (e foi reforçado nos anos 90 pelo “livro do Gang of Four”) surgiu um termo chamado “Design Pattern” que, segundo a Wikipedia, em engenharia de software, um “design pattern” é uma solução reusável geral para um problema que ocorre comumente em design de software. Um design pattern não é um design fechado e acabado que pode ser transformado diretamente em código. É uma descrição ou template para como resolver um problema que pode ser usado em muitas situações diferentes.

Para nós, no Brasil, existe um *enorme* problema que só me caiu a ficha por causa da discussão nos comentários do meu artigo que mencionei acima. A reclamação foi que traduzi “Design Patterns Standards” como “Padrões de Design”. O Ronald, que fez a reclamação, levantou o ponto correto, as palavras em inglês: “default”, “standard” e “pattern” todas traduzem para a mesma palavra “padrão” em português.

Padrões: excelência vs. mediocridade

por Fabio Akita

A- A+

Tweet 6 Comentários

O texto a seguir é uma tradução do excelente artigo Standards: excellence vs mediocrity, escrito por Jason Yip, consultor da Thoughtworks, que tive o prazer de conhecer pessoalmente ano passado.

Antes de iniciar o texto traduzido, uma pequena introdução: todos sabemos como muitos conceitos que temos como fundação no mundo ocidental podem ser radicalmente diferentes no mundo oriental. Um desses conceitos difíceis de transpor do mundo oriental para o ocidental é justamente o de “padrões”. No mundo ocidental “padrão” é um denominador comum, estático, rígido, difícil de mudar, o status quo. No mundo oriental, a idéia de “padrão” é “o melhor”. Se amanhã aparece outro “melhor”, este deve ser considerado o novo padrão. Não é algo inatingível, que admiramos de baixo para cima sabendo que dificilmente vamos alcançar, como um “recorde”.

Imagine um mundo onde o “recorde” é o “padrão”. Eu falei sobre isso em outro artigo chamado Padrões, Commodities e Inovação, recomendo ler. Agora sim, segue a tradução do artigo do Jason:

Então você é um terceiro? Quem é você?

por Fabio Akita

A- A+

Tweet 6 Comentários

Quem leu meu artigo de alguns dias atrás “Então você quer terceirizar um projeto? Quem é você?” pode imaginar que a culpa dos projetos terceirizados darem errado é somente de quem pede, do cliente. De jeito nenhum. Parte está lá sem dúvida, mas boa parte está fora, em quem atende, os terceiros, as “consultorias”.

Tudo começa quando você recebe uma Requisição de Proposta (RFP) e agora precisa entender o problema, rascunhar uma solução, descrevê-la numa proposta, precificar e enviar de volta ao requerente.

Se é ruim quando uma RFP vem apenas como “quero um site”, tanto pior é uma proposta que retorna com “eu faço sites, custará $X”. Do ponto de vista do departamento de compras, quando eles recebem uma proposta de volta obviamente concluem que quem está mandando a proposta está automaticamente afirmando que “sabe fazer”, e para ele basta observar quanto cada um vai cobrar. Basta que o responsável técnico avalie as propostas e se ele disser que todos atendem a solicitação, vence o menor preço.

Então você quer terceirizar um projeto? Quem é você?

por Fabio Akita

A- A+

Tweet 3 Comentários

Apesar de ter trabalhado em produtos e projetos internos como funcionário de empresas, a maior parte da minha carreira sempre foi como freelancer ou consultor. Em outro artigo vou explicar porque gosto muito mais de consultorias do que ser funcionário.

De qualquer forma uma coisa que sempre vai existir é a terceirização. Existem dezenas de motivos para isso. Vamos entender neste artigo como é a figura do gerente de projetos da empresa que quer terceirizar serviços para consultorias, agências ou outros.

A grande maioria das empresas e gerentes peca estupidamente na hora de terceirizar. Depois de anos atendendo todo tipo de indústria, dá para contar nos dedos a quantidade de vezes que recebi uma requisição de proposta (RFP) realmente decente.

O problema: você que é gerente de projetos da empresa não é o dono do dinheiro e não é quem será beneficiado pelo produto desenvolvido pelo terceiro. Economicamente falando, você é a pessoa que tem o menor interesse no projeto e mesmo assim é o principal responsável em fazer com que ele aconteça. Não estou dizendo que todos agem conscientemente dessa forma, mas sim que inconscientemente é onde a situação naturalmente os leva.

Processos e Metodologias não vão te Ajudar

por Fabio Akita

A- A+

Tweet 24 Comentários

Depois de tanto tempo falando de metodologias, processos, procedimentos, existe uma coisa que já deveria ser óbvia mas que a maioria das empresas ignora: metodologias nunca vão substituir bons profissionais.

Se eu disser isso a qualquer um, todos vão dizer: “mas isso é óbvio”. E minha vontade é retrucar: “então porque diabos você está tentando implantar essa metodologia?”

Antes de mais nada, vamos a algumas definições:

• Metodologia: um sistema de métodos usados em uma área particular de estudo ou atividade.
• Processos: uma série de ações ou passos tomados para atingir um determinado objetivo.
• Procedimento: uma maneira estabelecida ou oficial de se fazer alguma coisa.

Fim das Férias :-)

por Fabio Akita

A- A+

Tweet Comente!

Passei bastante tempo longe deste blog. Peço desculpas aos leitores que pacientemente estiveram esperando por mais conteúdo.

Alguns deve saber, no ano passado ingressei na consultoria Gonow Tecnologia, uma empresa nova e dinâmica, pouco conhecida – na época – no mercado brasileiro, mas que há 4 anos atua exportando software para o Chile.

Meu desafio era criar uma área de desenvolvimento de aplicações Web de qualidade utilizando as tecnologias que formam o ecossistema Ruby on Rails. Partimos de 4 funcionários e hoje já temos mais de 15 pessoas nessa equipe entregando software de qualidade.

Por causa disso meu volume de trabalhou aumentou “consideravelmente” mais do que eu esperava e meu tempo para blogar diminuiu para perto de zero. À medida que eu mesmo consigo organizar melhor meu tempo pretendo retornar com mais frequência a este blog.

Obrigado a todos pela paciência e espero que continuem acompanhando!

Desmistificando o método Kanban

por Fabio Akita

A- A+

Tweet 3 Comentários

Se você acompanha as discussões sobre metodologias de gerenciamento de projetos de software Ágeis, já deve ter ouvido falar sobre o hype a respeito de Kanban. Eu já conversei com algumas pessoas da área explicando que eu não discordo do conceito em si, mas que acho confuso chamá-lo de “Kanban”.

Para os que não entenderam, Kanban é uma técnica derivada do processo “Lean” que é uma generalização do Sistema Toyota de Produção, o famoso processo industrial criado pela Toyota décadas atrás e que ajudou a revolucionar a Toyota. Criar hype sobre a técnica Kanban não é novidade e a área de Engenharia de Produção já passou por isso antes.

Um dos problemas de se usar o nome “Kanban” é que ela se associa com “Lean” e isso leva a toda uma discussão sobre Agile-Lean que eu particularmente desgosto, especialmente porque o Kanban aplicado a software não tem muito a ver com o Kanban de produção e, portanto, também não tem a ver com Lean.

Para realmente entender o Sistema Toyota de Produção é importante ir às raízes, estudar sobre Taiichi Ohno, W. Edward Deming. Também recomendo a leitura do livro “O Sistema Toyota de Produção do Ponto de Vista da Engenharia de Produção“, escrita por Shigeo Shingo, que atuou como consultor externo e ensinou cursos de engenharia industrial desde 1955. Desse livro, quero parafrasear um trecho do Prefácio da Edição Japonesa:

O que significa ser um Gerente?

por Fabio Akita

A- A+

Tweet 3 Comentários

Por incrível que possa parecer, não existe uma boa definição, simples, clara e curta que pode definir o que é ser um “gerente”. Gerente não é uma profissão. Você não pode “aprender” a ser um gerente numa escola ou curso. A única forma de aprender é tentando, errando, melhorando, continuamente e indefinidamente.

Uma das melhores definições que encontrei é de ninguém menos que o professor Henry Mintzberg, em seu recente livro “Managing”, publicado em 2009. Uma leitura madura e leve.

Recomendo a leitura desse livro. Se você é um gerente iniciante ou quer ser um gerente, talvez este livro lhe dê alguma visão do que vai enfrentar à frente. Se você já é um gerente, vai ficar surpreso pois muitos livros teóricos pintam cenários que você nunca viu na prática – fazendo-o se questionar se você está fazendo a coisa certa ou não – e este livro talvez defina melhor os problemas reais que você enfrenta.

Quero trazer alguns trechos da primeira metade do livro.

Gerenciamento Não é uma Profissão

Depois de anos procurando por Santos Graal, é hora de reconhecer que gerenciar não é nem ciência nem profissão; é uma prática, aprendida primariamente através de experiência, e enraizada em contexto.

Certamente não é uma Ciência. Ciência tem a ver com o desenvolvimento de conhecimento sistemático através de pesquisa. Isso nem de longe é o propósito de gerenciamento, que tem a ver com ajudar a conseguir realizar coisas em organizações. Gerenciamento não é nem mesmo uma ciência aplicada, porque isso ainda é ciência. Gerenciamento certamente aplica ciência: gerentes precisam usar todo o conhecimento que conseguir. E eles certamente usam análise, enraizada no método científico (que significa aqui mais prova científica do que descoberta científica).

Mas gerenciamento efetivo é mais dependente na arte e é especialmente enraizada em ofício. Arte produz o “insight” e “visão”, baseado em intuição (Peter Druker escreveu em 1954 que “os dias do gerente ‘intuitivo’ estão contados”. Meio século depois, ainda estamos contando.) E ofício tem a ver com aprendizado a partir de experiência – trabalhando nas coisas à medida que o gerente avança.

Portanto, vale repetir o que Mintzberg costuma dizer: é impossível formar gerentes na escola. Não é um “talvez”, é uma certeza. Na escola você pode aprender técnicas de contabilidade, de marketing, conhecimento técnico repetitível. Nada disso gera um gerente e muito menos um líder. Se uma escola, um curso de MBA diz “Formamos Líderes”, isso é mentira. Essas escolas formam técnicos; técnicos que vão trabalhar em atividades técnicas até crescerem para começar a acumular responsabilidades e, talvez, um dia conseguirem realmente gerenciar alguma coisa.