PAULO FERNANDO VASCONCELLOS NOGUEIRA

Tag: Management 3.0

  • Pensando Negócios – Referências

    Pensando Negócios – Referências

    A série que se encerra aqui mal arranhou os temas arquitetura de negócios, pensamento sistêmico, complexidade etc. Se este trabalho tem algum valor, ele está exatamente na combinação desses temas. Iniciativa ainda rara, particularmente em terras tupiniquins. Ainda…

    As ideias compiladas neste trabalho vêm de um grande número de cabeças. Recomendo abaixo apenas as obras fundamentais. Porque acredito que quem gostou dos temas da série e pretende aprofundar seus estudos quer: i) dar passos seguros neste novo e traiçoeiro terreno; ii) ter contato com os exemplos que não consegui construir;  e iii) ser provocado a pensar e construir seus próprios modelos e exemplos.

    Thinking in Systems

    Donella Meadows, assim como Russell Ackoff e Jay Forrester, dedicou toda a sua vida ao estudo (e ensino) de sistemas complexos. Ficou famosa ao publicar, em 1972, o livro The Limits to Growth. Há quarenta anos ela já demonstrava a preocupação com a sustentabilidade de nosso planeta. E apresentava sua tese utilizando lentes de sistemas.

    Thinking in Systems: A Primer é um livro póstumo, publicado em 2008 pela Chelsea Green Publishing. Donella trabalhava neste livro desde o início da década de 1990. Era um projeto xodó, concebido para sintetizar mais de três décadas de experiência com sistemas complexos em uma linguagem acessível.

    Texto básico e fundamental para o entendimento de sistemas. Donella ilustra dezenas de exemplos (um “Zoológico de Sistemas”) através de diagramas de estoque e fluxo. E nos ensina a lidar com sistemas relacionando cinco dicas principais:

    1. Observe o comportamento do sistema;
    2. Aprenda a sua história;
    3. Dirija seu pensamento para a dinâmica,
      não para a análise estática;
    4. Não se limite a entender o que está errado.
      Descubra como chegamos até aqui; e
    5. Busque o por quê: por que o sistema se comporta assim?

    Se o pensamento sistêmico é novo para ti, então este livro é o ponto de partida ideal.

    Systems Thinking – Managing Chaos and Complexity

    Jamshid Gharajedaghi foi aluno e parceiro de Russell Ackoff. Seu livro, publicado em 2011 pela Elsevier/Morgan Kaufmann, é um dos primeiros a combinar pensamento sistêmico e arquitetura de negócios. Na capa é prometida “uma plataforma para o desenho da arquitetura de negócios”.

    Jamshid começa praticamente do zero, revendo conceitos básicos sobre sistemas. Não é didático como Donella, mas entrega o que promete. O livro é organizado em quatro partes:

    1. Filosofia de Sistemas: O Nome do Diabo
    2. Teoria de Sistemas: A Natureza da Besta
    3. Metodologia de Sistemas: A Lógica da Insanidade
    4. Prática de Sistemas: Os Poucos Corajosos

    Títulos fortes e irônicos. O texto é mais sisudo, mas não deixa de ser claro. Não concordei com todas as sugestões apresentadas, mas elas me fizeram pensar. Surrupiei descaradamente de Jamshid sua visão das cinco dimensões de um sistema sociocultural.

    Se sua intenção é aprender a desenhar ou redesenhar negócios sob a ótica de sistemas, este é o livro. E não apenas porque ainda é o único a propor tal combinação.

    O Que Importa Agora

    Gary Hamel não utiliza a linguagem de sistemas. Mas a compreensão da complexidade que nos cerca e as sugestões apresentadas neste livro não são apenas compatíveis com as ideias apresentadas acima. São complementos mais que necessários. Gary é um dos principais pensadores do mundo dos negócios e da administração do século 21.

    O Que Importa Agora (Elsevier/Campus, 2012) dedica cinco capítulos para cada item que importa agora. São eles:

    1. Valores
    2. Inovação
    3. Adaptabilidade
    4. Paixão
    5. Ideologia

    Hamel confessa desconhecer uma única empresa que seja exemplar em todos os critérios listados. Mas conta histórias reais que ilustram de forma bastante objetiva os bons e os  maus exemplos. Os sopapos nos gananciosos de Wall Street e em mercadores de modas gerenciais são particularmente saborosos.

    Por falar em sabor, Gary escreve no prefácio que seu livro é “apenas um tira-gosto num pé-sujo”. Pode até ser, mas é daquele tipo de tira-gosto que merece cada centavo.

    Ao término do livro, Hamel dispara 25 tiros à lua elaborados por um grupo chamado MiX – Management Innovation Exchange. Fonte perene de boas ideias para tempos bicudos.

    Outras Fontes

    Quantas vezes mais vou surrupiar e citar Management 3.0, de Jurgen Appelo? Até a chegada da versão 4.0, você diria. Não se deixe enganar por esse tipo de numeração. E não superestime nossa capacidade de evolução. Acho que não estaremos mais aqui – eu com certeza não estarei – quando as ideias sugeridas neste livro virarem arroz com feijão. Sou um otimista incurável, por isso acho que levaremos só meio século para desfazer as cagadas cometidas durante todo o século passado. Um bom resumo das propostas de Jurgen pode ser visto nesta apresentação.

    Appelo é cofundador de um grupo que, a exemplo do MiX citado acima, se propõe a debater (questionar!) liderança e gerenciamento de uma maneira geral. É o Stoos Network, que tem um satélite em formação na cidade de São Paulo. Interessados naqueeeele clube que sugeri em maio passado devem gostar desta iniciativa.

    Seria uma imensa injustiça não citar Managing the Design Factory, de Donald Reinertsen (Free Press, 1997). Afinal, são dele diversos guias apresentados nesta série. Só não vou detalhar mais a obra porque ela merecerá uma entrada específica na biblioteca {finito}.

    Chopps

    Parte de minha meia dúzia de leitores fez contato off-blog durante a elaboração da série. Para tirar dúvidas, debater sugestões ou simplesmente jogar conversa fora. Um papo em especial merece registro. Teve o carioca Igor Couto como interlocutor e durou pouco mais de duas horas. Aconteceu logo após a publicação da quinta parte, aquela sobre cultura.

    Igor (que pelo silêncio não deve ter curtido o tabuleiro), queria uma ajuda para “visualizar” as dimensões culturais. Guiamos a conversa da mesma forma que sugeri na série: trabalhando exclusivamente com uma das cinco dimensões (pra lembrar: riqueza, conhecimento, poder, valores e beleza). Escolhemos conhecimento para começar. No meu ponto de vista, a mais visível (ou visualizável). 

    O carioca me ajudou muito quando pediu para ver um processo de desenvolvimento (de software) sob o prisma sugerido. Eu disse: Scrum! Veja como o Scrum tem resposta para os três tipos de aprendizado (geração e disseminação de conhecimento) sugeridos na parte V: Ele nos leva a aprender a aprender (através das retrospectivas) e também a aprender a fazer (através das revisões e encontros diários). E a experiência do trabalho conjunto ensinam time e indivíduos a ser. As duas primeiras respostas são intencionais – ativa e explicitamente almejadas pelo método – enquanto a última é efeito do uso (correto e prolongado) daquele  framework.

    Agora, uma provocação: quantas vezes você se deparou com um processo de negócio  equipado de forma a intencionalmente promover a geração e disseminação de conhecimento?

    Lógico que a conversa com o Igor foi muito mais extensa. Lá pelo final sugeri que ele visse as dimensões soft como se fossem o ESB (Enterprise Service Bus) da arquitetura de negócios. Como o Igor, entre outras coisas, é um arquiteto de software, a analogia caiu como um chope gelado goela abaixo em um fim de tarde no Rio 40°.

    Espero que este resumo o ajude também. E, principalmente, que o incentive a puxar conversa. Vai um chopps aí?

     

  • Universos Paralelos: O Samba e o Bebop

    Universos Paralelos: O Samba e o Bebop

    É muito pouco provável que alguém do Universo Samba (Negócios) perca dois minutos de sono ou dois fios de cabelo por causa deste artigo proveniente do Universo Bebop (TI). As interfaces fraquinhas e o pouco interesse que um nutre pelo outro – apesar da mútua dependência – tendem a deixar tudo (caduco) como está. Como sou metido a besta e me sobrou um tempinho, vou jogar dois gravetos verdes nessa acanhada fogueira.

    Não entendeu nada, né? Eu explico. O artigo em questão compila uma série de reclamações que Steve Denning, autor de The Leader’s Guide to Radical Management (Jossey-Bass, 2010), publicou na revista Forbes. Denning reclama de um certo conservadorismo por parte dos “gerentes” e da “tendência muito antiga de se ignorar ideias novas e ousadas”. Condena, no atacado, a relutância ou desconhecimento dos “gerentes” do que seria o movimento Agile.

    Me surpreendi com uma das conclusões de Denning. A de que os “grandes avanços na área de gestão” obtidos através de métodos ágeis não pegaram no mundo dos negócios porque não foram pessoas ou acadêmicos “de negócio” que os criaram. Foram os nerds, segundo suas próprias palavras. Em outro trecho, uma derrapada comprometedora:

    “O mundo gerencial continua em estado de negação sobre as descobertas dos métodos ágeis. Você pode explorar as páginas da Harvard Business Review e dificilmente encontrará quaisquer referências, mesmo que indiretas, para as soluções que a filosofia ágil oferece aos problemas gerenciais da atualidade.”

    De onde Denning acha que brotaram 80% das ideias que compilamos e etiquetamos como agile, lean etc? Será que ele se lembra que o Scrum, por exemplo, é inspirado em um artigo da mesma Harvard Business Review de janeiro de 1996? E o que dizer dos artigos e do trabalho de Donald Reinertsen, autor de Managing the Design Factory¹ (The Free Press)? Ele aparece na mesma InfoQ e está na edição atual (maio/2012) da edição brasileira da HBR, com o artigo Seis Mitos do Desenvolvimento de Produtos. Qual é o problema? O fato de vários autores (de negócios) não revenderem a marca Agile, apesar de a influenciarem e serem influenciados por ela?

    Eu só boto Bebop no meu Samba…

    … quando Tio Sam tocar um tamborim”². Esta citação apareceu em um papo que rolou com o amigo Leandro Mendonça. Ele trabalha em outro universo: Publicidade. E tem como uma de suas diversões favoritas ver como a patota de TI reinventa a roda, registra patente e bebemora o feito. O artigo em questão, além de comprovar este ciclo, não contribui em nada para uma mudança da situação. Pelo contrário, parece fechar portas. Veja, por exemplo, as “dez objeções perenes da gestão” apresentadas:

    1. “O Agile é apenas para estrelas – Ao ser confrontado com a escolha entre o alto desempenho e a mediocridade, a gerência tradicional escolhe a segunda”.
      pv: Existe mesmo algum gerente que, em sã consciência, faz opção pela mediocridade?
    2. “O Agile não se enquadra em nossa cultura organizacional – No mercado dos dias atuais, ou as empresas mudam sua cultura ou morrem. A cultura das empresas deve ser ágil”.
      pv: Não sei de nada, mas desconfio de muitas coisas³. Desconfio, por exemplo, que mudanças impostas, arbitrárias (“deve ser ágil”), são mais efêmeras que bolas de sabão.
    3. “O Agile apenas funciona para projetos pequenos – Já existem soluções óbvias para se lidar com projetos grandes…
      pv: Impressionante como “óbvio” constantemente se parece com álibi (“não tenho uma boa resposta”) ou falta de respeito (“você é burro e não perderei meu tempo contigo”).
    4. “O Agile requer que as equipes estejam no mesmo lugar – … pode-se usar tecnologias para manter a comunicação aberta e contínua”.
      pv: Nenhum gerente sabe disso. Mal sabem que já inventaram o telégrafo!
    5. “O Agile é fraco em processos gerenciais – A não ser que você escolha uma metodologia ágil que já atenda a todos os processos necessários, é importante juntá-la com outra que supra os processos não cobertos”.
      pv: Difícil imaginar resposta pior. Ou o Agile deixou de questionar os “processos necessários e não cobertos”?
    6. “O sistema de recompensas individuais de nossa empresa não se encaixa no Agile – É o sistema de recompensas que está errado, não o Agile. Mude o sistema”.
      pv:  Mude o sistema e tente explicar para o Zé, que rende quatro vezes mais que o João, porque ambos passarão a receber a mesmíssima recompensa. Em Management 3.0, Jurgen Appelo nos explica que “não há nada inerentemente errado com sistemas de recompensas individuais. Eles só se tornam um problema nas mãos de ingênuos que desconhecem seus riscos”.
    7. “O Agile é algo passageiro – Não se trata de uma solução para todos os problemas… O Agile é a solução para um problema particular, ou seja, a reaproximação de uma execução disciplinada com a criatividade e a inovação”.
      pv: A questão, ou, usando os termos do artigo original, a “objeção perene” era outra. Agile é passageiro? Nada, em nenhum dos dois universos, que passe dos onze anos de vida pode ser classificado como “passageiro”. Ele veio para ficar? Meu caro, além da beleza da Catherine Deneuve, da estupidez humana e das embalagens de plástico, o que mais veio para ficar?
    8. “Há ideias melhores que o Agile – Em vez de entrar nessa briga, prefira buscar os aspectos comuns entre estes movimentos e junte forças para obter um resultado mais efetivo”.
      pv: Santa saída estratégica pela direta, Batman! Sempre existirão ideias melhores que outras, dependendo do contexto. Como Agile também se apresenta como “cultura” e “filosofia”, talvez valha a pena “entrar na briga” ao invés de fugir ao primeiro desafio apresentado.
    9. “Nada de novo aqui – Todos os componentes individuais do Agile já existem há algum tempo. O que é novo é juntar todos estes elementos de uma maneira coerente e integrada”.
      pv: Acho que fui mais corajoso ao afirmar anteriormente que 80% dos componentes do Agile já existiam. O que a resposta acima omitiu foi a origem desses componentes. Não estaria neste reconhecimento uma boa arma para vencer as “objeções perenes” dos gerentes?
    10. “Não é uma comparação justa? – Introduzir Agile (de verdade) significa expor todos os truques encobertos que os gerentes, em hierarquias tradicionais, utilizam sobre seus subordinados para manter o poder”.
      pv: E assim Agile vira o sol que vai revelar todos os segredos dos gerentes e, de quebra, dar uma desinfetada no ambiente. Talvez esteja aqui, nesta ingênua acusação, a principal razão pela qual ainda temos muitos gerentes relutantes em relação ao Agile. Caramba, eles foram apontados como os inimigos desde o início. Appelo de novo: “Acredito que o desenvolvimento Agile negligenciou a importância da gestão. Se os gerentes não sabem o que fazer e o que esperar de uma organização Agile, como esperar que eles se envolvam na transição para o desenvolvimento Agile? Qual é a mensagem aqui? Se é apenas ‘não precisamos de gerentes’, então não surpreende o fato de estarmos conversando sobre ‘objeções perenes’”.

    Não estou isentando os gerentes de nada. Quem sou eu para isentar alguém de qualquer coisa? Existem sim os gerentes relutantes e ignorantes e muitos deles seguirão existindo, não importa o que façamos ou quanto gritemos. Mas passou da hora da gente, dos que acreditam na proposta Agile, assimilarmos um velhíssimo dito chinês, aquele que ensina: “quando apontar o dedo para alguém, repare para onde apontam três dedos”. É de quem vende uma ideia, de quem propõe uma mudança, o ônus da prova. Show me the money!, dizem os caras de negócios. Enquanto não provarmos nossas teses com fatos, números e valores, estaremos apenas e simplesmente (simploriamente?) filosofando.

    Os caras não colocarão bebop no samba deles enquanto não pegarmos nos tamborins, mora?

     

    Notas

    1. São raros os trabalhos do mundo Agile que souberam equilibrar, como Reinertsen neste livro, as preocupações com Organização, Processos e Produto (Arquitetura do). Uma honrosa exceção é Agile Project Management, de Jim Highsmith. Reparem como nossos papos andam monotemáticos: processo, processo, processo… Scrum, Kanban, baranga-dã… Outra diferença fundamental do trabalho de Reinertsen, já demonstrada anteriormente em Desenvolvendo Produtos na Metade do Tempo (Futura, 1997), é a preocupação com a Economia – com a grana que o produto pode gerar e com os custos que o projeto deve suportar.
    2. Foi Jackson do Pandeiro quem escreveu “Chiclete com Banana” e desafiou Tio Sam a pegar um tamborim. Foram Leandro Mendonça e Pedro Braga que me deram esse presente. Ou será que surrupiei a ideia indevidamente?
    3. Foi Guimarães Rosa quem originalmente disse não saber de nada mas desconfiar de muita coisa.
    4. Tamborim, a imagem utilizada, é de Schröedinger’s Cat.

     

  • Marco Regulatório da Silva

    Marco Regulatório da Silva

    Brasileiros gostam de ser guiados. Encontram segurança quando olham para cima em uma organização hierárquica e encontram autoridades. Acham conforto quando ouvem, lá de cima, um grande conjunto de leis e regras. Conforto não significa obediência, o que invariavelmente resulta em novas leis e novas regras. Esta é uma leitura possível deste estudo de Geert Hofstede, que me foi apresentado por Shane Hastie no final do ano passado. Dá o que pensar, não? O nosso incomensurável e complexo sistema legal seria produto de uma cultura – do gosto por ser regulado.

    Estamos bem servidos e já não estranhamos o fato dos poderes executivo e judiciário também legislarem. Afrouxamos regras para a criação de regras – através de medidas provisórias, por exemplo. Só a legislação tributária recebe em média sete novas inserções diárias em seus incontáveis alvos e sabores. E pensar que um dia já tivemos um tal Ministério da Desburocratização. Não espanta que ele tenha durado tão pouco. É causa perdida e de pouco apelo popular. É?

    É triste a vida de um povo que depende de leis e respectivas penalidades para saber, por exemplo, onde não é permitido fumar e que não pode dirigir se tiver entornado umas biritas. E parece paradoxal que o desenvolvimento econômico e social da última década não tenha gerado uma redução no número de leis e regras. Pelo contrário, ele aumentou. Até que ponto um sistema tão regulado e restritivo se sustenta?

    A metáfora que cabe aqui é a do sabonete molhado. Esprema-o. Em determinado momento ele saltará de suas mãos. Faltou drama? Troque o sabonete por um passarinho.

    Nossa legislação tributária, burra em sua essência, já escapuliu das mãos faz tempo. Mas não caio na armadilha do volume da carga e nem pretendo discuti-lo aqui. É sua complexidade que não se justifica. Basta olhar todo o aparato necessário para calcular impostos para perceber que há algo de muito podre no país das maravilhas. Se parte dessa complexidade foi pensada para pegar gatos e gatunos, é hora de entender que a mesma complexidade abre buracos na rede por onde passam vazam cachoeiras.

    Mas será o nosso gosto inato por leis e regras desculpa para deixar tudo como está?

    Os Outros Três Dedos

    É tão fácil apontar para o governo, não é mesmo? Está aqui outro traço da cultura tupiniquim, um que passou desapercebido pelo estudo de Geert Hofstede: o costume de se livrar de responsabilidades, de sempre achar que a culpa é de outro. A autocrítica sincera, definitivamente, não figura entre nossas qualidades. Vivemos ignorando um velho ditado chinês: quando você apontar para alguém, veja para onde apontam os outros três dedos.

    A parte endireitada de nossa grande prensa vive dando generoso espaço para empresários e seus representantes repetirem, ad nauseam, o mesmo chororô: a) a carga tributária é altíssima; b) a regulamentação é exagerada e complexa; em outras palavras: é difícil fazer negócios no Brasil. Acho que ninguém em sã consciência negaria a verdade dessas reclamações. Elas são corretas. Serão justas?

    Não da boca de quem, alegando corte de custos, terceiriza alguns de seus processos primários (atendimento a clientes, por exemplo) contratando empresas que alocam seus teleatendentes em uma das cidades mais caras da América Latina. Tão absurda quanto uma alíquota de 50% de algum imposto qualquer é a contratação de serviços de telemarketing localizados na avenida Paulista. Um contrassenso que só não choca porque não é noticiado. Nem vou entrar na discussão sobre taxas administrativas (de serviços financeiros) e o tal spread bancário. São as regras e a consequente complexidade gerada por elas o assunto aqui.

    Toda empresa, em qualquer lugar do globo, está sujeita ao Marco Regulatório imposto por governos e agências reguladoras. Não acredito que chegará o dia em que os negócios confessarão estarem plenamente satisfeitos com o conjunto de regras ao qual está submetido. Sempre existirão aqueles que reclamarão do excesso de regulação ou, na outra ponta, da perigosa porosidade das fronteiras de seu ramo de atividades. Mas para onde apontam os outros três dedos dos reclamantes?

    O quão fácil é fazer negócios com a sua empresa? Está aqui um teste que pode envergonhar muita gente. Pense, por exemplo, no setor de serviços. Lembre-se da última vez que contratou uma apólice de seguros ou um serviço de telecomunicações. Ou então pense, agora como colaborador, no conjunto de regras que sua empregadora impõe. Será que a burocracia criada pelos nossos próprios negócios é assim tão diferente daquela que vem das esferas governamentais? É triste reconhecer que, em muitos casos, é cara de um e focinho de outro. Frutos de uma mesma cultura.

    Acho que as empresas serão mais eficazes em suas reclamações quando servirem de exemplo. Até lá, seu interminável chororô não passará de pura hipocrisia.

    Desobediência Civil

    Já reparou no que fazem algumas classes quando querem chamar a atenção sem fazer uso de greves? Elas adotam a Operação Padrão, também conhecida como Operação Tartaruga. E o que ela significa? Que todas as regras serão cumpridas, sem exceção. Não é curioso que o modus operandi tradicional signifique a mais descarada vista grossa para o procedimento formal?

    E o que dizer das metodologias, que são abandonadas tão logo surja um primeiro desvio não previsto? E daqueles procedimentos ISO-like que só são seguidos em tempos de homologação?

    A quebra de regras, a desobediência civil, é a Regra, não a exceção. Se esses desvios não são inocentes, por outro lado também não são, em sua grande maioria, culpados. Podem ser apenas os sintomas de um sistema que não suporta mais o próprio peso. Um sistema que clama por ordenação e simplificação do jeito que pode. Do jeito que sabe.

     

    Notas

    Repare novamente a foto utilizada no topo deste artigo. Ela mostra uma rua de Zurique, Suíça, praticamente sem nenhum tipo de sinalização. Nem calçada tem. A ausência de regras tornou a todos, motoristas e pedestres, mais cuidadosos. O que parece ser um descuido por parte do governo é na realidade uma delegação de poderes. Que os elementos daquela parte do sistema definam suas regras de convivência. Lao Zi, um filósofo chinês lá dos idos de 600 a.C., dizia que o controle inteligente se confunde com a falta de controle – também conhecida como liberdade. Aprendi essas provocações em Management 3.0, de Jurgen Appelo.

    Está longe deste que aqui escreve propor a desregulamentação ampla, geral e irrestrita. Crianças levadas (como o sistema financeiro mundial) e potes de ouro (como licitações públicas) precisam e seguirão merecendo boas regras e respectivas palmadas. Pessoas adultas e profissionais deveriam merecer o benefício da dúvida. Sempre.

     

  • Eu Quero Ser Gerente Quando Crescer

    Você já ouviu uma criança manifestar o desejo de ser gerente? Eu não. Mesmo os filhos de gerentes bem sucedidos não parecem se interessar pela posição da mãe ou pai. Talvez porque eles, durante toda a semana de trabalho, cheguem em casa estafados e aborrecidos. Também pode ser porque raramente apareça em um desenho animado ou filme infantil um gerente ou chefe que não seja pintado como um vilão, mau caráter, interesseiro e desumano. Acho que não veríamos com bons olhos uma criança que desejasse tal papel. O que será que aconteceu com a grande profissão do século XX?

    O gerente é uma invenção da era industrial, um mal necessitado pelos verdadeiros donos de negócios que precisavam ganhar escala. Deveriam funcionar como clones parciais e especialistas do manda-chuvas. Um especialista em vendas, outro em finanças e assim por diante. Os gerentes ocupam a camada intermediária de uma organização, entre o topo e os peões. Na teoria, e quase só na teoria, eles defenderiam o ponto de vista tático. Ou seja, trabalhariam com um horizonte de médio prazo. Quem está acima deles enxergaria mais longe. Quem está na base cuida do dia a dia, provavelmente sob os auspícios e chicotes de um supervisor ou líder técnico – um outro nível de gerente que vive a mirar o andar de cima com desejos inconfessáveis.

    A necessidade de uma organização hierárquica criou na marra uma separação que não fazia sentido no século 18 assim como parece não fazer no século 21. Cérebro e mãos foram apartados artificialmente. Tanto que Henry Ford vivia reclamando que “quando contratava duas mãos, o cérebro vinha junto”. À base de pirâmide não era permitido pensar. Seus ocupantes deveriam apertar porcas e deixar todo o trampo intelectual para quem estivesse acima. E assim a posição do cérebro – do gerente – mesmo que limitada, virou objeto de desejo de todos que tivessem um mínimo de ambição. Não era só o maior salário. Era sobretudo o status, o inequívoco sinal de ascensão social.

    Muita demanda, ofertas teoricamente limitadas. Neste jogo político, assim como em governos com inflada base de apoio, inventam-se cadeiras e postos. E o meio da pirâmide inchou para todos os lados. Na linha do tempo estamos entre os anos 1950 e 1980 (lá fora) ou 2000 (aqui no Brasil). Pois é, tem duas ou três décadas que olhamos para este meio de campo e perguntamos: precisamos de tantos gerentes assim? Aqueles que já passaram da página três têm outra questão: precisamos mesmo de gerentes?

    G de Gerente, G de Gargalo

    Se os proponentes dos métodos ágeis adoram falar que gerentes não são mais necessários, não deve surpreender a ninguém o fato deles – os gerentes –  serem tão pouco receptivos à ideia. Com outras palavras, é isso que diz Jurgen Appelo em Management 3.0, publicado em 2011. Desconfio que também sejam eles, os gerentes, os responsáveis pelo bloqueio do principal requisito das iniciativas BPM: a organização por processos. Não por ação, mas por omissão. Afinal, como aceitar e trabalhar por um modelo que não dê uma atribuição minimamente respeitável para os gerentes? Como acatar uma sugestão que, em sua origem, significou a extinção de diversas cadeiras de gerentes?

    Que sejam sabotadas, sutilmente, as propostas de mudanças nada sutis. E provemos nosso valor mergulhando, com todo o tempo e saúde de que dispomos, nas questões do dia a dia. Pagamos para ver quem sabe mais do que a gente. Queremos ver quem nos tira daqui.

    Não espere que um gerente confesse o parágrafo anterior. E não caia na armadilha da generalização. Os gerentes não são ruins por natureza. Mas estão, neste ponto da história, defendendo sua sobrevivência. Nada mais natural. Nada mais humano.

    Mas, e daí? Devemos aceitar que os gerentes, assim como várias outras invenções do século XX, devem ser riscados do mapa? Eles são de fato supérfluos nos tempos da economia do conhecimento e do autogerenciamento?

    G de Gratificante

    Peter Drucker, ao tratar a organização por processos, sugeriu que os departamentos funcionais seguiriam existindo. Não mais com responsabilidades sobre as funções executadas, mas como formadores e provedores de especialistas. Tom DeMarco e Thimoty Lister, em Peopleware, cruzaram caminho semelhante: “o centro de aprendizagem mais natural para a maioria das organizações reside naquela mal falada instituição, na camada intermediária. Isso bate com nossa observação de que as mais bem sucedidas organizações que aprendem possuem um forte time de gerenciamento”.

    Os gerentes não cuidariam apenas de ensinar, mas principalmente de montar e manter um ambiente onde o aprendizado acontece. Será que basta? Claro que não, como demonstra Henry Mintzberg em Managing – Desvendando o Dia a Dia da Gestão (Bookman, 2010). Seu modelo de gestão, ilustrado ao lado, sugere a existência de três planos e duas atividades principais vinculadas a cada um deles: Plano das Informações (comunicar e controlar), Plano das Pessoas (liderar e fazer conexões) e o Plano das Ações (executar e negociar). Repare também que o modelo indica três zonas de atuação: dentro da unidade de negócio, com o resto da organização e fora da organização.

    Não é curioso como Mintzberg parece ignorar ou desconsiderar as sugestões anteriores, de ensinar e prover um ambiente que estimule a aprendizagem? Me arrisco a sugerir a existência de um quarto plano, central, o Plano da Aprendizagem Organizacional. Que também teria duas atividades principais (promover e difundir) e três dimensões (a unidade, a organização e o lado de fora da organização). Creio que este quarto plano responderia as críticas apresentadas por Jurgen Appelo em seu livro (sobre a falta de preocupação, no modelo de Mintzberg, com o Desenvolvimento de Competências e a Melhoria Contínua).

    Não se engane, o modelo seguiria errado. Assim como é equivocada (e simpática) a Martie – monstrinho que representa o modelo Management 3.0 sugerido por Appelo. Porque, como confessa seu próprio criador: “todos os modelos estão errados. Mas alguns são úteis”. O bom gerente desconfia disso. O excelente tem certeza, por isso estuda todos os modelos e tenta colocá-los em prática. Não apenas em busca de paz de espírito e disponibilidade para seus filhos, mas porque ele sabe que seu principal trabalho é fazer com que outras pessoas trabalhem e evoluam. Sua responsabilidade é imensa. Por isso o papel do gerente pode ser tão gratificante.

    Nada disso fará com que seus filhinhos manifestem a vontade de ser gerentes quando crescerem. Não importa. Eles também nunca dizem que serão otorrinolaringologistas.

     

  • TI: O Início do Meio do Fim

    TI: O Início do Meio do Fim

    Este artigo não estava em meus planos, assim como não estava o penúltimo. Aquele acidente gerou conversa boa a partir de sentimentos e colocações ruins. No fechamento daquele texto escrevi que “se a Análise de Negócios seguir submissa à TI, terá o mesmo triste fim“. A colega Cristina Belderrain interpretou que “o fim que aguarda TI é a passagem para a nuvem”. Não era o que eu sugeria. Confesso que, até a participação da Cris, não havia parado para pensar no “fim que aguarda TI”. Vou pensando enquanto escrevo – zeloso a la Veloso (ou não).

    Na resposta onde prometi este artigo eu conclui que “TI já acabou”. E que já faz um tempão! Claro, não estou falando da Tecnologia da Informação de maneira geral, e sim dos departamentos de TI nas empresas que têm outros fins. Saca só esta breve cronologia de matérias de capa de algumas publicações tupiniquins:

    • EXAME, 20/fev/2002: Tecnologia – Como Matar o Desperdício
    • Info Corporate, Jul-Ago/2003: O CEO não manja de Tecnologia?
      Como convencê-lo de que TI é essencial para o negócio
    • Info Corporate, Nov-Dez/2003: CIOs X Usuários: o que precisa mudar nessa histórica rixa
    • EXAME, 4/fev/2004: Tecnologia da Informação – Dá para se livrar dela?
    • Info Corporate, Set/2004: É o fim da TI como a conhecemos
      A área de tecnologia vai mudar para sobreviver. Como fica o CIO?
    • Info Corporate, Mai/2005: A tecnologia perdeu poder?
      Só 20% dos CIOs brasileiros se reportam ao presidente. O que isso significa?

    A Info Corporate não existe mais – e já foi tarde. A EXAME, quando fala de tecnologia, tem dois assuntos:  gadgets da moda e “bilionários” fenomenais, não necessariamente nesta ordem. Não devo ser o único que sente saudades dos artigos do Helio Gurovitz. Mas o que quero ilustrar é que… desistiram. Falar que TI não funciona – não entrega, deixou de ser novidade. Deixou de vender revistas, se é que um dia o fez. E, pelo visto, deixou de motivar soluções milagrosas. Faz tempo que não aparece uma sigla de três letras prometendo mais que político em período eleitoral, não?

    Lembrado pelo amigo Igor Couto, mostro ao lado a explicação do Jurgen Appelo para o estado atual das coisas. Seu alvo é o desenvolvedor de software, mas o modelo serve como uma luva para explicar como e porque os departamentos de TI chegaram onde estão.

    Perdão, mas vou resumir: falta de disciplina e de competência detonam a qualidade e a produtividade. Baixas qualidade e produtividade deixam clientes e usuários muito insatisfeitos, P’s da vida mesmo. O que aumenta a pressão que eles exercem sobre TI. Uma pressão que só faz erodir a motivação e, consequentemente¹, a produtividade.

    Assim, de tanto não entregar ou entregar soluções de péssima qualidade, TI perdeu o direito de dizer NÃO. Onde deveria haver motivação há medo, puro medo. Ciclo montado, circos incendiados diariamente em organizações dos mais diversos portes e ramos de atividades.

    Perdemos muito tempo correndo atrás de extintores e mangueiras. E, preciso dizer, a contratação de analistas de negócios foi só o uso de um extintor diferente. Ferramenta inútil em incêndios de grandes proporções.

    O CLD (Diagrama de Ciclos Causais) do Jurgen sugere três soluções de amplo espectro: Educação e, a partir dela, Competência e Disciplina. Nunca foi segredo para ninguém que qualidade e produtividade dependem desses fatores. Acontece que Educação é investimento de longo prazo. Pronto, consegui colocar em uma frase com oito palavras três termos aparentemente incompatíveis com muitas organizações de TI: Educação, Investimento e Longo Prazo.

    Se Tudo tem que Terminar Assim

    Que pelo menos seja até o fim, diz a letra do Herbert². As letras do Gartner e do McKinsey, traduzidas na Info Corporate de setembro de 2004, não alimentavam nenhuma esperança:

    • O departamento de informática como o conhecemos desaparecerá;
    • Algumas áreas de TI, como infraestrutura, vão mesmo virar commodities e serão inevitavelmente terceirizadas;
    • A TI deixará de ser uma área de suporte aos usuários para ser absorvida pelas próprias unidades de negócio;
    • Não haverá mais espaço para o profissional eminentemente técnico. Quem quiser trilhar carreira técnica deverá trabalhar num fornecedor de tecnologia;
    • Nesse cenário, o CIO tem dois caminhos a seguir: ou se torna um executivo de processos de negócios ou continua a gerenciar ativos de TI, tornando-se, assim, um ser em extinção.

    Dramática lista, não? Dramática, um tanto equivocada e, como este artigo até aqui, pouco construtiva. Não sei se tenho respostas (construtivas), mas meu balaio tá repleto de palpites:

    • A Nuvem não curará aplicações bugadas e mal integradas. Acima de uma inchada camada de commodities residem dados e sistemas que pedem, há tempos, por drásticas revisões. A mesma metralhadora do Gartner já havia sugerido, no final do século passado, uma interessante solução: aposente algo entre 3 e 5 sistemas legados por ano. O remédio pode ser amargo e caro, mas parece ser a única alternativa.
    • Serviços de manutenção de hardware, impressão, suporte ao uso de equipamentos e outros que não lidem nem dependam de conhecimentos do negócio já deveriam estar terceirizados desde mil novecentos e pedrinha. A Nuvem, se bem utilizada, pode tirar outros pesos das costas de TI. Desde que tal movimento não comprometa ainda mais os níveis de serviços atuais.
    • Cogitar que áreas de negócios assumam responsabilidades sobre a administração de TI é ingenuidade que ignora três fatores: i) as soluções que realmente interessam ao negócio suportam processos, não departamentos. A pulverização sugerida só faria aumentar o caos instalado, nada mais; ii) Pouquíssimas organizações possuem uma arquitetura de negócios que não dependa de um mínimo nível de integração e padronização; e iii) unidades de negócio têm suas responsabilidades bem determinadas. Não sei de nenhuma que faça sua própria contabilidade ou limpeza ou folha de pagamentos. Por que assumiriam a gestão de TI?
    • Aquele papo de CIO virando “executivo de processos” era conversa para BOI dormir. Bad trip provocada pela onda BPM que então surgia, nada mais.

    Pois é, TI acabou. Mas, como disse Voltaire em outro contexto, precisaremos (re)inventá-la. Exercício para a próxima semana: se você pudesse desenhar um departamento de TI do zero, como ele seria?

     

    Notas

    1. Descrever diagramas já é um atentado contra a inteligência. Escrever “consequentemente” na descrição de um CLD deve resultar em uns 100 anos de cadeia e solidão, mais ou menos. Perdão!
    2. “Caleidoscópio”, composição de Herbert Vianna gravada pelos Paralamas numa época em que existiam o Rock Nacional e os departamentos de TI.

     

  • UMA Modesta Arquitetura

    UMA Modesta Arquitetura

    Modesta: moderada, sem afetação, sem exagero.

    Arquitetura¹: concebida com o propósito primordial de organizar espaço para determinada finalidade e visando a determinada intenção.

    Este artigo é uma modesta provocação. E uma tentativa de transcrever a palestra “Arquitetura do Negócio: Enxuta & Ágil” que apresentei no último Agile Vale. É que alguns assuntos pedem para ser espalhados. Se você se interessa por arquitetura corporativa, arquitetura de negócios, arquitetura de software, DDD, DSL, métodos ágeis e pensamento enxuto (lean), talvez encontre algo de útil no meio deste longo texto.

    ?

    Peço sua atenção para a definição de arquitetura acima. Particularmente para os termos espaço, finalidade e intenção. Quando arquitetamos algo, nós “organizamos um espaço para determinada finalidade visando a determinada intenção”. Preciso voltar também para um conceito que já apresentei aqui no {finito}, a Tríade Vitruviana. Ela fixa três critérios fundamentais para avaliação de uma arquitetura:

    • Firmitas: a construção é estável, robusta e sustentável;
    • Utilitas: a arquitetura é funcional; e
    • Venustas: é bela.

    A área de TI gosta de adotar termos de outras áreas de conhecimento. Seria legal se, além dos nomes, adotássemos também os conceitos básicos. Já tem um tempinho que acolhemos o termo “arquitetura”. Recentemente, passamos a falar bastante sobre Arquitetura Corporativa. Acho que indicamos que através dela “organizamos espaço para determinada finalidade e visando a determinada intenção”. Qual espaço?

    TI organiza dois espaços, a saber: i) Arquitetura Tecnológica – hardware, infraestrutura de rede e software básico. Significa o que a organização possui; ii) Arquitetura de Informações – bases de dados e repositórios de informações não estruturadas. Indica o que a organização sabe. Esses espaços são organizados “para determinada finalidade”. Qual finalidade?

    TI atende a ou oferece um sem número de finalidades, de funcionalidades. O faz através de sua Arquitetura de Sistemas, que representa todas as aplicações, ou seja, o que a organização faz. E faz esse tanto de coisa porque está “visando a determinada intenção”. Que intenção?

    Chegamos naquela parte da tal Arquitetura Corporativa que justifica tudo, inclusive a própria existência de TI. É a Arquitetura do Negócio, aquela que explica a intenção – para quem e porque a organização faz (oferece sistemas), sabe (informações) e possui (aquele tanto de ferro e software básico). No longínquo mundo ideal, não deveria haver um único centavo gasto em qualquer das três camadas inferiores que não fosse rastreável até a arquitetura do negócio, comprovando um benefício real e mensurável. Sendo assim, é factível supor que tudo começa (e deveria terminar) aqui, na Arquitetura do Negócio. Do que ela consiste?

    Todo e qualquer negócio, independente do porte ou ramo de atividade, é formado por quatro elementos básicos: Objetivos, Recursos, Processos e Regras. Mas estamos falando de Arquitetura do Negócio, o que nos leva novamente para a preocupação de “organizar espaço para determinada finalidade visando a determinada intenção”. O espaço que organizamos é a estrutura da empresa – as pessoas, instalações, móveis, veículos, enfim, todos os seus recursos². A finalidade é representada por todo o seu conjunto de processos, por toda a sua parte dinâmica. Finalmente, a intenção é o grupo de objetivos da organização. Colocando de outra maneira: organizamos os recursos (espaço) de uma empresa de forma que os permita executar ou viabilizar a execução de processos (finalidade) visando a alcançar determinados objetivos (intenção).

    Ao representar a arquitetura de um negócio, mesmo sem querer, sempre utilizamos três visões ou combinações entre elas. A visão do negócio trata dos objetivos, da intenção. A visão da estrutura nos mostra os recursos, o espaço. E a visão dos processos nos dá a finalidade. As representações podem ser ultrasofisticadas ou de uma simplicidade risível. Não é minha intenção debatê-las aqui, agora. Mas, para fins ilustrativos, entenda que um organograma é parte da visão da estrutura, enquanto um fluxograma pode compor a visão dos processos. Balanced Scorecards ou simples listas de objetivos representam a visão do negócio. O que nos interessa neste ponto é a “organização do espaço para determinada finalidade visando a determinada intenção”. Hora de agitar o coreto.

    Muito falamos sobre a dinâmica, a velocidade das mudanças, e a complexidade do atual mundo dos negócios. O que muda tanto? E o que é complexo? Será que tudo?

    Jurgen Appelo, no livro “Management 3.0” e falando sobre a teoria da complexidade, sugere um modelo para estudos: o modelo da Estrutura-Comportamento³. Ele escreveu que nos equivocamos quando intercambiamos os termos “complexo” e “complicado”. E afirma que o que é complexo não é passível de simplificação. Me esforçarei para deixar o papo menos maluco (e menos abstrato).

    Quando tratamos de uma estrutura, o que está em jogo é nossa habilidade para entendê-la. Portanto, uma estrutura pode ser simples ou complicada. Neste sentido um casamento, por exemplo, é uma estrutura simples. Ele envolve, na teoria e em seu início, apenas dois elementos. Por outro lado, uma empresa ou uma cidade possuem uma estrutura complicada – difícil de entender.

    Em outra dimensão está o comportamento e o que é exigida é nossa capacidade de prevê-lo. Um relógio, por complicado que seja (em sua estrutura), tem comportamento bastante previsível. Dizemos que seu comportamento é ordenado. Diferente do casamento, que apesar da estrutura simples, pode resultar em comportamentos bastante complexos. Nesta dimensão temos ainda uma terceira “ordem de grandeza”, o caos. O trânsito de nossas grandes cidades, por exemplo, tem comportamento caótico – ele é praticamente imprevisível. E, só para fechar o exemplo, a estrutura destinada para esse mesmo trânsito não tem nada de simples. Ela é complicada. Uma estrutura é passível de simplificação. Já o comportamento, com certa dose de boa-fé, poderia ser linearizado (o que é complexo ou caótico poderia ser ordenado).

    Coreto devidamente agitado? E o que esse papo sobre complexidade tem a ver com arquitetura? Tudo!

    A “estrutura” do papo acima é o espaço que organizamos. Voltando para a arquitetura do negócio, trata-se exatamente da visão da estrutura, de todos os recursos utilizados por uma organização. E a dimensão do comportamento representa a finalidade da arquitetura, as ações que ali devem ocorrer. No domínio (!) do negócio, refere-se à visão dos processos.

    Um negócio, qualquer negócio, é um Sistema Adaptativo Complexo. O modelo proposto por Appelo nos ajuda a estudá-lo. Sistemas de informação são igualmente adaptativos e complexos. O modelo “Estrutura – Comportamento” nos ajudaria a arquitetá-los? No mínimo, como tentarei mostrar abaixo, justificaria uma “nova” maneira de pensar.

    Quando falamos, geralmente reclamando, sobre a dinâmica dos negócios, devemos entender que o grande volume de mudanças ocorre na dimensão comportamental, ou seja, nos processos. Posso apelar para Pareto? Então vamos fixar que 80% das “mudanças organizacionais” (sic) referem-se às alterações na forma de trabalhar, nos processos de negócios. O restante significa, de fato, alteração na estrutura (demissões, remanejamentos, fusões & aquisições etc).

    Acima eu escrevi que também vivemos reclamando da complexidade dos negócios. Novamente o modelo proposto pelo Appelo nos ajuda a separar o joio (estrutura, no máximo complicada) do trigo (processos, de fato complexos ou até mesmo caóticos). Fiquei com vontade de usar outra metáfora.

    Ao desenhar sua casa, você separou generoso espaço (!) para montar seu sonhado home office (finalidade!). Mobiliou-o com tudo de bom e do melhor e ficou realmente mais produtivo (intenção!) naquela zona (no bom sentido) de conforto (no melhor sentido possível). Mas eis que vem a notícia de um filhinho não planejado e lá se vai o querido escritório de volta para a garagem. Aquele generoso espaço ganhará nova finalidade. Ele mudou? A menos que você tenha derrubado paredes e redimensionado outros cômodos, você não mexeu no espaço – na estrutura da casa. Foi só a finalidade daquele espaço que mudou.

    Uma estrutura, mesmo quando mal e porcamente concebida, é mais estável que o comportamento. Ou, colocando de outra forma, a estrutura é menos instável que os processos. Então, por que será que nossos sistemas de informação raramente refletem essa separação? Até que ponto nossa indisciplinada mistura de forma (espaço) e funcionalidade (finalidade) é responsável pelos altíssimos custos de manutenção e pela dificuldade de adaptação dos sistemas ditos “legados”? Prometo parar por aqui com as questões retóricas. O que vem a seguir é uma proposta para pensar arquitetura de sistemas de uma maneira diferente.

    Arquitetura Enxuta & Ágil

    Se não ficou claro, apesar (ou exatamente por causa) de minha verborragia, nosso objetivo é fazer com que um sistema reflita e respeite a separação entre estrutura e comportamento. Vamos diferenciar o que o sistema é do que o sistema faz.

    Já tem um tempinho que utilizamos classes para representar coisas do mundo real. Apesar de chamarmos isso de “Orientação a Objetos”, o fato é que nossa programação é mesmo orientada a classes. Não importa. Aprendemos nas escolas da vida que um objeto deveria encapsular sua estrutura (atributos) e comportamento (métodos). Temos outro probleminha aqui. Se desejamos representar elementos da estrutura do negócio, então deveríamos esquecer todo esse papo de encapsular comportamento. Essas classes e respectivos objetos que definem o que o sistema é devem ser ignorantes em relação a tudo o que se refira a ação. Quando muito, sabem um CRUDzinho básico. O cliente Mané, por exemplo, não sabe o que é comprar livro ou colocar livro no carrinho de compras. O Mané não sabe nada! Mas pode aprender!!

    Todas as ações, serviços ou funcionalidades, compõem o que o sistema faz. No diagrama ao lado, todas essas interAÇÕES são representadas por papéis (roles). Existem dois tipos: aqueles que sabem o que fazer (methodful roles) e aqueles que só fingem que sabem (methodless roles). A distinção entre os papéis que sabem (methodful) daqueles que fingem saber (methodless) é muito importante. Os últimos funcionam apenas como interfaces. E nós esperamos que as interfaces sofram bem menos alterações do que os métodos propriamente ditos. Novamente a intenção é separar nitidamente aquilo que muda com mais frequência daquilo que pouco se altera no decorrer do tempo. Mas, afinal de contas, do que tratam esses papéis? Simples, são eles que sabem comprar livro ou colocar livro no carrinho de compras, por exemplo.

    Pronto! Agora temos atores (classes e objetos dispostos no lado esquerdo do diagrama) e papéis. Falta dar-lhes um roteiro.

    Peraí Paulo: ou seu exemplo não é lá essas coisas ou então o papo é bem furado mesmo. Afinal, comprar livro ou colocar livro no carrinho de compras não são ações extremamente simples?

    Ações ordenadas ou bastante previsíveis, você quis dizer, certo? Vamos lá: imagine que nosso querido Mané, apresentado ali em cima, seja um cliente preferencial. Como tal, ele tem direito a descontos em todas as compras. Quando ele vê um livro, já sabe seu preço normal e o desconto que merecerá. Ao mesmo tempo, a loja já sabe que o Mané prefere pagar com cartão de crédito. O que significa, além de outras coisas, um prazo menor de entrega. Já o cliente (objeto) José é bem diferente: mal se identificou (a loja ainda não sabe nada sobre suas preferências) e está prestes a fazer sua primeira compra. Os ROTEIROS que Mané e José seguirão são consideravelmente diferentes. Apesar de ambos apenas desejarem comprar o último best-seller da Bruna Surfistinha.

    Ok, o exemplo continua meia-boca. Mas espero que você tenha entendido o fundamental: interAÇÕES bem distintas acontecerão em ambos os casos. Os atores José e Mané desempenharão papéis diferentes.

    Primeiro ponto, aquele que ficou aberto seis parágrafos acima: como Mané e José “aprenderão” a comprar livro ou colocar livro no carrinho de compras? Primeira “mágica”: aquele conhecimento (comprar ou colocar) será INJETADO nos dois clientes (objetos). O termo injetado é muito bom. Lembra-se como Neo, no filme Matrix, aprendeu a lutar kung-fu? Pois é, o conhecimento foi injetado na nuca! É mais ou menos o que estamos fazendo aqui, ensinando (em tempo de execução!) um elemento da estrutura a executar determinada ação.

    Não disponho de tempo, espaço e nem competência para entrar em detalhes técnicos desta sugestão. Só me cabe dizer, por enquanto, que tal “mágica” é possível tanto em linguagens OO mais antigas (como C++) quanto em modernosos dialetos mais dinâmicos (como Ruby). Já já te falo onde encontrar exemplos de código, se isso te interessa.

    De interesse mais geral deve ser nosso segundo ponto, gritado quatro parágrafos acima: o ROTEIRO. Agora ele merecerá outro nome, um pouquinho mais técnico: Caso de Uso. Estranho como algumas pessoas perdem o sentido da palavra “caso”. Gosto de provocá-las usando um termo caipirão, “causo”. Um “causo” é uma história curta, enxuta. Para nós, é uma história de interAÇÕES, sobre o USO de alguma coisa, sobre FUNÇÕES executadas. Portanto, nosso roteiro (ou script) é redigido na forma de uma especificação de caso de uso. E, em tempo de execução, este mesmo roteiro se transforma em um objeto. Objeto que tem um nome bem especial: CONTEXTO. Mané e José, nossos honoráveis clientes (objetos), desempenharão alguns papéis diferentes e outros semelhantes dependendo do Contexto.

    Tempo para uma breve releitura. Você ainda está aqui? Puxa, muito obrigado. Vamos lá:

    Mané e José mudarão muito pouco no decorrer do tempo. Alguns de seus atributos, como endereço ou telefone, podem ser alterados. Sua idade, com certeza, mudará a cada ano. Mas isso não significará nenhum tipo de mudança em sua forma. Já os papéis, as interações ou processos de negócios, podem sofrer mudanças com grande frequência. A porção mais volúvel de um negócio, suas regras, estariam praticamente todas concentradas nos papéis com real conhecimento (methodful roles). Assim, ao contrário do que vemos em grande parte dos sistemas de hoje (ou seria de ontem?), as mudanças ficam concentradas em um só lugar. Elas não gerarão impactos em um sem número de classes e outros elementos. Neste desenho, podemos agregar novas funcionalidades sem gerar praticamente nenhum impacto nos elementos já constituídos. Um novo cenário em um caso de uso é só isso, um novo roteiro – que costura e direciona como os atores desempenharão seus papéis em um novo contexto.

    Hora de dar nome e crédito à proposta apresentada acima. DCI, de Data, Context and Interaction, é o nome da criança. Criança mesmo, que mal tem cinco anos de vida. A primeira parte, Data (Dados), representa a estrutura (o espaço). Já as Interações representam as finalidades, a arquitetura funcional. E o Contexto, por fim, junta tudo. Este paradigma foi sugerido por Trygve Reenskaug, sujeito que tem em seu currículo outro padrão arquitetônico, amplamente conhecido e aceito: o MVC (Model-View-Controller). Já havia apresentado o tema aqui, quando comentei o livro “Lean Architecture“, de James Coplien e Gertrud Bjørnvig. Para você que quer ver e experimentar um pouco de código, creio que este livro seja o melhor ponto de partida.

    UMA Arquitetura

    Muito provavelmente é pura burrice de minha parte, mas quando vejo (de soslaio) altos papos sobre DDD (Domain-Driven Design), DSL’s (Domain-Specific Language) e afins, enxergo pouco ou nenhum NEGÓCIO. Eu sei, os conceitos são amplos demais e não pretendem apenas tratar de sistemas para negócios. Mas eu desconfio que um pouquinho de proximidade não faria mal nenhum, muito pelo contrário. Por isso o DCI, particularmente da forma como foi trabalhado por Coplien e Bjørnvig, me chamou tanto a atenção. Percebi ali uma nítida preocupação com o domínio, a complexidade e a dinâmica dos negócios. Mais que isso, vi naquela proposta uma extensão lógica e natural – o que tentei demonstrar aqui. Arquitetura do negócio e de sistemas podem ser vistas como UMA única arquitetura. É certo que estou sendo tendencioso e otimista demais. Se DCI demorar tanto quanto o MVC para “pegar”, com certeza não estarei por aqui para ver o resultado. O MVC é de 1978!

    Mas eu sou um incurável otimista. Ao testemunhar como ideias “agile” e “lean” se espalham, fico na esperança de ver mais conversas práticas e pragmáticas ganharem espaço nas agendas de todos os envolvidos com sistemas de informação. Preciso achar espaço para registrar uma preocupação. Será aqui mesmo: não basta ser “ágil” pra caramba e entregar na metade do tempo aquele maravilhoso produto, realizando um pseudo e imediatista valor. Teu ROI (sic), prezada(o) leitora, derretará mais rápido que bolsa de valores em tempos de crise se:

    1. Teu rebento, aquele produto, exigir mudanças estruturais toda vez que o negócio evoluir;
    2. O tempo tornar seu produto ilegível e incompreensível para os olhos de outrem;
    3. Seu produto pedir por duas ou três iterações toda vez que um novo cenário ou papel for necessário.

    É curioso e divertido acompanhar como a combinação dos termos “agile” e “lean” tem evoluído. Enquanto algumas dicotomias caem por terra, surgem novos confrontos e contradições. Coplien e Bjørnvig não hesitaram ao colocar várias lenhas nesta estimulante fogueira. Por exemplo:

    • Pensar antes não significa FAZER antes. E se você é realmente “lean”, você PENSA antes de fazer;
    • Pensar arquitetura != BDUF (Big Design Up Front).
    • Esse papo de postergar uma decisão para o último momento (responsável) é perigoso. Porque é difícil descobrir que momento é esse. Mais lógico é decidir na hora em que a decisão é realmente necessária e pronto.
    • Lean é baseado em “uma cultura de parar ou desacelerar de forma a obter qualidade no primeiro momento e maior produtividade no longo prazo.” (Jeffrey Liker, em “The Toyota Way” – McGraw-Hill, 2004);
    • Pensar “lean” é ver o todo – daí minha preocupação que acabou tornando este artigo um recorde pessoal (2.730 palavras até aqui!). Tentei mostrar como Arquitetura do Negócio e Arquitetura de Sistemas compartilham fundamentos (Espaço, Finalidade) e, principalmente, Intenção;
    • Pensar “lean” é ser sustentável – é ter sincera preocupação com o amanhã, com a evolução de um sistema que responde sem ressalvas nem soluços à dinâmica do negócio;
    • E ser “ágil”, nos ensina o Manifesto, é “responder a mudanças” (além de outras coisas, claro);
    • “TDD (Test-Driven Development) pode deteriorar a arquitetura”; e
    • Como sou um chato incorrigível, vou citar até uma lenha aparentemente menor: o que é mais fácil administrar e entregar, 300 e tantas histórias (User Stories) ou 20 e tantos casos de uso?

    ?

    Céus, quase três mil palavras e você ainda está aqui? Espero que de fato aproveite alguma coisa no meio de tanta prosa. Sabe o que é pior? A sensação de mal ter explorado todas as possibilidades do tema. Pior ainda? Aceitar o fato de que minha contribuição não irá muito além disso aqui. Não vou codificar exemplos e é pouco provável que eu participe, mesmo que como observador, do desenho de uma arquitetura conforme sugerida por Reenskaug, Coplien e Bjørnvig. Resta te pedir que me avise sempre que perceber qualquer coisa parecida passando por perto, ok? Tks!

    Observações:

    1. Trecho da definição de arquitetura proposta por Lúcio Costa e surrupiada da Wikipédia.
    2. Não é lá muito “ágil” esse negócio de chamar pessoas de recursos. É feio, eu admito. Mas, por favor, entenda que no frio da teoria uma pessoa pode ser sim um RECURSO utilizado por uma empresa para determinada finalidade e visando a determinada intenção. O que deveria de fato importar é que a empresa não trate uma pessoa da mesma maneira como trata uma mesa ou um carro enguiçado. Mas tem gente que gosta de briga e não será um recurso nunca! Nem no melhor sentido da palavra.
    3. Por uma questão de brevidade (haha!) me limitei a citar o modelo Estrutura-Comportamento proposto por Jurgen Appelo. Saiba que ele compara sua sugestão com dois modelos um pouco mais conhecidos, o Cynefin proposto por David Snowden e o modelo da Concordância & Certeza (Agreement & Certainty) proposto por Ralph Stacey. Jurgen insiste para que recebamos todas essas propostas sempre com um pé atrás: “todas estão erradas… mas algumas são úteis”.
    4. “Spil-skitse-tegning” é o cartoon que aparece lá no longínquo topo do artigo. Pra variar, é do HikingArtist.
    5. Ah sim, caso interesse, está aqui a apresentação utilizada no Agile Vale 2011. Como alertei a amiga Simone, ela deve ser ininteligível se não acompanhada da prosocopeia acima.

     

  • GESTÃO* na Berlinda

    GESTÃO* na Berlinda

    Antes que eu perca a última oportunidade de escrever alguma coisa em julho. Antes que reclamem que há tempo não coloco nada de novo em  nossa Biblioteca. E antes que a leitura dos livros abaixo me faça abandonar tudo e iniciar nova carreira, provavelmente cultivando milho orgânico e produzindo pamonhas, pamonhas, pamonhas…

    ?

    Um bom título alternativo para este artigo seria “Crise nas Infinitas Terras“. Porque o que vemos hoje, entre terras Exatas e Humanas, são crises que parecem não ter fim. “Infinitas Crises em nosso Mundinho” soaria melhor. Não importa. O que incomoda, ou deveria incomodar, é perceber que Economia, Administração, TI e vários outros “campos ou corpos de conhecimentos” passam por maus bocados. Arrisco dizer, com mínimo domínio de causa, que se trata de uma crise de meia idade. Não pretendo me aventurar pelo estranha situação da economia mundial. E, pelo menos nesta entrada, TI não interessa. Quero falar – na realidade, apresentar trabalhos que falam sobre a (triste porém estimulante) situação atual daquilo que conhecemos como GESTÃO (ou MANAGEMENT*).

    Um Livro Bom, Pequeno e Acessível sobre Estudos Organizacionais (2ª Edição) – Chris Grey (com ótima tradução de Raul Rubenich). Bookman (2010).

    Chris é professor de Comportamento Organizacional na Warwick Business School e resolveu, no início deste século (com a 1ª edição deste livro), jogar m… nos ventiladores do campo dos Estudos Organizacionais e da área que conhecemos como Administração. Jogou m…. com estilo, diga-se de passagem, com uma prosa limpa e livre de academicismos. Apesar de (ou justamente por) seu livro mirar, principalmente, os estudantes. Acho que consigo resumir sua “tese” através de um trecho surrupiado da página 65:

    “… a ideia de uma organização burocrática – ou de qualquer outro tipo de organização – voltada simplesmente ao estabelecimento de meios apropriados para atingir determinados fins é fundamental, irremediável e irrevogavelmente defeituosa.”

    Não espere explicações simples. Muito menos sugestões “aplicáveis”. Chris e poucos outros (dois deles apresentados abaixo) anunciam o início do fim reconhecendo humildemente sua incapacidade de desenhar o que viria depois. Conte, isso sim, com um livro bom, pequeno e acessível que: i) mostra zelo pela história da Administração, passando por Weber e Taylor até chegar em Tom Peters, autor (segundo Chris e para meu deleite) de um livro horrível (In Search of Excellence) “para jovenzinhos” (Drucker); ii) tem a imensa coragem de desafiar não um ou outro aspecto do ensino da administração, mas todo ele! (“O ensino da administração é movido para a produção do conformismo. Os imperativos da eficiência, da competição, das relações de mercado, etc. levam à conclusão de que as organizações têm, por necessidade, de manter-se da forma como se apresentam atualmente.”); e iii) dará um certo alívio para todos aqueles que, apesar dos estudos, diplomas e dedicação, seguem aturdidos (quando não perdidos) em seus esforços de GESTÃO e Administração. Alívio? Sim, porque apesar da infinidade de m… atirada ao vento, Chris é otimista: “Parece-me perfeitamente possível que o gerente ou candidato a gerente possa se preocupar com algo mais do que a racionalidade instrumental.”

    Management NÃO É o que Você Pensa – Henry Mintzberg, Bruce Ahlstrand e Joseph Lampel. Bookman (2011).

    Tema e preocupação idênticos – forma totalmente diferente do livro acima. O trio fez uma compilação de artigos, provocações e “máximas” que tenta (e consegue) mostrar que GESTÃO não é o que costumamos pensar. Livro conciso (150 págs.) e eficaz na mira do ventilador. Tanto que, apesar dos destaques que saltam em praticamente todas as páginas, pérolas brotam dos curtos textos. Como, por exemplo, a colocação de que as superstições são diretamente proporcionais as incertezas. E de que elas, as superstições,  “são o veículo pelo qual líderes carismáticos infundem sentimentos de certeza em tempos de incerteza.”

    Os autores (compiladores?) foram felizes na organização dos recortes em sete capítulos, além do “Mosaico” introdutório. Foi particularmente curioso ler um artigo que pareceu muito atual (“O que a Gestão Diz e o que os Gestores Fazem”, de Albert Shapero) e descobrir depois que se tratava de um texto publicado originalmente em 1976 na revista Fortune. Saca só:

    “Mais cedo ou mais tarde, a estranha cultura da GESTÃO baterá em retirada. A cada dia, centenas de milhares de gestores dedicam sua imensa boa vontade e aptidões naturais a compreender o enorme fosso existente entre a GESTÃO e a caótica realidade da vida cotidiana.”

    Mintzberg é conhecido, além de seus tratados sobre estratégia e outros temas, pelas suas críticas ao ensino de Administração e GESTÃO. O livro inclui seu famoso artigo “MBA?, Não, Obrigado!”. É preciso dizer que o livro acaba funcionando como uma bela propaganda  de seu “programa para desenvolvimento de gestores” conhecido como “Coaching Ourselves”. A propaganda (literalmente embutida na forma de um prospecto) não compromete.

    Management 3.0 – Jurgen Appelo. Addison-Wesley (2011).

    Ok, peço desculpas. Trata-se de uma entrada duplicada em nossa Biblioteca. Em fevereiro dediquei generosa resenha ao trabalho do Jurgen. Acontece que tenho duas boas justificativas para a redundância. A primeira, claro, é o fato deste livro ter tudo a ver com os outros dois apresentados acima. Mas, dos três, é o mais Construtivo (acho que deveria dizer “propositivo”). Jurgen apresenta sugestões organizadas em seis visões, todas amparadas em avaliações que reforçam as críticas descritas nos dois livros acima.

    Ok, o subtítulo desta obra promete a “Liderança de Desenvolvedores Ágeis” e o “Desenvolvimento de Líderes Ágeis”. Talvez eu não tenha sido tão claro naquela resenha, mas engana-se quem acha que se trata de um livro dedicado exclusivamente ao Gerenciamento de Organizações que desenvolvem sistemas. Sim, enganou-se o editor e aquele que bolou a chamada da capa. Paciência. Leia com a mente um pouquinho aberta e você perceberá um livro que fala de GESTÃO para organizações do século XXI. Propondo um modelo “errado”, como reconhece Jurgen. Porque, afinal, TODOS estão errados. “Mas alguns são úteis!”.

    Segunda justificativa para o repeteco: Jurgen Appelo estará no Brasil agora em agosto. Vai ministrar um treinamento na AdaptWorks e, graças aos esforços do grupo Rio Agile, apresentará uma palestra na Cidade Maravilhosa no dia 22/agosto. Trata-se de uma oportunidade única de conhecer as ideias deste cara que já é um dos mais requisitados palestrantes e instrutores do Mundo Ágil. Lembrando: não faça deste rótulo (“Ágil”) uma caixinha. E tente fazer o possível para assistir este evento único.

    ?

    Observações:

    • Grafei GESTÃO assim colando Mintzberg. Parece contraditório, mas apela para uma GESTÃO de fato maiúscula. E mantive o termo ciente de que alguns colegas preferem que “Management” seja traduzido como “Gerenciamento” ou “Administração”.
    • “Crisis!“, a imagem utilizada neste artigo, é de autoria de Richard “dipfan”.
    • Milho orgânico? Pamonhas?!? Perdão, apelação idiota. O que estas obras conseguiram de verdade foi me dar novos ânimo e horizontes. Torço para que façam o mesmo por ti. Inté!
  • Management 3.0

    Management 3.0

    Autor: Jurgen Appelo, holandês que se apresenta como escritor, palestrante, instrutor, desenvolvedor, empreendedor, gerente, blogueiro, leitor, sonhador, líder e pensador livre. Figura relativamente nova na Comunidade Ágil. Este é seu primeiro livro.

    Editora: Addison-Wesley (2011).

    Promessa do Subtítulo: Liderando Desenvolvedores Ágeis, Desenvolvendo Líderes Ágeis

    Do que se trata: GERENCIAMENTO. O autor dirige o livro para gerentes “de linha” (de áreas de Desenvolvimento ou Departamentos de TI) reforçando que não se trata de (mais) um livro sobre Gerenciamento de Projetos. Também “filtra” um pouco mais a seleção colocando que o livro é sobre Gerenciamento Ágil. Mas parece que todo mundo que já teve o prazer de conhecer esta obra descobriu que se trata de um trabalho sobre Gerenciamento no século XXI, o século da Complexidade. GERENCIAMENTO em seu sentido mais amplo.

    Três ponto zero?: O gerenciamento 1.0 foi aquele chamado de científico, caracterizado por hierarquias e originado no início do século passado. O gerenciamento 2.0 brota em meados dos anos 1980 e é caracterizado pelas manias e modismos, por patches e add-ons (TQM, BPR, TOC, BsC, Six Sigma etc) que tentavam “corrigir” a versão anterior.

    Então veio a teoria da complexidade e sua aplicação na matemática, biologia, economia e sociologia. Aí chega o Jurgen, mergulha na teoria e em sua aplicação nos mais diversos domínios, e a destila em um modelo que ele chamou de Management 3.0.

    Indicado para: Gerentes, líderes, desenvolvedores, empreendedores, sonhadores, pensadores livres e todos que queiram entender a razão de tudo neste mundo parecer um tanto complicado e/ou complexo e porque todo sucesso não passa de um adiamento do fracasso.

    Contra-indicações: Puristas, extremistas, conservadores, preconceituosos, adoradores de ângulos retos e eleitores do Jair Bosonaro podem sentir um certo desconforto em diversos trechos do livro.

    Breve Resenha: Quem lê livros técnicos sobre um mesmo tema com uma certa frequência vive com a sensação de déjà-vu. Nos últimos tempos engoli, total ou parcialmente, mais de uma dúzia de livros sobre o Desenvolvimento Ágil de Sistemas. Poucos realmente colocaram assunto novo na mesa. Dois deles mereceram entrada nesta biblioteca. O resto girou em torno dos mesmos temas, problemas e sugestões. Às vezes mudando nomes, outras tantas reciclando histórias.

    Jurgen Appelo acaba de colocar o assunto “Agile” em outro patamar.

    Não se trata de um reset, pelo contrário. Jurgen conhece e respeita toda a história que no próximo dia 13 de fevereiro completará dez anos (data da publicação do Manifesto Ágil). Mas ele se apresenta como um pensador livre. E é. Por isso busca coisas com milhares ou milhões de anos de idade ou situações bobas do cotidiano para ilustrar suas colocações e tornar mais palatáveis as ideias e teorias que sustentam seu modelo. Estratégia mais que necessária, porque Jurgen parte de um Corpo de Conhecimentos de Sistemas formado por coisinhas espinhosas como: Teoria Geral dos Sistemas, Cibernética, Teoria dos Sistemas Dinâmicos, Teoria dos Jogos, Teoria do Caos e Teoria da Evolução. Não se assuste ainda. Esta é apenas parte da história que ele conta para justificar o uso do Pensamento da Complexidade (ou Teoria da Complexidade ou ‘simplesmente’ Complexidade, hehe) como base para o seu modelo.

    Perdão, não há motivos para sustos. Jurgen apresenta essas teorias e conceitos para “humanos normais” como você e eu. Primeiro em um único capítulo, o terceiro, pavimentando o caminho que seguiremos. Depois em capítulos que concentram toda a parte teórica de cada Visão proposta no modelo Management 3.0. Cada uma das seis visões da Martie (o monstrinho que Jurgen desenhou para representar o modelo) é apresentada em dois capítulos, um teórico e outro prático. Essa sacada, além de facilitar a compreensão de suas sugestões, permite o planejamento de nossos estudos. Este é um livro para ser estudado, não simplesmente lido. Optei por estudar um visão por dia: o capítulo teórico na parte da manhã, o prático bem depois do almoço.

    Hora de apresentar, afinal, os seis “olhos” da simpática Martie:

    • Energizar Pessoas: “Penso que as pessoas são as partes mais importantes de uma organização e que os gerentes devem fazer de tudo para mantê-las ativas, criativas e motivadas.”
    • Fortalecer¹ Times: “Acredito que os times podem se auto-organizar, e isto requer delegação de poderes, autorização e confiança por parte dos gerentes.”
    • Alinhar Restrições: “Expliquei que a auto-organização pode resultar em qualquer coisa, portanto é necessário proteger as pessoas e os recursos compartilhados e dar para as pessoas propósitos claros e objetivos definidos.”
    • Desenvolver Competência: “Também acredito que os times não podem atingir esses objetivos se seus integrantes não forem capazes, e que os gerentes devem contribuir para o desenvolvimento da competência de cada um deles.”
    • Desenvolver² Estrutura: “Muitos times trabalham no contexto de uma organização complexa, por isso estou convencido de que é importante considerar as estruturas para melhorar a comunicação.”
    • Melhorar Tudo: “Também penso que as pessoas, times e organizações devem continuamente melhorar tudo de forma a adiar o fracasso o máximo possível.”
    • “Finalmente, acho que a apresentação acima está bem fácil de entender, o que significa que ela provavelmente está errada.”

    O resumo acima é apresentado lá no finalzinho do livro, quando o autor confessa: “Sim, meu modelo está ‘errado’”. “Todos Estão Errados, mas alguns são úteis” é o título do capítulo 16. O humor e a honestidade de Jurgen, além, claro, do tanto que ele conhece e estudou, fazem deste livro um marco. Suecos (e seus 1.217 mosquitos), belgas, cubanos e eleitores do Bosonaro terão alguns motivos para reclamar do livro. Acho que nenhum relacionado ao que ele ensina sobre GERENCIAMENTO.

    Alguns Trechos Selecionados, Surrupiados e Livremente Traduzidos:

    “Acho que o Movimento Ágil negligenciou a importância dos gerentes (de linha). Se os gerentes não sabem o que fazer nem o que esperar de uma organização Ágil, como esperar que eles se envolvam na transição para o desenvolvimento Ágil de software? Qual é a mensagem do Movimento Ágil aqui? Se for apenas ‘não precisamos de gerentes’, então não causa espanto saber que transições para o Ágil estão sendo obstruídas ao redor do globo.”

    “Lembre-se que valores Ágeis não são listas fixas com cinco, sete ou doze itens. Este livro é sobre complexidade, não sobre respostas simples.”

    “Nenhum sistema³ que se auto-organiza existe fora de um contexto. E é o contexto que restringe e direciona a organização de um sistema.”

    “Gerentes inteligentes sabem que devem tomar o menor número de decisões possível.”

    “Acredito que um ‘ponto fraco’ do Manifesto Ágil é o fato dele não reconhecer (explicitamente) que todos os projetos de software precisam de pessoas inteligentes, disciplinadas e atentas. O paradigma ‘pessoas mais que processos’ é jóia, até você descobrir que seu time se limita a dois duendes, um papagaio, uma cabeleireira e um gerente de projetos aparentemente brilhante mas que é cego, surdo e mudo. Não há coaching no mundo que faça este time se auto-organizar e entregar um produto bem sucedido.”

    “Disciplina * Habilidade = Competência”

    “A melhor maneira de implementar processos Ágeis é fazê-lo do seu jeito.”

    “Modelos de maturidade são pouco úteis, talvez até um pouco ofensivos.”

    “Se eles podem escovar seus dentes todos os dias para se livrar de cáries, por que não podem escovar o código diariamente para se livrar dos bugs?”

    “Gerentes de projetos estão ali para servir os times, não para controlá-los. Gerentes de projetos estão ali para gerenciar projetos, não pessoas.”

    “Se você introduzir um novo produto de software em um ambiente, o ambiente vai mudar, consequentemente os requisitos para o produto também mudarão.”

    “O valor percebido de uma mudança é proporcional à dor que se sente por não mudar.”

    “Compañero, no hay camino. Se hace camino al andar.”

    Observações:

    1. O termo original é “empower”. Optei por “fortalecer” (times) como tradução porque empowerment normalmente é entendido apenas como “delegação de poderes”. O autor tem objetivos mais amplos e ambiciosos para a palavra.
    2. Outro termo comum que ainda me atrapalha é “grow”. Simples: é crescer… ou aumentar, germinar, florescer, produzir. Optei por “desenvolver” por achá-lo mais coerente com a intenção do autor: “grow structure”.
    3. A palavra “sistema” é utilizada no livro em seu sentido mais amplo. Empresas, times, pessoas e bactérias são sistemas.
    4. Esta entrada ficou longa, muito longa! O livro, em cada uma de suas 413 páginas, fez por merecer. De tempos em tempos me deparo com um título que realmente me “melhora”. Muito. Não vejo a hora de estudá-lo de novo.
  • Um Corpo de Verdade

    Um Corpo de Verdade

    Como prometi no último artigo, vou tentar liberar uma série de textos mais construtivos sobre Análise de Negócios. E por onde eu deveria começar? Já tinha uma ideia. O colega Jefferson Velasco deu o empurrão que faltava ao comentar que o processo de seleção de analistas de negócios (AN’s) costuma ser um tanto confuso e muito exigente. Como não há uma definição amplamente aceita sobre o papel de um AN, pedem e buscam de tudo nos currículos e testes. Esta é a questão que tentarei responder neste artigo: o que devemos cobrar de um AN? O que um AN estuda, aprimora e domina? Afinal, qual é o CORPO de conhecimentos que o define?

    ?

    A sensação de eterno reset me incomoda também. Estou cansado de ver artigos sobre o mesmíssimo assunto. Acontece que boa parte dos problemas que reportei no artigo anterior tem a ver com isso, com a má compreensão do papel e responsabilidades de um AN. Por isso decidi voltar ao básico e arriscar o desenho de um CORPO de conhecimentos. Por favor, esqueça o BABoK por enquanto. Lá no final do artigo eu falo sobre ele e suas diferenças em relação ao corpo aqui proposto.

    Começamos com as duas pernas. São elas que dão sustentação e movem todo o corpo. A perna direita de nosso simpático Woody (O AN Vitruviano) representa o Conhecimento do Negócio. Se a pessoa será analista de Negócios, parece lógico que iniciemos a jornada por aqui, certo? Acontece que “negócio” é um termo tão amplo e abstrato que há o sério risco desta perna ficar superdimensionada ou atrofiada. Precisamos separar dois tipos de conhecimentos do negócio. O primeiro, que vou chamar de básico (mas alguns chamarão de horizontal), é formado por disciplinas… básicas. Disciplinas que são aplicáveis em negócios de qualquer ramo ou porte. Sim, estou falando de Administração de Empresas, Contabilidade, Finanças e Marketing, principalmente. Calma! Ninguém em sã consciência vai passar a exigir dos AN’s diplomas de curso superior nessas áreas. Mas devem cobrar sim que o AN conheça: planos de contas, lançamentos contábeis, matemática financeira e um monte de etc. Esta é a primeira metade da perna, aquela que vai do pé ao joelho.

    A segunda é menos chata (hehe) e mais cheia de carne e músculos. Aqui podemos utilizar o termo “vertical” para identificar este tipo de conhecimento do negócio. Prefiro chamá-lo de conhecimento especializado. Refere-se à especialização em determinada empresa, área ou ramo de atividades. O AN pode ter experiência no ramo de seguros ou no varejo de drogas lícitas, por exemplo. É relativamente comum, particularmente em anúncios estrangeiros, que as empresas exijam este tipo de experiência, de conhecimento de um tipo específico de negócio. Reparem que citei também a especialização em “determinada empresa”. Neste caso o profissional tem tempo de casa suficiente para “saber tudo” sobre ela. Tipo de domínio muito caro em tempos de pouca fidelidade.

    A perna esquerda representa Conhecimentos de TI. Desenhei assim porque estou falando com AN’s que atuam exclusivamente em projetos de TI. Novamente é necessária uma divisão. O conhecimento básico (do pé até o joelho) condensa: conceitos fundamentais de informática, lógica de programação, modelagem de sistemas, modelagem de bancos de dados, operação de ferramentas de produtividade e colaboração e alguns etc. Há quem questione parte desta lista, principalmente os itens que falam de programação e modelagem. Insisto que um bom AN deve ter tal conhecimento para conseguir se comunicar de maneira mais eficaz com os times técnicos. Pode não ser mandatório, mas sempre será desejável. Dado o perfil de 80% dos AN’s que conheço (com formação em algum sabor de TI), não creio que isso represente um problema.

    A segunda parte desta perna, a exemplo do que aconteceu com a direita, também representa conhecimentos específicos. No caso de AN’s que atuam apenas em uma organização, estamos falando do conhecimento sobre a Arquitetura Corporativa daquela organização. Conhecer a plataforma tecnológica, os principais repositórios de dados e aplicações. Mas é importante destacar que aqui podemos ver o desenvolvimento de outra categoria de especialização: AN’s que atuam exclusivamente em projetos de determinado tipo, de BI (Business Intelligence), por exemplo.

    Como já coloquei, são as pernas que sustentam e movem o corpo. Deficiências em qualquer dos dois tipos de conhecimentos significam dificuldade de locomoção e de aprendizado. CALMA! Todos os AN’s que conheço apresentam alguma dificuldade de locomoção. É natural. Ninguém sabe tudo, e nós estamos falando de conhecimentos muitas vezes voláteis e dinâmicos (particularmente aqueles que chamei de especializados). O bom AN saberá diagnosticar e diferenciar uma unha encravada de um menisco estropiado. E saberá sanar o problema ou encontrar um bom médico. Só deve preocupar mesmo aquele AN que chega manco no fim de um projeto.

    Não estamos aqui para conversar sobre o que um AN carrega no abdômen, então pularemos diretamente para os dois braços. Não foi o acaso que decidiu a posição de cada disciplina no desenho acima. O braço direito de um AN é a Modelagem de Negócios. Porque esta é a disciplina que o ajuda a Entender um Negócio. Reparem que o lado direito dele é só negócio, perna e braço. A modelagem, o entendimento de um negócio, é condição primordial para um bom entendimento dos usuários. Coisa que conseguimos através da Engenharia de Requisitos, o braço canhoto do AN. Todo analista precisa dos dois braços. Mas muitos ainda utilizam apenas sua mão sinistra¹!

    Os braços representam habilidades técnicas que um AN deve desenvolver. É o tipo de habilidade (e conhecimento) mais fácil de ser transferido. É aqui que se posiciona, por exemplo, o programa FAN. Mas é importante notar que o domínio dessas duas disciplinas facilita a evolução das pernas (o desenvolvimento de conhecimentos sobre o negócio e sobre TI). Quem malha – quem faz musculação ou algo parecido – sabe que existem exercícios específicos e outros que movimentam pernas e braços. A analogia se aplica aqui. Por exemplo: quanto mais você praticar a modelagem de negócios, mais conhecerá sobre um negócio ou ramo de atividade.

    Mas braços e pernas são suficientes para a formação de um bom AN? Claro que não. Como o desenho acima ilustra, um AN também tem Coração e Mente. Sobre eles a gente conversa na próxima semana. Inté!

    ?

    Se este é, como o título adianta, um “Corpo de Verdade”, então o BABoK seria um corpo de mentira? Não, não há (muitas) mentiras no BABoK. Mas, como você já deve estar cansado de saber, não vou muito com a cara e o jeito daquele Corpo de Conhecimentos. Se você fizer uma comparação minimamente isenta em relação ao que foi apresentado acima, verá que o BABoK praticamente se resume a um braço esquerdo. Portanto, quem entende a profissão só pelo que viu no BABoK está contratando, formando ou se transformando em um braço esquerdo¹.

    Observações:

    1. Nada contra o braço esquerdo, por favor! Sou canhoto e gosto disso (jogando bola, principalmente). Mas houve um tempo em nossa história que canhotos eram queimados em fogueiras. Tô brincando não. Alguns acreditavam que canhotos eram “coisa do demo”. Daí o surgimento de um termo utilizado até hoje. Em meu certificado de reservista, no campo “Sinais Particulares”, está escrito: sinistromano. Sinistro!
    2. A classificação apresentada neste artigo foi levemente inspirada neste trabalho.
    3. O uso de um Corpo Humano como metáfora para um Corpo de Conhecimentos foi totalmente inspirado (leia-se: surrupiado e adaptado) em uma classificação feita por Jurgen Appelo no livro “Management 3.0“. A diferença é que ele desenhou um “Corpo de Conhecimentos de Sistemas”. E utilizou uma bonequinha medonha para representá-lo. O livro, excepcional, vai furar fila e aparecer muito em breve aqui na Biblioteca do finito.
    4. O “Woody Witruviano” é obra do Aldo Cavini Benedetti e foi disponibilizada no Flickr com licença CC (by-nc-sa).