Gestao | AkitaOnRails.comhttps://akitaonrails.github.io/tags/gestao/Blog do Fabio Akita do Canal do YouTube 'Akitando' falando sobre tecnologia, carreira e coisas geek.Hugo -- gohugo.iopt-BRMon, 19 Oct 2026 23:20:48 +0000[Akitando] #120 - Discutindo Gestãohttps://akitaonrails.github.io/2022/06/13/akitando-120-discutindo-gestao/https://akitaonrails.github.io/2022/06/13/akitando-120-discutindo-gestao/Mon, 13 Jun 2022 10:47:00 -0300<div class="embed-container"> <iframe src="https://www.youtube.com/embed/2tpshOTtleM" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen> </iframe> </div> <h2>DESCRIÇÃO<span class="hx:absolute hx:-mt-20" id="descrição"></span> <a href="#descri%c3%a7%c3%a3o" class="subheading-anchor" aria-label="Permalink for this section"></a></h2><p>Gestão é um mundo enorme e complicado e por isso muito iniciante tem muita dificuldade de entender o que realmente precisa fazer. E no video de hoje resolvi falar um pouco sobre a arte de gerenciar e alguns pontos que eu pessoalmente considero importante depois de 30 anos gerenciando projetos de uma forma ou de outra. Não é o guia definitivo nem nada disso, só um pequeno empurrão que pode trazer alguns insights, seja você gerente ou não.</p>

DESCRIÇÃO

Gestão é um mundo enorme e complicado e por isso muito iniciante tem muita dificuldade de entender o que realmente precisa fazer. E no video de hoje resolvi falar um pouco sobre a arte de gerenciar e alguns pontos que eu pessoalmente considero importante depois de 30 anos gerenciando projetos de uma forma ou de outra. Não é o guia definitivo nem nada disso, só um pequeno empurrão que pode trazer alguns insights, seja você gerente ou não.

Conteúdo

  • 00:00:00 - Intro
  • 00:01:47 - O problema com histórias
  • 00:02:39 - PMI
  • 00:04:52 - Onde aprender?
  • 00:06:30 - O que é gestão?
  • 00:08:47 - O mais difícil em gestão
  • 00:10:54 - A trindade de projetos
  • 00:14:02 - PO e stakeholders
  • 00:17:50 - Jovem demais
  • 00:20:36 - Cicatrizes de guerra
  • 00:23:26 - Filosofia Peaky Blinders
  • 00:26:13 - Hardware vs Software
  • 00:30:09 - Tipos diferentes de software
  • 00:32:39 - Tomando decisões
  • 00:35:01 - Motivação
  • 00:36:20 - Alguns livros
  • 00:37:10 - Métricas
  • 00:40:19 - Comunicação
  • 00:42:54 - Cortando na carne
  • 00:44:12 - Knowledge Workers
  • 00:48:10 - Evoluindo as pessoas
  • 00:52:28 - Conclusão
  • 00:54:02 - Bloopers

Links

SCRIPT

Olá pessoal Fabio Akita

Se tem um papel que é difícil de definir e também de evitar em qualquer empresa de tecnologia é o do famigerado “gerente”, seja um product owner, seja um scrummaster, seja um chapter leader ou seja lá que nome andam inventando agora. Todo mundo reclama quando eu fico cagando regra, mas já aviso que esse episódio vai realmente ser uma grande cagação de regra. Esse episódio é pra você que é gerente, ou quer ser gerente ou se viu obrigado a atuar como gerente. Todo mundo, em algum momento, vai passar por isso. Depende de você decidir se vai abraçar a oportunidade ou fugir. Porque sempre é mais fácil ser o reclamão do grupo, mas ninguém quer ser o cara que vai realmente resolver o problema.

O objetivo deste episódio não é ser um guia definitivo de tudo que existe sobre gestão mas só apresentar alguns pontos que eu pessoalmente considero importantes quando se discute esse assunto. Pontos que se você já não gerenciou diversos tipos diferentes de projetos, talvez não seja tão óbvio.

(…)

Tenho que deixar claro que tudo que eu disser hoje não são verdades absolutas. O problema de projetos e administração em geral é que a gente vê resultados ao longo do tempo. E durante esse tempo prestamos atenção em alguns poucos pontos que parecem importantes pra gente e ignoramos dezenas de pequenos pontos que pra mim pode não parecer importante porque são coisas que eu faço sem pensar, mas pra outras pessoas não são óbvias porque elas não estão acostumadas a fazer. Daí eu conto uma história que vai ser incompleta e por isso é difícil de replicar. O mesmo vale pra versão de outras pessoas. Por isso que ninguém vira gerente só assistindo videos ou lendo meia dúzia de histórias.

Se duas pessoas contarem a mesma história sobre um mesmo projeto, as histórias vão ser diferentes e ambas vão ser incompletas. É impossível resumir tudo que realmente foi importante num projeto que durou 12 meses em 12 minutos. Por isso valorizamos a tal da experiência. Parte da experiência são items que são fáceis de explicar, outra parte é implícito e difícil de colocar em palavras. São as várias pequenas decisões invisíveis que podem fazer a diferença no final. Portanto não, não tem nenhum livro que você possa ler que vai te ensinar essas coisas, só prática real, várias vezes, em cenários diferentes, prestando atenção em tudo que está fazendo e quais as consequências. Algumas vezes foram ações específicas que levaram ao sucesso, outras vezes foi literalmente a sorte de estar no lugar certo na hora certa. Não dá pra prever.

Falando em livros e teoria, uma cena que ficou famosa do meu video sobre o Guia de Aprendendo a Aprender foi quando rasguei meu certificado de PMP. Eu acho que expliquei isso lá mas vale repetir: eu quis dizer que certificados não significam nada. Colecionar papel pode ser um hobby, mas na prática é inútil. Porém não significa que eu não respeite o PMBOK.

Pra quem não sabe, existe um corpo de conhecimento documentado no Project Management Body of Knowledge, que é o PMBOK. É o material ensinado pelo PMI pra quem quiser se certificar como gerente PMP. É como se fosse uma enciclopédia e dicionário dos principais temas e termos de gestão como custos, escopo, comunicação. É o básico de conhecimento pra quem tem intenções sérias de se tornar um bom gestor. Mas como todos os cursos, ele não ensina como se tornar um bom gestor.

Pense no PMBOK como uma caixa de ferramentas. Só um bom carpinteiro sabe como usar quais ferramentas pra fazer bons móveis, mas só o manual de cada ferramenta nunca vai te tornar um bom carpinteiro. O PMBOK é a mesma coisa, tem chave de fenda, tem martelo, tem alicate, e como usar cada uma. Mas só isso é inútil pra você se considerar um gestor de verdade. Mas, vale a pena estudar pra saber o que todo mundo já sabe e não ficar tentando reinventar a roda.

No mundo de agilidade existem até alguns frankensteins como Agile PMI. Pelo mesmo motivo, isso não quer dizer muita coisa. Só misturar vocabulário de PMI com de Agile. E só mais um produto de marketing que consultorias tentam empurrar goela abaixo dos desavisados. O famoso “se der certo, é porque a metodologia é boa, mas se der errado, é porque você não seguiu exatamente como a gente falou, então paga a gente de novo pra corrigir”.

Eu falo disso no episódio de “Esqueça Metodologias Ágeis” onde explico como o termo Agile foi sequestrado e diluído por consultorias tentando vender a próxima grande moda da vez. E no episódio “O Guia Definitivo de Organizações” explico porque se você usa o tal modelo do Spotify, você não entendeu o modelo do Spotify. Em ambos os episódios explico o básico sobre a evolução e filosofia de organizações, então recomendo que assistam depois de terminar aqui porque não vou repetir o que já expliquei lá.

As maneiras formais de aprender sobre gestão é fazer faculdades como de engenharia de produção ou administração ou um MBA. E antes que comecem a me perguntar qual deveriam fazer, já respondo: tanto faz. Varia de pessoa pra pessoa e eu não te conheço pra dizer o que é melhor pra você, só você sabe disso e já digo que se você sequer consegue decidir o que é melhor pra você, como acha que vai decidir o que é melhor pro projeto dos outros? Já começa aqui o indicativo que você talvez não tenha inclinação pra ser um gerente.

Falando em MBAs, muita gente faz pelo prestígio do papel. Poder dizer que é um MBA. Tem quem coloque “virgula MBA” depois do nome no LinkedIn. Não posso criticar demais porque eu também colocava “virgula PMP” no meu, mas a vergonha alheia me fez tirar rápido. Também era 2003. Em 2022 já fica ridículo. Aproveite que ninguém viu e tira o seu porque é cringe. Nos anos 90 até 2000 alguns consideravam grande coisa. Hoje nem tanto. E se alguém se exibe por ser MBA, é um sinal vermelho. Que nem foto de Tinder com carrão atrás.

Tem quem confunda ser MBA com ser um bom gestor, e não existe correlação. Fazer MBA em instituições renomadas tem o objetivo maior de criar networking, não muito mais que isso. Se você está nesse caminho recomendo ler livros como do professor Henry Mintzberg e seu clássico “Managers, not MBAs”. Se certificar como PMP ou se formar como MBA é só mais uma forma de colecionar papel, e não garantia de se tornar um bom gestor. Eu ainda acho que se você puder estudar o material deles, é super válido. Só não pode achar que já sabe tudo e sim que pelo menos sabe o básico do básico.

Se eu fosse resumir o que é gestão em poucas palavras diria que é a capacidade de tomar decisões na hora que precisa, mesmo tendo informações incompletas. Alguém que não consegue tomar decisões e assumir responsabilidades nunca deveria gerenciar nada. Ser gerente não é obedecer ordens e preencher planilhas e relatórios sem fim. Qualquer idiota pode fazer isso. Isso não é um talvez, se seu dia a dia é só checar o backlog, checar as métricas, preencher nas suas planilhas e reportar, isso não é ser um gerente, é só ser um burocrata. E sim, existe a necessidade de burocratas em empresas grandes, mas não se iluda achando que está gerenciando porcaria nenhuma.

Vamos voltar ao conceito mais básico. Qual é o objetivo de uma empresa? Você pode inventar que é inovação, que é fazer diferença social e todo bla bla, mas isso é marketing. Não há nada de errado nisso porque toda empresa precisa construir sua marca em torno de algum tipo de marketing. Mas vamos tirar o marketing do caminho e ir na realidade nua e crua. O objetivo de toda empresa é dar lucro de forma sustentável. Nada mais, nada menos. Empresas que não dão lucro e ficam vivas ao custo de investimento é o que chamamos de “empresas zumbi”.

Mas não é “lucro a qualquer custo” como amadores pensam. Se o objetivo for dar lucro rápido sem nenhuma preocupação com futuro é simples: venda drogas. Dá muito mais dinheiro com muito menos trabalho do que tentar fazer uma tech startup. Só que o risco de você acabar preso ou morto é muito alto, por isso eu enfatizo o “sustentável”. Não é difícil ter lucro de vez em quando, é muito difícil sustentar esse lucro por anos a fio. Crescer 10%, 20%, todo ano, anos seguidos.

Outra definição importante é que projetos tem começo, meio e fim. Muita gente esquece disso, mas se alguma coisa não tem objetivo bem definido e não tem uma data final, não é projeto, é operação. Não existe projeto que não tem fim. E mais importante: na prática nem todo projeto precisa ir até o fim. Saber quando cancelar um projeto e não insistir numa coisa que não vai dar certo é uma arte. Não existe nada de errado em descobrir que as premissas iniciais estavam erradas e reajustar. Mas tem muito problema em insistir num erro depois de descobrir que estava errado.

Na verdade, em cursos e em guias sobre gestão se dá muita ênfase em como documentar as coisas, como fazer métricas, e muita coisa que, francamente, é bem inútil. Eu quero começar falando sobre o que quase nunca vejo ninguém discutindo fora de happy hour e conversa de bebedouro. Como dizer “não”. Ser um yes man ou yes woman é muito fácil. O cachorrinho abanando o rabo quando o superior manda fazer alguma coisa. Um yes man nunca vai ser um bom gestor porque um bom gestor é aquele que sabe dizer não quando precisa.

Por outro lado, alguém que só diz não e nunca entrega nada, é igualmente inútil. Um bom gestor é como um bom general, ele sabe escolher quais batalhas vai investir. Porque batalhas custam seu batalhão, custam tempo. Só lute batalhas que sabe que vai ganhar, e espere ter condições mais pra frente de lutar as batalhas que hoje iria perder. E só assim, escolhendo certo uma batalha de cada vez que se vence uma guerra. Sabedoria militar é especialmente interessante em empresas. Não a toa todo mundo fala sobre Sun Tzu e sua arte da guerra, mas ninguém sabe o que ele quer dizer, porque seu livro não pode ser lido literalmente. São alegorias inúteis pra qualquer um que já não tenha lutado uma guerra. E de fato, eu mesmo lá no começo era estilo mais kamikaze, ficava pegando briga que não era minha, e perdendo tempo com batalhas inúteis. Demorei anos pra aprender isso.

Um gestor ou um general só precisam existir porque lidamos com recursos escassos. Não existe dinheiro infinito, não existe tempo infinito, porque se existisse, ninguém precisaria gerenciar nada, era só gastar eternamente. É por isso que eu sempre acho que toda tech startup unicórnio e essa idéia maluca de só crescer fatia de mercado sem se preocupar em dar lucro tem como consequência gerar pessoas fracas. Porque muito pouca decisão precisa ser tomada, o problema sempre pode rolar pra frente, até o próximo round de investimentos. É viver a ilusão que se tem dinheiro infinito. E se tem dinheiro infinito, pra que escolher ser eficiente? Basta sair contratando mais gente, infinitamente. Até a bolha estourar. E podem acreditar, ela sempre estoura.

Um projeto costuma ser definido pela trindade escopo, tempo e custo. É impossível ter o maior escopo no menor custo e tempo. Se aumentar o escopo ou o custo aumenta ou o tempo aumenta. Não existe outra forma. Como custo e tempo costumam ser os fatores limitantes o que sempre precisa variar, pra menos, é o escopo. E sempre o escopo é mau definido e os objetivos do projeto que esse escopo quer cumprir são mau entendidos. Só durante o projeto que esse entendimento vai melhorando e isso sempre tem que levar à revisão do projeto.

Quase 10 anos atrás tive um cliente muito burro, o cara era tipo herdeiro. Quem construiu tudo foi a família dele, agora ele achava que só porque fez seu MBA ou sei lá, sabia alguma coisa. Herdeiros acham tudo fácil, lógico, sempre ganhou tudo de mão beijada. É um saco. Na época ele veio com o clássico “Akita, a gente podia encaixar aqui uma funcionalidade de chat, igual o Facebook Messenger, agora que já existe deve ser fácil né? Não dá pra fazer em um mês?” Minha resposta é sempre a mesma “igual? Claro que dá. Se você pagar a mesma coisa que o Facebook pagou, a gente faz”. Sério, lidar com gente que acha que tudo é fácil é foda. Tenho pena de quem trabalhava embaixo dele.

O que um mau gestor sempre vai preferir fazer primeiro, é tentar limitar o problema do tempo fazendo a equipe trabalhar mais horas no dia. E isso é outra burrice sem tamanho. Isso pode funcionar numa emergência de poucos dias. Mas transforme isso numa rotina e automaticamente a qualidade geral de tudo vai cair, e isso se torna uma bola de neve muito rápido, porque as coisas mau feitas dessa semana vão atrapalhar a semana que vem, e agora todo mundo vai ficar correndo atrás do próprio rabo pelo resto do projeto. Como um projeto atrasa 1 ano? Simples, um dia de cada vez.

A trindade de projetos é escopo, custo e tempo, mas existe a quarta variável invisível que todos esquecem. Tente entuchar o máximo de escopo, num tempo pequeno, cortando custos e naturalmente a variável que vai decair drasticamente é a qualidade. Essa é a quarta variável invisível. Falei no episódio anterior que qualidade foi um fator que passou a aparecer entre os anos 80 e 90, mas até hoje muita gente ainda ignora esse fator, porque é mais fácil falar em dólares e horas, mas é difícil de descrever qualidade. Os problemas gerados por um projeto mau feito tendem a ser empurrados pra operação depois.

Comece estabelecendo uma data final. Estabeleça um orçamento. Saiba quais são os objetivos que precisam ser atingidos, em ordem de prioridade, e estabeleça qualidade como fator importante. Daí acomode um escopo que caiba nessas restrições. Normalmente não cabe. E agora vem a inteligência de toda a equipe envolvida em decidir as melhores formas de executar cada tarefa de forma eficiente. Sem fazer horas extras. Garantindo que o que foi feito até agora não seja uma bomba relógio que vai explodir lá na frente. Tudo que é feito às pressas e sem cuidado vai virar um problema muito rápido.

Hoje em dia existe a figura de um PO ou Product Owner. Que é um nome mais bonito pra um gerente de projetos e gerente de operações. Dependendo de pra quem perguntar, vai ter definições diferentes. Mas eu gosto de pensar num PO como sendo um gerente com uma responsabilidade a mais, a de ser responsável pelo ROI do produto, o retorno do investimento. Numa empresa grande, abaixo de um PO vão existir várias equipes, cada uma com projetos próprios, que contribuem pro produto principal. As decisões do PO devem sempre levar em consideração o retorno de investimento de todos. Essa é uma das formas de limitar suas decisões e priorizar seus recursos nos lugares certos. Dê prioridade nos projetos que trazem o maior retorno de investimento. Parece fácil falar, mas muitos se esquecem disso.

Toda empresa e todo projeto tem diversos stakeholders, que são as partes mais interessadas. O financeiro está interessado em manter as contas sob controle, de preferência faturando mais do que gasta. O marketing está interessado em atingir novos clientes, aumentar a fatia de mercado, aumentar as vendas. O marketing só se preocupa com clientes que já existem quando o churn começa a ficar preocupante, ou seja, quando o cliente já existente desiste de você. O suporte ao cliente é o oposto, ele está mais preocupado com o cliente que já existe do que com os que ainda não pagam nada.

Os gerentes de projeto estão no meio desse fogo cruzado. Eles precisam saber colaborar entre si, mas seu foco é no projeto que está executando nesse instante. É nesse fogo cruzado que deveria atuar a camada C, o CEO, CFO, CMO, CTO, etc. A camada C existe pra tomar as decisões que afetam a empresa como um todo. As decisões que um gerente isolado não pode tomar. Facilitar a resolução de conflitos. Por isso eu digo que não existe nada pior que um C-level que não toma decisões e fica empurrando problemas com a barriga, normalmente jogando o osso e deixando os gerentes abaixo brigando entre si pra ver quem ganha ou fala mais alto. É o sintoma de um péssimo C-level e, por consequência, uma péssima empresa.

Da mesma forma, especialmente em empresas grandes, existe uma camada do meio muito gorda, os gerentes midlevel. Eles nem são C-level que podem tomar as decisões mais cruciais e nem estão na linha de frente vendo a guerra de verdade sendo travada nos fronts, onde estão os coordenadores e funcionários em geral. Eles acabam sendo mais burocratas, os famigerados pilotos de Excel e Powerpoint. É um mau necessário em muitas empresas, e eu realmente não consigo ver uma forma de eliminar isso totalmente, só minimizar. Não importa se você chama departamentos de chapters, é tudo a mesma coisa, estrutura hierárquica profunda e pior, estática.

Onde esse problema já existe, que é na maioria das multinacionais e empresas realmente grandes, só vejo isso mudando em épocas de mudança de liderança. Numa mudança de CEO, por exemplo. Onde é forçado a tal “reestruturação” de cima pra baixo. Não é garantia de melhoria, mas pelo menos o caos força mudanças, algumas podendo ser boas. Mas isso é arriscado e custa caro, por isso não se vê todo dia. Em empresas pequenas e médias, o problema é evitar chegar nesse ponto cedo demais.

No começo de uma empresa, ela vai necessariamente ter a cara dos sócios fundadores, que são a primeira geração de C levels dessa empresa. Se os sócios são ruins, a empresa vai ser ruim. As exceções são quando esses sócios tem conexões e investidores que forçam um C level diferente dos fundadores. Mas pensando no caso geral, é por isso que eu sempre digo que um jovem nos seus 20 e poucos anos não deveria pensar em abrir empresa se já não tiver sido muito bem criado e educado com herdeiro de um negócio pré-existente.

Eu disse isso em episódios anteriores, porque muito jovem ingênuo até hoje ainda fala das histórias lendárias dos jovens Bill Gates, Steve Jobs ou Mark Zuckerbergs e a lendária história da startup de garagem, como se todo mundo pudesse fazer a mesma coisa. Existe uma razão de porque se menciona Bill Gates, que abriu a Microsoft no fim dos anos 70. Tem muito pouco exemplo na história. Todos os nomes que eu falei largaram faculdades renomadas. Harvard e Stanford. Experimente entrar nelas. O nome do Bill Gates é William Henry Gates Terceiro. A família já era reconhecida. O famoso contrato da Microsoft com a IBM pra licenciar o MS-DOS só saiu porque o a mãe do Bill Gates era amiga do CEO da IBM daquela época. É assim que se faz. Nem eu, nem você temos como ter contatos assim aos 20 anos.

Quem não é um bom herdeiro vai precisar gastar pelo menos a primeira década de trabalho criando conexões. Conhecendo outras pessoas em começo de carreira que vai confiar em você porque viu em primeira mão que você é competente e entrega o que promete. Daqui alguns anos, ele vai ser dono de empresa, investidor, ou diretor, agora você tem networking de verdade. Isso se constrói e se conquista demonstrando competência de verdade e não se conectando no LinkedIn. Vou repetir: eu não aceito nenhum convite no LinkedIn de quem eu ja não tenha conhecido antes na vida real. Quando aceito desconhecido foi acidente. E outras pessoas que aceitam também não dão nenhum peso. Convite de LinkedIn, cartão de visita, e-mail de spam, vai tudo pro lixo. Não perca seu tempo. Quem eu confio tá no speed dial do meu celular, o resto é resto.

Enfim, o ponto que estava falando é que a empresa vai sempre ter a cara dos fundadores. Se os fundadores forem inexperientes e incompetentes, é assim que a empresa vai ser. Daí vai precisar ter sorte pra conseguir contratar alguém bom que aceite trabalhar pra você. É bem loteria. Por isso eu acho que o certo é primeiro você se tornar bom, um profissional nível A, porque só assim, vai conseguir contratar outro profissional nível A. Um profissional nível B só contrata caras nível C. E caras nível C só conseguem contratar caras nível E, e assim por diante. Só A contrata A.

E isso é importante porque quando possível, parte do trabalho de um gestor é contratar pessoas. Só que se ele próprio não for um cara reconhecido como nível A, vai continuamente contratar as pessoas erradas e colocar nos lugares errados. Das duas uma, ou vai contratar cara nível C quando precisava de um A. Ou vai dar tarefas nível C pra um cara nível A. Em ambos os casos vai ser uma equipe ruim.

Muitos gestores em começo de carreira ficam lendo os cases e metodologias aplicadas em grandes empresas como Netflix ou Google e enchem a boca pra falar “vamos fazer do jeito X porque a Netflix faz assim”. Mas reconheça como isso é idiota. Uma grande empresa como Netflix pode pagar profissionais nível A que ganham meio milhão de dólares por ano ou mais. Primeiro se pergunte: você pode pagar isso? O budget dos projetos que eles executam são da ordem de milhões de dólares. Seu projeto tem esse tipo de orçamento? Se não, por que diabos você está se iludindo achando que pode fazer o que eles fazem?

Sinceramente eu não acredito num gestor que não foi ele próprio um profissional igual aos membros de sua equipe. Um time de futebol onde o treinador não foi ele próprio jogador de futebol. Um chef de cozinha que não foi ele próprio descascador de batatas. Um general que não foi ele próprio soldado raso. E um gerente de equipe de desenvolvimento que não foi ele próprio um desenvolvedor de software. Nem todo programador tem capacidade de virar um gestor, mas certamente um gestor não técnico, nunca vai saber o que é ser um programador num seminário de poucas semanas. Nenhum soldado jamais vai respeitar um general que nunca esteve numa batalha de verdade.

Daí caímos no caso onde temos uma equipe que não respeita seu gestor e o gestor que não confia na própria equipe, que eu chutaria que descreve a maioria das equipes por aí. Respeito e confiança é diferente de ser o cara engraçado no happy hour. Foda-se ser engraçado. Bons profissionais tem respeito mútuo entre si, independente do ranking e classificação. Eles nem precisam ser amigos e gostar um do outro. Mas cada um sabe que na hora H pode contar com o outro. Acaba sendo natural. E esse é o terror das equipes de RH e recrutamento porque eles também não tem a mínima idéia de como contratar certo, porque são só burocratas, nunca estiveram na linha de frente.

E como eu sei que eu sou bom, nível A? Tem um checklist? Tem pré-requerimentos? Tem curso ou certificados que preciso ter? Não, não, não e não. Eu gosto de dizer que ser bom é que nem paixão. Como eu sei que estou apaixonado? Bom, quando estiver apaixonado, você vai saber. E todo mundo ao seu redor também vai saber. É a mesma coisa de ser bom. Se você não sabe se é bom, provavelmente não é. Quando for, vai saber, e todo mundo ao seu redor - que não for sua família e amigos - vão saber. E eu faço essa distinção porque quem automaticamente diz pra você que é bom, mesmo não sendo, tem boas intenções, mas está sendo desonesto. Um amigo de verdade diz quando você está errado, caso contrário está sendo um péssimo amigo, porque está roubando sua oportunidade de melhorar às custas dele se sentir bem consigo mesmo.

Quando você for bom, naturalmente, vai conseguir identificar outras pessoas boas. É assim que funciona. Pra ilustrar, eu gosto da série Peaky Blinders. E me identifico com um aspecto que o protagonista Tommy Shelby tende a no mínimo respeitar quem lutou na guerra como ele. Ele tem vários traumas das trincheiras da França na Primeira Grande Guerra Mundial, que foi uma das mais carniceiras de todos os tempos. Quando você encontra outro ex-soldado condecorado que esteve em batalhões que lutaram juntos, você meio que sabe do que ele é feito. Todo filme de guerra tem esse aspecto, e no mundo fora das guerras de verdade, é similar, a gente que tem cicatrizes sabe reconhecer as cicatrizes dos outros. Só que um recém formado ou iniciante não tem cicatrizes ainda. Esse é o ponto.

Mas não é só executar o trabalho? Não é só preencher planilhas e preencher relatórios e meu trabalho como gestor tá acabado? Esse é o pensamento que muito iniciante tem. Das duas uma, você vira o yes man, que vai só executando o que pede. Ou você se torna o maverick, o imprudente que acha que precisa revolucionar as coisas do seu jeito. Mas como eu disse, nenhum dos dois tem cicatrizes ainda pra saber até onde pode ir e nem como ir. E ambos estão fazendo bobagens. O problema é que o termo “gerenciar projetos” é o jeito errado de dizer. O objetivo é entregar projetos mas você sempre gerencia pessoas. Sua taxa de sucesso em projetos é diretamente proporcional ao seu bom relacionamento com suas equipes.

E pessoas não são máquinas. Especialmente em programação. Aliás, eu sempre falo que essa é a diferença entre software e hardware. Quando falei que é importante saber PMI mas não seguir nada deles ao pé da letra é porque muito do que existe documentado sobre gerenciamento de projetos deriva da engenharia de produção, da gestão de fábricas, relíquias da revolução industrial, o legado de modelos como da Ford. Aquele estereótipo de Charles Chaplin onde pessoas são secundárias e a linha de produção é o principal.

Nesse ambiente, tudo é minuciosamente planejado, você faz blueprints, plantas baixas, esquematizações e daí é possível calcular até que com bastante precisão quanto vai custar e quanto tempo vai levar pra construir a fábrica. E a partir daí a produção dos items é bem uniforme, com pouca variabilidade. Muita coisa é automatizada e no mundo ideal, nem é pra ter pessoas envolvidas, só robôs, como numa fábrica de carros mais moderna. A maior parte do conhecimento de administração e gerenciamento deriva desse cenário de produção em massa.

No jeito antiquado de pensar, se em hardware funciona, em software também deveria funcionar. Afinal, o programador é como se fosse o operário da linha de produção. Basta desenhar o projeto da forma mais detalhada possível, fazer a planta baixa, que seria função de um arquiteto, daí é só o programador executar como um operário numa linha de fabricar carros. Outra metáfora que se usa quando povo tenta falar de software como arte é equiparar com uma orquestra de música clássica, onde temos um maestro ou condutor, que é o gerente de projetos, a composição que é o trabalho do equivalente arquiteto, daí cada um na orquestra com seu instrumento só precisa executar sua parte com precisão pra termos uma peça de sucesso.

Só que ambos os pontos de vista estão errados. O trabalho de operário ou do músico da orquestra, o trabalho repetitivo, braçal, já é totalmente automatizado. Quem cumpre esse papel é o compilador ou interpretador. É o compilador que recebe a tal planta baixa e cospe o binário que o computador vai executar, mecanicamente. Agora o que é essa planta baixa? Esse é o código-fonte, o programa propriamente dito. O programador não é o operário. Todo programador é tecnicamente arquiteto. E na realidade não se trata de uma orquestra de música clássica e sim um grupo de jazz, onde intuição, improvisação, trabalho em equipe, fazem toda a diferença.

Eu não sou músico, mas do pouco que entendo, jazz seria o mais próximo de programação. Cada integrante toca improvisando, complementando e competindo com os demais no mesmo grupo, mas trabalhando de forma a criar uma música que faça sentido. Programação é a mesma coisa. Cada programador tem seu estilo, seu ritmo, e apesar de precisarem ter alguma base mínima pra não virar só barulho, a contribuição individual de cada um conta.

Um programador não é um operário. E software é ordens de grandeza mais complicado do que hardware porque hardware obedece as mesmas leis da natureza que são não-ambíguos pra todo mundo. Duas empresas de construção que recebem a mesma planta baixa, no final vão construir basicamente o mesmo prédio. Com quantidades similares de cimento, tijolos e tudo mais. A especificação é precisa o suficiente pra isso. E tem que ser assim porque uma vez construído, não tem como refatorar uma ponte. Não tem como adicionar ou tirar um andar no meio de um prédio.

Software é diferente. Dois programadores que receberem qualquer tipo de especificação de software, vão sair com dois conjuntos de código completamente diferentes. E quanto mais específico você tentar ser, mais próximo do código final você vai chegar, então no final é como se estivesse você mesmo fazendo o código. O código é a especificação. E o erro é justamente esse: achar que é possível especificar um software com precisão antes de comecar a codificar. Isso é impossivel.

Claro, se você está num ramo de atividade onde sempre faz o mesmo software o tempo todo, aí é mais fácil. Por exemplo, uma agenciazinha cujo trabalho é customizar Wordpress pra pequenos clientes. Nesse caso o grosso do software já está pronto, é o Wordpress. Você muda tema, muda logotipo, faz uma ou outra customização. Mas agora sim, você está muito mais próximo de uma linha de montagem de fábrica. Porque o grosso do trabalho não é codificar, é copiar e colar mesmo.

Mesma coisa um ERP como os de uma Totus da vida. O trabalho de programação mesmo é fazer e atualizar esse ERP, adicionar novas funcionalidades. Mas o grosso do trabalho de instalar nos clientes é customização, e não totalmente programação. A maior parte do software é padronizado e já está pronto. Daí o que tem de programação é mais a integração dele com outros sistemas, por exemplo. Daí é um ambiente um pouco mais controlado. Nesse tipo de ambiente que funciona as tais ferramentas low code ou no code, que é pra grudar peças que já existem e foram codificadas por um programador. Daí um operador só precisa customizar a integração desses peças. Mas o grosso do software em si, que é o ERP, já está pronto.

Na prática, em graus diferentes, ninguém mais faz 100% de todo software do zero. O sistema operacional é padronizado. Componentes como bancos de dados são padronizados. Pouco a pouco plataformas como AWS da Amazon ou Azure da Microsoft foram comoditizando diversas coisas que antes fazíamos do zero, até machine learning e inteligência artifical hoje são serviços que a gente só integra. A maioria dos projetos hoje tem uma parte grande que é basicamente só integração. O que muitos programadores fazem o dia inteiro é na realidade o trabalho de um integrador.

E mesmo assim o trabalho ainda não é linear de linha de produção porque temos diversos aspectos que mudam. Requerimentos de performance, requerimentos de escalabilidade, requerimentos de segurança, requerimentos de usabilidade. Nenhum deles permanece estático pra sempre. Mudanças nesses requerimentos às vezes exigem reescrever uma parte do software que não atende mais o que precisa. Às vezes é jogar fora um legado por um produto mais moderno. E é aí que entram as equipes de desenvolvimento pra decidir qual o melhor caminho: um band-aid em cima do que já existe, reescrever um pedaço, integrar com um produto de terceiros, ou uma combinação de tudo isso.

E de novo voltamos à formação da equipe. Uma vez definido a direção e objetivos. Quem decide como as coisas vão ser feitas? Um gerente não técnico tem zero condições de decidir essas coisas. Então, ou ele precisou receber essa ordem de alguém, ou precisou confiar que a equipe sabe quais as melhores decisões técnicas. E agora ele se ferrou, porque se não teve a oportunidade de criar essa equipe, se for o caso que falei antes de um gestor que não conquistou o respeito da equipe, tenha certeza que parte dessas decisões vai ser tomada no automático, e os resultados nunca vão ser os melhores.

Quando um gestor não tem a capacidade de decidir essas coisas, ele precisa de suporte. É onde normalmente deveria entrar o tal do CTO, o Chief Technology Officer. Dependendo do tamanho da empresa ele vai ter pares como um CSO ou Chief Security Officer que se preocupa com coisas como governança. E um bom CTO se for realmente um nível A, deveria já ter uma equipe de líderes técnicos que ele confia, e juntos conseguem prototipar, criar provas de conceito, e decidir a melhor solução técnica e orientar as demais equipes dos caminhos que decidiram tomar.

Agora cabe aos gestores de cada equipe coordenar com suas equipes e ver se é possível executar o que foi demandado. Às vezes a resposta vai ser não, e aqui um bom gestor tem que ser o firewall da equipe. Ele tem que saber decidir quando precisa forçar a solução pra equipe ou quando a equipe sabe que não vai dar certo, e porquê, e rediscutir o problema pra cima. E isso é sempre um problema quando o gestor não confia na própria equipe ou a equipe não respeita o gestor. Alguém sempre vai estar vendido nessa situação, e por isso eu disse que gestão de projetos é na realidade gestão de pessoas.

Por princípio, se não for do tipo kamikaze como eu, a maioria das pessoas detesta conflitos, e vai fazer o possível pra evitar, inclusive prejudicando os projetos, empurrando o problema com a barriga até ser tarde demais. Esse é o pior tipo de gestor, na minha opinião, porque ele vai dar burn out na equipe, executando uma coisa que já se sabia que não ia dar certo, só pra postergar a discussão do problema. O famoso jogar embaixo do tapete e torcer pra ninguém ver. Dentro da equipe, o único que tem obrigação de não fugir de conflitos, é o gestor. A equipe deve ser blindada de conflitos desnecessários, e o gestor é quem tem que aguentar a úlcera e blindar a equipe.

E falando na equipe, agora temos o problema de composição e comunicação. A realidade é que na maior parte do tempo, nenhum trabalho é realmente interessante. Você tem períodos de coisas legais e períodos de coisas chatas. Infelizmente as duas coisas são importantes. Sabendo disso, muito gestor tenta o caminho de tentar ser o motivador, cheerleader ou algo assim. Isso não funciona. Nenhum gestor motiva equipes, no máximo eles evitam desmotivar. Motivação é intrínseco, cada pessoa só consegue motivar a si mesma. Motivação externa é no máximo um rush temporário. Cada pessoa precisa encontrar propósito nela mesma, e isso é um trabalho individual. Psicólogos podem ajudar, mas gestores só precisam ajudar a não atrapalhar.

Se o gestor enxerga as coisas como fábrica, projetos como linha de produção, programadores como operários, a vida vai ser difícil. Porque ele vai sempre passar só o mínimo de informação, normalmente na forma de ordens, vai microgerenciar como se não houvesse amanhã, e raramente vai ter a via inversa que é de conversa e comunicação. Dizer uma informação é diferente de se comunicar. Comunicação é diálogo. Um diálogo não precisa ter uma resolução imediata, mas no mínimo precisa existir duas mãos na conversa. Isso é o mínimo.

Não dá pra aprender relacionamento de pessoas lendo livros, mas não tem nenhum mau em complementar seu conhecimento com alguns bons livros. E eu recomendo dois. O primeiro é o lendário “Psychology of Computer Programming” do grande Gerald Weinberg. E ele tem vários outros livros interessantes como o “Becoming a Technical Leader”. Mas se quiserem só um resuminho, acho que no mínimo todo mundo já deveria ter lido outro livro famoso, o “Peopleware”, do Tom DeMarco. Esse eu acho que tá um pouco defasado. Várias coisas que eram novidade nele, valiam pro começo dos anos 2000 e hoje parte já é meio considerado comum, mas continua sendo válido ler. Eu vou bater no ponto que a parte mais importante de gerir projetos é entender pessoas, então todo gestor deveria fazer um esforço nessa direção, nem que seja ler alguns livros.

O pior caso é quando o gerenciamento passa a ser em sua maior parte orientado a métricas. Métricas são boas e necessárias. Mas nem toda métrica é boa. As piores métricas são as de produtividade. E isso sempre cai no problema das famigeradas estimativas. O primeiro grande erro é quem confunde estimar com prever. Sabem porque existem duas palavras diferentes? Porque elas significam coisas diferentes. Muita gente ainda pede estimativa mas na realidade estão esperando previsão. Por isso sempre dá discussão “ah, mas você disse que 2 semanas estaria pronto”.

Estimativa é sempre aquela brincadeira de “você finge que fala a verdade e eu finjo que acredito”. Na prática não importa muito com que instrumentos você quer estimar, seja story points, seja horas-homem. O problema é dividir as tarefas ou storys em tamanhos que não sejam muito diferentes. Por exemplo, se o menor tipo de story é de meio dia, o maior não deveria ser mais que uns 2 ou 3 dias. Mais do que isso é um épico e deveria ser dividido mais. Acho importante no mínimo se ter um backlog com stories e um acompanhamento de stories por sprint, tipo um burn out chart. Se não sabe do que estou falando leia os papers originais de Scrum do Schwaber e Sutherland.

Agora, muito mais do que isso eu acho desnecessário. Isso porque essas medidas já são grosseiras, é mais pra ter ordem de grandeza e não exatidão. Sprints também deveriam ser semanais, duas semanas no máximo, mais do que isso e eu posso adivinhar que tem outros problemas graves sendo escondidos. Por exemplo, suas reuniões duram tempo demais e certamente são desnecessárias. Lógico que não dá pra ter um sprint de 1 semana se a segunda feira inteira é gasta só em planejamento e a sexta feira inteira é gasta com review e retrospectiva, e de terça a quinta todo mundo da equipe é toda hora interrompido.

Não adianta querer medir produtividade, no sentido de código entregue por semana. Seu maior problema de produtividade é desperdício de tempo. De novo, um gestor que não tem muita noção do que está fazendo acha que discutir por horas, vai chegar em algum lugar. No máximo é um gestor que sente que está trabalhando muito por gastar muitas horas fazendo reunião. Fazer reunião é o oposto de trabalhar. Tudo que pode ser resolvido por email, deve ser resolvido por email. Você se junta cara a cara quando a discussão claramente não está evoluindo. Aí faz uma reunião pra bater o martelo, e não pra gerar mais discussões.

Isso sem contar métricas aleatórias que obviamente são prejudiciais. Por exemplo, já vi lugares que mediam quantidade de bugs corrigidos. Ou seja, parecia uma coisa boa, quem mais corrigisse bugs, era o melhor. Não precisa ser nenhum gênio pra saber o que isso vai gerar: ninguém vai se preocupar em não gerar bugs. Já que a métrica é corrigir bugs, então o incentivo vai ser em criar mais bugs. Métricas ruins podem afundar sua empresa, porque se você encheu o lugar de pessoas ruins e deu incentivos pra elas serem ruins, é isso que elas vão ser: ruins. Nunca se esqueçam que no geral, as pessoas sempre vão escolher o caminho de menor esforço, é praticamente uma lei econômica isso.

Não tem nada em comunicação que me irrita mais do que quem não sabe o objetivo da comunicação. Ninguém gosta de ouvir sua voz por mais tempo do que o necessário. Ninguem está interessado no seu discurso. A gente só quer saber: qual o objetivo? Qual a direção? Se for um navio é “virar 15 graus a bombordo”. Pronto, essa é a informação. Tudo que você falar antes ou falar depois é desnecessário. O bom dia pode vir na mesma mensagem e não antes de um “digitando …” que fica nos três pontinhos por 5 minutos e me faz ficar esperando que nem um idiota. E você tem que estar disponível pra todo mundo da equipe o tempo todo, porque o papel de um bom gestor é ser um facilitador. Gestor que é difícil de encontrar, não presta. Ah, mas é porque ele tá sempre em reunião. Não tenho dúvidas, e isso é um problema que ele precisa se virar e resolver.

Toda interrupção é desperdício. Toda tarefa de 1 hora que foi interrompida por 5 minutos no meio vira 1h e meia ou mais. Porém, toda informação relevante precisa chegar na hora certa. Nem antecipado que não altera o fluxo de nada, e nem atrasado que agora vai custar o dobro pra agir em cima. Qual é a hora certa? É pra isso que existe um gestor. Interrompa todo mundo o tempo todo e sua produtividade vai pro buraco. Evite interromper quando realmente precisa e vai cometer erros que vai custar mais caro lá na frente. Se fosse fácil decidir isso, não precisaríamos de gestores.

Chats como Slack não foram feitos pra serem usados o tempo todo. Se algo realmente urgente surgiu que não pode esperar, sim, acione o alerta vermelho, interrompa quem precisar pra resolver. Porém, se tudo é alerta vermelho, em breve ninguém mais vai dar atenção. Se a informação não for urgente, anote, comunique quem precisa por email no fim do dia. É o tipo de etiqueta que não deveria precisar ser dito.

Falando nisso, aprenda de uma vez por todas: se tudo é uma prioridade, por definição, nada é prioridade. Eu fiz um video só sobre priorizar. E saber priorizar vale pra todo mundo, todo integrante de qualquer equipe, até chegar no dono da empresa. Não existe querer fazer tudo, porque não temos recursos infinitos. Gerenciar é a eterna tarefa de eleger prioridades e cortar coisas que não são prioridade. E como define prioridades? Essa é a pergunta de um milhão de dólares, se existisse forma fácil eu estaria vendendo. Agora, se você não consegue definir prioridades, certamente não deveria estar liderando. Foi o que eu falei antes: tomar decisões quando elas precisam ser tomadas, e não empurrar problemas com a barriga.

Estimativas e prioridades são coisas que só quem está ativamente participando do projeto deveria se preocupar. Burocratas que aparecem de vez em quando, não tem que dar pitaco em nenhuma das duas. E esse é outro problema frequente, especialmente em empresas grandes demais onde um diretor não tem como fisicamente estar presente em todos os lugares. E aí voltamos ao problema do nível A que contrata outro nível A. Todo mundo precisa poder confiar em outras pessoas. Não cegamente, mas com o mínimo de informações que te dão segurança o suficiente pra poder focar em outros lugares que precisam mais da sua atenção. Não existe metodologia nem fórmula mágica pra isso. Ou você tem pessoas que confia ou não tem, e se não tem, não dá pra substituir por métricas mágicas. Elas só vão te iludir por mais tempo do que deveria.

Eu disse antes que um soldado não confia num general que não foi ele mesmo um soldado antes. No mundo ágil temos a história do porco e da galinha. O gerente que não precisamos ter são os galinhas. Por que galinha bota o ovo e vai embora, mas o porco corta na carne. Quem toma decisões precisa cortar na própria carne e não largar o problema pra equipe e ir embora, e só aparecer quando é pra tomar o crédito. Faça isso muitas vezes, e daqui a pouco vai estar se perguntando porque a produtividade da sua equipe só cai.

Houve uma época que toda decisão era mais baseada em métricas financeiras. É de onde vem a má reputação no meme popular de que empresas são entidades do mau que só pensam em dinheiro. E muitas realmente são assim. Daí teve a época de qualidade total, onde finalmente caiu a ficha que qualidade faz tanta diferença quanto financeiro. Foi a partir do fim dos anos 60 que passamos a diferenciar trabalhadores entre aqueles que executam tarefas rotineiras e padronizadas, como numa fábrica, versus uma categoria que começou a crescer cada vez mais, o que Peter Drucker cunhou como knowledge workers ou trabalhadores do conhecimento, que executam tarefas não-rotineiras, como nós programadores.

Muitos conceitos de gestão ainda vem da época da Revolução Industrial. A idéia de hora-homem por exemplo. Mas esses conceitos não funcionam pro dia a dia moderno porque fábricas deixaram de ser o principal componente das indústrias. Então medir só com base nos números financeiros já não dava mais indicativos da saúde geral da empresa. Foi quando surgiram outras formas de enxergar empresas como o famoso Balanced Scorecard do Kaplan e Norton e suas variações a partir do fim dos anos 80, com métricas financeiras e não-financeiras.

Se você for de admistração certamente já viu Balanced Scorecards, se não for, os detalhes não interessam tanto, mais a noção que hoje as empresas não são todas tão burras de só olhar métricas financeiras como muitos ingenuamente assumem. Elas podem ser incompetentes em alguns aspectos, mas a maioria tem que preocupar com múltiplos aspectos da empresa, hoje em dia incluindo coisas como reputação em redes sociais. Mas tudo bem, eu sei que tem empresas burras porque vira e mexe ouço falar dos idiotas que querem monitorar produtividade mandando o funcionário ligar a câmera e instalando software pra ver se ele tá mesmo digitando ou coisas assim. São empresas assim que mancham nosso mercado e eu espero que eles entrem em falência logo. Ou você confia em quem contrata, ou então não contrata. Se alguém quebra sua confiança nesse nível, você não fica brincando de monitorar, você manda embora. É simples asim.

Pra complementar, o maior problema de uma empresa é quando ela trata todo mundo como criança. Sabe, piscina de bolinha e afins? Quando é uma creche, sim, consigo ver a necessidade de monitoramento ativo. Porque crianças são difíceis de prever, e alguém pode acabar se machucando. Mas uma empresa precisa tratar todo mundo como adulto. Se você tem adultos, não precisa ficar microgerenciando nem monitorando. Por outro lado, se você trata todo mundo como criança, de novo é culpa sua. Empresas não são creches. Não acumule crianças birrentas. Monitorar crianças só funciona quando elas mijam nas próprias calças e brincam de ficar fuçando onde achar faca da cozinha pra se cortar. Num trabalho sério, monitoramento desse tipo não serve pra nada, só pra comprovar que a liderança é completamente incompetente.

Enfim, Peter Drucker, pelo menos na minha época, era o be-a-ba da administração. E naquela época também tivemos trabalhos como de Ikujiro Nonaka e Hirotaka Takeuchi, como eu falei no episódio anterior os japoneses aceleraram seus processos de qualidade e gestão. E Nonaka e Takeuchi escreveram vários artigos, incluindo o famoso The New New Product Development Game, que é de onde surgiu o termo “scrum” que depois o Ken Schwaber usou pra formular a metodologia Scrum e se tornou uma das raízes do movimento Ágil.

Qualquer um que tenha minimamente estudado agilidade já leu esse paper. E eu recomendo que dêem uma boa estudada caso ainda não tenham feito isso. É o resumo do resumo sobre organizações e termos como auto organização. Não é de hoje que se fala em coisas como autonomia. Esse paper é dos anos 80 e até hoje a maioria das empresas ignora o que já sabemos que funciona. Uma boa parte das idéias dessa época fala em elevar os funcionários a pensar em vez de só obedecer e executar. Mas sem entrar em caos. Eu explico isso no meu video sobre Organizações.

Parte disso tem a ver com evoluir as pessoas e passar esse conhecimento pra novos projetos. Por exemplo, um dos erros que até hoje ainda vejo muitas empresas cometendo é quando querem iniciar um novo projeto, mas todo mundo está ocupado já. O que eles fazem? Contratam uma empresa terceirizada pra fazer o novo projeto. Isso é um grande erro.

Às vezes não existe outra forma a não ser aumentar o head count, ou seja, quantidade de pessoas. Um bom gestor sempre deve designar novos projetos pros membros mais seniors das suas equipes e colocar terceiros embaixo deles. Se por acaso for uma especialização que ninguem das suas equipes tem, mesmo assim você coloca seus seniors junto com os terceiros pra eles aprenderem seja lá qual especialização que não tem.

Terceiros devem ser tratados como juniors internos. Ambos os casos embaixo dos seniors internos. Os seniors se tornam seniors quando eles aprendem a mentorar os membros menos experientes. Esse é o ciclo sustentável. Depois que o projeto que eles entregaram passa pra fase de operação, que é realmente ser usado, receber correções, ajustes, manutenção, eles precisam aprender a criar sucessores pras suas posições, pra continuar o trabalho enquanto eles assumem novos projetos.

Autonomia só existe se todos os membros conseguem confiar nos demais membros, não cegamente, mas porque os mais experientes sabem que conseguem mentorar os mais novos, e porque os mais novos sabem que tem quem consultar quando tem dúvidas ou problemas. Uma equipe só de seniors é um desperdício e uma equipe só de juniors é um desastre esperando pra acontecer. Toda equipe deve ter capacidades mistas e serem rotativas. Um junior bem mentorado vai se tornar o novo senior no futuro, que vai passar a mentorar os novos juniors. Os antigos seniors vão continuar em novos projetos, que passa a aceitar novos juniors pra mentorar e assim por diante.

Bons gestores sabem reconhecer os pontos fortes e fracos de cada membro e a ajustar as equipes de acordo com isso. Se em todo jogo você só manda o dream team jogar, quem está de reserva nunca vai ganhar experiência, e quando um dos membros estrela tiver problemas, ninguém vai conseguir jogar no seu lugar, a equipe não sabe como lidar com a mudança. Todo jogo não decisivo precisa misturar reservas. Todo treinador sabe disso. É assim que começam a surgir novas estrelas. Todo gestor precisa saber disso também. Nada que fica estático tempo demais é bom, sempre vai deteriorar. Pequenas mudanças, periódicas, é bom. É a beira do caos que falei no episódio passado.

Confiança não é amizade. Entendam isso de uma vez por todas. Uma coisa é o happy hour. Outra coisa é o trabalho. Quem confunde essas coisas, acha que esconder os erros do amigo é uma coisa boa, porque ele não quer se o cagoeta, o x9. Mas isso prejudica ele, prejudica a equipe e prejudica quem está cometendo os erros. Se você desse o feedback honesto, estaria dando a chance dele corrigir o erro e melhorar. E quando a pessoa se recusa a corrigir o erro, ele é quem está quebrando a confiança com você. Ninguém precisa de pessoas desonestas do lado, especialmente aquele que te chama de amigo só quando interessa. Corte essas pessoas, o quanto antes. Seja realista. Incompetência é algo que podemos tentar consertar. Porém, maucaratismo se corta na raíz. Eu sempre digo que se a mãe dele não conseguiu criar caráter nele em 20 anos, não sou eu que em 2 meses vai conseguir. Corta.

Mas o trabalho é assim mesmo: quando você faz algo certo, não é nada demais, afinal você é pago pra fazer certo. Por outro lado, quando comete erros, eles sempre se sobressaem. É a vida, se fosse fácil, qualquer um fazia e ninguém precisaria de você. Senioridade é aprender a lidar com isso e continuar caminhando em frente. E o papel do gestor não é fazer tudo sozinho, é conseguir construir uma equipe onde todos tem essa mentalidade, e naturalmente os projetos tendem a alcançar sucesso. Não porque todo mundo previu logo no começo tudo que precisava fazer, mas sim porque entendem que erros vão acontecer no caminho e as expectativas vão sendo realinhadas de acordo. Os stakeholders não ficam sabendo de desastres só quando já é tarde demais, esse é o principal. Todo erro identificado o quanto antes, tem chances de ser arrumado.

Gerenciar projetos é gerenciar pessoas. E gerenciar pessoas é gerenciar expectativas. Ninguém precisa de alguém que só faz promessas. Todo mundo precisa de pessoas que assumem seus erros e fazem o possível pra corrigir e, claro, evitar repetir os mesmos erros. É só isso. Promessas e discursos são inúteis e desnecessários. A camada de gestão é responsável pela estratégia, a direção e objetivos. As equipes são responsáveis pela tática, a execução. Todo soldado na frente precisa confiar que o soldado de trás vai cobrir sua retaguarda, e assim todos avançam coordenados em busca do mesmo objetivo, que é ganhar mais uma batalha.

Como falei no começo, esses foram só alguns pontos que eu considero importante lembrar. Mas cada parágrafo que eu falei não é mais que um pequeno resumo de um assunto gigante. O tema completo de gerenciamento engloba décadas de experiência e técnicas que vieram sendo aprimoradas, modificadas, e continuam em evolução. Toda técnica moderna de gerenciamento de software nasceu nos últimos 15 a 20 anos. Muita literatura ainda fala de coisas de 3 ou mais décadas no passado. Algumas coisas continuam valendo, outras não. E a função de todo bom gestor é se manter atualizado, experimentar coisas novas, e não perder o foco sobre sua missão, que é entregar projetos de forma sustentável e ajudar a evoluir suas equipes. Se ficaram com dúvidas mandem nos comentários abaixo, se curtiram o video deixem um joinha, assinem o canal, e compartilhem o video com seus amigos. A gente se vê, até mais.

]]>gestaoagileakitando[Akitando] #104 - RANT: Empreendendo com Software do JEITO ERRADO!https://akitaonrails.github.io/2021/09/28/akitando-104-rant-empreendendo-com-software-do-jeito-errado/https://akitaonrails.github.io/2021/09/28/akitando-104-rant-empreendendo-com-software-do-jeito-errado/Tue, 28 Sep 2021 11:20:00 -0300<div class="embed-container"> <iframe src="https://www.youtube.com/embed/NuIOO5VWmXc" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen> </iframe> </div> <h2>DESCRIÇÃO<span class="hx:absolute hx:-mt-20" id="descrição"></span> <a href="#descri%c3%a7%c3%a3o" class="subheading-anchor" aria-label="Permalink for this section"></a></h2><p>Depois de 2+ décadas atendendo centenas de projetos, quero resumir alguns dos casos toscos que eu já vi no caso de pequenos empreendedores amadores não-técnicos e muitas das coisas que eles pensam errado e fazem errado com projetos de software.</p> <p>Assista pra não cometer os mesmos erros!</p> <p>Se gostou da proposta do video e quiser se candidatar, estamos contratando: <a href="mailto:become@codeminer42.com">become@codeminer42.com</a></p>

DESCRIÇÃO

Depois de 2+ décadas atendendo centenas de projetos, quero resumir alguns dos casos toscos que eu já vi no caso de pequenos empreendedores amadores não-técnicos e muitas das coisas que eles pensam errado e fazem errado com projetos de software.

Assista pra não cometer os mesmos erros!

Se gostou da proposta do video e quiser se candidatar, estamos contratando: become@codeminer42.com

Conteúdo:

  • 00:00 - Intro
  • 01:27 - Disclaimer
  • 02:02 - Sua idéia NÃO é original
  • 03:00 - Zero Experiência
  • 04:04 - Sem co-fundador técnico
  • 05:40 - Sua empresa sequestrada!
  • 07:30 - Não reinvente a roda!
  • 07:54 - Especificações que não valem NADA!
  • 10:25 - Escopo Fechado NÃO FUNCIONA!
  • 11:53 - Por que o que você imaginou vai desandar
  • 15:24 - Software NUNCA acaba!
  • 15:52 - Você PRECISA de Júniors!
  • 18:07 - Economia PORCA
  • 18:33 - NUNCA TERCEIRIZE TUDO!
  • 20:10 - Indianos e Príncipes Nigerianos
  • 21:01 - Dá pra fazer igual empresa X??
  • 22:06 - NDA é lixo
  • 23:05 - Jurídicos AMADORES
  • 23:35 - Licitações: LIXO
  • 24:45 - E o que você REALMENTE deveria fazer?
  • 26:17 - Fechamento

SCRIPT

Olá pessoal, Fabio Akita

Andei um pouco sumido nas últimas semanas porque a última série me cansou um pouco, acho que exagerei e detalhei demais um tema só e isso me deixou bem entediado. Então vou retornar um pouco mais light antes de pegar mais temas técnicos. Hoje quero mudar de marcha e falar um pouco sobre projetos.

Por décadas eu trabalhei em projetos de software e até hoje vejo que muita gente ainda pensa errado, especialmente os amadores, mas até gente que diz ter experiência comete alguns desses erros. Estando do lado da empresa que realiza os projetos, quero explicar que tipo de coisas que aparecem na minha porta e que eu quero chutar a mesa quando escuto. Obviamente não dá pra cobrir tudo, mas vou dar alguns exemplos pra que vocês não cometam os mesmos erros no futuro.

Uma coisa que você vai ouvir sempre é “depende”. Quanto custa? Depende. Quanto tempo leva? Depende. O que eu vou precisar fazer? Depende. E depende porque como já disse no video sobre The Mythical Man-Month, não existe Bala de Prata. Não existem soluções one-size-fits-all, ou seja um tamanho que cabe em qualquer problema. Todo projeto é sempre caso a caso. Hoje quero focar mais no pequeno empreendedor, microempresa, a startup de primeira viagem, o fundador individual não-técnico que nunca participou de projetos de software antes.

(…)

Como disclaimer vale dizer eu não estou generalizando dizendo que todo mundo que empreende, começa um projeto do zero faz tudo errado como vou falar agora. Já consigo ver gente nos comentários falando “ah, mas eu não sou assim” ou “ah, mas eu conheço gente que não é assim” e bla bla bla. Foda-se. Óbvio que existem exceções, senão não existiriam casos de sucesso. Mas é um fato que ao longo de quase 30 anos, tendo passado por literalmente centenas de projetos, estatisticamente a grande maioria se encaixa muito no que vou explicar hoje. Se a carapuça servir, não culpem o mensageiro, só isso.

Parte do que vou falar hoje já falei no video dos mitos de startups, mas vou repetir pra reforçar. E a primeira coisa que todo empreendedor de primeira viagem acha, é que teve alguma idéia inédita que vai revolucionar alguma área ou até o mundo - se for mais um megalomaníaco iludido. Deixa eu colocar da maneira mais suave possível: sua idéia não é original e muito menos revolucionária. Entenda: é muito, mas muito raro alguém surgir com uma idéia verdadeiramente inédita e revolucionária. Não importa o que sua mãe diga pra você, sua idéia é medíocre, na melhor das hipóteses.

Se você gosta de alguma área e gastou 10 anos fazendo pesquisa, estudando, criando protótipos, testando de verdade no mercado, voltando pra mesa de projetos e redesenhando, melhorando e investindo e depois desses 10 anos, talvez, talvez, você tenha conseguido chegar numa ideia razoavelmente original. Isso é possível. A pergunta é: você gastou esse tempo e esforço?

A coisa mais tosca que me deixa pasmo toda vez que eu ouço é um recém formado, faz de conta, de medicina, chegando pra mim e falando “Akita, vou revolucionar o mercado de hospitais”. A primeira pergunta que eu tenho que fazer é “filho, quantos anos e em quantos hospitais você já trabalhou?” E a resposta sempre é: nenhum, ou muito pouco tempo. E como você acha que vai revolucionar um mercado onde você sequer trabalhou ainda? Simples: não vai. Esquece. “Ah, mas teve o caso daquele outro cara que chegou e revolucionou do nada … “ - cara, um caso, você tá se baseando na exceção da exceção?

Pra compensar isso, o caso seguinte é quando o tal empreendedor conheceu alguém que já trabalhou os tais 10 anos ou mais na tal área e eles acham que juntos vão mudar o mercado. Ok, justo, é um pouco melhor. Não muito, mas já vi dar certo algumas vezes. Poucas vezes. O problema é que agora querem criar um software pra implementar essa ideia. Quantos anos eles tem de experiência trabalhando em projetos de software? Zero. Chances de dar certo? Perto de zero também.

Eu não consigo entender fundadores não técnicos querendo criar uma empresa de software sem ter outro co-fundador que tenha anos de experiência nessa área. É quem ocuparia o cargo de CTO ou Vice presidente de engenharia ou diretor de tecnologia ou qualquer coisa assim. Alguém que já participou diretamente na codificação de diversos sistemas, de diversos tamanhos, e já esbarrou em todo tipo de problemas, tá calejado.

Entenda, se você quer ser uma tech startup significa que o Core Business, o negócio central, dessa empresa é tecnologia. Alguém de cargo de confiança precisa ser responsável por isso. Isso não é opcional. Não se terceiriza o core business inteiro da sua empresa. E eu digo isso sendo um terceirizador. Eu não quero a responsabilidade de decidir por você, porque eu não sou e nem vou ser seu sócio. Nenhum terceirizado jamais vai ter o mesmo nível de preocupação porque a gente não é stakeholder. Entenda esse conceito: não importa o quanto o vendedor te prometeu que vai ser o melhor relacionamento do mundo. Palavras são só palavras.

Também cansei de ver empreendedores não-técnicos falando que começaram a fazer algum curso online de programação, achando que isso vai fazer alguma diferença. Sério? Você acha que pra fazer sistemas eficientes, robustos, seguros, de fácil manutenção é só gastar algumas míseras semanas assistindo video no YouTube? Não perca seu tempo, não é sua praia, não vai fazer absolutamente nenhuma diferença. Foque nas suas responsabilidades. Ou você já é um engenheiro de carreira com anos de experiência nas costas ou você tem um sócio nesse perfil que confia totalmente. Não inventa moda.

Cansei de ver gente que contratou freelancer pra cuidar de tudo. A senha da Amazon fica com esse freelancer, a conta da organização do GitHub fica com esse freelancer, todos os acessos e permissões mais importantes, que podem desligar sua empresa, estão na mão de alguém que sequer é um funcionário da sua própria empresa. É que nem você ter 1 milhão de reais na sua conta de banco e nem você tem a senha dessa conta, está na mão de um estranho qualquer. Você faria isso?

O que acontece se no final o cara que parecia gente boa se mostra de má índole? Em bom português, você se ferrou. Você foi juvenil, agora vem as consequências. O mínimo do mínimo é que você como dono da empresa ou co-fundador técnico tenha os meios de desligar alguém da empresa e ele não ter acesso às coisas que mantém seu negócio de pé. Se não sabe como fazer isso, nem comece. Nunca dê as chaves da sua casa pra um estranho.

Isso é especialmente mais importante agora que existe a LGPD que é a Lei Geral de Proteção aos Dados. Se um terceiro faz bobagem com seu banco de dados e compromete dados pessoais dos seus usuários é sua empresa e você que são responsáveis. Se você precisa compartilhar parte desses dados com um terceiro, tem que ler a lei pra saber em quais condições e o que é necessário fazer pra não ficar juridicamente exposto. Não adianta dizer “ah, eu não sabia”. Ignorância das leis não te torna inocente.

Muitos projetos que as pessoas vem pedir são coisas que já existem. Um ecommerce, uma plataforma de ensino, um meio de pagamento ou algo assim. Vamos entender: seu negócio principal é produzir algum produto pra vender? Então seu core business, pelo menos no começo, não é tecnologia, é manufatura e vendas. Não tente construir seu próprio ecommerce, não é sua praia. Faça uma pesquisa, hoje em dia temos dezenas de plataformas pré-prontas que vão fazer praticamente tudo que você precisa de forma melhor do que se você tentar fazer do zero.

Não reinvente a roda, se precisa vender, abra uma conta num Shopify da vida. Lá na frente, quando seus processos de manufatura estiverem azeitados, quando já tiver bom volume de vendas e, principalmente, boa margem de lucros, daí sim, talvez você queira mais controle da tecnologia e vai ter dinheiro pra pesquisar e investir. E acredite, não vai ser barato, então não coloque o carro na frente dos bois.

Digamos que você chegou nesse ponto, ou talvez conseguiu ludibriar algum investidor disposto a colocar dinheiro no seu negócio. De novo, se você não tem um co-fundador técnico com muita experiência - e ênfase aqui em muita experiência, porque um co-fundador técnico recém formado não vai te ajudar em muita coisa. Daí você comete o próximo erro clássico: começa a desenhar como acha que seu sistema perfeito deveria ser.

Normalmente contrata algum designer, sei lá porque, pra sair desenhando telas de mockup. Acho impressionante quando vejo esses trabalhos porque vira um calhamaço de telas e a primeira tonelada de papel é sempre telas de formulários pra se registrar, login, esqueci minha senha e outras bobagens assim. Sério? Todo mundo sabe como um formulário de registro funciona, não precisa detalhar isso.

Mas coisas que deveriam ter sido especificadas e até feito mockup incluem as funcionalidades chatas que ninguém gosta de fazer justamente porque nem sabem que existem e como deveriam funcionar: as partes administrativas, relatórios, integração com backoffice e todos os controles que precisa pro sistema realmente funcionar. Pergunta se alguém que faz mockups lembra de desenhar essas coisas? Raramente! Dão mais atenção pra uma tela de login do que um admin.

Entenda: você, marinheiro de primeira viagem, sempre vai conseguir desenhar o que “acha” que precisa e não o que “realmente” precisa. No papel pode tudo mas sua imaginação não vai conseguir visualizar coisas que você nunca viu, as coisas por trás das telas bonitas. Se for um ecommerce, no final vira um copy e paste das telas de uma Magazine Luiza ou Mercado Livre. Mas se você nunca trabalhou numa plataforma dessas, não tem idéia de como eles funcionam por trás. O tanto de sistema que existe que um usuário jamais vai ver. Logística é um grande exemplo. Você realmente acha que com seus trocados e nenhuma experiência vai fazer uma fração disso? Não vai, então pára de chegar pedindo “ahh, dá pra fazer essa funcionalidade igual do MercadoLivre?” - claro que dá, se você pagar a mesma coisa que eles investiram, a gente pode tentar fazer.

Acho interessante que a primeira concepção que alguém sem experiência chega sempre é achar que é possível desenhar tudo em papel e de uma só vez chegar num software que funciona, custando “barato” ainda. Não é assim que software funciona. Design emerge do software e não o contrário. Software nunca tá pronto na versão 1.0. É sempre um trabalho em andamento. Se você acha que terminou a última linha de código e nunca mais vai mexer, provavelmente é um software que ninguém usa.

E na sequência dessa concepção errada, vem outra concepção errada. A próxima pergunta é “olha só, fiz aqui o desenho, me dá um prazo e quanto vai custar.” Podemos ficar dias aqui discutindo porque esse pedido não faz sentido. Construir um negócio baseado em software não é que nem construir uma casa, que quando o último tijolo for colocado, acabou. Nunca vai ter o último tijolo.

A primeira coisa que vou dizer é: a maior parte do que tá desenhado aqui você não vai precisar. Pode jogar tudo fora, perda de tempo. A segunda coisa é: esquece, posso dar uma ordem de grandeza de quanto vai custar pra chegar numa versão minimamente funcional. Mas o software nunca vai terminar. No mínimo, no mínimo, você sempre vai precisar fazer atualizações de segurança, nos frameworks, bibliotecas e outros componentes da infraestrutura. Senão em pouquíssimo tempo seu sistema vai ser atacado e invadido embaixo do seu nariz. Não pode largar código rodando sem ninguém mais vendo.

Entenda, você só vai entender o que realmente precisa implementar quando uma versão mínima for pro ar, pessoas reais realmente começarem a usar, e daí as reais necessidades vão começar a emergir e elas vão quase sempre ser diferentes do que você imaginou. É a natureza de se lidar com tecnologia. Só quando é um software muito pequeno, pra poucos usuários, e que é um copy e paste de outro software que já existe. Por exemplo, você só quer colocar no ar mais um Wordpress da vida e mudar o logotipo na primeira página. Ok, isso pode ser simples, barato e vai pro ar logo. Muito mais que isso é incerto.

Num exemplo tosco só pra ilustrar aqui. Um pequeno ecommerce, você pode facilmente baixar um Magento da vida que é um ecommerce de código aberto, pagar alguém pra instalar num servidorzinho qualquer e tá pronto. Dificilmente vai ser simples assim, mas enfim. Um freelancer amador vai instalar tudo num VPS, tipo numa DigitalOcean ou Linode da vida, servidor web, banco de dados, tudo numa máquina virtual só. Vai suportar algumas dezenas de usuários e se você só precisa disso, ok, tá pronto. Por algum tempo vai funcionar.

Mas normalmente não é só isso. Provavelmente você quer integrar com meios de pagamento, por exemplo. Alguns já tem plugins pré-prontos pra um Magento da vida, outros não. Implementar pode ser fácil ou difícil. Se sua empresa tem algum mínimo de organização, certamente tem um ou mais sistemas de backoffice, um ERP, que administra aspectos da sua empresa como manufatura, estoque, contabilidade, RH, CRM e mais. Você provavelmente quer integrar com ele, pra poder gerar nota fiscal, controlar faturamento, contas a pagar e a receber, disponibilidade de produtos.

Isso é mais difícil ter plugins prontos, alguém vai precisar integrar, e se for um amador como é a maioria dos casos, vai fazer uma zona. Certeza. Em breve você vai ter problemas de performance. O banco de dados rapidamente vai se tornar um gargalo. Então você instala mais plugins como de cache pra tentar ajudar. Não tava previsto, porque quem nunca fez projetos grandes, não vai saber que precisa disso. Lá se vão mais dias de bateção de cabeça.

Por acaso você tem sorte, e seu marketing foi competente pra trazer muitos usuários. De repente nenhuma venda acontece. Começa a vir um monte de tickets de suporte porque ninguém consegue comprar nada. Lembra aquela integração com seu ERP? Pois é, foi feita de tal maneira que se ela não responder a tempo, seu checkout falha. Clássico. Nenhum ERP foi feito pra aguentar escala de web e se você programa um passo pra ser sequencial e dependente do outro, dançou. Todo amador cai nisso.

Agora tem que rearquitetar pra resposta do ERP ser assíncrona do checkout e só bloquear a próxima etapa, que é a entrega, por exemplo. Tornar um código síncrono em assíncrono significa ter que colocar uma fila, e se tiver uma fila é mais um componente que precisa ser monitorado e gerenciado porque se cair e perder o que tava lá, muitas vendas vão ficar bloqueadas ou corrompidas de novo. Uma solução sempre vai criando novos problemas. Não existe uma solução definitiva que resolve todos os problemas e você nunca mais vai precisar olhar.

Esse cenário é bem mais comum do que parece. Já vi acontecer várias vezes. Mas o oposto é igualmente ruim, que é quando alguém que já passou por essas coisas uma ou duas vezes, agora quer tentar prever tudo que pode dar errado e implementar de uma vez no projeto que tá fase super inicial, onde o negócio não foi provado, não tem um usuário pagante ainda. Agora o sistema fica tão complexo de fazer, demora tanto tempo, e por consequência custa tão caro, que o negócio não aguenta esperar tanto e fecha as portas. Nem tanto oito, nem tanto oitenta. E é aí que experiência faz diferença.

Em vez de planejar um projeto que vai levar 2 anos pra ficar pronto o melhor é planejar uma versão mínima, que dá fazer em 2 ou 3 meses pra testar a ideia e o mercado. Se tudo der errado, você perdeu 3 meses em vez de 2 anos. Toda vez que acha que pode economizar 100% já prevendo e fazendo tudo de uma vez, é quando você vai se dar mau, garantidamente. Porque você está partindo da premissa errada que dá pra prever tudo e que você vai aguentar esperar implementar tudo. Melhor arriscar pouco e perder pouco. Não existe risco zero, existe gerenciar riscos. E colocar todos os ovos num lugar só é o oposto disso.

Por isso não venha com mentalidade de “ah, depois de 1 ano, meu sistema vai estar pronto e nunca mais vou precisar me preocupar”. Você sempre vai precisar se preocupar. Dar manutenção, atualização. Melhorar seu sistema com o feedback dos seus usuários tem que virar parte da rotina da sua empresa e você deve se preparar pra isso. Precisa de sistema de suporte, precisa de equipe treinada pra atender as pessoas. O mercado é super competitivo, quem fica parado e não ouve seus usuários, sempre vai ficando pra trás.

Outro erro super comum. Mesmo caso, o cara me chega com um calhamaço de especificações e pede “pra fazer meu sistema perfeito, preciso da equipe perfeita, me vê aí uns 5 ou 6 desenvolvedores sênior, pra viagem”. Povo pensa que é pastelaria. Nenhum projeto precisa ter só seniors, além de ser um desperdício, você vai desmotivar pelo menos metade deles, que em pouco tempo vão vazar. Isso porque todo projeto tem tarefas desafiadoras e tem muitas tarefas mundanas. Ficar trocando textos, substituir imagens, corrigir pequenos bugs, atender suporte. Pede pra um senior fazer isso, ele vai mandar você ir lá praquele lugar, especialmente num mercado aquecido e competitivo como de agora.

É que nem você querer construir sua casa dos sonhos, aí na sua infinita sabedoria pensa “cara, não vou contratar nenhum pedreiro, vou contratar uma dúzia de mestres de obra. Se os pedreiros fazem minha casa em 6 meses, certamente os mestres de obra sozinhos vão fazer em 3 meses e ainda com muito mais qualidade”. Entenderam o ridículo? Todo projeto tem tarefas pra seniors e pra juniors. A tarefa mundana que o senior já fez quinhentas vezes e não quer fazer de novo? É exatamente o tipo de tarefa que um junior precisa pra ganhar experiência.

Coloque seniors orientando juniors e não só sua produtividade vai ser melhor do que num time só de seniors, vão ser todos mais motivados e você ainda aproveita pra garantir que sua equipe naturalmente consiga se auto-repor. O junior de hoje é o senior de amanhã. E quando chegar amanhã ele vai saber da importância de orientar novos juniors, porque foi assim que ele cresceu também. É um ciclo positivo. Toda empresa de tecnologia precisa de juniors, estagiários. Não é sustentável achar que sempre você vai achar seniors com disposição pra ficar fazendo tarefas mundanas de manutenção. É isso que eu pratico na minha empresa faz anos.

“Ah, esse mercado tá foda, não consigo contratar.” Lógico, você tá procurando só seniors pra ficar mudando botão de lugar na sua tela. Não é o mercado que tá foda, é você que não sabe contratar e não sabe formar pessoas. Formação de novas pessoas é fundamental pra qualquer negócio, seja grandes corporações ou pequenas startups. Pessoas entram e saem, ninguém fica pra sempre, mas se você forma pessoas, seu processo já está adaptado a mudanças.

Não sei se vocês notaram, mas em todos os exemplos que falei até agora o tema comum é que todo mundo sempre pensa em economizar. E tá correto, não se deve esbanjar dinheiro a toa. Mesmo quando tem sobrando. Porém, em todos os casos, estamos falando de casos de “economia porca”. Toda economia porca sempre vai sair caro lá na frente. É que nem comprar um Mercedes e querer economizar não fazendo seguro. O que acham que vai acontecer? Murphy é o cara que mais trabalha.

Um exemplo disso é quando o tal empreendedor decide que gerenciar projetos, gerenciar pessoas, processos de tecnologia e tudo mais não é pra ele. Então terceiriza 100% de toda a tecnologia pra outra empresa. Pronto, agora ele só dá ordem, paga fatura no fim do mês, e deixa outra pessoa com a dor de cabeça de gerenciar tudo. Faz uma pesquisa porca, acha uma agênciazinha de esquina que tem um sisteminha pré-pronto e lá vai ele confiar o negócio pra um estranho.

Hoje em dia é comum no mundo de Software as a Service, ou SaaS, mudar muita coisa de capex pra opex. Em poucas palavras mudar de gastos internos pra gastos externos, ou de propriedade própria pra aluguel de serviços. Por exemplo, seria impossível toda empresa ter seu próprio servidor de emails que seja rápido, seguro e tudo mais. Por isso ninguém faz isso, todo mundo faz uma assinatura do Gmail, Outlook e outros e pronto. O mesmo vale pra vários outros serviços como video conferência, email marketing, até CRM e contabilidade. Todo mundo conhece as marcas mais famosas e mais confiáveis. Mailchimp, Salesforce, Zoom e muito mais.

O problema é contratar uma empresinha desconhecida de fundo de quintal, onde você paga pra eles desenvolverem customizações ou novas funcionalidades, mas por contrato você não é dono do que tá pagando pra construir. Propriedade intelectual é sério. Software é propriedade intelectual. Mas no começo você não se incomoda, afinal sai mais em conta pra você trabalhar assim. Se alguma coisa parece boa demais, é porque é: é menos caro porque você não tinha a propriedade. E se no futuro o relacionamento azedar, você fica sem nada. E acredite, sempre azeda. É assim que as coisas funcionam. Aprenda a ler contratos.

Mas aí você não quer nem pagar caro e nem ficar na mão de um terceiro assim. Aconteceu um caso que o cara veio pedir uma demanda pra minha empresa, passamos o preço e ele reclamou que achou muito caro e que se a gente não baixasse ia terceirizar pra uma empresa indiana. Por alguma razão acho que ele achava que tava me oferecendo alguma grande honra de trabalhar pra ele.

Resumindo minha resposta eu disse algo como “não tem nenhum problema, o código é seu, você terceiriza pra quem você quiser. Mas eu não abaixo meu preço, e já aviso que você vai pagar a metade com os indianos e daqui 6 meses vai voltar pra mim pedindo pra consertar, e nessa hora meu preço vai ser o dobro.” Seis meses depois, ele voltou. Não existe almoço de graça, você recebe proporcional ao que paga, se foi barato, é porque o resultado vai ser porco. Simples assim. Eu recebo tanto email de empresa desconhecida indiana me oferecendo serviços que eles já tão ganhando do príncipe nigeriano.

Tô cansado de virem procurar a gente falando “olha só, conhece esse site X? Quanto vocês cobram pra fazer igual? Eu falei com um indiano e ele me falou que por mil dólares ele faz, se vocês fizerem por menos fecho com vocês”. Não estou nem inventando, foi um caso recente. Você abre o tal site, é uma plataforma de fintech, mais ou menos. Só tem um hotsite bonitinho. Eu nem duvido que por mil dólares ele faça a 1a página, que é exatamente o que a maioria das pessoas pensa.

Entenda, só a primeira página. Esquece as coisas invisíveis por baixo: integração com outras plataformas, banco de dados, administrativo, etc. Muita gente acha que um site é só as primeiras páginas que ele vê, sendo que o grosso do trabalho é tudo aquilo que um usuário comum nunca vai ver. Como eu falei antes do designer que só faz mockup da página de login, porque é só isso que ele conhece. E muita gente acredita que é só isso mesmo. Mil dólares pfff. Um protótipo de software começa na ordem de grandeza de 10 vezes isso. Uma tech startup de verdade começa na ordem de 100 vezes isso. Pra mais. Mil dólares …

Falando em gente que inventa abobrinha, coloco nessa categoria os famosos NDAs que me mandam pra assinar. Coisa de departamento jurídico amador ou empreendedor de primeira viagem querendo impressionar do jeito errado. NDA pra quem não sabe é non-disclosure agreement, basicamente um contrato de confidencialidade querendo dizer “eu acho que minha ideia é super foda, mas ninguém pode ficar sabendo, e se você roubar minha ideia ou contar pra alguém, cobro uma multa”. Acho NDA uma coisa ridícula, especialmente pra empresa iniciante.

Como eu disse lá no começo, sua ideia não é original, pára de ficar se super-valorizando. Em segundo lugar, se sua ideia realmente é algo fora do comum que eu nunca vi, e se eu for de má índole e quiser roubar, a multa de um NDA é só um preço de compra barato. Só isso. Qual é a multa? 1 milhão de reais? 5 milhões? Noooosa. Se a ideia for tão boa assim deve valer 50 milhões, 100 milhões? Comprar por um 1 milhão é barato, pago a vista, em cash se quiser. Tosco.

E esses departamentos juridicos amadores são os que fazem contratos toscos, copy e paste de alguma coisa que viu no Google, com cláusulas do tipo “pra trabalhar com a gente, você se compromete, caso a gente termine, de não trabalhar com mais nenhuma empresa do setor”. Aí você vê que o cara é do setor de fintech. Ele acha que eu nunca mais vou trabalhar com nenhum outro fintech. Tá de brincadeira? Quer comprar minha empresa, você paga por ela. De graça, vai sonhando. É impressionante a quantidade de juridico tosco assim que eu vejo.

Jurídico tosco me lembra de licitações. Como eu já expliquei, software não tem como especificar e construir exatamente. Eu ainda estou pra ver uma licitação que especifica alguma coisa direito. Pra quem não sabe licitação é um leilão. A empresa faz o desenho de um projeto de software e convida algumas empresas pra avaliar e apresentar propostas de tempo, custo, suporte e tudo mais. Daí eles escolhem o mais barato, normalmente, ou a empresa de algum conhecido. Então é tudo menos justo. Como eu disse: barato sai caro e eu não participo de licitações porque acho o modelo inteiro tosco pra começo de conversa. Só lamento pra quem precisa trabalhar nesse modelo.

Isso me lembra de casos que a gente já recebeu de licitação que pede pra gente mandar um prazo pra entregar o projeto, sendo que um dos itens de trabalho que vai ser realizado é literalmente “definir o escopo”. Entenderam? Pra participar da licitação eles querem que a gente já se comprometa num prazo final sendo que o escopo nem sequer está definido e vai ser parte do projeto, depois que ganhar a licitação, definir esse escopo. É uma piada de tão mau gosto que fico imaginando que tipo de gênio da lâmpada escreve essas coisas e pior ainda, que tipo de animal aprova isso.

Eu disse que ia me focar no pequeno empreeededor mas licitação já começa a entrar na área de empresas maiores então acho que é minha deixa pra finalizar. Se não ficou claro, no dia zero, quando você tá pensando em criar um software pra sua empresa e você é o dono e/ou o investidor principal, nem pense em começar se não tem um sócio técnico experiente pra gerenciar tudo. Contrate alguns programadores internamente primeiro, funcionários devidamente contratados em tempo integral, e não freelancers.

Só depois terceirize uma parte pra acelerar a produtividade, mas faça os terceiros trabalharem junto com seus funcionários de confiança, nunca em modelo de black box onde você manda especificação e fica meses esperando eles entregarem alguma coisa depois. Se preocupe com aspectos de infraestrutura e segurança, LGPD tá aí. E se preocupe em formar pessoas. Você precisa sim de bons seniors, que sejam de confiança, que vão ajudar a orientar e treinar os juniors e estagiários. Esse é o básico do básico.

E veja, falei um monte até aqui e nem entrei no assunto sobre melhores linguagens de programação, frameworks ou coisas assim. Porque não importa. A melhor linguagem e ferramentas são aquelas que seus melhores funcionários preferem. Não é essa escolha que vai fazer diferença se todo o resto que falei antes não estiver correto primeiro. Você como administrador e empreendedor não-técnico não tem que meter o bedelho nisso, pra isso serve um CTO ou um Tech Lead. E lembre-se do mais importante: economia porca não compensa.

Tem muito mais que posso falar sobre isso, mas acho que por hoje é o suficiente. Se ficaram com dúvidas mandem nos comentários abaixo, se curtiram o video deixem um joinha, assinem o canal e não deixem de compartilhar o video com seus amigos. A gente se vê, até mais.

]]>startupsengenharia-de-softwaregestaoakitando[Akitando] #57 - O Guia DEFINITIVO de Organizações | Desconstruindo o Modelo Spotify [RATED R]https://akitaonrails.github.io/2019/07/31/akitando-57-o-guia-definitivo-de-organizacoes-desconstruindo-o-modelo-spotify-rated-r/https://akitaonrails.github.io/2019/07/31/akitando-57-o-guia-definitivo-de-organizacoes-desconstruindo-o-modelo-spotify-rated-r/Wed, 31 Jul 2019 17:00:00 -0300<div class="embed-container"> <iframe src="https://www.youtube.com/embed/6S94h3xSbnI" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen> </iframe> </div> <p>No episódio &ldquo;Esqueça Metodologias &lsquo;Ágeis&rsquo;&rdquo; eu critico como consultorias e coaches deturparam e prostituíram as idéia originais de agilidade.</p> <p>O episódio de hoje continua na mesma idéia de como a idéia do tal &ldquo;Modelo Spotify&rdquo; ou &ldquo;Modelo de Squads&rdquo; foi também surrupiada pelos mesmos perpetradores e deturpada até o próprio Spotify não reconhecer mais.</p> <p>Mas eu resolvi andar a última milha e ir além, eu quero usar o que o paper do Spotify descreve pra explicar de onde vêm conceitos como &ldquo;Auto-organização&rdquo;, o que de fato são &ldquo;organizações ágeis&rdquo; e quais são todos os erros que que todas as empresas cometem quando pensam em implementar metodologias desse tipo.</p>

No episódio “Esqueça Metodologias ‘Ágeis’” eu critico como consultorias e coaches deturparam e prostituíram as idéia originais de agilidade.

O episódio de hoje continua na mesma idéia de como a idéia do tal “Modelo Spotify” ou “Modelo de Squads” foi também surrupiada pelos mesmos perpetradores e deturpada até o próprio Spotify não reconhecer mais.

Mas eu resolvi andar a última milha e ir além, eu quero usar o que o paper do Spotify descreve pra explicar de onde vêm conceitos como “Auto-organização”, o que de fato são “organizações ágeis” e quais são todos os erros que que todas as empresas cometem quando pensam em implementar metodologias desse tipo.

O vídeo é BEM longo, e a primeira metade vai soar bastante estranho. Em algum momento vocês vão pensar “onde esse cara tá querendo chegar”, mas eu peço que tenham um pouco de paciência e assistam até o final pra entender meu ponto.

Links:

=== Script

Olá pessoal, Fabio Akita

O vídeo que eu fiz chamado “Esqueça metodologias Ágeis” fez um sucesso enorme no canal e vocês andaram compartilhando pra lá e pra cá e eu agradeço bastante por isso! Eu fiz o video como faço todos os outros: eu peguei um assunto que me interessa e tentei explicar de uma forma que a maioria consiga entender, e eu realmente não esperava que fosse viralizar assim. Ao que parece muito mais gente do que eu pensava estava incomodado com as mesmas coisas.

No vídeo de hoje quero fazer uma continuação. O problema original foi como uma Boa idéia que é o conceito de agilidade foi prostituído e transformado em um produto que consultorias e coaches vendem e cuja implementação em nada lembra os objetivos originais do Manifesto. Quando nós agilistas dizemos que Ágil está morto significa dizer que o que você consome hoje como Ágil provavelmente não é mais Ágil.

Eu venho pesquisando, aplicando e escrevendo a respeito do assunto geral de gerenciamento faz mais de 10 anos. Se você entrar no meu blog na url akitaonrails.com/management vai encontrar artigos e traduções que eu acumulei desde 2007 até pelo menos 2017. Recomendo dar uma olhada nesse material também.

À medida que os termos de agilidade se tornaram diluídos ao ponto de quase não reconhecermos mais, assim também aconteceu com outros conceitos do passado como o Lean da Toyota que hoje virou o irreconhecível Kanban ou Lean Startup. E agora outro conceito que vem sendo esticado além do que deveria que é o tal modelo do Spotify ou modelo de Squads. A idéia desses episódios não é dizer que agilidade, lean ou Squads não funcionam. Claro que funcionam, só que eu vou argumentar que quase todas as pessoas implementando esses modelos vão fracassar.

(…)

O que é o tal modelo do Spotify? Eu não vou explicar em detalhes, porque assim como Scrum ou Lean, você pode ir no Google e vai achar dúzias e dúzias de posts de blog, palestras e até eventos repetindo as estruturas como se não houvesse amanhã. Então vou resumir. Todo mundo a essa altura já conhece o conceito de equipes cross-funcionais, ou feature-teams, que no Spotify eles decidiram chamar de Squads. São como unidades de negócios numa organização em matriz, estrutura que se conhece desde os anos 80 por causa da Digital Equipment Corporation, ou DEC.

Teoricamente, um Squad é responsável por uma funcionalidade ou feature inteira, do design, programação até deployment. Por exemplo, um squad que lida só com a feature de playlist, ou outro só com a organização de álbuns. Você também pode ter dois ou mais squads que no fim acabam lidando com a mesma funcionalidade ou experiência do usuário, então esses squads se coordenam no que eles chamaram de tribes.

Cada squad é composto por profissionais de diferentes capacidades, então além do Product Owner ou PO, você pode ter um designer, quatro programadores, dois devops, um tester e assim por diante. Dois ou mais testers de múltiplos Squads formam outra organização horizontal chamada Chapters, por exemplo Chapters de devs front-end ou chapters de QA.

Por fim, você pode ter grupos com interesses similares mas não necessariamente do mesmo squad e nem do mesmo chapter, e pra isso eles se organizam em Guilds. Em termos de estrutura é só isso. Basicamente você chama departamentos de chapters, unidades de negócio de squads e tribes, e grupo do bebedouro ou cafezinho de guilds e boom, temos o modelo do Spotify.

Mais importante do que a estrutura são os princípios e aqui a coisa fica mais interessante. Nenhum dos pontos que o Spotify listou no seu modelo são novidades ou estão errados, são todos os mesmos pontos que qualquer um que já tenha lido The Mythical Man Month, Extreme Programming, The Pragmatic Programmer, Continuous Delivery do Martin Fowler, e mesmo os originais de Scrum do Ken Schwabber, ou Feature Driven Development do Jeff de Luca e Pete Code já ouviram falar várias vezes.

Quando o Spotify fala de Release Trains, Feature toggles ou feature flags, é tudo conceito de continuous delivery. Pra chegar ao nível de continuous delivery você precisa ter tudo que o Extreme Programming já ensinou: incluindo continuous integration.

Como eu disse no começo, o modelo Spotify não tem nenhum problema em si. Ele é meramente uma descrição do estado que supostamente, supostamente, estava a organização do Spotify por volta de 2012 a 2014 que foi quando eles soltaram o post de blog com o paper descrevendo o modelo e quando o Henrik Kniberg começou a palestrar e evangelizar o modelo em eventos de agilidade.

Eu fico pasmo vendo gente agora em 2019 vendendo explicitamente a implementação do tal “modelo Spotify” quando temos pessoas como o Marcin Floryan, diretor de engenharia do Spotify explicitamente explicando em palestra que Não existe um modelo Spotify. Vou deixar linkado a palestra dele do ano passado, onde ele mesmo diz que o que estava no paper de 2012 sequer descrevia corretamente como as coisas eram em 2012 e certamente já é diferente de como estava em 2018. Por isso eu disse “supostamente” agora a pouco. Ele fez questão de dizer: sabe porque chamamos as estruturas de Tribes ou Chapters? Porque ninguém estava usando esses termos antes! A idéia era criar um vocabulário próprio pra diferenciar dos outros. Por isso mesmo se você começa a copiar o modelo do Spotify pelo vocabulário, você já perdeu o ponto.

E sendo justo, se você pesquisar direito, no Google mesmo vai achar diversas pessoas, inclusive no Brasil, corretamente explicando porque o modelo do Spotify não é algo que você deva sair copiando. Exemplo disso é a palestra de Thiago Soares e Raphael Molesim chamado “3 razões porque o modelo do Spotify não serve pra você”, que vou deixar linkado os slides nas descrições abaixo. As explicações variam em qualidade e escopo, mas em princípio eles estão corretos. Por isso me deixa pasmo ainda ver empresas contratando coaches pra implementar esse elusivo pseudo-modelo.

E onde funciona o modelo do Spotify? Bom, se você for uma plataforma de música com milhões de usuários, em Stockholm, com várias pessoas que vieram da universidade KTH, em 2012, talvez esse modelo se encaixe. Ou seja, se você for o Spotify, então o modelo Spotify talvez faça sentido, por um período de tempo. Parem de comprar balas de prata! Balas de prata não existem! Qualquer empresa que compre um modelo como o do Spotify pra alguém implementar é só preguiçoso e não quer de fato entender como organizações funcionam. Parem de comprar implementação de modelos, seja de Spotify, seja de Lean, seja de Ágil ou qualquer variante.

Agora vem a parte difícil da minha explicação e eu vou ser o primeiro a dizer que eu mesmo tenho muita dificuldade de explicar isso. Se implementar modelos não funciona, o que a gente deve fazer?

Primeiro de tudo vocês precisam entender o que são modelos. Modelos são nada mais, nada menos, do que a descrição em forma de texto de uma observação em algum ambiente específico durante um período curto e finito de tempo. Por exemplo, eu poderia definir o modelo “Nature”, natureza mesmo. Poderia falar que eu vejo como ecossistema nas savanas da África são eficientes e auto-sustentáveis, poderia dizer como os animais se organizam em Bandos ou, em inglês pra ficar mais marketável, vamos chamar de Herds. Então esqueçam Squads, vamos implementar Herds.

Posso dizer como a natureza foi sábia em fazer as leoas atacar os antilopes, zebras e gnus, então podemos implementar herds que se alimentam de outros herds, afinal é uma cadeia alimentar e isso faz sentido, o herd que ganha fica com o budget do herd que perdeu. O Herd Lead é o leão, claro. Mas outros herd leads podem clamar a posição e então eles podem se desafiar e quem matar o outro se torna o lead daquele herd. E assim eliminamos a necessidade de precisar fazer reuniões e stand ups pra discutir o assunto, basta um lead tomar a posição do outro. E como diz o nome da metodologia “Nature” é tudo naturalmente justificado e fácil de entender. Olha só que da hora, acabamos de inventar mais um modelo. Coaches, quero meus royalties se vocês implementarem!

Piadas à parte, agora vamos falar sério. O que está errado não é a configuração das estruturas de Squads ou Tribes do modelo descrito. O problema é que modelos são meras fotografias de um processo em constante mudança. Você não implementa modelos de gerenciamento de cima pra baixo e espera que tudo funcione. Por exemplo, eu sou uma instituição que por N motivos é gigante, uma instituição financeira, vamos dizer. Ao longo dos anos acumulamos 4000 funcionários. Só que a cada ano a entrega das coisas fica mais lenta e mais custosa. Enquanto isso essa nova onda de fintechs tá aí, atacando sem parar, sendo mais rápidos e mais eficientes. Precisamos evoluir!

E pra evoluir o que fazer? Oras, vamos ver os modelos que tem no mercado e reconfigurar todas as nossas equipes! Vamos desintegrar as unidades de negócios e departamentos que temos hoje, dividir todo mundo em equipes cross-funcionais, mudar fisicamente o lugar de todo mundo em Squads! Pronto! Agora vamos começar a entregar com velocidade de startup! Menos, bem menos … Em qualquer implementação desses tipos de modelos, você sempre vai ver alguns resultados muito acima da média com alguns resultados medíocres ou bem abaixo do esperado. Você esconde os resultados ruins, reporta os bons pra diretoria e pro conselho e a vida segue.

O problema é o seguinte: em qualquer empresa, se você implementar qualquer modelo dessa forma, você vai sim ver algum resultado, especialmente se sua empresa era uma porcaria pra começo de conversa. Qualquer coisa é melhor do que nada num ambiente estagnado, você adiciona energia, joga um pouco de caos num lugar onde a entropia já começou a desintegrar a eficiência, e naturalmente vão emergir nichos de resultados até que bons. Isso acontece em qualquer lugar. Porém isso é um efeito colateral, não o efeito principal. Se for só isso que você fez, muito em breve a mudança vai se tornar o novo status quo, o nível de energia vai voltar ao normal, e a entropia volta a aumentar começando a deteriorar o novo modelo também. É inevitável.

Agora vem uma parte que eu pessoalmente gosto mas que é tão difícil de explicar que você vai ser obrigado a meio que engolir minha cagação de regra e depois buscar os detalhes. Como eu disse, eu escrevi bastante sobre isso no meu blog, tem vários artigos com mais detalhes. Mas você vai notar que no paper e palestras do povo do Spotify, bem como em material original de Scrum ou no próprio Manifesto de Desenvolvimento Ágil de Software, um termo que aparece bastante é Auto-organização e em alguns lugares aparece o tempo Complex adaptive systems, e com mais frequência mas sempre interpretado da maneira errada aparece a palavra Autonomia. Esqueça todas as estruturas, squads, chapters, sprints, scrums, kanbans, six sigma, e qualquer outra coisa. Enquanto você não entender o que é auto-organização, nada mais interessa.

Complex adaptive systems ou sistemas adaptativos complexos é um termo que vai aparecer em lugares tão diferentes quanto biologia, física, matemática. Se eu for explicar de maneira muito, muito grosseira, vamos pensar no seguinte: o que estamos tentando fazer é criar uma organização o mais eficiente possível. O que são organizações? São formas de organizar pessoas em torno de algum objetivo em comum. Ou mais corretamente, são formas que as pessoas se organizam pra atingir algum objetivo. Complexo não quer dizer difícil ou que você precisa de um phd pra entender. Pense num sistema como um grupo de agentes, onde cada agente tem possibilidades de se comunicar com outros agentes. Como já expliquei no vídeo sobre The Mythical Man Month, as linhas de comunicação aumentam muito rápido, de forma não-linear, com a inclusão de poucos agentes. Quanto mais agentes, mais complexas se tornam as linhas de comunicação. É muito difícil prever o comportamento desse sistema só observando o comportamento de um agente individualmente. A interação dessas linhas de comunicação criam redes dinâmicas complexas. Complex adaptive systems é um sub-grupo de uma área maior chamada Non Linear Dynamical Systems. A palavra chave é não-linear. Ou seja, se dobrarmos a quantidade de agentes, a complexidade não dobra, ela pode ser exponencial e aumentar ao quadrado ou mais.

Quando eu tento aprender uma coisa, mesmo em software, eu não procuro só na área de software. Obviamente outras áreas provavelmente já apanharam no assunto muito antes de nós, então eu tento estudar fora e ver o que já foi estudado. É claro que existem formas de organização diferentes de empresas. Todos nós vivemos já em alguma organização fora das empresas. Nossa família é uma organização, com hierarquia baseada na senioridade dos membros, onde teoricamente você devia respeitar sua mãe e seu avô, por exemplo. As famílias vivem em bairros ou comunidades, onde elas interagem e convivem umas com as outras, uns ajudando os outros ou fofocando sobre os outros pelos cantos, como todos gostam de fazer. Essas comunidades formam cidades, que se aglutinam em estados, que são unidos num grupo maior chamado país. E por último os países se organizam em blocos econômicos pra realizar comércio entre si.

Mas muito, muito antes disso, centenas de milhões de anos atrás, tivemos os primeiros seres monocelulares. Esses seres não tinham cérebro nem nenhum tipo de cognição, não tinham ambições de dominar o planeta ou mesmo consciência de que eles estavam em um lugar chamado planeta. Com os objetivos mais simples e imediatos como conseguir comida e reproduzir, eles foram se organizando e se aglutinando. Milhões de anos se passam e eles foram organismos multicelulares. Algumas dessas combinações dão errado e eles não sobrevivem no ambiente, alguns dão certo e eles conseguem reproduzir e criar mais cópias com características similares. Alguns desses grupos se separam do original e vagam pra mais longe, eventualmente alguns saem do mar e encontram terra. E agora temos grupos que vivem no mar e grupos que vivem na terra. Se você nunca leu a fascinante história da evolução recomendo que leiam livros como The Selfish Gene de Richard Dawkins.

Enfim, todo mundo aprendeu em biologia como literalmente do nada, por mero acaso e coincidência, uma combinação aleatória de fatores permitiu o surgimento das primeiras proteínas no ambiente precário da Terra do passado e com o passar dos milênios esses organismos foram se auto-organizando e evoluindo. Tentativa e erro atrás de tentativa e erro. Cada nova tentativa que deu certo deixando descendentes. E ao longo de centenas de milhões de anos saímos dos organismos monocelulares até chegar ao Homo Sapiens moderno e seja lá qual for a próxima evolução da nossa espécie. E antes que alguém comente, não, isso não é teoria que ainda não se tem certeza, já é um fato e uma lei. Nenhum ser divino fez um plano ultra detalhado e um belo dia disse “que se faça o ser humano” e boom, tudo apareceu como é hoje. É exatamente o que eu estou falando que também não funciona com implementação de modelos, um plano master que já nasce pronto e os divinos CEOs e COOs mandam implementar e você ganha um Spotify no dia seguinte. Aproveitando, se você nunca leu sobre o que é o método científico propriamente dito, recomendo que leia o clássico The Demon-Haunted World, Science as a Candle in the Dark do lendário Carl Sagan.

Eu brinquei falando da metodologia Nature antes mas foi uma meia brincadeira, porque foi exatamente assim que as coisas aconteceram e continuam a acontecer. O ecossistema natural, que compreende não só os grandes animais mamíferos que conseguimos ver mas até os micróbios e bactérias, todas existem num ambiente em equilíbrio dinâmico. Aliás, esse é outro conceito que vocês precisam entender: quando falamos em equilíbrio a maioria pensa em equilíbrio estático, que significa chegar num certo nível e não mexer em mais nada. Equilíbrio dinâmico é assim: nesta década nasceram pessoas demais, na década passada morreram pessoas demais, beleza, na média deu 0, estamos em equilíbrio, dinâmico. Nunca considere equilíbrio como sendo algo fixo ou estático mas sim sistemas que trocam energia entre si e na média estão em equilíbrio.

Essa história toda é pra encaixar alguns termos. Na sopa primordial do começo dos tempos na Terra tínhamos praticamente puro caos. Caos é basicamente desordem. Milhares de tipos diferentes de componentes químicos expostos numa terra em formação, ar irrespirável, trovões e raios. A parte interessante do Caos é que ao contrário do senso comum, a ordem tende a emergir do Caos. Da ordem surge entropia e entropia pode levar de volta ao caos. Por pura sorte, se você der tempo suficiente, milhões de anos, numa sopa de caos, é probabilisticamente inevitável que uma combinação de materiais químicos e energia vai acabar resultando em elementos como aminoácidos. E isso é o processo de evolução: seleção natural em mutações que surgem aleatoriamente. As mutações são aleatórias, a seleção natural não é, ela é cumulativa, por isso a evolução tende, no geral, a andar pra frente.

Agora entenda uma limitação da biologia: carregar a melhor combinação de genes acontece via reprodução. Dois animais precisam reproduzir pra gerar um filhote que carrega a combinação dos seus genes e talvez uma ou outra mutação acidental. É uma combinação de 2 pra 1 durante semanas ou meses. Idéias, ou o que Richard Dawkins cunhou como memes, tem a vantagem de ser N pra M em vez de só 2 pra 1, e não precisa de mais que alguns segundos pra reprodução de um novo meme. Fora que memes não precisam andar pra frente, ele pode fazer o equivalente a incesto e reproduzir com os pais, ou com os irmãos. Idéias podem ser misturadas pra qualquer direção. E a propagação de memes é muito mais rápida que a propagação de genes, por isso podemos fazer tentativas e erro muito mais rápido, criar mutações de memes e fazer seleção artificial dos melhores memes. O que no mundo biológico levaria centenas ou milhares de anos, no mundo da memética, das idéias, podemos executar em minutos ou horas. Organizações ou modelos de organização são idéias, memes, e eles podem e devem estar evoluindo constantemente. Nenhuma idéia é sagrada demais que não possa ser contestada e substituída.

Teoria do Caos é uma vertente da física, a maioria das pessoas vai reconhecer por causa do exemplo clichê da borboleta que bate as asas no Brasil causando um furacão no Texas. Ou os filmes do Efeito Borboleta como Ashton Kutcher, a idéia de que um pequeno evento causa efeitos em cascata imprevisíveis. E é isso mesmo: sistemas dinâmicos, que são altamente sensitivos a condições iniciais, embora aparentemente aleatórios, começam a demonstrar padrões emergentes, constante feedback loops - outro termo usado na palestra do Spotify - repetição, auto-similaridade, fractais e por fim, auto-organização.

Nós estamos acostumados a criar correlações entre causa e efeito de forma linear. É a descendência do pensamento determinista de René Descartes, melhor representado pelas equações da física de Isaac Newton. A física de Newton descreve um mundo determinístico, se eu souber a posição inicial, a velocidade inicial e a aceleração de alguma coisa, eu consigo saber onde no futuro esse alguma coisa vai estar com precisão. Consigo saber onde certo planeta vai estar, com precisão, daqui 50 anos. Se você parar pra pensar nisso, seu pensamento foi naturalmente treinado pra pensar em determinismo, previsibilidade, e praticamente a acreditar em destino.

Porém, o mundo real não é tão determinístico assim, especialmente depois da Teoria da Relatividade e Física Quântica. Aliás, aqui tome muito cuidado: você tem certeza que está vendo um charlatão quando ele aplica conceitos de física quântica no mundo macroscópico. Entanglement só existe no mundo sub-atômico, então esqueça essas teorias new age de consciência coletiva. Trabalhos como esse (What the bleep to we know) ou esse (The Secret) ou esse (Deepak Chopra) são todos bullshit de pseudo-quânticos e pseudo-ciência.

Agora, o comportamento de animais num ecossistema, o comportamento de seres humanos em mercados, o comportamento de particulas sub-atômicas, o comportamento da luz ao redor de um buraco negro, tudo isso não é trivialmente determinístico. E agora temos diferentes escolas com modelos pra entender essas coisas, em particular Teoria do Caos.

Existem alguns autores que eu vou recomendar que vocês leiam se tiverem interesse: Chaos, the new Science do James Gleick. Se você não sabia, o personagem Iam Malcolm de Jurassic Park foi inspirado em Gleick. Um autor extremamente importante pra entender sistemas não lineares e emergência é Steven Strogatz, começando pelo NonLinear Dynamics and Chaos. Daí Sync: How Order Emerges from Chaos in the Universe. Strogatz foi mestre de outro autor importante pra entender como as idéias de sistemas não lineares afetam relacionamentos em grupos, que descrevemos como networks ou redes, Duncan Watts que escreveu sobre o famoso Six Degrees: The Science of a Connected Age. Se você já ouviu falar sobre os seis graus de separação e porque isso acontece, recomendo ler Watts e outro autor importante: Albert Lazlo Barabási com seu excelente livro Linked. Finalmente pros mais inclinados a matemática provavelmente um dos nomes mais importantes na área que é Paul Erdös.

Agora, como tooodo esse mambo jambo de ciências se encaixa na nossao discussão de modelos de organizações? Simples, porque pra todos os efeitos, especialmente quando você tem um número grande de pessoas, você pode tentar usar os efeitos de emergência e auto-organização. Em teoria do caos, pense em caos quando você tem desordem entre um número grande de agentes. Agentes podem ser qualquer coisa, um micróbio, um animal, um ser humano, ou até mesmo um ser inanimado, nem precisa estar vivo.

Steven Strogatz tem um vídeo interessante sobre emergência, do TED Talk de 2004, uma época onde TED Talks ainda valiam alguma coisa. Eu gostava muito de mostrar em palestras que eu fiz até 2009. Nós tendemos a achar que sistemas tendem a aumentar sua entropia e isso leva inevitavelmente à desordem, a entropia no universo tende sempre a aumentar e por isso não é tão óbvio de entender que ordem pode emergir desse caos. Mas sem entrar em muitos detalhes sobre segunda lei da termodinâmica, entenda que o universo como um todo pode aumentar a entropia, mas a entropia em sub-sistemas menores pode decair e sua ordem pode aumentar à medida que trocamos entropia de um sistema pelo outro. Recomendo que procure sobre o demônio de Maxwell e a entropia de Shannon, de Claude Shannon que escreveu sobre Teoria da Informação.

(starlings)

De qualquer maneira, entenda que no mundo real, coisas tendem a demonstrar comportamento de sincronização e ordem tende a emergir desses sistemas. O mambo jambo todo anterior é meio pra dizer que sim: sabemos que esse tipo de comportamento realmente acontece naturalmente. E como eu disse, você sequer precisa de seres vivos pra obter esse comportamento. Veja este exemplo de Strogatz.

(metronomes)

De tudo que já li a respeito, resumindo de forma bem simplória, temos organizações da era da Teoria X, onde assumimos que as pessoas que contratamos simplesmente nunca vão ter vontade de realizar nenhum trabalho, então criamos estruturas de microgerenciamento, pra garantir que cada engrenagem da máquina esteja funcionando como deveria. Seja numa empresa com 10 pessoas ou com 10 mil pessoas, colocamos todo mundo em pequenas caixas altamente reguladas e limitadas, com o mínimo possível de liberdade. É um sistema de baixa entropia, porém é um sistema com baixas chances de ordem emergente, pelo contrário é a que tende a entrar em decadência mais rápido e exige quantidades maiores de energia entrando nesse sistema para manter a baixa entropia. Por isso custa caro, precisamos de grandes hierarquias, enormes quantidades de regras e procedimentos, pra manter o sistema em ordem.

Na teoria Y as premissas são diferentes. A palestra do Spotify de Marcian cita leituras como o livro Drive de Daniel Pink. Por acaso outro autor que eu citei como se não houvesse amanhã lá por 2008 e que fala sobre motivação, não era mais pra ser nenhuma novidade hoje. O conceito é simples mas não deve ser confundido com o que se fazia nos anos 90 onde começaram movimentos motivacionais, o famoso vamos juntar todo mundo da empresa pra se conhecer numa chácara, e fazer todo mundo se importar uns com os outros, todo mundo abraçar árvore e mimimi. Esse conceito até eu já considero bem antiquado.

A hipótese de Daniel é que empresas, chefes, não tem como motivar as pessoas. É impossível. As pessoas motivam elas mesmas. Segundo Daniel, o que as pessoas procuram é Autonomia, Mastery que eu não sei como traduzir em português mas seria a vontade de ser melhor no que faz, e Propósito. E daí você vê de novo a palavra Autonomia que aparece no paper do Spotify e inúmeras outras metodologias.

Na teoria de emergência de Strogatz existe outro insight que eu considero importante. Vemos no vídeo aquele bando enorme de pássaros todos voando em sincronia, formando uma coreografia no ar, e conseguindo desviar de predadores e rapidamente avisar os pássaros que estão dezenas de metros mais à frente através da propagação de ondas, que é uma maneira de propagar informação de forma eficiente pra frente. Entao os pássaros vão desviando dos ataques e rapidamente retornam à formação próximo um dos outros. O bando inteiro, olhado de longe, parece um grande organismo.

É a propriedade de auto-similaridade e fractal do comportamento emergente de sistemas complexos adaptativos. O mesmo comportamento pode ser observado no nível microscópico como células ou no nível macroscópico como bando de pássaros ou peixes. E ao contrário da nossa tendência antropomórfica de imaginar que os pássaros de alguma forma se importam uns com os outros e por isso andam em bando, não, não existe essa correlação. No exemplo da simulação de computador, basta termos agentes completamente egoístas, que tendem a voar perto dos demais, desviar de outros agentes tentando voar por cima deles, e tentar retornar pra perto do bando quando puder.

Por que eles voam em bando? Por que aumenta as chances individuais de sobrevivência de cada indivíduo. O predador vai acabar pegando alguns, mas se você tentar voar sozinho separado do bando, você é o alvo fácil. Portanto pra ter comportamento emergente de grupo, trabalhando em sincronia, sequer existe a necessidade de alguma causa em comum. Basta que cada agente do grupo tenha liberdade de reagir em favor de seu próprio interesse individual e encontrar valor em preservar sua estadia no grupo pra atingir esses objetivos.

Como eu disse, eu poderia ficar semanas esmiuçando todas as vertentes de teoria do caos de maxwell, mandelbrot, lorenz, começar a chegar na física termodinâmica, explorar todas as derivações da segunda lei da termodinâmica, entropia, conservação e transferência de energia, teoria da informação, até esbarrar na teoria quântica com von neumann. E mesmo depois de tudo isso, a aplicação em teoria das organizações continua sendo mais especulativa do que uma aplicação consistente. A idéia não é dizer pra começar a fazer equações físicas pra descrever organizações, mas já que todo mundo fica roubando vocabulário da física e biologia eu resolvi mostrar de onde vem essas palavras que todo mundo usa sem saber do que se trata.

A maioria dos trabalhos de organizações, por alguma razão, tende a convergir pra essas vertentes de estudo. Mas, isso só vai ser útil se você é nerd como eu e gosta de tentar entender os mecanismos das coisas. Mas com tudo isso dito o que eu concluo é o seguinte. Comece pensando no indivíduo. Evite pensar em grupos ou comunidades. Todo mundo gosta de ser politicamente correto pseudo-socialista pró-causas sociais e bla bla bla. Tudo isso é bonito, é marketável, mas falando friamente em organizações, elas são irrelevantes.

O erro é tentar formar grupos de cima pra baixo, é mais fácil dar a direção e deixar os grupos se formarem sozinhos, emergirem a partir das vontades individuais de cada agente no sistema. Você tem duas maneiras de obter ordem nesse tipo de sistema. Um deles é de alto gasto de energia, que é via microgerenciamento. Você precisa tornar as coisas difíceis pra todo mundo, gastar muita energia pra conseguir fazer alguma coisa, e assim você obtém o maior grau de ordem, porém com o menor grau de mobilidade. Você estabelece um microestado e cada agente vai ficar preso no mesmo lugar, o sistema fica estático e tende a se linearizar.

Você pode ir pelo caminho do mínimo esforço, que seria literalmente apostar no caos e esperar a ordem emergir naturalmente. Porém a probabilidade de você chegar num microestado dentre milhões de combinações aleatórias diferentes em tempo hábil tende a zero. Ou seja, simples anarquia não vai te levar a um lugar algum, a menos que você seja muito sortudo. E nem vou dizer que isso não acontece.

Por fim, só existe uma outra solução: trabalhar no limite do caos, o Edge of Chaos em Teoria do Caos. E aqui vou ter que ser nerd de novo. Em termos simples pensa em transições de fase. Da água líquida pra cubo de gelo, é uma transição de fase de um estado de maior desordem pra um estado de menor desordem. Quando pesquisadores começaram a explorar esse limite entre as fases começamos a falar sobre adaptação.

Adaptação no limite do caos se refere à ideia de sistemas complexos adaptativos de intuitivamente evoluir a um regime próximo às fronteiras entre caos e ordem. Muitos começaram a discutir alguns anos atrás sobre aprendizado no limite do caos. E eu não lembro onde li que tentava demonstrar que uma organização de aprendizado é justamente uma organização que consegue andar na linha bamba próximo ao limite do caos. Na realidade, variando de forma controlada entre momentos de ordem e momentos de caos.

Se de novo isso parece um pouco familiar com o comportamento de um modelo circular ou iterativo, não é mera coincidência. Pode ser uma das razões de porque modelos circulares parecem funcionar tão bem, e justamente porque quando você trabalha sobre muita coisa desconhecida, ir e voltar do limite do caos aumenta sua probabilidade de resolver o problema e aprender alguma coisa.

A vantagem desse tipo de organização é que ela teoricamente gasta menos energia pra manter com o trade-off de causar erros e desperdícios. E ao contrário de uma anarquia, ela maximiza a probabilidade de se chegar num estado de entropia que forneça máxima eficiência mais rápido. A forma de fazer isso é abrir mão do micro-controle. Você nunca, mas nunca, deve confiar cegamente nas pessoas. Porém você não deve controlá-las tão de perto. Você precisa ter mecanismos de auto-preservação no ambiente. De preferência deve fazer parte do interesse de cada agente nesse sistema trabalhar somente do lado de outros bons agentes, assim como no bando de pássaros, não pelo bem da empresa ou qualquer outra causa, mas pelo seu próprio bem, porque não faz bem pra reputação dele estar num grupo de gente ruim, por exemplo.

Finalmente chegando na parte importante, o que o paper do Spotify faz corretamente é falar sobre alinhamento e autonomia. Alinhamento é outro termo vago, mas é basicamente dar direção ao barco. Se os C-level da empresa não sabem pra onde o barco deve ir, fodeu, pra todo mundo. Mas partindo do princípio que a direção está clara, você pode dar a autonomia aos funcionários pra atingir esses objetivos da forma como quiserem. Mas não de qualquer jeito, direção exige regras claras. Não se trata de criar organizações democráticas ou holocracias.

Na prática, nenhum funcionário jamais deve ter autonomia completa numa empresa, por exemplo via voto da maioria. Uma empresa não é e nunca deve ser uma democracia, que é basicamente a máfia da maioria. E a explicação é simples: qualquer pessoa que continua ganhando a mesma coisa todo mês, independente se fez tudo certo ou tudo errado, não pode ter autonomia completa. Somente os sócios majoritários podem ter essa autonomia porque se tudo der errado, quem vai sofrer os ônus do prejuízo vão ser eles. Os funcionários ganham se forem mandado embora, inclusive. Por isso você como funcionário, nunca deve se sentir mal de não poder decidir o gasto do orçamento da empresa, não é da sua responsabilidade. Se quiser que seja, assuma o prejuízo e torne-se sócio. Por esse simples fato, democracias puras não tem como funcionar no ambiente privado. Pra assuntos mais relevantes como por exemplo, quais ferramentas de trabalho vão usar, quem vai fazer parte de qual equipe, ou seja, tudo que tem a ver diretamente com a competência para os quais os funcionários foram contratados, então sim, eles podem e devem ter autonomia.

E só essa autonomia já é suficiente se você não contratou um bando de idiotas. Essa é outra coisa que pouco se fala: um modelo de auto-organização só acontece com bons agentes no sistema, agentes que não se sabotam e atiram no próprio pé sem perceber. Novamente, definir o que são boas pessoas é complicado. A maioria das pessoas de recursos humanos é incompetente em reconhecer boas pessoas, porque elas procuram ou por quantidade de capacitações e experiência ou personalidade das pessoas, se elas parecem boazinhas ou simpáticas. E nenhuma das duas coisas está correto, boas pessoas são aquelas que procuram Mastery.

Se você assistiu meus videos neste canal, já deve ter ficado muito claro que eu estou tentando falar com um tipo muito específico de profissional, e não com todos: os que programam ou estudam programação porque gostam de programar. Não importa se vai trabalhar num produto unicórnio ou num legado de repartição pública. Não importa se vai ganhar 4 dígitos ou 6 dígitos de salário por mês. Claro, todo mundo gosta de reconhecimento, mas não é esse o drive mas sim o mastery, e por causa disso também não gostam de trabalhar com pessoas medíocres do lado deles, e não gosta de coisas mal feitas dos outros e, se puder, vai ajudar os demais ao redor espalhando conhecimento, ou se isso não der certo, vai expurgar os maus elementos. Mastery. O problema é que somente pessoas que são assim conseguem enxergar outras pessoas que são assim. Como diria Jobs: pessoas A contratam outras pessoas A, pessoas B sempre contratam C. E recursos humanos, desculpem, nesse quesito vocês são C contratando D, deixe esse trabalho pros A.

Partindo da premissa que você contratou gente A, e partindo da premissa que você tem direção bem definida, naturalmente uma organização que se parece com Squads, Tribes e Chapters vai emergir. E aqui parece um pouco mágica, mas é basicamente isso: dê a pessoas A, um ambiente A, e naturalmente uma auto-organização A vai emergir. E dar um ambiente A não significa piscina de bolinhas ou xbox na sala comum. Ambiente A significa um ambiente estável e simples, onde salários não atrasam, onde reuniões sem sentido não aparecem aleatoriamente, onde a direção não muda toda hora obrigando o trabalho a recomeçar o tempo todo, onde a comunicação é liberada e não precisa de formalidades, nem rituais, nem reuniões especiais, onde feedbacks podem ser repassados o tempo todo pra cima ou pra baixo, novamente, sem formalidade de avaliações 360 ou qualquer bullshit assim, ou seja, onde adultos podem trabalhar como adultos sem babás tentando trocar as fraudas deles toda hora.

Outra coisa é quando falamos de transparência, que é outra coisa importante. Transparência não é terapia de casal pra ficar expondo tudo. Informação inútil demais também não ajuda ninguém. No caso de programadores, todo programador deveria ter acesso a todo o código da empresa. Todo devops precisa ter acesso a toda a infraestrutura da empresa. Todos os designers precisam ter acesso a todo o roadmap de produtos da empresa. Porém, coisas como abrir faturamento, lucro, dívidas, conversas com investidor e todas essas coisas, é bonitinho mas é inútil pra maioria das pessoas. De novo, uma empresa não é nem deve ser uma democracia. Novamente, se você é sócio da empresa sim, deveria ter que ler essas chatices. Se você não é, então não faz diferença. Por muitos anos eu pensei o contrário, mas de fato nunca achei nenhum bom argumento pra justificar. Empresas privadas Não são órgãos públicos ou ONGs.

Todo o resto que você já viu sobre esse modelo está melhor descrito em todos os materiais que eu já repeti mil vezes como extreme programming. Por exemplo, continuous delivery. O código no master do repositório deveria estar sempre pronto pra deploy em produção. Pra isso nenhum desenvolvedor deveria subir código incompleto ou que crasheia o sistema. Pra isso todo desenvolvedor deveria desenvolver num branch, ou pull request no caso do GitHub, e só quando o código estiver completo, com testes automatizados, que passam pelo sistema de integração contínua, só aí ele deveria ser mergeado na master e somente quando pelo menos um colega de equipe revisar. É uma coisa meio básica, bem arroz com feijão mesmo, mas incrivelmente poucas empresas fazem isso.

Outra coisa é releases frequentes, porque se demorar demais pra lançar em produção começa a acumular muito código que nunca foi testado de verdade por gente de verdade, e quanto mais demorar maiores as chances desse deploy falhar. E quanto mais aumenta essas chances mais todo mundo prefere protelar pra fazer deploy e vira um ciclo vicioso. É melhor fazer deploys constantes, com bastante frequência. Assim, mesmo se tiver um bug, é mais fácil de reverter e consertar do que lançar uma tonelada de código novo de uma só vez e depois virar um pesadelo pra saber o que exatamente quebrou aonde. E é isso que nas palestras do Spotify o CEO fala que eles falham rápido toda hora. Fail Fast é um conceito que ficou famoso no Lean Startup, novamente nenhuma novidade.

Mas claro, ser assim o tempo todo é uma utopia, e nem no Spotify é assim. Nessa entrevista de 2018 com Joakim Sundén, que é “coach” de equipes e liderança no Spotify ele mesmo diz: Não me entenda mal: amo o Spotify, a nossa cultura e forma de trabalhar, mas está longe de ser um “Nirvana Ágil”. Aliás, uma coisa que sempre surpreende aqueles que tem uma vasta experiência com o Ágil é que as práticas de engenharia como TDD, programação em par, código limpo e design simples não são tão comuns por aqui. Squads que usam estas práticas geralmente são exceção, e não a regra. Na verdade, muitos squads não estão habituados nem com as práticas ágeis em geral. Talvez até fazem reuniões de planejamento, mas não necessariamente revisam o plano ou refletem sobre como melhorá-lo. As equipes que usam kanban raramente usam a limitação de trabalho em progresso, ou se usam, frequentemente a ignoram. Não estou dizendo que esta seja a realidade de todos as equipes, mesmo porque tendo na organização cerca de 150 equipes, não teria como saber detalhes de cada um. Estas observações vêm do trabalho feito com dezenas de equipes ao longo de seis anos, além de conversas com muitos outros coaches e Spotifiers.

E aqui vem uma coisa que eu digo faz anos: nenhuma metodologia vai salvar pessoas ruins. Se você já sabe que a maioria dos seus funcionários não é boa, não tem essa vibe de mastery e está lá mais porque não tem outro lugar pra ir e ninguém contrataria eles, então esqueça metodologias. Scrum, Lean, Kanban, Spotify, nenhum modelo vai jamais salvar profissionais ruins ou mal caráters. Aliás, pouca experiência técnica é algo que sempre podemos evoluir, mas mal caratismo não tem cura. Eu digo que se nem a coitada da mãe dele conseguiu dobrar o mal caratismo do filho por toda a vida dele, não sou em que em um mês vou conseguir. Portanto quando alguém se mostra mal caráter corte imediatamente, não tem salvação. Nunca, jamais, mantenha alguém mal caráter na equipe mesmo que ele pareça ser o melhor técnico. A pior coisa que uma empresa novata pode fazer é acumular escória assim.

Pra concluir. Esqueça metodologias ágeis, lean, kanban, spotify ou qualquer outra coisa. Na verdade, esqueça quem vende essas coisas. Se quem vende essas coisas não começou com a questão de tirar do cargo de chefia quem emperra decisões ou demitir os mal caraters que ainda estão no cabideiro da empresa, já começou errado. A primeira coisa que qualquer empresa que quer implementar esse tipo de processo precisa fazer é cortar a gordura fora e começar com o essencial: evitar desperdícios. O diretor de marketing que está lá só porque é cunhado do CEO, e todo mundo sabe que só fala besteira e não entrega nada? Precisa ir embora. O tal líder técnico que diz que manja bastante mas os programadores juniors que varam noite consertando os bugs que ele comitou direto na master, e que só aparece pra trabalhar 2 horas da tarde? Esse precisa ir embora. O gerente de projetos que sempre promete A pro diretor, manda a equipe fazer B, e depois muda de idéia pra C no meio do projeto mas mantém o prazo igual porque não quer contar pro diretor que fez merda? Esse precisa ir embora.

Eu não acredito em nenhuma tentativa de se implementar um novo modelo de gestão que não inicia com uma limpeza de RH. De departamentos inteiros se possível. Depois disso é ver toda a burocracia que se tem hoje em dia e jogar tudo fora se possível. Eu já vi casos imbecis de empresa com sprints de Scrum de 3 semanas ou mais! 3 semanas é ridículo. Uma semana é o ideal, na minha opinião. E quando você vai perguntar porque é tão longo eles falam que as reuniões de grooming, planning, review e retrospectiva acabam levando tantos dias que não cabe em 1 semana. Ou seja, estão desperdiçando o tempo da equipe toda em reunião 1 semana inteira por mês.

E isso tudo porque alguém leu que se deveria ouvir a opinião de todos os membros da equipe toda hora, que é uma desculpa pro PO e pro líder técnico não fazerem os trabalhos deles que é definir exatamente o que se precisa fazer e daí só discutir com a equipe toda quem vai fazer o que e como, o que deveria ser super rápido. É de novo a falta de alinhamento. Ninguém sabe exatamente que direção precisa ir, e na última hora durante o planning tem que ficar especulando cenários, começar a fazer pra alguém decidir diferente no meio e aí ter que parar tudo e recomeçar. Daí claro, 3 semanas de sprint, 6 semanas de sprint, não importa, você nunca vai ser ágil. Porque dessa forma toda vez você começa um sprint de 3 semanas, as coisas dão errado e só nas 3 semanas seguinte dá pra corrigir e potencialmente você atrasa as coisas 1 mês e meio toda vez, e isso vai acumulando. Daí seus deploys são atrelados ao aceite total no final de 2 ou 3 sprints, e você só tem coisa indo pra produção a cada 2 ou 3 meses. E, lógico, bugs vão se acumulando, todo deploy é uma dor de cabeça, daí na sequência todo mundo vara noite resolvendo bug e o próximo sprint já começa com burn out.

Isso porque a prioridade tá errada: você precisa criar restrições pro processo e fazer caber. O sprint é 1 semana. Mas daí não cabe as reuniões, oras, elimine as reuniões. Mas metade do backlog tá mal definido e não dá pra começar, oras corte fora do backlog tudo que tá mal definido. Ah, mas foi o diretor que pediu, oras, devolva pro diretor definir o que quer direito e escolher uma das opções, porque todas não dá pra fazer. É assim que se começa a tomar decisões. Se isso não é possível, então não adianta escolher metodologias, a fundação da empresa tá errada. Começa se livrando desse diretor e metade dos problemas vão embora com ele. Squads não vão ajudar.

É como o caso de microserviços que eu gosto de comentar como sintoma de más empresas. A Lei de Conway é outra lei das antigas que até hoje todo mundo cai nela. Melvin Conway postulou que qualquer organização que desenvolve sistemas vai inevitavelmente produzir um design que reflete a estrutura de comunicação da organização. Microserviços ficaram famosos porque ela aparentemente resolve um problema em organizações: a inabilidade de duas equipes de colaborarem entre si. Qual a melhor solução? Cada um cria seu próprio microserviço e eles não precisam colaborar agora. Uma organização com 10 equipes cria 10 ou mais microserviços. Claro, existem usos legítimos de microserviços, mas é muito mais comum ver eles sendo usados como tapa buraco em problemas de organização.

Toda implementação de bala de prata é alguém incompetente querendo esconder sua incapacidade atrás da muleta de uma metodologia. Daí quando tudo der errado você sempre pode dizer, ah mas a culpa não foi minha, nós seguimos todos os passos da metodologia, então outra pessoa deve ter implementado um passo errado. E pronto, todo mundo vai ficar discutindo ad eternum sobre especificidades de uma metodologia genérica. E ninguém vai ter o culhão de discutir o elefante no meio da sala: foda-se a metodologia. Qual é o real problema? É a quantidade de bugs em todo release? É a demora em se fazer deploys? É a quantidade de mudanças frequentes no backlog a cada sprint? Defina o problema objetivamente e ataque um de cada vez. Se fizer dessa forma, um modelo de organização naturalmente vai emergir.

Mas comece eliminando desperdícios. E contratar coaches é um desperdício. Se você como diretor ou C-level não fez merda demais, você já deveria ter tech leads ou similares na empresa que sabem o que precisa ser feito, mas não podem porque você enterrou todos eles em burocracia ou em backlogs impossíveis e estão todos varando noite correndo atrás do próprio rabo. A coisa mais óbvia? Desatole eles, assuma o prejuízo de fazer isso do que jogar dinheiro fora numa consultoria de agilidade que, se eles fizessem o trabalho deles direito, deveria te dizer pra fazer exatamente isso: desatole seus líderes e deixe eles fazerem o que eles já sabem que precisa ser feito.

Por fim, o próprio Spotify vem repetindo ao longo dos anos que nem eles seguem o modelo que eles mencionaram em 2012. E nem deveriam. Porque qualquer organização que esteja seriamente pensando à frente em sua qualidade e eficiência, está mudando as coisas o tempo todo. Um modelo, assim como a tal “Cultura”, que tooooodo mundo adora ficar falando em palestra ou post de blog é nada mais do que uma fotografia num determinado momento. Toda cultura muda, cultura é simplesmente o conjunto de costumes e valores de um grupo num determinado local e num determinado momento no tempo. Em 2019 a maioria das pessoas que trabalhava em 2012 talvez nem esteja mais lá, a cultura com 100 pessoas e com 2000 pessoas é diferente. Não se pode nunca achar que cultura é algo que vai ser preservado ou mesmo que deve ser preservado. Pelo contrário, é algo que deve estar em constante mudança, por isso eu acho meio idiota quando uma pessoa quer entrar numa empresa pela “cultura” que ela leu num post de blog.

Em Lean se popularizou um conceito que é melhoria contínua. É a única coisa importante depois de evitar desperdícios, Kaizen. Incentivar as pessoas a errarem rápido, aprender com os erros, ensinar os outros, e não errar a mesma coisa na próxima vez. É meio óbvio, mas parece que tudo que é óbvio precisa ser explicitamente dito numa organização. E esquece Kanban, foda-se OKR e rhythms e dibbs, que porra é dibbs? Fuck. Se quiser saber sobre Lean de verdade só tem uma fonte pra ler: Taiichi Ohno e seus discípulos como Shigeo Shingo. Na verdade, quem vende Kanban hoje já até avisa que o Kanban de software não tem mais nenhum paralelo com o Kanban da Toyota. É mais uma apropriação de vocabulários pra vender os mesmos produtos de sempre.

Como eu já disse no vídeo de Ágil: esqueça metodologias. O objetivo é entregar valor, software que funciona. O objetivo é maximizar os lucros. O objetivo é que todos trabalhem num ambiente minimamente funcional, com salários pagos em dia, com poucas interrupções, onde feedback não precise de burocracias e comunicação seja livre e aberta, onde cada profissional possa executar seu trabalho no máximo das suas capacidades, em vez de ter que se conformar com um padrão de ferramentas ou plataformas ou processos. Onde exista incentivo para que as pessoas vejam que existem ganhos individuais quando ele contribui com as outras pessoas, seja direta ou indiretamente. Use a ambição do indivíduo em prol da organização em vez de tentar convencer as pessoas a participar de um grupo só porque é politicamente correto colaborar com os outros. E, principalmente: demita esse maldito CMO ou C-FUCK-O ou VP de sei lá o que, que só atrapalha, só toma decisões erradas e só fica inventando de implementar o próximo Squad da moda.

Não menos importante, na dúvida sempre se lembre: um scrum master, um agile coach, um arquiteto, um chapter lead, ou qualquer coisa assim que vêm cagar regra em programação e nunca ele mesmo programa e não consegue se expressar em código pra explicar o que quer, não tem lugar numa equipe de desenvolvimento de software. E pra finalizar, tudo que falamos até agora não é novidade pra quem leu o Manifesto de Desenvolvimento de Software Ágil de 2001. Ele tem os famosos 4 valores, mas também tem 12 princípios, lembra? Vamos alguns deles e você vai ver como tudo que aparece no modelo Spotify e outras metodologias vem de lá também.

Entregar software funcionando com freqüencia, na escala de semanas até meses, com preferência aos períodos mais curtos. Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diariamente, durante todo o curso do projeto. - olha squads aqui Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho. - voltando ao ponto de autonomia e alinhamento O Método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa cara a cara. - ou seja, sem rituais, simplesmente fale Software funcional é a medida primária de progresso. - esse é o objetivo: software que funciona e não estruturas de controle Contínua atenção à excelência técnica e bom design, aumenta a agilidade. - que é o pré-requisito a profissionais A Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito. - e o que eu sempre repito que o melhor software é zero software. Se não precisa ser feito, não faça. As melhores arquiteturas, requisitos e designs emergem de times auto-organizáveis. - e o manifesto também trás auto-organização Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo. - e aqui é o manifesto remetendo ao princípio de melhoria contínua de Lean

Eu não vi nada de novo surgindo no mundo de teorias de gerenciamento faz mais de 10 anos já. É tudo a mesma coisa que a gente já sabia até o fim do século XX. Em vez de olhar pra esse tanto de bullshit quero que pensem outra coisa. Vejam software livre, código aberto. Você que é uma empresa de desenvolvimento de software, tentando implementar squads e scrums, nunca se sentiu meio envergonhado que um grupo aleatório de voluntários, que sequer ganham salário, consegue se juntar num projeto e entregar código de melhor qualidade do que seus squads com 10 coaches? Quando você se vê conseguindo entregar um framework como React? Quando você se vê entregando um banco de dados como Redis? Quando você se vê entregando um sistema como Git? Você está criando uma tonelada de estruturas inúteis de controle e sequer consegue entregar um formulário de login sem erro. Não tá muito claro que as prioridades estão erradas?

O mundo de software livre funciona porque ele tem só o mínimo necessário pra funcionar. O voluntário consegue baixar o código, rodar os testes e avaliar como prosseguir. Os bugs e roadmap estão expostos de forma transparente no issue tracker e wiki do projeto. Os membros estão disponíveis em mailing list ou chats. Existe um indivíduo ou grupo que é o ditador benevolente do projeto que é quem garante a integridade conceitual - como Fred Brooks já disse que era necessário no The Mythical Man Month. Discussões longas que se arrastam são cortadas por alguém que toma uma decisão. Boa ou ruim, ela é tomada. A principal métrica do projeto é sua utilidade aos usuários, caso contrário o projeto simplesmente morre. Como deveria.

E com isso eu vou fechar o assunto sobre agilidade por algum tempo. Acho que já falei tudo que eu queria falar. Prometo não voltar nesse assunto tão cedo porque quero falar de outras coisas mais interessantes: software. Então se ficaram com dúvidas, nao deixe de mandar nos comentários abaixo, se curtiram o video mandem um joinha, assinem o canal e cliquem no sininho pra não perder os próximos videos. Compartilhem o video com seus amigos pra ajudar o canal. A gente se vê semana que vem, até mais!

]]>gestaoagileengenharia-de-softwareakitando[Akitando] #23 - The MM-M: O Melhor Livro de Software?https://akitaonrails.github.io/2018/11/01/akitando-23-the-mm-m-o-melhor-livro-de-software/https://akitaonrails.github.io/2018/11/01/akitando-23-the-mm-m-o-melhor-livro-de-software/Thu, 01 Nov 2018 17:00:00 -0300<p>Disclaimer: esta série de posts são transcripts diretos dos scripts usados em cada video do canal <a href="https://www.youtube.com/channel/UCib793mnUOhWymCh2VJKplQ"target="_blank" rel="noopener">Akitando</a>. O texto tem erros de português mas é porque estou apenas publicando exatamente como foi usado pra gravar o video, perdoem os errinhos.</p> <div class="embed-container"> <iframe src="https://www.youtube.com/embed/wcGGklDfHM4" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen> </iframe> </div> <h3>Descrição no YouTube<span class="hx:absolute hx:-mt-20" id="descrição-no-youtube"></span> <a href="#descri%c3%a7%c3%a3o-no-youtube" class="subheading-anchor" aria-label="Permalink for this section"></a></h3><p>Vocês vão encontrar dezenas de listas de &ldquo;Top 10 Livros sobre desenvolvimento de Software&rdquo;. Mas como realmente confiar numa lista? Vou explicar um dos critérios que eu uso para escolher.</p>Disclaimer: esta série de posts são transcripts diretos dos scripts usados em cada video do canal Akitando. O texto tem erros de português mas é porque estou apenas publicando exatamente como foi usado pra gravar o video, perdoem os errinhos.

Descrição no YouTube

Vocês vão encontrar dezenas de listas de “Top 10 Livros sobre desenvolvimento de Software”. Mas como realmente confiar numa lista? Vou explicar um dos critérios que eu uso para escolher.

E aproveitando o gancho do vídeo anterior, de porque blockchains não são balas de prata pra tudo, vamos ver a origem da frase Balas de Prata.

O livro The MM-M é possivelmente um dos livros que eu consideraria obrigatório a qualquer um que leve a sério a área de Engenharia de Software, particularmente como gerir um projeto de software.

Mas um livro publicado em 1975 não está atrasado? Agile não é o jeito moderno?

Vamos quebrar esses e muitos outros mitos que muitos de vocês devem ter até hoje sobre gerenciamento ágil de software.

Quando gravei eu disse que não sabia de onde tinha ouvido falar desse livro pela primeira vez, mas fui vascular meus e-mails mais velhos e sem querer achei exatamente. Foi no dia 27 de julho de 2002 (então eu estava certo, 15 anos atrás), e foi no Slashdot.org, exatamente nesta página: https://web.archive.org/web/20040412002157/http://slashdot.org/books/980805/1148235.shtml

Fica aqui pra posteridade :-)

Links:

Script

Olá pessoal, Fabio Akita

Alguns vídeos atrás, alguém pediu nos comentários para recomendar livros na área de tecnologia. Vou dizer logo de cara: qualquer lista de top 10 livros de tecnologia que não mencione Fred Brook’s e seu magnum opus The Mythical Man-month perto do topo, não é uma lista confiável. … by Akita

Na verdade, aqui vai uma dica importante: os livros publicados mais recentemente, por autores “celebridadezinhas” raramente, muito raramente, são úteis. Eu não compro, eu recomendo não comprar se o objetivo for criar fundações sólidas. Deveria ser meio óbvio, mas pra um livro ser considerado realmente bom, ele PRECISA passar pelo teste do TEMPO. Durou 10 anos e ainda é válido? Começo a considerar. Durou 30, 50 anos? Agora eu começo a considerar se entra numa lista top 10. Colocar livros de menos de 10 anos num top 10 normalmente expõe a fraqueza da lista.

Muitos autores modernos desprezam os livros antigos de engenharia de software porque tem a noção errada que os atuais livros de fake-agile ou os to-do list glorificados do kanban são a única doutrina necessária e os antigos programadores de Cobol faziam tudo errado. Se você pensa assim ou tem algum resquício disso no fundo da sua cabeça, vou dizer de novo logo de cara: você é moleque! Continue pensando assim e prepare-se para uma longa carreira medíocre.

(…)

Se você já está na área faz algum tempo, o livro de Fred Brooks The Mythical Man-Month vai ser surpreendentemente atual. Quando eu li esse livro uns 15 anos atrás, eu pensei, cara se eu tivesse lido esse livro uns 10 anos antes, no começo da minha carreira, talvez eu tivesse evitado muitos problemas ou pelo menos teria tido insights pra soluções diferentes. Brooks descreveu em detalhes TODOS os problemas que eu já passei em projetos e possíveis soluções. Ele foi publicado em 1975! seguindo as experiências adquiridas em diversos projetos como o sistema operacional OS/360 da IBM.

Ou seja, quase meio século depois, nossa área de engenharia de software continua errando nos MESMOS lugares que já se errava desde os anos 60!! George Santayana já dizia: aqueles que não se lembram do passado estão condenados a repetí-la. Eu tento não ser idiota, por isso passei os últimos anos indo atrás do passado, e é por isso que eu lido com projetos e equipes de uma maneira um pouco diferente e também por isso tenho zero interesse em discussões atuais de “agile”. Vou falar disso em outro vídeo.

Na verdade todos os grandes clichês que você já ouviu falar foram provavelmente tirados desse livro de Brooks. Por exemplo o título do livro é o capítulo 2 e também a chamada Lei de Brooks: adicionar mais gente num projeto atrasado só vai deixá-lo mais atrasado. Man-month ou pessoa-mês é a definição da quantidade de trabalho que uma pessoa faz em um mês. É a falácia de achar que pessoas e tempo são recursos iguais: ou seja, que se você tem 1 pessoa num projeto de 3 meses ou 3 pessoas num projeto de 1 mês, é tudo igual. O maior problema em projetos é a coordenação dessas pessoas.

Coordenação entre pessoas, combinação de caminhos diferentes entre múltiplos nós. Qual era mesmo a fórmula que você aprendeu na faculdade? AH sim ! No pior caso, você tem n x (n-1) / 2 caminhos de comunicação. Lembrou?

Ou seja, 10 x 9 / 2 ou 45 linhas de comunicação entre 10 pessoas. Vamos adicionar 5 pessoas a mais, achando que vai melhorar. Agora vc tem 15 x 14 / 2 = 105 linhas de comunicação. E se for um time de 20 pessoas? 190 linhas de comunicação. Está vendo como o problema escala rapidamente?

Toda vez que você adiciona pessoas novas no projeto, segundo Brooks e segundo minha experiência como evidência, você perturba o projeto de 3 maneiras importantes: você agora precisa reparticionar as tarefas com as pessoas novas. Essas pessoas novas precisam ser treinadas no que já foi feito até agora, é o tempo de phase-in ou on-boarding. E finalmente, temos as novas linhas de comunicação pra piorar.

Como fazemos num projeto grande então? Brooks descreve a solução: você divide o sistema em sub-sistemas, cada qual com uma Equipe Cirúrgica - que ele define em detalhes no capítulo 3 -, uma equipe pequena - ele até menciona o conceito de Feature Teams. Uma equipe multidisciplinar com um líder claro. Já se sabe faz décadas, empiricamente, que uma equipe jamais deveria ter mais que 10 pessoas. Tem uma parte do capítulo que eu gosto que ele diz: “se um projeto de 200 pessoas tem 25 gerentes que são os programadores mais competentes e experientes, demita a tropa de 175 e coloque os gerentes de volta pra programar”. MAS isso faria o projeto levar 25 anos pra acabar. Portanto, melhor dividir as 200 pessoas em 20 equipes cirúrgicas de 10, cada um com um sub-sistema.

No capítulo 7 ele inicia descrevendo a Torre de Babel. Segundo o livro de Genesis a torre de Babel foi a segunda obra de engenharia da humanidade, a primeira tendo sido a Arca de Noé. Mas Babel foi o primeiro fiasco de engenharia. Vamos analisar esse conto bíblico pela ótica da engenharia: Eles tinham:

  1. uma missão clara? sim.
  2. pessoas suficiente, sim
  3. materiais? sim
  4. tempo suficiente? sim
  5. tecnologia adequada? Sim

Se eles tinham tudo isso, porque o projeto falhou? Em 2 aspectos: comunicação e, por consequência, organização. A conclusão? como pequenas equipes devem se comunicar uns com os outros? DE TODAS AS MANEIRAS POSSÍVEIS. Pega o maldito telefone e liga. Manda pombo correio, sinal de fumaça, mas se comunique! Falta de comunicação, já é sabido, desde a Genesis se você acredita na Bíblia, ou desde os anos 60 se você acredita em Brooks, é a principal causa de fiasco de projetos. Por que você acha que alguns dos softwares mais famosos hoje em dia são todos de coordenação? Jira, Trello, Slack, Basecamp, Github, etc.

Falando em Github. Na republicação de 1995 ele reflete sobre o capítulo da Torre de Babel. Citando: “No projeto do OS/360 nós decidimos que TODOS os programadores deveriam ver TODO o material. Harlan Mills argumentou de maneira persuasiva que programação deveria ser um processo público, e que expor todo o trabalho pra todo mundo ajuda o controle de qualidade, tanto por peer-pressure de fazer as coisas direito e por cada um poder de fato ajudar a encontrar falhas e bugs”. OS/360, o projeto de 1964. Você acha que a noção de “quanto mais olhos no código melhor” vem de open source? Eu diria que a noção de open source vem dessa visão dos anos 60!

No capítulo 4, ele fala de Aristrocracia, Democracia e Design de Sistemas, onde ele postula provavelmente algo ainda mais importante do que o título do livro: Integridade Conceitual. Citando Brooks: “Eu vou defender que integridade conceitual é a coisa MAIS importante a se considerar em design de sistemas. É melhor um sistema omitir certas features e melhorias, mas refletir apenas Um conjunto de idéias de design, do que ter um sistema que contém muitas idéias boas mas independentes e descoordenadas”.

Uma equipe ou várias equipes, não importa, precisa de líderes cuja principal função é manter a Integridade Conceitual. Projetos de software não são e nunca devem ser democracias onde toda boa idéia de alguém entra no sistema. Alguém precisa ser responsável pela integridade do PRODUTO, como ele diz no título do capítulo, uma aristocracia mesmo, um ditador benevolente. Ou você já viu um projeto open source sem um Core Team que decide o que mergeia ou o que não mergeia? Deixe entrar tudo e você ganha uma Torre de Babel.

Nos anos 90 nós erramos nesse conceito e elevamos a idéia do famoso “arquiteto de sistemas” alto demais sem colocar esta missão de forma clara: integridade conceitual. Mas foi de novo um erro de não ler o livro porque Brooks deixa muito claro: o propósito de programar um sistema é deixar o computador mais fácil de usar. Uma arquitetura monumental feita por um arquiteto não serve pra nada se serviu ao sistema mas não ao Uso desse sistema. Outra coisa que eu sempre digo mas que Brooks disse primeiro: um arquiteto que não sabe programar não serve pra nada, citando Brooks: “o arquiteto deve estar sempre preparado para mostrar uma implementação pra toda feature que descreve, embora ele não deva ditar A implementação”. Mudamos um pouco o foco disso e dividimos o arquiteto entre líder técnico e outro papel para manter a parte da integridade conceitual: Hoje em dia você tem um conceito semelhante: chama-se PRODUCT OWNER.

E já que falamos num termo de Agile, vamos voltar a outra falácia: que só no século XXI aprendemos que waterfall é ruim e por isso substituímos por Agile. Isso é uma das noções mais erradas de todos os tempos. Eu digo isso por experiência porque isso assume que programadores dos anos 90 como eu eram todos burros. Bom, alguns eram. Mas pense assim: a gente entregava software no século XX.

Vamos ao capítulo 11: Planeje jogar um fora. Citando Brooks: “na maioria dos projetos, o primeiro sistema é quase inusável. Pode ser lento demais, grande demais, complicado demais, ou todos os 3. Não há outra alternativa a não ser começar de novo, melhor, e construir uma versão redesenhada em que esses problemas são resolvidos. Isso pode ser feito de uma vez ou pedaço por pedaço.” Tudo que você discute hoje sobre reescrever ou refatorar, é uma discussão que vem sendo feita faz décadas, nada de novo aqui. Nesse capítulo ele define que a única constante é mudança e a primeira coisa a se fazer é aceitar o fato que mudanças são fatos da vida, do que uma exceção. Prepare o gerenciamento do projeto para aceitar mudanças. Parece um tema moderno de Agile? Essa frase também é de 1975.

Ele fala que eventualmente você vai, de uma vez ou em partes, acabar reescrevendo o primeiro sistema. Mas no capítulo 5 ele avisa dos perigos do Efeito do Segundo Sistema. Citando: “A tendência geral é fazer um design grande demais no segundo sistema, usando todas as idéias que foram cautelosamente deixadas de lado no primeiro.” Ele avisa que o segundo é o mais perigoso sistema que uma pessoa vai desenhar. Exemplo clássico? Lembram do Windows Vista? Ou no nosso mundo mais recente: todo novo framework de Javascript?

Ele define e descreve em detalhes essas etapas. Incluindo a quantidade de bugs que aparecem no sistema por conta dessas mudanças e como lidar com elas. Ele não chama dessa forma mas ele advoga testes, fixtures, testes de regressão. Deixa eu citar um trecho desse capítulo de novo: “O problema fundamental com manutenção é que consertar um defeito tem uma chance substancial - 20 a 50%- de introduzir outro defeito. Então o processo todo é dois passos pra frente e um passo pra trás. E porque defeitos não são corrigidos melhor? Primeiro, porque mesmo um defeito pequeno que parece local tem ramificações pelo sistema todo. Qualquer tentativa de consertar com pouco esforço vai reparar o defeito local e óbvio, mas a menos que a estrutura seja pura ou muito bem documentada, os efeitos do reparo vão passar despercebidos. Segundo, porque o reparador é normalmente alguém que não escreveu o código original, e normalmente é um junior ou trainee. … Como consequência da introdução de novos bugs, programas de manutenção requerem mais testes de sistemas. Teoricamente, depois de cada correção você deve rodar a suíte inteira de casos de teste, para garantir que o sistema não foi danificado”. Você acha que o conceito de rodar suites de testes, manulmente ou automatizado, é algo moderno? De novo, 1975.

No capítulo 14 tem a frase que eu usei no video de Prioridades. “Como um projeto atrasa 1 ano? 1 dia de cada vez“. No capítulo ele diz: “Como alguém pode controlar um projeto grande com agenda apertada. O primeiro passo é TER uma agenda”. Defina milestones, defina prioridades, defina datas. Milestones precisam ser concretos, altamente específicos, mensuráveis. No mundo agile seria próximo da definição de DONE, ou finalizado, de cada etapa. Defina datas e faça caber, pra isso você precisa mudar alguma coisa: equipes, arquiteturas, backlogs. Mude, só não mude a data. Isso é gerência, qualquer coisa diferente é ingerência.

Se só isso não te convenceu. Vamos à edição de 1995. A parte interessante das edições modernas é que Brooks vem criticando seu próprio livro e atualizando ou expandindo alguns dos conceitos. Em 95 ele fala do capítulo 11 onde ele postula que você vai jogar fora o primeiro sistema e explica melhor. Ele começa falando que o modelo Waterfall ou cascata está errado e também corretamente explica como Winston Royce melhorou o modelo sequencial em cascata em 1970 (!!) adicionando: estágios de feedback. Então Brooks resume: a primeira falácia básica do modelo de cascata é que ele assume que o projeto avança pelo processo somente UMA vez” e a segunda falácia é que ele assume que o sistema é construído de uma vez. Qual a solução? Um modelo de construção incremental (!), por exemplo, ele menciona o modelo de Harlan Mills onde começamos a construir primeiro o esqueleto do sistema e várias funções vazias e vamos preenchendo uma a uma. Compile, teste, repita. E citando Brooks: “Em TODO estágio temos um sistema que roda. Se formos diligentes em cada estágio temos um sistema debugado e testado … e já que temos um sistema funcionando toda vez, nós podemos começar testes com usuários muito mais cedo, podemos adotar estratégias que fazem caber no orçamento o que protege contra atrasos no planejamento (ao custo de ter menos features)”. Ele basicamente descreveu conceitualmente o modelo de test driven development, deploys frequentes, ambiente de staging com versões que sempre funcionam. É só o que há de mais moderno no mundo “Agile” de hoje. Em 1995!!

Na verdade com os conceitos do capítulo 11, do Second System, e esse de 95, ele fala muito sobre protótipos que vão ser jogados fora mas vão te ajudar a “pivotar”. Ele define MVP ou Most Viable Product sem usar o termo MVP que só foi cunhado no Lean Startup do Eric Ries em 2011. Mas o conceito já é conhecido na engenharia de software faz décadas!

Você acha que continuous integration ou CI e continuous deployment ou CD são criações do Agile moderno? Esse capítulo de 95 menciona James McCarthy que descreve o processo de Nightly Builds, ou builds toda noite que a Microsoft fazia desde aquela época, um processo automatizado que toda noite recompila e reconstrói a versão mais nova, daí na manhã seguinte dava pra testar a última versão. Se tivesse um defeito grave, pára tudo, até consertar, e repete o processo.

Outra frase que todo mundo já ouviu pelo menos uma vez: “não existe bala de prata”. De onde vocês acham que vem isso? É o primeiro paper incluso na republicação de 20 anos de aniversário, de 1995! Ela se contrapõe à lei de Moore. Na Lei de Moore, que já acabou também aliás, Moore postulava que o poder de processamento dobraria a cada 12 a 18 meses. Simplesmente não há nada assim em software. Nós não conseguimos fazer projetos de software na metade do tempo a cada 12 a 18 meses. Nós estamos longe de ter sequer uma ordem de grandeza em eficiência de engenharia de software, é o elo perdido da nossa engenharia.

Durante a leitura do livro ele vai citando outros autores que vocês deveriam dar uma olhada. Se você assistiu minha série de porque sua linguagem não é especial, vão lembrar que eu mencionei Nicklaus Wirth que inventou talvez uma das coisas mais importantes de programação: a modularização, com sua linguagem Modula, antes do Pascal. Mas Brooks menciona bastante outro pesquisador importante: David Parnas, que criou o conceito de esconder informação, ou encapsulamento, um dos pilares da orientação a objetos que você usa até hoje e - eu tenho certeza - nunca sequer ouviu falar de David Parnas.

Além deles, Harlan Mills que desenvolveu uma metodologia de engenharia de software chamado Cleanroom e, que em muitos aspectos, já tem traços do que você poderia chamar de Agile. Finalmente Tom DeMarco, que eu tenho certeza que pelo menos você já ouviu falar por causa de seu famoso livro Peopleware.

Como podem ver The Mythical Man-Month é conterrâneo de alguns dos mais importantes nomes da computação, ele tem vários pontos que só fazem sentido se você pensar que ele foi escrito em 75 (portanto menciona-se linguagens como APL, Modula, ALGOL, COBOL, ADA, mas obviamente não menciona nada de Java ou Python, eles sequer tinham sido inventados na época!)

Eu vi Agile, técnicas de Extreme Programming, Repositórios como Git, todo o processo open source nascer desde o dia 1, e vejo como os conceitos já existiam antes. Se você só começou a programar no século XXI eu sei que parece que não havia nada antes, mas pra mim que começou a programar no fim dos anos 80, nada foi realmente surpreendente, só uma evolução do que eu já sabia. Eu vi muitas das coisas que eu já fazia ganhar nomes, só isso. Vou falar disso em outro episódio.

Novamente, se você leva a sério sua carreira de programação, deixe um pouco de lado os livros mais recentes - não estou dizendo pra não ler - mas comece por este. A partir dele, procure pela bibliografia de Fred Brooks, esses são os autores que realmente importam. Exemplos, eu mencionei nomes como Christopher Strachey do CPL ou Codd ou Dijkstra.

Não leia o livro de Brooks como um procedimento ou doutrina a ser seguida. Ele é uma conversa: um programador experiente de 75 dizendo ao programador de 2018 como ele continua cometendo os mesmos erros, usando como contexto, os projetos e tecnologias dos anos 70 e 80. E você deveria ficar mais assustado em ver como em 50 anos, muito pouco realmente mudou na engenharia de software.

E faz sentido, porque se toda vez você ignora o que já se sabe do passado, vai simplesmente cometer os mesmos erros e, se tiver sorte, chegar às mesmas conclusões. Seria mais inteligente subir no ombro de gigantes e usar o que eles já sabiam e nos avisaram. Eu faço isso, a forma como eu trabalho deriva mais de Brooks do que de Agile moderno. E quando eu vejo algumas barbaridades vindas do mundo Agile eu só penso … é …

Num lado mais positivo, ele fez um capítulo chamado “The Joys of the Craft” onde ele tenta explorar porque programação é legal. Em resumo ele chegou nestes pontos: Primeiro, simplesmente a graça em fazer coisas. Isso é crafting. Programação é uma profissão de prática. Ela depende de, prática! Segundo, o prazer em fazer coisas que são úteis pra outras pessoas Terceiro, o fascínio de ligar objetos complexos como quebra-cabeças de peças móveis e ver funcionar, brincando com as consequências dos princípios construídos no começo Quarto é o prazer de estar sempre aprendendo Finalmente, existe o deleite de trabalhar numa mídia tão maleável

Lembram o que eu venho dizendo nos vídeos sobre faculdade? A única coisa que você precisa é aprender a aprender, e o único jeito de fazer isso é primeiro gostando de aprender coisas. É o único jeito de começar a se tornar um bom programador. Se você se tornar doutrinado, só seguir certas marcas e só usar certas ferramentas, você nunca vai evoluir como programador. Você vai, no máximo, virar um bom codificador, ou datilógrafo. Copia mas nunca cria. Repete mas não sabe porque. Onde está a ciência em ciência da computação. Ciência não é dogmática.

E aí, o que acharam desse vídeo? Não me enganem, vocês já conheciam esse livro? Comentem abaixo se sim e o que mais gostam desse livro. Se curtiram o vídeo mantem um joinha, assinem o canal e cliquem no sininho pra não perder os próximos episódios! A gente se vê, até mais!

]]>engenharia-de-softwaregestaoagileakitando[Akitando] #11 - Projetos: Aprendendo a Priorizarhttps://akitaonrails.github.io/2018/09/18/akitando-11-projetos-aprendendo-a-priorizar/https://akitaonrails.github.io/2018/09/18/akitando-11-projetos-aprendendo-a-priorizar/Tue, 18 Sep 2018 17:00:00 -0300<p>Disclaimer: esta série de posts são transcripts diretos dos scripts usados em cada video do canal <a href="https://www.youtube.com/channel/UCib793mnUOhWymCh2VJKplQ"target="_blank" rel="noopener">Akitando</a>. O texto tem erros de português mas é porque estou apenas publicando exatamente como foi usado pra gravar o video, perdoem os errinhos.</p> <div class="embed-container"> <iframe src="https://www.youtube.com/embed/akKRtjIqRjs" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen> </iframe> </div> <h3>Descrição no YouTube<span class="hx:absolute hx:-mt-20" id="descrição-no-youtube"></span> <a href="#descri%c3%a7%c3%a3o-no-youtube" class="subheading-anchor" aria-label="Permalink for this section"></a></h3><p>Esse é um assunto que todo mundo bate cabeça, mas o básico não é tão complicado quanto parece. Em vez de complicar as coisas sem necessidade, entenda a linha geral primeiro. Esqueça processos e metodologias se ainda não entendeu a primeira coisa mais importante em qualquer projeto: priorizar as coisas!</p>Disclaimer: esta série de posts são transcripts diretos dos scripts usados em cada video do canal Akitando. O texto tem erros de português mas é porque estou apenas publicando exatamente como foi usado pra gravar o video, perdoem os errinhos.

Descrição no YouTube

Esse é um assunto que todo mundo bate cabeça, mas o básico não é tão complicado quanto parece. Em vez de complicar as coisas sem necessidade, entenda a linha geral primeiro. Esqueça processos e metodologias se ainda não entendeu a primeira coisa mais importante em qualquer projeto: priorizar as coisas!

Links:

Script

Olá pessoal, Fabio Akita

HOJE quero tocar no assunto sobre projetos. Em particular sobre a importância de entender o que significa priorizar as coisas e o processo de gerenciar um projeto Não tem nada tão complexo que requer uma pós-graduação no assunto. Qualquer um pode entender os conceitos básicos e como um conceito naturalmente leva ao próximo.

Em outros episódios vou entrar em mais detalhes sobre cada um desse conceitos, mas hoje quero só mostrar a linha de raciocínio geral que você podem levar para qualquer projeto, pequeno ou grande, basta expandir as premissas que vou mostrar hoje.

…

Um dos problemas mais frequentes que eu vejo é a surpreendente capacidade das pessoas de fugir da priorização. Parece medo de priorizar. E não é difícil de entender porque.

O modo mais normal das pessoas é: “vou fazendo, uma hora dá certo”. Ou pior: “eu não escolho o que fazer, alguém escolhe por mim, e eu só vou fazendo”.

A molecada é muito ligeira pra postar no Twitter como a gerência do projeto ou da empresa é ruim. Mas eu pergunto: quantos desses já assumiram de fato o bastão da responsabilidade pra criticar com tanta confiança? É muito fácil se esconder na anonimidade da internet. Difícil é executar e mostrar resultado. Nunca ouça ninguém que não tem resultados mensuráveis pra mostrar.

Você não precisa ser um MBA ou um “Certified Scrum Master” … pra entender esses conceitos, porque eles são meio triviais na verdade.

Primeiro entenda uma verdade absoluta: você não tem tempo infinito. Sua vida não é infinita, uma coisa que temos em comum é que um dia vamos morrer. Se fôssemos imortais, priorizar seria irrelevante já que poderíamos realmente fazer o que quiser, quando quiser.

No mundo real, tudo é finito. Tempo é a primeira coisa finita. Segundo são recursos, dinheiro, pessoas, materiais. É finito, é restrito e normalmente é pouco. Sua expectativa é investir 1 unidade de recurso pra no futuro conseguir recuperar 2 ou 3. Sim, retorno. Senão você estaria simplesmente jogando recursos fora. Por exemplo, eu costumo dizer que o objetivo de qualquer Product Owner é a responsabilidade sobre o retorno do investimento. Na verdade, eu diria que o objetivo de qualquer profissional é o retorno de investimento sobre seu trabalho, senão pra que você trabalha?

Sendo tempo e dinheiro coisas finitas, você precisa Escolher o que fazer. A primeira coisa a precisa fazer é planejar, enxergar o começo e o fim. Essa é a definição de um projeto. Você tem uma lista de coisas pra fazer, mas provavelmente não dá pra fazer tudo.

Quem me conhece sabe que eu tenho um certo desdém por material de auto-ajuda. Porém sou obrigado a aceitar que analogias e metáforas ajudam a visualizar um conceito abstrato.

Eu vi um vídeo anos atrás, acho que foi de Stephen Covey, autor do famoso Os 7 Hábitos das pessoas altamente eficazes. Ele ensinava o conceito e a importância de priorizar. Eu nunca mais achei esse vídeo online, então quero recriar minha própria versão aqui.

Priorizar funciona assim: você costuma ter tarefas pequenas e tarefas grandes. Tarefas mais fáceis e tarefas mais complicadas. Se você não tem experiência, o normal é a inércia tomar conta e você começar a fazer as tarefas menores ou mais fáceis.

Só quando já é tarde demais se lembra que tinha as tarefas mais importantes que ficaram pra trás. Você percebe que desperdiçou seu tempo fazendo o que não era importante e agora não tem mais tempo. É assim que projetos atrasam: um dia de cada vez, deixando a priorização pra amanhã.

O que o povo aprende a fazer com o tempo? A olhar o big picture: quais são TODAS as tarefas? Quais são as MAIS importantes? Vamos fazer as mais importantes PRIMEIRO e ir encaixando as menos importantes no meio.

Iteração, iteração. E no final, a mesma quantidade de tarefas pode até mesmo CABER no mesmo TEMPO que antes não caberia.

Priorizar é avaliar. É tomar uma decisão e se comprometer. É errar, assumir o erro, reajustar e seguir em frente. É colaborar com os colegas, criar relacionamentos de confiança. Nosso povo sabe que pode confiar um no outro, sabe quem pode procurar pra qual tipo de problema, não existe perda de tempo e desperdício onde a gerência cria silos de influência e um grupo começa a sabotar outro grupo. Nosso povo funciona tão bem que eu posso quase que aleatoriamente ir formando equipes entre eles e eles sabem o que fazer.

Eu aprendi que todo projeto funciona como um gás: ele vai ocupar todo o espaço que você der pra ele. Se você der um ano, o projeto vai durar um ano e mais um pouco. O mesmo projeto se você der 6 meses, vai durar 6 meses e um pouco. A coisa mais importante em um projeto é delimitar os tetos: o custo e o tempo.

E como você sabe que vai durar isso? Você NÃO sabe. Não é uma previsão. Já notou que existem 2 palavras: estimar e prever? Pára de tentar prever. Estime. E estimar não é exato, pela definição da palavra. Estimar é chutar uma ordem de grandeza. Ordens de grandeza não é dizer que vai durar 743 horas e 54 minutos. É saber dizer a ordem de grandeza que estamos falando é uma semana, ou um mês, um semestre, um ano.

O que você faz quando precisa ir pra um lugar longe e não tem um Waze pra te guiar? Você pega um mapa. Mas não tem como ir vendo o mapa o tempo todo e dirigindo ao mesmo tempo. Então você dirige um trecho até onde acha que ainda sabe o caminho. Daí você pára, olha o mapa e vê se continua no caminho certo. Daí prossegue. Pára de novo. De repente você nota que entrou numa curva errada, então você volta até a última bifurcação e corrige. E vai assim até o fim. Por isso a temos sprints ou iterações, senão você ia até o fim do caminho pela estrada errada e quando perceber que tinha feito uma curva errada, já é muito tarde pra voltar. Se for reavaliando em trechos menores, mesmo que precise voltar um pouco ainda dá tempo de corrigir. Faz sentido?

Essa é a essência de gerir um projeto: não é acertar todos os passos, mas garantir que se você errar - e vai por mim, você vai errar - dá tempo de voltar um pouco atrás e corrigir o percurso. Gerir não é evitar 100% dos erros, é garantir que o 1% que errar Não vai comprometer os 99%. Tente ir às cegas: você cai do barranco.

E como você sabe de quanto em quanto tempo parar? Na dúvida pára no menor período possível. Por isso quando me falam de sprints de 3 semanas eu dou muita risada. Significa que se você errar, você vai levar no mínimo 3 semanas pra corrigir e isso pode gerar um efeito cascata de erros que vai prejudicar pelo menos 1 mês e meio de trabalho. Agora começa a escalar isso, é assim que um projeto atrasa 1 ano.

E como você estima as coisas? Tanto faz. Esqueça fórmulas complicadas, diferença de story points, ou qualquer tipo de points. Usa uma escala assimétrica. O menos granular possível. Por exemplo: fácil, médio ou difícil. 1, 2, 5, 8. Por que assimétrico assim? Porque numa ordem de grandeza você quer saber só se a tarefa leva meio dia, um dia inteiro, dois dias ou 1 semana. Mais que isso tanto faz, 5 ou 4 ou 6 dias não faz diferença. Basta 1 story de 8 pontos pra quebrar suas pernas, daí as outras stories de 1 ou 2 pontos não fazem diferença porque essa de 8 é que vai definir seu andamento. É como a demonstração da esfera maior ou das bolinhas menores. Ordem de grandeza. Você só precisa saber quais são as histórias que representam o maior risco, e lidar com o risco. Talvez quebrar em história menores se possível.

Finalmente, você vai ter sua velocidade: quantas dessas histórias são possíveis de serem feitas dentro de um período ou sprint. Com uma ordem de grandeza de velocidade, agora você olha pro projeto como um todo e diz: com essa velocidade atual, dá pra chegar ao fim?

Normalmente não dá. Então você precisa começar a cortar o que é menor prioritário e está no fim da lista. E avisar o quanto antes todo mundo: NÃO VAI DAR TEMPO DE TUDO. É simples assim. Das duas uma: ou simplifica o que precisa fazer ou CORTA o excesso, corta. E não tenta como primeira opção aumentar o custo ou aumentar o tempo. Faz caber! E nem adianta tentar aumentar a velocidade à força. É como no exemplo da viagem de carro sem Waze. Tenta acelerar sem ter certeza, você só vai errar mais bifurcações mais vezes e ter que voltar atrás mais vezes. Não compensa só pisar no acelerador.

Mas e se não for aceitável simplificar ou cortar? Então cancela o projeto, pára agora. Se a premissa inicial tava subestimada, é melhor aceitar um prejuízo pequeno do que tentar acelerar e no final gastar mais e o prejuízo aumentar. É o problema do custo perdido. Sempre é melhor perder o que já gastou no curto prazo do que insistir no erro e no final gastar mais. Deixa eu parar pra explicar custo perdido um pouco.

Digamos que você comprou um ingresso de cinema mas só depois vai ver as críticas e descobre que o filme é uma droga por unaminidade. Assumindo que você não tem nenhum conhecido idiota que compraria seu ingresso, você tem duas opções:

  1. Já que você já pagou pelo ingresso, vai assistir pra não desperdiçar
  2. Jogar o ingresso fora

A falácia do custo perdido é não perceber que em qualquer das duas opções, você já pagou pelo ingresso e não vai ter reembolso e portanto o custo perdido não é relevante pra tomar uma decisão racional.

Opção 1: Você sofre o custo do ingresso + Você sofre pelo resto do filme Opção 2: Você sofre só o custo do ingresso e não desperdiça também o seu tempo

Racionalmente a opção 2 é melhor.

E pra chegar nessa conclusão, primeiro você teve que fazer os passos anteriores que falei: enxergar os limites do projeto que são o tempo e o custo, enxergar o que é o objetivo do projeto, organizar o que é essencial e importante e o que é opcional e pode ser deixado pro fim ou até mesmo cortado, começar a fazer, parar e ver se não errou o caminho, e uma vez determinada a velocidade normal, ver o objetivo é alcançável ou não. E, se não for, parar imediatamente antes de gastar mais do que precisaria pra não chegar em lugar nenhum de qualquer jeito.

E isso, senhoras e senhores, é a essência de gerência de projetos. Avançar num objetivo inalcançavel, continuar remando num navio que vai afundar, não é gerenciar, é simplesmente dirigir às cegas sem um mapa. E tudo começa com priorização.

Como eu disse no começo, o objetivo desse vídeo não é transformar ninguém em um ultra gerente de projetos. É só introduzir os primeiros conceitos do que todo mundo, gerente ou não gerente, deveria saber. Em outros vídeos eu quero explorar alguns desses conceitos em mais detalhes, algum em especial que você tenha interesse? Não deixe de mandar nos comentários quais aspectos de projetos mais deixam você inquieto. E se gostou deste vídeo mande um joinha, assine o canal e não deixe de clicar no sininho pra não perder os próximos episódios. A gente se vê até a próxima !

]]>gestaoagileprodutividadeakitandoEstimativas São Promessas - Uma Metáfora Melhorhttps://akitaonrails.github.io/2017/06/26/estimativas-sao-promessas-uma-metafora-melhor/https://akitaonrails.github.io/2017/06/26/estimativas-sao-promessas-uma-metafora-melhor/Mon, 26 Jun 2017 17:44:00 -0300<p>Se você não sabia, eu respondo perguntas no Quora com frequência. <a href="https://www.quora.com/profile/Fabio-Akita"target="_blank" rel="noopener">Me siga lá</a>; já escrevi quase 600 respostas, muitas parecidas com os posts mais longos daqui do blog.</p> <p>Uma das mais populares responde à pergunta <a href="https://www.quora.com/What-is-the-hardest-thing-you-do-as-a-software-engineer/answer/Fabio-Akita"target="_blank" rel="noopener">&ldquo;Qual é a coisa mais difícil que você faz como engenheiro de software?&rdquo;</a>. Escrevi algo parecido em português no post <a href="http://www.akitaonrails.com/2013/08/23/off-topic-estimativas-sao-promessas-promessas-devem-ser-cumpridas"target="_blank" rel="noopener">&ldquo;Estimativas são Promessas. Promessas devem ser cumpridas.&rdquo;</a>.</p> <blockquote> <p>Em resumo: você nunca consegue dar uma estimativa &ldquo;correta&rdquo;. Se conseguisse, não seria uma &ldquo;estimativa&rdquo;, seria uma &ldquo;previsão&rdquo;.</p>Se você não sabia, eu respondo perguntas no Quora com frequência. Me siga lá; já escrevi quase 600 respostas, muitas parecidas com os posts mais longos daqui do blog.

Uma das mais populares responde à pergunta “Qual é a coisa mais difícil que você faz como engenheiro de software?”. Escrevi algo parecido em português no post “Estimativas são Promessas. Promessas devem ser cumpridas.”.

Em resumo: você nunca consegue dar uma estimativa “correta”. Se conseguisse, não seria uma “estimativa”, seria uma “previsão”.

Vamos assumir que não temos poderes de precognição nem bolas de cristal para prever o futuro.

Estimar algo é “chutar” o valor de alguma coisa. É sempre um chute, a mesma coisa que uma avaliação. Como todo chute, nunca pode ser considerado “correto”: é só um candidato provável dentro de uma faixa infinita de valores possíveis.

Não existe nenhuma conexão entre um chute e o resultado. Entenda essa verdade simples: dizer que algo pode acontecer não FAZ com que aconteça.

Estimar que vai chover amanhã não FAZ chover. Estimar o resultado do Super Bowl não FAZ o jogo acontecer daquele jeito. Não há correlação entre uma estimativa e o resultado real.

Eu disse nos artigos mencionados que “Estimativas são Promessas”. A intenção era provocar uma reação, porque a maioria das pessoas assume que estimativas jamais podem ser promessas, justamente pelo que acabei de explicar.

O que torna uma promessa especial é que, ao prometer algo, espera-se que você AJA para realizá-la.

Skin in the Game

Ninguém que não tem “skin in the game” deveria dar estimativas.

Se você não é um jogador ativo no jogo, não deveria dar chutes. Do mesmo jeito que ninguém faz promessas em nome de outra pessoa.

Dá pra fazer promessas críveis e cumpri-las? Dá, mas primeiro você precisa entender mais algumas verdades sobre a realidade.

Você provavelmente já leu muitos artigos explicando metodologias e técnicas de gestão de projetos. A maioria consegue explicar os “o quês” e os “comos”, mas como sempre, falha nos “porquês”.

Por que precisamos dessas metodologias? Por que elas são necessárias? Por que funcionam? Que mecanismos ocultos elas colocam em movimento?

O que diferencia as técnicas Ágeis da homeopatia ou de um clichê barato de autoajuda?

É sempre sobre Pareto

Não existe escopo de projeto preciso. Existe um limite para adicionar detalhes, e depois dele você só tem retornos decrescentes.

O nível mais preciso de detalhe que o escopo de uma funcionalidade pode ter é o próprio código. E isso importa: as linhas de código NÃO são o produto final. O que os usuários experimentam de fato é a execução desse código em tempo de execução.

A programação em si é o blueprint de verdade. Os diagramas, os casos de uso, as user stories e tudo que vem antes da programação são só rascunho, um esboço.

Um arquiteto ou designer ingênuo pode achar que diagramas detalhados, documentos de casos de uso e slides bonitos de PowerPoint valem o mesmo que um blueprint de engenharia. Eles valem menos: são o equivalente a um rabisco no guardanapo. Voláteis e, na prática, quase inúteis.

Napkin Sketch

“Mas a programação não é a mesma coisa que a fase de construção, colocar tijolo sobre tijolo?” NÃO, não é isso que um programador faz. Empilhar tijolos é trabalho do interpretador da linguagem ou do compilador que gera o binário executável.

Essa é a metáfora que deixa os não-programadores malucos. Na engenharia, a construção em si é a parte mais cara e demorada. Na programação, a parte cara é criar o blueprint (escrever o código), e a “construção” é trivial: só compilar, o que é automático.

Do mesmo jeito, o escopo de um projeto é só um conjunto de esboços. Precisamos abandonar a ideia de que vai existir um escopo “completo”. Não dá pra dizer “100% do escopo” ou “escopo fechado”, porque o escopo de um projeto de software é, por definição, sempre incompleto.

Além disso, sustento que cerca de 80% desse tal “escopo”, o que prefiro chamar de esboço, é praticamente inútil para a maioria das atividades dos usuários finais: a seção administrativa, as páginas institucionais que ninguém lê, processos complicados de cadastro e por aí vai.

Por isso toda lista de funcionalidades precisa ser priorizada. Você costuma se virar com 20% das funcionalidades, que é o que as pessoas querem dizer com “MVP” ou “produto mínimo viável”. Entregue o mais cedo possível, colete feedback dos usuários e refine o resto do “esboço” que você chama de backlog.

Então, em vez de mirar numa proposição de tudo-ou-nada, procurando equações complexas e estúpidas para calcular uma estimativa “precisa” de um esboço incompleto, assuma que dá pra entregar CEDO os primeiros 20% que realmente importam e descubra o resto em iterações.

É isso que chamamos de “Ágil”, aliás.

Ágil é sobre Gestão de Riscos

As pessoas assumem que Agilidade é gerenciar os próprios instrumentos de gestão: o backlog, os rituais, as métricas.

Ter instrumentos parecidos com Ágil não te torna Ágil.

Ser Ágil é manter o Risco sob controle.

Em vez de tratar projetos como uma proposição de tudo-ou-nada, comece a pensar como um investidor pensa no seu portfólio de ações. Você não espera que o portfólio inteiro dê lucro; parte do princípio de que alguns ativos vão ter desempenho abaixo do esperado. Como não sabe quais, você dilui o risco.

Portfolio stocks

Tentar prever o mercado de ações é um exercício de futilidade.

Tentar prever a implementação exata de um projeto, ainda mais os longos, também é um exercício de futilidade.

Então você precisa lidar com a incerteza do jeito certo: tornando-se Antifrágil.

“Algumas coisas se beneficiam de choques; elas prosperam e crescem quando expostas à volatilidade, aleatoriedade, desordem e estressores, e adoram aventura, risco e incerteza. No entanto, apesar da ubiquidade do fenômeno, não existe uma palavra para o exato oposto de frágil. Vamos chamá-lo de antifrágil. A antifragilidade vai além da resiliência ou robustez. O resiliente resiste aos choques e permanece igual; o antifrágil melhora.” - Nassim Taleb

Em vez do exercício absurdo e inútil de tentar prever incertezas e eventos aleatórios, você faz a coisa sensata: assume que Cisnes Negros existem e que você não consegue prevê-los. E aí se prepara para a incerteza da única forma razoável, que é não tentar prevê-los.

Exponha os pequenos erros cedo e corrija com frequência. Implementar tudo numa caixa-preta e fazer um deploy Big Bang é o caminho mais fácil para o fracasso. Entregar sempre, expor os bugs e corrigi-los constantemente é aceitar que erros vão acontecer e ganhar força no processo.

Antifragile

Uma Metáfora Melhor

Iron Ore Furnace

Imagine que você, seja o cliente não-programador, seja o programador que não faz ideia de como explicar o processo para esse cliente, tem um alto-forno de minério de ferro para gerenciar.

O problema desses fornos é que, se você aquecer demais, eles podem explodir na sua cara. Se esfriar demais, o minério endurece.

Seu trabalho é adicionar carvão ao forno, e você decide o ritmo. Rápido demais, fica quente o bastante para explodir. Devagar demais, o fogo apaga e você perde o forno.

Agora tente estimar uma entrada constante de carvão para manter o forno em bom estado.

Não dá.

A saída mais fácil é instalar um termômetro que acompanha a temperatura atual do forno.

Você fica seguro dentro de uma certa margem de temperatura e acelera ou reduz a entrada de carvão consultando o termômetro o tempo todo.

O TEMPO TODO.

Iron Furnace

É isso que a “Velocidade” do Ágil (ou qualquer simulação de Monte Carlo mais sofisticada) realmente é: um termômetro.

Se a Velocidade está alta demais, seu time provavelmente está fazendo hora extra ou entregando código de qualidade inferior. Isso vai dar problema: ou o time estoura rápido demais, ou o código acumula dívida técnica rápido demais e você não vai conseguir pagar. Mantido esse ritmo, a Velocidade despenca até parar (o forno explode).

Se a Velocidade está baixa demais, seu time está enrolando, seu backlog é um lixo que ninguém entende nem depois de 10 horas de reunião, ou você deixou a Velocidade subir demais e agora está pagando a dívida técnica, ou seu time está morto de burnout (o fogo apagou).

Você quer manter a Velocidade estável, constante. É disso que se trata ser Ágil: ficar de olho no termômetro e responder.

O Triângulo de Ferro dos Projetos

Iron Triangle

Bem-vindo ao Triângulo de Ferro da Gestão de Projetos.

Repita comigo: se eu quero travar o tempo, o custo e o escopo, sou um idiota.

Repita de novo.

Você deve travar tempo e custo. Se leu até aqui, sabe que nunca consegue travar o “escopo”: só dá pra engordá-lo, e nem sempre torná-lo mais valioso. Por isso sempre digo que a definição de um Product Manager ou Product Owner é ser o guardião do ROI (Retorno sobre Investimento).

Por quê?

Porque o Triângulo de Ferro tem o seguinte corolário:

Project Triangle

  • Se quer rápido e bom, não pode ser barato
  • Se quer rápido e barato, não pode ser bom
  • Se quer bom e barato, não pode ser rápido

Isso é uma Lei, não tem como contornar. Escolha o seu.

Make your choice

Como Cumprir Promessas então?

Com essas 3 verdades em mãos:

  • Não dá pra ter tudo ao mesmo tempo (barato, rápido e bom)
  • Você está gerenciando a temperatura do forno
  • Você só precisa de 20% do “esboço” que chama de “escopo”

Sim, qualquer desenvolvedor experiente consegue te dar uma estimativa de “ballpark”. Uma estimativa de ballpark é assim:

  • 1 mês (talvez 1 mês e meio, mas com certeza menos de 2)
  • 3 meses (mais de 2 meses, menos de 6)
  • 6 meses (mais de 4 meses, menos de 9)
  • mais de 6 meses, provavelmente menos de 1 ano

Nem tente granular mais que isso. É inútil.

Trave o tempo. E trave o custo (o número de desenvolvedores vezes a taxa horária vezes o total de horas estimadas). Só isso.

Agora anote o que o cliente chama de “escopo” como user stories num backlog e peça pra ele priorizar.

Comece as iterações. Depois de cada uma, faça deploy num ambiente de staging. Não-programadores, atenção: SEMPRE garanta que o programador que você contratar entregue versões testáveis das stories numa URL pública que você possa visitar e testar.

Se o programador recusar isso ou vier com desculpa: DEMITA.

Se o programador, a empresa ou seja lá o que for te prometer um preço de “escopo fechado”, prometer fazer tudo e você acreditar, você é ingênuo demais.

Acha graça em jogar esse jogo idiota de “vou fingir que sei a verdade e você vai fingir que acredita no que estou dizendo”?

Actions and Words

Nenhum profissional sério tem tempo pra jogos idiotas. A única coisa honesta que alguém pode dizer sobre qualquer projeto de software é: “com base na minha experiência, acredito que o ballpark para esse tipo de projeto é de X meses, dados os pressupostos Y e Z”.

Você não precisa acreditar nele. Só precisa começar a verificar o termômetro. Qualquer não-programador consegue avaliar a qualidade da entrega a partir das entregas frequentes das funcionalidades priorizadas.

“Mas e se depois de 2 semanas eu não gostar do resultado?” Simples: DEMITA.

E às vezes “demitir” nem é a palavra certa. Às vezes o relacionamento é difícil e o melhor é seguir caminhos separados.

Você precisa aceitar perder 2 semanas, ou qualquer período curto, como parte da Gestão de Riscos. É melhor aceitar perder 2 semanas do orçamento do projeto do que acreditar cegamente em alguém por 6 meses e perder o orçamento inteiro e mais um pouco.

Pareto de novo: Agilidade é sobre Gestão de Riscos. Você aceita que perder 20% do orçamento está de bom tamanho e joga com isso. E tudo bem, porque você só precisa de um pouco mais de 20% do esboço vago que chama de escopo.

Viu o que fiz com a matemática aqui?

Paramos de jogar o faz-de-conta e passamos a gerenciar de fato os riscos do projeto. Você colabora no termômetro equivalente, que combina o backlog priorizado (a escala) e a velocidade (a temperatura), e fica de olho nas entregas parciais no ambiente de staging.

Conclusão

Então sim, Estimativas devem ser levadas tão a sério quanto Promessas. Você consegue dar Estimativas razoáveis desde que consiga gerenciar os Riscos e o Cliente aceite as regras do jogo: não existe “escopo fechado e completo”, prioridades primeiro, e testar e aceitar funcionalidades entregues toda semana.

A ideia por trás das Promessas é que você precisa GERENCIAR para cumpri-las. A melhor forma é parar com frequência, reavaliar e seguir. Parece perda de tempo, mas é assim que você evita desperdiçar tempo de verdade.

Se você não tem skin in the game, dê um passo atrás.

A Velocidade deve ser mantida estável, num ritmo previsível. Use a variância como sinal de estar rápido demais ou devagar demais, ajuste a outra variável, meça de novo e siga. Igual a um termômetro de forno.

Existem várias versões de “termômetros”, do Evidence Based Scheduling do Joel Spolsky às sofisticadas simulações de Monte Carlo e outros processos estocásticos (todos são termômetros, e NÃO ferramentas de estimativa).

O que te impede de fazer isso é usar as metáforas e as referências erradas.

Em vez de procurar metáforas equivalentes na construção civil, nas fábricas e em outras montagens de “hard”-ware, olhe para outro lugar, onde você vai encontrar processos de “soft”-ware.

Músicos têm prazos. Pintores têm prazos. Coreógrafos têm prazos. Esportes têm prazos. Laboratórios de pesquisa têm prazos. Como eles cumprem? Verificando constantemente o estado atual, comparando com os objetivos, avaliando se o que fazem está funcionando e mudando o que não funciona.

Conducting Star Wars

Hollywood tem prazos. Tem variáveis muito piores de controlar do que qualquer projeto de software que você vá encontrar, e ainda assim entrega. E lucra.

Aceite que você não controla todas as variáveis e pare de tentar. Pense nos mercados financeiros. Um dia o Ethereum dispara 4.000% e no dia seguinte despenca num flash-crash.

Não tente ficar resistente ou resiliente. Prepare-se para ser Antifrágil.

]]>agilegestaoengenharia-de-softwareoff-topic[Off-Topic] Coletânea "Processos e Metodologias Não Vão Te Ajudar!"https://akitaonrails.github.io/2015/01/07/off-topic-coletanea-processos-e-metodologias-nao-vao-te-ajudar/https://akitaonrails.github.io/2015/01/07/off-topic-coletanea-processos-e-metodologias-nao-vao-te-ajudar/Wed, 07 Jan 2015 14:33:00 -0200<p>Este é um dos assuntos mais antigos que eu exploro neste blog. Muitos dos princípios e filosofias por trás dele estão nos meus famigerados (e longos) <a href="http://www.akitaonrails.com/off-topic/"target="_blank" rel="noopener">Off-Topic</a>. Como são muitos anos de posts, resolvi compilar o que considero as bases do que todos precisam saber sobre esse longo bikeshedding chamado &ldquo;processos e metodologias&rdquo;.</p> <p>Comece simples com o artigo que empresta título a esta coletânea, <a href="http://www.akitaonrails.com/2013/05/24/processos-e-metodologias-nao-vao-te-ajudar"target="_blank" rel="noopener">Processos e Metodologias não vão te Ajudar</a>, que publiquei nos blogs da Abril em 2011. É o ponto de partida para entender o que são processos, metodologias e procedimentos.</p>Este é um dos assuntos mais antigos que eu exploro neste blog. Muitos dos princípios e filosofias por trás dele estão nos meus famigerados (e longos) Off-Topic. Como são muitos anos de posts, resolvi compilar o que considero as bases do que todos precisam saber sobre esse longo bikeshedding chamado “processos e metodologias”.

Comece simples com o artigo que empresta título a esta coletânea, Processos e Metodologias não vão te Ajudar, que publiquei nos blogs da Abril em 2011. É o ponto de partida para entender o que são processos, metodologias e procedimentos.

Em seguida, vá direto ao mais recente Agile: a Verdade por trás do Método e entenda de uma vez: nenhuma metodologia ou receita mágica vai salvar membros incompetentes ou de mau caráter em nenhuma equipe. Depois de tentar melhorar postura e treinamento sem sucesso, você só livra o time desses elementos de uma forma: trocando os membros. Nada salva um Net Negative Producing Programmer.

Muitos ficam com aquela sensação de “desperdício”, tipo “puxa, mas já investimos tanto nele, e se investirmos mais um pouco?”. Isso vem da falta de compreender que Custo Perdido é melhor do que aumentar seu Custo de Oportunidade.

No mesmo tema “Agile is Dead”, ou, mais explicitamente, “Agile-by-bikeshedding-consultants is Dead”, vale relembrar o antigo tema de O problema das credenciais e A Argumentação através da Intimidação. O cara da credencial tem o trabalho mais fácil do mundo: chega na sua empresa para implementar “práticas” que ele não pratica de verdade. E tentar implementar em uma ou meia dúzia de lugares é ridiculamente a mesma coisa que nada.

Quando “parece” que dá certo, ele coloca o caso na lista do portfolio como “sucesso”. Quando dá errado, diz “você não fez direito”. Péssimo.

Esqueçam nomes pomposos e diferentes escolas de metodologias. Tudo parte exatamente do mesmo princípio: Método Científico vs Cargo Cult, onde é claro que ninguém compreende o principal do método: ele não escolhe lados, nem torce por nenhum time.

Não existe a frase “está provado que funciona porque já vi funcionando em 100 lugares”.

Qualquer um que use uma frase similar a esta é claramente um amador. Pelo princípio da “Falseabilidade” de Karl Popper, em vez de tentar provar que algo funciona, o melhor é tentar desprovar que ela funciona. Porque não importa quantas toneladas de evidências conseguimos acumular de que algo é verdadeiro, basta uma única evidência que a torne falsa pra destruir qualquer hipótese. É por isso que o corpo científico é robusto, não porque temos montanhas de evidências a seu favor, mas porque o que temos acumulado até hoje ainda não foi provado falso.

Porém, seres humanos são falíveis. Nosso cérebro não-racional, resquício de nossa longa evolução, ainda é excepcional em enxergar padrões onde eles não existem, como descrevo em Somos Matematicamente Ignorantes e Processos, Metodologias e o Cérebro Humano.

A hipótese mais aceita é que temos a tendência de confundir correlação com causalidade. Porque “A” veio antes de “B”, tendemos a achar que “A” causou “B”, e isso, na maioria das vezes, não é verdade. O mundo é mais aleatório do que gostaríamos de aceitar. Shit just happens.

Isso leva aos pseudo-intelectuais, que querem empurrar sua “Dieta Southbeach” da vez e se tornam meros trolls ou haters, como descrevo em Matemática, Trolls, Haters e Discussões de Internet. Eles criam mais e mais dietas, como falo em #noEstimates Debunked, Desmistificando o método Kanban e Cuidado com o Kanban-butt.

E tudo isso que linkei acima é apenas a introdução da coisa mais importante de todas: seja cético o tempo todo, nada é automaticamente verdade, não importa quem esteja dizendo. E como Carl Sagan diria: “afirmações extraordinárias EXIGEM evidências extraordinárias”. No fim, sempre voltamos ao tema dos Inimigos da Razão.

O problema é: se nada disso funciona, o que fazer? É bem mais fácil dizer o que está errado do que dizer o que fazer. O problema nunca foi a receita. Tudo se resume às decisões que você toma.

Cada decisão traz consequências, que levam a novos dilemas, que exigem mais decisões. Como Neo diria em Matrix Reloaded: “O problema são as escolhas”. Simplesmente não existe receita, dieta ou metodologia mágica que faça você tomar decisões melhores o tempo todo.

Existe uma vontade de buscar uma ferramenta externa, uma fonte externa de “validação”, que é uma das piores palavras inventadas nos últimos tempos. O detalhe é que decisões carregam consequências, e a maioria das pessoas simplesmente gostaria de não ter que assumi-las. Essa é a raiz do problema. É a zona de conforto: todos reclamam e querem coisas, mas ninguém quer tomar decisões e, muito menos, encarar suas consequências.

A única forma de tomar decisões melhores é estudar e treinar, o máximo possível, o tempo todo, continuamente. Experiência não é fazer a mesma coisa 10 anos seguidos, e sim se tornar muito bom em 10 coisas diferentes ao longo desses 10 anos. Seguir a moda não vai te ajudar, assim como seguir dietas mágicas. Elas te deixam um pouco mais magro no começo, e logo vem o rebote que te deixa mais gordo do que você era antes. É por isso que Processos e Metodologias não vão te ajudar.

]]>agilegestaofilosofiaoff-topic[Small Bites/Off-Topic] "People over Processes", o que são "People"?https://akitaonrails.github.io/2014/11/21/small-bites-off-topic-people-over-processes-o-que-sao-people/https://akitaonrails.github.io/2014/11/21/small-bites-off-topic-people-over-processes-o-que-sao-people/Fri, 21 Nov 2014 16:06:00 -0200<p>Essa frase aparece bastante no mundo ágil. A leitura correta dos 4 valores do Manifesto Ágil está no que ele mesmo diz: &ldquo;Ainda que exista valor nos itens à direita, valorizamos mais os da esquerda&rdquo;.</p> <p>O problema é usar a frase como desculpa. Ela vira &ldquo;não precisamos de processos, basta deixar as pessoas escolherem&rdquo;, ou então &ldquo;as pessoas escolhem, então vamos ter consenso pra tudo&rdquo;, a falácia da <a href="http://www.akitaonrails.com/2011/04/25/off-topic-mea-culpa-organizacoes-democraticas-nao-funcionam"target="_blank" rel="noopener">organização democrática</a>. No fundo, é justificativa para não entender o valor de ter processos.</p>Essa frase aparece bastante no mundo ágil. A leitura correta dos 4 valores do Manifesto Ágil está no que ele mesmo diz: “Ainda que exista valor nos itens à direita, valorizamos mais os da esquerda”.

O problema é usar a frase como desculpa. Ela vira “não precisamos de processos, basta deixar as pessoas escolherem”, ou então “as pessoas escolhem, então vamos ter consenso pra tudo”, a falácia da organização democrática. No fundo, é justificativa para não entender o valor de ter processos.

Agile, derivado do Lean, é inteiramente baseado em processos. E o pilar do Lean original (não das derivações como Lean Startup ou Kanban) é o “Kaizen”, ou seja, a “melhoria contínua”.

A ideia é que o hoje seja pelo menos um pouco melhor do que o ontem. O que fazemos é mensurável, e por isso dá para afirmar que hoje ficou melhor do que ontem. O princípio é simples; a execução, nem tanto. Se ainda não leu, siga os links deste parágrafo para entender esses conceitos.

Agora vem a parte ruim: como falar sobre pessoas? Ou, mais especificamente, sobre o comportamento das pessoas?

Como todos nós somos “pessoas”, temos a certeza de que sabemos como as pessoas pensam. E nada poderia estar mais distante da verdade. Carregamos ideias pré-concebidas, falaciosas, supersticiosas e preconceituosas, muitas ultrapassadas há tempos. De tanto serem repetidas como clichê, ainda acreditamos nelas, do mesmo jeito que muita gente acredita que só usamos 10% do cérebro ou que não dá para tomar manga com leite.

E não precisamos adivinhar. Assim como no caso dos processos, existe uma longa literatura sobre pessoas: psicologia, sociologia (que evoluiu muito a partir dos anos 90 graças ao estudo de redes), economia comportamental, entre outras. É impossível para quem vem da tecnologia virar especialista em Humanas, mas se a responsabilidade é priorizar pessoas, além dos processos, é melhor se equipar o suficiente.

Este é um Small Bite porque não pretendo, desta vez, entrar em detalhes sobre o assunto. Prefiro deixar alguns livros de que gosto muito para dar uma base.

Dentro da própria área de tecnologia existem alguns clássicos que valem a leitura:

Daí podemos ir para Economia Comportamental e Psicologia:

E, mais especificamente, sobre o comportamento de diversos agentes em grupos (teoria de redes):

Sim, muitos desses livros são bem superficiais (nenhum é técnico ou de especialista), mas a intenção é só dar uma introdução às diversas áreas. Com o tempo, eliminei alguns superficiais demais, já na categoria de entretenimento e auto-ajuda, como Malcolm Gladwell, Dan Pink, Clayton Christensen e Clay Shirky. Ainda assim, vale a pena ler alguns deles.

O principal é a conclusão: ao contrário do que costumamos pensar, nós, pessoas, não somos tão racionais quanto gostaríamos, e nosso comportamento é fortemente influenciado por agentes externos e pelo ambiente.

]]>agilepsicologiagestaooff-topic[Off-Topic] Agile: a Verdade por trás do Métodohttps://akitaonrails.github.io/2014/09/28/off-topic-agile-a-verdade-por-tras-do-metodo/https://akitaonrails.github.io/2014/09/28/off-topic-agile-a-verdade-por-tras-do-metodo/Sun, 28 Sep 2014 23:18:00 -0300<p>Este ano, além da <a href="http://www.akitaonrails.com/2014/08/23/small-bite-um-pouco-tarde-o-grande-debate-sobre-tdd"target="_blank" rel="noopener">discussão sobre TDD</a> (que não está morto!), ninguém menos que um dos signatários do Manifesto Ágil, Dave Thomas, declarou a morte de &ldquo;Ágil&rdquo; como conhecemos hoje.</p> <p>Alguns artigos que podem dar base ao resto da discussão:</p> <ul> <li>de Dave Thomas <a href="https://pragdave.me/blog/2014/03/04/time-to-kill-agile/"target="_blank" rel="noopener">Agile Is Dead (Long Live Agility)</a></li> <li>de Richard Bishop <a href="http://web.archive.org/web/20140908134511/http://rubiquity.com/2014/03/12/agile-is-dead-angry-developer.html"target="_blank" rel="noopener">Agile Is Dead: The Angry Developer Version</a></li> <li>de Giles Bowkett: <a href="http://gilesbowkett.blogspot.com/2014/09/why-scrum-should-basically-just-die-in.html"target="_blank" rel="noopener">Why Scrum Should Basically Just Die In A Fire</a></li> </ul> <p>Na minha empresa, desde a concepção, não usamos a palavra &ldquo;Ágil&rdquo;, &ldquo;Scrum&rdquo; nem qualquer outro buzzword. Temos &ldquo;sprints&rdquo;, sim, mas coisas como grooming e planning poker (brincadeira!) não são de jeito nenhum &ldquo;impostas&rdquo;. As práticas são usadas, com ou sem os nomes, sempre que necessárias. Não gosto de usar &ldquo;Scrum&rdquo;, &ldquo;Kanban&rdquo; ou qualquer outro rótulo, me dá uma leve vergonha mencionar esses nomes.</p>Este ano, além da discussão sobre TDD (que não está morto!), ninguém menos que um dos signatários do Manifesto Ágil, Dave Thomas, declarou a morte de “Ágil” como conhecemos hoje.

Alguns artigos que podem dar base ao resto da discussão:

Na minha empresa, desde a concepção, não usamos a palavra “Ágil”, “Scrum” nem qualquer outro buzzword. Temos “sprints”, sim, mas coisas como grooming e planning poker (brincadeira!) não são de jeito nenhum “impostas”. As práticas são usadas, com ou sem os nomes, sempre que necessárias. Não gosto de usar “Scrum”, “Kanban” ou qualquer outro rótulo, me dá uma leve vergonha mencionar esses nomes.

Para quem de fato aplica as práticas de agilidade no dia a dia, isso não é nenhuma novidade. Não há dúvidas sobre coisas como Collective Code Ownership (Github!), Continuous Integration (Jenkins, Travis, Semaphore, etc), Test Driven Development (Rspec, Jasmine, Capybara, etc), Refactoring, YAGNI, User Stories/Requirements/Use Cases (ou tanto faz a nomenclatura: basicamente, escopo). Veja os processos de projetos open source: em termos de práticas de programação, não é muito mais do que isso.

O problema é o processo: o gerenciamento de projeto em si. Fala-se muito em Waterfall vs Agile, mas isso é um grande bullshit. O que se lamenta é como o mundo das consultorias “especializadas” em “processos Ágeis” prostituiu a Agilidade.

E é verdade. É por isso que eu não “vendo” coisas como “implementação de metodologias”, e na verdade não recomendo que ninguém contrate um terceiro para isso. Se precisar muito, avalie quanto de hands-on direto no código e no dia a dia o candidato realmente tem. A maioria acumula mais horas “verbais” do que de ação.

Neste artigo não vou dar a solução, isso fica para um próximo. Aqui quero apenas dizer a única grande verdade que ninguém avisa, e por isso qualquer tentativa de implementação vai falhar: a implementação de quaisquer práticas, processos e métodos Ágeis exige uma boa equipe, tanto programadores quanto gerentes e todo o resto.

“Boa equipe” significa uma equipe só de “sêniors”? Não. Exige gente comprometida com sua prática, sejam juniores ou sejam sêniores. Aliás, os que muitos hoje consideram “sêniores” ou “ninjas” (argh, seja porque palestram, seja pelos muitos anos de “experiência”) são quase todos bem pouco comprometidos e meramente arrogantes. De novo, mais verbo do que ação.

Este ponto é crucial: muita gente vai tentar implementar “Ágil” na esperança de transformar uma equipe ruim, ou uma empresa ruim, em algo melhor. Isso não vai acontecer. No começo vai parecer que “melhorou” ou, pelo menos, que alguma coisa “mudou”. Mas é óbvio: você está implementando algumas práticas meramente “diferentes”, claro que por algum tempo alguma coisa vai mudar.

Programação é uma profissão de prática. Não dá para transformar um programador ruim num bom só adicionando métodos, da mesma forma que fazer um jogador de futebol novato assistir a um treinamento de dois dias nunca vai transformá-lo num fazedor-de-gols. Somente a prática árdua, ininterrupta, consistente, feita de pequenas melhorias contínuas, talvez o leve a ser um goleador. No meu cinismo, eu disse diretamente a Bob Martin minha teoria sobre o que motivou Ken Schwaber a criar algo tão idiota quanto a Certificação de Scrum, na Railsconf 2010.

Quem programava nos anos 80 e 90 não viu nada tão disruptivo quando as descrições dos princípios e práticas chamados “Ágeis” apareceram no fim dos anos 90, até a publicação do manifesto em 2001. O que foi diferente é que finalmente alguém condensou tudo num pacote comercial marketável, principalmente o Scrum (que sozinho não inclui nenhuma das importantes práticas de programação do Extreme Programming). Quer ver como as práticas vêm evoluindo há muito mais tempo? Leia The Cathedral and the Bazaar e The Mythical Man Month.

Portanto não: implementar Scrum ou mesmo começar a implementar XP não vai salvar uma equipe ruim. Um ou outro, que já tinha pré-disposição, talento e vontade, vai conseguir se tornar ágil, depois de praticar, errar e praticar mais. Os outros, que não têm o talento nem a pré-disposição, ou pior ainda, são de fato mal-caráter, não vão mudar.

Nenhuma metodologia do mundo jamais vai mudar a personalidade de uma pessoa, pelo menos não em tão pouco tempo. Pense assim: a mãe dele não conseguiu fazer o cara deixar de ser preguiçoso e enrolador, você também não vai conseguir, e nem é essa a sua função. Sua função é entregar valor.

A verdade não dita do mundo Ágil é que a aplicação das práticas ágeis nasce naturalmente entre bons programadores já com experiência. Ela não será útil numa equipe novata, que ainda precisa praticar muito, com ou sem princípios ágeis.

Eu disse que basta ver como funciona o mundo open source. Ao contrário do que muitos brasileiros novatos imaginam, open source não tem nada, a princípio, a ver com inclusão ou movimentos esquerdistas. Eu resumiria open source como “a forma capitalista mais eficiente de se manter commodities”. Ele é altamente exclusivo para desenvolvedores.

Sem nenhum vínculo empregatício, de forma puramente voluntária, os interesses giram em torno de marketing: exposição da empresa, exposição do desenvolvedor, redução de custos, oportunidades. Você realmente precisa ser “bom” para se manter no topo da lista. A opinião de todo mundo tem o mesmo peso? Pergunte a Linus Torvalds o que ele faz quando uma ideia ruim aparece.

O mundo open source expõe problemas imediatamente. Só porque você acha o seu projeto “legal” isso não se traduz automaticamente em voluntários e exposição. A taxa de projetos que morrem é ordens de grandeza maior do que a de projetos que ganham tração. Comparado ao mundo comercial, o open source mata projetos muito mais rápido.

Ágil foi feito para expor os problemas o quanto antes. Entenda: as práticas Ágeis são mecanismos de exposição de problemas! Ágil é um mecanismo de redução e gerenciamento de Risco! Encontrar os obstáculos no momento em que acontecem e tratá-los imediatamente para mitigar riscos futuros desnecessários, que só levam a desperdício.

Só que ninguém quer fazer isso. Se o problema for o gerente, que consultoria vai conseguir removê-lo do cargo, a menos que o dono acima dele esteja comprometido em cortar na própria carne? Se o problema é o programador mal-caráter que todo mundo gosta (o tipo mais perigoso: o que sabe se articular e criar zonas de influência entre pares e superiores), como mandar esse cara embora?

Sim: consertar uma equipe em pouco tempo significa necessariamente substituir seus membros. No pior dos casos, trocar todos eles. Se o método for bem aplicado, ele imediatamente demonstra e expõe os problemas. E como na grande maioria dos casos o problema está no comportamento, e não na prática, é preciso resolver na hora. Se você, stakeholder e responsável pela sua empresa, não está mandando ninguém embora depois de começar a implementar Ágil, está fazendo errado.

E aqui está o grande problema: ninguém entende esse compromisso. Não há almoço de graça. Não há como fazer omeletes sem quebrar alguns (ou todos) os ovos. Sem esse entendimento e esse compromisso, não há agilidade. Aliás, não é a primeira vez que eu digo isso, se você leu meu artigo de 2009: Net Negative Producing Programmer. Mas como a maioria parece ainda não ter entendido, resolvi deixar mais claro.

Esta foi uma introdução. Dependendo dos comentários, talvez eu desça mais alguns degraus para explicar exatamente os mecanismos do que apresentei muito rapidamente aqui.

]]>agilegestaoengenharia-de-softwareoff-topic[Off-Topic] Alguém importante deixou a comunidade! E agora??https://akitaonrails.github.io/2014/07/06/off-topic-alguem-importante-deixou-a-comunidade-e-agora/https://akitaonrails.github.io/2014/07/06/off-topic-alguem-importante-deixou-a-comunidade-e-agora/Sun, 06 Jul 2014 20:38:00 -0300<p>Esta semana um conhecido desenvolvedor da comunidade Node.js declarou estar deixando o barco. Foi <a href="https://medium.com/code-adventures/farewell-node-js-4ba9e7f3e52b"target="_blank" rel="noopener">TJ Holowaychuk</a>, um dos contribuidores mais prolíficos dessa comunidade. Como era de se esperar, a notícia gerou controvérsia, discussão e gente se desesperando.</p> <p>Se você é um programador experiente, não precisa de mim para ouvir isso. Mas se as notícias recentes deixaram você inseguro, talvez o que eu tenho a dizer traga alguma perspectiva.</p> <p>Antes, quero compartilhar outros artigos que li nos últimos dias:</p>Esta semana um conhecido desenvolvedor da comunidade Node.js declarou estar deixando o barco. Foi TJ Holowaychuk, um dos contribuidores mais prolíficos dessa comunidade. Como era de se esperar, a notícia gerou controvérsia, discussão e gente se desesperando.

Se você é um programador experiente, não precisa de mim para ouvir isso. Mas se as notícias recentes deixaram você inseguro, talvez o que eu tenho a dizer traga alguma perspectiva.

Antes, quero compartilhar outros artigos que li nos últimos dias:

  • My Next Chapter: a declaração de Mike Perham, um dos rubistas mais conhecidos desta geração e criador do onipresente e excelente Sidekiq. Ele não abandona o projeto; conta que está tocando um produto novo, e esse produto não envolve Ruby.

  • Saying Goodbye To Python: aqui foi o pythonista Ian Bicking, que declarou trocar Python por JavaScript, seguindo a onda do momento. Vale entender que a bolha atual de JavaScript não “exige” que você “abandone” nada. Dá para ser pythonista e usar JavaScript ao mesmo tempo, sem conflito.

  • Why I Left the .Net Framework: o desenvolvedor Jonathan Oliver resolveu explicar por que está deixando a tecnologia do dia a dia e aponta os prós e contras das ferramentas Microsoft. Nada de trollagem; é uma leitura bem interessante.

  • Java Again: quem é das primeiras gerações da comunidade Java lembra de James Duncan Davidson, criador nada menos que do primeiro Tomcat e do Ant. Ele deixou o Java, passou um tempo na comunidade Ruby e se dedicou à fotografia (procure as fotos das RubyConf de oito anos atrás e vai ver que as oficiais são todas dele). Agora declarou que está voltando ao Java.

  • Why Go Is Not Good: como o nome diz, é uma crítica que argumenta que uma linguagem recém-lançada deveria ter sido melhor pensada para cobrir casos que outras linguagens já resolvem.

  • Rust vs Go: de novo com um certo tom de “dor de cotovelo”. Rust realmente parece uma tecnologia superior a Go em design de linguagem e recursos, e o texto demonstra a frustração de ver Go mais popular mesmo assim.

  • Why Perl Didn’t Win: leitura obrigatória sobre as circunstâncias de uma das linguagens mais populares do fim dos anos 80 ao fim dos anos 90, que caiu no esquecimento e no desuso. Até o Swift, lançado pela Apple semanas atrás, já tem mais usuários ativos que o Perl 6. Uma das conclusões: qualquer coisa nova precisa mirar os problemas do futuro, não os do passado.

Quem é das primeiras gerações das comunidades Ruby e Rails vai lembrar dos “traumas” que passamos:

  • Zed is Not Dead: de 2008, quando um dos nossos desenvolvedores mais prolíficos, Zed Shaw, criador do Mongrel e um dos primeiros a encarar o desafio de medir e otimizar a performance do Ruby, declarou que estava deixando a comunidade e migrando para Python.

  • Bomba: Merb e Rails se fundem!: também de 2008, quando a equipe do Merb estava em rota de colisão com o Core do Rails. A solução, feliz para muitos e infeliz para alguns poucos, foi engolir o Merb dentro do Rails 3, e ela deixou mortos e feridos. Em retrospecto, vale ler “Learning from Rails’ failures”, de Matt Aimonetti (que também migrou para Go) e que está entre os feridos dessa insurgência, e “The Rails/Merb Merge In Retrospect”, de Giles Bowkett (ainda rubista), que analisa os resultados com olhar bem crítico.

  • Twitter muda de Ruby para Java: de 2011, quando o Twitter declarou que estava substituindo as partes da infraestrutura de mensagens escritas em Ruby por uma solução proprietária em Scala. O que a notícia original dizia e o que as pessoas escolheram memorizar são coisas diferentes, mas o fato é que aquilo virou uma bela dor de cabeça de relações públicas para nós. Felizmente já passou.

E esses são só os links que li e lembro de cabeça. Existem dezenas de outros.

Quem ainda é jovem ou inexperiente em comunidades de software, em especial quem é novo no Node.js, deve estar se perguntando: “E agora? Se alguém importante como o TJ diz que está saindo, eu não deveria sair também?” Se fizer sua pesquisa direito, vai ver que não é a primeira vez. Em 2012, o criador do Node.js, Ryan Dahl declarou que continuaria acompanhando o projeto, mas não estaria mais no dia a dia de codificação. “Putz, o mundo acabou!”

Isto não é uma Má Notícia. Esta é uma Excelente Oportunidade! (Sério!)

Em 2006, quando eu estava começando minha militância no mundo Ruby e Rails, eu já sabia o que vinha pela frente. Éramos os novatos, imaturos, com tecnologia incompleta e muita expectativa, então o caminho seria o mais difícil possível. Foi por isso que escrevi o artigo Evolução pela Concorrência.

Muita gente imagina que o melhor dos mundos seria aquele em que ninguém questiona o que você faz, todos deixam você em paz e acreditam nas suas promessas que, claro, você pretende cumprir um dia. (yeah, right…)

Eu discordo. Qualquer promessa ou expectativa que valha a pena precisa ser questionada, pressionada, escrutinada. Se ela é tão frágil que não aguenta crítica, ataque direto e indireto e sabotagem, então a promessa já era fraca e não merecia seguir em frente. Quanto antes cair, melhor, porque menos tempo a gente perde.

Por isso eu sempre abraço os ataques: espero estar pronto para revidar em dobro ou morrer tentando. E não esperaria menos da comunidade Rails. Todo mundo ainda acredita que restrição é ruim, mas eu já disse antes que restrição é importante, porque é o único lugar de onde nasce a inovação.

Quem precisa recorrer ao velho truque de falar mal dos outros, o famoso “não tenho vontade de melhorar, então vou prejudicar o outro para parecer maior” (escrevi sobre isso em 2007, “Para eu ganhar, o outro precisa perder…”), se declara fraco por conta própria. Pare e lembre de artigos, palestras e entrevistas em que você ouviu alguém que admira falando mal de outra comunidade. “Ah, Ruby, aquele negócio de menininha. Porque nós, homens, usamos JavaScript.” Isso me dá vontade de rir e um pouco de pena, porque para mim fica claro que a pessoa sempre vai ser fraca.

Todas as declarações acima, e outras parecidas (“Estou deixando Node”, “Estou deixando .NET”, “Estou deixando Ruby”, “Estou deixando X”), eu honestamente acredito que vieram sem má intenção ou má fé, ao menos não conscientemente. Mas tenho uma teoria. Quem faz declarações assim quer validação dos pares, ou pior, quer que os pares o sigam, o que também é uma validação da própria posição. “Não gosto mais do meu brinquedo velho, mas também não quero que ninguém brinque com ele.” É uma posição bem infantil.

Tomando a comunidade Ruby como exemplo, vários nomes meio que “largaram” suas atividades principais sem bater a porta nem agir com infantilidade. Chad Fowler está na Alemanha tocando o Wunderlist, focado em desenvolvimento mobile e back-end, e não fala mais de Ruby. Ilya Grigorik teve sua startup comprada pelo Google e acabou sumindo também. Matt Aimonetti, depois do episódio Merb vs Rails, se retirou em silêncio e hoje trabalha com Go.

Ryan Bates, um dos mais queridos da comunidade pelo trabalho incansável de anos no RailsCasts, parou de publicar faz meses e não declarou nada a respeito. David Chelimsky, mantenedor do RSpec, passou o bastão adiante e saiu sem alarde. José Valim, um dos principais nomes por trás do Rails 3, hoje está com Elixir e Erlang e raramente comenta algo sobre Ruby.

“O.M.G! Quer dizer que tudo acabou!? Foi pelos ares!?”

Não. Nesse meio-tempo, centenas de novos rubistas surgiram e tocaram o trabalho para a frente. O exemplo mais imediato são Carlos Antônio e Rafael França, que meio que assumiram o manto do José Valim no Rails Core. Evan Phoenix assumiu o manto do Chad Fowler na Ruby Central. Avdi Grimm meio que assumiu o do Ryan Bates com o excelente RubyTapas, e por aí vai.

Uma comunidade é feita de indivíduos, e cada indivíduo rende mais quando age para maximizar o próprio benefício. O efeito colateral disso é que ele acaba influenciando e puxando outros para cima junto com ele. São sempre trocas voluntárias para benefício mútuo. Ninguém age sem nenhum benefício próprio; há quem acredite que sim, e são justamente esses que chegam mais rápido ao “burnout”, porque logo a pergunta vira:

"Por que eu me canso tanto de colaborar nessa comunidade, me estresso, e mesmo assim nem todos apreciam o que eu faço? Eu faço tudo por eles!"

Essa é a pergunta errada, e pergunta errada leva a resposta errada. Alguns começam a achar que os outros lhe devem algo, já que dedicaram tanto do tempo livre (ainda mais no mundo open source) para “ajudar os outros”. E “os outros” acham que não devem nada, porque ninguém pediu esse esforço em primeiro lugar. Na prática, “os outros” estão certos.

Se você participa de uma comunidade, faz isso por você mesmo. Pode ser porque entende que ajudar os outros faz parte da sua recompensa pessoal. Pode ser porque isso traz paz de espírito ou consciência limpa. Ou porque você é bom estrategista e sabe que certas contribuições vão abrir portas lá na frente. O motivo não importa, desde que exista uma recompensa que você não cobra dos outros de forma obrigatória. Cobrar respeito, educação, compaixão, nada disso faz sentido sem contrapartida. Ninguém pediu para você fazer o que faz; se está fazendo, entenda que é por você. Essa é a definição de trabalho voluntário.

E deixando bem claro: trabalho voluntário é trabalho sem remuneração financeira, e não trabalho sem benefício ou puramente altruísta. Se o seu trabalho é remunerado, a conversa é outra, e aí o melhor conselho é o do Don Draper:

Voltando ao assunto, imagino que os nomes que citei, os que se retiraram de forma parcial ou silenciosa, entendem isso. Foram buscar satisfação pessoal em outro lugar. Não devem nada a ninguém, e ninguém deve nada a eles.

Já quem sai com declaração bombástica está, consciente ou não, jogando na cara dos outros: “você não me valorizou, agora perdeu a chance, e eu sei que vai sentir minha falta!” Não está escrito assim, mas é o que faz sentido. Do contrário, por que jogar no ventilador e transformar aquilo em controvérsia pública? Todo argumento por escrito é só parte da razão, nunca “a” razão.

Você, Indivíduo

O outro lado da moeda é quem segue, admira e idolatra uma dessas pessoas que largaram o lugar onde você está. Dependendo do nível de admiração, você fica sem chão, atordoado, sem saber para onde correr. Aí acontece uma de duas coisas: ou você procura outro ídolo e começa o famoso “ele nem era tão bom assim”, ou afunda na depressão e no desespero do “não sei o que vai ser agora”.

Meu conselho: "não tenha ídolos, tenha referências."

Pare de achar que você deve alguma coisa aos outros e, por tabela, pare de jogar nos outros a responsabilidade de ajudar mais gente. É isso que está acontecendo: você não entende o seu propósito e acha que os outros têm que fazer aquilo que você mesmo não faz. Pior, você deixa os outros decidirem o caminho que você vai tomar. Se a insegurança é tão grande assim, pare um instante e reflita sobre o que você “é” antes de tudo.

Seu único propósito na vida é cuidar de si mesmo e produzir, sem atrapalhar o caminho dos outros. Quando você faz isso, o efeito natural é que colaborações espontâneas aparecem, comunidades evoluem e todo mundo sai ganhando. Uma comunidade onde todos cobram todos cresce sem propósito.

Sobre tecnologia, opinião, proposta e promessa, lembre também: você quer estar sob “ataque” e restrição constantes. Não existe nada pior do que ser ignorado. Escrevi outro artigo, tradução de alguém bem mais sábio que eu, a Kathy Sierra, chamado Dilbert e a zona de mediocridade, onde cito:

Quanta coragem você tem? Até onde você (ou seu empregador) iria para evitar a Zona de Mediocridade? A menos que você esteja disposto a arriscar provocar ódio passional, talvez nunca sinta o amor. Scott Adams concorda. Num post recente no blog do Dilbert, ele escreveu: "Se todo mundo que for exposto a um produto gostar dele, o produto não terá sucesso... A razão pela qual um produto que 'todo mundo gosta' vai falhar é que ninguém o 'ama'. A única coisa que prevê sucesso é paixão, mesmo que só 10% dos consumidores a tenham."

E daí se alguém deixou a sua comunidade? Será que ela é tão frágil que uma pancada, não importa o tamanho do impacto, vai fazer tudo desmoronar? Se você acredita que a sua comunidade é apenas resistente, você tem razão: passado certo ponto, ela desmorona. Mas se ela for resiliente, maleável e adaptável, ela sobrevive. É o que garante a sobrevivência das espécies, a Lei do Mais Adaptável (não do mais “forte”; lembre da diferença entre resistente e resiliente, você quer ser o segundo).

Você é adaptável? Ou está só procurando validação dos outros, deixando que eles decidam por você? Uma coisa eu garanto: se um dia eu desistir do que faço, ninguém vai ficar sabendo por um comunicado escrito. Isso eu já tinha decidido no dia em que comecei.

]]>open-sourcefilosofiagestaooff-topic[Off-Topic] Breaking Bad foi uma startup de muito sucessohttps://akitaonrails.github.io/2014/03/28/off-topic-breaking-bad-foi-uma-startup-de-muito-sucesso/https://akitaonrails.github.io/2014/03/28/off-topic-breaking-bad-foi-uma-startup-de-muito-sucesso/Fri, 28 Mar 2014 06:00:00 -0300<p>Publicado pela 1a vez em <a href="http://web.archive.org/web/20150405090805/http://startupi.com.br/2014/03/breaking-bad-foi-uma-startup-de-muito-sucesso/"target="_blank" rel="noopener">2014-03-28T09:00:33+00:00</a></p> <p>Eu escrevi este artigo em inglês logo depois que o último episódio da série foi exibido na TV, em <a href="https://akitaonrails.tumblr.com/post/62925918688/breaking-bad-showed-a-startup-that-was-too-successful"target="_blank" rel="noopener">Outubro de 2013</a>. Como já passaram alguns meses, imagino que todos já tenham tido a oportunidade de assistir tudo. Para mim esta foi uma das melhores séries de TV das últimas décadas. Chega perto do &ldquo;The Sopranos&rdquo;.</p> <p>Não vou revisar cada detalhe da série, já que existem muitos blogs fazendo isso com mais competência do que eu faria. Vou assumir que você já assistiu à série e vou contar partes do final, então vá assistir antes de continuar lendo.</p>Publicado pela 1a vez em 2014-03-28T09:00:33+00:00

Eu escrevi este artigo em inglês logo depois que o último episódio da série foi exibido na TV, em Outubro de 2013. Como já passaram alguns meses, imagino que todos já tenham tido a oportunidade de assistir tudo. Para mim esta foi uma das melhores séries de TV das últimas décadas. Chega perto do “The Sopranos”.

Não vou revisar cada detalhe da série, já que existem muitos blogs fazendo isso com mais competência do que eu faria. Vou assumir que você já assistiu à série e vou contar partes do final, então vá assistir antes de continuar lendo.

As pessoas amam a série e torcem pelo Heisenberg mesmo sabendo que ele comete vários crimes. Pessoalmente, acho que o que prende as pessoas é a história que o autor está contando, muito mais do que os crimes em si.

Esta é a história de uma startup de muito, muito sucesso, a clássica “startup de garagem”, só que dentro de uma van. Walter e Jesse começam com uma ideia, alguns trocados e muito trabalho, cozinhando metanfetamina no meio do deserto. Mesmo com pouco dinheiro e sem recursos, Walt não abre mão da qualidade do produto, e essa é uma marca dos grandes empreendedores. Jesse é a metáfora do empreendedor amador, que largou os estudos e tenta acertar na loteria sem experiência e sem pensar adiante.

Walt

Para mim, toda a ideia de Breaking Bad gira em torno de empreendedorismo. Walt não é só um experiente professor de química, com conhecimento e talento de verdade; é também um grande homem de negócios, e provou isso muitas vezes. Um exemplo está em perceber que, para pontuar alto, crescer organicamente vendendo nas ruas do jeito do Jesse não é o bastante.

Aí entram Gus Fring e a Los Pollos Hermanos, com a explosão nos canais de distribuição. É assim que se escala um negócio. Gus é o “investidor anjo” do Walt, e depois do aporte a pressão só aumenta. Jesse se cansa rápido de trabalhar tanto no laboratório, como todo jovem idealista que ainda não entende o que é trabalho pesado de verdade. Walt, por outro lado, está focado em pontuar alto a qualquer custo.

A série também mostra como negociar com parceiros de quem você não gosta e em quem não confia, num jogo sempre exigente. Quando surge a oportunidade, você não precisa fazer todo o trabalho sujo com as próprias mãos: ponha cachorro grande para comer cachorro grande, jogue o Cartel contra o Gus. E, se tudo der errado, sempre dá para explodir a casa de repouso.

No processo, o que vemos é o amadurecimento do Jesse. Walt foi um grande mentor, e as aventuras o tornaram mais forte. O final também é sobre o Jesse entender o que ele realmente é e talvez se tornar uma pessoa melhor, em termos de autoconhecimento. Agora ele está pronto para se comprometer e sacrificar, em vez de ser só um idealista.

No mundo real, a gente tem que se comprometer e fazer sacrifícios. Vão existir danos colaterais, porque não dá para fazer uma omelete sem quebrar alguns ovos. Nada que valha a pena é fácil, e o processo nunca vai ser bonito.

O final é fantástico porque Walt finalmente admite uma coisa: quem empreende faz isso por si mesmo. Não pela família, não pelos amigos, não pelo bem da humanidade. É para você e só para você. Quem não está fazendo por si mesmo está fazendo errado, e esse é o conceito mais básico do empreendedorismo.

Beneficiar (ou prejudicar) os outros é sempre um efeito colateral de ações feitas com o único objetivo de beneficiar a si mesmo. Enquanto você não faz por você, sempre vai usar os outros como saída fácil, como desculpa. “Deu errado, mas eu fiz com boas intenções.” Boas intenções não importam, resultados importam. Se você faz tudo por você mesmo, a responsabilidade é sempre sua. Sem desculpas.

Ter sucesso vai muito além de glória e fama. Como Breaking Bad mostra, quando o negócio cresce, a concorrência fica mais agressiva, os ataques ficam mais violentos e todo mundo quer o seu pedaço da pizza. Defender o próprio território depende só de você, e nem sempre dá para fazer isso sozinho.

Às vezes você precisa de bons mercenários e sempre de um bom advogado, como Mike Ehrmantraut e Saul Goodman, para cobrir seus passos. São os parceiros de sangue frio que tocam os negócios que você não pode fazer o tempo todo.

Marie representa o que há de pior e mais degradante no mundo: a normalidade medíocre. São pessoas tão presas ao status quo, tão entediadas com a própria existência, que sentem inveja mortal de quem não segue a sua versão minúscula de “verdade”, o tal caminho de “ser normal”. Gente cheia de preconceito e cheia de si, que julga tudo e todos o tempo todo. O melhor a fazer é se manter o mais longe possível desse tipo.

Skyler começa igual à Marie, mas, por estar tão perto do Walt, ela luta contra si mesma. Sofre para sair da caixa, para se acostumar a correr riscos, para pensar de um jeito diferente. Ela passa por todas as fases comuns de transição: negação, raiva, negociação, depressão e aceitação. No final, a gente vê que ela finalmente entendeu.

Breaking Bad

Walt não era o vilão, era um homem fazendo o que sabia fazer de melhor. Alguém que valorizava tanto o próprio trabalho que jamais deixaria nada nem ninguém pará-lo. Isso é “garra”, e é o nível de garra que qualquer um que queira empreender precisa ter. Alcançar o objetivo, custe o que custar.

Walt é o melhor exemplo de empreendedor que existe, muito parecido com o Tony Soprano. A Máfia é o melhor MBA do mundo.

]]>startupsgestaocinema-e-cultura-popoff-topic[Off-Topic] Lean está Morto, longa vida à Eficiênciahttps://akitaonrails.github.io/2014/03/27/off-topic-lean-esta-morto-longa-vida-a-eficiencia/https://akitaonrails.github.io/2014/03/27/off-topic-lean-esta-morto-longa-vida-a-eficiencia/Thu, 27 Mar 2014 15:03:00 -0300<p><strong>Atualização (29/03/14):</strong> Publiquei um post em outubro de 2013 que traz argumentos bem mais detalhados sobre este tema. Leia <a href="http://www.akitaonrails.com/2013/10/30/off-topic-matematica-trolls-haters-e-discussoes-de-internet"target="_blank" rel="noopener">&ldquo;Matemática, Trolls, Haters e Discussões de Internet&rdquo;</a>.</p> <p>O ano era 2001. Um grupo de programadores sêniores se reuniu numa estação de esqui em Snowbird, Utah. Estavam ali os principais nomes da programação nos Estados Unidos: Kent Beck, Alistair Cockburn, Ward Cunningham, Martin Fowler, Jim Highsmith, Ron Jeffries, Brian Marick, Bob Martin, Ken Schwaber, Jeff Sutherland, Andy Hunt, Dave Thomas, Mike Beedle, Arie van Bennekum, James Grenning, Jon Kern, Steve Mellor. Uma lista de &ldquo;quem é quem&rdquo; da área.</p>Atualização (29/03/14): Publiquei um post em outubro de 2013 que traz argumentos bem mais detalhados sobre este tema. Leia “Matemática, Trolls, Haters e Discussões de Internet”.

O ano era 2001. Um grupo de programadores sêniores se reuniu numa estação de esqui em Snowbird, Utah. Estavam ali os principais nomes da programação nos Estados Unidos: Kent Beck, Alistair Cockburn, Ward Cunningham, Martin Fowler, Jim Highsmith, Ron Jeffries, Brian Marick, Bob Martin, Ken Schwaber, Jeff Sutherland, Andy Hunt, Dave Thomas, Mike Beedle, Arie van Bennekum, James Grenning, Jon Kern, Steve Mellor. Uma lista de “quem é quem” da área.

Desse encontro histórico surgiu um manifesto de 4 valores e 12 princípios, que ficou conhecido como o “Manifesto Ágil”.

Treze anos depois, Dave Thomas, autor de “The Pragmatic Programmer” e um dos que mais se envolveram na redação do texto do manifesto, publicou um artigo de desabafo chamado “Agile is Dead, Long Live Agility”.

Karl Popper

A intenção dos agilistas originais era quebrar a forma antiquada de pensar e executar engenharia de software, o mesmo modelo obsoleto que ainda é ensinado hoje na maioria das universidades do país. Isso causou um enorme furor na indústria.

Vieram as derivações, os treinamentos, as ferramentas, as certificações, as conferências, as consultorias. Um portfólio imenso de opções, para qualquer tamanho e a qualquer preço. No meio de todo esse circo, esqueceu-se o que é de fato ser um agilista.

E, como Dave Thomas resumiu bem no seu desabafo, você não “faz” Ágil nem “compra” Ágil. Agilidade é uma qualidade, um adjetivo. Para ser ágil, é preciso voltar aos princípios. Citando:

  • Descubra onde você está.
  • Ande um pequeno passo em direção ao seu objetivo.
  • Ajuste seu entendimento baseado no que aprendeu.
  • Repita

Como fazer isso:

“Quando se deparar com duas ou mais alternativas que entregam mais ou menos o mesmo valor, escolha o caminho que facilite modificações futuras.”

E é só isso: quatro linhas e uma prática.

Treze anos depois que algo tão simples foi publicado pela primeira vez, o mundo parece ter ficado complicado demais. Scrum, Kanban, Scrumban, Lean Programming, Lean Six Sigma, Agile PMI. Num momento em que o caos reina, quem “parece” saber explicar o caos vira guru.

E aí surgem as associações, as certificações, os treinamentos, as conferências. Funciona assim para dietas, funciona assim para terapias, funcionou assim para engenharia de software. É isso que Dave Thomas lamenta.

Mas é um resultado inevitável. As pessoas são fáceis de enganar: procuram sempre alguém ou alguma coisa para seguir e raramente questionam. Foram dogmatizadas a nunca contestar a autoridade e a torcer para times de futebol sem nenhum critério.

Em 2010 estive numa conferência em Baltimore e tive a chance de conversar com Bob Martin, que organizou o encontro em Snowbird. Foi no escritório da Object Mentor dele que aconteceu o primeiro treinamento de certificação Scrum do Ken Schwaber.

Eu já era imune ao “Agile Hype”, mas queria dizer ao Bob Martin o que achava daquilo. Para quem não sabe, o treinamento “oficial” de Scrum Master é um curso de dois dias, e no fim você sai certificado. Nem precisa comparecer: basta pagar pelo curso.

Eu disse a ele, cinicamente, que a ideia do Ken provavelmente saiu pela culatra. “Provavelmente o Ken pensou ‘puxa, como convencer essas grandes corporações a adotar práticas ágeis?’ e aí ele pensou ‘claro, empresas grandes gostam de certificações’, e então criou um Cavalo de Tróia, um curso-piada de 2 dias onde pessoas sérias saberiam que não dá para aprender nada sério em 2 dias mas aí ele poderia inserir a ideia nas empresas. Porém todo mundo levou isso a sério, e é aí que o tiro saiu pela culatra.” Pule direto para o minuto 6:24 do vídeo abaixo se quiser ouvir essa história.

Aprendendo a Aprender

Agora vamos sair um pouco de software e entrar no mundo das “startups”. Esse mundo tem o seu próprio “Agile”, batizado de “Lean Startup”. Eric Ries cunhou o termo em 2008 e o popularizou com o livro de mesmo nome, de 2011, derivado direto dos princípios de Lean da Toyota. É uma reembalagem de ideias antigas.

Esse Lean vem das mesmas ideias de W. Edwards Deming sobre PDCA, “Plan, Do, Check, Act”, ou “Planejar, Fazer, Checar, Agir”. Você vai notar a semelhança com os quatro princípios de Dave Thomas que citei acima.

Não importam nomes pomposos, celebridades, gurus, ferramentas caras nem cargos de destaque. Os princípios básicos de Agile e Lean são os mesmos: entregar valor o mais rápido possível com o menor desperdício possível, aprendendo e usando esse aprendizado no processo, planejando e replanejando para atingir objetivos que ficam mais claros ao longo do caminho. É só isso.

O maior problema aparece quando um programador amador se pergunta “qual o próximo passo?” e a resposta é “o objetivo é montar um Kanban.” Ou quando um empreendedor amador se pergunta “qual o próximo passo?” e a resposta é “o objetivo é montar um Business Canvas.”

Kanban e Business Canvas não são objetivos, são meios. Se esses meios não ajudam a atingir os fins, entregar valor ao cliente e ter lucro no seu empreendimento, então são descartáveis. O objetivo é ter lucro. MVP, protótipo, Lean UX e Business Canvas são apenas caminhos possíveis para chegar lá. Quais deles servem?

Se você quer aprender qualquer coisa, os passos para começar são simples:

  • Não crie ídolos, nunca “idolize” ninguém, pelo menos não a sério.
  • Ignore quase tudo o que você vê ou ouve em grupos. Faça anotações, mas não leve tudo a sério.
  • Ignore conselhos e mentorias. É como um gerente de banco dando dica de investimento: se ele fosse bom de verdade, estaria rico em vez de vender conselho. É vendedor com outro nome.
  • Tudo, absolutamente tudo, começa com poucos princípios. Ninguém vira cirurgião cardíaco querendo cortar a aorta antes de aprender a lavar as mãos. Procure os princípios e ignore os títulos pomposos.
  • Assuma que sabe pouco, sempre. Encare cada assunto com os olhos de um ignorante. Quem acha que já sabe tudo não aprende mais nada. Mas seja um ignorante esperto, não um ignorante idiota.

Aprenda a questionar. Todo o mundo das Ciências, do mundo quântico absolutamente pequeno até o mundo cosmológico infinito e imenso, só existe porque aceita um único princípio: o Método Científico.

Ele é basicamente o PDCA: defina o problema, faça hipóteses, faça experimentos controlados, descarte as hipóteses provadas erradas, repita. Sendo mais exato, o PDCA de Deming é que se inspira diretamente no Método Científico.

Aí está o princípio de tudo. De Agile a Lean a PDCA, voltamos a Karl Popper e à sua filosofia do “Racionalismo Crítico”, que ensina que tudo deve estar aberto à crítica racional.

É por isso que o Lean, enquanto guarda-chuva para vender produtos e serviços de que você não precisa, está morto. Longa vida ao princípio de alcançar valor evitando desperdício com aprendizado contínuo, ou seja, Eficiência. Não existem fórmulas mágicas. Se as dietas mágicas funcionassem, não existiria obesidade no mundo.

Karl Popper

PS: Eu sei, tem #tongueincheek no título e no artigo, mas a intenção, pra variar, é dar uma provocada mesmo ;-)

]]>agilegestaoengenharia-de-softwareoff-topic[Off-Topic] Trabalho Remoto - Small Office, Home Office (SoHo)https://akitaonrails.github.io/2013/11/18/off-topic-trabalho-remoto-small-office-home-office-soho/https://akitaonrails.github.io/2013/11/18/off-topic-trabalho-remoto-small-office-home-office-soho/Mon, 18 Nov 2013 19:11:00 -0200<p><em>Update:</em> Esse assunto é mais complicado, e alguns pontos talvez precisem de mais explicação. Depois vejo se faço um adendo ou um post para complementar. Até lá, se alguém discordou, talvez seja na linha em que o <a href="https://twitter.com/porcelli/status/402555629371678720"target="_blank" rel="noopener">@porcelli também discordou</a> e que tentei explicar pelo Twitter, embora seja mais o caso de concordarmos em concordar do que uma discordância de fato :-) O ponto principal é simples: não sou contra trabalho remoto, muito pelo contrário. O TL;DR é que não acredito que seja a &ldquo;única&rdquo; solução, e a intenção aqui é explorar alguns cenários. Conheço excelentes profissionais que trabalham remoto. Eu mesmo, como digo no artigo, tenho equipes geograficamente separadas, então esse não é o ponto em discussão.</p>Update: Esse assunto é mais complicado, e alguns pontos talvez precisem de mais explicação. Depois vejo se faço um adendo ou um post para complementar. Até lá, se alguém discordou, talvez seja na linha em que o @porcelli também discordou e que tentei explicar pelo Twitter, embora seja mais o caso de concordarmos em concordar do que uma discordância de fato :-) O ponto principal é simples: não sou contra trabalho remoto, muito pelo contrário. O TL;DR é que não acredito que seja a “única” solução, e a intenção aqui é explorar alguns cenários. Conheço excelentes profissionais que trabalham remoto. Eu mesmo, como digo no artigo, tenho equipes geograficamente separadas, então esse não é o ponto em discussão.

Para variar, SoHo é um daqueles assuntos que a maioria de nós pensa só na superfície e decide “é bom” ou “é ruim”. É ruim que a Marissa Mayer proibiu Home Office. É bom que a 37signals está evangelizando Home Office. É ruim que a Microsoft concorda com Home Office, mas com uma possível visão distópica. Vale lembrar que SoHo é um tema que a indústria discute praticamente desde o advento do computador pessoal, em meados dos anos 80. Não tem nada de recente.

Um disclaimer: sou dono de um software shop, uma empresa que oferece serviços de desenvolvimento. O core da empresa são programadores contratados não só em São Paulo, onde moro e tenho clientes, como em Porto Alegre, Fortaleza e Natal. Não pretendo entrar no meu processo neste artigo.

Pensei em dissecar o livro Remote, que é a referência do momento. Mas não há muito o que dissecar. Se você ler o índice, basicamente já sabe tudo o que o livro diz, e o resto é fermento. Veja só:

  • A Hora é Essa para Trabalho Remoto: lista tudo o que já conhecemos como ponto negativo dos grandes escritórios, as reuniões longas, as interrupções, o tempo de locomoção, a qualidade de vida. Sem ler o capítulo já sabemos o que nos incomoda. O problema é que isso é difícil de contra-argumentar, porque qualquer lugar tem coisas que agradam e coisas que desagradam. Listar só o que desagrada não é o mais relevante. Se você namora ou é casado, fez uma lista comparando seu parceiro à Miss Universo ou ao Mister Universo? O que importa é o conjunto que agrada ou o que desagrada?

  • Lidando com Desculpas: de novo, os “argumentos”, a “demagogia”, a “retórica” que se assume serem as desculpas de gerentes e donos de empresa para não permitir trabalho remoto. Metade delas nem sai da boca das empresas; sai dos vendedores de auto-ajuda motivacional, no estilo “trabalhar próximo aumenta a troca de informação e, portanto, a criatividade”. A outra metade são políticas de segurança de dados, atendimento ao cliente, perda de controle. Esses itens são secundários. Como dono de empresa, quase todos são fáceis de lidar e de concordar. A indústria não é tão ruim assim, e nenhum desses pontos passou em branco nas últimas décadas. Ainda há resquícios, sem dúvida, mas compare hoje com 20 anos atrás e verá a diferença.

  • Como Colaborar Remotamente: resume o que já sabemos, que a tecnologia diminuiu as distâncias. Skype/Hangout, Basecamp/Tracker/Asana, Github/Bitbucket, IRC/Campfire. Fora que muitos serviços terceirizados já são remotos. Contador é um bom exemplo, e vou voltar a ele mais adiante, então guarde esse ponto.

  • Cuidado com os Dragões: a única parte que “equilibra” o livro e admite que trabalho remoto nem sempre é um mar de flores. Não se sentir sozinho, não trabalhar mais horas do que deveria, manter hábitos saudáveis. São dicas que valem para o trabalho remoto e para a rotina de qualquer pessoa. Resumindo: tenha bom senso, mas isso você já sabia.

  • Contratando e Mantendo os Melhores: resumindo, e aqui eu concordo, existem profissionais excelentes em todo canto do mundo. É a minha razão para explorar fora de São Paulo. De novo, é fácil evangelizar um argumento sem levar todos os pontos em consideração. Concordo com a ideia e volto a ela mais para frente.

  • Gerenciando Trabalhadores Remotos: mais uma vez, bom senso de gestão. Bons gerentes já sabem disso. Temos multinacionais funcionando em todos os continentes há décadas, e somos bons nisso. Muita gente acredita que as empresas rejeitam o trabalho remoto porque não sabem gerenciar gente à distância. Isso não se sustenta: veja o movimento massivo de outsourcing de serviços para países como a Índia. Como nos jornais, a gente só olha para a má notícia, mas sabemos fazer isso, e tem ficado cada vez mais simples. Terceirizar para indivíduos parece mais complicado do que terceirizar para filiais em outros países, mas no geral o processo é o mesmo.

  • Vida como um Trabalhador Remoto: mais bom senso para qualquer pessoa. Tenha disciplina, monte uma rotina equilibrada, reserve tempo para a família. O único trecho realmente relevante é o último, “garanta que você não está sendo ignorado”. Esse é o meu ponto central para o resto do artigo, então guarde bem.

Concluindo: dos livros que já li da 37signals, este é sem dúvida o mais fraco. Quando ler o índice basta para entender o livro inteiro, a conclusão vem fácil. Isso não significa que ele esteja errado ou seja ruim, mas um post de blog daria conta da mesma mensagem: sim, existem muitas vantagens no trabalho remoto. E, claro, por coincidência eles vendem ferramentas para exatamente o que o livro descreve. É uma excelente peça de self-marketing, e seria burrice não fazer.

A Verdade sobre o Trabalho Remoto

Agora ao outro lado da moeda. No meu artigo recente Matemática, Trolls, Haters e Discussões de Internet tentei passar um conceito simples e importante: fórmula incompleta não serve para nada. Recapitulando, um procedimento, uma metodologia ou um processo só viram “fórmula” quando definem o “domínio” do problema.

Vou assumir que a 37signals argumenta que profissionais de serviços poderiam trabalhar remotamente. Restrinjo à computação porque várias outras áreas simplesmente não funcionam assim, como piloto de avião, bombeiro, médico. O domínio se limita a serviços, nunca produção, e cujo resultado não precisa de mídia física, ou seja, chega pela Internet. Músico, programador, escritor, contador, advogado, arquiteto (em parte). É simples de definir. Para os meus propósitos, fico na área de serviços de desenvolvimento de software.

O maior problema de livros e de pessoas que evangelizam sobre comportamento humano é ignorar a Sociologia, a Psicologia e os campos que já estudaram isso a fundo. O livro Remote é conveniente para o domínio da 37signals e funciona lá. Do jeito que está descrito, funciona só lá. Essa é a primeira pista para separar pesquisa séria de auto-ajuda: “Funcionou para mim, então pode funcionar para você.” É assim que se vende dieta.

Por várias razões, a 37signals deu muito certo como empresa de produtos. Entre elas, as que Zed Shaw explica nesta palestra e o aporte de capital de Jeff Bezos. Ótimo para eles, mas isso quer dizer que o domínio do problema é “empresa de produtos que fatura e lucra muito bem”. E isso já elimina uma fatia enorme do mercado da equação. Se você não conhece os números, estamos falando de um universo bem maior, que no Brasil chegava perto de R$ 37 bilhões. Muito maior do que o universo restrito das tech startups.

Vale entender outra coisa que Getting Real e Remote tentam argumentar, e que poderiam ter simplificado. Estruturas muito centralizadas, com controle top-down forte e pouca ou nenhuma valorização da equipe, costumam ser lugares ruins de trabalhar. A conclusão precipitada é que a descentralização completa seria a melhor forma. Pior ainda é imaginar a 37signals como uma empresa descentralizada só porque todos são remotos e não há uma hierarquia dura. Na prática ela é centralizada, com níveis intermediários de descentralização.

Jason Fried, DHH no centro

Dá a impressão de organização descentralizada porque usa processos de open source na execução. Mas a cadeia de comando é claramente centralizada em Jason Fried e David Hansson. Não há problema nenhum nisso, e é assim que deve ser mesmo.

Com isso em mente, quero mostrar um gráfico que tirei de uma aula do Nicholas Christakis. Ele cita um estudo sobre os shows da Broadway. Alguns fazem muito sucesso, outros são fracasso de bilheteria, e os pesquisadores queriam saber se havia correlação entre o tipo de rede social da organização do show e a taxa de sucesso.

Imagine no eixo X a densidade de relacionamentos entre os profissionais da equipe. 0 é a rede altamente centralizada, onde as pessoas nas pontas nem se falam; 100 é a rede altamente descentralizada, onde qualquer um fala com qualquer um. O nível 0 a intuição já entrega como ruim, e a correlação confirma: aparece nos shows que fracassaram. O contraintuitivo é que as redes totalmente descentralizadas fracassam na mesma medida. Os shows de sucesso estão nas redes intermediárias, com um pouco de descentralização e um pouco de centralização.

O sucesso está no meio

A da 37signals não é totalmente centralizada, já que os programadores remotos conversam por chat, via Github e afins. E não é totalmente descentralizada, porque existe algum nível de especialização e, claro, um comando estratégico central.

Estou testando cenários diferentes, e o primeiro passo, no meu caso, começa com este outro diagrama:

Codeminer 42

Mas, como falei, não vou desviar do assunto principal aqui. Fica só a dica.

O Problema da Carreira

Repito que definir o domínio importa porque, no caso da 37signals, dá para aumentar o salário das pessoas quase indefinidamente. O produto já atingiu uma escala em que o faturamento é ordens de grandeza maior que custos e despesas. Ora, se dá para bancar corridas em Le Mans, dá para pagar 5 ou 6 dígitos aos programadores.

Continuando a evoluir o produto, criando novos produtos com cuidado, mantendo os clientes antigos satisfeitos e fazendo bom marketing para atrair novos, enfim, o que uma boa empresa deve fazer, é possível seguir crescendo por um bom tempo.

Só que empresa de produtos assim não é comum. Na verdade é o caso mais raro da indústria, e as mesmas regras não valem para empresas de serviço, que são a maioria. E o motivo é estrutural, ligado aos fundamentos da indústria.

Daí vem o raciocínio: “Por isso não vale abrir empresa de serviços, melhor ir direto para produtos.” Minha resposta é simples: “boa sorte”. A premissa óbvia é que empresa de produtos dá certo na hora. Já discuti isso no artigo anterior Tech Startups, superlotação de B2C. Boring..

“Ah, é só seguir Lean Startup, processos Ágeis, Business Canvas” e todo o pacotinho que vendem hoje, com instruções que qualquer criança segue e pilha inclusa, e boom, sucesso automático… alguém acredita mesmo nessa bobagem?

Agora de volta à realidade. O maior problema de contratar programador home office é de Recursos Humanos e de gestão de carreira, não só de controle. Estamos chegando a um nível de maturidade em desenvolvimento de software em que programar com boas práticas, boa tecnologia, eficiência, previsibilidade e facilidade de manutenção deixou de ser Premium e virou o normal. Não vou oferecer um programador mais barato a um cliente por ele ter qualidade baixa. Quero que meu júnior vire pleno rápido, que o cliente tenha o mesmo nível técnico independentemente de quem faça, e que a qualidade fique sempre acima da média, porque a média da indústria ainda está abaixo da linha da pobreza.

Só que, se isso é o normal, como uma empresa dá aumento a programador? Até certo ponto a capacidade técnica faz muita diferença. Mas casos de tecnologia altíssima e ainda experimental, em que pouca gente sabe o que fazer, são raros, tanto em serviços quanto em produtos. O resto se comoditiza rápido. O mundo open source quase garante que, resolvido um problema difícil, ele se replica em pouco tempo. Se um dia foi “complicado” fazer um front-end web responsivo e minimamente bonito, um Foundation ou um Bootstrap já eliminaram boa parte dessa curva.

Esse é o núcleo da questão: só programar é pouco para 90% dos projetos de software. Já discuti em outro artigo, Estimativas são Promessas. Promessas devem ser cumpridas., que a coisa mais difícil na carreira de um Engenheiro de Software é entender que boa parte de um projeto de software não se resolve com software. O profissional “sênior” se define menos pelo código bonito e mais por saber gerenciar as expectativas do cliente, seja ele corporativo ou consumidor, e por assumir responsabilidade.

De novo, não vou me prender às exceções, como centros de pesquisa ou produtos consolidados. Dentro de um grupo, emergem propriedades que só existem dentro de um grupo. (Veja de novo a palestra do Christakis, ou outros como Duncan Watts, para começar a entender essas propriedades.) São atividades que costumam não acontecer sozinho: treinamento peer-to-peer, em que o júnior aprende com alguém mais sênior, e o exercício de comunicação, negociação, responsabilidade e trabalho em equipe.

Tudo isso é possível remoto, só que bem mais devagar e bem menos óbvio, porque cada indivíduo fica de fato isolado. Um cluster geográfico também influencia o mercado e a comunidade local ao redor, então ele não se restringe ao grupo primário: grupos secundários emergem. E cada cluster se relaciona como o próprio Remote descreve, com ferramentas online e viagens presenciais de vez em quando.

Na prática, quanto mais produtivo e eficiente um bom desenvolvedor sênior é em relação a um júnior? Dez vezes, se muito? Ou seja, se um júnior ganha 1000, um sênior ganha no máximo 10.000? E depois disso? Agora, um bom profissional que treina, orienta e se auto-escala de 1 para 3 já subiu ordens de grandeza. Ele chega fácil a 20.000 ou mais por esse caminho. Faça isso em clusters e logo você tem uma rede mais resiliente.

Não estou dizendo que mentoria só rola presencialmente, mas quem consegue fazer isso remoto ainda é a exceção, não a regra. A gente contrata quem tem pouca experiência ou saiu há pouco da faculdade, e mentorar essa pessoa à distância, embora não seja impossível, é complicado. No fim, sempre depende da pessoa.

Então um indivíduo trabalhando remoto está errado? Claro que não. Esse é outro problema desse tipo de argumentação: faz parecer que só existem dois caminhos. Como em tudo na sociologia, há vários cenários para várias configurações. O que as evidências apontam como mais ineficiente são justamente os dois extremos, o totalmente centralizado e o totalmente descentralizado. No intervalo entre eles mora uma série de oportunidades diferentes.

Conclusão

Então sim, não há nada de errado no que está no Remote. O erro é tratá-lo como a única solução. Eu poderia contratar indivíduos isolados em home office sem problema nenhum. Só que ainda não consigo imaginar como fazê-los evoluir, expô-los a mais do que codificar, e dificilmente conseguiria delegar responsabilidade além do código. A grande vantagem de atuar no mercado de serviços é ter acesso a mais empresas e mais situações do que qualquer funcionário de uma só empresa ou de um único produto teria. Remoto e isolado, sobram pouquíssimas dessas oportunidades.

E, de novo, existem exceções: grandes nomes do mundo open source que trabalham como freelancers, sozinhos, muito bem, com reputação só crescendo. Devolvo com a pergunta: isso é a regra ou a exceção? Exceção existe, e, se der, é melhor ser a exceção. Mas evangelizar o caminho da exceção o tempo todo é muita irresponsabilidade.

Trabalhar de casa é uma experiência que vale a pena. De maneira nenhuma ela é obrigatoriamente melhor do que trabalhar dentro de um grupo, mesmo contando o “tempo perdido” na locomoção, que, aliás, é uma péssima desculpa. Muito depende de a sua região ter opções. Se elas são escassas, aí o remoto vira uma boa alternativa. Só considere que sempre há prós e contras.

]]>carreiragestaooff-topic[Off-Topic] Agile feito Erradohttps://akitaonrails.github.io/2013/11/01/off-topic-agile-feito-errado/https://akitaonrails.github.io/2013/11/01/off-topic-agile-feito-errado/Fri, 01 Nov 2013 10:48:00 -0200<p>Uma das coisas mais comuns que já vi em inúmeras empresas é adotar alguma metodologia na esperança de que isso melhore as coisas. Invariavelmente não muda nada e às vezes piora. Já repeti isso inúmeras vezes e repito de novo: Agile não é uma bala de prata, e nenhuma receita mágica conserta maus profissionais. Maus profissionais não têm conserto.</p> <p>Vale a distinção. Um profissional júnior, que ainda tem deficiências técnicas e vontade de crescer, aprende técnicas, práticas e ferramentas, e ganha qualidade técnica, produtividade e eficiência. Um mau profissional, que até pode ter alguma capacidade técnica, está mais interessado em pouco trabalho, pouco esforço e pouca responsabilidade, e chega a ser mal caráter na conduta e na atitude. Esse não muda.</p>Uma das coisas mais comuns que já vi em inúmeras empresas é adotar alguma metodologia na esperança de que isso melhore as coisas. Invariavelmente não muda nada e às vezes piora. Já repeti isso inúmeras vezes e repito de novo: Agile não é uma bala de prata, e nenhuma receita mágica conserta maus profissionais. Maus profissionais não têm conserto.

Vale a distinção. Um profissional júnior, que ainda tem deficiências técnicas e vontade de crescer, aprende técnicas, práticas e ferramentas, e ganha qualidade técnica, produtividade e eficiência. Um mau profissional, que até pode ter alguma capacidade técnica, está mais interessado em pouco trabalho, pouco esforço e pouca responsabilidade, e chega a ser mal caráter na conduta e na atitude. Esse não muda.

Agile é mais uma fórmula cuja imagem (resultado) é a promessa de hiper-produtividade que pode chegar a 500% do atual. Novamente, qual o Domínio (as premissas)?

A premissa mais básica para Agile é que a equipe tenha capacidade técnica e comprometimento. Isso nenhuma metodologia ensina ou muda. Cada indivíduo da equipe é uma pessoa capaz ou simplesmente não vai funcionar. Código bem feito, bem organizado, seguindo as boas práticas conhecidas, com testes e disciplina, é o mínimo para começar, o arroz com feijão.

Se isso não existir, desista. Nenhuma metodologia, nem macumba, nem exorcismo, nem feng shui vão ajudar. Colocar Scrum, práticas de XP, Kanban ou qualquer outra coisa numa equipe ruim, com liderança fraca, produz algumas das seguintes prostituições das boas práticas:

Planning para Inglês ver

Um bom planning só é possível se o Product Owner se dedicar a manter um backlog priorizado e bem definido. E entenda: a definição das User Stories deve estar pronta antes do Sprint Planning. Uma User Story vaga, mal definida, não ajuda em nada.

Enquanto a equipe trabalha no Sprint, o PO define as próximas User Stories, e pode chamar um ou mais membros da própria equipe ou de equipes paralelas para ajudar. No Sprint Planning tudo já deve estar bem definido, de preferência pré-pontuado e priorizado. A equipe apenas pontua o Sprint e, de acordo com a Velocidade atual, vê o que cabe no próximo. Uma reunião bem feita dura 1 ou 2 horas no máximo.

Sintomas: se demorar mais que 2 horas, tiver pessoas demais só para fazer quórum, User Stories mal definidas que geram discussões intermináveis e nenhuma ação, você está fazendo errado.

Pair Programming para Inglês ver

Pair Programming é uma prática muito boa, e a equipe decide como praticá-la. Só que você pode encontrar um membro que quase nunca programa bem sozinho e, ao fazer o “pair”, vira mais ouvinte do que participante. É o famoso “peso morto”. Fica só dando pitaco, ou fica em silêncio jogando Candy Crush e navegando no Facebook. Não tem valor algum.

Sintomas: isso é mais fácil de acontecer em equipes muito grandes (acima de 6), pois fica mais fácil se “esconder” fazendo pair-fake com diferentes pessoas. Aliás, eu nunca recomendo mais do que 4 pessoas numa equipe ágil. Mesmo sendo um único produto, se tiver 15 pessoas, por exemplo, melhor dividir em 3 equipes de 5. Melhor ainda se as pessoas rotacionarem nessas equipes para que não se criem “panelas” onde um ruim protege o outro ruim.

Protecionismo Departamental

Programadores profissionais hoje precisam ser multi-funcionais, polivalentes. Obviamente cada um tem um tipo de capacidade melhor do que a outra. Por exemplo, o que chamaríamos de um “front-end” deve ser o mestre do HTML 5, CSS 3, Javascript, mas também deve saber o mínimo de Rails, Node.js, Python ou o que for o back-end para conseguir organizar os templates e integrar com controllers, models, helpers, etc. E os “back-ends” também devem minimamente saber HTML, e mesmo infraestrutura.

Pontuação de User Stories (seja em Story Points, Working Hours, etc) deve ser sempre a mesma não importa quem puxe a User Story. Não existe isso de: “essas 3 stories são minhas, essas 2 são do Fulano, essas 4 são do Ciclano”. As stories são priorizadas e cada um vai puxando uma story de cada vez à medida que termina a anterior.

Sintomas: stories que são pontuadas diferente dependendo da pessoa que vai pegar, ou stories “reservadas”, ou tipos de stories que só um “tipo” de profissional pode pegar. Não existe isso de “esta story é de infra, só um cara de infra deve poder pegar, e o cara de back não deveria estar olhando pra ela”. Sprints são responsabilidade da equipe toda.

Uma das vantagens de pair programming e equipes pequenas é cada um aprender novas capacidades com os outros. Um back pode puxar uma Story que tem alguma coisa de front, mesmo sem ser o melhor de front, e nada impede de pedir pair com um bom front da equipe na hora que precisar. Uma User Story pode demorar 2 horas se for feita por um bom back, mas pode levar 5 horas se feita por um front.

O correto é o cara de front se aproximar das 2 horas, e não reservar a story. O correto é a velocidade da equipe aumentar gradativamente, e para isso a velocidade individual de cada membro também precisa aumentar. E para isso ele deve constantemente aprender novas capacidades. É assim que todos evoluem. Reservar stories é o melhor exemplo de batedor-de-ponto querendo ‘proteger’ seu emprego e esconder sua mediocridade.

Qualidade para Inglês ver

Todos os membros da equipe devem estar preocupados tanto com a qualidade técnica do código quanto com a qualidade funcional, ou seja, se a funcionalidade realmente se comporta da forma correta com os usuários finais. Muitas vezes existem equipes que alocam pessoas com o objetivo único de ser um “Q&A” (Quality Assurance), que se responsabiliza de montar casos de teste, automatizar testes de integração, alinhar com o PO e com analistas de negócios, marketing, etc.

Vou dizer que pessoalmente não gosto dessa distinção, mas confesso que em alguns casos faz muito sentido. Só que isso deve ser feito de forma que não se retire da equipe a responsabilidade de entregar funcionalidades que de fato funcionam. Não pode existir a sensação de “foda-se se tiver bugs, depois o Q&A pega”. Mas é isso que acontece muitas vezes.

Sintoma: procure User Stories que são entregues, depois rejeitadas, depois refeitas, depois rejeitadas de novo, e ficam assim por muito tempo. Uma User Story que fica 1 mês sem ser aceita é um absurdo monstruoso, uma abominação. Pior ainda se existirem membros da equipe que, quando você olha o backlog passado, estão sempre envolvidos em stories que sempre são rejeitadas e sempre demoram dias para serem aceitas. É o típico caso do profissional que mantém o emprego resolvendo problemas que ele mesmo criou. Remova essas maçãs podres da equipe o quanto antes, porque contaminam o pote todo muito rapidamente.

Desculpas, Desculpas, Desculpas

“Não deu pra fazer porque faltou teste, mas o cara que faz teste estava sobrecarregado então travei.”

“Não deu pra fazer porque tinha um obstáculo na outra equipe que não resolveram, então travei.”

“Não deu pra fazer porque estava mal especificado, mandei um e-mail pra tirar a dúvida, ninguém respondeu, então travei.”

Um bom profissional dá soluções, não aponta culpados nem fica procurando desculpas para justificar a própria incompetência. Significa que ninguém pode reclamar? Claro que não. Sempre existem problemas difíceis de resolver, e as pessoas podem e devem procurar ajuda quando necessário.

Sintomas: é fácil identificar o procrastinador profissional. O sujeito nunca está na mesa dele, passa mais tempo conversando no café do que trabalhando. Chega tarde todo dia, sai cedo todo dia. Quando está na mesa, você olha e o infeliz está no YouTube ou no Hacker News.

E que fique bem claro: nenhuma dessas atividades, isolada, é um problema. Até eu dou uma pausa e fico no Facebook. Só que quem age assim constantemente, rotineiramente, está de palhaçada. Pior: se no fim do dia a tarefa dele estivesse pronta, com código bem feito e sem bugs, eu não reclamaria. Normalmente não está. A tarefa fica incompleta, o código mal feito, sempre precisando ser refeito, e o sujeito aparece com desculpas parecidas com as de cima.

Isso é ser mal caráter, é atitude de criminoso. Ele está deliberadamente roubando a empresa: o salário está sendo pago e o valor não está sendo entregue. É um ladrão.

Um bom profissional, que trabalha sério, não espera ser cobrado para dizer “ah, eu perguntei, ninguém respondeu, então não fiz”. Quando encontra um obstáculo, corre atrás do problema. Dúvida técnica, pergunta aos colegas do lado (pessoalmente, e-mail, chat, gtalk). Problema funcional, procura o PO direto. Problema departamental, levanta da cadeira e vai até a outra equipe tirar a dúvida. Se a tarefa depende de um terceiro que não colaborou, vai direto ao chefe resolver.

O sintoma básico do mau profissional é o oposto: ele não vai atrás. Fica contente quando encontra o obstáculo, porque daqui a uma semana, só na próxima reunião de Review, vai dizer “puuuuuts, eu até tentei, mas o Fulano não colaborou, então não deu”. Tá de brincadeira.

Conclusão

Se sua equipe tiver apenas 1 dos problemas descritos acima, já é uma catástrofe. Se tiver mais de um, é um problema de intervenção militar, nível Iraque. Mais do que isso, só uma bomba nuclear para resolver. E pior ainda, alguém que apresenta todos os maus comportamentos descritos acima é um sociopata criminoso. Não adianta dar bronca, não adianta tentar consertar: não tem conserto… mas tem solução: trocar as maçãs podres o quanto antes.

E novamente, para ficar claro, é óbvio que existem todos os tipos de maus profissionais, e não estou falando somente de programadores. Existem maus gerentes, maus analistas, maus coordenadores, maus supervisores, maus diretores, etc. Isso vale para todo mundo.

Se você é um programador e está vendo tudo isso, corra atrás. Se o problema for na diretoria, sinto dizer que não há o que fazer. Agora, se você é um gerente, um supervisor, alguém em cargo de autoridade, e não está tomando nenhuma atitude sabendo de tudo isso: se demita, você está fazendo muito errado e sendo conivente com um ambiente cuja cultura é o mau-caratismo.

Aplicar ‘algumas’ práticas Ágeis, interpretadas da maneira errada, não é ser Ágil, é se enganar. É como uma dieta nutricional. Durante o dia você segue a dieta à risca, mas quando ninguém está olhando come chocolate e doces, e no dia seguinte fala “puts, não sei porque essa dieta não funciona, estou seguindo direitinho, acho que a dieta não presta, vamos tentar outra.” #lamentavel

]]>agileengenharia-de-softwaregestaooff-topic[Off-Topic] Desmontando o #noEstimateshttps://akitaonrails.github.io/2013/10/07/off-topic-desmontando-o-noestimates/https://akitaonrails.github.io/2013/10/07/off-topic-desmontando-o-noestimates/Mon, 07 Oct 2013 11:35:00 -0300<p><strong>Update:</strong> Esqueci de mencionar uma coisa. Se você não quis ler tudo isso, ou discorda por completo, faça a si mesmo a seguinte pergunta. Você não quer prazos, então está disposto a abrir mão do prazo do seu salário também? Por que você não consegue estimar o que vai entregar e, mesmo assim, seu cliente tem que pagar?</p> <p>Vamos deixar isso parelho: você adota #noEstimates se, e somente se, estiver disposto a adotar #noSalary. Seu empregador segura o seu pagamento até você entregar, e nesse cenário o valor precisa ser depreciado quanto mais tempo demorar. A CLT não permite isso, infelizmente. Mas seria um cenário interessante.</p>Update: Esqueci de mencionar uma coisa. Se você não quis ler tudo isso, ou discorda por completo, faça a si mesmo a seguinte pergunta. Você não quer prazos, então está disposto a abrir mão do prazo do seu salário também? Por que você não consegue estimar o que vai entregar e, mesmo assim, seu cliente tem que pagar?

Vamos deixar isso parelho: você adota #noEstimates se, e somente se, estiver disposto a adotar #noSalary. Seu empregador segura o seu pagamento até você entregar, e nesse cenário o valor precisa ser depreciado quanto mais tempo demorar. A CLT não permite isso, infelizmente. Mas seria um cenário interessante.

Tem muita gente falando sobre #noEstimates ultimamente. Já li boa parte dos argumentos a favor, e qualquer um pode fazer uma busca rápida no Google, então não vou ficar referenciando cada um. A essência é a seguinte: estimativas nunca vão ser boas o bastante, e quanto mais especificação e planejamento você faz, menos a qualidade delas parece melhorar. Num mercado dinâmico as especificações mudam o tempo todo, e quanto maior o esforço de estimativa, maior o desperdício. Se estimativa é tanto desperdício assim, por que não jogar tudo fora de uma vez?

Soa como uma ideia nobre, especialmente para desenvolvedores de software. Software é maleável, é abstrato, e parece simplesmente não caber nas noções tradicionais de gerenciamento de projeto. E já que estamos nessa, por que não jogar fora a ideia inteira de projetos também? Foi assim que surgiu outra moda, o #noProjects.

Minha intenção aqui não é responder a cada argumento, e esse nem é o ponto. O que vou fazer é explicar por que a ideia toda é absurda já na origem. Então vamos começar pelo básico.

Uma coisa que eu defendo desde pelo menos 2008 é olhar o gerenciamento de projetos e os mercados em geral pelos modelos de Sistemas Adaptativos Complexos, Teoria do Caos e Biologia Evolutiva. Fui muito influenciado pelas ideias de Nassim Nicholas Taleb e seu magnum opus “A Lógica do Cisne Negro”. A ideia é incrível: os mercados são movidos por agentes caóticos que influenciam um sistema complexo, longe de qualquer caminho linear.

Todas as empresas são gerenciadas para lidar com médias, com sigmas limitados como margem de erro operacional. Mas quando algo grande acontece, um “Cisne Negro” como a crise econômica de 2008, a maioria não está preparada. Nenhum modelo consegue prever, e o sistema inteiro trava e desaba.

Se você não conhece a ideia, dá uma googlada rápida e vai perceber que empresas, mercados e relações entre pessoas são sistemas dinâmicos que obedecem às regras da biologia evolutiva. Sistemas descentralizados parecem ser o caminho, e esses conceitos influenciam vários dos movimentos Lean que vemos hoje. Então, sim, eu estou bem ciente desses efeitos.

Resumindo, quem tem mais chance de sobreviver num sistema complexo desses são os mais adaptáveis, muito mais do que os que se prendem rigidamente a planos. Cumprir planos de longo prazo com rigidez é o jeito mais fácil de cair quando os Cisnes Negros aparecem.

Isso me levou a outro conceito: a Teoria da Relatividade Geral de Einstein. Na cosmologia moderna, ela substituiu a Teoria de Newton. Quando aprendi isso, meu primeiro pensamento foi: se Newton está “errado”, por que não usamos a Relatividade para calcular tudo no dia a dia?

A resposta é que Newton só está “errado” se você exigir dele calcular qualquer coisa. Ele não se aplica ao muito muito grande, ao cálculo gravitacional, a cálculos no nível de galáxias. Mas em tamanhos da Terra, calculando a trajetória de um avião ou de uma bala, ele continua valendo, porque as margens de erro são desprezíveis. No dia a dia dá para reduzir o problema a Newton e deixar a Relatividade Geral de lado. É uma simplificação grosseira, claro, mas me acompanhe.

O mesmo se aplica às empresas. Estamos todos sujeitos a distribuições de Lei de Potência, à Biologia Evolutiva e às forças implacáveis do Caos que fazem tudo se comportar como Sistemas Adaptativos Complexos. Mas num ambiente restrito eu vou argumentar que dá para reduzir o cálculo de volta para Curvas de Sino. Essa é a parte mais difícil de “provar”, então não vou tentar agora, mas a explicação a seguir talvez te leve até lá.

Vamos definir o que é uma empresa: um conjunto de operações. Operações são atividades repetitivas, como “pagar um fornecedor”, “enviar um pedido de compra”, “processar a folha de pagamento” ou “transportar produtos”. O conjunto dessas atividades define o que uma empresa é.

A ideia central de uma empresa é executar essas operações da forma mais eficiente possível. Você faz isso refinando o processo continuamente, em pequenos passos, ou através de um breakthrough que muda totalmente a forma de fazer uma operação específica.

Um exemplo: antigamente havia grupos inteiros de pessoas dedicadas a preencher formulários de papel e organizá-los para a informação fluir dentro da empresa. Com o surgimento dos sistemas digitais, dos ERPs, essa papelada toda deixou de ser necessária. Eliminamos uma profissão inteira de digitadores e agregamos eficiência e precisão ao sistema. Breakthroughs costumam ser a automação digital de trabalho manual, ou a eliminação completa de um processo.

Para alcançar esses breakthroughs existem os Projetos. Projetos são empreitadas temporárias, onde um grupo de pessoas se concentra para atingir um objetivo pré-estabelecido. Costumam ter data fixa de início e de entrega, orçamento fixo e quantidade fixa de pessoas envolvidas.

E aqui chegamos na parte da Estimativa. Todo projeto quer atingir algum objetivo, e no caso de um projeto de software escrevemos código para chegar lá. Para isso, criamos features e as quebramos em Casos de Uso, User Stories, Requisitos ou qualquer artefato que descreva o que precisa ser construído. Depois estimamos quanto recurso (tempo, dinheiro, pessoas) é necessário para implementar cada peça e integrá-las numa “solução” que resolve o problema.

A reclamação dos desenvolvedores é que não dá para estimar essas peças com precisão, e que projetos sempre vão sair atrasados e estourando o orçamento. Daí a ideia de não estimar nada, simplesmente começar a codar, entregar valor o mais rápido possível e considerar pronto só quando estiver pronto.

Alguns desenvolvedores ficam tão de saco cheio dessa noção que querem largar suas empresas para abrir suas próprias startups, onde vão poder fazer o que quiserem sem nenhum controle. Aí saem atrás de investidores, porque precisam de muito dinheiro e muito tempo. Claro que precisam. O que eles não percebem é que TODO MUNDO precisa de muito dinheiro e muito tempo.

E os investidores sabem disso: a ideia é irrelevante, execução é que é tudo. Quem merece mais dinheiro e mais tempo são exatamente os que conseguem se pressionar para entregar abaixo do orçamento e na frente de todo mundo. Fazer alguma coisa sem se preocupar com restrições é o reino do medíocre. E medíocre não merece nada.

Voltando ao básico: existe uma coisa chamada Economia justamente porque os recursos não são infinitos. Tudo que tem valor tem preço, seja um produto físico ou horas trabalhadas.

Entenda o seguinte: no negócio de serviços, onde nós desenvolvedores estamos todos, seja como empregado, seja como co-fundador, valor tem só duas variáveis, qualidade e eficiência. A gente costuma enxergar qualidade como a única coisa que importa. Pior: costuma enxergar aquilo que nós achamos que é qualidade como a única coisa que importa.

Isso nos traz de volta ao CONTEXTO. A maioria dos programadores é ruim de estimativa, e a raiz disso é que eles costumam ser absolutamente incompetentes em entender contexto. Como alguém com formação em Matemática, eu leio todos esses artigos sobre processos, metodologias e coisas como “#noEstimates” como se fossem “fórmulas”.

Fórmulas sozinhas não significam nada. Qualquer matemático sabe que você precisa definir um Domínio e uma Imagem, a origem e o destino de todas as entradas e saídas. Se eu mostro uma fórmula como “f(x) = 1 / x”, você pode dizer que ela é inválida, porque não dá para dividir quando x é zero. Mas se eu disser que o Domínio é todo número Natural exceto o zero, agora ela é uma fórmula totalmente válida para a Imagem dos Racionais.

Então, quando alguém fala “#noEstimates”, a pergunta natural é: em qual Domínio e para qual Imagem? Essa é a origem da confusão na maior parte das discussões na Internet. As pessoas argumentam a favor ou contra uma ideia porque cada uma está num Domínio diferente. Vale para Agile em geral, Lean Startups, Lean Manufacturing e por aí vai: costumam definir só práticas, procedimentos, fórmulas, mas raramente definem Domínio e Imagem. Isso gera confusão e perde o ponto.

O que eu vou definir é o seguinte: Projetos são necessários toda vez que existe um objetivo definido a ser atingido. Esse é o domínio. E vou afirmar também que quem fala “#noEstimates” está pensando no Domínio de “Operações Contínuas”, enquanto Projetos são um Domínio à parte. É justamente aí que o Lean Manufacturing em geral também se encaixa.

Já expliquei Operações acima, e é onde os pequenos passos de melhoria (Kaizen) emergem. Às vezes o feedback de uma operação dá insumo suficiente para justificar um Projeto e dar um passo maior, um breakthrough.

Projetos, por outro lado, continuam sendo empreitadas temporárias. A ideia toda é estabelecer fronteiras, como restrições de tempo e custo. E voltamos à pergunta original: é impossível prever os esforços necessários para algo tão maleável quanto desenvolvimento de software?

Antes de mais nada, sim, é impossível prever com precisão exata. Vamos definir de novo: é impossível prever um número com margem zero de erro. Estimativa é previsão com margem de erro. E por que alguns projetos custam mais que o dobro e demoram mais que o dobro do que foi estimado?

Na maior parte das vezes, em 90% dos casos, porque o time é incompetente. O problema não é a estimativa, é a execução. Estimativa é o estabelecimento de uma expectativa, e expectativas precisam ser gerenciadas. Uma estimativa só é boa se o contexto for levado em conta.

A maioria não gosta de estimar por causa dos cenários “e se”. E se o cliente mudar de ideia? E se a gente esbarrar num obstáculo difícil? E se um meteoro atingir a Terra e todas as criaturas vivas perecerem? “E se” não dá para gerenciar; o que dá para gerenciar é o que você sabe, criando restrições. As restrições de um projeto começam pelo objetivo. Para atingir esse objetivo, também estabelecemos as regras de engajamento, as premissas. Sem objetivos e sem premissas, não tem jogo.

Nada disso garante uma Previsão. Uma estimativa é tão boa quanto a execução. Agora a gente tem que gerenciar, e todo mundo tem que gerenciar.

De nada adianta definir regras claras e de repente ver um programador parado. Você pergunta por que ele está parado, e a resposta é “ah, porque eu mandei email pro cliente sobre uns requisitos e ele nunca respondeu, então fiquei esperando”. Você pergunta “e você tentou ligar pra ele?”, e a resposta costuma ser “Não, não tentei”. Não existe quantidade de processo ou metodologia que “conserte” um funcionário incompetente. Falta de habilidade técnica dá para consertar. Má-fé não.

Os defensores do #noEstimates podem argumentar que eles não são assim, e eu acredito. Mas 90% dos projetos que fracassaram tinham funcionários assim. Programadores tendem a colocar a culpa no cliente, nos chefes, no mercado, mas nunca em si mesmos. E como programador eu vou argumentar: a maioria dos projetos fracassa por causa de funcionários preguiçosos, muito mais do que por mudança de requisitos ou tempo limitado. Quer fazer projetos darem certo? Comece pelos Recursos Humanos, depois vá atrás de metodologia e práticas.

O problema das metodologias que não declaram o Domínio sob o qual suas fórmulas funcionam é que a maioria não percebe onde esse Domínio começa: em “ter funcionários competentes, comprometidos e habilidosos”. A maioria adota metodologias na esperança de transformar funcionários incompetentes em competentes, e isso simplesmente não acontece.

Resolvido isso, por que precisamos de estimativas? Ou, de forma mais geral, por que precisamos de restrições? Porque essa é a essência do valor de qualquer sistema. A natureza pressiona toda espécie viva: clima mudando, comida limitada, predadores. As espécies mais adaptáveis evoluem, e as que não conseguem se adaptar perecem.

Quando alguém fala “é impossível fazer X”, esse é provavelmente o objetivo mais valioso a perseguir. Porque a frase completa é “é impossível fazer X com o que sabemos hoje”. Era impossível dar a volta no globo em 24 horas, hoje não é mais. Era impossível se comunicar com o outro lado do mundo em tempo real, hoje não é mais.

Restrições são a base da inovação. Se eu tivesse que definir inovação, diria que “é o processo pelo qual você realiza algo que antes era considerado impossível”.

Se você tem recursos infinitos, ou simplesmente não precisa se preocupar com restrições, que é o que acontece nas bolhas, você não inova. Isso é tão importante que vou repetir:

Inovação é o subproduto das Restrições.

A gente estima com base no conhecimento passado. Se não conseguimos superar o nosso próprio passado, o quão incompetentes somos? Dá para argumentar que software não é previsível, e eu concordo. Mas errar por ordens de grandeza ao recriar software parecido, para mim, cheira incompetência.

A maior parte do software que produzimos é a mesma coisa de sempre: site de conteúdo, e-commerce, e-learning, rede social, social commerce, fórum, enquete. Raramente é ideia nova ou algoritmo de ruptura. A não ser que você trabalhe em programa de pesquisa, que tipo de software realmente diferente você fez ultimamente?

Estimativa raramente é o problema. Toda estimativa parte de um conjunto de premissas, e o problema é não gerenciar essas premissas. Se os requisitos mudam, tudo bem, isso a gente sempre consegue gerenciar. O que não dá para gerenciar é o problema acumulado no último dia do projeto, quando os programadores empurraram tudo com a barriga. De novo, isso é um problema de Recursos Humanos.

Meritocracia só existe num sistema de escassez, onde um se destaca em relação ao outro diante de uma restrição. Num sistema de pura abundância, não há necessidade de inovar nem de mérito. Empresas que acabaram de receber uma quantidade absurda de grana invariavelmente mostram sintomas de preguiça, muito mais do que de inovação.

A confusão acontece porque algumas das “práticas” defendidas vêm dessa situação temporária e irreal de bolha, e não aguentam a pressão do tempo. Dá tempo suficiente e você vai se perguntar: “como é que a gente, com tanto dinheiro e tanto tempo, conseguiu tão pouco, e aquela startupzinha, com recursos tão limitados, conseguiu nos superar?”. Essa é a resposta de por que um Yahoo! compra um Tumblr, por que um Facebook compra um Instagram, por que um Google compra um Waze.

Se você defende #noEstimation, por que não dar mais um passo e defender #noWork? É só um passo a mais.

]]>agilegestaoengenharia-de-softwareoff-topic[Off-Topic] Estimativas são Promessas. Promessas devem ser cumpridas.https://akitaonrails.github.io/2013/08/23/off-topic-estimativas-sao-promessas-promessas-devem-ser-cumpridas/https://akitaonrails.github.io/2013/08/23/off-topic-estimativas-sao-promessas-promessas-devem-ser-cumpridas/Fri, 23 Aug 2013 16:15:00 -0300<p>Navegando no Quora, encontrei uma pergunta simples e interessante: <a href="https://www.quora.com/Software-Engineering/What-is-the-hardest-thing-you-do-as-a-software-engineer/answer/Fabio-Akita"target="_blank" rel="noopener">&ldquo;Engenharia de Software: qual a coisa mais difícil para um engenheiro de software&rdquo;</a>. É um assunto sobre o qual reflito há muitos anos. Respondi lá em inglês, e vale republicar uma versão em português aqui também.</p> <p>Sou engenheiro de software e, depois de vinte anos passando por empresas, mercados e equipes diferentes, vejo um padrão. Praticamente todo engenheiro que conheci começa com a premissa de que &ldquo;código&rdquo; é o objetivo e a solução de todo problema.</p>Navegando no Quora, encontrei uma pergunta simples e interessante: “Engenharia de Software: qual a coisa mais difícil para um engenheiro de software”. É um assunto sobre o qual reflito há muitos anos. Respondi lá em inglês, e vale republicar uma versão em português aqui também.

Sou engenheiro de software e, depois de vinte anos passando por empresas, mercados e equipes diferentes, vejo um padrão. Praticamente todo engenheiro que conheci começa com a premissa de que “código” é o objetivo e a solução de todo problema.

A verdade é que, no mercado em geral, problemas de software não encontram solução em software. Não estou falando dos casos excepcionais de pesquisa e desenvolvimento ou do meio acadêmico. Essa é a primeira e mais difícil coisa que todo engenheiro sofre para entender, e briga contra ela.

Francis Underwood

Linda Vasquez: Eu sei que ele te fez uma promessa, mas as circunstâncias mudaram.

Francis Underwood: A natureza das promessas, Linda, é que elas se mantêm imunes a mudanças de circunstâncias.

– House of Cards

Um aspecto que muita gente cita como o mais difícil é “estimar”, porque é raro chegar a estimativas certas. E aí mora o problema: a própria frase confunde.

Estimativas, por definição, nunca serão “corretas”. Se fossem, se chamariam “previsões”, e são duas palavras separadas justamente por isso. Numa previsão as variáveis são conhecidas e determinadas, o caminho é previsível e automático. É o cenário de laboratório: “dadas as condições ideais de temperatura e pressão, no vácuo, com atrito zero, um carrinho de brinquedo a uma velocidade constante de 10 metros por segundo, por 10 segundos, percorre 100 metros.” E estimativas?

Fora do laboratório, temos estimativas, e estimativas são PROMESSAS.

Promessas são feitas para serem cumpridas. Uma promessa não se resolve sozinha. Você precisa se esforçar deliberadamente para alcançá-la e manter a sua palavra. Com estimativas é igual: você estima e depois trabalha duro para cumprir o que prometeu.

“Mas o gerente/cliente/investidor/chefe fica me pressionando o tempo todo para adicionar mais coisas, fazer mudanças toda hora, quebrando minha concentração com problemas irrelevantes o dia inteiro.”

Sim, eles fazem isso, e vão continuar fazendo, ontem, hoje e sempre. A reação mais comum é ficar na defensiva. Para não se comprometer, a pessoa decide não dar estimativa nenhuma, ou dá um número fora de proporção para garantir que qualquer “extra” caiba. É um péssimo comportamento padrão.

Imagine que você promete à sua filha estar na apresentação dela na escola. Você falha e chega duas horas depois de tudo terminar. Esse fracasso é seu, e só seu.

Não foi o trânsito, não foram as reuniões inesperadas, não foi o tempo. Você fez a promessa e não se preparou para os acidentes de percurso: sair antes, adiantar-se aos problemas, deixar folga para o inesperado. Deixou tudo para a última hora, saiu no último minuto e, claro, shit happens.

Com estimativas acontece o mesmo. Você disse um número sem comprometimento, sem senso de responsabilidade, e não fez nada além de sentar e escrever código para chegar lá. Não foi atrás de explicar os problemas.

Dizer uma vez, do seu jeito, não significa que a outra ponta entendeu. Quem inicia a comunicação é responsável por encontrar o meio de a mensagem chegar do outro lado; sem isso, a comunicação não aconteceu. Comunicar é ser entendido, e ser entendido é responsabilidade de quem fala.

Então você fracassou em se comunicar, em gerenciar o próprio tempo, em ajudar seus pares com os problemas. Era tudo sua responsabilidade. Escrever código era o menor dos problemas.

Ter senso de responsabilidade é justamente a segunda coisa mais difícil que todo engenheiro enfrenta. Se a premissa inicial é que ele só responde por “escrever código”, ele não enxerga a comunicação falha como falha dele. Por isso raramente assume o fracasso: é muito mais fácil culpar todo o resto. E isso vem direto da primeira dificuldade, a premissa errada de que seu único objetivo na vida é escrever código e de que todo problema se resolve com código.

Isso não vale só para software. Vale para o músico, o cozinheiro, o construtor. Como profissional de ofício, espera-se que você seja ótimo na sua arte, claro. Mas isso é o mínimo da fundação, e não há nada de excepcional em ser tecnicamente bom, por mais impressionante que a habilidade pareça.

Não adianta escrever o código mais elegante e perfeito se ele resolve o problema errado. É como compor a peça clássica mais perfeita, à la Beethoven, para um trabalho que pedia música de festa de aniversário infantil. Das duas, uma: ou você não aceita a festa infantil, ou escreve a melhor música pop que conseguir. Se aceitou e ficou, ou entrega com qualidade excepcional, dentro da expectativa, ou reconhece a incapacidade e sai de cena, sem atrapalhar quem consegue resolver o que você não pôde.

Quem oferece um serviço precisa entender uma coisa: o objetivo é implementar a melhor solução possível, mas para o conjunto certo de problemas. E o mais difícil é encontrar esse conjunto certo. Os clientes procuram profissionais justamente porque também não sabem. Cabe a nós ajudar a achar esses problemas, avaliar se está ao nosso alcance cumprir a promessa, e depois mantê-la, gerenciando cada obstáculo que aparecer no caminho.

Parece simples dito assim, mas até engenheiros experientes falham em entender essa verdade, e muitos se safam quebrando promessas com truques para esconder o rombo.

Aprendam então a primeira e mais difícil verdade do mundo: software normalmente não é resolvido com software, é resolvido com capacidades humanas. Numa distribuição de Pareto, eu diria que 80% de todo problema de software só se resolve quando você investe os 20% restantes em comunicação, articulação, pensamento claro e racional, quebra de ambiguidades, negociação e compromisso.

Diante disso, pode parecer mais fácil nunca prometer nada. Só que nunca prometer significa nunca se comprometer, e nunca se comprometer significa nunca ser profissional. É exatamente isso que separa o amador ou hobista do profissional: fazer promessas e trabalhar para cumpri-las. Também acontece de você não cumprir seu lado porque ele dependia de o cliente, o chefe ou quem seja cumprir o lado dele primeiro. Uma troca mútua de promessas é a razão de existir um árbitro chamado Justiça, e o instrumento que registra essas duas promessas tem nome: contrato.

Promessas

Dito tudo isso, dá para cumprir todas as promessas? Não, infelizmente não dá. Mas é nossa responsabilidade como profissionais buscar sempre esse ideal, em vez de inventar maneiras de fugir dele.

Já falei mais sobre o que considero um profissional num post de 2011, "[Off-Topic] Opiniões, Verdades, Democracia e Ética".

]]>carreiragestaoengenharia-de-softwareoff-topicPrevisivelmente Irracionalhttps://akitaonrails.github.io/2013/07/12/previsivelmente-irracional/https://akitaonrails.github.io/2013/07/12/previsivelmente-irracional/Fri, 12 Jul 2013 20:44:00 -0300<p><strong>Original de 4/3/2010</strong>: <a href="http://web.archive.org/web/20130724115712/http://info.abril.com.br/noticias/rede/gestao20/gestao/previsivelmente-irracional/"target="_blank" rel="noopener">Gestão 2.0</a></p> <p>Existe um ramo de pesquisa conhecido como “Economia Comportamental”, uma vertente diferente da Economia tradicional. A Economia clássica parte do princípio de que as pessoas são racionais e decidem com base em análise de custo-benefício. A Economia Comportamental leva em conta os fatores sociais, cognitivos e emocionais que influenciam nossas decisões do dia a dia.</p> <p>Gostamos de acreditar que tomamos decisões racionais o tempo todo, mas na maior parte das vezes damos chutes e decidimos na emoção. E isso produz resultados muito interessantes. Um dos pesquisadores mais conhecidos da área é o Prof. Dan Ariely, autor do livro “Previsivelmente Irracional”.</p>Original de 4/3/2010: Gestão 2.0

Existe um ramo de pesquisa conhecido como “Economia Comportamental”, uma vertente diferente da Economia tradicional. A Economia clássica parte do princípio de que as pessoas são racionais e decidem com base em análise de custo-benefício. A Economia Comportamental leva em conta os fatores sociais, cognitivos e emocionais que influenciam nossas decisões do dia a dia.

Gostamos de acreditar que tomamos decisões racionais o tempo todo, mas na maior parte das vezes damos chutes e decidimos na emoção. E isso produz resultados muito interessantes. Um dos pesquisadores mais conhecidos da área é o Prof. Dan Ariely, autor do livro “Previsivelmente Irracional”.

No livro ele analisa como enxergamos preços, por que o preço não é uma simples questão de “oferta e procura”, por que somos desonestos e como funciona o efeito placebo. É o resultado de anos de experimentação empírica.

Assista a este trecho que legendei da palestra dele no TED sobre o assunto:

Por que isso importa? Porque lidamos com pessoas todos os dias. Tomamos decisões influenciadas por outros ou, pior, que vão afetar outros. E dormimos de consciência tranquila, convencidos de que escolhemos a melhor opção racional com os dados que tínhamos em mãos.

Mas e se nossas decisões não forem tão racionais assim? E se somos facilmente influenciados por dados e circunstâncias? Melhor ainda: e se reconhecer esse fato nos ajudar a entender nossas limitações e a decidir melhor de verdade?

Por isso vale a pena entender a própria psicologia. Quem ocupa uma posição de gerência precisa disso mais que todo mundo, porque o trabalho em si já é “gerenciar pessoas”.

Somos irracionais, previsivelmente irracionais. Use isso a seu favor.

]]>psicologiaeconomiagestaooff-topicIntrodução à Agilidadehttps://akitaonrails.github.io/2013/06/28/introducao-a-agilidade/https://akitaonrails.github.io/2013/06/28/introducao-a-agilidade/Fri, 28 Jun 2013 20:08:00 -0300<p><strong>Original de 18/6/2010</strong>: <a href="http://web.archive.org/web/20130723202056/http://info.abril.com.br/noticias/rede/gestao20/gestao/introducao-a-agilidade/"target="_blank" rel="noopener">Gestão 2.0</a></p> <p>Eu retornei no último fim de semana de uma viagem a Baltimore, Maryland, onde palestrei na RailsConf. Foi um evento com grandes palestras, algumas voltadas não só a Ruby on Rails, mas à carreira de programação em geral. Uma delas foi de ninguém menos que Robert Martin, da Object Mentor. Eu traduzi um artigo dele no meu post anterior.</p> <p>Recomendo assistir à palestra na íntegra.</p> <p>Desde que comecei este blog, tento explicar as condições e dificuldades que um Gestor de Projetos enfrenta. Mas venho tomando cuidado para não repetir o termo &ldquo;Agile&rdquo; a todo momento. Estamos no meio de uma febre de &ldquo;agilidade&rdquo;. Todo CIO, CTO, gerente ou consultor, para parecer moderno, diz que sabe &ldquo;Scrum&rdquo; e que é &ldquo;ágil&rdquo;.</p>Original de 18/6/2010: Gestão 2.0

Eu retornei no último fim de semana de uma viagem a Baltimore, Maryland, onde palestrei na RailsConf. Foi um evento com grandes palestras, algumas voltadas não só a Ruby on Rails, mas à carreira de programação em geral. Uma delas foi de ninguém menos que Robert Martin, da Object Mentor. Eu traduzi um artigo dele no meu post anterior.

Recomendo assistir à palestra na íntegra.

Desde que comecei este blog, tento explicar as condições e dificuldades que um Gestor de Projetos enfrenta. Mas venho tomando cuidado para não repetir o termo “Agile” a todo momento. Estamos no meio de uma febre de “agilidade”. Todo CIO, CTO, gerente ou consultor, para parecer moderno, diz que sabe “Scrum” e que é “ágil”.

Isso tem um lado bom: algumas empresas talvez enfim adotem essas ideias do jeito certo. Tem também um lado ruim, e grande. Estamos queimando o nome “Agile” por causa de consultorias ruins que implementam tudo errado no cliente. O resultado é a percepção, entre os desavisados, de que “Agile não funciona”.

Pois bem, durante a RailsConf, tive a oportunidade de conversar e entrevistar o Robert Martin, cuja gravação você pode assistir abaixo:

Dessa entrevista, o trecho que quero apresentar é a história de como surgiu o “Agile”. Robert Martin, também conhecido como “Uncle Bob”, é programador há décadas, certamente mais do que qualquer um de nós. Nos anos 90 ele foi um dos que notaram o surgimento de metodologias “leves” ou “lean”. Muito disso derivava dos conceitos de manufatura que revolucionaram a indústria japonesa a partir dos anos 60.

Vários nomes de peso começaram a propor formas mais inteligentes de desenvolver software. Kent Beck com o Extreme Programming (XP); Ken Schwaber e Jeff Sutherland com o Scrum; Alistair Cockburn com o Crystal.

Todos seguiam uma linha parecida: iterações curtas, feedback constante e muita comunicação. Vendo esse padrão, Uncle Bob procurou Martin Fowler, outro nome forte no mundo de arquitetura de software, e juntos passaram a organizar uma reunião, convocando um grupo desses profissionais.

A lendária reunião aconteceu na estação de esqui de Snowbird, em Utah, entre 11 e 13 de fevereiro de 2001. Dezessete profissionais passaram três dias ali e saíram com o “Manifesto Ágil”. Ele reúne 4 valores e 12 princípios que todos os participantes aceitaram como o mínimo denominador comum na prática de desenvolvimento de software. O manifesto diz:

Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazerem o mesmo. Através deste trabalho, passamos a valorizar:

Indivíduos e interações mais que processos e ferramentas

Software em funcionamento mais que documentação abrangente

Colaboração com o cliente mais que negociação de contratos

Responder a mudanças mais que seguir um plano

Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.

Como disse antes, existe uma febre crescente de adoção de metodologias ágeis. Pior que isso, existe a tendência de expropriar o termo “Ágil” e seus derivados, como “XP” e “Scrum”, criando verdadeiros frankensteins que misturam o jeito antigo com o novo. É o caso de tentar juntar RUP com Scrum, ou PMI com Scrum, e assim por diante.

São tentativas oportunistas que aproveitam a febre para ganhar dinheiro fácil. Algumas empresas, por exemplo, fazem questão de um “Certified Scrum Master” no currículo de um gerente, entre outras coisas igualmente irrelevantes.

E, para piorar, muitos tentam implementar metodologias ágeis “by the book”, ou seja, de forma dogmática. Todo dogma, por definição, é burro.

Voltando aos 4 valores: a prioridade é software que funciona e valor ao cliente. Implantar uma metodologia vem depois disso, quando vem. O primeiro valor é claro: valoriza muito mais Indivíduos e Interações do que Processos e Ferramentas. O que se vê hoje é o oposto, um esforço para empurrar processos, metodologias e ferramentas.

Agora é uma boa hora para começar a desmistificar o mundo Agile. Isto aqui é só uma introdução, mas vale o conselho que o Uncle Bob dá na entrevista: siga os originais. Se você está mesmo comprometido em melhorar as coisas e entregar projetos com qualidade e valor, largue essa nova geração de consultorias. Comece pelos primeiros livros de Ken Schwaber, Kent Beck, Alistair Cockburn e Mike Cohn.

Pergunte-se o tempo todo: estou de acordo com os 4 valores?

Se estiver dando mais ênfase ao processo do que às pessoas, você já começou errado. Muito errado.

]]>agilegestaoengenharia-de-softwareoff-topicProcessos, Metodologias e o Cérebro Humanohttps://akitaonrails.github.io/2013/06/21/processos-metodologias-e-o-cerebro-humano/https://akitaonrails.github.io/2013/06/21/processos-metodologias-e-o-cerebro-humano/Fri, 21 Jun 2013 20:00:00 -0300<p><strong>Original de 24/6/2010</strong>: <a href="http://web.archive.org/web/20130311020016/http://info.abril.com.br/noticias/rede/gestao20/gestao/processos-metodologias-e-o-cerebro-humano/"target="_blank" rel="noopener">Gestão 2.0</a></p> <p>O cérebro humano é uma máquina fantástica, e dizer isso é basicamente uma redundância do termo. Porém existem muitas anedotas e misticismo quando se fala sobre ele.</p> <p>Todos já discutiram alguma vez a separação da <strong>“Emoção”</strong> do <strong>“Raciocínio”</strong>. Desde os tempos de Platão, as emoções são vistas como algo que atrapalha o pensamento lógico. Pior ainda: a maioria das pessoas acredita que, pelo menos nas decisões mais importantes, somos capazes de deixar as emoções de lado. A ideia é pensar de acordo com a economia clássica, baseados em fatos, evidências e custo-benefício.</p>Original de 24/6/2010: Gestão 2.0

O cérebro humano é uma máquina fantástica, e dizer isso é basicamente uma redundância do termo. Porém existem muitas anedotas e misticismo quando se fala sobre ele.

Todos já discutiram alguma vez a separação da “Emoção” do “Raciocínio”. Desde os tempos de Platão, as emoções são vistas como algo que atrapalha o pensamento lógico. Pior ainda: a maioria das pessoas acredita que, pelo menos nas decisões mais importantes, somos capazes de deixar as emoções de lado. A ideia é pensar de acordo com a economia clássica, baseados em fatos, evidências e custo-benefício.

Porém, na grande maioria das vezes não é assim que nos comportamos. Quando vamos a um supermercado, dificilmente ficamos fazendo aritmética, considerando os ingredientes de cada produto ou o valor nutricional. Normalmente olhamos para um produto e decidimos se compramos ou não com base no que sentimos.

No meio de dezenas de marcas para um mesmo tipo de produto, escolhemos com base em experiências passadas, em algum acontecimento marcante, nas lembranças, e tudo em frações de segundos. Preferimos levar um produto “80% light” a levar um “20% gorduroso”, apesar de ambas as frases dizerem a mesma coisa.

Brain

Antonio Damasio é um conhecido neurologista que estuda o cérebro e nosso comportamento. Ele acompanhou pacientes que literalmente perderam a capacidade de ter emoções por causa de danos cerebrais, seja por tumor, seja por problema genético. Poderíamos imaginar, como o filósofo Platão, que uma pessoa sem emoções tomaria as melhores decisões o tempo todo, já que não seria influenciada por elas.

Porém, sem as emoções essas pessoas não conseguem aprender. Qualquer decisão trivial vira uma análise de custo-benefício. Escolhas cotidianas como que roupa vestir, que canal de televisão assistir, tomar chá ou café, todas as coisas mundanas que decidimos quase instantaneamente, podem levar horas até esse tipo de paciente chegar a uma conclusão.

Brain

Um fato que já conhecemos: todas as emoções, tristeza, compaixão, alegria, depressão, prazer, são reações químicas no cérebro. E já sabemos como influenciar ou controlar muitas delas.

Usuários de drogas conhecem a sensação de prazer. Quem toma antidepressivos também. São todos químicos que atuam no cérebro e modificam nossas emoções. Esquizofrenia e Parkinson, por outro lado, são danos nesse sistema químico.

Outro fato é que nosso cérebro evoluiu para aprender. Aprendemos por tentativa e erro. Aprendemos observando e inferindo padrões. As emoções influenciam fortemente nossas decisões, e isso é bom.

Quando aprendemos algum padrão, dopamina é liberada no cérebro e cria uma sensação de prazer. Gostamos de descobrir o padrão das coisas e de tentar prever eventos futuros.

Pegue um experimento com macacos: tocamos um sino e depois damos uma banana. O macaco aprende o padrão “depois do sino vem a banana”. Dá para medir a dopamina sendo liberada já quando o sino toca, porque o macaco passa a prever esse acontecimento.

Se acendermos uma luz, tocarmos o sino e depois dermos a banana, o macaco aprende que o evento “luz” dá sequência ao sino e depois à banana. O padrão pode ser repetido com várias etapas, e o macaco aprende. Porém, se seguirmos o padrão e a banana não vier no final, o macaco fica triste, porque a previsão falhou.

Nós também funcionamos assim.

Para muitos eventos simples, com poucas variáveis, isso funciona bem. Talvez por isso muitos gostem de rotina, onde os resultados são bem definidos.

Nosso cérebro, no entanto, tem um defeito: na ânsia de encontrar padrões, ele tenta encaixá-los onde não existem. É assim que nascem as superstições. Antes de entendermos meteorologia, tribos primitivas achavam que “chover” estava ligado a uma dança que acabaram de fazer, e imaginavam que repetir a dança traria a chuva de novo.

Traduzi no meu outro blog um artigo da Scientific American demonstrando como somos “matematicamente ignorantes”. Tentamos achar um padrão para tudo. Um trecho que ilustra nossas superstições e explicações sobre coincidência é este:

Sempre é possível combinar dados aleatórios e encontrar alguma regularidade. Um exemplo muito bem conhecido é a comparação das coincidências nas vidas de Abraham Lincoln e John Kennedy, dois presidentes com 7 letras em seus últimos nomes, e eleitos com 100 anos de diferença, 1860 e 1960. Ambos foram assassinados numa sexta-feira na presença de suas esposas, Lincoln no teatro Ford e Kennedy num automóvel feito pela Ford. Ambos assassinos têm 3 nomes: John Wilkes Booth e Lee Harvey Oswald, com 15 letras em cada nome completo. Oswald atirou em Kennedy de um armazém e correu para um teatro, e Booth atirou em Lincoln em um teatro e correu para um tipo de armazém. Ambos os sucessores vice-presidentes eram Democratas sulistas e ex-senadores chamados Johnson (Andrew e Lyndon), com 13 letras em seus nomes e nascidos com 100 anos de diferença, 1808 e 1908.

Mas se compararmos outros atributos relevantes falhamos em encontrar coincidências. Lincoln e Kennedy nasceram e morreram em datas (dia e mês) e em estados diferentes, e nenhuma das datas é separada de 100 anos. Suas idades eram diferentes, assim como os nomes das esposas. Claro, se alguma dessas fosse correspondente estariam na lista de coincidências “misteriosas”. Para qualquer pessoa com vidas razoavelmente cheias de eventos é possível encontrar coincidências entre elas. Duas pessoas se encontrando numa festa normalmente encontram coincidências chocantes entre elas, mas o que são – aniversários, cidades natais, etc – não são previstos de antemão.

O mundo real é cheio de aleatoriedades, e não é difícil encontrar padrões nelas. Na verdade é muito fácil. Situações complexas têm muitos aspectos aleatórios, mais do que se imagina. E nosso cérebro ainda não evoluiu o suficiente para se sentir confortável num mundo totalmente aleatório.

Um exemplo são as pessoas de sucesso. Imagine um mega-investidor como Warren Buffett. Livros e mais livros são impressos, com análises, biografias e teorias, tentando explicar o processo que leva uma pessoa comum a ganhar bilhões na bolsa. Só por especulação: e se Warren Buffett for nada mais, nada menos, do que um acidente estatístico?

Nassim Taleb explica isso num artigo de Malcolm Gladwell:

Suponha que existem 10 mil gerentes de investimento por aí, o que não é um número tão irreal assim, e que a cada ano metade deles, totalmente por acaso, ganharam dinheiro e a outra metade perdeu dinheiro, também totalmente por acaso. E suponha que todo ano os que perderam dinheiro saem do mercado, e esse jogo é repetido todos os anos com os que sobraram. Ao final de 5 anos, ainda existiriam 313 pessoas que ganharam dinheiro seguidamente em todos os anos. E depois de 10 anos ainda existiriam 9 pessoas que ganharam dinheiro todos os anos, seguidamente, totalmente por acaso, por pura sorte da aleatoriedade. E quem pode dizer que Buffett não é um desses 9?

Nosso cérebro tem prazer em procurar padrões em tudo, especialmente em casos de sucesso. Queremos encontrar a receita, a fórmula mágica. Às vezes fica aquela sensação de “o que ele tem que eu não tenho?”

Às vezes duas pessoas são tecnicamente igualmente capazes, mas uma fica rica e a outra não. A diferença pode ser simplesmente aleatoriedade. “Mas isso não é justo!”, você reclama. O mundo não foi feito para ser justo. Justiça é um conceito humano, e a realidade não tem senso de moralidade: ela apenas “é”.

A ciência, felizmente, tem um procedimento para evitar essa armadilha do cérebro: o método científico. Tudo pode começar com um desses enganos, achando que encontrou um padrão e gerando uma teoria. Agora essa teoria precisa ser colocada à prova.

Para virar uma boa teoria, precisamos não só tentar comprová-la, mas principalmente tentar desprová-la. E mesmo que não achemos como desprovar a hipótese, nem por isso ela vira uma “Lei”. A ciência toma muito cuidado com as afirmações que faz.

Mesmo que uma teoria funcione bem mil vezes, basta um único fracasso para que seja rejeitada. É graças a essa forma de pensar que temos fundações sólidas e confiáveis na ciência, livres de superstição e misticismo.

Processos, Metodologias e Superstições

Dei toda essa explicação para chegar ao assunto principal deste blog: gerenciamento de projetos e de pessoas. Quem acompanha meus posts notou que em nenhum momento eu prego uma metodologia, um processo, uma receita de bolo. Coisas do tipo “como fazer estimativas corretas” ou “como prever o sucesso de um projeto”.

Se você é bem atualizado, sabe que existe todo um mercado de indivíduos e empresas que tentam justamente isso: vender processos e metodologias. Seja a Engenharia de Software tradicional, seja o PMI, sejam as chamadas “metodologias Ágeis”.

Antes preciso deixar um alerta: todas essas metodologias foram pensadas com a melhor das intenções. A ideia era compartilhar os fatores que levaram determinado projeto ao sucesso.

Minha explicação é mais ou menos assim: os líderes desses projetos, ou melhor, seus cérebros, começam incansavelmente a procurar padrões. Talvez seja o post-it na parede. Talvez o tipo de documento usado. Talvez a forma de as pessoas se sentarem à mesa.

Tudo isso forma um conjunto de “pseudo-verdades” que o cérebro entende como as “luzes” e os “sinos” que levam à “banana”. Esses líderes aplicam a receita em outros projetos e, como Nassim Taleb explicou, têm sucesso seguidamente.

Eureca! Parece que encontramos a fórmula para transformar ferro em ouro! Rapidamente essas pseudo-verdades são formatadas como metodologias, enlatadas, empacotadas e vendidas.

Porém pensem por um momento: e se todas essas metodologias forem exatamente como a dança da chuva? Como eu disse, é muito fácil encontrar padrões na aleatoriedade.

Quando começamos a discutir minúcias, com que nível de detalhe fazer uma estimativa, que métricas usar, quais os mecanismos de comunicação da equipe, não consigo deixar de pensar nas tribos primitivas discutindo “Quais penas devemos vestir? Que cores usar na cara? Devemos dar passos longos ou curtos na dança?”

Mas a questão principal não vem à tona: é a dança da chuva que efetivamente faz chover? Ou, no nosso caso, é a metodologia que de fato leva o projeto ao sucesso?

Dança da Chuva

E o método científico? O problema é que um “projeto” é uma situação muito complexa. Mesmo os menores projetos são complexos, no sentido de que têm mais variáveis do que é possível medir.

Um dos jeitos de testar uma teoria é fazer um experimento duplo-cego, como os laboratórios de remédios fazem: um grupo recebe o medicamento de verdade e outro recebe um placebo, sem saber. Se ambos tiverem aproximadamente o mesmo resultado, o remédio não funciona.

Porém uma metodologia é mais complicada do que um remédio. Mesmo que a gente crie dois ambientes de trabalho isolados e idênticos, coloque dois grupos de pessoas “aproximadamente” semelhantes em cada um, comece no mesmo horário e com os mesmos requisitos, um lado com a metodologia “A” e o outro com a “B”, ainda assim não dá para comparar os resultados.

Isso porque metodologias envolvem as micro-decisões e as capacidades de cada pessoa, e “aproximadamente semelhante” é muito diferente de “igual”. É impossível duplicar o mesmo grupo de pessoas em cada ambiente.

Teríamos primeiro que clonar as pessoas com sucesso. Aí sim, com grupos exatamente idênticos, daria para fazer um experimento duplo-cego. Mas isso é impossível.

A conclusão é que provar uma metodologia desse tipo como “correta” é impossível, assim como é difícil desprová-la. Portanto, é inútil tentar afirmar que elas funcionam ou não. É claro que influenciam e, separadamente, cada técnica pode ser testada com mais cuidado. Mas não acho possível afirmar cientificamente que elas funcionam.

“Mas eu testei a metodologia X no meu projeto e funcionou!”

Excelente, bom para você. Porém, para cada projeto bem-sucedido com determinada metodologia, dá para encontrar um caso em que deu errado.

E os indivíduos e consultorias que vendem essas metodologias são espertos: se o projeto deu certo, foi graças à metodologia; se deu errado, foi porque as pessoas não seguiram a metodologia como deveriam. A culpa nunca é da metodologia. É uma ótima retórica para montar um argumento de vendas.

E como as pessoas não estão acostumadas a avaliar as coisas racionalmente, e como expliquei, na maioria das vezes nem raciocinam, sobram muitos consultores ganhando muito dinheiro sem precisar se comprometer com resultados.

Isso importa porque muita gente acredita que, com a ajuda da metodologia da moda, basta aplicá-la a uma equipe só de inexperientes para um bom resultado aparecer, como se o importante fosse o processo e não as pessoas. Acontece o contrário.

Na maioria das vezes essas metodologias não descrevem as qualificações exatas que cada membro precisa ter, porque é impossível listar todas. No máximo trazem descrições vagas de “papéis”, que geram mais discussão do que resposta. Um projeto com chance de dar certo começa com pelo menos algumas pessoas muito experientes, capazes de conduzir o resto da equipe.

Enfim, minha recomendação: estude as tais “metodologias”, porque, como eu disse, algumas técnicas ali têm valor. Mas entenda que nenhuma delas representa a verdade.

E não adianta somar duas meia-metodologias achando que isso as torna “mais completas”. Projetos são executados por pessoas, o comportamento humano é difícil de prever e o mundo real é cheio de variáveis imprevisíveis, formando um sistema complexo com muita aleatoriedade envolvida.

Evolução

Comece aceitando que o mundo é aleatório e está fora do seu controle. Em situações complexas é melhor errar antes do que depois, porque os erros trazem informação que ajuda a refinar as decisões seguintes.

Aceite que prever o futuro num sistema complexo é impossível e adapte-se: algumas coisas vão sair como previsto e outras vão precisar mudar. Talvez uma funcionalidade não prevista precise ser feita, e o prazo tenha que esticar. Talvez uma funcionalidade prevista não fosse tão necessária e possa ser descartada. É assim que se lida com um ambiente complexo e imprevisível: adaptando.

A biologia explica: todos os seres vivos do planeta são resultado de uma sequência constante de tentativa e erro. A natureza não é “perfeita”, no sentido de que não há criador, não há design inteligente, não há grande plano, não há destino. Todo ser vivo veio de um rascunho biológico muito ruim que, pouco a pouco, via seleção natural, foi descartando o que não funcionava e favorecendo o que funcionava.

Nós humanos carregamos resquícios biológicos, como o apêndice. Somos um produto em constante evolução, e para muita coisa o estágio atual é “bom o suficiente”. Em termos de projeto, é nesse ponto que ele pode ser lançado: quando está “bom o suficiente”, ainda com arestas a arrumar, mas funcionando no geral.

Tentativa e erro. Adaptação. Evolução. É assim que se gerencia qualquer coisa.

Se quiser uma visão mais detalhada sobre esse assunto recomendo começar lendo os seguintes livros:

]]>psicologiaagilegestaooff-topicO que significa ser um Gerente?https://akitaonrails.github.io/2013/06/07/o-que-significa-ser-um-gerente/https://akitaonrails.github.io/2013/06/07/o-que-significa-ser-um-gerente/Fri, 07 Jun 2013 19:40:00 -0300<p><strong>Original de 10/10/2010</strong>: <a href="https://web.archive.org/web/20130414102358/http://info.abril.com.br/noticias/rede/gestao20/gestao/o-que-significa-ser-um-gerente/"target="_blank" rel="noopener">Gestão 2.0</a></p> <p>Por incrível que possa parecer, não existe uma definição boa, simples, clara e curta para o que é ser um “gerente”. Gerente não é uma profissão. Você não pode “aprender” a ser um gerente numa escola ou num curso. A única forma de aprender é tentando, errando e melhorando, de forma contínua e indefinida.</p> <p>Uma das melhores definições que encontrei é de ninguém menos que o professor Henry Mintzberg, em seu recente livro “Managing”, publicado em 2009. Uma leitura madura e leve.</p>Original de 10/10/2010: Gestão 2.0

Por incrível que possa parecer, não existe uma definição boa, simples, clara e curta para o que é ser um “gerente”. Gerente não é uma profissão. Você não pode “aprender” a ser um gerente numa escola ou num curso. A única forma de aprender é tentando, errando e melhorando, de forma contínua e indefinida.

Uma das melhores definições que encontrei é de ninguém menos que o professor Henry Mintzberg, em seu recente livro “Managing”, publicado em 2009. Uma leitura madura e leve.

Recomendo a leitura. Se você é um gerente iniciante, ou quer ser um, talvez o livro lhe dê alguma visão do que vem pela frente. Se você já é gerente, vai se surpreender. Muitos livros teóricos pintam cenários que você nunca viu na prática e ficam fazendo você duvidar se está no caminho certo. Este aqui define melhor os problemas reais que você enfrenta no dia a dia.

Quero trazer alguns trechos da primeira metade do livro.

Gerenciamento Não é uma Profissão

Depois de anos procurando pelo Santo Graal, é hora de reconhecer que gerenciar não é nem ciência nem profissão; é uma prática, aprendida primariamente através de experiência, e enraizada em contexto.

Certamente não é uma Ciência. Ciência tem a ver com o desenvolvimento de conhecimento sistemático através de pesquisa. Isso nem de longe é o propósito de gerenciamento, que tem a ver com ajudar a conseguir realizar coisas em organizações. Gerenciamento não é nem mesmo uma ciência aplicada, porque isso ainda é ciência. Gerenciamento certamente aplica ciência: gerentes precisam usar todo o conhecimento que conseguirem. E eles certamente usam análise, enraizada no método científico (que significa aqui mais prova científica do que descoberta científica).

Mas gerenciamento efetivo é mais dependente na arte e é especialmente enraizada em ofício. Arte produz o “insight” e “visão”, baseado em intuição (Peter Drucker escreveu em 1954 que “os dias do gerente ‘intuitivo’ estão contados”. Meio século depois, ainda estamos contando.) E ofício tem a ver com aprendizado a partir de experiência – trabalhando nas coisas à medida que o gerente avança.

Portanto, vale repetir o que Mintzberg costuma dizer: é impossível formar gerentes na escola. Isso é uma certeza. Na escola você aprende técnicas de contabilidade, de marketing, conhecimento técnico repetível. Nada disso gera um gerente, e muito menos um líder.

Quando uma escola ou um curso de MBA estampa “Formamos Líderes”, está mentindo. Essas escolas formam técnicos. Esses técnicos vão trabalhar em atividades técnicas até crescerem, acumularem responsabilidades e, talvez, um dia gerenciarem alguma coisa de verdade.

Gerenciamento é uma Prática

Coloque junto uma boa porção de ofício com o toque correto de arte junto com algum uso de ciência e você acaba com um trabalho que é, acima de tudo, uma prática. Não existe “uma melhor maneira” de gerenciar; tudo depende da situação.

Nem mesmo é uma Profissão. Já foi apontado que engenharia também não é uma ciência ou uma ciência aplicada tanto quanto uma prática em seu próprio direito. Mas engenharia aplica uma boa porção de ciência, codificada e certificada quanto à sua eficiência. E portanto ela pode ser chamada de profissão, que significa que ela pode ser ensinada antes da prática, fora de contexto. De certa maneira, uma ponte é uma ponte, ou pelo menos ferro é ferro, mesmo que seu uso tenha que ser adaptado para a situação do momento. O mesmo pode ser tido sobre a medicina. Mas não sobre gerenciamento:

Muitas capacidades médicas de diagnóstico, inferência e tratamento … assumem que uma doença pode ser decomposta em problemas separados que não diferem muito entre pacientes e podem ser tratados por remédios razoavelmente padrões … Em contraste, muito do trabalho gerencial envolve lidar com problemas que são muito interdependentes com outras partes da organização, são específicas a esta firma, mercado e indústria em particular e não facilmente reduzíveis para uma síndrome padrão geral que pode ser tratada por técnicas específicas.

Gerenciar é um trabalho de negociação, de trocas, de ceder, de conquistar. Não existe um procedimento, não existe uma metodologia, não existe um corpo de conhecimentos rígido que define esse papel. Não dá para saber “qual é o nível” de um gerente porque não existe um “padrão” de comparação. Existem bons gerentes e maus gerentes, apenas isso. Os “maus gerentes”, na realidade, sequer poderiam ser chamados de “gerentes” porque de fato não estão gerenciando.

Gerenciamento Real

Já foi dito que um expert é alguém que sabe mais e mais sobre menos e menos até que finalmente ele ou ela sabe tudo sobre nada. O problema do gerente é o oposto: saber menos e menos sobre mais e mais até finalmente ele ou ela saber nada sobre tudo.

Muita gente acha que fazer vários cursos, pós-graduação, MBAs e afins vai necessariamente torná-la um bom gerente. Essa correlação não existe. Sim, existem excelentes gerentes com boa formação, mas quem os formou de verdade foi a prática. Correlação não é causalidade. No caso geral, essa pessoa está apenas postergando aquilo que de fato lhe daria chance de virar um bom gerente: a prática.

Gerentes que não fazem e lidam, e então não sabem o que está acontecendo, podem se tornar incapazes de surgir com decisões sensíveis e estratégias robustas.

Também existe a ideia de que gerentes não devem colocar a mão na massa, afinal ou ele gerencia ou ele executa. Isso não significa que o gerente possa ser ignorante quanto à área onde atua. Muito pelo contrário: um gerente com excelente conhecimento técnico da sua área tem mais chances de entender o contexto.

Pensar é pesado – pensar demais pode cansar demais um gerente – enquanto agir é leve – agir demais pode fazer o gerente não conseguir parar.

Da mesma forma, liderança demais pode resultar em um trabalho sem contexto – sem mira, sem foco, sem ação – enquanto muito relacionamento pode produzir um trabalho desconectado de suas raízes internas – relações públicas em vez de conexões tangíveis. O gerente que somente comunica nunca termina nada, enquanto o gerente que somente “faz” termina fazendo tudo sozinho. E o gerente que somente controla riscos termina controlando uma casca vazia de homens e mulheres “sim”. Nós não precisamos de gerentes orientados-a-pessoas, orientados-a-informação ou orientados-a-ação; precisamos de gerentes que operam nesses três planos. Somente juntando todos esses papéis em todos os três planos fornecem o balanço que é essencial à prática de gerenciamento.

Mintzberg aponta algo óbvio: se você quer ser um autor renomado de gerenciamento, escrever livros e dar palestras, precisa focar em um único aspecto e exaltá-lo como a “peça que falta”. Só que, na realidade, um gerente que foca em um só aspecto da prática com certeza está fazendo a coisa errada. Um bom gerente equilibra os diferentes papéis conforme a situação e usa todos sempre que precisa.

Enfim, como podem ver, o papel do Gerente é muito mais amplo do que parece. Apenas estudar procedimento não o torna um gerente, assim como estudar uma tabela de cores não o torna um pintor, ou saber ler uma partitura não o torna um compositor.

Arte, Ofício, Técnica e Prática. Esta é a definição de Gerenciamento. Um gerente que não entende isso sempre será um péssimo gerente.

Como adendo, um cuidado. Às vezes vemos profissionais muito ativos, e não só gerentes, que parecem fazer muita coisa porque falam com muita gente, agem bastante e vivem acelerados. Esse costuma ser o sintoma do “profissional-herói”. Na minha definição, é justamente o indivíduo que está fazendo o trabalho da forma errada. Ele parece produzir muito, mas na prática só está sendo ineficiente e, pior, corrigindo os próprios erros que gera no caminho. Parece que resolve muita coisa quando, na verdade, está só correndo atrás do próprio rabo.

]]>gestaopsicologiaaprendizadooff-topic