claudiobr

Minha história em São Paulo contada na Revista Bicicleta (na íntegra aqui)

Sun, 03 Feb 2013 07:19:00 -0800

No final do ano passado a Revista Bicicleta me convidou a contar a minha história com as magrelas em São Paulo para uma seção da publicação. Eu fiquei muito feliz com a oportunidade de deixar um registro do que aconteceu nesses últimos três anos muito especiais.

Segue abaixo a transcrição da matéria e no final, as fotos das páginas da revista. Aliás, a revista é muito bem feita e traz muitas informações para quem ama as bicis.

Passar um mês inteiro trabalhando em São Paulo? Bem, isso pareceu meio estranho quando propuseram, principalmente porque São Paulo para mim lembrava “dinheiro”, “violência”, “trânsito”, “alagamentos” e “caos social” (os quatro últimos graças ao Datena). A essência do preconceito.

Durante 10 anos São Paulo se limitava a viagens a trabalho inevitáveis o mais curtas possível, muitas delas de bate-volta, contudo, após quatorze anos em Florianópolis eu havia passado por algumas mudanças radicais como o fim do casamento e ter largado um bom emprego para abrir a minha empresa, então, por que não? Aceitei.

Desci no aeroporto de Congonhas, porta de entrada das minhas visitas anteriores e segui a tradição: depois de uma bela fila embarquei em um táxi e fui para a empresa que fica na Faria Lima com a Rebouças. Eu só conhecia essas ruas por causa do Banco Imobiliário jogado na infância. Trabalhei o dia todo e precisava ir para o hotel onde passaria o próximo mês. Estava com a mala. Bora pegar um táxi.

Ao sair o mundo havia se transformado ao redor da empresa. Cheguei no meio da manhã, agora era horário de pico e estava tudo parado ou se arrastando. Achei um taxi e embarquei. O hotel também ficava em uma rua do Banco Imobiliário, a Nove de Julho e a apenas quatro quilômetros do trabalho. Bem, contei no relógio: de porta a porta foram 44 minutos e 40 reais. quase um real por minuto de desfrute.

Assim seria difícil. Eu não tinha fundos para gastar 40 reais/minutos para ir e 40 reais/minutos para voltar. Belo empresário! Os ônibus, minha feliz opção em Florianópolis desde 2003, pouco ajudavam. Eu precisava de uma alternativa, então, na manhã do segundo dia em São Paulo eu saí cedinho e resolvi caminhar.

Uau. Cheguei em 40 minutos! Sem pressa, sem gastar e passeando por belas ruas daquela região. Parece que os 6 Km/h do ser humano médio eram equivalentes à velocidade do carro médio naquela região, mas eu não fiquei satisfeito. Faltava alguma coisa. Foi quando me veio à cabeça algo surpreendente que havia visto na última viagem para São Paulo: uma bicicleta dobrável. Estava em um carro na Faria Lima (agora eu sei que era lá) quando fomos ultrapassados por um sujeito em uma daquelas bicicletas excêntricas de aro 20’’.

Procurei na Internet, encontrei uma autorizada e o modelo de entrada, a ECO 1: branquinha, sem marchas. R$ 750,00. Liguei, imprimi a rota de volta e na hora do almoço me fui de táxi para a Av. Sumaré. A Corrida, minha última foi de 7 Km e custou R$ 26,00. Fechei a porta pensando: “todo dia não táxi! Te vejo uma hora dessas”.

O teste seria: se eu fizer os 7 Km de subida entre a loja e o trabalho eu faria os quatro de ia mais os quatro de volta brincando. Entrei na loja onde entraria muitas vezes no futuro (dei uma dobrável para cada pessoa de casa em Florianópolis), fui super bem atendido e saí de lá com a bicicleta, rapidamente apelidada de “Tetéia”, capacete e luzes.

E agora? Tinha que voltar. Eu tinha 32 anos, estava bem sedentário, mas não estava morto! Cheguei numa boa no trabalho e rapidinho. Naquele dia eu não tinha os conhecimentos de comportamento no trânsito que tenho hoje, mas saber dirigir carros me ajudou no mais importante na segurança do ciclista nas ruas: ser previsível.

Duas da tarde eu estava entrando triunfante no escritório com a Tetéia dobradinha que ficou ali, dia após dia, esperando ao lado da minha mesa a hora de ir para casa.

A Tetéia teve um efeito enorme na minha rotina e no meu jeito de perceber São Paulo. Eu ansiava por acordar e fazer meu trajeto até o trabalho. Ao chegar, lamentava ele ser tão rápido e trabalhava esperando a hora de fazer o rolê de volta.

Já conhecia um monte de gente que havia perguntado sobre a bicicleta estranha e era conhecido como o cara da bicicleta estranha. No dialeto local a expressão era “da hora essa bike mano!”.

Meu hotel era daqueles de baixo custo, tudo certinho, limpinho, eficiente e... estéril. Foi o mais perto que cheguei de viver em uma estação espacial, então dá para imaginar a depressão que seria passar os finais de semana ali sozinho, sem conhecer ninguém, então eu saía cedinho com a Tetéia e só voltava à noite.

Eu explorava a zona sul de São Paulo sem GPS e sem conhecimento prévio, só parando para perguntar para que lado era o quê: Avenita Paulista, parque do Ibirapuera e arredores, ciclovia da Marginal Pinheiros e por aí vai.

“Me apropriei de São Paulo” como alguns amigos paulistanos dizem e aquela cidade “horrível” não era tão horrível assim, ela apenas ficava feia quando olhávamos por trás dos vidros de uma cápsula de lata cercada de cápsulas de lata emitindo fumaça.

No primeiro momento eu pensava que eu via São Paulo assim porque estava em uma área nobre da cidade, contudo, conforme fui conhecendo (sempre pedalando) outras regiões notei a verdade universal de que todos os lugares ficam mais bonitos quando você tem acesso direto a eles, quando passa devagar e se permite se misturar.

Notei que você não precisa ser um catarinense distante impressionado com o que a TV no fim de tarde fala sobre São Paulo para desenvolver preconceito com a cidade, você pode ser simplesmente um paulistano, nascido aqui mesmo, que só usa carro para se locomover. No carro não se vê pessoas, ruas, árvores, casas. Você vê pistas, outros carros e obstáculos.

Amei aquilo tudo e, juro, por acaso, encontrei uma vaga de trabalho muito legal em São Paulo ainda na terceira semana na cidade. Qual era a pergunta mesmo? Ahh, por que não? Terminei o trabalho daquele mês, dei dez dias em Florianópolis me preparando, procurando onde ficar perto do novo trabalho, lá no sul da cidade, próximo a Santo Amaro (é, claro que não ia morar em bairro de Banco Imobiliário!).

Cheguei para trabalhar sem ter certo onde ficar. Fui para um hotel “estação espacial” por cinco dias, mas na Internet encontrei um cara sensacional, baixista acústico vindo do interior de São Paulo morando a 6 Km do meu trabalho. Era uma casa, não um apartamento e esse cara gostava de viver uma vida simples. Aprendi muito com ele e ele comigo durante dois ótimos anos.

Desde os primeiros passeios pela cidade fui conhecendo pessoas ligadas a bicicletas, conheci a bicicletada nacional (passeio enorme realizado todas as últimas sextas-feiras do mês) e vários grupos. Rapidinho conhecia mais gente legal em São Paulo do que na minha terra natal.

Ao longo do tempo mudei de emprego, de trajeto e de bicicletas. Conforme trocava de bicicleta ia levando a anterior para Florianópolis para incentivar meus pais a voltar a pedalar. Eles voltaram e hoje pedalam muito.

Foram-se a Tetéia, a Tetéia II (com sete marchas) e depois a Aretha (com seis marchas) chegando por fim ao Jipinho, uma dobrável com oito marchas e suspensão nas duas rodas, uma máquina com a qual eu rodei nada menos que seis mil quilômetros em um ano entre os 30 Km de ida e volta para o trabalho na Av. Paulista e as descidas para Santos (fantástica viagem que não canso de fazer). Isso tudo sem acidentes e sem assaltos. Não pode ser simplesmente sorte.

Quando tenho algum trabalho em outra cidade costumo levar uma dobrável comigo, seja no ônibus, seja no avião, assim, além de manter o hábito acabo conhecendo melhor cada cidade, seja o Rio de Janeiro, seja Bauru. Desembarcar em outra cidade, desdobrar a bicicleta e sair dali mesmo pedalando rumo ao hotel ou ao evento traz uma sensação de autonomia sensacional. Desdobrar a bicicleta após retirar da esteira de bagagens de Congonhas e sair pedalando enquanto todos aguardam naquela fila enorme para os taxis também. Em dia de chuva então, nem se fala.

Ano passado eu comecei a sentir uma dor insistente no quadril que logo notei estar vinculada às pedaladas. Eu levei um tempo para descobrir o que era e qual a gravidade, o que me deixou bastante preocupado. Foi nesse período de dois meses que arranjei uma bicicleta com motor elétrico (também dobrável) e passei a usá-la para ir e voltar do trabalho.

Esse período serviu para eu separar bem os componentes da bicicleta na minha cabeça. A bicicleta com motor resolvia o meu problema logístico, contudo, todos os demais benefícios da bicicleta, aqueles vindos do vínculo entre o esforço físico e o movimento, a autonomia, a construção das pernas (perna se constrói, não se compra), as recompensas químicas no cérebro estavam fora do meu alcance.

Por um bom tempo eu sentia uma espécie de vergonha por não estar pedalando, fiquei retraído e não cumprimentava os ciclistas por quem passava. Isso foi um exagero, claro, eu estava usando um meio, apesar de haver problemas com a regulamentação em São Paulo, legítimo para resolver meu problema. Mesmo assim, recomendo o uso de bicicletas com motor somente quando não há alternativa uma vez que o que se perde quando se apela para um motor é justamente o vínculo com o mundo real.

Com motor nosso estado de espírito rapidamente se volta para a pressa de quem não sente a relação entre o seu esforço e o movimento. Do nada me vi apressado e irritado. Abandonei a bicicleta com motor de vez no exato dia em que me recuperei como se elas fossem as muletas usadas enquanto a perna quebrada sarava.

Engraçado como a cidade grande e a “vida adulta” levam você a esquecer as coisas óbvias que amava. Meu amigo músico chegou a competir com patrocínio em provas de downhill, mas a sua bicicleta estava parada havia oito anos. Ele se empolgou tanto que adotou novamente a magrela esquecida, comprou uma speed e logo estava fazendo trajetos maiores que o meu para dar aula nas casas dos seus alunos.

Trabalhei muito desde que cheguei em São Paulo, muitos projetos para grandes empresas daquelas que anunciam na TV, contudo, o que aquece meu coração mesmo é pensar nas dez, doze pessoas que influenciei diretamente com o exemplo (e um pouco de militância ciloativista) e que hoje fazem da bicicleta o seu meio de transporte principal.

Uma dessas pessoas acabou virando meu amor, minha companheira e nossa história foi se desenrolando ao redor das bicicletas. Ela, paulistana que conheci em um dos clientes que atendi como consultor, gostou da ideia, comprou a Tetéia III de mim (hoje se chama Alcides).

Foi ela quem encontrou nossas bicicletas “grandes” maravilhosas: o Guacamole e a Laurinda em uma loja de Criciúma por um preço ótimo e que volta e meia viaja de carona sentadinha sobre o quadro com as pernas cruzadas, como ontem quando fomos ao cinema.

Moramos no centro da cidade onde fazemos tudo a pé ou de bicicleta e ela me ensina sobre a história da cidade, rua por rua, prédio por prédio. Hoje, domingo, fomos pedalando coletar mudas de plantas frutíferas nos canteiros das ruas da Vila Mariana para plantar na hortinha de casa.

Eu amo São Paulo. Eu amo você...

Páginas:

Permalink | Leave a comment »

Até onde vamos para não alterar o escopo

Thu, 10 Jan 2013 09:51:00 -0800

Essa semana um prédio público construído em Ponta Grossa no Paraná chamou a atenção da mídia por possuir algumas features digamos, peculiares.

O edifício possui quase todas as paredes de vidro, o que, aliás, ficou muito bonito, contudo, essas paredes também foram usadas nos sanitários. No piso térreo é possível observar nitidamente o uso do banheiro que possui, inclusive, um chuveiro.

José Aldinan/Gazeta do Povo

Outra peculiaridade foram as saídas de emergência que constituem em portas que dão para o vazio, ou seja, a opção é pular para fora do prédio do segundo e terceiro pavimentos e torcer que o chão seja mais agradável do que o fogo.

O projeto do prédio contava com banheiros transparentes e é claro que os responsáveis pela construção questionaram a prefeitura a respeito. A resposta foi que o projeto não poderia ser alterado e que tudo deveria ser feito à risca.

Em entrevista por telefone à Gazeta do Povo, o proprietário da empresa, engenheiro Carlos Nakazima, afirmou que a construtora seguiu o projeto à risca e que não constavam do memorial descritivo sugestões para impedir a transparência dos banheiros e nem o projeto da escada. “Não posso alterar um projeto arquitetônico sem a autorização de quem o criou. Nós identificamos o problema, estávamos cientes e avisamos a Prefeitura antes da inauguração. A empresa está aberta a questionamentos”, salienta.http://www.gazetadopovo.com.br/vidaecidadania/conteudo.phtml?tl=1&id=1333844&tit=Banheiros-transparentes-causam-estranheza-em-obra-publica-de-Ponta-Grossa

Uma resposta tradicional para esse problema seria dizer que é necessário investir no gerenciamento de projetos, que alguém deveria ser responsabilizado por isso (centralizar tudo) e que a passagem de bastão entre as fases deveria ser melhor observada.

Aí está o perigo, pois investir mais nisso estressaria o vetor errado e não trataria as causas dos problemas que envolvem a distância entre: quem vai usar de fato, quem vai pagar, quem vai desenhar e quem vai desenvolver; a falta de ciclos de feedback e a ideia de que um projeto só anda em uma direção: para frente.

Como um projeto faseado só anda para a frente, não havia um ambiente que amparasse esse tipo de questionamento, afinal, as fases anteriores estavam marcadas como “completas”.

A resposta dada pela prefeitura aos questionamentos do engenheiro são uma boa evidência disso.

Nesse contexto, mesmo que você descubra algo absurdo sendo feito será visto não como alguém que está auxiliando, mas como alguém que está atrapalhando, possivelmente atrasando o trabalho do vai vai cavalinho.

Nos sentimos compelidos a nos agarrar ao desenho inicial. Nesse caso chegou ao ponto de virarem motivo de piada.

As pessoas dizem que todos os projetos são, em algum momento ágeis. Os que não começam ágeis terminam ágeis, pois depois que o problema gigante aparece há duas saídas: cancelar ou aumentar a colaboração entre as partes e focar no que traz valor.

Agora que caiu na boca do povo eles vão correr para a segunda opção, já que não dá para deletar o prédio.

Quem pagou o pato foi o diretor do conservatório de música que utilizará o prédio, que aparentemente, nunca foi consultado a respeito do projeto, apesar de ser o principal interessado. Espero que esse vidro tenha boas propriedades acústicas.

Uma obra civil feita para o governo possui uma série de restrições que nos incentivam a correr para o escopo fechado, para o faseamento e a falta de ciclos de feedback. Não acho que sirva de desculpa, mas tudo bem, larguei a engenharia civil no quarto semestre e não é nem de longe o meu campo de atuação, contudo, com que cara ficamos quando o produto é software desenvolvido para a iniciativa privada? O que justifica que tenhamos os mesmos problemas que ocorreram nessa obra?

As restrições estão mais nas nossas mentes do que no mundo real.

Diz aí, você já entregou algum banheiro transparente por não poder alterar o escopo?

A piadinha infame é que, pelo menos nesse projeto, não dá para dizer que faltou transparência.

Veja a matéria aqui e tire as suas conclusões: http://globotv.globo.com/rede-globo/jornal-hoje/v/predio-publico-no-parana-tem-todas-as-paredes-de-vidro-ate-as-do-banheiro/2333126/

Curiosidade sobre edifícios de vidro

http://www.historytoday.com/rowena-hammal/never-surrender-british-civilian-mo..." width="300" style="height: auto; display: block; margin: 0px auto; border: 1px solid #eeeeee; padding: 6px;" />
Foto: http://www.historytoday.com/rowena-hammal/never-surrender-british-civilian-mo...

Ao longo da segunda guerra mundial Londres sofreu muitos bombardeios, o que acabava com as janelas e portas de vidro de casas e edifícios.

Ao longo da guerra os Londrinos se especializaram em produzir vidro bom, mais barato e em maior quantidade que era imediatamente utilizado.

Com o fim da guerra e dos bombardeios começou a sobrar muito vidro. Os construtores aproveitaram aquele vidro todo e passaram a fazer belíssimos edifícios com paredes inteiras de vidro que, por deixar a luz e o escasso sol de Londres entrar, eram excelentes para aquela cidade.

Como nós focamos na estética, passamos a construir edifícios de vidro, inclusive em cidades como o Rio de Janeiro e cidades da região nordeste.

Acontece que o Brasil tem a maior incidência de sol do mundo, temperaturas médias altas, então colocaram cortinas e, consequentemente, refrigeração, mas muita refrigeração.

O cúmulo da ineficiência.

Isso lembra o hábito de usar terno preto e gravata em um país tropical, também copiado da Inglaterra/França.

Permalink | Leave a comment »

Aprendendo muito com a classificação brasileira de ocupações

Wed, 05 Dec 2012 11:59:00 -0800

Mês passado recebi um convite para participar no dia primeiro de dezembro como analista de negócios de um trabalho realizado pela FIPE para o Ministério do Trabalho referente à CBO, a Classificação Brasileira de Ocupações. O trabalho tomou um sábado inteiro e, apesar de estar com muita vontade de usar meu tempo com outra coisa algo me dizia que valeria a pena e valeu.

O objetivo do trabalho era em uma sessão que levaria o dia todo com alguns intervalos definir quais eram os deveres e as tarefas que definiam quatro ocupações representadas por profissionais presentes.

A Classificação serve para o reconhecimento pelo Ministério do Trabalho da existência das ocupações. Esse reconhecimento é usado para guiar programas de governo, sensos, pesquisas e outras ações. A Organização Internacional do Trabalho mantém uma classificação, mas é claro que ela não abrange todas as ocupações de todos os países.

Quando falamos em abrangência estamos falando de todas mesmo. O trabalho de classificação atual envolve aproximadamente duas mil sessões com sete mil profissionais. Eu confesso que fiquei muito interessado por esse trabalho. Imagine um analista de negócios poder conhecer profissionais de todas as ocupações existentes, entender seus objetivos e o que fazem para atingi-los? É um conhecimento muito rico.

Você deve estar se perguntando se profissionais do sexo estão nessa lista e a resposta é sim. Outra ocupação interessante é a de catador de papel. Segundo a facilitadora, metade dos participantes da sessão naquele dia eram analfabetos e mesmo assim ela foi muita produtiva, trazendo ao conhecimento da classificação tarefas as quais elas nem faziam ideia.

Na última classificação a Análise de Negócios estava agrupada junto com ocupações voltadas para a publicidade, o que era muito estranho, uma vez que os objetivos são muito distintos, então, dessa vez ela foi mudada de agrupamento.

A priori o novo agrupamento me pareceu apenas “menos pior” do que o anterior, pois envolvia na primeira metade ocupações prioritariamente voltadas para vendas. O primeiro pensamento que me veio à mente foi “nossa, como é que essas pessoas sabem onde enquadrar cada ocupação?” e o segundo foi “nossa, estamos ferrados, pois não vamos poder mudar isso”.

Acontece que as pessoas responsáveis sabem como agrupar. Ocorre que no mesmo grupo estavam ocupações que, como viemos a descobrir ao longo do dia, tem muito a ver com análise de negócios: Relações Públicas, Ouvidor e Analista de Mercado.

Apesar dos agrupamentos, cada ocupação tem a sua definição própria. É comum as ocupações compartilharem tarefas entre si, contudo, há tarefas exclusivas e a combinação das tarefas e os diferentes objetivos que elas atendem é que definem uma ocupação.

O método utilizado para o trabalho se chama DACUM, um acrônimo para “Developing a Curriculum”, ou “Desenvolvendo um Currículo”. O método consiste em um processo de storyboarding que fornece uma representação visual do que o trabalhador faz em termos de deveres, tarefas, conhecimentos, habilidades, tratos e em alguns casos ferramentas.

Hum... peraí... “story”... “tarefas”... “representação visual”...

Não foi à toa eu me sentir confortável com o que eu vi na parede. Esse método é a cara do story mapping.

Na primeira coluna são colocados objetivos principais. No caso de um professor, o grande objetivo principal seria “ensinar”. Nas colunas seguintes são colocados papéis representando as tarefas que o profissional executa para atingir esse objetivo.

A forma com a qual as facilitadoras trabalhavam o vocabulário para que conseguíssemos pensar no que deveria ir parar na parede também era muito similar à facilitação de uma story mapping.

Lembro da facilitadora separando claramente o que era um objetivo do que era uma tarefa perguntando “ok, você quer isso, mas o que, objetivamente, você faz para chegar a esse resultado?”. Muito bom. Nada melhor do que fazer muito alguma coisa para ficar muito bom nisso.

Bem, eu já falei que gostaria de ter a oportunidade de conhecer melhor o máximo de ocupações, claro que isso não é possível, a não ser que eu me prepare e consiga trabalho na FIPE, contudo, esse sábado permitiu que eu conhecesse um pouco mais das ocupações que ocupavam a mesa conosco.

Notei que quase todas compartilham de preocupações similares às preocupações que temos na análise de negócios. Por exemplo: como analistas de negócios defendemos que o valor do nosso trabalho está na compreensão das reais necessidades das partes interessadas e não no simples ato de “tirar pedidos” registrando o que as pessoas pedem.

No caso do relações públicas, existe uma preocupação em ir além da melhoria da imagem de uma organização, o intuito é melhorar as ações da organização.

No caso da ouvidoria, o objetivo é garantir voz para quem não tem, buscar soluções, ou, pelo menos respostas para os demandantes e não se limitar ao que chamaram de “encaminhadoria”, ou seja, o simples ato de encaminhar problemas para outras áreas da organização.

Sério, eu nem pensava nisso antes desse sábado. No caso da análise de mercado, soube que o gerente de projetos está absorvendo todas as atividades do analista de mercado. Bem, a minha teoria é a de que se o gerente de projetos não absorver atividades dos demais não sobra muito para fazer (pausa para uma boa risada), então na prática o gerente de projetos é um analista de mercado que reporta para o negócio e para os clientes.

Outro aspecto que me deixou bem satisfeito no sábado foi que fazia tempo que eu não era uma parte interessada tendo meu trabalho facilitado por alguém. Sou sempre eu quem facilita (ou co-facilita) e quase nunca sou parte interessada, só me interesso mesmo pelo bem geral da nação.

No sábado eu estava realmente preocupado com como a análise de negócios seria representada, como fazer com que meus interlocutores compreendessem o que fazemos e o que é importante para a nossa ocupação. É uma posição bem diferente e me ajudou a buscar ainda mais empatia com as pessoas que participam das minhas facilitações.

E então, como ficou a análise de negócios na nova CBO??? Não posso dizer, é segredo até o começo do ano que vem quando será publicada. Só posso dizer que acho que o Fabrício Laguna (o relato dele está aqui), presidente do IIBA São Paulo e eu fizemos um bom trabalho.

Permalink | Leave a comment »

Construir a coisa certa

Sun, 25 Nov 2012 06:24:00 -0800

O livro “Leading Lean Software Development: Results Are not the Point” é o tipo de livro que só deve ser lido pelas pessoas que gostam de desafiar suas crenças e conceitos-chave a cada capítulo.

O capítulo 3 “Reliable Delivery” (entrega confiável) descreve em detalhes o processo de construção do Empire State Building, que, lançado em 1931 manteve por 40 anos o título de edifício mais alto do mundo. Por que o edifício é exemplo de entrega confiável? Porque ele foi construído em apenas 20 meses.

A maior parte dos fatores que levaram a esse sucesso de entrega também fazem sentido quando pensamos em desenvolvimento de software e eu sugiro que todos os interessados em entrega leiam pelo menos esse capítulo.

Eu sempre prego que “entrega” ou “delivery” devem ser preocupação do analista de negócios, afinal, nenhum trabalho feito pelo AN (a não ser aquele que evita que software seja desenvolvido) faz sentido se o software não estiver disponível no momento certo, contudo, o que mais me chamou atenção nesse capítulo foi o fato de que apesar de ter atendido às expectativas da santíssima trindade prazo, custo e escopo com qualidade, o Empire State, como NEGÓCIO foi um fracasso.

No momento em que foi lançado, dia primeiro de maio de 1931 o edifício estava localizado em uma área da cidade com pequeno fluxo de pessoas, havia uma enxurrada de ofertas de escritórios baratos na cidade e o país ainda não havia saído da grande depressão econômica. Esses fatores levaram o empreendimento a decolar apenas 15 anos após a sua construção.

Após anos me preocupando com como entregar os projetos da melhor forma, como elicitar os requisitos e comunicá-los, como aprender com o feedback que recebemos do desenvolvimento iterativo e incremental de software e aplicar o aprendizado em seguida, como aproximar quem paga, quem vai utilizar e quem está construindo em um ambiente harmonioso, não atingi a paz de espírito, muito pelo contrário, uma pulga enorme surgiu atrás da minha orelha:

Será que faço esse trabalho todo sem nem ao menos saber se estamos construindo a coisa certa? Passeio esse tempo construindo meu Empire State Building?

Para trabalhar essa hipótese passei em exame mental as iniciativas das quais eu participei nos últimos 15 anos e notei que elas se separam, quase que naturalmente, em duas categorias bem distintas com base no que se esperava do meu papel de analista de negócios.

A primeira categoria, que batizei de “eficácia”, possui as iniciativas nas quais eu tinha acesso de fato ao negócio, compreendia seu funcionamento de ponta a ponta e via em primeira mão como a nossa iniciativa o impactaria, permitindo adaptações, modificações no curso. A melhor delas envolveu o gerenciamento de um produto já estabelecido no mercado.

A segunda categoria, a “eficiência”, possui as iniciativas nas quais eu estruturava todo o meu trabalho sobre uma ou mais premissas passadas a mim por alguém. Eu tomava essas premissas como verdadeiras com base na autoridade de quem as repassou e desenvolvia todo o trabalho a partir dali.

A primeira categoria reúne iniciativas em organizações menores, nas quais eu atuei na maior parte das vezes como colaborador interno, como “intraempreendedor” enquanto a segunda categoria tende a reunir as iniciativas de organizações maiores, nas quais eu atuei como consultor externo.

É muito natural que isso ocorra, afinal, quando você contrata alguém para fazer um trabalho para você, o objeto dessa contratação, esse trabalho, já nasce como uma premissa, ela é o que “deve” ser feito e entregue.

Quando as organizações são maiores, mesmo quando não existe a contratação de agentes externos, existe a “contratação de outras áreas”, no nosso caso TI, e essa contratação tende a seguir o mesmo modelo mental da terceirização.

Isso se dá porque poucas empresas sabem trabalhar como modelos como mapa estratégico e acabam cobrando as áreas com base no seu desempenho individual gerando mais negociação de contratos do que cooperação.

Qual seria então a diferença primordial entre essas duas categorias? Apelo à frase de Peter Drucker para explicar:

“a eficiência consiste em fazer certo as coisas
e a eficácia em fazer as coisas certas.”

Veja, não estou propondo uma falsa dicotomia, não existe uma escolha obrigatória entre eficiência e eficácia, o que existe no nosso trabalho de análise de negócios é um foco na eficiência e desapego pela eficácia.

Abraçamos a premissa, seja qual for, e fazemos o nosso melhor para atendê-la. Chegamos ao cliente e ouvimos “oferecer o produto x até a data y nos trará N% de retorno e possibilitará que yada yada yada aconteça”. Colocamos isso no coração e partimos para o trabalho.

Isso está errado? Teoricamente não. Veja a definição de análise de negócios:

“Análise de negócios é o conjunto de atividades e técncias utilizadas para servir como ligação entre as partes interessada, no intuito de compreender a estrutura, políticas e operações de uma organização e para recomendar soluções que permitam que a organização alcance suas metas”.

NADA na definição de análise de negócios envolve questionar ou desafiar as premissas (metas), o trabalho do analista de negócios é facilitar que a organização alcance as suas metas, não questionar as metas, rever as metas e o que seria melhor, testar as metas.

O modelo mental dentro do qual essa definição foi escrita é o modelo mental que subordina a análise de negócios ao gerenciamento de projetos, não ao negócio.

Não existe modelo de trabalho que dificulte mais o desafio de premissas do que o gerenciamento de projetos, porque um projeto é um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo.

Uma vez definido um projeto, questionar produto, serviço ou resultado exclusivo é um ato que fere a própria natureza do projeto.

Um projeto traz o mesmo risco para um negócio que trabalhar desenvolvendo épicos ou casos de uso de 45 páginas traz para o desenvolvimento de software. Lotes de trabalho menores são muito benéficos para o desenvolvimento, permitem um feedback mais rápido, descoberta e tratamento de defeitos mais cedo e mudanças de rumo menos traumáticas.

A conta é a mesma para um negócio: o custo de descobrir que a sua ideia estava errada é muito superior ao custo de implementar uma estrutura que permita que você teste suas ideias de forma barata e mais rápida.

A análise de negócios que deveria ser um belo cisne negro desafiador de premissas nasceu e hoje cresce achando que é um patinho feio defensor de premissas.

O que hoje chamamos de análise de negócios deveria ostentar um nome menos pomposo, algo como promoção do consenso em projetos e ser sim uma subdisciplina do gerenciamento de projetos.

Isso é o melhor que podemos fazer quando estamos em um ambiente onde as premissas não podem ser questionadas. Se você é analista de negócios em um projeto e seu trabalho contribuir para a eficácia do trabalho dos demais (requisitos mais claros e não ambíguos, consenso entre as partes interessadas e tudo mais) você será considerado um bom profissional indepentende do fato do produto, serviço ou resultado exclusivo criado trazer ou não resultado.

De qualquer forma, a falta de vínculo com o resultado para o negócio deveria impedir que ostentássemos “negócio” no crachá.

Ok, mas nós temos opções? Sim, nós temos opções. Eu vejo pelo menos duas.

A primeira é buscar trabalhar com iniciativas menores como startups. As startups (fora aquelas abertas com o dinheiro do papai) não tem tempo a perder, elas precisam validar as suas hipóteses rapidamente, sentir o pulso do mercado e adaptar, tudo em ciclos curtos. Trabalhar como analista de negócios nesse contexto é excitante e você pode se divertir muito. Contudo, trabalhar assim também é desgastante ao ponto que raramente uma empresa mantém essa forma de trabalhar depois de ter conseguido superar as suas maiores incertezas. Quando a caça está garantida você pode deixar um pouco de gordura se acumular onde antes havia uma barriga de tanquinho. Nosso sonho inconsciente é o conforto, não tem jeito. Pelo jeito só pessoas como o Steve Jobs não buscam instintivamente estabilizar um dia.

A segunda opção é aceitarmos que o nosso trabalho é de promoção do consenso em projetos e fazermos esse trabalho da melhor forma possível.

Ok, eu chamei esse cara de patinho feio, mas ele não é feio, é só “menos bonito”. Quer saber, talvez seja até mais bonito.

Existe uma beleza na promoção do consenso em projeto e essa beleza está no simples fato de que quando você trabalha com isso você trabalha para ativamente melhorar as vidas das pessoas envolvidas no projeto.

Quando você promove uma melhor comunicação está fazendo com que as pessoas passem os dias com menos receio de serem mal compreendidas. Quando você diminui a ambiguidade dos requisitos você diminui a insegurança de todos, quando você dá espaço para que desenvolvedores interfiram no produto você aumenta o senso de propósito deles e por aí vai.

Dizer que isso não tem valor é como dizer que o trabalho de um profissional da saúde não tem valor porque ele não compreende ou interfere ativamente nas metas do negócio no qual seu paciente trabalha.

Ser um promotor do consenso no projeto implica trabalhar pelo bem-estar dos envolvidos no projeto partindo da sua ferramenta de trabalho, o escopo do produto do projeto, seja ele salvar golfinhos, seja construir a estrela da morte. Isso é fazer o bem de forma tangível e é totalmente válido inclusive como sua meta de vida profissional.

Vale lembrar que esse último parágrafo pode ser uma premissa a partir da qual você pode construir a sua carreira. Nesse caso, insisto que você a questione e a desafie, afinal, o produto aqui é a sua vida e as metas da sua vida são você quem faz.

Esse “negócio” é seu. Nada de simplesmente adotar as premissas dos outros ok?

E quanto a mim? É, eu acredito nessa premissa. Apesar de sentir satisfação quando trabalho no lado da eficácia, os momentos nos quais me senti mais feliz no trabalho foram aqueles nos quais sentia no olhar das pessoas do negócio, dos clientes e dos desenvolvedores que a vida deles havia melhorado em parte por causa do meu trabalho.

Me sinto construindo a coisa certa.

Permalink | Leave a comment »

Nós vendemos soluções ou estamos presos dentro do cercadinho?

Thu, 25 Oct 2012 11:16:00 -0700

Soluções, soluções...

Segundo o BABOK 2.0 uma solução é “um conjunto de mudanças no estado atual da organização que são feitas com o intuito de permitir que ela atenda a uma necessidade do negócio, resolva um problema ou se beneficie de uma oportunidade”.

O mais importante a respeito de soluções, fora a sua relação com a necessidade do negócio, claro, é que “grande parte das soluções envolve um sistema de componentes de solução que interagem entre si e cada componente é potencialmente uma solução em si mesmo”.

Isso implica que quando nós chamamos um sistema de “solução” corremos um enorme risco de tomarmos uma parte como o todo, pois é muito provável que o sistema seja, de fato, um dos componentes da solução e nem sempre o mais importante.

Digamos que nossa empresa preste atendimento pós-vendas, ou suporte também via telefone para os clientes atuais (caso real).

A empresa tem como meta anual um acréscimo no volume de venda sobre a sua base de clientes (clientes atuais), ela quer vender mais para quem já é cliente, ou seja, conseguir uma parcela maior da carteira dele (share of wallet).

Alguém do pós-venda e suporte lembrou que é comum clientes expressarem desejo por incrementos nos produtos atuais ou até mesmo novos produtos durante as interações do pós-venda e suporte, mas que os atendentes não sabem exatamente como proceder.

Alguns passam os dados de contato da área comercial, outros de pessoas específicas na organização que podem auxiliar, contudo, há sempre a impressão de que essas oportunidades não são bem exploradas e a certeza de que não há nenhuma informação a respeito delas para a

nálise depois que a ligação é encerrada.

Por outro lado, a área comercial alegava que as oportunidades oriundas do pós-venda e do suporte chegavam com informações truncadas, pouca clareza da necessidade e às vezes por diferentes meios como e-mail, telefone e até bilhetes colados no monitor. Quando uma oportunidade como essa é registrada no sistema de força de vendas, responsável pelo gerenciamento, a comercial não encontra a origem correta (deveria ser suporte ou pós-venda) e acaba informando algo aproximado.

Bem, o problema seria melhorar o aproveitamento dessas oportunidades de venda, mas e a solução? Bem, neste caso a solução se dividiu em alguns componentes:

Criação de um acordo nível operacional entre pós-venda, suporte e comercial no qual as áreas geradoras de oportunidades se comprometeram a coletar as informações junto aos clientes no formato determinado pela comercial e no qual a comercial se comprometia a iniciar o tratamento das oportunidades em no máximo um dia útil após a comunicação.
Treinamento dos atendentes do pós-venda e do suporte para a detecção de possíveis oportunidades junto aos clientes e coleta correta de informações.
Adequações no sistema de força de vendas para a entrada de novos atores (pós-venda e suporte), digo atores e não usuários, porque eles possuem uma interação com o sistema levemente diferente dos demais atores. Também é necessário inserir duas novas opções de origem de oportunidade (pós-venda e suporte) para que o resultado desse trabalho possa ser medido.

São três componentes (dimensões?). Podemos dizer que o primeiro é humano, o segundo processual e o terceiro tecnológico.

Fica claro para você que se ignorássemos os itens 1 e 2 e implementássemos apenas o 3 a coisa ficaria no mínimo capenga?

Pois é, isso acontece todos os dias o tempo todo em um monte de lugares. Colocar o status de solução para o sistema, para o componente tecnológico ignorando o que está ao redor nos faz correr o risco de fazermos uma entrega tecnicamente perfeita que surte pouco efeito prático.

Um bom exemplo disso são todas as features que você já entregou ao longo da vida que foram pouco ou nunca usadas. Faça um levantamento rápido aí.

A cena é clássica, alguém chama você para conversar e diz algo como “o pessoal do suporte vai começar a usar o SFA, precisamos fazer algumas adaptações. Conversa com eles, vê como tem que ser e...”.

É nesse ponto que a TI ou o fornecedor precisa tomar uma decisão consciente do que oferece e até onde vão as suas responsabilidades.

Se optar por se limitar ao componente software deve também se conformar com os limites disso e com a provável baixa relevância que terá nos resultados finais. Isso inclui quem utiliza métodos iterativos e incrementais com muito foco na entrega e pouco questionamento do que foi entregue.

Esse tipo de posicionamento é bom para quem gosta de usar o argumento “fiz tudo o que era da minha responsabilidade” ou “entreguei tudo que vocês pediram”.

Optar por se envolver com os demais componentes da solução, por coordenar esforços é como abrir um portal para novas dimensões: é mais perigoso, é mais arriscado, mas é ali que estão as grandes oportunidades de fazer a diferença e também de aprender muito.

Aliás, pensar em ficar restrito ao componente da solução "software" me parece ser como optar por viver em duas dimensões quando somos afetados e temos a opção de perceber três, como se fôssemos viver na Planolândia de Edwin Abbot explicada com maestria pelo saudoso Carl Sagan (assista, é sensacional).

Não sou partidário de falsas dicotomias, então adoraria se alguém apontasse uma terceira alternativa para a situação, desde que, claro, não seja a de se responsabilizar pela solução e focar apenas no seu componente. Essa é um tiro no pé.

Uma boa analogia para o pensamento fora da caixinha (nesse caso, software é apenas um componente da solução) é a campanha da Coca Cola Zero que passou a vender latinhas e garrafas contendo “nomes próprios” (a professora de português está orgulhosa agora) junto com o seu slogan “quanto mais, melhor”.

A publicidade convencional costuma contar com componentes de solução bem definidos e estabelecidos como comerciais em diferentes mídias (somos bombardeados, em média, por três mil comunicações publicitárias por dia) e os publicitários (divididos em várias subespecializações) costumam trabalhar da mesma forma que a TI ou os fornecedores, ou seja, focados no seu nicho de costume.

A promoção da Coca Cola Zero foi abrangente e envolveu além dos componentes tradicionais uma mudança que impactou a própria produção na fábrica.

Se você trabalhou com produção em massa sabe que quanto mais unidades de um modelo específico de alguma coisa você fizer maior será o seu ganho econômico.

Já vi casos de empresas alimentícias concorrentes que combinaram que cada uma faria um tipo de produto na sua fábrica para que todas evitassem o enorme custo do setup das máquinas na hora de produzir outra coisa.

Em suma, fazer o que a Coca fez é complicado e é caro e deu um baita resultado. Eu nem tomo mais tanta Coca Cola, mas comprei uma com o nome da minha pessoa favorita para guardar de lembrança.

O componente software da campanha da Coca permitia você publicar uma foto de uma latinha com o seu nome em uma rede social, algo que (tirando a publicação na rede social que não existia) eu teria feito com a biblioteca GD do PHP em 1999 de tão simples que é. Imagine qual seria o impacto da campanha se apenas o componente de software tivesse sido entregue.

Ahh, mas é a Coca Cola! Eles já davam minigarrafas de refrigerante antes de eu nascer. Tudo bem, mas será que trabalhar nos diferentes componentes da solução só funciona nessas circunstâncias? Claro que não.

O primeiro exemplo que eu dei é, de fato, uma situação bem ordinária e foi necessário apenas dar um passo atrás para ver a situação como um todo e desejo de aprender. Ok, e se eu quiser entregar soluções, o que eu preciso fazer? Que tal contratar alguém que entende de negócios (seja lá como se mede isso em alguém), e dar a ele a função de analista de negócios? Não resolve? Não, não mesmo.

Contratar um analista de negócios e deixá-lo restrito dentro do cercadinho do seu componente da solução não vai resolver. Isso pode até ser considerado crueldade, principalmente se o pobre analista realmente gostar de negócios e criar empatia com ele.

O caminho está em desenvolver um ambiente, um contexto que aumente a interação entre os diferentes componentes possíveis da solução. Para que eles estejam abertos para sugestões e mudanças você precisa se abrir para sugestões e mudanças no seu componente.

Isso depende de negociação, confiança e lembra a terceira frase do manifesto pelo desenvolvimento ágil de software: “Colaboração com o cliente mais que negociação de contratos”.

Tanto para a área de TI quanto para o fornecedor isso tem a ver com saber vender, com como fechar uma boa venda onde o terreno está propício para que um bom trabalho seja realizado em seguida, seja um trabalho orientado ao planejamento seja orientado à mudança.

Eu sou analista de negócios (aquele cara ali na jaula) e me interesso em atender à necessidade do negócio ficando muito frustrado quando mandam eu ficar no cercadinho, por isso já aviso bem cedo que “Quanto mais sair da caixinha melhor”.

Permalink | Leave a comment »

Ouça a minha palestra na Jornada de Informática da UNESP Bauru e acompanhe os slides

Wed, 24 Oct 2012 06:32:00 -0700

Diferente da palestra do BABRAZIL 2011 que tinha como público alvo analistas de negócios a palestra da última sexta-feira (19/10) teve como público alvo estudantes de sistemas de informação e ciências da computação.

O objetivo da palestra foi armar esses futuros profissionais com conhecimentos sobre negócios suficientes para que possam ter uma atuação mais abrangente no desenvolvimento de produtos ou passar a executar atividades de análise de negócios em iniciativas.

A palestra é longa e o áudio não está dos melhores, contudo quem participou disse que valeu muito a pena. Convido você a assistir:

Análise de Negócios como ferramenta para desenvolver produtos de sucesso - UNESP Bauru (áudio sincronizado!) from Claudio Kerber

Permalink | Leave a comment »

Palestra para estudantes. Adoro! UNESP Bauru dia 19/10

Sun, 14 Oct 2012 17:21:00 -0700

Gosto muito de falar para estudantes em palestras e workshops. Os estudantes são sim mais jovens, inspirados e menos influenciados pelos vícios comumente adquiridos no mundo do trabalho.

Estudantes do terceiro grau em fases mais avançadas possuem uma vantagem extra: eles já estão fazendo incursões no mercado e já estão levando os primeiros sustos e as situações estão despertando questões complexas. Algumas eu consigo responder, outras espero respondermos juntos.

Estou sempre aberto a palestrar sem custos em faculdades, mas acho que ando divulgando pouco isso, uma vez que a última vez na qual tive esse prazer foi em junho de 2001 na Uninove.

Na sexta-feira vou para Bauru palestrar na XIII Jornada de Informática. Fiz um pouco de elicitação junto aos organizadores e o tema será:

Análise de Negócios como ferramenta para desenvolver produtos de sucesso

Passamos anos estudando e nos aprimorando sobre “como fazer” software, como desenvolver soluções, contudo, onde fica o “o que fazer” e como justificamos “por que fazer”?

Seriam “o que fazer” e “por que fazer” questões alheias aos profissionais de tecnologia? Seriam essas questões que deveríamos deixar nas mãos de profissionais mais próximos ao mercado e afeitos a esses assuntos? Eu acredito que não.

O sucesso de um produto passa pela relação estreita entre a descoberta e a entrega e profissionais de TI que dêem sentido ao que produzem através do envolvimento com a forma com que seu trabalho afeta clientes e usuários são o ativo mais importante que uma iniciativa pode ter.

Nessa palestra apresentarei a análise de negócios como disciplina, sua história, áreas de conhecimento, técnicas, ferramentas e aplicação e irei além, apresentando aplicações práticas desses conhecimentos por times de desenvolvimento que aplicamos ao longo do tempo em produtos que envolviam software e também hardware.

Mais informações aqui: http://www2.fc.unesp.br/jornada_informatica/index.php

Será um enorme prazer tanto participar do evento, conversar com as pessoas (aprender um bocado com isso) quanto conhecer Bauru, pois as bicicletas e a companheira de pedal vão me acompanhar na viagem.

Permalink | Leave a comment »

Por onde andei

Sun, 07 Oct 2012 10:45:00 -0700

O que mais me mantém inspirado para escrever aqui são as interações com os times de desenvolvimento. Sim, sou analista de negócios e o senso comum nos leva a pensar em um analista focado no lado da descoberta, do o que fazer e do porque fazer, contudo, sou fascinado pela importância que a aproximação do time de desenvolvimento com o negócio tem para o sucesso das iniciativas.

Quando um desenvolvedor se envolve com o produto sendo desenvolvido todos ganham. Ganha o negócio que consegue validar hipóteses mais rápido, que passa a contar com a surpreendente e muitas vezes inesperada criatividade do desenvolvedor. O desenvolvedor dá sentido e significado ao seu trabalho, pois entende o contexto e pode ver com seus próprios olhos o impacto que ele traz para as pessoas.

Em 2012 acabei me envolvendo com iniciativas que envolviam pessoas, mas onde eu tive que trabalhar com mais afinco meu lado técnico.

Que iniciativas foram essas?

A primeira foi envolvimento com BI, business intelligence, a arte de cruzar dados de bases de dados transacionais (de sistemas usados nas operações) com diversas outras fontes para gerar informações que sejam úteis para o negócio.

Nessa iniciativa começamos trabalhando com o Pentaho na sua versão community (aberta) e terminamos utilizando o QlikView, um aplicativo pago, fechado e... impressionante.

Além da elicitação, dever de todo analista de negócios, esse trabalho envolveu diferentes habilidades e conhecimentos: mineração dos dados em bancos grandes e complexos como ERPs e CRMs, ETL (extraction, transformation, loading) e por fim o conhecimento específico nas plataformas utilizadas.

O mais interessante nesse trabalho foi conseguir construir análises de dados que envolviam diferentes fontes de informação relevantes para o negócio. Não se trata de fazer gráficos e tabelas rebuscados de apenas um sistema, mas sim de permitir que correlações entre diferentes informações sejam estudadas pelo negócio, no caso informações do ERP, do Smart Ad Server e do Google Analytics.

[Sim! dá para comparar maçãs com bananas, alhos com bugalhos e isso é muito bom, basta fazer comparações com números relativos, não absolutos].

A segunda iniciativa foi a implantação de uma intranet. Sim, as intranets ainda existem. Não mais como pensávamos nos anos 90 e isso ficou claro quando contrapus dois modelos mentais, um literalmente centralizado, o do Central Desktop e o descentralizado, o do Google Apps.

Eu pretendo fazer um post sobre cada uma das iniciativas com todas as reflexões que elas merecem, tanto técnicas quanto sociológicas.

Sobre os times de desenvolvimento me aguardem. Logo logo volto para a minha “cachaça”.

Permalink | Leave a comment »

Hoje - Mini Palestra no TDC 2012

Fri, 06 Jul 2012 11:07:00 -0700

Vou apresentar na prática como o Pentaho pode ser usado para extrair dados de um arquivo com a pior formatação possível para leitura, a formatação para impressão, e gravá-los em um arquivo separado por vírgulas ou mesmo em uma base de dados.

Também vou falar sobre como o processo pode ser implementado em um servidor e agendado para execução periódica ou a partir de outros eventos (chegada de arquivos à uma pasta, recebimento de e-mails entre outros).

A palestra será na trilha de banco de dados do TDC:

http://www.thedevelopersconference.com.br/tdc/2012/saopaulo/trilha-banco-de-dados-university#programacao

E sobre análise de negócios? Não vai falar nada? É isso mesmo. Na edição de 2012 vou me limitar a apresentar uma solução interessante para um problema concreto.

Até lá.

Permalink | Leave a comment »

Conversa rápida: Desobediência Civil

Fri, 30 Mar 2012 11:38:00 -0700

Na semana passada participei do Conversa Rápida onde os palestrantes possuem alguns minutos para falar sobre qualquer assunto.

Para fugir do habitual não falei nem de análise de negócios nem de bicicleta, preferi falar sobre Desobediência Civil, um assunto que me chamou atenção faz uns 11 anos.

Permalink | Leave a comment »

Meu primeiro artigo na InfoQ internacional! ||||| The Day I Become Unnecessary - Part 1

Wed, 28 Mar 2012 08:15:00 -0700

O meu artigo "O dia em que me tornei desnecessário" foi, sem modéstia, um sucesso. Escrevi do coração com base em uma experiência muito legal que tive quando estava na Stefanini atuando como Agile BA.

Até hoje foram incríveis (para mim) 11.118 pageviews.

Graças ao convite do coordenador da área Agile da InfoQ Shane Hastie pude publicar o artigo lá. Para deixar mais interessante eu o dividi em duas partes e a primeira foi ao ar essa semana em http://www.infoq.com/articles/day-became-unnecessary-part1 .

Chegue lá, dê uma lida e deixe seu comentário. Eu adoraria estender a discução ao âmbito internacional e também de ter muitos acessos e comentários para publicar mais textos nessa publicação tão legal.

Permalink | Leave a comment »

Pra não dizer que não falei de árvores

Tue, 06 Mar 2012 13:28:00 -0800

Alguém na sua empresa aborda você com uma ideia, uma iniciativa a ser feita para atingir um objetivo, algo que desejam alcançar. O que fazer? Como avaliar? Como pensar no que será necessário e nas suas implicações?

Aqui vai o primeiro passo: Desenhe uma arvorezinha.

O lance da arvorezinha é o seguinte: Pense na empresa como uma arvorezinha, genial não? Pois eu acho que é desde a primeira vez que rabiscaram isso para mim*.

No topo temos os frutos, os frutos são a perspectiva financeira. Na perspectiva financeira temos objetivos bem comuns como “aumentar a receita” ou “diminuir os custos”, claro que existem outros com nomes mais elaborados, mas, basicamente tem a ver com quanto dinheiro a mais a empresa vai ficar.

Frutos não se sustentam por si só, eles precisam dos galhos. Os galhos são os clientes e tudo o que tem a ver com eles, como, por exemplo, os produtos que você oferece em troca dos “nutrientes”. Nessa perspectiva temos objetivos como “vender mais coisas para um mesmo cliente”, “conseguir novos clientes”, “perder menos clientes” e por aí vai.

Galhos também não se sustentam por si, e aí vem o tronco. O tronco são os processos da empresa e a tecnologia que apoia esses processos. Os objetivos aqui tem muito a ver com eficiência, com saber fazer as coisas de um jeito melhor, que consuma menos recursos e entregue mais para os galhos como “aumentar a velocidade de resposta do call center”, “melhorar a utilização de equipamentos ociosos na produção”.

Um belo tronco não se sustenta sem as raízes. As raízes são o que diferenciam uma empresa de uma máquina. As raízes são as pessoas. Os objetivos em relação às pessoas tem a ver com “contratar mais pessoas com a competência x”, “desenvolver a competência y no grupo w de pessoas” ou simplesmente “se livrar do grupo z de pessoas”.

Pensar na arvorezinha implica pensarmos que:

1. Para aumentar a receita...

2. ... precisamos de um novo produto x adicional para fazer com que nossos clientes gastem mais...

3. ... para isso vamos precisar desenvolver o produto adicional e aumentar nossa estrutura de suporte além de fazer alterações na forma de cobrança...

4. ... e vamos precisar de novos desenvolvedores e analistas de suporte, além de treinar o pessoal de cobrança para lidar com os novos casos.

Parece simplório, e é, mas se uma ideia não passar por um filtro simples assim não merece atenção.

Gosto da arvorezinha da mesma forma que gosto do business model canvas e do lean startup canvas, gosto porque ela trabalha com o pensamento visual permitindo que discutamos o que interessa com todos os envolvidos independente do seu conhecimento no que tange aos negócios.

O teste da arvorezinha serve para evitarmos o pensamento mágico de que novas iniciativas não possuem vínculos com outras perspectivas. Pense naquele produto novo que foi criado apesar de simplesmente não haver alguém para desenvolvê-lo? Um claro problema de alimentação entre raíz e tronco. E naquele caso no qual disseram que nossa receita cresceria 10% no próximo ano sem que você visse nenhuma ação nas outras perspectivas que levasse você a acreditar nisso? Loucura? Ahh, você sabe que acontece.

A arvorezinha também pode ser cruel com algumas iniciativas cruciais como “mudar todo nosso sistema de asp para .net”. O exercício aqui começa com localizar essa iniciativa, acredito que seja em processos e tecnologia, no tronco. Pensando para cima, nos galhos: produtos e os clientes. Você pergunta “isso vai fazer com que vendamos mais, perdamos menos clientes, tiremos mais dinheiro dos nossos clientes ou coisa assim?” e, pensando nos frutos: isso vai nos trazer mais faturamento, lucro ou queda nos custos?

Pensando para baixo, nas raízes: temos competência para fazer isso? Vamos precisar contratar, treinar ou tercerizar?

É mais ou menos por aí. Coloque a arvorezinha na sua caixa de ferramentas. Existem mil maneiras de usá-la, invente uma!

A arvorezinha é baseada nos Mapas Estratégicos (http://www.submarino.com.br/produto/1/225108/mapas+estrategicos:+balanced+sco....

* Quem me explicou isso foi o Miguel Rivero Neto na Dígitro em 2007. Altamente didático como sempre.

Permalink | Leave a comment »

Gerenciamento de riscos: o poder é de vocês

Wed, 15 Feb 2012 09:15:00 -0800

Minha amiga chega ao trabalho e após alguns minutos se dá conta de um fato aterrador: não consegue lembrar se tirou ou não a sanduicheira da tomada.

Você conhece a sensação, talvez o mais desagradável seja o fato de simplesmente não conseguirmos lembrar. A memória é assim: prega peças para dar sabor à vida, transforma em probabilidades o que poderia ser certeza.

Bem, os riscos fazem parte da nossa vida. Para que um risco exista basta determinarmos qualquer resultado esperado em qualquer ramo da atividade humana.

Acordo pela manhã, abro os olhos e penso: “vou trabalhar”. Pronto! Com essa frase nasceu o risco de eu não trabalhar hoje ou talvez nunca mais.

Riscos existem, podemos lidar com eles, ignorá-los (não saber da sua existência) ou simplesmente aceitá-los e as suas consequências. Ignoramos riscos que não conhecemos e aceitamos riscos que achamos pouco prováveis, como faço com o risco da minha casa ser atingida por um asteróide.

Como vamos lidar com um risco depende de uma equação simples na qual pesamos o quão ruim as coisas serão se esse risco se concretizar, qual a probabilidade desse risco acontecer de fato e por fim, qual o custo que vamos ter em lidar com ele.

Custo da ação < (Bomba / Probabilidade)

Em PT-br: o custo da ação não deve superar o custo da bomba explodir em relação à probabilidade dela explodir.

Os seres humanos que habitam o planeta hoje são descendentes dos seres humanos que souberam aplicar essa equação da melhor forma dado cada momento.

Vou usar a história da minha amiga para descrever o que podemos fazer em relação a um risco, no caso dela o risco da sanduicheira esquentar demais e causar um incêndio.

A primeira opção em relação a um risco é evitar. Trata-se da velha história de que prevenir é melhor do que remediar, só que para evitar um risco você precisa agir com antecedência.

Quando eu saio de casa dou uma geral nas tomadas e desligo até mesmo equipamentos sem muito risco, até para protegê-los de sobrecargas na rede. Isso tem um custo: são minutos perdidos da minha vida todos os dias e uma boa chance de adquirir um transtorno obsessivo-compulsivo.

Faço a continha e até então esse custo é menor do que a bomba em relação à probabilidade percebida por mim (casa velha).

Minha amiga ainda podia evitar o risco voltando para casa e se certificando de que a sanduicheira está fora da tomada, contudo o custo disso é bastante alto dado o fato do transporte na cidade dela ser bem precário e uma reunião importante estar marcada para logo mais.

Aqui vai algo importante: O custo de evitar só ficou grande porque o risco se tornou consciente quando era tarde demais. Podemos argumentar que ela poderia ser mais responsável, bla bla bla, mas seríamos apenas engenheiros de obra pronta, pois depois que o risco aparece costuma parecer óbvio para todos.

É virtualmente impossível conhecer todos os riscos com antecedência, dessa forma, cuidado com a obsessão de prever e evitar todos os riscos, isso pode ter um custo muito alto para a empreitada e você corre o risco :) de criar uma sensação de segurança total nas pessoas que não tem fundamento.

A segunda opção se chama transferir. Minha amiga paga seguro do imóvel e em última instância um incêndio acidental é coberto pela sua apólice.

A transferência é isso: alguém com mais condições do que você de lidar com a explosão da bomba aluga essa capacidade para você em troca de dinheiro antecipado.

As seguradoras e planos de saúde fazem a mesma continha que nós fazemos, só que do lado inverso. No caso da seguradora: Se a quantidade de dinheiro recebido pelo seguro dos imóveis for superior do que a média gasta pagando pelos que de fato pegam fogo, somado aos custos operacionais você está no lucro.

No filme Clube da luta existe um exemplo do tipo de conta simples que as empresas fazem, falam da decisão de fazer ou não recall de veículos que estão causando acidentes com mortes horrorosas, famílias inteiras morrendo queimadas. O raciocínio é:

A: número de carros em uso

B: taxa provável de falha

C: custo médio de um acordo judicial

Se A X B X C der um custo inferior ao enorme custo de um recall a empresa simplesmente não faz o recall permitindo as mortes e pagando seu preço na justiça.

Cruel? Bem, é exatamente o mesmo tipo de cálculo que nós fazemos no nosso dia a dia. Fazemos uma série de escolhas baseadas em custos e comodidades que afetam pessoas ou outros seres e como eles estão distantes nem nos damos conta. Isso se chama externalização dos custos, mas é assunto para outro post.

Nós pagamos o seguro porque percebemos que o custo é inferior ao custo do nosso imóvel vezes a probabilidade dele pegar fogo. Minha amiga tem seguro, mas digamos que ele não cobre outros problemas advindos do seu lar (veja que usei lar e não imóvel) pegar fogo como perder suas coisas, memórias e o tempo sem ter onde morar.

Uma vez que evitar era muito caro e transferir não parecia uma boa a minha amiga decidiu mitigar.

Mitigar um risco implica fazer algo que diminua a probabilidade ou as conseqüências do problema. A mitigação pode ser feita com antecedência, mas também pode ser uma ferramenta útil depois do risco aparecer caso você for criativo.

A idéia dela foi ligar para o síndico e solicitar que ele desligasse a chave geral de energia do seu apartamento. Essa ação diminui a probabilidade do apartamento pegar fogo a quase zero (mesmo com tudo desligado a probabilidade ainda existe) e tranqüiliza a pessoa uma vez que tanto faz a sanduicheira estar ou não na tomada (fonte daquela sensação desagradável de dúvida). É um grito de liberdade “dane-se maldita sanduicheira!”.

Todavia, existe um custo, esse custo está no tempo gasto ligando para síndico, está em dever mais um favor para ele (favor é custo), em provavelmente perder o que ela tem na geladeira e no tempo gasto reprogramando eletrodomésticos como rádio relógios e televisores modernos.

Minha amiga fez as contas e optou por mitigar dessa forma. Você pode não concordar com a solução dela e isso faz todo sentido porque risco e probabilidade tem a ver com percepção. Há pessoas que não dão bola para alguns riscos enquanto valorizam outros. Esse fenômeno é fruto da diversidade de experiências humanas.

Todavia, essas divergências na forma de ver os riscos e as probabilidades pode gerar muitos problemas que vão explodir mais à frente, pois a forma de lidar com os riscos tem tudo a ver com “custos” e ali o sapato é apertado.

É por isso que dentro do gerenciamento de riscos, o primeiro a ser analisado é justamente esse, o da diferença de percepção. Para isso vale conversar com os envolvidos na sua empreitada, deixar as coisas claras e decidir as ações em conjunto. Muitas ideias boas podem surgir disso.

Conforme a empreitada avança novas coisas acontecem e a nossa percepção muda ficando mais abrangente, o que possibilita que percebamos riscos que havíamos negligenciado, dessa forma, um bom gerenciamento de riscos além de participativo deve ser iterativo, ou seja, deve ocorrer em ciclos para absorver essas novas percepções e para manter o consenso.

Outra ferramenta fantástica do gerenciamento de riscos é enfrentá-los, trazê-los para mais perto para saber se realmente são aquilo que você pensava. Isso está no coração do agile no desenvolvimento de software e do lean no que tange ao modelo de negócios como um todo. Quanto mais cedo e mais barato você lidar com seus riscos, melhor.

Escrevi este artigo porque gerenciamento de riscos tem sido vendido como uma ciência dominada por poucos escolhidos e realizada dentro de salas fechadas quando na verdade trata-se de uma atividade natural humana que deve ser realizada por todos os envolvidos o tempo todo.

Como dizia o Capitão Planeta, o poder é de vocês. Que tal se reunir com os envolvidos, fazer um brainstorm para descobrir os principais riscos e depois bater um bom papo sobre como lidar com eles?

A sua sanduicheira - vida pessoal - é fundamental, mas os riscos que afetam o seu trabalho também merecem atenção consciente.

Permalink | Leave a comment »

Cuidado com o sênior

Mon, 13 Feb 2012 06:05:00 -0800

A região metropolitana de São Paulo não chega a ser digamos, montanhosa, contudo existem algumas subidas que desafiam quem deseja utilizar a bicicleta como meio de transporte, principalmente para quem gostaria de chegar no ponto B sem suar além da conta.

Um desses desafios é chegar à Avenida Paulista. Em termos relativos ela está lá no alto e não importa por onde você chega: você precisa subir.

Eu sou considerado um ciclista experiente, talvez não pelo tempo que pedalo nas ruas de São Paulo (dois anos), mas pela distância diária e a freqüência, são 30 km todos os dias úteis para ir trabalhar. Minha bicicleta atual está beirando os cinco mil rodados o que me transformaria em termos relativos em um ciclista urbano pleno ou sênior.

Recentemente montamos um grupo de ciclistas geeks, uma galera muito alto astral, do bem que trabalha com informática (sim, isso é possível) e que está começando a pedalar pela cidade de São Paulo.

No nosso primeiro passeio montei uma rota que incluía o caminho que eu considerava “o menos pior” (uma vez que bom não existe) para subir à Paulista.

Passeamos pela Paulista, vimos as luzes de natal, descemos para o Ibirapuera ver a árvore e voltamos para a nossa avenida querida, foi muito divertido. Fizemos outros passeios depois desse, um na sexta-feira 13 e outro no aniversário de São Paulo.

Na semana passada o pessoal estava louco para fazer um passeio, mas eu não podia por causa de uma dor no joelho. Meus amigos insistiram, falaram que eu era o cara, mas eu sugeri que eles fossem sem mim.

Eles foram, se divertiram, superaram as dificuldades e descobriram um caminho ainda melhor para subir para a Paulista coisa de duas ruas distante do caminho que eu considerava melhor, mas que eu havia ignorado, talvez por simples acomodação.

Como eu prefiro validar as hipóteses ao invés de simplesmente discuti-las,hoje, segunda-feira, mudei o meu caminho, encontrei a rua e subi. Não é que é super leve, mão única e não tem ônibus?

A moral da história é que devemos ter muito cuidado com a palavra “Sênior”. Essa palavra não pode ser tomada como “aquele que sabe mais e que guia os outros”. Acredito que sênior no nosso ramo tem mais a ver com aquele que aprende mais e aplica o que aprende. O passado só tem importância se ele ajuda no presente.

A inovação está nas mãos daqueles que vão e fazem.

Permalink | Leave a comment »

A Cigarra e a Formiga

Fri, 16 Dec 2011 11:02:00 -0800

No bosque havia uma cigarra faceira, vivia cantando e batendo papo por aí, conversava com quase todos, menos com as formigas que passavam o verão todo carregando comida para seu formigueiro.

Um dia a cigarra abordou uma formiguinha e perguntou “por que você passa o dia carregando comida para sua casa?”, “para termos o que comer durante o inverno”, respondeu a pequenina, “e você faz o que mais da vida?”, “eu leio sobre como carregar mais comida por viagem, como e descanso para o trabalho do dia seguinte”, “sério? Uau, quer fazer uma pausa para tocar uma musiquinha e relaxar?”, “não posso, nossa metodologia de trabalho me impede de parar dentro do turno de trabalho, nem devia ter parado para falar com você, afinal, estou cheia de trabalho atrasado”, “belê então formiguinha, manda brasa aê”, disse a cigarra enquanto afinava o violão.

A formiguinha se foi levando cinqüenta vezes o peso do seu corpo nas costas e a cigarra queimou um paiero enquanto mandava ver numa milonga paraguaia para umas joaninhas que estavam por ali.

O verão se foi e o inverno implacável chegou. As formigas se trancaram no formigueiro quentinho e repleto de comida. Lá, tinham tudo o que precisavam, mas era um tédio. Como não havia muito espaço, podiam no máximo dormir, estudar ou escutar palestras motivacionais sobre coleta de alimentos.

A maior diversão das formiguinhas durante o inverno era esperar os outros insetos baterem na porta implorando por comida e abrigo, cada vez que um aparecia era um evento, elas sorteavam qual teria o privilégio de escolher se mandaria o bicho se catar ou se trocaria um prato de sopa quente por duas horas de discurso sobre a importância de se prevenir para o inverno.

Vários insetos apareceram e sofreram nas mãos das formiguinhas, mas a safada da cigarra não aparecia. Algumas formiguinhas chegaram a montar um bolão de apostas quanto ao dia e o estado no qual a violeira iria aparecer. “Aposto que vai até querer trocar o violão por comida” dizia uma, “hahaha” tergiversava a outra.

Mas nada... A primavera chegou, as formigas voltaram a trabalhar e nada da cigarra. O bolão agora era para apostar o dia e como ela havia morrido.

Ao procurar comida em uma rota conhecida a formiguinha ouviu ao longe um som familiar, parecia ser um chamamé, não que ela desse muita bola para estilos musicais. Para seu espanto, sim... Era a safada da cigarra, corada, sorridente fazendo um fandango para umas pulgas que estavam por ali esperando o cachorro das três.

A formiguinha correu em direção da cigarra com os olhos arregalados e perguntou “você está viva? Onde você estava? Te esperamos o inverno todo!!”, a cigarra jogou o paiero para o outro lado da boca, sorriu e respondeu “ahh, nem te conto, bati tanto papo por aí que acabei conhecendo um pato”, “ué, ele não te comeu?”, “não, fizemos um som juntos e ele acabou me apresentando a turma toda, aí quando o inverno chegou me perguntaram se eu ia voar para algum lugar tropical como eles para escapar desse frio, afinal, só otário para ficar por aqui nessa época”, “otário???? Tá tá, continua, e aí?”, “então, eu falei que minhas asinhas não me levam muito longe e não lido bem com o vento, então ele disse que me levava, mas eu tinha que ir tocando um som para animar a viagem”, “nossaaaa”, “pois é, a viagem foi muito boa, vi coisas que nem imaginava, ficamos quatro meses visitando praias lindíssimas e conhecendo uma bicharada muito louca”, “por que você voltou?”, “queria ver uns amigos, e matar a saudade, afinal, aqui é a minha terra né, e você? Como anda a vida?”, “ahhh, aumentamos a produtividade em 2,35% já na primeira semana”, “ahh, legal, só...”.

A formiguinha se despediu da cigarra e continuou a sua labuta.

A cigarra bateu forte com o pé no chão e perguntou “quem quer um forró? Aprendi na última viagem! e começou a tocar.

Permalink | Leave a comment »

Ouça a minha palestra do BA BRAZIL 2011 e acompanhe os slides

Fri, 02 Dec 2011 04:37:00 -0800

AN, Você Não Sabe o Que Está Perdendo! Métodos para Aproveitar ao Máximo o Potencial do Time de Desenvolvimento

O seu desenvolvedor inexperiente já é um usuário experiente. Como usuário, ele conheceu a Internet na sua infância (dele e da Internet), fez compras on-line, votou em urnas eletrônicas, usou redes sociais e provavelmente está começando a declarar o imposto de renda através de um sistema. Nesta palestra, discutiremos como criar um ambiente no qual o potencial dessa perspectiva única de “desenvolvedor-usuário” pode ser aproveitado no desenvolvimento de produtos de software. A empatia desse novo perfil de desenvolvedor, aliada à sua criatividade, pode encantar os usuários e simplificar a vida do analista de negócios.

Os slides estão sincronizados com o áudio:

AN, Você Não Sabe o Que Está Perdendo!

View another webinar from Claudio Kerber

Permalink | Leave a comment »

Faça a prova para CBAP em português

Wed, 30 Nov 2011 03:45:00 -0800

Após a tradução do BABOK 2.0 em português agora é a vez de traduzir a prova de certificação. Para que isso seja possível o IIBA precisa de um número razoável (acima de 50) pessoas interessadas em fazer a prova na nossa língua.

Se você tem interesse, entre nesse endereço http://www.iiba.org.br/PesquisaCert.php e informe os seus dados para que essa iniciativa vá para a frente.

Permalink | Leave a comment »

Dê a sua contribuição para a Extensão Ágil do BABOK

Tue, 08 Nov 2011 08:56:00 -0800

A Extensão Ágil do BABOK ou Agile Extension é um esforço conjunto de profissionais praticantes da análise de negócio em contextos ágeis no intuito de unir duas partes do desenvolvimento de soluções de software em uma visão comum: a descoberta e a entrega.

A descoberta (discovery) é o lado que literalmente "descobre" o que deve ser feito e porque, e a entrega, bem, a entrega é quem desenvolve e entrega o software.

O objetivo da extensão ágil é auxiliar quem está no lado da descoberta a visualizar e a entender a entrega e vice-versa uma vez.

Onde está o valor nisso?

Bem, tudo o que descobrimos do lado do problema são hipóteses. Acreditamos que alterar uma determinada interface dará um certo ganho, acreditamos que vender para a Argentina (o que implica em internacionalização dos sistemas) aumentará o faturamento em N, acreditamos que o relatório X ajudará o negócio a compreender melhor as variações na demanda e por aí vai.

O analista de negócios que conseguir validar mais rápido essas hipóteses correrá muito menos risco do que aquele que as estoca para serem validades em grandes pacotes.

Como ele faz isso? Intercalando descoberta e entrega através de metodologias ágeis.

Me arrisco (aqui sou eu e apenas eu falando) a dizer que em um modelo ideal, a entrega é componente da descoberta, a entrega realiza a descoberta, fecha um ciclo para iniciar o próximo.

Ficou interessado? Então você tem duas opções dependendo do quanto sobre isso você já sabe:

- Ler o draft da Extensão Ágil do BABOK para já ir aprendendo.

- Ler o draft da Extensão Ágil do BABOK para dar seu feedback e ajudar o pessoal a fazer um ótimo livro.

O download está nessa página, vai lá: http://www.iiba.org/imis15/IIBA/Professional_Development/The_Agile_Extension_of_the_BABOK/IIBA_Website/Professional_Development/Agile_Extension.aspx?hkey=c7942e53-b6fa-479e-a057-03a820596f02

O formulário de feedback está aqui: https://docs.google.com/spreadsheet/viewform?hl=en_US&formkey=dGtscUtIbVNFZmhGVE1faFZISktoZlE6MQ#gid=0

Permalink | Leave a comment »

AN, você não sabe o que está perdendo! Métodos para aproveitar ao máximo o potencial do time de desenvolvimento

Thu, 27 Oct 2011 12:09:00 -0700

Nesta palestra, discutiremos como criar um ambiente no qual o potencial dessa perspectiva única de “desenvolvedor-usuário” pode ser aproveitado no desenvolvimento de produtos de software. A empatia desse novo perfil de desenvolvedor, aliada à sua criatividade, pode encantar os usuários e simplificar a vida do analista de negócios.

Sexta-feira* 25/11 em Porto Alegre no

www.babrazil.com

* pode vir de camiseta e bermuda.

Veja aqui todas as palestras

Claudio Br é administrador de empresas com habilitação em marketing e trabalha com sistemas gerenciais e Internet desde 1997. Na sua história, valoriza a multiplicidade de experiências e os aprendizados conquistados nas mais diversas iniciativas.

Como entusiasta da análise de negócios, recorre a ela para promover ao mesmo tempo a visão do todo e a atenção aos detalhes. Dedicou-se à tradução do BABOK 2.0 para o português e escreve sobre o tema no seu blog (blog.claudiobr.com). Claudio Br é Agile Business Analyst no Grupo RBS em São Paulo.

Permalink | Leave a comment »

Refletindo sobre a frase de happy hour

Wed, 26 Oct 2011 05:05:00 -0700

No meio de uma conversa no Happy Hour Ágil na qual discutia os problemas intríncecos do conceito de "projeto" e como ele é incompatível com desenvolvimento de software, pregando a sua substituição pelo conceito de "produto" soltei essa:

"Projeto tem começo, meio e... foda-se"

Alguém já deve ter dito isso em algum momento (não encontrei no Google, se não está lá, será que existe?), mas foi muito espontâneo. Eu gosto das frases espontâneas, elas parecem vir direto do subconsciente que é bem mais esperto.

É uma frase forte*, mas passa a ideia do sentimento que temos ao entregar (quando conseguimos) o que o projeto se propôs. Como um projeto é uma iniciativa temporária de um determinado grupo de pessoas para atingir um resultado único, não há um cuidado com o que vem depois, mesmo quando há sucesso e ficar encadeando projetos é insano.

O aprendizado entre projetos é muito difícil, dado que equipes mudam e quem trabalhava no anterior quer se livrar do fardo e quem está começando o novo não tem vivência com o assunto para dar valor ou mesmo para compreender os ensinamentos. Toda uma cultura e linguagem se perde.

Eu prego o uso do conceito de produto, um produto visto como algo que nasce, atinge seu mínimo viável e evolui ao sabor do contexto no qual está inserido através das mãos de pessoas que possuem um relacionamento caloroso com ele.

Dessa forma, acredito que o menos pior projeto que pode ser feito é justamente um projeto de implantação do processo de criação e evolução do produto. Esse projeto tem como resultado o primeiro rascunho executável do processo**. Entregue esse rascunho, o projeto morre e tanto o produto quanto o processo entram em PDCA.

Em julho palestrei no TDC2011 na trilha de ALM falando sobre isso. Os slides estão longe de conter todas as informaçõees da palestra, mas dão uma boa ideia dos argumentos principais: http://blog.claudiobr.com/slides-da-palestra-vantagens-e-meios-de-conve

Aliás, em novembro vou palestrar no BABRAZIL em Porto Alegre. Não perca!

* tudo bem que esse verbo perdeu bastante do seu impacto dos anos 80 pra cá. Lembro que em 88, aos 10 anos eu fiz uso dele na mesa do almoço e fui duramente reprimido pela minha mãe que perguntou: "onde você aprendeu isso piá???" e eu respondi: "com o pai, quando ele falou como estava o trabalho no banco". Meu pai surpreso disse "eu não, eu não falei isso!".

** pensando bem, dá para fugir de um projeto ali também. Basta considerar que o processo é um produto em evolução (algo muito salutar) e instituir que a primeira versão do processo é o mínimo produto viável desse processo.

Permalink | Leave a comment »