Ser Lean é parte do modus operandus das startups (pelo menos no caso das que trabalham com orçamentos limitados). Crescer com recursos mínimos e carga de trabalho, experimentos e quantidade de projetos crescentes demanda priorização radical do trabalho e a eliminação do desperdício.
Empresas maiores e consolidadas tem mais tempo e recursos, portanto, deveriam ser mais rápidas e ir além das startups. Mas, o foco no recurso ao invés do foco no uso destes recursos e o compromisso de cumprir orçamentos resultam na perda de oportunidades e na priorização do trabalho de acordo com políticas, ao invés da priorização baseada na entrega de valor.
O livro "Lean Enterprise" dos autores Jez Humble, Joanne Molesky e Barry O'Reilly trata das falácias das práticas de gestão tradicionais. Essas práticas frequentemente promovem o "estar ocupado", ao invés de promover a geração de valor (financeiro) rápido e sustentável (através do gerenciamento de múltiplos horizontes de acordo com o ciclo de desenvolvimento dos produtos).
Compreender a distinção fundamental (em termos de estratégia, estrutura, processos, etc) entre a exploração de novas ideias (modelo Lean de Startup) e a exploração de produtos (de sucesso) existentes é um primeiro passo crucial para organizações que desejam se tornar Lean como um todo e não apenas ser Lean em departamentos e equipes específicas.
Os princípios e práticas descritos no livro tem por objetivo criar alinhamento e viabilizar a autonomia não apenas nos departamentos de engenharia, mas também nas áreas de gestão financeira, gestão de programas, governança e e melhoria de processos.
A InfoQ americana conversou com os autores para compreender os desafios e benefícios da aplicação dos princípios "Lean" na organização.
InfoQ.com: O que os motivou a escrever esse livro?
Como consultores na área de tecnologia expostos a diversos tipos de organizações, ficamos frustrados com a forma como muitas delas abordam o uso da tecnologia. As funcionalidades e capacidades da tecnologia cresceram dramaticamente ao longo da última década e os custos caíram muito. Infelizmente muitas empresas e organizações não conseguiram acompanhar esse processo. Apesar de algumas empresas conseguirem gerenciar entregas rápidas através do uso de princípios e conceitos Agile, como Continuos Delivery, vemos que ainda existe uma lacuna na forma como a tecnologia é vista e usada. As organizações ainda investem muito tempo na criação de produtos, serviços e negócios que, simplesmente, não entregam o valor esperado por seus consumidores.
A tecnologia pode reduzir drasticamente o tempo de lançamento de novos negócios e produtos quando utilizada de maneira adequada e tem o poder de transformar o relacionamento entre negócio e cliente. As técnicas e práticas que descrevemos no livro não são novas, e, ainda que tenham sua eficácia reconhecida, muitas organizações não as utilizam. O livro tem como objetivo ensinar aos líderes e gerentes como equilibrar as vantagens únicas do uso de software em todas as etapas dos negócios e dos ciclos de vida dos produtos. A meta é testar muitas idéias, descartando as que forem ruins o quanto antes, a medida que se itera rapidamente as idéias boas, desenvolvendo e cultivando as habilidades dos colaboradores da organização.
InfoQ.com: O livro aborda uma vasta gama de tópicos incluindo gerenciamento de projetos, RH, desenvolvimento de produtos, melhores práticas de engenharia, psicologia, melhoria de processos. Qual seria a categoria adequada para o livro?
O livro é sobre negócios e trata do desenvolvimento de produtos baseados em software das organizações de médio e grande porte. A tecnologia deve deixar de ser entendida como um domínio especializado e exclusivo do departamento de TI. Também é muito ruim enxergá-la como um setor que recebe ordens ou que pode ser terceirizado buscando mão de obra barata que não tem conhecimento ou qualquer relação com o negócio e seus clientes.
Atualmente, todos estamos no negócio da tecnologia. Ainda que as principais atividades de uma organização estejam ligadas a recursos físicos e pessoas, é a tecnologia que permite a entrega dos serviços aos clientes. A economia tem sido impulsionada pela tecnologia. Lideranças de negócios devem ter uma compreensão clara das possibilidades proporcionadas pela tecnologia e criar ambientes que incentivem o aprendizado e inovação tornando esses fatores parte do jogo. Isso requer mudanças fundamentais no gerenciamento e direção de colaboradores ligados ao conhecimento na organização.
InfoQ.com: Em suas experiências como consultores, é possível notar os impactos positivos da adoção de uma abordagem Lean no nível organizacional (não apenas por equipes de desenvolvimento e de operações)?
Com certeza. Isso não é novidade: basta olhar para adoção do Sistema de Produção Toyota pela indústria de manufatura. Outro exemplo é o uso do Lean na área de saúde para melhorar qualidade, segurança de pacientes e engajamento dos empregados. Em alguns aspectos a tecnologia da informação chega atrasada. Barry participou da primeira KataCon esse ano em Miami. O KataCon é uma conferência organizada por Mike Rother e incluiu Jeff Liker e outros líderes do pensamento Lean. Barry falou na trilha de tecnologia da informação que, na verdade, foi a menor trilha com pouco mais de 10 pessoas participando das sessões, quando comparado com mais de 100 pessoas nas sessões de manufatura, saúde, serviços/escritórios.
O foco na entrega de valor para clientes sempre foi a marca de organizações duradouras e de sucesso. Em parte por isso, aqueles que compreendem o poder da mudança que a tecnologia tem e sua influência no sucesso de suas organizações estão prestando mais atenção. Era comum recebermos diretores e vice-presidentes de departamentos de TI para entregarmos novos produtos baseados na web que fossem projetados a partir de uma base de sistemas legados. Desde o lançamento do livro, somos abordados por executivos sênior de inúmeras empresas Fortune 500 querendo saber como começar e de que forma podemos ajudá-los a usar tecnologia para entregar mais valor aos seus clientes.
InfoQ.com: "A ansidedade na aprendizagem é a barreira mais séria para criação de uma organização que aprende e de mudanças organizacionais". Que outras barreiras podem existir?
A principal barreira é a ausência de compreensão, incentivo e suporte por parte de executivos. Apenas falar sobre conceitos Lean não é suficiente. Muitos executivos tem que mudar seu próprio comportamento bem como processos e políticas organizacionais de forma a criar uma cultura que apoia a aprendizagem e experimentação, conforme enfatizado por John Shook, com base na sua experiência na Toyota. Não se muda uma cultura apenas falando sobre a mudança. São necessárias ações concretas.
Um segundo ponto é que leva tempo. Equipes na verdade serão mais lentas a medida que aprendem novos métodos e técnicas antes que seja possível ver as melhorias. Isso requer comprometimento no longo prazo e investimento para manter as mudanças nos períodos difíceis. É aí que lideranças verdadeiras mostram suas qualidades e são necessárias para manter a fé das pessoas e impulsionar a equipe a seguir adiante.
Também, vemos muitas culturas patológicas em que a informação é usada como fonte de poder e não é compartilhada. Nesse caso também se usa medições de desempenho e recompensas para direcionar comportamentos de forma a alcançar ganhos de curto prazo para acionistas, mas que afetam negativamente a capacidade de entregar valor a clientes no longo prazo.
Consistentemente vemos as falhas contaminarem os processos de um negócio de ponta a ponta e afetaram todos os componentes da cadeia de valor. Processos rígidos e estruturas desenhadas para otimizar silos funcionais como Finanças, Risco e Jurídico, inibem a habilidade das equipes de experimentarem e aprenderem ou, pior, as impedem de assumirem responsabilidades e prestarem contas pelo resultado de seu trabalho.
InfoQ.com: Uma das ideias subjacentes no livro é a separação entre os estágios de investigação/descoberta e exploração/execução de um produto. É possível afirmar que existe um conflito desse conceito com as práticas de gerenciamento de programas e produtos prevalentes nas empresas hoje em dia?
Definitivamente existem algumas áreas que estão em conflito com o gerenciamento de projetos tradicional. Na verdade gostaríamos que muitas práticas de gerenciamento de projetos tradicional tivessem o mesmo destino dos pássaros Dodo. No livro, falamos a respeito da mudança de pensamento de projeto para pensamento de produto.
O gerenciamento de programas trata principalmente da gestão de dependências entre equipes trabalhando juntas para entregarem um serviço ou produto. Isso não deveria ser afetado pela separação entre iniciativas de investigação e exploração. Um bom gerente de programa reconhece em qual estágio está cada produto e sabe quando a transição entre estágios de um mesmo produto acontece e são criadas novas dependências.
Para gerenciar a investigação, é necessário um bom gerenciamento de portfólio. Isso é algo que muitas organizações não tem, o que faz com que gastem seu tempo e dinheiro mantendo produtos ultrapassados quando deveriam estar planejando aposentá-los e substituí-los. Esse processo resulta na simplificação do portfólio. Consequentemente, a inovação é desencorajada, pois a maioria dos controle e processos tradicionais são configurados para gerenciar a execução e não o aprendizado.
InfoQ.com: Como uma empresa inicia a mudança de estar focada na execução para a alternância entre investigação/descoberta e exploração/execução de produtos? Esse processo começa no topo, na base ou em ambos?
Para extrair o máximo de valor, a mudança deve ocorrer tanto no topo como na base. Executivos são responsáveis por direcionar a cultura organizacional e criar um ambiente no qual tanto a investigação como a exploração tem sucesso. Também é necessário prestar atenção ao equilíbrio do portfólio conforme mencionado anteriormente.
Equipes na base devem abraçar a tecnologia e métodos que permitirão o aprendizado mais rápido e melhores tomadas de decisões.
InfoQ.com: Reconhecer a ideia de que existem múltiplos horizontes de produto para gerenciar pode ter um efeito muito grande na estrutura organizacional. No caso de organizações com equipes multi funcionais, como é possível saber se as transições entre estados estão sendo realizadas muito cedo ou tarde demais?
Não existe certeza absoluta, mas é possível reduzir riscos e o impacto de uma transição prematura ou tardia avaliando dados reais, fazendo apostas pequenas e evitando o medo de atrasar ou parar algum trabalho completamente.
Delinear um conjunto de princípios guia para cada horizonte em termos de como as equipes são criadas, consolidadas e de como se qualificam para uma transição ao próximo estágio, é um bom começo. Acreditamos que os Serviços Digitais do Governo no Reino Unido tem um modelo muito bom que compartilham com todos em termos de sua transformação digital. Os estágios Descoberta, Alpha, Beta e Publicado descrevem quem e o que estão envolvidos, bem como definem suas respectivas missões.
Ultimamente tem sido deixado a critério de cada organização criar suas próprias estruturas, resultados a serem alcançados e medidas de sucesso, bem como evoluir cada um desses aspectos ao longo do tempo. Executar esse exercício como uma equipe multi funcional é uma ótima forma de incentivar a colaboração, desmanchar silos e alinhar estratégias e objetivos de negócio.
InfoQ.com: Startups de sucesso podem encontrar problemas similares ao fazerem a transição de uma operação direcionada à inovação para uma operação direcionada à execução. Além disso, Startups enfrentam maiores restrições em termos de pessoal e competências. Quais são os conselhos para se tratar essas "dores de crescimento" e evitar se tornar uma organização regida por um esquema de comando e controle?
"Não ferre com a cultura" (citação de Peter Thiel, AirBnB)
A medida que se cresce, o que funciona hoje não irá necessariamente funcionar amanhã.
O papel da liderança é manter um senso de missão e propósito para organização especialmente quanto essa começa a crescer. A partir de então, a liderança precisa alinhar todos os níveis da organização a medida que também trabalha em como delegar autoridade e aumentar o fluxo de informação. Isso é muito difícil. Crucialmente, as ações e comportamento dos líderes vão ditar a cultura que será propagada por todo negócio.
Uma das armadilhas na qual organizações que estão em fase de crescimento caem é acreditar que aumentar estrutura, políticas, regras e processos vai aumentar a eficiência e criar resultados mais previsíveis. Na realidade, isso diminui a eficiência na comunicação e os resultados, apesar de previsíveis, podem não ser bons. Políticas serão necessárias, mas devem ter seu foco na definição de limites e em oferecer direcionamento a respeito de como tomar boas decisões - e não listar regras devem ser seguidas por todos em todas as circunstâncias. Isso vai permitir que as equipes continuem a experimentar e aprender em todos os aspectos de seu trabalho a medida que a organização cresce. É como Reed Hastings, CEO da NetFlix diz, "os melhores gestores descobrem como alcançar grandes resultados ao estabelecer o contexto adequado, ao invés de tentar controlar seu pessoal."
É preciso aceitar que as pessoas que começaram a mudança podem não ser as mesmas pessoa que vão liderar o próximo estágio. Em algum momento será preciso trazer sangue novo para a organização, e outros vão partir por que "as coisas não são como eram antes". De forma simples, o que te trouxe até aqui não vai te levar adiante. É por isso que a disciplina em aplicar os princípios de comando de missão no nível da liderança - estabelecer contexto apropriado, definir resultados mensuráveis em todos os horizontes de tempos e, então, trabalhar com as esquipes de forma que essas possam definir, testar e desenvolver seu próprio caminho em direção aos resultados - é tão essencial.
InfoQ.com: Departamentos de P/D independentes são comuns em empresas de grande porte. Pode-se considerá-los como um anti-padrão bloqueante para uma empresa Lean e, se esse não for o caso, como é possível garantir uma transição adequada para as equipes de implantação?
Departamentos de P/D independentes não são bloqueantes quando trabalham alinhados com os objetivos de negócio e a missão da organização. Existem três grandes armadilhas na qual podem cair. Primeiro, podem estar tão distantes da organização que seu trabalho é completamente desconectado dos objetivos de negócio e outros setores passam a exergá-los como "brincadeira" e sem propósito. A segunda é que surjam grandes ideias no âmbito destes departamentos, mas essas sejam delegadas a equipes que não tem domínio sobre o produto a ser desenvolvido. Finalmente, quando os departamentos de P/D são gerenciados e avaliados em comparação com produtos já maduros acabam esmagados e perdem a capacidade de fazer P/D.
Uma boa maneira de tratar a transição entre P/D independente e equipes de produto é trazer a equipe de P/D (ou parte dela) para a equipe responsável por explorar as ideias.
Finalmente, o P/D deveria ser parte do dia a dia de todas as equipes de produtos para incentivar a cultura de aprendizado e a experimentação. É por isso que a 3M inventou o conceito de 20% de tempo, também adotado pela Google, para encorajar equipes de produto a criar e testar novas ideias. Essa prática além de criar novas ideias também enriquece a experiência de trabalho das equipes.
InfoQ.com: No livro há muitas afirmações que, com certeza, vão chocar executivos nível C e a gerencia tática da maioria das empresas. Uma das mais desafiadoras é empoderar as equipes de produto para que priorizem elas mesmas o seu trabalho (utilizando medições baseadas em economia associadas a valores de negócio), ao invés de apenas tirar itens de trabalho de um backlog pré-priorizado. Podem explicar os pros e contras e qual a viabilidade dessa abordagem considerando, especialmente, organizações orientadas por uma estratégia de comando e controle na qual as equipes sequer são autorizadas a escolher ambientes/ferramentas?
Esclarecendo, extrair itens de trabalho de um backlog pré-priorizado é, na verdade, um bom começo para muitas organizações. Se as equipes de engenharia estão constantemente trabalhando com turbulências resultantes de demandas conflitantes de múltiplos clientes, fazer com que stakeholders se encontrem regularmente e entrem em consenso a respeito da prioridade do trabalho que precisa ser executado, já é um enorme avanço. Esse é um dos insights mais importantes do Kanban, Scrum e de outros frameworks Agile em larga escala.
De qualquer forma, quem testou uma abordagem de seleção do trabalho, divisão em partes e entrega dessas às equipes e o agrupamento do resultado de cada parte, esperando conseguir alcançar metas organizacionais e requisitos desejados por clientes sabe que -- em escala -- essa é uma abordagem de tentativa e erro que toma muito tempo.
É possível alcançar melhorias grandes na produtividade definindo de forma clara e concisa, em termos mensuráveis, os resultados desejados no nível dos programas tanto para organização como para os clientes. Essa definição deve ser realizada com o horizonte de tempo do próximo mês. Feita a definição, deixe as equipes trabalharem para atingir os resultados utilizando um processo baseado em experimentação. Essa abordagem pode ser adotada para o desenvolvimento de produto, melhorias de processo e mudanças arquiteturais de larga escala.
Para fazer tudo isso funcionar, primeiramente é necessário afrouxar a abordagem de comando e controle, e substituí-la por missões e direcionamento claramente comunicados, juntamente com princípios para tomada de decisão e o desenvolvimento de habilidades para enxergar o que está acontecendo a medida que o processo avança.
Em segundo lugar, as equipes de produto devem ser multi funcionais e incluir representação apropriada de todas as áreas do negócio e não somente especialista no desenvolvimento da tecnologia. Os especialistas não devem tomar decisões isoladamente. As decisões devem ser tomadas em conjunto com representantes do negócio e devem ter como foco a entrega de valor para os clientes.
No final das contas, as equipes são responsáveis por definir a melhor formar de entregar os resultados desejados. Usualmente, as próprias equipes tem as melhores ideias a respeito de como fazer o que é pedido e, quando as equipes tem a liberdade de testar suas próprias ideias, é muito maior a chance de que se esforcem para colocá-las em prática. O papel de executivos e gerentes táticos e dar suporte e treinar as equipes.
Esse tipo de abordagem requer disciplina extrema em todos os níveis da organização. É o oposto do caos. A gerencia precisa comunicar claramente e de forma mensurável os resultados organizacionais e os resultados para clientes que são esperados. Os limites para tomada de decisão devem ser definidos, especialmente no que diz respeito a que critérios aplicar quando uma equipe sente que o restante da organização está trabalhando contra os seus objetivos.
InfoQ.com: "Minimizar entregas, maximizar resultados" é outro tema recorrente. Por que (gerentes nas) empresas ainda são obcecados por executar trabalho, ao invés de entregar valor para clientes?
De forma simples, o motivo é que a maioria do gestores ainda são avaliados com base em entregas (Quanto trabalho executei?), ao invés de serem avaliados por resultados (o trabalho que executei tinha algum valor?). Equipes ágeis que reportam velocidade são avaliadas com base na velocidade. Uma equipe ágil que reporta em termos de resultados para o negócio e para os clientes desse negócio são avaliados com base no alcance de resultados para o negócio e para os clientes.
O desafio é que a maioria das equipes estão desconectadas dos clientes e do resultado de seu trabalho que é difícil medir qualquer coisa a não ser entregas. Isso também está relacionado ao contexto do projeto. Equipes de projeto são criadas para entregar funcionalidades. Equipes compreendem que a única razão para sua existência é a entrega de novas funcionalidades. Se não houver funcionalidades para entregar, o projeto deixa de existir. Essas equipes essencialmente caem na armadilha de se tornarem fábricas de funcionalidades e tem pouca preocupação com o resultado do seu trabalho em termos de valor.
Criar equipes de produto que se importam com a geração de valor para clientes permite a criação ciclos de realimentação entre a equipe e as pessoas pra quem se soluciona um problema. Isso permite que a equipe de produto empatize com cliente e compreenda os resultados do trabalho resolvendo problemas reais para esses clientes.
InfoQ.com: O que é "a tolice da otimização local" e quais são os sinais de que uma organização é refém dessa prática?
Isso usualmente ocorre quando uma organização é estruturada em torno de equipes funcionais que são avaliadas por métricas diferentes e conflitantes. A tendência é que as equipes otimizem seu trabalho de forma a atingir os melhores resultados sem considerar as equipes que são impactadas em etapas anteriores ou posteriores do processo fim a fim. Isso não quer dizer que a equipe seja estúpida ou faça isso maliciosamente e ocorre, apenas, por que a equipe nunca vê de fato os resultados das decisões que tomam.
Um bom exemplo disso é o gerenciamento de mudanças técnicas na TI. Equipes de projeto são avaliadas com base na velocidade com que conseguem entregar funcionalidades e trabalham duro para isso aceitando riscos mais altos do que equipes no nível de produção e operação, que são avaliadas com base na estabilidade dos sistemas em produção. De forma a gerenciar a tensão entre essas duas metas opostas, existe um processo de gerenciamento de mudanças. Esse processo é visto como um gargalo custoso por equipes de produto, mas equipes operacionais o usam como forma de limitar a quantidade de erros que vão para produção. No final das contas todos realizam trabalho extra, muitas vezes desnecessário. Se amba as equipes são avaliadas e responsabilizadas pelos mesmo resultados - mais funcionalidades entregues sem downtime ou rollbacks, o processo de gerenciamento de mudança seria visto de forma diferente por todos. Essa é uma das ideias chave do movimento DevOps.
Alguns sinais de otimização local incluem o aumento do tempo de espera para entrega do trabalho entre as equipes, nível de retrabalho elevado, pouca colaboração e confiança entre as equipes, tensão constante e a inabilidade de se trabalhar em melhorias - a orientação para as equipes é: foquem em entregar funcionalidades. O mapeamento da cadeia de valor é uma ferramenta poderosa para expor esses problemas e experimentar com soluções -- desde que se consiga de fato colocar todos os stakeholders, de todas as funções que constam na cadeia de valor, juntos em uma sala.
InfoQ.com: Há muitas criticas sobre as práticas financeiras atuais, em particular a respeito de como planejamentos de orçamento de projetos anuais matam a inovação. Por quê?
Existem várias premissas falhas assumidas pelas organizações quando usam a abordagem tradicional de orçamento anual. A maior delas é assumir que podemos prever como serão o mercado e ambiente local em um futuro não muito distante. Esse processo exige que tiremos de uma bola de cristal números para horizontes entre 1 a 3 anos a frente. É necessário estimar com precisão baseado em métricas como: "O quanto nossas ações vão valorizar como resultado do nosso trabalho?" Dessa forma, a decisão de alocar fundos é baseada nessa métricas com pouco aprendizado válido para suportá-las. Isso não funciona com a taxa de mudança que vemos hoje tanto na tecnologia como nas necessidades de clientes e no impacto que a primeira tem sobre os negócios. De forma simples, é cada vez mais difícil fazer predições com precisão. Pedir que toda uma organização se planeje dessa forma é usar mal seu tempo, pois o planejamento estará errado e todo resultado estará sujeito a seguir um caminho errado.
O outro problema com planejamento anual de orçamentos por projetos é que se assume que, a menos que haja retorno positivo sobre o investimento, o trabalho é inútil. Fundos são entregues a quem oferecer o maior ROI (Return Over Investment). Não existe espaço para experimentação e, a menos que se aparente certeza, não se recebe fundos. Ciclos de realimentação e decisões sobre continuar ou não são tomadas apenas ao final do período de financiamento, depois que a maior parte do dinheiro já foi gasta. Frequentemente não se tem software funcional ou aprendizado válido com base nos quais tomar decisões a respeito da aplicação de fundos futura. É considerado arriscado experimentar quando se usa esse modelo de financiamento baseado em um planejamento anual. É difícil convencer alguém de uma certeza de ROI para algo que não tenha sido realizado ainda.
A inovação deriva da experimentação disciplinada por restrições de forma a encorajar a criatividade, ciclos frequentes de realimentação e ajustes baseados no que foi aprendido. Um dos problemas mais difíceis que os departamentos de TI enfrentam é como ser criativo e inovador quando a maior parte do tempo e orçamento dedicados a operação são consumidos na melhoria e suporte de um portfólio inchado, criado pela área de projetos. Até que se elimine a estratégia de melhoria da TI usando uma abordagem de projetos, vai existir pouco tempo e investimento para inovação técnica acontecer.
InfoQ.com: Conseguir que um departamento financeiro mude sua forma de trabalhar é completamente diferente da implementação das práticas Lean no desenvolvimento de produtos. Como começar?
Mudanças de departamentos financeiros em larga escala são complicadas e usualmente caem na categoria de coisas fáceis de falar, mas difíceis colocar em prática. Requer que todo a equipe de executivos e diretoria da organização acreditem e apoiem integralmente a mudança. Não vai funcionar em organizações em que o retorno de curto prazo dos acionistas é prioridade número um e a recompensa de executivos é baseada em objetivos de curto prazo como resultados bimestrais e preço de ações.
De qualquer forma, quando se começa a discutir o risco financeiro associado a uma abordagem de desenvolvimento baseada em projetos de longo prazo, a conversa a respeito de como se pode mudar é mais fácil. Fale com o departamento financeiro de apostas menores e decisões a respeito do financiamento mais frequentes mesmo para ideias que já tenha sido previamente aprovadas.
O dilema entre capital vs operacional frequentemente vem a tona nessas discussões. Mas, não é tão difícil conciliar ambos. Ainda é possível estimar quanto se deseja gastar em um ano e usar isso como objetivo. Ao invés de alocar o total disponível de uma vez, pode-se quebrá-lo em partes menores que são alocadas com mais frequência. A alocação de uma equipe de produto entre capital e operacional pode ser feita usando-se estimativas da quantidade de trabalho que será realizada em cada uma das categorias de trabalho descritas no SOP 98-1 (Statement of Position 98-1 Allocation of Costs of Computer Software Developed or Obtained for Internal Use, Financial Accounting Standards Board, 1998 - é importante observar que essa classificação de trabalho em desenvolvimento de software foi escrita em 1998 e está completamente desatualizada em relação a como tecnologia é desenvolvida atualmente). Um bom analista financeiro deve ser capaz de sentar e encontrar uma maneira de alocar custos adequadamente com um pouco de ajuda de gerentes de produto e, assim, se tornar parte de uma equipe multi funcional de alto desempenho. O segredo está no feedback e na tomada de decisão a respeito do que investir. Essa decisão deve ser tomada com horizontes de tempo cada vez menores, o que vai exigir um pouco de experimentação.
InfoQ.com: O livro também questiona o mito da "escassez de talento técnico", apontando falhas nas práticas de recrutamento que focam nas habilidades que candidatos já possuem, ao invés de focar na habilidade de adquirir rapidamente novas habilidades e conhecimentos. Que exemplo se pode dar a respeito de como avaliar o potencial de crescimento de candidatos? Em outras palavras, que tipo de prática de recrutamento pode efetivamente avaliar as habilidades de aprendizagem de um candidato?
Não somos especialistas em RH, então, a primeira coisa a se fazer e buscar ajuda dessa classe de profissionais que vão poder colaborar com qualquer tipo de avaliação psicológica e de personalidade de forma a fornecer insights a respeito da habilidade do candidato em aprender. Apesar de oferecermos algumas sugestões que podem ajudar a decidir se uma pessoa é ou não um eterno aprendiz, testes mais específicos realizados por equipes de RH podem revelar características significantes que podem passar despercebidas.
Algumas ideias:
Não restrinja seus requisitos a formação acadêmica específica ou um perfil de experiência prévia. Não se encontra pessoas com 5 anos de experiência no uso das últimas tendências tecnológicas. Pessoas que se candidatam a oportunidades de trabalho fora de sua área de formação e experiência tem mais chances de estarem dispostas a aprender. Examine a experiência de um candidato, buscando por exemplos de aprendizado em diferentes situações e crescimento ao longo do tempo. Quando estiver filtrando as candidaturas a fim de obter uma lista de candidatos potenciais, remova qualquer informação pessoal que possa resultar no uso de preconceitos inconscientes que podem resultar na seleção de pessoas mais parecidas com você.
Uma das coisas que notamos é que se afastar de lista itens de habilidades que os candidatos já tem permite que se aumente a diversidade. Existem boas evidências de que diversidade em todos os níveis das organizações gera vantagem competitiva em termos de permitir um ambiente criativo de aprendizagem. O fato de que muitos departamentos de engenharia (pelo menos no caso de economias desenvolvidas) são predominantemente de brancos e masculinos indica que estamos perdendo uma enorme quantidade de talento em potencial. Precisamos nos esforçar em buscar e desenvolver esses talentos.
Preste muita atenção a habilidade dos candidatos de ouvir e se comunicar durante entrevistas, já que essa é uma habilidade importante para aprender no ambiente de trabalho. Os candidatos tomam tempo adequado para compreender as perguntas? Respondem as perguntas cuidadosamente? Admitem não conhecer a resposta, mas dão ideias de que abordagem poderia ser tomada para se chegar a uma resposta? Cumprimentam todas as pessoas que estão na sala de entrevista? Se referem aos sucessos do passado como resultado de esforço individual ou reconhecem a contribuição de outros?
Não esqueça de reunir um grupo diversificado de pessoas para realizar as entrevista e observar a interação. Conforme mencionamos, diversidade tem um papel importante no desenvolvimento de uma equipe criativa e inovadora. Quando há um grupo de pessoas com as mesmas origens e experiências que não conseguem se identificar com pessoas fora de sua zona de conforto, não se pode esperar que esse grupo se identifique bem com clientes. Isso, vai restringir muito sua habilidade de inovar.
InfoQ.com: É revelado no final do livro a epifania de que melhorias de processo efetivas exigem o método científico de experimentação. É possível combinar tal abordagem com frameworks como CMMI e ITIL, que prescrevem níveis de maturidade nos quais um conjunto concreto de práticas operacionais simultâneas é esperado?
Não vemos nenhum conflito no uso de frameworks e padrões que ajudam a descobrir como melhorar o que se faz. De qualquer forma, ficamos preocupados quando as pessoas tentam seguir práticas e regras desses frameworks dogmaticamente. Não existe nenhuma organização que seja igual a uma outra. O que funciona para uma nem sempre funciona nas outras. O mais importante é ensinar as pessoas a resolver os problemas em suas próprias organizações e como aumentar o valor entregue aos seus clientes. Essa é a essência do pensamento Lean. Determine a direção que quer seguir. Compreenda a situação atual e escolha a condição a qual deseja chegar. Então, crie um experimento que conduza em direção a condição objetivada. Use o que for aprendido para atualizar a visão e definir o próximo passo.
Frameworks e padrões como ITIL, CobiT, TOGAF, SAFe, série ISO 27000, etc., são bons em ajudar organizações a determinar o que é ideal e em ajudar a escolher objetivos de melhoria. Uma das cinco seções principais do ITIL é chamada Melhoria Contínua. Modelos de maturidade, incluindo o CMMI, são apenas ferramentas para ajudar na definição de em que ponto da jornada se está, de forma a usar a tecnologia da melhor forma. O nível 5 é aquele em que o processo é completamente automatizado e a melhoria contínua é aplicada.
Todos esses padrões e frameworks são bons para definir o que significa melhor. A armadilha em que organizações caem é pensar que precisam chegar ao Nível 5 em todas as áreas ou acreditar que aplicar o framework vai resolver os problemas. Não existem balas de prata ou atalhos para pensar por si só e experimentar. Quando se trata frameworks e padrões como atividades que devem ser executadas por todos da mesma maneira, de forma a conseguir os resultados definidos, jamais se terá sucesso. Ao invés disso, planeje, execute, verifique e aja - pegue ideias de diferentes fontes e escolha aquelas que trazem melhores resultados e, então, repita esse processo de forma cíclica.
Quando se está em uma organização que precisa ser certificada em certo padrão ou atender algum regulamento, a situação muda. A maioria das certificações é baseada em auditorias que avaliam se a organização tem os documentos exigidos para os processos, a partir dos quais são geradas evidências de que a organização segue esses processos. A maioria não mede a qualidade e se há entrega de valor. O número de vazamentos de dados de cartões de pagamento que aconteceram nos últimos dois anos em organizações que estão em conformidade com o PCI, é um exemplo de como a certificação e conformidade não significam necessariamente que vai se atingir os objetivos definidos para o padrão seguido. (No caso do PCI, é muito maior a quantidade de vilões que são mais espertos no uso da tecnologia - esses indivíduos estão constantemente executando experimentos para descobrir e hackear sistemas susceptíveis que foram desenvolvidos para atender um padrão.)
Sobre os autores do livro
Jez Humble é o vice presidente da Chef, palestrante na UC Berkley, e co-autor do livro vencedor do Jolt Award, Continuous Delivery (Entrega Contínua), publicado na série de livros assinada por Martin Fowler (Addison Wesley, 2010). Também é autor do livro Lean Enterprise (Empresa Lean, em tradução livre), da série Lean de Eric Ries (O'Reilly, 2014). Trabalhou como desenvolvedor de software, gerente de produto, executivo, consultor e treinador em uma grande variedade de domínios e tecnologias. Seu foco está em ajudar organizações a entregar software com alto valor agregado e de alta qualidade com frequência e confiabilidade através da implementação de práticas de engenharia efetivas.
Joanna Molesky é consultora referência na ThoughtWorks, na qual ela trabalha internamente com Risco e Conformidade em TI e oferece serviços de consultoria a clientes na área de entrega contínua e melhorias de processo, particularmente, no que se aplica a controles, risco e conformidade. Molesky tem as certificações CISA e CRISC da ISACA.
Barry O'Reilly trabalha na ThoughtWorks, prestando consultoria em melhoria contínua utilizando práticas e princípios Lean e Agile. Nessa função trabalha com organizações que são líderes globais em seus setores. O'Reilly já trabalhou como empreendedor, empregado e consultor. É apaixonado pela inovação em modelos de negócio, desenvolvimento de produto, projeto organizacional e transformação cultural.
