PAULO FERNANDO VASCONCELLOS NOGUEIRA

Tag: Método

  • A Sprint Ideal tem Duas Trilhas?

    A Sprint Ideal tem Duas Trilhas?

    Já rabiscamos a estrutura de uma Sprint Ideal. Falamos sobre início e fim,  cerimônias, duração e a necessidade de folgas. O papo de hoje é sobre o que acontece dentro de uma sprint. Gente muito boa¹, como Marty Cagan e Jeff Patton, sugeriu o trabalho em duas trilhas (dual track). Há controvérsias, claro. Além de ideias que merecem dois ou três giros experimentais. 

    Não estamos em uma corrida de revezamento, como aquele quadro kanban/scrum parece sugerir de vez em quando. Esse jeito de ver o desenvolvimento de produtos e soluções deveria ter sido definitivamente escanteado lá em meados dos anos 1980, quando Takeuchi e Nonaka nos apresentaram o jeito scrum de pensar – ou, melhor dizendo, o jeito japonês de desenvolver produtos².Outro trabalho seminal da dupla, Gestão do Conhecimento (Bookman, 2008), inspirou a matriz ao lado. No eixo horizontal navegamos do entendimento de um problema (análise) até a criação da solução (síntese). Na vertical diferenciamos a natureza de nossas fontes, matérias-primas e artefatos. Eles podem ser concretos (gentes, fatos, problemas) ou abstratos (hipóteses, personas, planos).  É uma bela coincidência o encaixe sem gambiarras do ciclo OODA (Observe, Oriente, Decida, Aja) nesta matriz. Observação e Ação ocorrem aqui, no mundo real, concreto. Elas lidam com fatos e envolvem e afetam gente de carne e osso. Do outro lado, lá em cima, estão os trabalhos baseados em ideias e possibilidades. Na Orientação nós criamos opções para, logo depois, tomarmos Decisões. Os termos originais falavam com pilotos de combate. A partir deste ponto vamos chamar os trabalhos de Descoberta, Exploração, Desenvolvimento e Entrega. 

    Aos Trabalhos

    Os proponentes do modelo Dual Track falam em dois tipos de trabalho: descoberta (discovery) e desenvolvimento (development). Veja o desenho sugerido por Jeff Patton:Patton, no mesmo artigo, reconhece a existência de um terceiro tipo de trabalho, o design tático. Ele defende que os trabalhos são diferentes porque requerem um jeito de pensar diferente. Vamos retomar a matriz sugerida anteriormente? Não são dois ou três tipos de trabalho. São quatro! Em cada quadrante temos fontes e materiais distintos. Mais que isso, temos objetivos bastante diferentes:

    • Descobrir: revelar, jogar luz, tomar conhecimento, fazer conhecer.
      É neste momento que delineamos o problema ou parte dele. É aqui que conhecemos as pessoas envolvidas (holders) e temos o primeiro contato com seus interesses (stakes) e dores. É aqui, no mundo real, que descobrimos o que precisa ser feito.
    • Explorar: percorrer (região, território) para estudar, pesquisar, conhecer.
      O entendimento do problema continua e se enriquece quando começamos a cogitar alternativas de solução. Brincamos com hipóteses, rabiscamos arquiteturas e validamos protótipos. É no campo das ideias que exploramos o como fazer. 

    Aquilo que Patton e Cagan apresentam como a trilha discovery é a combinação de dois trabalhos. Pense no OODA original. Observação e Orientação são trabalhos distintos. Complementares, com certeza, mas muito diferentes. Fechando a matriz:

    • Desenvolver: elaborar, criar. No OODA original, é o momento das tomadas de decisão. Dentre as diversas opções sugeridas durante a Exploração, algumas começarão a ganhar vida neste quadrante. Para encontrar o mundo real logo depois. 
    • Entregar: para muita gente seria apenas uma questão de “colocar em produção”, “subir pra nuvem”, “mudar de assunto”… É claro que a entrega é muito mais que isso. Pode envolver a preparação das pessoas que receberão aquela mudança. Deveria incluir o monitoramento de indicadores que vão comprovar ou não a solução do problema dado. Enfim, é botando para rodar e quebrar que nós aprendemos e justificamos nossos ganhos e choros. É aqui, no mundo concreto, que encerramos e começamos tudo de novo.

    Patton e Cagan tratam os dois trabalhos acima na trilha de desenvolvimento. Nossa matriz, mais colorida abaixo, mostra como Desenvolvimento e Entrega são movimentos/momentos diferentes:

    Quatro Trabalhos / Duas Trilhas

    Durante muito tempo convivemos com o ciclo PDCA (Plan/Do/Check/Act) como se ele fosse o único ou o melhor molde para todos os nossos métodos. Apesar do berço esplêndido e de teimosos ilustres³, faz tempo que o PDCA deu o que tinha que dar. Os problemas que merecem a nossa atenção pedem por novos modelos mentais.

    O ciclo OODA nasceu da necessidade de fazer com que pilotos de caça voltassem para casa sãos e salvos. O ciclo, naquele contexto, poderia girar dezenas de vezes em uma única missão. Tente calçar aqueles coturnos. Pense em como deve ser um combate nas alturas controlando uma máquina a, sei lá, 3.000 km/h?  Pois é, o OODA parece ser uma ideia – um jeito de pensar – bastante adequado para nossos tempos velozes e furiosos. Se você topa este entendimento, então aceita o fato de que temos quatro e não dois trabalhos. 

    Quatro trabalhos em duas trilhas: Divergente e Convergente. Surrupio os termos sugeridos por Tim Brown em Design Thinking (Alta Books, 2017). Na primeira nós criamos opções. No outra, tomamos decisões. Você prefere usar Upstream e Downstream? Fique à vontade.

    Como?

    Reclamações acerca das dificuldades de trabalhar com “ágil” – feitas por designers, analistas de negócios e afins – foram sumariamente ignoradas por muito tempo. Foi necessária a intromissão de nomes mais conhecidos – Marty Cagan, James Coplien, Peter Morville e Jeff Patton, por exemplo – para que a sugestão do trabalho em duas trilhas fosse percebida. Aceita não, percebida. 

    Confesso que ainda não vi o dual-track rodando em sua plenitude. Muitos times preferem apostar em coisas como o refinamento ou workshops de requisitos. Repare: esses eventos parecem ser espaços abertos na agenda do time – concessões? – para a realização dos trabalhos de descoberta e exploração. Como se a realização deles fosse possível em dois ou três encontros por sprint. Sei não, mas isso tem jeito e cheiro de cascata.

    Descoberta e exploração deveriam acontecer todo santo dia. É por isso que a convivência diária do time com gente do negócio é um requisito para o bom uso do XisPê, Scrum etc. 

    A gente tentou encaixotar o trabalho criativo em timeboxes que fazem muito sentido para desenvolvimento e entrega, mas nenhum sentido para descoberta e exploração. São ritmos diferentes, paradas e roteiros variados. 

    “Em vez de considerar essa característica ad hoc como um dado de inferioridade do design, creio que isso atesta a independência epistemológica da área – o design não é necessariamente científico, mas pode estabelecer diálogos muito fecundos com a ciência”.
    – Caio Adorno Vassão em Metadesign (Blucher, 2010)

    Sigo confiando na proposta das duas trilhas. Aliás, dadas as críticas mais recentes?, estou disposto a dobrar a aposta. Porque elas partem de um engano: há dois times trabalhando, um em cada trilha, cada um com seu backlog!? Não foi isso que Cagan e Patton escreveram. Caramba, basta ler os artigos: há duas trilhas, não dois times. Tá todo mundo junto, o tempo todo! O tempo todo? Veja bem…

    Notas

    1. Marty Cagan escreveu Inspired: How to Create Tech Products Customers Love (Wiley, 2018) e Patton ficou famoso por causa de User Story Mapping (O’Reilly, 2014). Cagan escreveu o artigo Dual-Track Agile há oito anos. Patton voltou ao tema logo depois.
    2. No artigo The New New Product Development Game, publicado na edição de jan-fev/1986 da Harvard Business Review.
    3. O ciclo PDCA é cria de W. Edwards Deming e defendido, na comunidade Lean-Agile, por gente grande como Mary e Tom Poppendieck. Em Implementando o Desenvolvimento Lean de Software (Bookman, 2011), por exemplo. É risível a forçada de barra dada para justificar o P (plan).
    4.  We Need One Complete Product Team, de Todd Lankford (27/ago/20).
        Time to Say Goodbye to Dual Track Agile?, de Alex Ballarin (12/set/20).
    5. Foto de Henry & Co. surrupiado no Unsplash
  • Checkup Ágil – Parte II

    Checkup Ágil – Parte II

    Como nós criamos e entregamos valor? Na primeira parte deste checkup nós conversamos sobre eficácia. Agora o tema é eficiência: criar e entregar valor do jeito certo. Como trabalhamos? Nosso método realmente ajuda? Calma, não é mais uma comparação entre Scrum e Kanban. Até porque ambos tropeçam no mesmo lugar.A essência de nossos trabalhos é criar valor eliminando problemas. Nossos projetos, produtos e serviços são desenvolvidos para isso. A visão curta – imediatista, mecanicista e reducionista – nos leva a resolver problemas. Quase sempre isso redunda em paliativos e efeitos não previstos nem desejados. Ou seja, em mais problemas. Isso pode até ser um meio de vida: receitas recorrentes, como não? Pode ser um sonho para quem vende horas. E um caro e merecido pesadelo para quem as compra. Mas isso não pode ser a intenção de quem se propõe verdadeiramente Ágil.

    Entre todos os grandes pensadores sistêmicos, Ackoff foi o mais incisivo¹: devemos dissolver problemas. Devemos redesenhar o sistema de forma a evitar reincidências e efeitos negativos. O Pensamento Sistêmico nos dá essa visão privilegiada: de longo alcance, inclusiva e obrigatoriamente atenta à dinâmica das relações entre todos e tudo o que está envolvido em dada situação.

    O mundo Ágil, através de livros e propostas, gosta de apontar o Pensamento Sistêmico como uma de suas bases. É uma pena que, quase sempre, tal referência se limite a um capítulo ou nem isso². Pior ainda é quando o Pensamento Sistêmico é interpretado através de uma visão curta. Vira mera etiqueta que tenta dar ares de coesão e coerência para ideias frouxas. Nesses casos é sempre bom relembrar a Lei de Durden.

    Retomando: como criamos e entregamos valor? Como trabalhamos? Estamos de fato dissolvendo problemas? Ou simplesmente criando outros?

    Método

    O Design Thinking, também derivado do Pensamento Sistêmico, foi feliz ao escolher um losango como representação de um jeito de pensar e eliminar problemas. E muito desastrado quando resolveu trocá-lo por um squiggle. Sigamos com o losango. Na primeira metade temos a compreensão. Na outra, criação. Na primeira metade criamos opções. Na outra, tomamos decisões. Convenhamos, isso é tão antigo quanto andar para a frente. O que o mundo do design nos deu foi uma imagem e termos sofisticados: movimento divergente, movimento convergente. No fundo isso é, sempre foi e sempre será uma sequência de ANÁLISE e SÍNTESE. Necessariamente nessa ordem³.O losango perde sua utilidade quando nos deparamos com dois problemas. Primeiro: esse pensamento é linear. Os problemas que justificam os nossos salários e lucros não são eliminados assim. Eles pedem por iterações porque, como humanos, a chance de acertarmos na primeira tentativa é quase nula. Uma imagem bem melhor é a do semi círculo ornamentado por uma seta que aponta para o início e diz: vamos experimentar, aprender e tentar de novo. E de novo…

    O segundo problema é a necessidade de uma segunda dimensão. Um eixo que nos permita separar o que é CONCRETO do que é ABSTRATO. Dados, fatos, pessoas e soluções são coisas concretas. Ideias, hipóteses, opções, oportunidades e experimentos são abstrações. Acabamos de ganhar mais uma matriz 2×2.Quase todos os frameworks e métodos propostos nas últimas décadas apresentam, em seus próprios termos, a visão acima. O que não se encaixa ali é o jeitão antigo – linear, mecanicista e reducionista – de fazer as coisas. Até o ciclo PDCA (Plan-Do-Check-Act), por exemplo, não combina. Apesar de suas origens sistêmicas e, como tal, ser iterativo. OODA (Observe-Orient-Decide-Act), por sua vez, se encaixa perfeitamente. Se uso outros nomes é para aproximar o modelo de nosso contexto. OODA foi sugerido por um piloto de caças.

    Talvez alguém queira apontar a coincidência dos quadrantes acima com aqueles do Cynefin: Descoberta é Caótica, Exploração é Complexa, Desenvolvimento é Complicado e a Entrega é Simples. A coincidência é feliz. Aliás, esse caminho seria feliz… se não fosse equivocado. Se o problema que pretendemos resolver é complexo, ele não deixa de sê-lo só porque se encontra em outro momento (quadrante) daquele ciclo.

    No próximo artigo nós vamos esticar esse papo. E ver como Scrum, Kanban e derivados compartilham problemas semelhantes. Agora é hora de uma segunda rodada de nosso autoexame.

    Autoexame

    Como a sua organização CRIA e ENTREGA valor?

    • O trabalho executado no lado esquerdo do diagrama acima obedece ao mesmo ritmo e às mesmas restrições daquele que é executado no lado direito? As Sprints têm a mesma duração nesses dois hemisférios?
      Obs.: aos adeptos do Kanban deixo minha desconfiança de que o que chamo de lados esquerdo e direito são, respectivamente, o que vocês tratam como upstream e downstream Kanban. Mas vem coisa nova por aí, um tal Discovery Kanban. O nome não é mera coincidência. A necessidade, tardia, parece óbvia.
    • Você usa sprints 0, -1 e afins para tentar entender o problema?
    • Como são iniciados os seus projetos? Com Histórias de Usuários? Com hipóteses? Com planos?
    • Todas as hipóteses se tornam experimentos?

    Qualquer SIM não é bom sinal.

    Notas

    1. Dois trabalhos sintetizam bem as propostas de Russell Ackoff: Ackoff’s Best (Wiley, 1999) e, para os apressados, Differences that Make a Difference (Triarchy Press, 2010).
    2. Craig Larman e Bas Vodde vão um pouco além de um capítulo em Scaling Lean & Agile Development (Addison-Wesley, 2009) e Large-Scale Scrum – More with LeSS (Addison-Wesley, 2017). O mesmo pode ser dito sobre Managing the Design Factory (Free Press, 1997) e The Principles of Product Development Flow (Celeritas, 2009) ambos de Donald Reinertsen. No entanto, para perceber a aplicação do Pensamento Sistêmico como um todo e no todo (e como é estranho escrever isso) vale a pena ler The Journey to Enterprise Agility: Systems Thinking and Organizational Legacy (Springer, 2017) de Daryl Kulak e Hong Li.
    3. Aquela frase não seria necessária caso eu não tivesse me deparado com Essential Upstream Kanban, de Patrick Steyart. O cara tá falando que a síntese antecede a análise?!?
    4. 4 Windows, compartilhada por gmahender no flickr, ilustra este artigo.
  • ferramentas, FERRAMENTAS

    ferramentas, FERRAMENTAS

    Nossa era da ansiedade é, em grande parte, o resultado de tentarmos fazer o trabalho de hoje com as ferramentas de ontem – com os conceitos de ontem.
    – Marshall McLuhan

    Que tal começar com uma autoanálise? Pense em quantas ferramentas você conheceu nos últimos tempos. Quantas você experimentou? Quais foram incorporadas ao seu dia a dia? Considere tanto aquelas que só demandam papel e caneta quanto os brilhantes apps que inundam seu smartphone. Quais o tornaram um profissional melhor, mais produtivo e eficaz?

    Há muita conversa sobre ferramentas e respectivos guias de seleção e uso, os métodos. Que parte desse papo se concretiza? Quantos trabalhos se tornaram mais eficazes, rápidos e até prazerosos por causa de novas ferramentas? Temo que poucos, muito poucos.

    Participando de reuniões variadas em empresas idem, o que mais vejo é o puro improviso. Não há ordem nem um mínimo sistema dando sentido aos debates. De vez em quando alguém rabisca algumas ideias. Mas a solução do problema em questão, se acontece, é fruto de muito trabalho (e retrabalho) ou do acaso. Quem está ali conhece uma série de ferramentas. Talvez até desconfie que algumas seriam úteis naquele momento. Mas, por algum motivo, abre mão de aplicá-las. Qual motivo? Ou melhor, quais motivos?

    Hábitos, Vícios e Preconceitos

    Velhos hábitos e vícios são duros de matar. Desaprender é mais difícil do que aprender. Se pretendemos aplicar novos conceitos e ferramentas, antes de mais nada, precisamos abrir espaço para eles. Não é algo que ocorre do dia para a noite. Por nítidas que sejam as vantagens de uma nova técnica, o conforto do que é conhecido parece maior. E exerce uma atração irresistível. Na pressa, também comum, optamos pelo caminho que dominamos. Fazendo vista grossa para o fato dele ser o caminho mais longo e, não raro, mais acidentado.

    Outro motivo é confessado em algumas fichas de avaliação de meus treinamentos: “isso não vai funcionar na minha empresa”; “isso não é compatível com a cultura de minha empresa”; “minha empresa não está pronta para isso”; e por aí vai. Não há nem a chance ou curiosidade de experimentar um novo jeito de pensar e trabalhar. Porque regras nunca escritas seriam intransponíveis. Quem, em sã consciência, impediria ganhos de produtividade? Como pode uma ferramenta não testada ser incompatível por natureza? Tente imaginar uma carpintaria incompatível com um martelo, por exemplo. Coisa estranha.

    Assim como são estranhos alguns preconceitos. Adjetivos como “metódico” e “sistemático” são mais frequentes em tom pejorativo. Raramente aparecem como um elogio. O que é metódico e sistemático é invariavelmente chato e indesejado? De onde vem isso? Não é dos dicionários, que relacionam os termos com o perfil de alguém “que procede com método” ou “que segue ou observa um sistema”. Ou seja, são predicados de quem pensa o próprio trabalho. São características necessárias se pretendemos vencer as barreiras colocadas nos dois parágrafos anteriores.

    Voltemos ao McLuhan, citado lá em cima. Até quando insistiremos em ferramentas e conceitos de ontem? O que falta para que você faça um upgrade em seus ativos – no seu cinto de utilidades?

    Transição

    A entrevista de Jeffrey Immelt, presidente do conselho de administração da GE, para a EXAME (edição 1145 de 13/09/17) pode surpreender. A GE de Jack Welch serviu como modelo para muita gente. A cultura de controle e ferramentas como o Seis Sigma já foram coisas invejadas. Aquela GE não existe mais. Nas palavras de Immelt:

    “O Seis Sigma elimina a experimentação. O FastWorks (método ágil e enxuto desenvolvido pela GE) gira em torno da experimentação. O Seis Sigma visa eliminar falhas. No FastWorks, as falhas são endêmicas. Empresas burocráticas perdem rapidez.”

    Immelt não está fazendo nada mais do que seguir um conselho do próprio Jack Welch: “Mude antes de ser obrigado a fazê-lo”. A transição não é pequena. Uma nova cultura está nascendo. E, com ela, novos conjuntos de ferramentas.

    Para Pensar e Agir

    Donald Reinertsen, em Managing the Design Factory (Free Press, 1997), classifica as ferramentas em dois grupos¹:

    • Ferramentas para Pensar: nos ajudam a delimitar, relacionar, estruturar e avaliar determinado problema ou situação. Pensamento Sistêmico, Teoria da Informação, Teoria das Filas, Pensamento Lean e Pensamento Visual são alguns exemplos
    • Ferramentas para Agir: apoiam a execução de determinado trabalho. Diagramas de Efeitos e de Processos, cerimônias, canvases e quadros mil entram nessa categoria. 

    Trabalhos recentes – alguns livros de Design Thinking e o famoso Gamestorming (Alta Books, 2014), por exemplo – desfilam dezenas de ferramentas para agir sem o alicerce de uma teoria unificadora. Isso, por si só, não é um problema. Boas ferramentas provam o seu valor de forma pontual, sem dependências ou requisitos. No entanto, um bom profissional não vive desprovido de métodos e conceitos – sem Ferramentas para Pensar.

    Temos aqui outra tendência difícil de explicar e justificar: o desprezo pelas teorias. Entender o contexto que levou à criação de uma ferramenta – conhecer o seu porquê – é condição para sua aplicação eficaz. Não é por acaso que vemos tantos debates estéreis sobre métodos e ferramentas por aí: falta educação. Para detonar o preconceito (contra teorias e teóricos), Kurt Lewin tem uma boa provocação: “Não há nada mais prático do que uma boa teoria”.

    Assim como não há nada mais eficaz do que boas ferramentas se a nossa intenção é ganhar produtividade. Jurgen Appelo, autor de Management 3.0 (Addison-Wesley, 2011), faz uma aposta ainda maior: boas ferramentas podem nos ajudar a mudar ou implantar culturas. Essa é a proposta de seu novo projeto, Agility Scales².

    Plano de Ação

    Um plano para a reciclagem contínua de seu cinto de utilidades:

    1. Seja teimoso: experimente a ferramenta em três ou mais situações diferentes. Não desanime nem fale mal de uma coisa que você mal conhece. É possível e esperado que sua produtividade caia nas primeiras tentativas. Afinal, você está aprendendo. Lembre-se de como aprendeu a nadar ou andar de bicicleta. Tombos, água e sapos engolidos fazem parte do processo.
    2. Seja desobediente: afinal, a cultura de sua empresa não está escrita em pedra. Teste a ferramenta. Se você for bem sucedido, a empresa ganhou. Mostre os dados, fatos e ganhos. Se ainda assim você for proibido de usar a ferramenta, talvez seja hora de amarrar seu burrinho em outro lugar. Se você for mal sucedido, não desconsidere o que acabou de aprender. Pelo contrário, compartilhe!
    3. Seja aberto: e não perca tempo em debates bobinhos sobre ferramentas e métodos. Lembre-se sempre de que a quantidade de ferramentas dominadas é tão importante quanto a qualidade delas. É lógico que você terá as suas preferências. Por isso mesmo saberá quando um contexto não for favorável a elas. Você não quer queimar o filme de seus xodós, quer?
    4. Seja humilde: e não perca nunca a mentalidade de iniciante e a disposição para aprender. Immelt, na entrevista citada, diz que a resiliência (seu principal aprendizado) só se tornou possível quando ficou mais humilde. 
    5. Invista: As ferramentas formam parte considerável de seus ativos (tema do artigo anterior). Ativo largado é ativo depreciado. Faz quanto tempo que você não aprende e de fato aplica uma ferramenta nova? Se quiser alguma ajuda, consulte minha agenda acima, considere o investimento e volte ao passo #1.

    Notas

    1. Craig Larman e Bas Vodde pegaram carona nessa categorização. E chegaram a estruturar livros assim: Scaling Lean & Agile Development – Thinking and Organizational Tools for Large-Scale Scrum e Practices for Scaling Lean & Agile Development (Addison-Wesley, 2009 e 2010, respectivamente).
    2. Cito este projeto com uma ponta de orgulho e outra de inveja. Há semelhanças com o flit, ideia que apresentei há pouco mais de um ano. A grande diferença talvez esteja na minha ênfase nos Trabalhos a Executar (JTBD – Jobs to be Done) e em Ferramentas para Pensar, particularmente no Pensamento Sistêmico. Não tenho dúvidas de que o Agility Scales vingará. Daí a inveja. E gás novo para insistir nesse papo.
    3. Tool board, de Dean Wiles, ilusta este artigo.
  • Para Trabalhar

    Para Trabalhar

    O artigo anterior mostrou a escalada dos dados até a sabedoria, passando por informações, conhecimento e compreensão. Hoje subiremos em outra escada, das ferramentas até as metodologias. São novas entradas em nosso glossário comentado. Definições e redefinições necessárias em tempos de muita confusão.O gancho para este artigo apareceu na definição de conhecimento – “a capacidade de agir”. Se com informações respondemos as questões o que, quem, quando, onde e quanto, é com conhecimento que respondemos como (know-how). Para a realização de um trabalho qualquer, basta saber como executá-lo?

    Você seguiu passo a passo a receita daquele prato fantástico. Ficou tão gostoso quanto o da sua avó? João pensa ter executado os mesmos movimentos clássicos de Leônidas e Pelé. Fez o gol de bicicleta? Maria tentou se lembrar de todas perguntas essenciais ao desenvolver alguns requisitos. Os engenheiros entenderam o que ela quis dizer?

    Pois é, entre a teoria e a prática – dependendo do trabalho – pode haver um abismo. E não existem atalhos. Só praticando, errando, aprendendo e repetindo tudo de novo é que desenvolvemos habilidades.

    Inventamos ferramentas para facilitar os trabalhos. Podemos contar a nossa história através delas. Um dia tivemos pedras lascadas. Hoje carregamos smartphones repletos de apps. Existem ferramentas físicas (martelo, carro, liquidificador) e ferramentas conceituais (matemática, lógica e teoria da informação, por exemplo).

    Quando falamos sobre técnica, nos referimos ao modo de realizar um trabalho e/ou utilizar determinada ferramenta.

    Um método é um guia que nos ajuda a selecionar ferramentas e técnicas. Neste ponto nós bagunçamos bastante o coreto. Passamos a falar de processos, frameworks, metodologias e métodos como se esses termos fossem intercambiáveis.

    Processo pressupõe repetição: mesmas entradas, mesmo trabalho, mesmas saídas. Confundi-lo com projetos não cai bem. Porque cada projeto, por definição, é único: tem entradas, trabalho e saídas diferentes. “Processos são à prova de idiotas“, escreveu Dave Gray¹. Alguém tomou todas as decisões antes; Seu executor está dispensado de pensar. Ainda não inventamos uma maneira de abrir mão de cérebros em um projeto. Por isso, para estes, faz mais sentido falar em método – guia. 

    Framework, algo como “modelo de trabalho”, deveria ir para o mesmo balaio dos offs, sale, black fridays, stakeholders, ideation, elicitation, embromation e afins.

    Chegamos, enfim, em metodologia. Uma metodologia traduz para a prática uma teoria. Toda metodologia parte de princípios. E orienta a seleção de métodos de trabalho. Metodologia também significa o estudo dos métodos. Por definição, ela sempre propõe melhorias. Deveria…

    Resumindo: uma metodologia nos ajuda a escolher métodos. Métodos guiam a seleção de ferramentas e técnicas. Ferramentas, quando utilizadas com a devida técnica, nos ajudam a realizar um trabalho de forma produtiva.

    O trabalhador do século 21 é um atencioso curador e colecionador de métodos e ferramentas. Mas não se limita a utilizá-los. Ele também os combina, altera e até inventa novos. Quando chega nesse nível, nem o céu é um limite.

    “O bom trabalhador é conhecido pelas suas ferramentas.”
    – Provérbio

    Notas

    1. A Empresa Conectada, p. 201 (Novatec, 2013).
    2. Russell Ackoff é a fonte do texto acima, pra variar.
    3. Stairway to Heaven é o título da inspirada imagem de hoje. Por svenwerk, no flickr.
      Ooh, it makes me wonder…
  • Para Trabalhar

    Para Trabalhar

    O artigo anterior mostrou a escalada dos dados até a sabedoria, passando por informações, conhecimento e compreensão. Hoje subiremos em outra escada, das ferramentas até as metodologias. São novas entradas em nosso glossário comentado. Definições e redefinições necessárias em tempos de muita confusão.O gancho para este artigo apareceu na definição de conhecimento – “a capacidade de agir”. Se com informações respondemos as questões o que, quem, quando, onde e quanto, é com conhecimento que respondemos como (know-how). Para a realização de um trabalho qualquer, basta saber como executá-lo?

    Você seguiu passo a passo a receita daquele prato fantástico. Ficou tão gostoso quanto o da sua avó? João pensa ter executado os mesmos movimentos clássicos de Leônidas e Pelé. Fez o gol de bicicleta? Maria tentou se lembrar de todas perguntas essenciais ao desenvolver alguns requisitos. Os engenheiros entenderam o que ela quis dizer?

    Pois é, entre a teoria e a prática – dependendo do trabalho – pode haver um abismo. E não existem atalhos. Só praticando, errando, aprendendo e repetindo tudo de novo é que desenvolvemos habilidades.

    Inventamos ferramentas para facilitar os trabalhos. Podemos contar a nossa história através delas. Um dia tivemos pedras lascadas. Hoje carregamos smartphones repletos de apps. Existem ferramentas físicas (martelo, carro, liquidificador) e ferramentas conceituais (matemática, lógica e teoria da informação, por exemplo).

    Quando falamos sobre técnica, nos referimos ao modo de realizar um trabalho e/ou utilizar determinada ferramenta.

    Um método é um guia que nos ajuda a selecionar ferramentas e técnicas. Neste ponto nós bagunçamos bastante o coreto. Passamos a falar de processos, frameworks, metodologias e métodos como se esses termos fossem intercambiáveis.

    Processo pressupõe repetição: mesmas entradas, mesmo trabalho, mesmas saídas. Confundi-lo com projetos não cai bem. Porque cada projeto, por definição, é único: tem entradas, trabalho e saídas diferentes. “Processos são à prova de idiotas“, escreveu Dave Gray¹. Alguém tomou todas as decisões antes; Seu executor está dispensado de pensar. Ainda não inventamos uma maneira de abrir mão de cérebros em um projeto. Por isso, para estes, faz mais sentido falar em método – guia. 

    Framework, algo como “modelo de trabalho”, deveria ir para o mesmo balaio dos offs, sale, black fridays, stakeholders, ideation, elicitation, embromation e afins.

    Chegamos, enfim, em metodologia. Uma metodologia traduz para a prática uma teoria. Toda metodologia parte de princípios. E orienta a seleção de métodos de trabalho. Metodologia também significa o estudo dos métodos. Por definição, ela sempre propõe melhorias. Deveria…

    Resumindo: uma metodologia nos ajuda a escolher métodos. Métodos guiam a seleção de ferramentas e técnicas. Ferramentas, quando utilizadas com a devida técnica, nos ajudam a realizar um trabalho de forma produtiva.

    O trabalhador do século 21 é um atencioso curador e colecionador de métodos e ferramentas. Mas não se limita a utilizá-los. Ele também os combina, altera e até inventa novos. Quando chega nesse nível, nem o céu é um limite.

    “O bom trabalhador é conhecido pelas suas ferramentas.”
    – Provérbio

    Notas

    1. A Empresa Conectada, p. 201 (Novatec, 2013).
    2. Russell Ackoff é a fonte do texto acima, pra variar.
    3. Stairway to Heaven é o título da inspirada imagem de hoje. Por svenwerk, no flickr.
      Ooh, it makes me wonder…