PAULO FERNANDO VASCONCELLOS NOGUEIRA

Blog

  • Museu de Grandes Novidades

    Finalmente encerro a série de artigos onde tentei transcrever a palestra “O Futuro Não é Mais como Era Antigamente“. Este trabalho foi desenvolvido para o Seminário Engenharia de Software promovido pela Tempo Real Eventos. Para minha surpresa ele foi encomendado por algumas empresas, o que resultará em sua promoção para o status de Produto. Não do finito, mas de seu co-irmão que está brotando das cinzas com renovados propósitos. Assunto para outra hora.

    Hoje quero falar sobre o terceiro e último módulo daquela palestra, sobre o nosso “Museu de Grandes Novidades”. O primeiro módulo falava de pessoas e times e foi registrado aqui nos artigos “O Clube da Esquina Globalizada” e “O Cubículo Global“. O segundo tratou de tecnologias e arquitetura corporativa, tema que mereceu duas entradas: “(Pensando Alto sobre) Arquitetura Corporativa” e “Arquitetura do Negócio“. O prato quente é servido no final e o tal “Museu” foi a figura selecionada para puxar assunto sobre processos (metodologias) e projetos. Sim, eu esperava reações ruins entre as boas e indiferentes: “No size fits all!” Aliás, quem abre o tema com o slide abaixo não pode esperar coisa muito diferente, né?

    O “outras relíquias” do título indica a existência de um slide anterior. Verdadeira jóia: a certidão de nascimento do modelo ‘Cascata’. Mas, peraí: queria eu requentar debate tão chato e batido? Não era a intenção. E tento aplacar ânimos dizendo se tratar de um ‘Museu’, não de uma lixeira. Guardamos em um museu coisas que merecem ser vistas, lembradas e estudadas. Mostramos em um museu peças que têm valor. Preciso reforçar a questão que repeti várias vezes na palestra e que rotulei como ‘retórica’ (só pra tentar provar o contrário): nossas teorias (sobre engenharia de software) resistem ao confronto com as pessoas e tecnologias de hoje? Quantas ou quais sobreviveriam de fato? Minha cara e meu caro, se eu tivesse a resposta não estaria aqui, gastando o seu e o meu tempo.

    Também não se trata da elucubração isolada de um mineiro de Varginha que desfila lorotas nas horas vagas. O SEMAT (Software Engineering Method and Theory), que tem entre seus signatários algumas das pessoas que mais contribuíram com a área em todos os tempos, afirma com todas as letras em sua “chamada para a ação” que aquilo que conhecemos (conhecemos?) sobre engenharia de software encontra-se num perigoso e escuro mato sem cachorro porque:

    • Está repleta de modas e tendências, coisa que não combina com *engenharia*;
    • Está carente de uma base teórica forte e amplamente aceita;
    • Está abarrotada de métodos e variações com diferenças pouco compreendidas e artificialmente aumentadas;
    • Está pobre-pobre-pobre-de-marré-marré-marré em termos de avaliações e validações. Cada um fala que seu “método” funciona e pronto; e
    • Há uma divisão entre práticas da indústria e pesquisas da academia.

    Não consigo pensar em nenhuma outra área do conhecimento humano que tenha passado por algo semelhante. Repare bem: um grupo de pessoas que escreveu os livros e nos ensinou engenharia de software nos últimos 40 anos concordou com um diagnóstico nada favorável do nosso estágio atual. Repare também que entre os signatários existem representantes de todas as “escolas” relevantes, da extrema-direita até a extrema-esquerda. Hã.. ok. Alguns caras da extrema-esquerda que inicialmente concordaram com o diagnóstico tiraram o time de campo quando viram que o papo centro-direitista não os agradaria nem um pouco. Não importa. E também não creio que o SEMAT, pelo andar da carruagem, gere algum resultado. Mas o estrago está ou deveria estar feito. Ou alguém não concorda com o diagnóstico apresentado?

    .:.

    Definitivamente, minha intenção não é promover o bilionésimo papo besta sobre “cascateiros X agilistas”. Acontece que, tanto no evento aberto quanto em um fechado, teve gente que se sentiu pessoalmente atacada pelo conteúdo e, desconfio, pelo tom utilizado.

    Uma pessoa que participou da edição fechada desta palestra no último dia 9/11 manifestou enorme descontentamento com o evento. Detalhe: ela registrou sua insatisfação na forma de um comentário no último artigo publicado. Outros detalhes: utilizando nome falso, insinuando uma insatisfação geral e, indevidamente, registrando um link para o site da empresa contratante. Empresa que solicitou a remoção do comentário ou, no mínimo, do link que a identificava. Nunca cogitei a censura ao comentário (blog que é blog não modera nem censura). Mas, claro, retirei a referência para a empresa. Pela atenção, pelo time e pela rapidez na resposta, a empresa não merecia ver seu nome associado a comportamento tão feio e desonesto.

    Já fui atacado de quase tudo quanto é jeito pelas ideias que defendo e pelo que critico. Na grande maioria das vezes o ataque ou resposta, mesmo os mais agressivos, não é covarde. Não é anônimo. É o mínimo que se espera, certo?

    .:.

    Já escrevi por aqui que esta palestra é uma coletânea de temas que, por vários motivos, repousavam em minha gaveta. Pra ser sincero, não acreditava na viabilidade dos temas (em termos econômicos e políticos, hehe). Estouro champanhe quando erro assim. Além da apresentação para quase 100 profissionais de uma mesma empresa, ontem tive a chance de levar o mesmo papo para um território que parecia ser, no mínimo, inusitado. Ganhei um belíssimo presente da Profa. Renate Landshoff: a oportunidade de apresentar “O Futuro não é mais…”  para duas turmas do curso de graduação em Biblioteconomia da FESPSP (Fundação Escola de Sociologia e Política de São Paulo). Além da bela e antenada turma, contei com a enriquecedora presença de Sérgio Storch. Não vou tentar explicar agora o exótico mashup que se desenha. Mas algumas pistas você encontrará neste artigo da Profa. Renate (e respectivos comentários).

    “Beans“, a foto utilizada neste artigo, é de autoria de Naomi Ibuki e foi obtida no Flickr.

  • O Dono do Produto

    Tão ou mais complicado do que criar o produto – em meu caso, um treinamento – será o trabalho de ‘criar’ uma freguesia para ele. Sei que o FDP¹(Formação de Donos de Produtos) atrairá gente letrada e com experiência em projetos de software. Ok. Entendo que a maioria delas não vai desempenhar o papel e sim apoiar e orientar os profissionais que o farão. O treinamento deve contemplar esta modalidade de uso e o faz². Mas eu também sei que o evento não será legal se não contar com “não-letrados”, gente que não seja de TI e sim do negócio. Este treinamento foi desenhado principalmente para eles, nossos (frequentemente) mal compreendidos e (invariavelmente) mal tratados usuários. Ok, sei que não vou atrai-los com demagogia barata. Antes de mais nada, é preciso explicar melhor quem é esse tal de Dono do Produto (ou Product Owner), o que ele faz, como, porque etc. É o que tento com este artigo.

    .:.

    O dono do produto é O Cara. O cara que deve gerenciar o escopo de um projeto e garantir que o produto criado realmente gerará valor para o negócio. Do glossário oficial não consta o termo “escopo do projeto” e sim “Product Backlog”. Aqui, para desagradar a gregos e troianos, vamos chamar esse trem de Pauta. Antes que você tenhas ideias criativas e/ou nocivas, retomemos o fio da meada. O dono do produto, como o próprio nome confessa, tem a palavra final sobre funcionalidades, características e formato da obra gerada pelo projeto. E, acima de tudo, ele deve garantir que o produto atenda os objetivos pré-estabelecidos, ou seja, que ele gere valor. Peço sua atenção para o termo “pré-estabelecidos”. Obrigado. Já já conversaremos sobre isso.

    O dono do produto (DP daqui pra frente) deve ser do negócio. Aqui temos duas possibilidades. Se o produto destina-se para uso interno, então o DP será um representante de todos os usuários. Dele será exigido domínio do problema que o produto ajudará a resolver. Ele será escolhido não só pelo (amplo e profundo) conhecimento que detém, mas também pelo bom relacionamento com todas as outras partes interessadas. Deve ser reconhecido e merecedor da autonomia que receberá.

    Quando o produto é dirigido para o público externo, então o DP pode ser o próprio gerente do produto, quando existir, ou então um representante da área de marketing da empresa. É interessante notar que neste contexto o DP, na maioria das vezes, não cuidará de apenas um projeto mas de todo o ciclo de vida de um produto. Desconfio que seja uma possibilidade pouco aproveitada em solo tupiniquim.

    Do DP espera-se autoridade e autonomia em todas as decisões sobre o escopo do produto e as prioridades do projeto. Dele será cobrada disponibilidade para atender os demais membros da equipe do projeto. Recomenda-se que ele dedique, no mínimo, uma hora por dia ao projeto.

    Um DP por Projeto – Um Projeto por DP

    Por óbvio que pareça, é preciso dizer que cada projeto, cada produto tem um e apenas um dono. Invertendo a equação pisamos em terreno não tão óbvio: um DP deveria cuidar de apenas um projeto. Dois, no máximo. E desde que sejam pequenos. As empresas de Pindorama têm a péssima mania de jogar em seus profissionais uma carga de trabalho exagerada. Os profissionais de Pindorama têm o péssimo costume de tentar equilibrar em seus ombros uma carga de trabalho muito além de sua capacidade de entrega. Daí a relevância deste parágrafo.

    Um ponto não tão claro que só agora ganha a devida relevância é a solidão do DP. Segundo algumas interpretações, esta seria função de uma só pessoa. Uma visão mais prática e pragmática nos abre outras possibilidades. O DP pode ser uma pessoa sem disponibilidade para entrevistar n usuários, detalhar n cenários, responder n dúvidas do time etc. Pode ser muito n para uma pessoa só. Por isso autores como Jim Highsmith e Roman Pichler sugerem a existência ou necessidade de um Time do Produto³. Este time, como já foi apresentado aqui no finito, pode ser composto por analistas de negócios, consultores, especialistas no domínio e outros usuários ou partes interessadas. Cabe ao DP manifestar a necessidade de apoio. E ele não pode ser constrangido por dogmas bobos. Ele é o *dono* e, como tal, deve saber do que precisa para fazer seu trabalho bem feito.

    Colocado e Falante

    De boa que é, merece repeteco uma afirmação que fiz em artigo recente: “é o olho do dono que engorda o boi”. Colocando de outra forma: não há DP distante ou remoto. No mundo ideal ele ocupa a mesma sala dos outros integrantes do time. No mundo real ele deve visitar esta sala pelo menos uma vez por dia. E permanecer lá, à disposição e sem interrupções (celular desligado, please!), por pelo menos uma hora.

    Quando apostamos na figura de um DP estamos fazendo uma aposta bem maior: no valor do conhecimento tácito, na eficácia das conversas. Ou, como colocou um freguês, “estamos trocando 10 páginas de documentação por 10 minutos de prosa”. Se o DP não tiver disponibilidade e não for onde o time está não há conversas. Se elas não ocorrem então perdemos a aposta. Simples assim.

    O Passo Esquecido

    Este é o título de um dos capítulos do FAN. Descreve aquele fundamental e mal tratado momento que ocorre entre o entendimento de um problema e o desenvolvimento de sua solução. Aqui ele ganha escopo mais amplo. Trabalhos clássicos que ajudaram a criar e definir o papel do DP – como “Agile Project Management with Scrum“, de Ken Schwaber (Microsoft Press, 2004) – partem de uma visão do produto já definida. Sim, agora estou falando sobre aqueles “objetivos pré-estabelecidos” para os quais chamei sua atenção lá no início do artigo. É razoável supor que o DP participará da criação da visão do produto do qual é *dono*, não? Não me pergunte porque aqueles trabalhos ignoram este momento. Eu não saberia responder. Não sem uma considerável dose de veneno.

    Os conhecimentos do DP são mais exigidos nos momentos iniciais do projeto. Será um sinal de sanidade do projeto a decrescente dependência dos outros membros do time em relação ao DP. Significará que o conhecimento realmente se espalhou pela equipe. Todos passarão a demonstrar de razoável a impecável domínio do problema que tentam resolver. O que não pode significar, de forma alguma, o afastamento ou distanciamento do DP. Ele sempre terá responsabilidade pela manutenção e priorização da Pauta do projeto, do primeiro ao último dia do projeto. E, claro, é ele quem aceita ou não o resultado de cada iteração (ou sprint).

    Os Passos Executados

    Como já vimos, o DP tem duas grandes responsabilidades em um projeto: i) Definir a Visão do Produto e respectiva Pauta – funcionalidades e características de um produto. Fica subentendido aqui que a Pauta é formada por itens devidamente priorizados e que a priorização também é responsabilidade exclusiva do DP; e ii) Garantir que o produto em gestação está definitivamente a caminho de realizar os objetivos do negócio. Cada responsabilidade compreende um conjunto de atividades que fica a cargo do DP.

    A Pauta (lembre-se, o Product Backlog segundo gramáticas oficiais) deriva da Visão do Produto. A criação de ambas é responsabilidade do DP. Espera-se que a Visão, normalmente de alto nível (2km X 2cm…), seja estável durante todo o projeto. Ela explica funcionalidades e características gerais do produto, além de oficializar restrições (escopo, prazos e custos). A visão deve mostrar, principalmente, como o produto gerará valor para o negócio.

    Já a Pauta será desenvolvida de maneira iterativa e incremental. O DP e o time se preocuparão em detalhar apenas os itens necessários no horizonte pré-fixado (da iteração ou sprint). Uma iteração geralmente dura duas ou quatro semanas. Projetos estressados (complexos em sua porção negócio ou tecnologia ou ambas) devem utilizar a primeira opção. Projetos tranquilos se contentam com a calmaria dos ciclos de trinta dias. Espera-se que o DP (e seu opcional Time de Produto) esteja trabalhando no entendimento e detalhamento dos itens que comporão a pauta da iteração imediatamente posterior. Particularidades do projeto, da organização ou a velocidade do time podem pedir que o DP trabalhe com duas ou até três iterações de antecedência. É importante notar que isso não pode significar, em hipótese nenhuma, o não atendimento do time na iteração atual – dirimindo dúvidas e verificando a realização do produto, principalmente.

    Praticamente todos os proponentes de métodos que utilizam a figura do DP sugerem que os itens que compõem a Pauta sejam redigidos na forma de Histórias de Usuários (ou User Stories). Este padrão “força” a realização de conversas. É importante que o DP saiba que existem alternativas (casos de uso, por exemplo) e que ele deve optar pelo formato que lhe deixe mais confortável. Algumas organizações precisam de um pouco mais de formalidade (aka Documentação), por razões mil (sendo que 989 são bullshitagem/burocracia pura). Dependendo de suas exigências, parte do time pode ser destacado para atendê-las. Colocando de outra maneira: da porta (da sala do time de projetos) pra fora é oferecida uma documentação mais formal; Da porta para dentro o time pode optar por um padrão de conversas mais informal e leve. Um bom DP saberá lidar com as duas modalidades de comunicação.

    Em inglês fala-se que o DP é responsável por “grooming the product backlog”. Em tradução literal o verbo groom significa preparar, arrumar (ou adestrar cavalos). Acho que, em português, devemos nos contentar com o termo “manutenção da Pauta”. É crucial que o DP saiba que a Pauta é um (documento? artefato? ferramenta? – são tantos termos detestados, tantas emoções desperdiçadas…) Começando de novo: É crucial que o DP saiba que a Pauta é um trem vivo – um negócio que exigirá sua atenção diária. Itens da Pauta (requisitos, histórias ou casos ou…) ganharão ou perderão prioridade; mudanças surgirão (e não serão tratadas como más notícias); erros serão cometidos (e não significarão pena de morte aos seus causadores). Se o DP não administrar (!) diariamente todas as ocorrências as quais estão sujeitas a sua Pauta, me diga: que p%&R@ o cara está fazendo lá?

    Aos Donos com Carinho

    Por tudo isso e mais um tanto é que se diz que a função do DP é a mais crítica e complexa em um projeto guiado pelo framework Scrum. A vida de um DP não é nada fácil. Mas pode ser muito gratificante e edificante (Houaiss: que conduz à virtude). Quem já entregou projetos e viu os olhos dos usuários brilharem (e seus respectivos negócios lucrarem) sabe do que estou falando. A entrega de um produto pelo DP guarda uma satisfação ainda maior, exatamente porque foi ele quem desenhou e de certa maneira conduziu aquela realização. O bom DP sabe que o sucesso deve ser compartilhado por todos que participaram do projeto. Mas lá no fundo ele guarda algo que não confessará: a impressão digital mais notável deixada no produto é sua. Para o bem ou para o mal.

    .:.

    Observações:

    1. Foi em um belo boteco de Copacabana, bem servido de chopps, que consegui convencer meu parceiro de que a sigla FDP é filhadaputamente excepcional para uma oficina que se propõe a Formar Donos de Produtos. Além do apelo pop, serve também para peneirar e manter chatos ultrasensíveis bem distantes. Quem não güenta o leve tranco d’uma brincadeira boba demonstra não possuir um requisito mínimo que todo DP deve apresentar: bom humor!
    2. Faço questão de frisar na divulgação do FDP que todo o material didático utilizado está liberado para uso. As restrições são mínimas: i) Agradeça publicamente o autor; ii) Compartilhe o material utilizando a mesma licença; e iii) Se você pretende ganhar algum $ com o material, combine antes a comissão que irá me pagar. Preciso salientar isso porque sei que muitos vão querer replicar o treinamento em suas empresas. Em breve vou mostrar aqui no finito alguns dos itens que vão compor aquilo que estou chamando de “Kit do PO moderno” e que você poderá reutilizar.
    3. De longe já são os dois livros mais citados aqui no finito: “Agile Project Management – Second Edition“, de Jim Highsmith (Addison-Wesley, 2010) e “Agile Product Management with Scrum“, de Roman Pichler (Addison-Wesley, 2010). Se eu seguir referenciando-os assim periga eu te dispensar de estudá-los. Hehe.. brincadeira.
    4. Aproveitei o artigo para experimentar mais um pouquinho o método do Pensamento Visual. A sequência utilizada para apresentação do DP – quem, quanto, onde, quando, como e porque – obedece as regrinhas dos 6 W’s propostas por Dan Roam em “The Back of the Napkin” (Portfolio, 2008).
    5. A foto utilizada no topo, “Home Market: 1941 in Worthington, Ohio“, é do Don O’Brien.

    Faltou dizer:

    Caramba, ainda estás por aqui? Este artigo está com o dobro do tamanho padrão (2200 palavras!). Mas faltou dizer… Que o DP não é uma exclusividade dos projetos que são guiados pelo framework Scrum. Aliás, não precisa ser uma exclusividade. Ele é uma adaptação, por exemplo, do Engenheiro-Chefe utilizado pela Toyota há décadas. Pode ser visto também como uma exótica e criativa remixagem das funções do gerente de produtos e do gerente de projetos.

    É claro que, apesar das “licenças poéticas”, baseio boa parte de minhas sugestões no DP conforme definido na gramática oficial do Scrum. Mas preciso dizer que a idéia do DP, de boa que é, não deve ficar limitada ao uso do Scrum. Pronto, disse. Inté!

  • 11 Livros “Obrigatórios”

    Desconfio que listas só são elaboradas para criar polêmicas. Falta de assunto? Talvez. Listas de melhores filmes, músicas ou discos, por exemplo, sempre conseguem mais discordâncias do que aprovação. Natural que seja assim, afinal cada um tem seus gostos e desgostos. Mas é muito difícil justificar ou explicar uma lista que se apresenta como “10 Livros Obrigatórios para Executivos“. O problema começa com o termo ‘obrigatório’. E termina com uma lista sem lógica e com alguns títulos no mínimo questionáveis. Não estou julgando o valor ou a qualidade dos textos sugeridos, mas sua ‘obrigatoriedade’. Qual era a intenção, afinal? Recomendar leituras básicas para executivos? Se sim, então peço licença para apresentar minhas sugestões.

    Os Bruxos da Administração
    John Micklethwait e Adrian Wooldridge (Campus, 1998).

    O subtítulo diz tudo: “Como entender a Babel dos gurus empresariais”. Funciona como um guia para a leitura de livros de negócios, particularmente daqueles já apresentados como ‘clássicos’. Aqui você entende porque deve desconfiar das dicas e conselhos de recordistas de vendas como Tom Peters (de “Vencendo a Crise” e “Re-imagine”, dentre vários outros) e Stephen Covey (aquele dos “7 Hábitos das Pessoas Muito Eficazes” e derivados). Os autores fazem parte do time de editores da revista The Economist, famosa por sua independência (de verdade, não a falsa imparcialidade de algumas famosas publicações tupiniquins).

    Desafios Gerenciais para o Século XXI
    Peter Drucker (Pioneira, 1999).

    Como justificar uma lista de livros de negócios que não tenha um título do Mestre? Complicado. E não estou falando dos trabalhos clássicos (aka antigos) do Drucker. Ele nos deixou em 2005. Antes, publicou ensinamentos importantes para os novos tempos, particularmente neste “Desafios…” Gerência, estratégia, mudanças, produtividade do trabalhador do conhecimento e “gerenciar a si mesmo” são alguns dos temas. O subcapítulo chamado “Do ‘T’ para o ‘I’ em ‘TI’” é de particular interesse para todos que por aqui passeiam.

    Reengenharia – Revolucionando a Empresa
    Michael Hammer e James Champy (Campus, 1994).

    Como assim, “Reengenharia”? Livro, autores e proposta não foram considerados o grande desastre do mundo da administração no final do século XX? Sim. Cometeram uma carnificina escondidos na teoria da reengenharia. Mas a culpa dos autores foi exagerada. Não importa. Acontece que esta é a primeira obra a colocar processos de negócios em seu devido lugar (no topo da agenda de preocupações). Hoje, quando vemos tantos BP* por aí, vale a pena ler ou reler os conceitos originais de Hammer e Champy. E aplicá-los? Com moderação sim, por que não?

    A Execução Premium
    Robert Kaplan e David Norton (Campus, 2009).

    Poderia citar três ou quatro trabalhos de Kaplan, do ABC (Custeio Baseado em Atividades) aos Mapas Estratégicos passando pelo BSc (Balanced Scorecard). Costumo dizer que ele ajudou a criar algumas das principais ferramentas administrativas dos últimos 20 ou 30 anos. Neste título temos a oportunidade de rever seus trabalhos. Não numa espécie de coletânea, mas mostrando como as operações podem ser guiadas por estratégias bem formuladas e muito bem comunicadas.

    A Economia da Informação
    Carl Shapiro e Hal R. Varian (Campus, 1999).

    Título que já apareceu por aqui, em nossa biblioteca. Leitura essencial para a compreensão da (velha) economia dos novos tempos. Lê-se no subtítulo: “Como os princípios econômicos se aplicam à era da Internet”. Não serviu para evitar a bolha do ano 2000. Mas servirá para você não atuar como um bolha na hora de administrar e precificar seus ativos de conhecimento. Este livro ganhou por pouco de “Capital Intelectual“, de Thomas Stewart (Campus, 1999). Mas isso aqui não é corrida. Leia ambos!

    O Novo Jogo dos Negócios
    Shoshana Zuboff e James Maxmin (Campus, 2003).

    O título original é “The Support Economy”. A Campus não deveria ter cometido esta infeliz ‘tropicalização’. A Sra. Zuboff, professora na Harvard Business School, e seu marido, ex-CEO da Volvo, escreveram um verdadeiro manifesto para um novo Capitalismo. Todos que queiram entender o mundo que se desenha deveriam folhear estas páginas. Com calma – são quase 500. E três grandes temas: i) Desafio: Novas Pessoas, Novos Mercados; ii) Crise: Velhas Organizações se encontram com novas pessoas; e iii) Surgimento: A nova lógica empresarial. Texto surpreendente e contundente.

    O Futuro da Administração
    Gary Hamel com Bill Breen (Campus, 2008).

    Parece que Hamel quer se tornar o Peter Drucker do século XXI. Está no caminho certo. Neste livro ele fala especificamente sobre os processos de gestão e conta porque eles são a última fronteira da administração. Antenado, fugiu bem da perigosa palavrinha “governança”. Sabe que o buraco é mais embaixo. E se preocupa, por exemplo, com a criação de “comunidades de objetivos” e “democracia de inovação”. Não, a exemplo do título anterior, não se trata de uma obra neo-hippie. É administração moderna mesmo. A última do Hamel, não disponível ainda na forma de livro texto, é dizer que “colaboradores são mais importantes que os clientes”. Vem chumbo grosso por aí.

    Virando a Própria Mesa
    Ricardo Semler (Rocco, 2002).

    E por falar em chumbo grosso… Pelo menos um autor tupiniquim merece um lugar na lista. E não poderia ser outro se não o Semler. Mês passado este título foi colocado em nossa biblioteca. Mais que merecido. Afinal, são pouquíssimos os autores realmente práticos e inovadores. Aqueles que fazem da própria empresa a base para estudos são mais raros ainda. É uma pena que Pindorama aproveite tão pouco o potencial desse cara. Lá fora eles sabem aproveitar. Por exemplo…

    REWORK
    Jason Fried e David Hansson (Crown Business, 2010)

    Os autores citam e agradecem Semler neste livro. Não é por menos: suas ideias ‘radicais’ são muito inspiradas nas experiências e proposições do Ricardo. O que me deixa curioso em saber se um dia eles já se encontraram. O livro, o único desta lista ainda não disponível em PT-br, fala da vida, do universo e tudo mais. Falando sério: marketing, estratégia, produtividade, concorrência, pessoas e cultura, dentre outros assuntos. É uma REvisão do mundo da administração sob um ponto de vista ímpar e inovador. Trocando em miúdos, um sutil e necessário tapa na cara.

    O Futuro não é mais o mesmo
    Seth Godin (Campus,  2007).

    Revendo a lista pensei – pô, falta um livro de marketing. Apesar do tema aparecer em alguns trabalhos relacionados, queria ter um título só de marketing. Vou fazer mais que isso e citar O Cara de marketing que mais admiro e cito, Seth Godin. Seu livro é sobre o futuro e “182 outros paradoxos do mundo dos negócios”. Não espere uma leitura natural e linear. O livro compila o resultado de seis anos de publicação em um blog. E Seth cometeu o disparate de colocar os “paradoxos” em ordem alfabética. Por isso ele alerta: “Não leia este livro de uma vez só”. Não faria muito sentido. Deve ser saboreado como uma boa cachaça mineira, com moderação e aos pequenos goles.

    O Princípio Dilbert
    Scott Adams (Ediouro, 1997)

    E nenhuma lista é completa sem um item que a (con)teste ou renegue de alguma maneira. Feijoada sem a laranja não é completa. Se você vai listar discos, por exemplo, precisa contrapor Led Zep ao Clash. Cidadão Kane também não é o mesmo sem a oposição de Cães de Aluguel (ou Titanic, blergh!). Por isso nosso querido Dilbert encerra esta lista, com seu primeiro e principal título. Administração e negócios podem ser engraçados. Aliás, eles são engraçados! Mas não é todo mundo que sabe contar piadas. Scott Adams sabe e por isso o seu trabalho é tão duradouro (e necessário).

    .:.

    Desde que vi a lista da EXAME fiquei ansioso para publicar a minha (juro, não por falta de assunto). E repito: não estou dizendo que os livros lá recomendados são ruins ou algo do tipo. Aliás, tem uns 2 ou 3 livros lá, como “Estratégia do Oceano Azul”, que quase ganharam a 2ª divisão aqui. Acontece que alguns trabalhos ficam mais que seis meses na lista de recomendações – não são voláteis como álcool ou etanol. Acredito que seja este o caso de todos que citei aqui (inclusive REWORK, que é deste ano).

    O sumido Braga de Brotas vivia me dizendo que não via muito sentido nos livros sobre negócios e administração. Provavelmente ele baseava seu julgamento nos 99,75% de puro lixo e modismo que vemos na prateleira assim denominada. Aliás, êta prateleira bagunçada. Na Folha de São Paulo, por exemplo, é apresentada a lista dos mais vendidos em “Negócios e Auto-ajuda”. Pobre e infeliz aquele que não consegue separar as duas coisas. Inté!

  • Scrum kanbanbanban balangandã

    Conclusão do papo iniciado em “Scrum praticundum burungundum“¹. Naquela primeira parte tentei ilustrar a crescente adoção do Scrum em Pindorama. O texto de hoje se ocupará dos principais problemas enfrentados, possíveis causas e soluções. É necessário lembrar que minhas conclusões não estão baseadas em uma pesquisa estruturada. Elas são fruto de conversas e consultas informais.

    .:.

    O Scrum, pequeno e simples que é, não deveria ter significados diferentes para as pessoas. Quando alguém me diz que está adotando o Scrum, minha primeira pergunta é: “Scrum e?…” Muitos interlocutores não entendem a questão. Ignoram o fato de o Scrum orientar apenas o processo de gestão de um projeto. Uma parte deles está de fato adotando derivações ou até mesmo o XisPê (eXtreme Programming). Outra parte descobre depois de um tempinho que “tá faltando um monte de definição”. Alguns deixam que a equipe técnica selecione suas práticas favoritas ou que trabalhem como os Allman Brothers, em puros e longuíssimos improvisos. Nada disso se configura um problema se combinado previamente. No entanto, no mínimo para não falar besteiras, é bom saber o que vem do Scrum e o que foi importado de outros lugares.

    Um dos exemplos de “práticas importadas” são as User Stories (ou histórias de usuários). O Scrum não diz como deve ser explicitado o backlog do produto nem como devem ser redigidas as necessidades dos usuários. Autores como Jim Highsmith, Mike Cohn e Roman Pichler² manifestam sua preferência pelo padrão User Story. Sua natureza evolutiva “combina” melhor com o Scrum e com métodos ágeis em geral. Acontece que muitos acreditam que esta seria a única maneira de registrar os requisitos do negócio ou dos usuários, o que não é verdadeiro.

    Mas o que realmente importa é a necessidade de *completar* o Scrum com práticas de engenharia. E aqui deveríamos ver variações mil. Por quê? Oras, organizações, equipes e projetos têm necessidades e restrições bastante específicas. O chapéu Scrum, largo e leve que é, pode caber em qualquer cabeça. Mas seu complemento demanda cuidado. Um zelo que tem faltado em algumas implementações.

    E por falar em implementação. Qual a melhor estratégia? Implantar o Scrum em toda a organização em uma tacada só ou, como um bom e legítimo mineiro, promover uma adoção gradual (comendo quieto e pelas beiradas)? Sou mineiro. E quanto mais conservador ou desestruturado for o ambiente, mais lento é o ritmo que recomendo. Aposto nos hábitos e gostos que são desenvolvidos de maneira natural e orgânica, sem imposições. Deveríamos acreditar mais no potencial das boas ideias que são incorporadas – aprendidas de verdade – através de bons exemplos. Mesmo em organizações que precisam ou merecem radicais safanões, é complicada a implantação do tipo big-bang. Só o exorcismo do espírito Waterfall (cascata), que assombra por anos ou décadas, já é um trabalho e tanto. Representa uma mudança que raríssimas vezes pode ser classificada como simples ou sem traumas. Resumindo: é mais fácil adotar o Scrum de maneira gradual. Poucos casos, como o da Salesforce.com documentado por Mike Cohn em “Succeeding with Agile” (Addison-Wesley, 2010), justificam outra estratégia.

    E por falar em cascata. Não é que tem gente que fala que tá usando o Scrum mas manda um analista lá no cliente para “levantar *todos* os requisitos”? Gente que depois compila isso tudo numa proposta com escopo, preço e prazo fechados? Isso sim pode ser julgado como pecado mortal – um crime premeditado. Mas, guarda o fósforo menino! Não é questão de jogar hereges na fogueira. Uma das perguntas mais frequentes que ouço é exatamente sobre isso: como um prestador de serviços vende um projeto baseado no Scrum? O assunto é tão espinhoso e controverso que merecerá um artigo (ou série) só para ele.

    Outro ponto que facilmente se converte em discussão é o autogerenciamento pelo time do projeto. Existem duas interpretações principais: i) o time cuida de tudo e decide tudo; ii) “autogerenciamento não significa falta de liderança mas um estilo diferente de liderança”, escreveu Jim Highsmith na segunda edição de “Agile Project Management“ (Addison-Wesley, 2010). Sou ignorante pra burro (hehe) e conheço pouquíssimos casos da história da humanidade que comprovem a viabilidade da primeira opção. Pra citar assim, de cabeça, só o caso da Democracia Corinthiana, que durou cerca de dois anos (1982-83). Ainda assim, garanto que a leitura da última frase lhe trouxe lembranças do Dr. Sócrates, Casagrande e Vladimir.

    Henrik Kniberg e Mattias Skarin colocam em “Scrum e Kanban – Obtendo o Melhor de Ambos” (InfoQ, 2009) que “o Scrum é suficientemente minimalista tal como é, se você remover coisas e continuar chamando isso de Scrum a palavra ficará sem sentido e confusa”. Porém, nada nos impede de “colocar coisas” no Scrum. Parece ser o que fez Jim Highsmith no livro  já citado. Ele coloca a figura de um líder de projetos. Estranhamente, sem usar o termo Scrum. Sei lá se por respeito ou qualquer outro motivo. Também precisamos considerar um aspecto cultural: o brasileiro parece gostar de líderes e de ser liderado. Não é o caso de discutir se isso se dá por preguiça, submissão ou letargia (que é a preguiça chique). Ou é (o caso de discutir isso)? Sei lá.

    Outra pergunta de meu informal check-list: “Você confia em seu PO? Ele tem a palavra final sobre o escopo do projeto?” Espanta o número de vezes que ouço um “não” como resposta. Um “não” que algumas vezes nem tem noção do tamanho de engano que representa. Se há um termo muito feliz³ criado no Scrum é Product Owner (PO) – *Dono do Produto*. “Dono” dispensa explicações. Quando um dono não tem palavra final então ele não é dono de nada. Não existe meio dono.

    Existe um dito popular que ensina que é “o olho do dono que engorda o boi”. Adaptado para nosso caso, podemos dizer que é “o olho do PO que garante a entrega do produto”. E o que dizer dos PO’s indisponíveis, daqueles que não têm tempo para olhar o boi?

    E que dizer dos PO’s que não são do negócio? O que dizer dos PO’s?

    Outro dia eu digo. Inté!

    .:.

    Observações:

    1. Sigo firme na tradição dos títulos ridículos. Mas desta vez escondi ali uma provocação. Se surtiu efeito eu não vi. Chamei o artigo anterior de “Scrum praticundum burugundum”. A rima (!) só é possível se a pronúncia estiver errada. É  que eu ouço “ScrUm” com mais frequência que  “ScrÃm” (ou “Scrammm”). Fecho a provocação (mas não a tradição dos títulos ridículos) com o “Scrum kanbanbanban balangandã” de hoje.
      E não, (ainda) não tenho a intenção ou condição de falar sobre o Kanban. Dele só aproveitei a rima mesmo. Se o tema lhe interessa, aquele livro aberto e gratuito citado é uma boa dica.
    2. No próprio texto já referenciei os trabalhos de Highsmith e Cohn. Faltou citar o livro do Roman Pichler, “Agile Product Management with Scrum” (Addison-Wesley, 2010). Um dos poucos dirigidos especificamente para PO’s.
    3. Não sei se você sabe, mas os termos criados para o Scrum são intencionalmente “infelizes” ou “ruins”. Ruins no sentido de serem bastante diferentes daqueles utilizados tradicionalmente: Product Backlog, ScrumMaster, Product Owner, Sprint Backlog… A sacada do vocabulário original e radical é boa porque evita confusões. Bom, deveria evitá-las…
    4. “Battle against Time”, a bela foto que ilustra o artigo, é do Joakim Jardenberg.

  • Scrum praticundum burungundum

    A crescente adoção do Scrum por empresas tupiniquins chega a ser surpreendente. Seu uso por pequenas e médias empresas da indústria digital é facilmente justificável. Mas quando vemos grandes negócios – de áreas não relacionadas diretamente com TI – adotando aquele framework ágil para gerenciamento de projetos, devemos entender que algo importante está acontecendo.

    Este artigo é o primeiro de uma pequena série que tem a intenção de ilustrar um pouco o estágio atual de uso do Scrum no Brasil. Nesta primeira parte, um breve panorama – uma fotografia com 2km de extensão por 2cm de profundidade. Na sequência escreverei sobre os probleminhas que tem sido reportados com mais frequência em relação ao uso do Scrum. Questões relativamente pequenas, mas com potencial para batizar o mais novo integrante da família das boas ideias que fracassaram.

    .:.

    O Scrum, na forma como o conhecemos hoje, está quase completando 20 anos de existência. Partiu de ideias e experiências da dupla Takeuchi e Nonaka¹. Mas adquiriu corpo e alma nos trabalhos e escritos pioneiros de Ken Schwaber e Jeff Sutherland². Ganhou trilha e impulso para o mainstream com a publicação do Manifesto Ágil. Dentre as diversas propostas de métodos e processos ágeis, o Scrum se destaca por ser o único que se preocupa exclusivamente com os aspectos gerenciais de um projeto. Por não incorporar nenhuma prática de engenharia, o Scrum possibilita sua combinação com diversas outras propostas, do RUP (Rational Unified Process) ao XisPê (eXtreme Programming), passando pela galáxia que existe entre eles.

    O que vou colocar no próximo parágrafo não tem a força de uma pesquisa estruturada. Por outro lado, a população amostral é suficientemente grande (2000+) para garantir que eu não esteja viajando ou forçando a barra.

    Nas primeiras turmas do FAN, no já longínquo 2007, apenas 5% dos participantes, em média, levantavam a mão quando eu perguntava: “Quem *conhece* o Scrum?” Na última edição do evento em São Paulo, no final de setembro, mais de metade da sala respondeu positivamente. E esta é a média de todas as turmas que encontrei neste ano, em São Paulo, Belo Horizonte e outras praças. Claro que não posso concluir que a adoção do Scrum no Brasil aumentou 1000% em três anos. Mas, pensando bem, desconfio que foi algo com tal magnitude que aconteceu. Aliás, está acontecendo.

    Testemunhei algo parecido, em menor escala, entre os idos de 1998 e 2000 e pedrinha. A moda e elixir para todos os males dos projetos de software de então era o RUP. Foi adotado por grandes empresas, como Petrobras e BankBoston, e estava nas bocas e agendas de todo mundo minimamente antenado com a área. Algum tempo depois, em empresas diferentes e distantes, vi reações parecidas: “Não fala de RUP que me dá urticárias!” Não vale o espaço e muito menos o seu tempo o diagnóstico sobre o que aconteceu com aquele incomensurável corpo de boas ideias (pobres estratégias e falsos evangelistas).
    {Mas merece nosso tempo a preocupação de que algo semelhante aconteça com o Scrum. Neste artigo, publicado em setembro/2009, eu falo um pouco sobre isso.}

    Antes, porém, vale a pena ilustrar um pouco mais a crescente adoção do leve processo de gestão que sugere a divisão das partes interessadas entre “porcos” e “galinhas”. Como já coloquei, não é difícil justificar o uso do Scrum por pequenas e médias empresas prestadoras de serviços de TI. Elas não puderam saborear adequadamente o RUP porque ele era um produto (leia-se: seu uso significava, na maioria das vezes, um pesado investimento em ferramentas que ‘viabilizariam’ o uso do método). Agora, elas ganharam um método que não cobra royalties nem força o uso de (dispendiosas) ferramentas. E, talvez um ponto mais importante: elas ganharam um método cuja implantação é relativamente fácil, rápida e barata. Ou seja, um sonho.

    Surpreendente é o fato de algumas grandes empresas também apostarem no Scrum. Inclusive empresas de ramos que têm a péssima fama de serem conservadoras e burocráticas – pelo menos no que se refere a TI – como bancos e seguradoras. Entre tudo o que é sinalizado em movimentações deste tipo, parece nítida uma grande insatisfação com processos, padrões e metodologias utilizados até então.

    No primeiro semestre apresentei duas palestras para um dos maiores bancos do Brasil. Fui convidado para “provocar” e apresentar “tendências”. A segunda palestra foi motivada pelo “burburinho” gerado na primeira. E foi dirigida para gerentes e afins. Ao justificar o encontro, um dos principais executivos da área disse: “Precisamos de novas ideias”. Em outro momento, nas entrelinhas de uma nova intervenção do mesmo executivo, havia uma mensagem bem direta: “Não dá pra continuar trabalhando da forma como fazemos hoje”.

    Há tempos, esta e diversas outras empresas acreditam que os problemas de comunicação entre áreas de negócios e TI podem ser combatidos com mais documentos, assinaturas, change requests e coisas do tipo. Ao final do evento aquele mesmo executivo brincou concluindo que “cada dez minutos de boa conversa pode eliminar a necessidade de dez páginas de papel”. Para todas as empresas que chegaram neste ponto, e não são poucas³, o Scrum apresenta possibilidades maravilhosas. É difícil ignorar o canto da sereia que cobra tão pouco pelo muito que promete.

    O movimento no mundo dos negócios tem reflexos no universo da educação. Agora, além dos tradicionais cursos relacionados com Scrum e similares, passaremos a ver apostas mais ambiciosas e, de certa forma, mais abrangentes. Um curso de extensão da Universidade Federal de São Carlos (UFSCar), que neste ano fez uma experiência com um método “genérico” baseado no modelo iterativo e incremental, adotará o Scrum para a turma de 2011. Os Donos dos Produtos (Product Owners, ou simplesmente PO’s) já foram nomeados – são funcionários da Universidade – e os projetos já foram definidos. Assim como a grade com a distribuição das disciplinas. É o tipo de experiência com potencial para espalhar ainda mais a “novidade” Scrum. Realizada por uma entidade com o nome e peso da UFSCar, pode significar um impacto ainda maior.

    .:.

    Observações:

    1. Desconfio que Takeuchi e Nonaka nem prestem muita atenção em sua distante “criatura”. Na realidade eles apenas inspiraram a criação do Scrum. O que eles devem realmente lamentar é o fato de outras grandes descobertas e experiências suas não ganharem o impulso “pop” que o Scrum experimenta hoje. A dupla – que digo parecer dupla sertaneja ‘de raiz’ de Piracicaba – publicou alguns dos trabalhos mais relevantes da mal interpretada disciplina conhecida como Gestão do Conhecimento. Vou citar três: “Gestão do Conhecimento“, compilação de artigos organizada pelos dois (Bookman, 2008); “Theory of Organizational Knowledge Creation” e “Reflection on Knowledge Management from Japan“, artigos publicados na obrigatória coletânea “Knowledge Management – Classic and Contemporary Works” (MIT Press, 2000).
    2. De Ken Schwaber: “Agile Project Management with Scrum” (MS Press, 2004) e “Enterprise and Scrum” (MS Press, 2007).
      De Jeff Sutherland: Scrum Log (desde 2002).
    3. Essa coisa que diz que escrever mais é a solução gera situações cômicas. Em uma turma fechada do FAN no Rio de Janeiro, eu explicava os cinco níveis de detalhamento que uma especificação de casos de uso pode ter. Mostrava aqueles cinco ícones sugeridos por Alistair Cockburn em “Escrevendo Casos de Uso Eficazes” (Bookman, 2006). Quando terminei a explicação um aluno falou: “Pra gente, que trabalha com fábricas de software, isso aí não vai funcionar não. Faz o seguinte: depois da ‘ostra’ (o nível mais baixo) vamos colocar mais um ícone. Sete mil metros abaixo do nível do mar. Coloca o símbolo da Petrobras e vamos chamar isso aí de ‘Nível Pré-Sal’. Só assim as fábricas fazem o que a gente precisa”.
      Triste conclusão de outro participante: “Nem assim funciona…”
    4. A foto utilizada, “Vertical Scrum“, foi tirada pelo Jurvetson.

  • Arquitetura do Negócio

    Sequência de “(Pensando alto sobre) Arquitetura Corporativa“. Naquele artigo vimos que a arquitetura corporativa pode ser vista como um conjunto formado por quatro camadas: Arquitetura do Negócio, Arquitetura de Aplicações, Arquitetura de Informações e Arquitetura Tecnológica. Sugeri que sua elaboração só faz sentido se iniciada pela Arquitetura do Negócio. É sobre este desenho o texto de hoje.

    .:.

    A representação de um negócio, qualquer  negócio, na forma de modelos não é nada trivial. Mesmo quando pequeno e aparentemente simples, um negócio pode apresentar particularidades que dificultam o seu desenho. Não se engane: a elaboração da arquitetura do negócio é um trabalho árduo. Por isso precisamos justificá-la de maneira adequada. Quais são as principais motivações para este trabalho? Relaciono abaixo aquelas que considero mais sensatas:

    • Entender o negócio – compreender todos os seus principais componentes (recursos, processos e regras) e as forças que os definem e guiam (objetivos);
    • Avaliar a prontidão de TI – e assim justificar o desenho de toda a arquitetura corporativa. Queremos aqui mostrar o alinhamento (ou descobrir buracos) entre o negócio e todas as peças, trecos e trampos oferecidos pela TI.

    A primeira razão, “Entender o negócio”, pode ser tratada como uma iniciativa única ou espalhada em diversos projetos. Defendo que um analista de negócios entenda bem um negócio, pelo menos a parte afetada por um projeto. Só assim ele consegue contextualizar e, consequentemente, avaliar os requisitos aprendidos. Este *entendimento* se dá através de uma disciplina conhecida como Modelagem de Negócios. Se a empresa conhecer bem seu portfólio de projetos e planejar adequadamente o uso desta disciplina, ela pode elaborar gradativamente o que chamamos aqui de Arquitetura do Negócio. Devo admitir que nunca vi tal possibilidade sendo aproveitada. Sim, diariamente as empresas estão desperdiçando uma oportunidade de ouro.

    Por isso veremos um número considerável de projetos guiados pela segunda motivação acima, “avaliação da prontidão de TI”. Claro que o nome da iniciativa vai variar bastante. O termo aqui sugerido é pouco “pop” e muito comprometedor: “como assim, cara pálida, gastar dinheiro para avaliar se tu tá pronto pra me atender?!? Cê tá maluco?” O fato é que vimos surgir nos últimos tempos não só o termo e a necessidade, mas até um papel. Nasceu o arquiteto corporativo, o novo braço direito do CIO ou diretor de TI. E o que você acha que esse cara vai fazer?

    Sim, ainda são poucas (e grandes) empresas que demonstram preocupação com o tema. Mas acho que ele vai se espalhar. E isso é bom. Daí a motivação para estes dois artigos. Voltemos então ao que nos trouxe aqui: como desenhar a Arquitetura de um Negócio?

    Escrevi acima que o entendimento de um negócio significa o domínio das quatro partes principais que o definem: recursos (estrutura), processos (dinâmica), regras e objetivos. O diagrama ao lado exibe a visão de nível mais alto do “metamodelo” do qual derivamos todos os modelos de um negócio. Pois é, um negócio pode demandar vários modelos para sua correta demonstração e entendimento. Modelos ou conjuntos deles nos ajudam a montar visões, perspectivas diferentes. Podemos ter, por exemplo, um modelo que se preocupe exclusivamente com a estrutura de um negócio, seus recursos. Ou um conjunto de diagramas que trate apenas de sua parte dinâmica, seus processos.

    Recomendo o uso da EPBE (Eriksson-Penker Business Extensions), uma extensão da UML para modelagem de negócios, para a elaboração desses modelos. Neste artigo mostro os principais diagramas que podem ser elaborados através desta linguagem. Quero dizer, então, que a Arquitetura de um Negócio é representada por um conjunto de diagramas. E que estes diagramas são estruturados em visões. Mas eu tenho um probleminha.

    Falta naquela proposta um diagrama-sumário, um modelo que represente em apenas uma página a visão geral do negócio. Normalmente eu desenho (e recomendo) um grande mapa de processos. Consigo representar neste tipo de diagrama todos os elementos fundamentais de um negócio. Mas eu não consigo explicar, não sem um certo esforço, o negócio em si. Aqui é importante lembrar o estágio em que se encontra esta disciplina que chamamos de Modelagem de Negócios. Ela está renascendo. De certa forma, podemos dizer que está sendo redefinida. Este artigo ilustra um pouco o surreal (e interessante) momento atual¹. Acontece que nenhuma das duas obras comentadas no artigo apresentam uma solução para meu probleminha. Relembrando: precisamos de um modelo que explique um negócio da mesma forma que um A3² explica e justifica um projeto, em uma folha apenas. Mas não se trata da concisão pela concisão. Esta “folha” deve ter uma lógica de leitura, uma estrutura bem definida. E deve, acima de tudo, explicar um negócio.

    Encontrei em outro livro “estranho” uma possível alternativa. Estou falando de “Business Model Generation”, de Alexander Osterwalder e Yves Pigneur (publicação própria, BusinessModelGeneration.com, 2010). Um dos elementos do método proposto no livro é o Canvas, que vou adaptar aqui para tabuleiro. Não é tradução e sim uma adaptação, ok? Tabuleiro porque é onde colocamos as peças do jogo. Em nosso caso, do jogo do negócio. O tabuleiro não é um metamodelo nem uma alternativa para a EPBE/UML. Trata-se apenas de um modelo. Mas não interprete mal o ‘apenas’. É um modelo que pode sintetizar ou até mesmo guiar a elaboração de outros modelos. Vamos dar uma olhada no tabuleiro vazio.

    No centro do tabuleiro colocamos a proposição de valor do negócio, o que ele está prometendo para seus clientes. No lado esquerdo colocamos as peças que os autores remetem ao lado esquerdo do cérebro – aquilo que deve ser otimizado. Estão ali seus parceiros, processos e recursos principais, além da estrutura de custos. Concluímos então que o lado direito do tabuleiro representa a mesma porção do cérebro, mais quente e subjetiva – mais criativa. Ficam ali as quatro áreas que completam o tabuleiro: clientes, relacionamento com clientes, canais e fontes de receitas.

    Conseguimos mostrar ou entender um negócio através do tabuleiro? Sim, e os exemplos do livro – mostrando empresas como Apple, Amazon, Google, Procter & Gamble e Gillette, dentre outras – não deixam dúvidas quanto a isso. A ferramenta parece ser útil tanto para o desenho ou redesenho de um negócio existente quanto para a elaboração de um negócio totalmente novo. No processo sugerido, o tabuleiro seria desenhado em um quadro branco ou equivalente e preenchido com post-it’s ou desenhos. Estou usando termos condicionais ou dizendo que “parece ser útil” porque, a exemplo do que ocorreu com o método do Pensamento Visual um ano atrás, ainda não tive a chance de testar a nova ferramenta. Testá-la em campo. Porque desenhei o modelo do finito em poucos minutos e me diverti bastante. Mas este tipo de teste não conta. Espero em breve poder transcrever aqui outros testes e explicar melhor o uso do tabuleiro.

    Por enquanto, como de costume, não posso deixar passar alguns “poréns” ou possíveis correções. No meu modo de entender não basta a fixação da proposição de valor de negócio. O entendimento de sua motivação é crucial. Por isso eu colocaria naquele espaço central a visão, os grandes objetivos do negócio (e respectivos prazos) e também a missão da empresa (caso não esteja redundante com a proposta de valor). Também é cara ao processo de entendimento uma classificação mínima dos processos principais. Quais são primários, de apoio ou de gestão? Aliás, me parece que o espaço dedicado para processos e recursos é muito pequeno. Mas, enfim, apenas um bom volume de testes pode confirmar a utilidade da ferramenta e possíveis correções ou adaptações.

    Agora devemos retomar o ponto principal: este desenho, o tabuleiro, pode representar a arquitetura do negócio? Pelo menos em parte, sim. E tal possibilidade é sugerida no livro, na seção “Outlook – Aligning IT with Business” (pág. 272). Em relação ao sanduíche sugerido no artigo anterior o livro só não considera a Arquitetura de Informações (pelo visto, combinando-a com a Arquitetura de Aplicações). É uma pena que o livro dedique apenas duas páginas ao tema. Mas, claro, não era seu foco. Fica com a gente então o trabalho de testar a sugestão e, se for o caso, implementá-la. Tentarei fazer minha parte aqui. Inté!

    .:.

    Observações:

    1. Surreal? Sim, tanto que o BABoK 2.0, lançado no ano passado, ignora por completo a existência de uma disciplina chamada Modelagem de Negócios. Todas as obras citadas neste artigo e artigos relacionados sinalizam o renascimento da disciplina. O que nos permite concluir que o BABoK comeu bola. Ou você acredita que o assunto não interessa aos analistas de negócios?
    2. O “A3” é uma ferramenta criada na Toyota para solução de problemas. O nome vem do tamanho do papel utilizado na sua elaboração. Oportunamente mostrarei como ele pode completar ou até mesmo substituir o documento de visão de um projeto.

  • (Pensando alto sobre) Arquitetura Corporativa

    Segunda parte da palestra “O Futuro não é mais como era Antigamente“. O título original desta seção era “O Cérebro Eletrônico faz (quase) Tudo”. Mas vou poupá-los do resumo da saga¹. Este artigo vai tratar especificamente do tema que não consegui articular como gostaria no Seminário Engenharia de Software. Vou escrever (ou pensar alto) sobre Arquitetura Corporativa – aquela coisa abstrata que normalmente vem acompanhada de uma piadinha: “parece cabeça de bacalhau; Todo mundo sabe que existe mas ninguém nunca viu”.

    .:.

    Arquitetura, segundo o Houaiss, é 1. “arte ou técnica de organizar espaços e criar ambientes para as diversas atividades humanas”, ou 4. fig. “conjunto de elementos de um todo; estrutura, natureza, organização”. Uma arquitetura corporativa deveria representar todos os elementos da organização. É esta última frase que bagunça o coreto. Como representar “todos os elementos de uma organização”? Seria a arquitetura corporativa um tipo de documentação, de representação de coisas que existem no mundo real? Se for a representação de *todas* as coisas, não espanta que ninguém tenha visto uma. Por isso peço sua atenção para a primeira definição acima. “Arte ou técnica” – 97,8% técnica, em nosso caso; “de organizar espaços e criar ambientes” – estruturando todos os elementos de um conjunto; “para as diversas atividades humanas” – para as atividades e fins de um negócio, se estamos falando sobre Arquitetura Corporativa.

    Lá nos idos de 40 a.C. um tal de Vitrúvio, arquiteto e engenheiro romano, cismou em fixar algumas regrinhas para construções. Pelo jeito fez um bom trabalho, já que é ensinado até hoje. Dos dez volumes que ele batizou “De Architectura” só nos interessa aqui uma pequena definição: a tríade vitruviana. Ela fixa três elementos fundamentais da arquitetura:

    • Firmitas: solidez e estabilidade;
    • Utilitas: conveniência e utilidade. (Funcionalidade!);
    • Venustas: beleza, gosto estético.

    Se um dia resolvemos trazer “arquitetura” para nosso meio (TI), deveríamos ter importado também um comprometimento com as três características listadas acima. Afinal, elas são peças fundamentais da disciplina que incorporamos. Portanto, uma arquitetura corporativa deveria ser sólida, estável, útil e bela. Agora, faça uma breve análise dos negócios que você conhece. Faça de conta de que existe uma radiografia que sintetiza a arquitetura de uma determinada organização. Ela passaria pelo teste da tríade vitruviana? Não precisa responder. A menos que sua resposta seja ‘sim’. Assim vou pedir referências, CNPJ, “nada consta” e RG de todos os envolvidos.

    Não se trata de um julgamento negativo demais e sim de um “choque de realidade”. Um negócio, qualquer negócio, é feito de muita adaptação e improviso. O dinamismo que só faz crescer desde o início do século passado impõe uma dificuldade que a arquitetura “clássica” nunca enfrentou. Pelo que sei, nunca foi solicitada uma edificação que: i) se adaptasse instantaneamente às mudanças em seu ambiente; ii) influenciasse seu ambiente; e iii) suportasse os usos e mal usos mais improváveis e inconsequentes.

    Devemos concluir então que esse papo sobre “arquitetura corporativa” é pura balela e ponto final? Acho que não. Equivocada é a intenção de documentar extensivamente a arquitetura total de um negócio. Mais bola fora ainda é a documentação pela documentação, mera burocracia. A primeira pergunta que deveria ser feita é: por que precisamos falar sobre arquitetura corporativa?

    Todo negócio é uma viagem. Claro que não no sentido pejorativo que ficou comum nos últimos anos. Um negócio é uma jornada sem fim (pré-determinado) que de tempos em tempos renova seu destino (sua Visão). Condições do tempo e do terreno, cada vez mais instáveis e movediços, tornam a viagem e seu planejamento cada vez mais difíceis. A arquitetura corporativa, se bem elaborada, pode funcionar como mapa e bússola. Mas, afinal, o que é arquitetura corporativa? Como ela é desenhada, se é que é desenhada?

    Uma busca na Internet pode lhe dar dezenas de boas sugestões. O Zachman Framework, por exemplo, sugere um consistente modelo para a elaboração da arquitetura corporativa. Aqui vou apelar para uma visão mais simples, para o que chamo de “básico do básico”. Gosto de ver o desenho de uma arquitetura como se fosse um belo sanduíche. Belo mas simples, um cheeseburger. Que é formado por quatro partes apenas:

    • Arquitetura Tecnológica: ou “o que eu tenho”. São os ferros (hardware) e caixinhas (software) que compõem a infraestrutura tecnológica da organização;
    • Arquitetura de Informações: ou “o que eu sei”. Trata de dados, informações e conhecimento explícito, aquele que está registrado de alguma maneira no negócio.
    • Arquitetura de Aplicações: ou “o que eu faço”. Compila todas as funcionalidades oferecidas ao negócio na forma de sistemas aplicativos.
    • Arquitetura do Negócio: ou “Por qual razão e pra quem?”. Dá sentido para as três camadas (arquiteturas) inferiores. Justifica (ou não) cada aplicação, informação e componente de infraestrutura.

    Esta visão de alto nível atende parte da definição de arquitetura que vimos no início do artigo. Os “espaços” estão organizados. A partir dela conseguimos entender “estrutura, natureza e organização” dos elementos que formam a arquitetura corporativa.

    O desenho permite até algumas elocubrações e provocações. Por exemplo: Nicholas Carr (aquele do “IT Doesn’t Matter”) defende no livro “A Grande Mudança” (Landscape, 2008) que é questão de tempo para as empresas se livrarem da camada mais baixa do sanduíche, a arquitetura tecnológica. Aqueles “serviços” seriam oferecidos por grandes empresas, em um modelo muito parecido com o das distribuidoras de energia elétrica. Sua tese faz um certo sentido, mas qual o impacto nas camadas de cima? Ah, elas seriam terceirizadas também.  Opa, elas já são. Mas em fatias verticais, da mesma forma como repartimos um sanduíche de verdade. Ofertas assim são conhecidas como BPO, ou Business Process Outsourcing. Deixando as infinitas possibilidades de lado, voltemos ao tema central.

    Como são formadas cada uma das arquiteturas? As três camadas técnicas – Arquitetura Tecnológica, de Informações e de Aplicações – podem ser representadas por um ou mais diagramas específicos. A UML, por exemplo, oferece diagramas que podem representar muito bem cada uma delas. Importante aqui é o bom senso para se limitar a representar apenas os elementos principais, fazendo vista grossa para detalhes finos (sic). Desafiadora aqui é a ligação entre as quatro camadas, as relações entre elementos de infra, informações, aplicações e do negócio. Desafiadora porque é aqui que encontramos incontáveis ligações ponto a ponto (macarrônicas), vergonhosas redundâncias e incômodos buracos negros. Mas não é por aqui, pelas três arquiteturas técnicas, que o trampo deve começar.

    As três camadas técnicas só existem para suportar um negócio. Parece lógico que o desenho de uma arquitetura corporativa comece pelo entendimento e delimitação da arquitetura do negócio. Como estourei meu limite de 1000 palavras, uma sugestão para o desenho desta arquitetura fica para o próximo artigo. Inté!

    .:.

    Observações:

    1. Ok, tá aqui o resumo da saga: Era uma vez… lá na nossa pré-história acreditávamos em um colossal e monolítico “cérebro eletrônico”. Décadas depois testemunhamos o esfacelamento e distribuição do “cérebro” em peças cada vez menores e em locais dos mais inusitados. O que nos traz para uma das cinco supertendências apontadas pelo ZapThink: a interoperabilidade profunda. Em poucas palavras: esses pequenos cérebros ou pedaços de cérebro devem aprender a interagir e conversar entre si da maneira mais natural possível. Talvez este não seja o principal desafio dos novos tempos, mas com certeza é o mais instigante: “Como assim, meu tênis vai conversar com meu carro, minha casa e meu iPod?!?”
      A pergunta que fiz e não respondi naquela palestra foi: nossas teorias e práticas (sobre Engenharia de Software) resistem ao confronto com as novas pessoas, tecnologias e arquiteturas?
    2. A imagem utilizada neste artigo foi desenhada para o trabalho “De Architectura”, de Vitruvius, e obtida na Wikipédia.

  • Identificando Partes Interessadas, Interesseiras, Indiferentes e Encrenqueiras

    Ao seguir o método do Pensamento Visual, a segunda¹ questão que o analista de negócios deve responder é “Quem / O quê?”. A pergunta é repetida n vezes se o analista trabalha de forma iterativa e incremental. Mas desde as primeiras ocorrências ele deve se preocupar em identificar todas as partes interessadas – as pessoas que terão algum tipo de relacionamento com o projeto ou seu produto. Este artigo é sobre o processo de identificação e ferramentas que podem ajudar analistas e equipe a gerenciar o relacionamento com clientes e usuários.

    Um dos problemas mais frequentes e irritantes com requisitos é a sua não estruturação. Eles são listados de maneira ad hoc em documentos de texto, cartões ou planilhas eletrônicas e carecem de mínimos atributos que os qualifiquem. Uma das informações essenciais para a contextualização de um requisito é sua origem, sua fonte. Quem pediu? É claro que não basta registrar o nome da pessoa e sua posição na empresa. Por isso a correta identificação de todas as partes interessadas de um projeto é tão cara para a Análise de Negócios.

    Cara e complexa, porque a identificação não será produto da aplicação de um simples questionário ou check-list. A equipe, particularmente o analista de negócios, dependerá de seu poder de observação para identificar, avaliar e classificar cada pessoa envolvida com o projeto. Algumas informações serão fornecidas naturalmente, logo no primeiro momento. Outras aparecerão com o tempo, através da convivência (atenta e atenciosa). O mínimo que se espera de um Mapa de Partes Interessadas² é uma tabela com os seguintes atributos:

    • Papel / Função na organização;
    • Papel no projeto. Podemos completar esta informação com a Matriz RACI sugerida no BABoK:
      • esponsável – executa o trabalho;
      • ccountable – tem a última palavra (só deveria existir uma pessoa com tal poder);
      • onsultado – deve ser ouvido pela equipe;
      • nformado – deve ser comunicado sobre o projeto e algumas decisões.
    • Impacto que o projeto terá no dia a dia da pessoa. Pode ou deve ser simples como Alto, Médio, Pequeno e Nenhum;
    • Influência que a parte interessada exercerá no projeto. Pode usar mesma classificação sugerida acima;
    • Receptividade ao projeto: Contrário, Indiferente, Favorável ou Entusiasmado;
    • Razões para a resistência ou apoio.

    As três primeiras informações podem ser obtidas logo no primeiro momento. Elas devem compor aquele grande mapa que chamo de ‘fotografia com 2km de extensão e 2cm de profundidade’. As outras três informações – Influência, Receptividade e Razões – só surgirão com razoável confiabilidade no decorrer do projeto.

    É interessante notar que o Mapa das Partes Interessadas, quando completado com os últimos três atributos, é um dos únicos artefatos do tipo ‘caixa preta’ de uma equipe de projetos. Ou seja, ele deve ser confidencial. Não interessa a mais ninguém as percepções e cuidados que a equipe tem com cada pessoa envolvida.

    Sim, o mapa servirá para que a equipe saiba com quem está falando e evite riscos de mal entendidos ou até mesmo de conflitos. Sejamos mais visuais. A matriz ao lado sintetiza três informações fundamentais para que uma equipe gerencie seu relacionamento com as partes interessadas. O eixo X indica o Impacto que o projeto terá na vida das pessoas envolvidas. No eixo Y demonstramos a Influência que cada pessoa terá sobre o projeto. E quatro ícones ilustram a Receptividade de cada um ao projeto.

    O gráfico indica, por exemplo, que Joaquim e Carlão são contrários ao projeto. Pode ser por resistência às mudanças ou gosto de ser encrenqueiro. Joaquim pode exercer forte influência no projeto, o que o torna fonte de potenciais problemas. Apesar do pequeno impacto que o projeto terá em seu cotidiano. A equipe deve ‘pisar em cascas de ovos’ quando se relacionar com ele. Carlão, por outro lado, não tem tanta influência assim. Mas terá sua rotina muito impactada pelo projeto. Merece especial zelo quando entregas forem realizadas.

    Três pessoas, José, Dedé e Terezinha, são favoráveis ao projeto. José será muito impactado e terá forte influência no projeto. Dedé será muito impactado, mas não apitará nada. E o apoio da Terezinha pode ter efeito moral, mas nenhum benefício prático: ela tem muito pouco a ver com o babado. Quase como o Euclides, que se mostra indiferente. O que não fará muita diferença. Já a indiferença do Tonho deve ser percebida pela equipe com preocupação. Afinal, ele pode exercer forte influência e será muito impactado. Qual a razão de sua indiferença? O que pode motivá-lo? São questões que deveriam preocupar a equipe, particularmente o gerente do projeto e os analistas de negócios.

    Assim como Magda e João, entusiasmados com o projeto. Magda tem pouca influência, mas o João é relativamente influente. A equipe deve tratá-los como aliados e fazer de tudo para não desagradá-los. Afinal, seu entusiasmo pode contagiar outras partes interessadas. O que nos leva para outra questão: quais são as relações entre os envolvidos? Quem influencia quem? Se o número de pessoas envolvidas no projeto for relativamente grande, talvez se justifique a elaboração de um Mapa de Relacionamentos, como mostra o diagrama ao lado. Nas linhas indicamos o poder de influência de cada pessoa sobre as demais. Ele pode ser: Forte, Médio, Pequeno ou inexistente (“-“).  Vemos, por exemplo, que Euclides e Terezinha não influenciam ninguém. E que a Maria, que não é influenciada por ninguém, tem poder sobre todo mundo. Então ela não pode permanecer tão indiferente (alienada) em relação ao projeto, certo?

    Carlão e Joaquim são contrários ao projeto. É importante que a equipe saiba ‘blindar’ de alguma maneira todas as pessoas que estão em seu círculo de influência. Deve preocupar, principalmente, que Magda e Dedé não se deixem levar pelo pessimismo ou possível jogo sujo do Carlão.

    É claro que estou brincando com a simplicidade. Relações humanas são de uma complexidade absurda e nunca serão resumidas em uma ou duas matrizes. Mas isso não pode significar que a equipe se isente de sua responsabilidade de gerenciar o relacionamento com todas as partes interessadas. É sabido que boa parte dos problemas que ocorrem em projetos derivam de deficiências na comunicação e conflitos de interesses. As ferramentas aqui sugeridas podem ajudar equipes a cuidar melhor de suas relações com clientes e usuários. Faz bem ter a resposta na ponta da língua toda vez que alguém perguntar: Você sabe com quem está falando?

    .:.

    QuiProQuó

    Aproveitando os exemplos acima, alguns desafios:

    1. Das dez pessoas apresentadas qual seria o melhor candidato para a função de Dono do Produto (Product Owner) caso o projeto seja guiado pelo framework Scrum? Por quê?
    2. Há um conflito de informações entre as duas matrizes apresentadas. Qual é o conflito e qual a possível razão da inconsistência?
    3. Qual diagrama pode ilustrar e complementar a Matriz de Relacionamentos?
    4. Quais quadrantes podem significar requisitos mais ricos? Por quê?
    5. Seria a Magda carente ou influenciável demais?
    6. O que é que o Euclides tá fazendo no projeto?!?

    Observações:

    1. No método original, “Quem / O quê” é a primeira e não a segunda pergunta. Na adaptação que fiz para a Análise de Negócios transportei “Por que” para o início do questionário. Quer saber por quê?
    2. Mapa de Partes Interessadas?!? Pois é, o nome é ridículo. Sugestões?
    3. “Key-People” é o cartoon do HikingArtist.com utilizado hoje.

  • Virando a Própria Mesa

    Autor: Ricardo Semler. Paulistano nascido em 1959, formado em Direito pela USP e Administração em Harvard. Em 1980 assumiu a presidência da empresa do pai, atualmente conhecida como Semco. Em 1988 publicou este livro que se tornou um best-seller no Brasil.

    Editora: Rocco, 2002.
    Utilizei a capa clássica do livro para ilustrar esta entrada, da editora Best Seller (1988).

    Do que se trata: Visão alternativa do mundo da administração e de tudo o que acontece em uma empresa.

    Impressões: Passados 22 anos desde a publicação deste clássico, a impressão que se tem é que a Semco segue única em solo tupiniquim. Única em seus princípios, processos e (ausentes?) estruturas e regras. Semler virou uma referência lá fora, particularmente nos EUA. Suas palestras são concorridas e seus livros vendem bem, obrigado. Recentemente foi citado no livro “REWORK“, de Jason Fried e David H. Hansson. Enquanto isso, por aqui…

    Nesta semana aconteceu um fato curioso, que acabou motivando esta entrada. Aparentemente a Info Corporate, da Editora Abril, retirou do ar sem mais nem porque uma entrevista com o Ricardo Semler. O título da matéria era “Cio pra quê?“. Fiquei sabendo do caso pelo bafafá gerado no Twitter. E como tudo que pinta na Internet fica registrado de uma maneira ou de outra, consegui ler o bate papo com o Semler. Ele não fala nada muito diferente do que já falava em 1988, neste “Virando a Própria Mesa“.

    Semler 2010: “Há 15 anos eu gostava de dizer que um computador não passava de uma televisão em cima de uma máquina de escrever, e, hoje, 40 gigas depois, continuo achando algo parecido. Precisamos dele? Sem dúvida, para arquivar dados, compartilhá-los etc. Mas isso nós fazemos e é simples. O pessoal de TI é que complica. Duvido que existam empresas que se dão bem por causa da TI. As empresas se dão bem por causa dos seus produtos, de seus momentos. A TI vai de roldão.”

    Semler 1988: “Se você ainda vive na aflição de saber se o PC-XT é melhor que o AT, se o Lotus 1-2-3 versão 2.0 está obsoletado pelo 2.1, e se o míni vai ser comido pelo supermicro, abra a janela e espante os fantasmas. Cuide de vender, fabricar e atender bem o cliente. Lembre-se que a informática é uma televizãosinha em cima de uma máquina de escrever e desencante de vez. Desapareça com os salários superdimensionados do pessoal de sistemas, e dê um emprego honesto para eles em vendas ou na produção. Ser uma empresa ‘informatizada’ é o mesmo que querer ser uma empresa ‘máquina-de-escreverzada’. Use o avanço tecnológico. Use tudo que há de novo (e há muito todos os meses), mas deixe a informática em seu devido lugar, que é afundada e esquecida dentro das operações do dia-a-dia da empresa. Feche os olhos e cante a receita do antídoto da Maga Patalógica:

    Coruja peripática
    Moscas no dedal
    Faça a informática
    Cair na real!”

    Maga Patalógica?!? Hehe… É claro que o livro do Semler não é muito ‘normal’.

    Indicações: Burocratice crônica, estressite aguda, hipertensão administral e hipertrofia organizacional.

    Contra-indicações e reações adversas: Durante a leitura podem surgir crises de urticária, subidas abruptas de calor menopáusico, inchaço de olhos esbugalhados, insônia diurna, distúrbios gastrintestinais, taquicardia, palpitações sem palpites e, principalmente, dor de cabeça.

    Indicações e contra-indicações redigidas pelo próprio autor na abertura do livro, onde ele alerta que “cada 0,1mg de sarcasmo contém meia verdade”.

    Outras provocações:

    “Copiar cultura de empresa bem-sucedida é grau 8,5 de miopia.”

    “O crescimento não é finalidade – é meio.”

    “Quem planeja é quem vai executar!”

    “Nada é mais medieval na empresa de hoje do que as exigências da empresa em relação a roupa e conduta.”

    “Se não há erros constantes, não há aprendizado e, provavelmente, não há muita decisão.”

    “Para que um cliente tenha sempre razão é essencial que todo ser humano também tenha, sempre. Ou será que quando o ser humano se veste de cliente ele se transfigura num sábio defensor da justiça?”

    “Dizer para um operário que a tarefa dele é produzir, e dizer para outra pessoa que a sua tarefa é verificar se o que foi feito tem qualidade é um contra-senso. Não existe sensatez em produzir por produzir. Só existe produzir com qualidade como meta. E quem é a pessoa melhor aparelhada para garantir a qualidade da produção? A pessoa que faz.”

    “Não existe nada tão temporário quanto um programa permamente de redução de despesas.”

    “Um sim é sempre um sim. Um não é um talvez.”

  • O Cubículo Global

    Parte 1.1 da palestra “O Futuro não é mais como era Antigamente“. Tanto no evento quanto no artigo anterior, “O Clube da Esquina Globalizada“, não explorei como queria este ponto, que trato genericamente como o “cubículo global”. Espero preencher a lacuna com este artigo. Lembrando que a palestra é sobre Engenharia de Software e minha (retórica) questão é: nossas teorias, métodos e práticas resistem ao confronto com as pessoas e tecnologias de hoje?

    .:.

    Surrupiei o título de um artigo da ZapThink. O “Cubículo Global” seria uma das cinco “supertendências” da TI corporativa. O texto da ZapThink reconhece que se trata de uma tendência “com mais de 100 anos de idade”. Afinal, desde a invenção dos telégrafos e telefones o trabalho remoto e a colaboração à distância se tornaram possíveis e viáveis. Os avanços tecnológicos possibilitaram que colaboradores espalhados ao redor do globo trabalhem como se estivessem em uma mesma sala. Mas a tecnologia, neste ponto, serviu apenas para pavimentar o caminho para uma mudança maior e mais significativa. Uma grande mudança cultural está acontecendo, à revelia das organizações, e seu impacto na área de conhecemos como Engenharia de Software não pode ser desprezado.

    De todas as grandes e muito bem vindas provocações colocadas por Don Tapscott e Anthony Williams em “Wikinomics – Como a Colaboração em Massa pode Mudar o seu Negócio” (Nova Fronteira, 2007), existe uma que deveria ser lembrada diariamente pelas empresas: por mais talento que você contrate e retenha, sempre haverá mais inteligência lá fora do que aí dentro.

    Muito se fala sobre uma guerra de talentos, sobre a necessidade de uma empresa formar e tentar segurar pessoas que fazem a diferença em um mundo de hipercompetição. É claro que este tema merece a posição que ocupa na agenda das organizações. O problema, particularmente quando falamos sobre desenvolvedores, é que a cada dia eles têm mais motivos para estar fora. Não estou dizendo que todos os desenvolvedores se tornarão freelancers ou microempresários. Mas parece inevitável que um contingente de alguns dos melhores talentos da área decrete sua independência. De maneira aparentemente irreversível.

    Em primeiro lugar, de todos os trabalhadores do conhecimento, ninguém parece se incomodar mais com o “gap cultural” diagnosticado por Domenico De Masi¹ do que os desenvolvedores. Para entender: este gap é um fenômeno que “constrangeu os atuais knowledge workers, os trabalhadores do conhecimento, a se organizarem segundo os velhos princípios industriais”. O desenvolvimento de sistemas requer criatividade. É interessante notar que em doses cada vez maiores. O que torna legítima a insatisfação de seus praticantes com muitos processos e “metodologias” que lhes são impostos. Comando e controle não combina com criatividade. Mas esta é apenas uma parte do gap.

    Vários desenvolvedores têm em suas casas, bolsos e mochilas mais tecnologia, ou tecnologias mais modernas e atraentes do que aquelas utilizadas pelas empresas. E é indissociável do programador a vontade de trabalhar com o que é novo e desafiador. Me mostre um programador “conservador” e eu te mostrarei um cara que não hesitará em mudar de profissão na primeira oportunidade.

    Empresas que têm software n’alma (e no núcleo de seu negócio) sabem que os “velhos princípios industriais” seriam seríssimos impedimentos para seu sucesso. É por isso que na Google, Microsoft e em outras empresas notáveis há um zelo extremo com o ambiente de trabalho. Videogames e quadras de jogos, salas de “descompressão”, restaurantes e lanchonetes, salas de reunião e mobiliário. Tudo é pensado e desenhado para atrair e reter as melhores pessoas. Nem vou falar sobre remuneração. Mas sua vagas são limitadas. O que farão as centenas de milhares ou milhões de desenvolvedores que elas não contratam?

    Alguns já viram na App Store da Apple e no Marketplace da Google a resposta. Alguns? Só a loja da Apple já contabiliza mais de duzentas mil aplicações e cinco bilhões de downloads. O lançamento do iPad e a dinâmica da Apple fazem crer que essas curvas estão longe da estabilização. Tendo em vista que cada aplicação tem um mercado potencial de milhões de usuários ao redor da Terra, não é exagero supor que uma aplicação bem sucedida pode significar a aposentadoria para um desenvolvedor. Claro, para a maioria isso não passará de um sonho. Mas muitos tentarão a sorte. Aliás, já estão tentando.

    O Melhor dos Mundos

    No artigo anterior citei pesquisa da FGV que fala em um déficit de 800 mil profissionais só no Brasil. Acima cogito a possibilidade de uma debandada de outros tantos talentos. Como ficarão as empresas, tenham elas o software como atividade fim ou não?

    Não vejo mudanças muito significativas no curto prazo. O brasileiro, apesar da fama dizer o contrário, é muito conservador. Particularmente quando se trata de TI. Mas é possível projetar (ou seria torcer por?) um panorama bem diferente em um horizonte de três ou quatro anos. Organizações vão querer contar com aqueles reconhecidos talentos em projetos pontuais. Aquelas que têm o software como seu negócio central criarão redes de colaboradores virtuais. A localização física deles não terá importância nenhuma. Relevantes serão seus conhecimentos especializados e, em diversos casos, os ativos de software que cada um possuir. Uma equipe pode ser formada por um desenvolvedor de Blumenau, outro de San Francisco e um designer de Pádua, na Itália. Localmente ela só precisará de alguém que faça a ponte com o(s) cliente(s) e usuários. Isso soará bobo e romântico para alguns (Pádua?!?) e como notícia velha para outros que já trabalham assim não é de hoje². O que projeto é o crescimento considerável deste tipo de arranjo produtivo. Grandes fábricas desantenadas terão que concorrer com redes de oficinas (ou boutiques) especializadas. Vários componentes das redes serão empresas de uma pessoa só.

    Empresas que não têm o software como atividade fim terão mais opções de compra. A era dos projetos mastodônticos e milionários vai tarde mas vai. Já foi! Assim como a era das arquiteturas fechadinhas e repletas de ângulos retos. Tudo isso abre espaço para a participação de pequenos mas talentosos agentes criativos que nas horas vagas tentam a sorte nas roletas da App Store, Google Marketplace e afins. Para o comprador é um tipo de paraíso porque ele conta com um talento comprovado e sem o tradicional “overhead” daquelas empresas de RH que se disfarçam de solucionadoras de pepinos de TI. Para o pequeno agente criativo é também um paraíso porque ele não precisa fingir que acredita nem se submeter aos processos e juras daquelas tradicionais empresas de RH que fingem saber tudo de TI. Ele vende direto, pode colocar preço em seus produtos e serviços e seguir seus processos e práticas sem depender de nenhum amém. Amém? Inté!

    .:.

    Observações:

    1. “Criatividade e Grupos Criativos“, Sextante, 2002. Há tempos não citava este trabalho por aqui. É um tijolão de quase 800 páginas que deveria ser lido por tudo mundo que quer falar sobre inovação e criatividade. Pena que De Masi só seja lembrado pelo “ócio”… Beócios!
    2. Tem uns 4 anos que uma grande empresa multinacional me contratou para avaliar a adequação de uma aplicação aos seus processos. Me escolheu exatamente porque fazia pouco tempo que eu a havia estudado (analisado seu negócio). A empresa que queria vender a solução teve que me dar acesso a uma versão completa da solução e também ao código fonte. Eu tinha aqui os mapas dos processos que eu mesmo havia desenvolvido. Em pouco mais de 3 dias elaborei todo o trabalho. Sem ver a cara de ninguém. Só precisei sair de casa, daqui de Varginha, pra colocar a NF no Correio. Hoje, com as notas eletrônicas, nem isso seria necessário. Só desfilei o lero-lero para ilustrar um pouco mais a afirmação: a localização do trabalhador do conhecimento é irrelevante em um número cada vez maior de situações.
    3. “Another day at the office” é o nome do Cartoon utilizado hoje, do HikingArtist.