Como tinha anunciado em um post anterior, participei do evento “Software Innovation” nos dias 6 e 7 deste mês em São Paulo. Parabéns à equipe da Converge Comunicações pela organização – achei o evento muito bom, com conteúdo de primeira (exceto duas ou três apresentações cujo único objetivo era vender um produto ou uma empresa – ninguém quer pagar para assistir comercial, certo? Mas não vamos perder tempo com isso…)

Nas apresentações, as empresas que se destacaram foram sem dúvida a SalesForce (óbvio!), a IBM, a Google, a Microsoft e a SaleSolution. Vamos lá:

• Enrique Perezyera, da SalesForce, apresentou um histórico dos modelos de arquitetura de software usados ao longo do tempo, começando com o mainframe nos anos 60, seguido pela arquitetura cliente/servidor nos anos 80, e os aplicativos baseados em Cloud Computing agora. Três grandes benefícios no novo modelo: (1) não há mais necessidade para despesas de capital (CapEx) – o fornecedor é quem deve se preocupar com infra, não o cliente; (2) baixos custos operacionais (OpEx); e (3) software no modelo SaaS é escalável, ele cresce com seu negócio. À medida que projetos de software tradicionais fracassam na maioria das vezes, no modelo Cloud Computing espera-se um retorno de mais de 50% nos primeiros 12 meses. Realmente, a SalesForce é uma empresa pioneira nessa área, e é impressionante como conseguiu chegar, em 10 anos, a 55.000 clientes (dos maiores, como o Citi Group, aos menores com meia dúzia de usuários) e 1.500.000 usuários ativos. Sua plataforma de desenvolvimento permite agilidade e flexibilidade nas customizações e integrações, invalidando a objeção geralmente levantada que diz que SaaS não é flexível nem customizável. E para confortar os mais céticos, todos podem acessar a página trust.salesforce.com para checar o status dos servidores e os tempos de resposta.
• Para Richard Chaves, da Microsoft, o que realmente conta é o poder de escolha do cliente. A estratégia da Microsoft é baseada na oferta de um conjunto de software e serviços (“Software + Serviços”), incluindo SOA, Web 2.0, SaaS e RIA (Rich Internet Applications), dando ao cliente a opção de usar Cloud Computing como extensão do que ele fez até agora, não como uma nova tecnologia que o obriga a jogar tudo no lixo. Em outras palavras, a Microsoft vê o modelo SaaS como “uma evolução, não uma revolução”. A apresentação do Richard incluiu uma demonstração do Windows Azure, a platafora de Cloud Computing da Microsoft. Quem quiser saber mais pode ler isso.
• A apresentação do Cezar Taurion, da IBM, focou na questão de infra-estrutura: o modelo SaaS, na realidade, representa a terceira camada (em termos de nível de abstração crescente), em cima de PaaS (plataforma como serviço – por exemplo banco de dados ou ambiente de desenvolvimento) que, por sua vez, fica em cima da camada IaaS (infra-estrutura como serviço: servidores, storage e hardware em geral). A infra-estrutura é um elemento crítico na cadeia de valor pois o cliente vai confiar no provedor e, portanto, precisa de garantias em termos de segurança dos dados (disponibilidade, resistência a falhas e desastres, e confidencialidade). Em outras palavras, a hospedagem deve ser feita por especialistas (a IBM, por exemplo!) – e não é à toa que investidores de capital de risco não querem bancar a compra de infra-estrutura nos projetos SaaS: não faz sentido. Para Taurion, SaaS representa uma mudança cultural onde acontece de fato uma transferência de risco entre o gestor de TI e o provedor de software: o gestor de TI tem agora um novo papel: focar no negócio (ele se transforma em gestor de soluções, ou gestor de inovação) e deixar o provedor se preocupar com a infra. É interessante notar que o gestor de TI que não colabora com o negócio pode ser agora facilmente “contornado” pelos usuários: a implantação da solução, de fato, não necessita mais de competências técnicas ou do envolvimento da equipe de TI, donde o papel maior dos usuários, e o sucesso do modelo “try before you buy”. As aplicações mais comuns atualmente no modelo SaaS são aplicações horizontais como vendas, colaboração ou RH, e são adotadas principalmente por pequenas e médias empresas; a evolução natural do modelo, passado o processo de aprendizado, conduzirá na oferta de aplicações mais complexas, incluindo aplicações verticais (frameworks para indústrias específicas), com maiores possibilidades de customização, para o mercado corporativo.
• José Martins, da Google, apresentou a plataforma Google Apps que agora suporta Java. Como exemplo da escalabilidade das aplicações SaaS, citou o Google Moderator que foi concebido para postar e votar sobre perguntas a serem feitas em reuniões pequenas – na faixa de 50 pessoas – e foi inesperadamente usado pela Casa Branca no contexto do discurso dos 100 dias de Barack Obama: centenas de milhares de pessoas postaram perguntas, e mais de um milhão de votos foram registrados.
• Renato Romeu, da SaleSolution, observou que o modelo SaaS de fato inverteu a pirâmide dos custos de aquisição de software: no modelo tradicional, o maior custo (44%) provém da implementação, das customizações e do treinamento, enquanto licenças representam apenas 9% dos gastos. No modelo SaaS, temos 68% de “assinaturas” e 32% de implementação, customização e treinamento. E, é claro, no modelo SaaS não temos custos de equipamentos, mão de obra (TI) ou manutenção. Romeu também falou do que eu chamaria o “paradoxo do desempenho crescente” onde os tempos de resposta dos servidores diminuem com o aumento das transações. Explicação: a SalesForce nunca deixa um servidor rodar a mais de 50% de sua capacidade, portanto, à medida que o volume das transações aumenta, novos servidores são acrescentados. Ainda no quesito infra-estrutura, o Romeu fez um paralelo interessante com bancos para responder à preocupação sobre hospedar seus dados no data center de um terceiro: meu dinheiro está mais seguro no banco, ou debaixo do colchão? Acontece a mesma coisa com os meus dados: eles estão certamente mais seguros no data center de um provedor com excelente reputação.
• William Oliveira, da Oracle, levantou uma questão pertinente para fornecedoras de software: considerando um ciclo de depreciação de 3 anos, a migração do modelo tradicional para o modelo SaaS significa uma queda de receitas de licenças para um terço do valor anual atual. Wall Street não pode aprovar… 
• É por isso que a Oracle (80% das receitas provém da venda de licenças) não pode ter o mesmo compromisso com SaaS que a Benner (18% de licenças). Segundo Severino Benner, a empresa está re-escrevendo todo o código-fonte do seu ERP para se adequar melhor ao modelo SaaS, usando os conceitos de “processo” e “papel” que permitem maior flexibilidade e customização para os usuários.   
• Para Mauricio Paiva, da Distribuidora SaaS, o modelo é atrativo para pequenas e médias empresas. O grande desafio para os anos que vêm é amadurecer a oferta para penetrar o mercado corporativo.
• O Leandro Lopes, da L3, apresentou um case interessante onde uma solução de CRM foi implantada como serviço numa organização do terceiro setor, a Liga Solidária (veja este vídeo). Um belo exemplo do atrativo do modelo e do impacto que ele pode ter, incluindo um aumento drástico no número de doadores. Um projeto de CRM clássico teria sido caro demais, e provavelmente nunca teria sido implantado nesta ONG.
• Paulo Gabech, da Serasa, apresentou outro case representativo: o da nota fiscal eletrônica. Segundo ele, comparado com o modelo tradicional, SaaS oferece maior flexibilidade, fácil integração com outras plataformas (SOA e web), uma redução do custo total de aquisição (TCO) e uma maior independência do fornecedor. Do outro lado, os limites do modelo consistem no alto custo das customizações e da integração com sistemas legados, assim como o risco de segurança da informação com os dados hospedados no (ou pelo) fornecedor.
• Pedro Bicudo, da TGT Consult, observou que o modelo de negócios de SaaS é baseado  em soluções oferecidas na modalidade de um-para-muitos, com o pressuposto que é uma “commodity”, ou seja, fácil de acesso e fácil de utilização – portanto, SaaS “não é qualquer serviço”. Similarmente, SaaS “não é para todos os clientes”: o cliente precisa confiar (pois não percebe problemas), e o cliente “não sabe onde fica, quem conserta, como funciona”. Portanto, SaaS deve ser visto como uma nova alternativa de sourcing, sabendo que alguns desafios permanecem sem resposta, particularmente a questão de continuidade do serviço em caso de falência ou aquisição.
• Por fim, para o Delmar Assis, da Informática Corporation, Cloud Computing não é nada mais do que o “velho” ideal de Mobile Computing – acesso às informações e aos aplicativos a qualquer hora, em qualquer lugar.

Quanto tempo vai levar para fazer algo que nunca fez antes? Quanto vai custar? Resposta honesta: não sei. Resposta que a maioria vai dar para salvar sua carreira: acho que vai levar uns, hum, 3 meses… A realidade é que as pessoas não sabem, a priori, fazer estimativas, e isso é perfeitamente normal pois estimar é um exercício de tentativa e erro que requer disciplina e alguma experiência antes de começar a dar certo. O perigo é quando estimativas impossíveis ou não-realistas ameaçam o sucesso do seu projeto – veja as situações seguintes, muito comuns:

• A síndrome do “pentadigital oscilante”: é aquela mão suada, descrita acima, cujo dono declara sem convicção e sem fundamento que algum trabalho vai levar, hum, 3 meses… Fala sério…!
• A política do N – 1: o presidente da empresa chama o vice-presidente de tecnologia e diz: preciso do projeto entregue em 6 meses. O vice-presidente chama o diretor de TI e pede a entrega em 5 meses. O diretor de TI chama o superintendente… Bom, entendeu a lógica… Quando chegar ao programador, o projeto deve ser entregue – sob pena de demissão por justa causa e humilhação pública – em 1 mês… Coitado!
• A política do N + 1: em organizações mais democráticas do que a que acabei de descrever, o supervisor pergunta ao programador: quanto tempo? 6 meses, responde o programador competente, seguro de si. Ao gerente de projetos, o supervisor dirá: podemos entregar em 7 meses. O número que o superintendente escutará será 8 meses. E assim por diante, até o presidente que receberá uma estimativa de 12 meses. Resultado: o projeto é cancelado. À noite, entre duas lágrimas, o presidente dirá à sua esposa: precisava da entrega em 6 meses!

Histórias de coragem, sucesso e cinismo

Estimativas são sempre um assunto espinhoso em projetos de TI. Para ilustrar, vou relatar alguns exemplos da vida real:

• Em uma operadora de telefonia, tínhamos exatamente 3 meses para entregar o sistema. Um atraso de um dia, e a operadora corria o risco de perder sua licença. É claro que a gerente de marketing queria tudo nesses 3 meses… O que fizemos? Um trabalho contínuo, dia após dia, de educação do cliente; repetimos milhares de vezes que tínhamos de lançar em 3 meses, que devíamos focar em ter um sistema bem simples para começar, e que podíamos introduzir novas funcionalidades depois. Funcionou: o sistema entrou em produção em 3 meses, e implementamos os demais requisitos da gerente de marketing em fases posteriores;
• Em outra operadora de telefonia, tínhamos também 3 meses para entregar um projeto altamente complexo envolvendo uma dúzia de serviços de dados. Sentamos com o time, avaliamos a situação e chegamos à conclusão que precisávamos de pelo menos 1 ano para entregar. Levantamos a mão e avisamos ao negócio que não dava para entregar em 3 meses. O projeto foi suspenso temporariamente e os termos do contrato renegociados. O grande benefício neste caso, além de trabalhar com estimativas mais realistas, foi que o negócio teve uma oportunidade para revisar sua estratégia e definir um plano com prioridades estratégicas claras, factível do ponto de vista dos recursos de TI disponíveis. O projeto foi um grande sucesso. Vale a pena notar aqui que a atitude de levantar a mão demostra o alto nível de compromisso do time com a ética profissional;
• Em um projeto de P&D, tecnicamente desafiador, com um assunto novo para mim e para boa parte do time e que, invariavelmente, foi vendido com um prazo e um orçamento surrealistas, ficou claro depois de um tempo que não tinha como fazer estimativas de alto nível para a entrega total do produto – qualquer micro-tarefa requeria pesquisas aprofundadas e podia se tornar um projeto em si. Felizmente, o cliente entendeu muito bem a situação – mas precisava ter visibilidade sobre o andamento do projeto em todos seus detalhes. Implementamos um sistema de rastreamento de tarefas inspirado na metodologia chamada Issue-Based Development, colocamos todas as tarefas no cronograma e implantamos um processo de revisão diária do cronograma com comunicação, diária também, com o cliente. O índice de satisfação do cliente passou de 3.0 para 4.5 (o máximo sendo 5.0);
• Em um grande banco, também lidamos com um projeto vendido com estimativas absurdas. Bancos são geralmente ambientes altamente hierárquicos e políticos: os caminhos para escalar problemas são bem claros – mas quando alguém levantou a mão para alertar que tinha de fato um problema com o prazo do projeto, o processo engasgou por algum motivo e a alerta não chegou oficialmente à vice-presidência. Só que vice-presidentes não são tolos: eles sabiam também que existia algum problema… Resultado: um projeto onde todo mundo sabe que vai ter meses, senão anos de atraso, mas onde o trabalho continua como se nada fosse… Pior: os vice-presidentes aproveitaram a situação para culpar quem quiseram culpar pelos atrasos – uma verdadeira cultura de culpa se instalou nas equipes. É assim que nasce o cinismo no coração dos profissionais…

Conselhos práticos

O que fazer então para lidar com estimativas? Seguem algumas dicas que aprendi ao longo dos anos, e que achei bem úteis:

• Tenha coragem de levantar a mão quando estiver confrontado com estimativas absurdas;
• Reconheça que existem vários graus de acuracidade nas estimativas: um projeto maduro que já andou por um bom tempo tem mais chances de terminar dentro do prazo e do orçamento que uma empreitada de R&D, por exemplo, que começou ontem. Sempre comunique as previsões junto com o grau de acuracidade correspondente, isto é, gerencie as expectativas;
• Se não der para mexer no prazo ou no orçamento, lembre que pode ter outros graus de liberdade como escopo ou qualidade. Envolva todos os stakeholders e tome uma decisão informada;
• Desenvolva o hábito de coletar métricas de tudo – você não sabe quais poderão ser úteis daqui a algum tempo;
• Incorpore o elemento risco nas suas estimativas – planeje tempo extra por exemplo para aquela planilha que o cliente pode não entregar dentro do prazo;
• Coloque um pouco de “gordura” nas suas estimativas – mas sem cair no exagero do N + 1; ajuste a gordura em função da experiência que o time tem com o trabalho;
• Encoraja seu time a aprender a fazer estimativas de suas tarefas individuais – evite criar uma cultura de culpa: lembre-se que é um processo de tentativa e erro; seja compreensivo; com tempo, as estimativas individuais serão cada vez mais acuradas;
• Crie uma cultura de aprendizado contínuo – faça reuniões periódicas de lições aprendidas e discuta especificamente as estimativas: quais acertaram? quais erraram? por quê?
• E o melhor conselho de todos para lidar com a incerteza do dia-a-dia: oriente seu time a avisar quando perceber que vai atrasar antes de o atraso ocorrer – diga-me “vou atrasar”, não me diga “atrasei”… Isso irá facilitar, e muito, sua vida de gestor…

Fui desafiado recentemente com uma pergunta sobre as melhores práticas de gestão de projetos. Você já deve saber que não acredito em melhores práticas, e que creio que existem apenas boas práticas adequadas a um determinado contexto; então resolvi responder com uma lista das piores práticas. Seguem os 12 pecados capitais de gestão de projetos (queria limitar a lista a 7 pecados, infelizmente não deu!):

1. Estar fora do contexto (objetivos estratégicos, stakeholders, cultura, ambiente político, mercado, tecnologia, etc.)
2. Não comunicar, ou comunicar mal
3. Ignorar os riscos
4. Não ter um processo de gestão de mudanças
5. Não delimitar o escopo do projeto com clareza
6. Negligenciar o acompanhamento financeiro do projeto
7. Esquecer-se das pessoas, focar nos processos
8. Estimativas impossíveis ou não realistas
9. Monitorar o plano, e não o business case
10. Negligenciar os processos de qualidade
11. Repetir os erros do passado (incluindo este!)
12. Acreditar no poder das melhores práticas

Irei falar desses pecados em posts futuros, com o objetivo de tirar alguma lição de cada um deles. 

A série “Piores práticas em gestão de projetos” está aberta… Participe da discussão desde já deixando um comentário abaixo!

Este é o primeiro post de uma série de dois (talvez mais…) sobre o papel do gestor. Escolhi um texto clássico de Henry Mintzberg – The Manager’s Job: Folklore and Fact, Harvard Business Review, Julho/Agosto de 1975 – para ilustrar a visão tradicional que se tem do papel do gestor. Mintzberg acompanhou gestores de diversas organizações durante meses seguidos, observando-os e tentando responder à pergunta: o que é que o gestor faz? No caminho, ele tenta destruir o que ele chama de “visão tradicional”, e que na realidade é a visão introduzida por Henri Fayol no início do século passado, a do gestor que planeja, organiza, coordena e controla. O objetivo de Mintzberg? Nada menos do que propor uma teoria revolucionária do papel do gestor, como pode ser visto neste trecho:

A synthesis of these findings paints an interesting picture, one as different from Fayol’s classical view as a cubist abstract is from a Renaissance painting. In a sense this picture will be obvious to anyone who has ever spent a day in a manager’s office, whether in front of the desk or behind it. Yet at the same time this picture may turn out to be revolutionary, in that it throws doubt upon so much of the folklore that we have accepted about the manager’s work.

No próximo post desta série irei mostrar como as visões tradicionais de Fayol e de Mintzberg não se aplicam ao gestor em um ambiente de TI: as pessoas, a natureza do trabalho e, talvez de forma mais importante ainda, as relações de poder são tão diferentes dos demais ambientes que modelos alternativos devem ser desenhados.

Vamos lá… A visão tradicional do papel do gestor, introduzida por Fayol, consiste em quatro palavras: planejar, organizar, coordenar e controlar. Para Mintzberg, a realidade do dia-a-dia dos gestores não pode ser mais diferente. Pior, não temos resposta à pergunta básica: “o que é que o gestor faz?” Como conseqüências, estamos impossibilitados de ensinar efetivamente a profissão, desenvolver sistemas de informação úteis para o gestor e, de maneira geral, melhorar a prática gerencial. O objetivo de Mintzberg, portanto, é de partir da visão de Fayol e apresentar uma descrição mais útil, baseada em pesquisa sistemática e observações sobre como os gestores de fato ocupam seu tempo.

A primeira parte do artigo de Mintzberg contrasta a visão tradicional do papel do gestor (o folclore) com os fatos. Ao longo do texto, ele chega a conclusões surpreendentes que servem como base para o desenvolvimento subseqüente do raciocínio:

• Na visão tradicional, o gestor planeja de maneira refletiva e sistemática. A realidade é que o gestor trabalha a um ritmo acelerado, suas atividades têm como características brevidade, variedade e descontinuidade. Ele não gosta das tarefas refletivas, preferindo a ação. O gestor parece ser muito consciente do custo de oportunidade do seu próprio tempo, de forma que não seja possível identificar algum padrão na maneira com qual ele organiza o seu tempo. Quando deve planejar, ele o faz implicitamente dentro do contexto de suas tarefas diárias; em outras palavras, os planos só existem na mente do gestor;
• Na visão tradicional, o gestor eficiente não tem obrigações regulares a cumprir, pois ele planeja tudo com antecedência e delega as tarefas para os seus subordinados. A realidade é que o gestor passa uma boa parte do seu tempo lidando com situações excepcionais e executando tarefas regulares tais como rituais, negociações ou o tratamento de informações que interligam a organização ao seu ambiente;
• Na visão tradicional, o gestor precisa de informações agregadas; a melhor maneira de obtê-las é com um sistema formal de informação gerencial. A realidade é que o gestor dispõe de cinco meios de comunicação (documentos, telefone, reuniões planejadas ou não-planejadas e visitas observacionais), e ele tem uma forte preferência pelos meios de comunicação verbais. De fato, as informações fornecidas pelas correspondências são geralmente desatualizadas. Além disso, o gestor parece amar o que poderíamos chamar de “informações fluidas” (soft information), tais como fofocas, conversas reportadas de segunda mão e especulações do gênero: as fofocas de hoje podem muito bem ser os fatos de amanhã. A implicação principal deste ponto é que informações estratégicas da organização serão armazenadas na mente dos gestores, e que eles serão relutantes em delegar, pois precisarão para este fim repassar para outros (e verbalmente) todas as informações que eles detêm – tarefa que leva tempo;
• Na visão tradicional, a gerência está se tornando uma ciência e uma profissão. A realidade é que o “modo de operar” do gestor reside nas camadas mais profundas do seu cérebro, e que qualquer tentativa de descrevê-lo só colocaria a nossa ignorância em destaque. O gestor de hoje procura as informações verbalmente, exatamente como seus pares um século atrás. E a ciência gerencial não o ajuda em nada: ele é sobrecarregado de obrigações e responsabilidades, porém não pode delegar facilmente; além do mais, as próprias características do trabalho gerencial (tarefas breves e fragmentadas, forte preferência pela comunicação verbal) impedem quaisquer tentativas científicas para melhorá-lo.

Além da impossibilidade da ciência em ajudar a melhorar a prática gerencial, as pressões que o gestor tem de enfrentar estão ficando cada vez maiores com a democratização da organização, a redução na liberdade de mandar sem explicações e o aumento das influências externas. O primeiro passo para ajudar o gestor neste contexto, segundo Mintzberg, é de entender de fato qual é o seu papel. Esse entendimento pode ser deduzido a partir do que une todos os gestores em várias organizações: a autoridade formal sobre a organização (ou sobre uma unidade da mesma). Essa autoridade confere ao gestor status, conduzindo a uma série de relações inter-pessoais; essas relações resultam em acesso a informações que permitem a tomada de decisões. Mintzberg constrói então um modelo descritivo detalhando cada um dos papéis identificados:

• Papéis inter-pessoais: O gestor é um representante da organização, portanto ele tem obrigações de natureza cerimonial. Ele também é um líder, responsável pela contratação e o treinamento dos funcionários, e deve motivá-los e encorajá-los. Finalmente, com sua rede de relacionamentos dentro e fora da organização, ele serve de ponte entre seu grupo e os demais;
• Papéis informacionais: O gestor é o “centro nervoso” de sua unidade na organização; ele sabe geralmente mais do que seus subordinados. Ele monitora o ambiente à procura de informações (de preferência verbalmente), ele dissemina essas informações para os seus subordinados e, como porta-voz, ele comunica informações do seu grupo para os demais (interna e externamente);
• Papéis decisionais: O gestor é um “empreendedor”, iniciando (e terminando) projetos de natureza variada à medida que for necessário ou que idéias aparecerem. Ele precisa lidar com distúrbios, respondendo às pressões ou mudanças no ambiente. Ele é responsável também pela alocação de recursos, o seu próprio tempo sendo talvez o recurso principal com que se preocupar. Ele tem o poder para autorizar decisões importantes – é interessante notar aqui que a concentração das informações estratégicas na mente do gestor assegura, de certa forma, a coerência das decisões da organização, pois todas as decisões importantes precisam passar por um único cérebro; porém, devido à complexidade das escolhas que precisam ser feitas, não é incomum para o gestor tomar as decisões de maneira irracional, aprovando por exemplo um projeto não pelo seu mérito ou retorno antecipado, mas sim com base na credibilidade do seu proponente. Finalmente, ele é um negociador – neste caso também, o gestor é o único a deter as informações necessárias para poder negociar de maneira efetiva.

Todos esses papéis são relacionados e interligados, formando um verdadeiro “gestalt” – eles não podem ser divididos entre dois ou mais gestores, mesmo se, dependendo da situação, mais ou menos atenção será dada a um papel ou a outro.

A última parte do texto de Mintzberg é normativa, ele usa a análise e as conclusões anteriores para propor meios de melhorar o desempenho e a prática gerenciais. A questão-chave é a natureza essencialmente verbal da informação gerencial e suas conseqüências: problemas para delegar tarefas, um banco de dados de informações estratégicas concentrado no cérebro de um único indivíduo, e a impossibilidade para o pesquisador de ajudar na melhoria da prática gerencial. Mintzberg sugere as seguintes ações:

• Procurar meios de compartilhar as informações. As tarefas do gestor são cumpridas de maneira superficial por causa das pressões que ele tem de enfrentar. Compartilhando informações com seus subordinados, ele conseguirá efetivamente delegar atividades como tomada de decisão ou negociação e terá mais tempo para se dedicar a, e executar em profundidade, tarefas mais estratégicas;
• O gestor precisa fazer um passo para trás e contemplar a totalidade da situação (a broad picture), evitando assim uma dependência forte em informações fluidas e tomando uma atitude mais racional em relação aos problemas que requerem uma atenção mais séria. Neste ponto, o pesquisador em ciências gerenciais pode ajudar: ele tem o tempo e a tecnologia, enquanto o gestor tem informação e autoridade. O gestor precisa aprender a compartilhar informações, e os analistas precisam aprender a se adaptar às necessidades do gestor;
• O gestor precisa aprender a controlar seu tempo, tornando suas obrigações para sua própria vantagem, e aquelas atividades que ele quer fazer em obrigações. Os gestores bem-sucedidos do estudo de Mintzberg sabem controlar de forma eficiente o seu tempo, tirando vantagens das obrigações; os gestores mal-sucedidos culpam as obrigações pelo fracasso.

O texto encerra com uma reflexão sobre o ensino da profissão de gestor. O texto revelou habilidades importantes como desenvolver relacionamentos com os pares, negociar, motivar a equipe, etc., porém as escolas de negócios têm focado no aprendizado cognitivo. O ensino das habilidades necessárias ao gestor tem de ser considerado seriamente, ao lado dos conhecimentos teóricos, através de exercícios práticos e avaliações contínuas. Mais importante ainda, o gestor precisa ser introspectivo em relação à sua profissão: seu desempenho depende diretamente do seu entendimento do seu trabalho, e é somente com essa introspecção que ele conseguirá aprender continuamente. 

Reconciliando Mintzberg com Fayol

Do ponto de vista da retórica, a estrutura do texto em três partes é adequada ao objetivo implícito do autor: propor uma teoria revolucionária para descrever o papel do gestor. Ele começa contrastando a visão tradicional de Fayol (ilustrada através do “folclore” e sem mais detalhes sobre o significado de planejar, organizar, coordenar e controlar – nem o de comandar, omitido por Mintzberg) com fatos, usando uma narrativa dramática para insistir sobre a enorme diferença entre o folclore e os fatos, vide frases tais como:

The chief executives met a steady stream of callers and mail from the moment they arrived in the morning until they left in the evening. Coffee breaks and lunches were inevitably work-related, and ever-present subordinates seemed to usurp any free moment.

ou 

These five chief executives treated mail processing as a burden to be dispensed with. One came in on Saturday morning to process 142 pieces of mail in just over three hours, to ‘get rid of all the stuff’.

Em seguida, Mintzberg propõe um modelo descritivo do trabalho do gestor, usando sua autoridade formal como único ponto de partida – os diferentes papéis descritos oferecem um quadro adequado para explicar ou justificar as diversas observações feitas na primeira parte do texto. Finalmente, na parte normativa do artigo, Mintzberg faz algumas sugestões práticas que visam melhorar o desempenho e a prática gerenciais. Desta forma, ele espere ter oferecido uma teoria útil do papel do gestor.

Duas premissas fortes norteiam sua argumentação. A primeira é que o folclore que ele descreve provém diretamente da visão tradicional de Fayol, e a ilustra: de fato, o objetivo de Mintzberg é de propor uma visão alternativa à teoria de Fayol, e usa o folclore como ponto de partida para negá-la. Porém, a afirmação que esse folclore ilustra as teorias de Fayol não tem fundamento: primeiramente, a origem do folclore que o autor cita é totalmente omitida (nenhuma referência bibliográfica, nem provas concretas que são crenças geralmente aceitas no mundo acadêmico ou empresarial), levantando sérias dúvidas sobre a legitimidade da abordagem usada no artigo; em segundo lugar, boa parte do folclore apresentado não reflete as teorias de Fayol:

• No folclore, o gestor planeja de maneira refletiva e sistemática. Segundo Fayol, um bom plano precisa ser flexível; para planejar efetivamente, é preciso saber lidar com pessoas e ter uma energia considerável. Além disso, o esforço necessário para implementar o plano, assegurar que a execução segue o planejamento e verificar se alterações ao plano são necessárias é tão importante quanto o próprio planejamento;
• No folclore, o gestor não tem obrigações regulares a cumprir. Fayol recomenda, entre outros, que chefes de departamentos se reúnam regularmente para melhorar a coordenação entre departamentos;
• No folclore, o gestor precisa de informações agregadas. Na obra de Fayol, o gestor precisa de informações detalhadas para montar planos de longo prazo: prioridades e condições do negócio, previsões de longo prazo para a indústria e a economia, análises estratégicas do setor feitas por especialistas da empresa, a contribuição de pessoas-chave, etc.

A segunda premissa forte na argumentação do autor é que é a autoridade que une todos os gestores, em todas as organizações:

Earlier I defined the manager as that person in charge of an organization or one of its subunits. Besides chief-executive officers, this definition would include vice-presidents, bishops, foremen, hockey coaches, and prime ministers. Can all these people have anything in common? Indeed they can. To begin with, all are vested with formal authority over an organizational unit.

Essa visão simplifica o problema, pois ignora pelo menos um outro fator comum a todos os gestores: a responsabilidade. Em uma discussão sobre o papel do gestor, autoridade, responsabilidade e o equilíbrio entre as duas são questões pertinentes, e a omissão de uma dimensão enfraquece a argumentação. É interessante notar aqui que a questão de equilíbrio entre autoridade e responsabilidade é abordada na obra de Fayol, levando a discussão para uma dimensão ética quando o conceito de integridade é introduzido como fundamental para balancear autoridade e responsabilidade, veja esta citação de Fayol: 

The best safeguard against abuse of authority and against weakness on the part of a higher manager is personal integrity and particularly high moral character of such a manager, and this integrity it is well known, is conferred neither by election nor ownership.

A argumentação usada por Mintzberg para justificar seu modelo descritivo é demasiadamente acelerada – o leitor sente a falta de uma base lógica mais robusta:

From formal authority comes status, which leads to various interpersonal relations, and from these comes access to information. Information, in turn, enables the manager to make decisions and construct strategies for his unit.

Mesmo assim, o modelo descritivo em dez papéis não é sem mérito: ele explica os fatos dramaticamente narrados na primeira parte do texto; além do mais, ele explicita os papéis do gestor no quadro mais amplo da organização e do ambiente externo, enquanto as influências externas são implícitas na obra de Fayol.

Minha opinião é que o modelo descritivo de Mintzberg não constitui uma quebra de paradigma, deixando Fayol definitivamente para trás. Talvez ele esteja a um nível de abstração mais baixo, tornando-o mais próximo da realidade do dia-a-dia dos gestores. O estudo de Mintzberg não oferece um modelo revolucionário, tão diferente da teoria de Fayol quanto “um abstrato cubista difere de um quadro da Renaissance”. Ele apresenta uma descrição densa e dramática do dia-a-dia dos gestores, com a qual muitos se identificarão; e certamente um modelo descritivo útil – e complementar à teoria de Fayol. Umas trinta páginas de leitura que recomendo.

Agora, em um ambiente de TI, é outra história…

SaaS é um modelo inovador de software que veio para ficar. Sua empresa não pode deixar de considerá-lo, senão como poderoso instrumento de negócio, pelo menos como ferramenta para reduzir custos.

Para quem não puder participar, irei cobrir o evento neste blog.

Ah… e não tenho nenhuma ligação com os organizadores!

Vou começar este blog com um post sobre profissionalismo, assunto de primeira importância em uma área de TI que sofre de tantos males crônicos, mas que infelizmente anda esquecido pela maioria… 

Médicos, contadores e advogados exercem profissões altamente regulamentadas: o caminho para ser chamado de médico, contador ou advogado é bem definido, e os critérios para chegar lá extremamente rigorosos. O mesmo não pode ser dito das profissões de TI – qualquer um, com alguns conhecimentos adquiridos num quarto de adolescente, pode se auto-declarar programador; um currículo bem escrito pode lhe tornar instantaneamente gerente de projetos experiente, apesar de não ter o histórico de sofrimentos indispensável para desempenhar este difícil papel; pior ainda, para ser engenheiro de testes, não precisa comprovar absolutamente nada!

A Sociedade Brasileira de Computação (SBC) acha isso certo, e com razão – veja sua declaração sobre a questão da Regulamentação da Profissão:

1. Exercício da profissão de Informática deve ser livre e independer de diploma ou comprovação de educação formal. 
2. Nenhum conselho de profissão pode criar qualquer impedimento ou restrição ao princípio acima. 
3. A área deve ser Auto-Regulada.

A argumentação da SBC pode ser resumida da seguinte forma (a justificação do projeto de Lei 1561/2003 pode ser lida na íntegra aqui):

• A informática é uma área fundamentalmente multidisciplinar, e “multidisciplinaridade se constrói sobre as férteis bases da liberdade de atuação profissional”. 
• Conselhos de profissão são necessários quando “o exercício de uma determinada profissão poder causar sério dano social, principalmente relativo à exposição de vidas humanas a riscos”. (Não estamos falando de contadores, certo?)
• Conselhos de profissão “tem a função de proteger a Sociedade contra o mau profissional. Os conselhos, portanto, não são Conselhos de Profissionais, e certamente não é sua função dar-lhes proteção. Para isto existem os sindicatos.”
• “[Na Informática] não há interação direta entre Sociedade e Profissional. [...] o cidadão comum raramente contrata diretamente um profissional liberal para desenvolver um software sob medida. O usual é a aquisição no mercado de produtos acabados [...] Neste caso, controle da qualidade de produto é suficiente para atingir o nível de proteção necessário, e para isto não se requer a constituição de conselhos de profissões, e muito menos de se criar reserva de mercado de trabalho.”
• Esta reserva de mercado de trabalho “pode trazer como benefícios à categoria a redução de competição por emprego”, mas “o preço destes benefícios [...] será pago pela Sociedade, que passará a arcar com um maior custo dos produtos devido ao conseqüente aumento de salários e da mais que provável perda de qualidade dos produtos devido à redução do nível de competição”.
• “É assim nos Estados Unidos, Inglaterra, França, Canadá e Espanha.” 

A SBC defende sua posição no Senado com força, como pode ser visto nesta matéria. É claro que o Brasil não precisa de mais um sindicato, e concordo que o exercício da profissão deve ser auto-regulado – mas o que precisa ser feito neste caso é uma revisão profunda do papel da SBC. Deixar de pensar que a questão da regulamentação da profissão envolva necessariamente a criação de um Conselho da Profissão (no sentido “reserva de mercado”), e começar a se posicionar como um fórum de profissionais que tenha por missão justamente de promover o profissionalismo na área de TI. Não é estranho que esta palavra, “profissionalismo”, não apareça sequer uma vez nas páginas do site da SBC? Toda a argumentação sobre a regulamentação parte do pressuposto que apenas diplomas universitários dariam legitimidade a um profissional de TI – nada é falado sobre aprendizado contínuo ou atualização constante dos conhecimentos, elementos cruciais para que um profissional de uma área tão dinâmica como a nossa possa continuar a ser chamado de profissional ao longo dos anos. A SBC não teria um papel a desempenhar em relação a isto? A SBC, sem necessariamente “regular” a profissão, poderia nos encorajar a atualizar regularmente nossos conhecimentos, nos oferecer cursos e palestras em todo o território nacional, nos dar acesso às ultimas publicações, nos encorajar a pensar sobre questões de ética, nos dar meios de melhorar nossas competências técnicas e não-técnicas (nossa área é tão carente dos chamados soft skills…) – ou seja, a SBC poderia simplesmente promover o profissionalismo na nossa área. A missão da SBC me parece demasiadamente acadêmica; a Sociedade teria tudo a ganhar se tivesse um órgão que, além de suas preocupações com atividades de ensino e pesquisa, atuasse como um fórum de profissionais e como o guardião do profissionalismo nas empresas. A causa raiz de todos os males da área de TI é justamente a falta de profissionalismo, e discordo com o argumento da SBC de que “a população não contrata diretamente serviços profissionais para desenvolver suas soluções do dia a dia, e, portanto, não há interação direta entre Sociedade e Profissional”: há interação sim, não de primeiro grau, mas é a Sociedade (o contribuinte ou o investidor) que sofre quando milhões de reais são perdidos em um projeto de TI fracassado.

É assim na Inglaterra!

Uma profissão auto-regulada então, e uma organização para promover o profissionalismo: é assim na Inglaterra! O programa de profissionalismo da British Computer Society (BCS) nasceu em 2003 e é impressionante por sua ambição e seu escopo. Não vou entrar em todos seus detalhes (se quiser saber mais, veja esta página), vou apenas destacar seus pontos salientes:

• A ambição do programa é de fazer de TI uma profissão respeitada tanto quanto outras profissões mais antigas;
• Seu escopo engloba profissionais de TI, membros de outras profissões, organizações profissionais e outros grupos de interesse, profissionais de P&D e provedores de educação e treinamentos;
• TI não é mais apenas uma provedora de soluções técnicas: TI envolve tanto tecnologia quanto informação, e a profissão de TI faz parte integrante do negócio;
• Profissionalismo em TI deve ser medido não apenas com base em excelência técnica, mas também considerando resultados e impacto no negócio, o que significa:
  • Melhor uso dos recursos de TI;
  • Maior confiabilidade na entrega dos projetos e programas de TI;
  • Custos menores;
  • Melhor reputação da indústria e da profissão;
  • Benefícios econômicos e sociais sustentáveis;
• TI não é apenas uma ferramenta para reduzir custos: TI tem também um papel para gerar receitas.

O programa de profissionalismo da BCS contempla uma hierarquia de padrões profissionais, ou títulos, como por exemplo CITP (Chartered Information Technology Professional), a vantagem sendo que estes podem ser concedidos pela própria BCS, ou por organizações profissionais parceiras seguindo um processo rigoroso, o que resolve elegantemente a questão de multidisciplinaridade. A BCS desenvolveu também o quadro de competências SFIA que contempla várias especializações, de forma que o mesmo título CITP possa ser concedido a profissionais de áreas diferentes como por exemplo gestão de projetos e análise de negócio. Além de servir para a certificação, SFIA é uma ferramenta extremamente útil para as organizações pois pode servir tal qual como pano de fundo para descrições de cargo, planejamento de carreira e desenvolvimento profissional, e gestão de desempenho.

A BCS empregou um esforço considerável para montar um Código de Conduta e um  Código de Boa Prática, ambos com orientações factíveis e pertinentes, e exemplos para não sobrar dúvida na compreensão. O Código de Conduta lista os padrões profissionais aos quais todos os aderentes da BCS devem aderir. Veja alguns exemplos:

• You shall carry out work or study with due care and diligence in accordance with the relevant authority’s requirements, and the interests of system users. If your professional judgement is overruled, you shall indicate the likely risks and consequences.
• You shall not misrepresent or withhold information on the performance of products, systems or services, or take advantage of the lack of relevant knowledge or inexperience of others.
• You shall uphold the reputation and good standing of the BCS in particular, and the profession in general, and shall seek to improve professional standards through participation in their development, use and enforcement. 
• You shall seek to upgrade your professional knowledge and skill, and shall maintain awareness of technological developments, procedures and standards which are relevant to your field, and encourage your subordinates to do likewise. 

O Código de Boa Prática, por sua vez, lista padrões de prática profissional relacionados às “demandas contemporâneas e multifacetadas” encontradas em TI. Ele contém práticas comuns a todas as disciplinas e organizadas nas seguintes categorias:

• Maintain Your Technical Competence 
  
• Adhere to Regulations 
  
• Act Professionally as a Specialist 
  
• Use Appropriate Methods and Tools 
  
• Manage Your Workload Efficiently 
  
• Participate Maturely 
  
• Respect the Interests of your Customers 
  
• Promote Good Practices within the Organisation 
  
• Represent the Profession to the Public

Contém também uma série de práticas específicas por área. Na rubrica “Gestão de Programas/Projetos”, por exemplo, encontramos dicas tais como:

When Managing a Programme of Work

• Advise your customer if, in your opinion, any stage in the programme will not deliver the anticipated benefits.

When Defining a New Project

• Encourage your customer to:
  • Explain fully the corporate objectives that underpin the requirement, the scope, issues, constraints and risks to be addressed.

When Closing a Project

- Honestly summarise the mistakes made, good fortune encountered and lessons learned.

A BCS tem até uma política internacional cujo objetivo é de fazer que a profissão de TI seja reconhecida como uma profissão global, e que a BCS seja vista como uma organização profissional de TI de nível mundial. Ela está aberta a cooperar com outras organizações para estabelecer uma profissão de TI verdadeiramente internacional, e promover consequentemente o profissionalismo organizacional na área.

Bom, é claro que o programa da BCS não é perfeito. Tenho pelo menos duas críticas a fazer: a primeira diz respeito ao Código de Boa Prática que lista uma série de práticas a serem seguidas sem necessariamente contextualizá-las. Um bom profissional não segue boas práticas, ou melhores práticas, simplesmente porque são boas ou melhores práticas; a primeira coisa que ele faz é entender o contexto da sua atuação para depois escolher e customizar práticas adequadas a este contexto. Em outras palavras, não existem melhores práticas – existem apenas boas práticas adequadas ao contexto. A segunda crítica tem a ver com a importância dada às certificações profissionais oficiais: a BCS cria assim de fato um mercado de treinamentos e certificações, com um risco real de ver empresas e profissionais se preocuparem mais com canudos de papel do que conhecimentos e experiência. A Fundação ISEB está ciente do problema, mas na minha opinião mais deve ser feito à respeito.

Mas os resultados estão aí: a BCS tem 65.000 integrantes em mais de 100 países, enquanto a SBC, num país do tamanho do Brasil, tem apenas 4.000 sócios… As empresas na Inglaterra estão começando a perceber o valor do programa de profissionalismo da BCS; cada vez mais vagas de emprego são anunciadas exigindo algum título ou alguma certificação da BCS. Empresas como a IBM ou a Deloitte mantêm parcerias institucionais com a BCS, oferecendo assim aos seus empregados a possibilidade de integrarem automaticamente a BCS, com todos os benefícios que isso implica: dezenas de eventos e palestras grátis cada mês, inúmeras oportunidades de networking, acesso a uma tonelada de publicações online e offline, a possibilidade de integrar e de participar ativamente da vida de grupos de interesse ou grupos regionais… Me juntei à BCS em 2001, e posso dizer que foi um grande diferencial na minha carreira – em entrevistas de emprego, por exemplo, sem contar tudo o que aprendi e todas as pessoas que conheci organizando eventos todos os meses para a Filial Londres/Norte. Olha, um programa como o da BCS, ambicioso e moderno, faz bem à profissão e faz bem aos profissionais.

Uma dimensão ética

A grande Professora Karen Spärck Jones (que tive a honra de conhecer em Cambridge, onde fui aluno do seu marido Roger Needham) foi entrevistada em 2007 por Brian Runciman, editor da BCS e autor do divertido blog oddIT. A íntegra da entrevista pode ser lida aqui, mas veja o que Karen Spärck Jones tem a dizer sobre profissionalismo:

BR: BCS is pursuing professionalism in IT - what are your thoughts on this?

KSJ: I certainly think that professionalism is very important. I took part in one of the Thought Leadership debates, about security and privacy, and I was having an argument with a young fellow there. He was slightly surprised that I said that to be a proper professional you need to think about the context and motivation and justifications of what you’re doing.

A true professional will think like that. With ID cards, for example, I was concerned that people would treat it just as an opportunity to do a good software job, if the government’s got a sufficiently good idea of what it wants. But things like that have a fundamental effect on people’s lives and being a true professional means that you must contextualise your work.

BR: Is there an ethical dimension there?

KSJ: I think there is. This chap, who in many ways was thoughtful, said that his organisation only thinks about what the spec is and whether they can do a good job of it - what I call the first layer of being professional. But the second layer is the rationale for what you’re doing.

You see I could probably write a very good program for choosing people to be killed for some reason, selecting people from a population by a particular criterion. But you might argue that a true professional would say, ‘I don’t think I should be writing programs about this at all.’

The point is that there is an interaction between the context and the programming task itself. And as we know with the privacy debate, getting the system architecture right is extremely difficult. You need a deep understanding of what the whole thing is about to get that right and to appreciate that it still won’t be perfect.

You don’t need a fundamental philosophical discussion every time you put finger to keyboard, but as computing is spreading so far into people’s lives you need to think about these things.

O que fazer na prática?

Na prática, como vimos, há a necessidade de ampliar o papel da SBC para ir além das preocupações acadêmicas e começar a engajar com as empresas brasileiras em um diálogo acerca de profissionalismo. A questão da regulamentação tem de ser encerrada uma vez por todas com a posição final que TI deve ser uma profissão auto-regulada, e um novo capítulo aberto para tratar de profissionalismo. Por que não cooperar com a BCS para tirar proveito da sua experiência e do trabalho de reflexão que ela fez?

Agora, na ausência de um órgão guardião do profissionalismo no Brasil, o que o gestor de TI pode fazer para promover e manter um certo nível de profissionalismo dentro da sua organização?  Seguem algumas sugestões:

• Crie uma cultura de aprendizado contínuo – encoraje seu time a se atualizar o tempo todo, ler livros e artigos, participar e dar palestras…;
• Disponibilize livros, artigos e outros recursos para a sua equipe;
• Assegure-se que todos no time têm uma visão do todo, que entendem o contexto onde atuam e relembre-lhes regularmente de pensarem nas implicações do que fazem;
• Inicie conversas abertas sobre questões como profissionalismo ou ética, apresente suas idéias e escuta as dos outros;
• Faça um trabalho colaborativo com seu time para escrever um Código de Conduta adequado para sua organização.

Não custa muito, e faz uma grande diferença…

O que você acha? Nossa profissão deve ser regulamentada? Qual é sua visão sobre profissionalismo? Deixe um comentário abaixo!

Foto: Aral Balkan