Tim Lister - co-autor de livros

• O fator humano. Projetos e equipes de sucesso "(o livro original é chamado de" Peopleware ")
• “Valsando com os Ursos: Gerenciamento de Riscos em Projetos de Desenvolvimento de Software”
• “Incrível com padrões de adrenalina e zumbis. Padrões de comportamento da equipe do projeto

Todos esses livros são clássicos em seu campo e são escritos com colegas da Atlantic Systems Guild . Na Rússia, seus colegas são mais famosos - Tom Demarco e Peter Khrushchka , que também escreveu muitas obras famosas.

Tim tem 40 anos de experiência em desenvolvimento de software, em 1975 (ninguém que escreveu este hubrast nasceu este ano), Tim já era vice-presidente executivo da Yourdon Inc. Agora ele está envolvido em consultoria, treinamento e redação, participando de tempos em tempos em conferências em todo o mundo com relatórios .

Especialmente para Habr, fizemos uma entrevista com Tim Lister. Ele abrirá a conferência DevOops 2019 e acumulamos muitas perguntas sobre livros e muito mais. As entrevistas são conduzidas por Mikhail Druzhinin e Oleg Chirukhin, do comitê do programa da conferência.

Michael: Você poderia dizer algumas palavras sobre o que está fazendo agora?

Tim: Eu sou o chefe da Atlantic Systems Guild. Há seis de nós na guilda, nos chamamos diretores. Três nos EUA e três na Europa - é por isso que o Clã é chamado de Atlântico. Estamos juntos há tantos anos que você simplesmente não conta. Todos nós temos nossas próprias especialidades. Na última década, ou até mais, tenho trabalhado com clientes. Meus projetos incluem não apenas gerenciamento, mas também a definição de requisitos, planejamento e avaliação de projetos. Parece que projetos que começam mal geralmente acabam mal. Portanto, você deve garantir que todas as atividades sejam realmente bem planejadas e concordar que as idéias dos criadores sejam combinadas. Vale a pena considerar o que você está fazendo e por quê. Quais estratégias usar para concluir o projeto.

Por muitos anos, tenho assessorado clientes de várias maneiras. Um exemplo interessante é uma empresa que fabrica robôs para cirurgia nas articulações do joelho e quadril. O cirurgião não opera completamente de forma independente, mas usa um robô. A segurança aqui, francamente, é importante. Mas quando você tenta discutir requisitos com pessoas focadas na solução de problemas ... Parece estranho, mas nos EUA existe o FDA (Federal Drug Administration), que licencia produtos como esses robôs. Antes de vender e usar algo em pessoas vivas, você precisa obter uma licença. Uma das condições é mostrar seus requisitos, quais são os testes, como você os testou, quais são os resultados. Se você alterar os requisitos, precisará repetir todo esse imenso processo de teste repetidamente. Nossos clientes conseguiram incluir o design visual dos aplicativos em seus requisitos. Eles fizeram capturas de tela diretamente como parte dos requisitos. Temos que retirá-los e explicar que, na maior parte dos casos, todos esses programas não sabem nada sobre joelhos e quadris, todas essas coisas com a câmera etc. Precisamos reescrever os documentos com os requisitos para que eles nunca mudem, a menos que algumas condições fundamentais realmente importantes sejam alteradas. Se não houver design visual nos requisitos, a atualização do produto será muito mais rápida. Nosso trabalho é encontrar os elementos que lidam com operações nos joelhos, quadris, costas, puxá-los para documentos separados e dizer que serão requisitos fundamentais. Vamos fazer um grupo isolado de requisitos sobre cirurgia no joelho. Isso criará um conjunto mais robusto de requisitos. Falaremos sobre toda a linha de produtos, e não sobre instâncias específicas de robôs.

Muito trabalho foi feito, mas, no entanto, chegaram aos locais onde haviam passado semanas e meses de testes repetidos sem significado e necessidade, porque seus requisitos, descritos no papel, não coincidiam com os requisitos reais nos quais os sistemas foram construídos. Cada vez que o FDA disse a eles: seus requisitos foram alterados, agora você precisa verificar tudo do zero. Verificações cruzadas completas de todo o produto mataram a empresa.

Portanto, existem tarefas maravilhosas quando você se encontra no começo de algo interessante, e as primeiras ações estabelecem regras adicionais do jogo. Se você fizer isso do ponto de vista gerencial e técnico, essa atividade inicial começará a funcionar bem, há uma chance na saída de obter um excelente projeto. Mas se essa parte saiu dos trilhos e deu errado, se você não encontrar o acordo fundamental ... não, não que seu projeto necessariamente falhe. Mas você não será capaz de dizer: "Somos ótimos, fizemos tudo de maneira realmente eficaz". Essas são as coisas que faço, comunicando-me com os clientes.

Michael: Ou seja, você lança projetos, realiza algum tipo de kickoff e verifica se os trilhos levam na direção certa?

Tim: Também temos idéias sobre como reunir todas as peças do mosaico: de quais habilidades precisamos, quando exatamente são necessárias, como é o núcleo da equipe e outras coisas fundamentais. Precisamos de funcionários em período integral ou podemos recrutar alguém em meio período? Planejamento, gestão. Perguntas como: o que é mais importante para esse projeto em particular? Como conseguir isso? O que sabemos sobre esse produto ou projeto, quais são os riscos e onde é desconhecido, como vamos lidar com tudo isso? É claro que alguém neste momento começa a gritar "Mas e quanto ágil?!". Bem, vocês são todos flexíveis, mas e daí? Como é exatamente o projeto, como você o retirará para que ele se encaixe no projeto? Você não pode simplesmente dizer que "nossa abordagem é motivada por qualquer coisa, somos uma equipe de scrum!" Isso é um absurdo e um absurdo. Para onde você vai depois, por que deveria ganhar, onde está o ponto? Eu ensino meus clientes a refletir sobre todas essas questões.

19 anos de prisão

Michael: Em Ajail, as pessoas geralmente tentam não determinar nada com antecedência, mas tomam decisões o mais tarde possível, dizendo: somos grandes demais, não pensarei na arquitetura geral. Não vou pensar em várias outras coisas; agora, fornecerei ao cliente algo funcionando.

Tim: Acho que metodologias ágeis, começando com o Agile Manifesto em 2001, abriram os olhos da indústria. Mas, por outro lado, nada é perfeito. Estou inteiramente do lado do desenvolvimento iterativo. As iterações fazem muito sentido na maioria dos projetos. Mas você precisa pensar na pergunta: depois que o produto saiu e começou a ser usado, por quanto tempo ele dura? Este é um produto que dura seis meses e depois é substituído por outro? Ou é um produto que funcionará por muitos e muitos anos? Claro, não vou citar nomes, mas ... Em Nova York e sua comunidade de financiadores, os sistemas mais fundamentais são muito antigos. Isso é incrível. Você olha para eles e pensa que voltaria no tempo, em 1994, e diria aos desenvolvedores: “Eu vim do futuro, a partir de 2019. Basta projetar este sistema quantas vezes você precisar. Torne-o extensível, pense sobre a arquitetura. Ele será aprimorado por mais de vinte e cinco anos. Se você atrasar um pouco mais o desenvolvimento - ninguém perceberá isso em uma escala da história! ” Ao avaliar as coisas a longo prazo, é preciso considerar quanto custará na sua totalidade. Às vezes, uma arquitetura bem projetada realmente vale a pena, e às vezes não. Você precisa olhar em volta e se perguntar: estamos em uma situação adequada para essa solução?

Portanto, uma ideia do tipo "Somos ágeis, o próprio cliente nos dirá o que deseja receber" - é supernativo. Afinal, os clientes nem sabem o que querem e, mais ainda, não sabem o que poderiam obter. Alguns começarão a citar exemplos históricos como argumentos, eu já vi isso. Mas pessoas tecnicamente avançadas geralmente não dizem isso. Eles dizem: "Agora é o ano de 2019, temos essas oportunidades e podemos mudar completamente nossa visão de tais coisas!" Em vez de imitar as soluções existentes, tornando-as um pouco mais bonitas e penteadas, às vezes você precisa sair e dizer: "Vamos reinventar completamente o que estamos tentando fazer aqui!"

E eu não acho que a maioria dos clientes possa pensar em um problema dessa maneira. Eles vêem apenas o que já têm, e é isso. Depois, eles vêm com solicitações como "vamos facilitar um pouco" ou o que eles costumam dizer. Mas não somos garçons e garçonetes para fazer um pedido, por mais estúpido que seja, e depois assá-lo na cozinha. Nós somos os guias deles. Devemos abrir os olhos e dizer: ei, aqui temos novas oportunidades! Você percebe que podemos realmente mudar a forma como essa parte do seu negócio é feita? Um dos problemas do adjayl é que ele se afasta da consciência do que é uma oportunidade, do que é um problema, do que precisamos fazer, de quais tecnologias disponíveis são mais adequadas para essa situação específica.

Talvez eu tenha ido longe demais com ceticismo: muitas coisas maravilhosas estão acontecendo na comunidade ágil. Mas tenho um problema com o fato de que, em vez de definir um projeto, as pessoas começam a encolher os ombros. Eu perguntaria aqui - o que estamos fazendo, como vamos fazer isso? E, de alguma maneira mágica, sempre acontece que esse cliente deve saber o melhor de tudo. Mas o cliente sabe o melhor de tudo apenas quando escolhe coisas já construídas por alguém. Se eu quiser comprar um carro e souber o tamanho do orçamento da família, vou buscar rapidamente um carro adequado ao meu estilo de vida. Aqui eu sei tudo melhor do que ninguém! Mas, por favor, observe que alguém já fabricou a máquina. Como inventar um carro novo, não faço ideia, não sou especialista. Quando criamos produtos personalizados ou alguns produtos especiais, a voz do cliente deve ser levada em consideração, mas essa não é a única voz.

Oleg: Você mencionou o Agile Manifesto. De alguma forma, precisamos atualizá-lo ou revisá-lo, levando em consideração o entendimento atual do problema?

Tim: Eu não tocaria nele. Eu acho que este é um ótimo documento histórico. Quero dizer, ele é o que ele é. Ele tem 19 anos, ele é velho, mas ao mesmo tempo ele fez uma revolução. O que ele fez bem foi lançar uma reação, eles começaram a sussurrar sobre ele. Provavelmente, você não trabalhou no setor em 2001, mas todos trabalharam nos processos. Instituto de Engenharia de Software, Cinco Níveis do Modelo de Potencial de Integridade de Software (CMMI). Não sei se essas lendas da antiguidade dizem algo profundo, mas foi um grande avanço. A princípio, as pessoas acreditavam que, se os processos fossem construídos corretamente, os próprios problemas iriam evaporar. E então o Manifesto aparece e diz: "Não, não, não - estaremos baseados em pessoas, não em processos". Somos mestres em desenvolvimento de software. Entendemos que o processo ideal é uma miragem, não é. Há muita idiossincrasia nos projetos; a ideia de um processo único e sem falhas para todos os projetos não faz sentido. Os problemas são complexos demais para afirmar que uma única solução foi encontrada para tudo (oi, nirvana).

Não pretendo olhar para o futuro, mas direi que as pessoas começaram a pensar mais em projetos. Eu acho que o Manifesto Ágil é muito bom, ele pula para frente e diz: “Ei! Você está em um navio e você mesmo está liderando este navio. Você terá que tomar uma decisão - não solicitaremos uma receita universal para todas as situações. Você é a tripulação do navio e, se for bom o suficiente, poderá encontrar o caminho para a meta. Havia outros navios à sua frente, e outros navios estarão atrás de você, mas, de certa forma, sua jornada é única. Algo assim! Esta é uma maneira de pensar. Para mim, nada é novo sob a lua, as pessoas navegaram mais cedo e nadarão de novo, mas para você esta é a sua principal viagem, e não vou lhe dizer exatamente o que vai acontecer com você. Você deve ter as habilidades do trabalho em equipe coordenado e, se realmente forem, tudo dará certo e você chegará onde quiser.

Peopleware: 30 anos depois

Oleg: Peopleware também foi uma revolução, como o Manifesto?

Tim: Peopleware ... Tom e eu escrevemos este livro, mas não achamos que tudo iria acontecer. De alguma forma, ressoou com as idéias de muitas pessoas. Este foi o primeiro livro que disse: desenvolvimento de software é uma atividade muito intensiva em humanos. Apesar de nossa natureza técnica, também somos uma comunidade de pessoas que constroem algo grande, mesmo enorme, muito complexo. Ninguém pode criar essas coisas sozinho, certo? Portanto, a ideia de uma "equipe" se tornou muito importante. E não apenas do ponto de vista da gerência, mas também para pessoas de um armazém técnico que se uniram para resolver problemas profundos realmente complexos com um monte de incógnitas. Para mim, pessoalmente, ao longo da minha carreira, esse foi um enorme teste de inteligência. E aqui você precisa ser capaz de dizer: sim, esse problema é mais do que eu posso resolver, mas juntos podemos encontrar uma solução elegante da qual podemos nos orgulhar. E acho que essa ideia em particular ressoou mais. A idéia é que trabalhemos parte do tempo por conta própria, parte do grupo, e muitas vezes a decisão é tomada pelo grupo. A solução de problemas em grupo rapidamente se tornou uma característica importante de projetos complexos.

Apesar do fato de Tim ter um grande número de relatórios, há muito poucos deles publicados no YouTube. Você pode ver o relatório 2007 The Return of Peopleware. A qualidade, é claro, deixa muito a desejar.

Michael: Alguma coisa mudou nos últimos 30 anos desde o lançamento do livro?

Tim: Você pode ver de muitos ângulos diferentes. Falando sociologicamente ... uma vez, em tempos mais simples, você e a equipe estavam no mesmo escritório. Você pode estar lá todos os dias, tomar café juntos e discutir o trabalho. O que realmente mudou é que agora as equipes podem ser distribuídas geograficamente, em diferentes países e fusos horários, mas, no entanto, estão trabalhando na mesma tarefa, e isso adiciona uma nova camada de complexidade. Pode parecer antiquado, mas não há nada melhor do que a comunicação cara a cara; quando todos se reúnem, trabalham juntos, podem ir a um colega e dizer: veja, eu descobri como você se sente sobre isso? As conversas cara a cara oferecem uma maneira rápida de avançar em direção à comunicação informal, e acho que isso deve apelar para adiar também os amantes. E estou preocupado porque, na realidade, o mundo acabou sendo muito pequeno, e agora está coberto por equipes distribuídas, e tudo isso é muito complicado.

Todos vivemos no DevOps

Michael: Mesmo do ponto de vista do comitê do programa da conferência, temos pessoas na Califórnia, em Nova York, Europa, Rússia ... em Cingapura, ainda não há ninguém. A diferença na geografia é bastante grande e as pessoas começam a se distribuir ainda mais. Se já estamos falando sobre desenvolvimento, você pode nos falar mais sobre devops e a destruição de obstáculos entre equipes? Existe um conceito de que todo mundo está sentado em seus bunkers, e agora os bunkers estão desmoronando, como você gosta dessa analogia?

Tim: Parece-me que, à luz dos recentes avanços tecnológicos, os devops são de grande importância. Anteriormente, você tinha equipes de desenvolvedores e administradores, eles trabalhavam, trabalhavam, trabalhavam e, em algum momento, apareceu uma coisa com a qual você poderia procurar os administradores e distribuí-lo ao produto. E aqui começou a conversa sobre o bunker, porque os administradores são como aliados, não inimigos, pelo menos, mas você só conversou com eles quando tudo estava pronto para ser colocado à venda. Você foi até eles com alguma coisa e disse: olha, qual é a nossa aplicação, mas você poderia implementá-la? E agora todo o conceito de entrega mudou para melhor. Quero dizer, surgiu a ideia de que você pode pressionar as mudanças rapidamente. Podemos atualizar produtos em tempo real. Eu sempre sorrio quando um Firefox aparece no meu laptop e diz: ei, atualizamos o Firefox em segundo plano e, assim que você tiver um minuto, clique aqui e forneceremos uma nova versão. E eu sou como: "Oh sim, baby!" Enquanto eu dormia, no meu computador eles estavam trabalhando para me fornecer uma nova versão. Isso é maravilhoso, incrível.

Mas aqui está a dificuldade: você tem esse recurso com atualizações de software, mas integrar pessoas é muito mais difícil. O que quero dizer na palestra do DevOops é que agora temos muito mais jogadores do que nunca. Se você pensar em todos que participam do trabalho de apenas uma equipe ... Você pensou nisso como uma equipe, e é muito mais do que apenas uma equipe de programadores. São testadores, gerentes de projeto e várias outras pessoas. E todo mundo tem seus próprios pontos de vista sobre o mundo. Os gerentes de produto são completamente diferentes dos gerentes de projeto. Os administradores têm suas próprias tarefas. Torna-se um problema bastante difícil coordenar todos os participantes, para continuar a estar ciente do que está acontecendo e não sair das bobinas. É necessário separar as tarefas do grupo e as tarefas relacionadas a todos. Esta é uma tarefa muito difícil. Por outro lado, acho que tudo isso se tornou muito melhor do que uma vez há muitos anos. Este é exatamente o caminho em que as pessoas crescem e aprendem a se comportar corretamente. Quando você está envolvido na integração, entende que não deve haver desenvolvimento clandestino para que, no último momento, o software não saia da caixa: veja o que fizemos aqui! A idéia é que você pode fazer integração e desenvolvimento e, no final, será implementado de maneira organizada e iterativa. Tudo isso é de grande importância para mim. Isso possibilita criar mais valor para os usuários do sistema e para o seu cliente.

Michael: Toda a idéia do Devopse é entregar um trabalho significativo o mais cedo possível. Vejo que o mundo começou a acelerar cada vez mais. Como se adaptar a essas acelerações? Dez anos atrás, isso não era!

Tim: Claro, todo mundo quer mais e mais funcionalidade. Não há necessidade de se mover, apenas empilhe mais. Às vezes, você precisa desacelerar para que a próxima atualização incremental traga pelo menos algo útil - e isso é completamente normal.

A idéia de que você precisa executar, executar, executar não é a melhor. Dificilmente alguém quer viver assim. Eu gostaria que o ritmo das entregas definisse o próprio ritmo do projeto. Se você apenas produz um fluxo de coisas pequenas, relativamente sem sentido, tudo isso no total não faz sentido. Em vez de tentar descartar as coisas o mais cedo possível, o que vale a pena discutir com os principais desenvolvedores e gerentes de produto e projeto é a estratégia. Isso faz algum sentido?

Padrões e antipadrões

Oleg: Você costuma falar sobre padrões e antipadrões, e essa é a diferença entre a vida e a morte dos projetos. E agora, os devops invadem nossas vidas. Ele tem algum de seus próprios padrões e antipadrões que podem matar o projeto no local?

Tim: Padrões e antipadrões ocorrem o tempo todo. Sobre o que falar. Bem, há uma coisa que chamamos de "coisas brilhantes". As pessoas realmente gostam muito de novas tecnologias. Eles são simplesmente enfeitiçados pelo brilho de tudo que parece legal e estiloso, e param de fazer perguntas: é mesmo necessário? O que vamos alcançar? Isso é confiável, faz algum sentido? Costumo ver pessoas, digamos, na vanguarda da tecnologia. Eles estão hipnotizados pelo que está acontecendo no mundo. Mas se você olhar mais de perto, o que eles fazem de bom - muitas vezes, simplesmente não há nada de útil!

, – , , . 1969. , – 1969 , 1960 62, NASA , . – , ! -, , , . : «, , , , !». - … , . , , , , , . , : « !».

: , ?

: , ! … , , -. ! , , , – . , , ? ! . , . , , … – . : . , .

: , « , »: ?

: . - . – - , , ? , – . , , - : « ! !». Sério? .

«-»

: . - , «-» . : , , «-», ? , – , - .

: -. - . - , . , , , ! , , «-», , , ? – . , «» — , ? . - , , , . , ?

, , , , – . , - , - – . , DevOps, , - . , , , . « », « » , , – «».

- , , . , , . – , « ». ? , , . - , , , , , . , - , , , , . ! - .

- -. , , ? , , ? - : --, , , , , .

, , . , . , , : , . , . , . .

. – , , , , , , ! - . – …

« »

: ? , , , – « ».

: ! – , - . - , ( , ). – , – , - , .

, . , « - , ». , -, , . , , . , , , , , . , , , – , . , . , .

: , . , , . , . , – , – . , , , .

: Move fast and break things!

: , , , – -. , ?

: : . . , - , . , , - , « », , : « ». , . , , . – .

, . , , , - . - , , . , – , , , , . , , , . .

, , . , – , . , , , , , ? ? , ? , : , . , , , - . : , .

, . , : , , - , . , , . , , , .

, ? , . , . 100%, : «, , !». . – , , , ! , , , : « – , – ». , - .

, , – . , . . !

: . , . ?

: , , – . , . - ? , , , , . , , . « , – ». . ( !) , . . , , – , . , . , . , , , , , , … , , . , , . . , , , !

: , , - , (, ) .

Tim: Certo. Eu acho que os melhores técnicos, se você olhar de perto, eles são como gerentes para si mesmos. Como formulá-lo ...

Oleg: Sua vida é seu projeto que você gerencia.

Tim: Certo! Quero dizer, você assumiu a responsabilidade, entende o problema e entra em contato com as pessoas quando vê que suas decisões podem afetar o trabalho delas, tudo com esse espírito. Não se trata apenas de sentar à mesa, fazer o seu trabalho e nem saber o que está acontecendo por aí. Não não não A propósito, uma das melhores coisas do Agile é que eles sugeriram sprints curtos, porque o estado de coisas de todos os participantes é bem observado, eles podem assistir juntos. Todos os dias conversamos um sobre o outro.

Como entrar no gerenciamento de riscos

Oleg: Existe alguma estrutura formal de conhecimento nessa área? Por exemplo, sou desenvolvedor Java e quero entender o gerenciamento de riscos sem me tornar um gerente de projetos de educação real. Provavelmente, primeiro li “Quanto um projeto de software”, de McConnell, e depois o que? Quais são os primeiros passos?

Tim: O primeiro é começar a se comunicar com as pessoas no projeto. Isso proporciona uma melhoria instantânea na cultura da comunicação com os colegas. Você precisa começar abrindo tudo por padrão, em vez de ocultá-lo. Diga: estas são as coisas que me incomodam, essas são as coisas que me mantêm acordado à noite, hoje eu acordei à noite e assim: deuses, isso deve ser considerado! Os outros veem a mesma coisa? Como grupo, devemos responder a esses problemas em potencial? Você deve poder manter uma discussão sobre esses tópicos. Não existe uma fórmula pré-preparada pela qual trabalhamos. Esta não é a produção de hambúrgueres, é tudo sobre pessoas. “Fiz um cheeseburger - vendi um cheeseburger” - isso não é sobre nós, e é por isso que eu amo tanto esse trabalho. Eu gosto quando tudo o que os gerentes faziam agora se torna propriedade da equipe.

Oleg: Você disse em livros e entrevistas que as pessoas estão mais preocupadas com a felicidade do que com os números no gráfico. Por outro lado, quando você diz à equipe: mudamos para devops, e agora o programador deve se comunicar constantemente, isso pode estar muito além de sua zona de conforto. E neste momento, ele pode, digamos assim, ser profundamente infeliz. O que fazer nesta situação?

Tim: Não sei exatamente o que fazer. Se o desenvolvedor é muito isolado, ele não vê por que o trabalho é feito, ele apenas olha para sua parte do trabalho e precisa se aprofundar no que eu chamo de “contexto”. Ele precisa descobrir como tudo está interconectado. E, claro, não quero dizer a apresentação formal ou algo assim. Eu digo que você precisa se comunicar com os colegas sobre o trabalho como um todo, e não apenas sobre a parte pela qual você é responsável. E, neste momento, você pode começar a discutir idéias, acordos gerais, para que seu trabalho corra bem e como se apoiar em um problema comum.

Para se adaptar, os técnicos geralmente também querem enviá-los para treinamentos, discutir treinamentos. Um amigo meu gosta de dizer que o treinamento é para cães. Há treinamento para pessoas. Uma das melhores coisas para ensinar a um desenvolvedor é a comunicação com os colegas. Se alguém realmente conseguiu algo, você deve ver como ele funciona, ou discutir com ele, ou algo assim. Alguns Kent Beck condicionais constantemente falavam sobre programação extrema. É engraçado, porque XP é uma ideia tão simples, mas causa muitos problemas. Para alguém, fazer XP é como se fosse forçado a se despir na frente dos amigos. Eles verão o que estou fazendo! Eles são meus colegas, eles não apenas verão, mas também entenderão! Horrível Alguém está começando a ficar seriamente nervoso. Mas quando você percebe que esta é a melhor maneira de aprender, tudo muda. Você trabalha em estreita colaboração com as pessoas, e algumas pessoas entendem o assunto muito melhor do que você.

Michael: Mas tudo isso faz você sair da sua zona de conforto. Como engenheiro, você deve sair da sua zona de conforto, comunicar-se. Como uma pessoa que resolve problemas, você deve constantemente se colocar em uma posição fraca e considerar o que pode dar errado. Esse trabalho é inerentemente projetado para ser inconveniente. Você se coloca conscientemente em situações estressantes. Geralmente, as pessoas fogem deles, as pessoas gostam de ser crianças felizes.

Tim: O que pode ser feito, você pode sair e dizer abertamente: “Tudo está em ordem, eu posso lidar com isso! Não estou sozinho em desconforto. Vamos discutir várias coisas desconfortáveis, todas juntas, como uma equipe! ” Estes são os nossos problemas comuns, devemos lidar com eles, entendeu? Eu acho que os brilhantes desenvolvedores idiossincráticos - eles são como mamutes, eles desapareceram. Sim, e eles têm um valor muito limitado. Se você não consegue se comunicar, não pode participar normalmente. Portanto, apenas diga. Seja honesto e aberto. Lamento muito que alguém seja desagradável. Imagine, há muitos anos, houve um estudo segundo o qual o principal medo nos EUA não é a morte, mas adivinhem? Medo de falar em público! Portanto, em algum lugar há pessoas com maior probabilidade de morrer do que dizer um elogio em voz alta. E você, eu acho, tem apenas algumas habilidades básicas, dependendo do que você faz. Habilidades de conversação, habilidades de escrita - mas tanto quanto for realmente necessário em seu trabalho. Se você trabalha como analista, mas não consegue ler, escrever e falar, infelizmente não terá nada para fazer nos meus projetos!

Preço da comunicação

Oleg: O uso desses funcionários cessantes é mais caro por vários motivos? No final, eles falam constantemente em vez de trabalhar!

Tim: Eu tinha em mente o núcleo da equipe, e geralmente não todos seguidos. Se você tem um especialista que realmente configura seus bancos de dados de forma legal, adora configurá-los e continuará a configurá-los pelo resto da sua vida, e isso é legal, continue assim. Mas estou falando de pessoas que querem viver no próprio projeto. O núcleo da equipe, destinado ao desenvolvimento do projeto. Essas pessoas realmente precisam se comunicar constantemente. E, especialmente, no início do projeto, quando você discute riscos, maneiras de atingir objetivos globais e similares.

Michael: Isso se aplica a todos os envolvidos no projeto, independentemente de especialização, habilidades e maneiras de trabalhar. Todos vocês estão interessados ​​no sucesso do projeto.

Tim: Sim, você sente que está profundamente imerso no projeto, que sua tarefa é ajudar o projeto a se tornar realidade. Seja você programador, analista, designer de interfaces, qualquer pessoa. É por isso que venho trabalhar todas as manhãs, e é isso que fazemos. Somos responsáveis ​​por todas essas pessoas, independentemente de suas habilidades. Este é um grupo de pessoas que têm conversas com adultos.

Oleg: Na verdade, falando sobre funcionários falantes, tentei simular as objeções das pessoas, em particular dos gerentes que são oferecidos a mudar para devops, para toda essa nova visão do mundo. E para você, como consultores, essas objeções devem ser conhecidas muito melhor do que para mim, como desenvolvedor! Compartilhar o que os gerentes mais gostam?

Tim: Gerentes? Hum. Na maioria das vezes, os gerentes estão sob pressão de problemas, antes da necessidade de liberar algo com urgência e fazer uma entrega e coisas do tipo. Eles nos assistem constantemente discutindo e discutindo, e vêem assim: conversas, conversas, conversas ... Que outras conversas? Volte ao trabalho! Porque conversas não lhes parecem trabalho. Você não escreve código, não testa software, aparentemente não faz nada - por que não enviar você para fazer negócios? Afinal, a entrega já está em um mês!

Michael: Vá escrever código!

Tim: Parece-me que eles não estão preocupados com o trabalho, mas com a falta de visibilidade do avanço. Para que eles pensem que estamos nos aproximando do sucesso, eles precisam ver como pressionamos os botões do teclado. O dia todo, de manhã a noite. Este é o problema número um.

Oleg: Misha, você pensou em algo.

Michael: Desculpe, pensei, peguei um flashback. Tudo isso me lembrou de um comício interessante que aconteceu ontem ... Ontem houve muitos comícios ... E tudo isso parece muito familiar!

Vida sem salários

Tim: A propósito, não é necessário organizar "reuniões" para comunicação. Quero dizer, as discussões mais úteis entre os desenvolvedores ocorrem quando eles apenas conversam entre si. Você entra de manhã com uma xícara de café e lá nós cinco nos reunimos e discutimos algo técnico ferozmente. Para mim, se eu sou o gerente deste projeto, é melhor sorrir e ir a algum lugar da sua empresa, deixe-os discutir. Eles já estão envolvidos o máximo possível. Este é um bom sinal.

Oleg: A propósito, aqui você tem um monte de notas em seu livro sobre o que é bom e o que é ruim. Você usa algum deles você mesmo? Relativamente falando, aqui você tem uma empresa agora, e até uma estrutura muito heterodoxa ...

Tim: Não ortodoxo, mas esse dispositivo é ótimo para nós. Nos conhecemos há muito tempo. Confiamos um no outro, confiamos um no outro muito antes de nos tornarmos parceiros. E, por exemplo, não temos salários. Nós apenas trabalhamos e, por exemplo, se eu ganhei dinheiro com meus clientes, o dinheiro foi todo para mim. Depois disso, pagamos as taxas de associação à organização, e isso é suficiente para manter a própria empresa. Além disso, todos nos especializamos em coisas diferentes. Por exemplo, trabalho com contadores, preenche declarações fiscais, faço todos os tipos de tarefas administrativas para a empresa e ninguém me paga por isso. James e Tom trabalham em nosso site e ninguém os paga também. Contanto que você pague suas dívidas, ninguém pensará em lhe dizer o que você precisa fazer. Por exemplo, Tom agora trabalha muito menos do que antes. Agora ele tem outros interesses, algo que ele não faz pela Guilda. Mas enquanto ele pagar suas dívidas, ninguém o procurará e dirá: "Ei Tom, venha e trabalhe!" É muito fácil lidar com colegas quando não há dinheiro entre vocês. E agora nosso relacionamento é uma das idéias fundamentais, aplicada a diferentes especialidades. Funciona e funciona muito bem.

Melhor conselho

Michael: Voltando ao "melhor conselho", há algo que você repete para seus clientes repetidamente? Há uma ideia sobre 80/20 e, com certeza, alguns conselhos são repetidos com mais frequência.

Tim: Uma vez eu pensei que se você escrever um livro como “Waltzing with the Bears”, isso mudará o curso da história e as pessoas vão parar, mas ... Bem, veja, muitas vezes as empresas fingem que estão indo bem. Assim que algo ruim aconteceu, foi um choque e uma surpresa para eles. “Olha, nós testamos o sistema, e ele não passa em nenhum teste do sistema, e são mais três meses de trabalho extraordinário, como isso pôde acontecer? Quem sabia O que poderia ter dado errado? Sério, você acredita nisso?

Estou tentando explicar que você não deve ficar muito bravo com a situação atual. Você precisa discuti-lo, para entender realmente o que poderia ter dado errado e como evitar essas coisas no futuro. Se, no entanto, o problema se manifesta, como vamos combatê-lo, como contê-lo.

Para mim, tudo parece assustador. As pessoas lidam com problemas complexos e desagradáveis ​​e continuam fingindo que, se simplesmente cruzam os dedos e esperam o melhor, esse "melhor" realmente acontecerá. Não, isso não funciona.

Participe do gerenciamento de riscos!

Michael: Na sua opinião, quantas organizações estão envolvidas no gerenciamento de riscos?

Tim: O que mais me enfurece é que as pessoas anotam os riscos, olham para a lista resultante e vão trabalhar. De fato, identificar riscos para eles é gerenciamento de riscos. Mas para mim isso parece uma razão para a pergunta: bem, há uma lista, o que exatamente você vai mudar? Você precisa alterar sua sequência padrão de ações, levando em consideração esses riscos. Se houver uma parte mais difícil do trabalho, você precisará fazê-lo e só então passar para a mais simples. Nos primeiros sprints, comece a resolver problemas complexos. Agora, isso é semelhante ao gerenciamento de riscos. Mas geralmente as pessoas não podem dizer o que mudaram depois de compilar uma lista de riscos.

Michael: E, no entanto, quantas dessas empresas de gerenciamento de risco são cinco por cento?

Tim: Infelizmente, é desagradável dizer isso, mas essa é uma parte muito insignificante. Mas mais de cinco, porque existem realmente grandes projetos, e eles simplesmente não podem existir a menos que façam pelo menos alguma coisa. Digamos que eu ficaria muito surpreso se fosse pelo menos 25%. Pequenos projetos costumam responder a essas perguntas da seguinte maneira: se o problema nos tocar, então vamos resolvê-lo. Então eles mergulham com sucesso no problema e estão envolvidos no gerenciamento de problemas e no gerenciamento de crises. Quando você tenta resolver um problema, mas o problema não está resolvido - bem-vindo ao gerenciamento de crises.

Sim, ouço com frequência: "resolveremos os problemas à medida que estiverem disponíveis". Nós estaremos certos? Vamos decidir exatamente?

Oleg: Você pode fazer isso de forma ingênua e simplesmente inserir invariantes importantes no termo de abertura do projeto e, se os invariantes quebrarem, basta reiniciar o projeto. Acontece de uma maneira muito pembucca.

Mikhail: Sim, aconteceu comigo que, quando os riscos funcionaram, o projeto foi simplesmente redefinido. Bom, bingo, o problema está resolvido, sem mais preocupações!

Tim: Pressione o botão de reset! Não, isso não funciona.

Keynote na DevOops 2019

Michael: Chegamos à última pergunta desta entrevista. Você está chegando ao próximo DevOops com uma palestra: você poderia abrir o véu de segredo sobre o que vai contar?

Tim: No momento, seis deles estão escrevendo um livro sobre a cultura do trabalho, as regras tácitas das organizações. A cultura é definida pelos valores centrais da organização. Normalmente, as pessoas não percebem isso, mas nós, trabalhando em consultoria por muitos anos, estamos acostumados a perceber isso. Você entra na empresa e, poucos minutos depois, começa a sentir o que está acontecendo. Nós chamamos isso de "aroma". Às vezes, esse perfume é realmente bom, e às vezes é, bem, opa. Diferentes organizações têm coisas muito diferentes.

Michael: Eu também trabalho em consultoria há anos e entendo bem do que você está falando.

Tim: Na verdade, uma das coisas que vale a pena falar na palestra é que nem tudo é determinado pela empresa. Você e sua equipe, como uma comunidade - você tem sua própria cultura de equipe. Pode ser a empresa inteira ou um departamento separado, uma equipe separada. Mas antes que você dissesse: é nisso que acreditamos, é importante ... Você não pode mudar sua cultura antes de perceber os valores e crenças por trás de ações concretas. O comportamento é fácil de observar, e a persuasão é difícil. O DevOps é apenas um ótimo exemplo de como as coisas ficam cada vez mais difíceis. As interações se tornam apenas mais complicadas, elas não se tornam mais limpas e compreensíveis; portanto, você deve pensar no que acredita e no que todos ao redor se calam.

Se você deseja obter resultados rápidos, aqui está um bom tópico: você já viu empresas nas quais ninguém diz "não sei"? Há lugares em que você precisa literalmente torturar uma pessoa até que ela admita que não sabe alguma coisa. Todo mundo sabe de tudo, todo mundo é estudioso incrível. Você se aproxima de qualquer pessoa e ela precisa responder instantaneamente algo à pergunta. Em vez de dizer "eu não sei". Viva, eles contrataram uma multidão de estudiosos! E em algumas culturas é muito perigoso dizer "não sei", isso pode ser percebido como uma manifestação de fraqueza. Existem organizações em que, pelo contrário, todos podem dizer "não sei". É completamente legal lá, e se alguém em resposta a uma pergunta começa a esfregar o jogo, é perfeitamente normal responder: "Você não entende do que está falando, certo?" e faça disso uma piada.

Idealmente, eu gostaria de ter um emprego em que você pudesse ser feliz o tempo todo. Não será fácil, nem todo dia é ensolarado e agradável, às vezes você precisa trabalhar duro, mas quando você começa a resumir, acontece: uau, este é realmente um lugar maravilhoso, eu trabalho bem aqui, tanto emocional quanto intelectualmente. E existem empresas nas quais você entra como consultor e percebe instantaneamente que não teria sobrevivido por três meses e teria fugido horrorizado. É sobre isso que quero falar no relatório.

Tim Lister chegará com a palestra "Personagens, comunidade e cultura: fatores importantes para a prosperidade" na conferência DevOops 2019, que será realizada de 29 a 30 de outubro de 2019 em São Petersburgo. Os ingressos podem ser adquiridos no site oficial . Vejo você no DevOops!