"Nós confiamos um no outro. Por exemplo, não temos nenhum salário” – uma longa entrevista com Tim Lister, autor de Peopleware

"Nós confiamos um no outro. Por exemplo, não temos nenhum salário” – uma longa entrevista com Tim Lister, autor de Peopleware

Tim Lister - co-autor de livros

  • "Fator humano. Projetos e equipes de sucesso" (o livro original se chama "Peopleware")
  • "Valsando com os Ursos: Gerenciando Riscos em Projetos de Software"
  • “Enlouquecido por adrenalina e zumbificado por padrões. Padrões de comportamento das equipes de projeto"

Todos esses livros são clássicos em sua área e foram escritos em conjunto com colegas em Guilda de sistemas atlânticos. Na Rússia, seus colegas são mais famosos - Tom DeMarco и Pedro Hruschka, que também escreveu muitas obras famosas.

Tim tem 40 anos de experiência em desenvolvimento de software; em 1975 (nenhum dos que escreveram este habrapost nasceu este ano), Tim já era vice-presidente executivo da Yourdon Inc. Ele agora passa seu tempo consultando, ensinando e escrevendo, com visitas ocasionais a com relatórios conferências em todo o mundo.

Fizemos uma entrevista com Tim Lister especialmente para Habr. Ele abrirá a conferência DevOops 2019 e temos muitas perguntas sobre livros e muito mais. A entrevista é conduzida por Mikhail Druzhinin e Oleg Chirukhin do comitê do programa da conferência.

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

Tim: Eu sou o chefe da Atlantic Systems Guild. Somos seis na Guilda, nos chamamos de diretores. Três nos EUA e três na Europa - é por isso que a Guilda se chama Atlantic. Estamos juntos há tantos anos que você simplesmente não consegue contá-los. Todos nós temos nossas especialidades. Tenho trabalhado com clientes há uma década ou mais. Meus projetos incluem não apenas gerenciamento, mas também definição de requisitos, planejamento e avaliação de projetos. Parece que os projetos que começam mal geralmente terminam mal. Portanto, vale a pena garantir que todas as atividades sejam realmente bem pensadas e coordenadas, que as ideias dos criadores estejam combinadas. Vale a pena pensar no que você está fazendo e por quê. Quais estratégias usar para concluir o projeto.

Há muitos anos que aconselho clientes de diversas maneiras. Um exemplo interessante é uma empresa que fabrica robôs para cirurgias de joelho e quadril. O cirurgião não opera de forma totalmente independente, mas usa um robô. A segurança aqui, falando francamente, é importante. Mas quando você tenta discutir requisitos com pessoas que estão focadas em resolver problemas... Pode parecer estranho, mas nos EUA existe Certificação (Federal Drug Administration), que licencia produtos como esses robôs. Antes de vender qualquer coisa e usá-la 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 dos testes. Se você alterar os requisitos, precisará passar por todo esse enorme processo de testes repetidas vezes. Nossos clientes conseguiram incluir o design visual das aplicações em seus requisitos. Eles tinham capturas de tela diretamente como parte dos requisitos. Temos que retirá-los e explicar que na maioria 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 de requisitos para que eles nunca mudem, a menos que algumas condições subjacentes realmente importantes mudem. Se o design visual não estiver nos requisitos, a atualização do produto será muito mais rápida. Nosso trabalho é encontrar os elementos que tratam das operações no joelho, quadril, costas, retirá-los em documentos separados e dizer que esses serão os requisitos fundamentais. Vamos fazer um grupo isolado de requisitos sobre operações no joelho. Isso nos permitirá construir um conjunto de requisitos mais estável. Falaremos sobre toda a linha de produtos e não sobre robôs específicos.

Muito trabalho foi feito, mas ainda assim chegaram a locais onde antes passavam semanas e meses de testes repetidos sem sentido ou necessidade, porque os seus requisitos descritos no papel não coincidiam com os requisitos reais para os quais os sistemas foram construídos. O FDA sempre dizia a eles: seus requisitos mudaram, agora você precisa verificar tudo do zero. Novas verificações completas de todo o produto estavam matando a empresa.

Portanto, existem tarefas maravilhosas quando você se encontra no início de algo interessante, e as primeiras ações definem as demais regras do jogo. Se você garantir que essa atividade inicial comece a funcionar bem tanto do ponto de vista gerencial quanto técnico, há uma chance de você acabar com um ótimo projeto. Mas se esta parte saiu dos trilhos e deu errado em algum lugar, se você não consegue encontrar os acordos fundamentais... não, não é que seu projeto irá necessariamente falhar. Mas você não poderá mais dizer: “Fizemos muito bem, fizemos tudo com muita eficácia”. Essas são as coisas que faço quando me comunico com os clientes.

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

Tim: Também temos ideias sobre como juntar todas as peças do quebra-cabeça: quais habilidades precisamos, quando exatamente elas são necessárias, como é o núcleo da equipe e outras coisas fundamentais. Precisamos de funcionários em tempo integral ou podemos contratar alguém em meio período? Planejamento, gestão. Perguntas como: O que é mais importante para este projeto específico? Como conseguir isso? O que sabemos sobre este produto ou projeto, quais são os riscos e onde estão as incógnitas, como vamos lidar com tudo isso? Claro que neste momento alguém começa a gritar “E o ágil?!” Ok, vocês são todos flexíveis, mas e daí? Como é exatamente o projeto, como você vai realizá-lo de uma forma que se adapte ao projeto? Você não pode simplesmente dizer que “nossa abordagem se estende a qualquer coisa, somos uma equipe Scrum!” Isso é um absurdo e um absurdo. Para onde você irá em seguida, por que deveria funcionar, qual é o objetivo? Eu ensino meus clientes a pensar sobre todas essas questões.

19 anos de agilidade

Michael: No Agile, muitas vezes as pessoas tentam não definir nada com antecedência, mas tomar decisões o mais tarde possível, dizendo: somos grandes demais, não vou pensar na arquitetura geral. Não vou pensar em um monte de outras coisas; em vez disso, vou entregar algo que funcione para o cliente agora.

Tim: Acho que as metodologias ágeis, começando com Manifesto ágil em 2001, abriu os olhos da indústria. Mas por outro lado, nada é perfeito. Sou totalmente a favor do desenvolvimento iterativo. A iteração faz muito sentido na maioria dos projetos. Mas a questão que você precisa pensar é: depois que o produto sai e está em uso, quanto tempo ele dura? Este é um produto que vai durar seis meses antes de ser substituído por outro? Ou este é um produto que funcionará por muitos e muitos anos? É claro que não vou citar nomes, mas... Em Nova Iorque e na sua comunidade financeira, os sistemas mais fundamentais são muito antigos. Isso é incrível. Você olha para eles e pensa, se ao menos pudesse voltar no tempo, até 1994, e dizer aos desenvolvedores: “Eu vim do futuro, de 2019. Basta desenvolver este sistema pelo tempo que você precisar. Torne-o expansível, pense na arquitetura. Será então melhorado por mais de vinte e cinco anos. Se você atrasar um pouco mais o desenvolvimento, no grande esquema das coisas ninguém notará!” Ao estimar as coisas no longo prazo, você precisa considerar quanto custará no total. Às vezes, uma arquitetura bem projetada realmente vale a pena, e às vezes não. Precisamos olhar ao redor e nos perguntar: estamos na situação certa para tal decisão?

Portanto, uma ideia como “Somos ágeis, o próprio cliente nos dirá o que deseja obter” - é superingênua. Os clientes nem sabem o que querem e, mais ainda, não sabem o que podem conseguir. Algumas pessoas começarão a citar exemplos históricos como argumentos, já vi isso. Mas as pessoas tecnicamente avançadas não costumam dizer isso. Dizem: “Estamos em 2019, estas são as oportunidades que temos e podemos mudar completamente a forma como olhamos para estas coisas!” Em vez de imitar as soluções existentes, deixando-as um pouco mais bonitas e penteadas, às vezes é preciso sair e dizer: “Vamos reinventar completamente o que estamos tentando fazer aqui!”

E não creio que a maioria dos clientes possa pensar no problema dessa maneira. Eles só veem o que já têm, só isso. Depois disso, eles vêm com pedidos como “vamos tornar isso um pouco mais simples” ou o que quer que eles costumem dizer. Mas não somos garçons ou garçonetes, então podemos anotar um pedido, por mais estúpido que seja, e depois assá-lo na cozinha. Nós somos seus guias. Temos que abrir os olhos e dizer: ei, temos novas oportunidades aqui! Você percebe que podemos realmente mudar a forma como essa parte do seu negócio é feita? Um dos problemas do Agile é que ele elimina a consciência do que é uma oportunidade, do que é um problema, do que precisamos fazer, de quais tecnologias disponíveis são mais adequadas para esta situação específica.

Talvez eu esteja sendo cético demais aqui: há muitas coisas maravilhosas acontecendo na comunidade ágil. Mas tenho um problema com o fato de que, em vez de definir um projeto, as pessoas começam a desistir. Eu perguntaria aqui: o que estamos fazendo, como vamos fazer isso? E, de alguma forma mágica, sempre acontece que o cliente deveria saber melhor do que ninguém. Mas o cliente só sabe melhor quando escolhe entre coisas já construídas por alguém. Se eu quiser comprar um carro e souber o tamanho do meu orçamento familiar, selecionarei rapidamente um carro que se adapte ao meu estilo de vida. Aqui eu sei tudo melhor que ninguém! Mas observe que alguém já fez os carros. Não tenho ideia de como inventar um carro novo, não sou especialista. Quando criamos produtos personalizados ou especiais, a voz do cliente deve ser tida em conta, mas esta já não é a única voz.

Oleg: Você mencionou o Manifesto Ágil. Precisamos atualizá-lo ou revisá-lo de alguma forma, levando em consideração a compreensão moderna do assunto?

Tim: Eu não tocaria nele. Acho que é um ótimo documento histórico. Quero dizer, ele é o que é. Ele está completando 19 anos, é velho, mas na sua época fez uma revolução. O que ele fez bem foi provocar uma reação e as pessoas começaram a sussurrar sobre ele. Você provavelmente ainda não trabalhava no setor em 2001, mas todos trabalhavam de acordo com os processos. Instituto de Engenharia de Software, cinco níveis do modelo de completude de software (CMMI). Não sei se essas lendas da antiguidade profunda lhe dizem alguma coisa, mas foi um avanço. No início, as pessoas acreditavam que se os processos fossem configurados corretamente, os problemas desapareceriam por si próprios. E então surge o Manifesto e diz: “Não, não, não – nos basearemos em pessoas, não em processos”. Somos mestres em desenvolvimento de software. Entendemos que o processo ideal é uma miragem, não acontece. Há muita idiossincrasia nos projetos, a ideia de um único processo perfeito para todos os projetos não faz sentido. Os problemas são complexos demais para afirmar que só existe uma solução para tudo (olá, nirvana).

Não pretendo olhar para o futuro, mas direi que as pessoas começaram agora a pensar mais em projetos. Acho que o Manifesto Ágil é muito bom em saltar e dizer: “Ei! Você está em um navio e você mesmo o dirige. Você terá que tomar uma decisão – não iremos sugerir 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 o objetivo. Houve outros navios antes de você, e haverá outros navios depois de você, mas ainda assim, em certo sentido, sua jornada é única.” Algo parecido! É uma maneira de pensar. Para mim não há nada de novo sob o sol, as pessoas já navegaram antes e navegarão novamente, mas para você esta é a sua jornada principal, e não vou lhe dizer o que exatamente vai acontecer com você. Você deve ter habilidades para trabalhar coordenado em equipe e, se realmente as tiver, tudo dará certo e você chegará onde deseja.

Peopleware: 30 anos depois

Oleg: A Peopleware foi uma revolução assim como o Manifesto?

Tim: Peopleware... Tom e eu escrevemos este livro, mas não pensamos que aconteceria assim. De alguma forma, isso ressoou nas ideias de muitas pessoas. Este foi o primeiro livro que disse: o desenvolvimento de software é uma atividade que exige muito trabalho humano. Apesar da nossa natureza técnica, somos também uma comunidade de pessoas que constroem algo grande, até enorme, muito complexo. Ninguém pode criar essas coisas sozinho, certo? Então a ideia de “equipe” se tornou muito importante. E não só do ponto de vista gerencial, mas também para técnicos que se uniram para resolver problemas profundos realmente complexos e com um monte de incógnitas. Para mim, pessoalmente, este foi um grande teste de inteligência ao longo da minha carreira. E aqui você precisa ser capaz de dizer: sim, esse problema é mais do que posso resolver sozinho, mas juntos podemos encontrar uma solução elegante da qual possamos nos orgulhar. E acho que foi essa ideia que mais repercutiu. A ideia de que trabalhamos parte do tempo sozinhos, parte do tempo em grupo, e muitas vezes a decisão é tomada pelo grupo. A resolução de problemas em grupo tornou-se rapidamente uma característica importante de projetos complexos.

Apesar de Tim ter dado um grande número de palestras, poucas delas são postadas no YouTube. Você pode consultar o relatório “The Return of Peopleware” de 2007. A qualidade, claro, deixa muito a desejar.

Michael: Alguma coisa mudou nos últimos 30 anos desde que o livro foi publicado?

Tim: Você pode ver isso de muitos ângulos diferentes. Sociologicamente falando... era uma vez, em tempos mais simples, você e sua equipe sentavam-se no mesmo escritório. Vocês poderiam estar próximos todos os dias, tomar café juntos e discutir trabalho. O que realmente mudou é que as equipas podem agora ser distribuídas geograficamente, em diferentes países e fusos horários, mas ainda assim trabalham no mesmo problema, o que acrescenta toda uma nova camada de complexidade. Isso pode parecer antiquado, mas não há nada como a comunicação cara a cara, onde vocês estão todos juntos, trabalhando juntos, e podem ir até um colega e dizer: olha o que descobri, o que você achou disso? As conversas cara a cara fornecem uma maneira rápida de transição para a comunicação informal, e acho que os entusiastas do Agile também deveriam gostar. E também estou preocupado porque na realidade o mundo acabou por ser muito pequeno, e agora está todo coberto de equipas distribuídas, e é tudo muito complexo.

Todos nós vivemos em DevOps

Michael: Mesmo do ponto de vista do comité do programa da conferência, temos pessoas na Califórnia, em Nova Iorque, na Europa, na Rússia... ainda não há ninguém em Singapura. A diferença geográfica é muito grande e as pessoas estão começando a se espalhar ainda mais. Se estamos falando de desenvolvimento, você pode nos contar mais sobre devops e como quebrar barreiras entre equipes? Existe um conceito de que todos estão sentados em seus bunkers, e agora os bunkers estão desabando, o que você acha dessa analogia?

Tim: Parece-me que, à luz dos recentes avanços tecnológicos, o devops é de grande importância. Anteriormente, você tinha equipes de desenvolvedores e administradores, eles trabalhavam, trabalhavam, trabalhavam, e em algum momento apareceu algo com o qual você poderia ir até os administradores e lançá-lo para produção. E aí começou a conversa sobre o bunker, porque os admins são meio que aliados, não inimigos, pelo menos, mas você só falava com eles quando tudo estava pronto para entrar em produção. Você foi até eles com alguma coisa e disse: olha que aplicativo nós temos, mas você poderia lançar esse aplicativo? E agora todo o conceito de entrega mudou para melhor. Quero dizer, havia essa ideia de que você poderia realizar mudanças rapidamente. Podemos atualizar produtos instantaneamente. Eu sempre sorrio quando o Firefox no meu laptop aparece e diz: ei, atualizamos seu Firefox em segundo plano e, assim que você tiver um minuto, você se importaria de clicar aqui e lhe daremos a versão mais recente. E eu disse, “Ah, sim, querido!” Enquanto eu dormia, eles estavam trabalhando para me entregar um novo lançamento direto no meu computador. Isso é maravilhoso, incrível.

Mas aí está a dificuldade: você tem esse recurso de atualização de software, mas integrar as pessoas é muito mais difícil. O que quero expressar na palestra do DevOops é que agora temos muito mais jogadores do que jamais tivemos. Se você pensar apenas em todos os envolvidos em 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 um monte de outras pessoas. E cada um tem sua própria visão do 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 continuarem atentos ao que está acontecendo e não enlouquecerem. É necessário separar as tarefas do grupo das tarefas que se aplicam a todos. Esta é uma tarefa muito difícil. Por outro lado, acho que está tudo muito melhor do que há muitos anos. Este é exatamente o caminho pelo qual as pessoas crescem e aprendem a se comportar corretamente. Quando você faz a integração, você entende que não deve haver nenhum desenvolvimento subterrâneo, para que no último momento o software não saia rastejando como uma caixa de surpresas: tipo, olha o que fizemos aqui! A ideia é que você seja capaz de fazer integração e desenvolvimento e, no final, implementar de forma organizada e iterativa. Tudo isso significa muito para mim. Isso possibilita criar mais valor para os usuários do sistema e para o seu cliente.

Michael: A ideia do devops é entregar desenvolvimentos significativos o mais cedo possível. Vejo que o mundo começou a acelerar cada vez mais. Como se adaptar a tais acelerações? Há dez anos isso não existia!

Tim: Claro, todo mundo quer cada vez mais funcionalidades. Não há necessidade de se mover, apenas empilhe mais. Às vezes você até precisa desacelerar para a próxima atualização incremental trazer algo útil – e isso é completamente normal.

A ideia de que você precisa correr, correr, correr não é das melhores. É improvável que alguém queira viver sua vida assim. Gostaria que o ritmo das entregas definisse o ritmo do projeto. Se você apenas produzir um fluxo de coisas pequenas e relativamente sem sentido, tudo isso não terá sentido. Em vez de tentar lançar as coisas o mais cedo possível, o que vale a pena discutir com os principais desenvolvedores e gerentes de produtos e projetos é a estratégia. Isso faz 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, o devops irrompe em nossas vidas. Ele possui algum de seus próprios padrões e antipadrões que podem matar o projeto na hora?

Tim: Padrões e antipadrões acontecem o tempo todo. Algo para conversar. Bem, existe uma coisa que chamamos de “coisas brilhantes”. As pessoas realmente gostam de novas tecnologias. Eles ficam simplesmente hipnotizados pelo brilho de tudo que parece descolado e estiloso e param de fazer perguntas: é mesmo necessário? O que vamos conseguir? Isso é confiável, faz algum sentido? Muitas vezes vejo pessoas, por assim dizer, na vanguarda da tecnologia. Eles estão hipnotizados pelo que está acontecendo no mundo. Mas se você observar mais de perto as coisas úteis que eles fazem, muitas vezes simplesmente não há nada de útil!

Estávamos discutindo com nossos camaradas que este ano é um aniversário, cinquenta anos desde que as pessoas pousaram na Lua. Isto foi em 1969. A tecnologia que ajudou as pessoas a chegar lá nem sequer é a tecnologia de 1969, mas sim de 1960 ou 62, porque a NASA queria usar apenas o que tivesse boas evidências de fiabilidade. E então você olha e entende - sim, e eles eram verdadeiros! Agora, não, não, mas você tem problemas com tecnologia simplesmente porque tudo é pressionado demais, vendido de todas as maneiras. As pessoas gritam de todos os lugares: “Olha, que coisa, isso é a coisa mais nova, a coisa mais linda do mundo, adequada para absolutamente todos!” Bem, é isso... geralmente tudo isso acaba sendo apenas uma isca, e então tudo tem que ser jogado fora. Talvez seja porque já sou velho e vejo essas coisas com muito ceticismo, quando as pessoas saem correndo e dizem que encontraram a Única e Mais Correta Forma de Criar as Melhores Tecnologias. Nesse momento, uma voz desperta dentro de mim que diz: “Que bagunça!”

Michael: Na verdade, quantas vezes ouvimos falar da próxima solução mágica?

Tim: Exatamente, e este é o curso normal das coisas! Por exemplo... parece que isso já virou piada em todo o mundo, mas aqui as pessoas costumam falar sobre a tecnologia blockchain. E eles realmente fazem sentido em certas situações! Quando você realmente precisa de evidências confiáveis ​​de eventos, de que o sistema funciona e de que ninguém nos enganou, quando você tem problemas de segurança e todas essas coisas misturadas - o blockchain faz sentido. Mas quando dizem que o Blockchain irá agora varrer o mundo, varrendo tudo em seu caminho? Sonhe mais! Esta é uma tecnologia muito cara e complexa. Tecnicamente complexo e demorado. Inclusive puramente algoritmicamente, toda vez que você precisar recalcular a matemática, com as menores alterações... e esta é uma ótima ideia - mas apenas para certos casos. Toda a minha vida e carreira foram sobre isto: ideias interessantes em situações muito específicas. É muito importante entender exatamente qual é a sua situação.

Michael: Sim, a principal “questão da vida, do universo e de tudo”: esta tecnologia ou abordagem é adequada à sua situação ou não?

Tim: Essa questão já pode ser discutida com o grupo de tecnologia. Talvez até traga algum consultor. Dê uma olhada no projeto e entenda - faremos agora algo certo e útil, melhor do que antes? Talvez caiba, talvez não. Mas o mais importante é não tomar tal decisão por padrão, simplesmente porque alguém deixou escapar: “Precisamos desesperadamente de um blockchain! Acabei de ler sobre ele em uma revista no avião!” Seriamente? Não é nem engraçado.

O mítico “engenheiro devops”

Oleg: Agora todo mundo está implementando devops. Alguém lê sobre Devops na Internet e amanhã aparece outra vaga em um site de recrutamento. "engenheiro devops". Aqui gostaria de chamar a sua atenção: você acha que esse termo, “engenheiro devops”, tem direito à vida? Há uma opinião de que devops é uma cultura, e algo não faz sentido aqui.

Tim: Mais ou menos. Deixe-os então dar imediatamente alguma explicação deste termo. Algo para torná-lo único. Até que provem que existe uma combinação única de habilidades por trás de uma vaga como essa, não vou comprá-la! Quer dizer, bem, temos um cargo, “engenheiro devops”, um título interessante, sim, o que vem a seguir? Os títulos dos cargos geralmente são algo muito interessante. Digamos “desenvolvedor” – o que é afinal? Organizações diferentes significam coisas completamente diferentes. Em algumas empresas, programadores de alta qualidade escrevem testes que fazem mais sentido do que testes escritos por testadores profissionais especiais de outras empresas. E daí, eles agora são programadores ou testadores?

Sim, temos cargos, mas se você fizer perguntas por tempo suficiente, eventualmente descobrirá que somos todos solucionadores de problemas. Somos buscadores de soluções e alguns possuem algumas habilidades técnicas e outros diferentes. Se você vive em um ambiente onde o DevOps penetrou, você está engajado na integração de desenvolvimento e administração, e esta atividade tem um propósito bastante importante. Mas se lhe perguntarem o que exatamente você faz e pelo que é responsável, descobre-se que as pessoas têm feito todas essas coisas desde tempos imemoriais. “Eu sou responsável pela arquitetura”, “Eu sou responsável pelos bancos de dados” e assim por diante, tanto faz, você vê - tudo isso foi antes do “devops”.

Quando alguém me diz o cargo que ocupa, eu realmente não escuto muito. É melhor deixá-lo dizer pelo que ele é realmente responsável, isso nos permitirá entender muito melhor o problema. Meu exemplo favorito é quando uma pessoa afirma ser um “gerente de projeto”. O que? Isso não significa nada, ainda não sei o que você faz. Um gerente de projeto pode ser um desenvolvedor, o líder de uma equipe de quatro pessoas, escrevendo código, fazendo trabalho, que se tornou um líder de equipe, que as próprias pessoas reconhecem entre si como um líder. E também, um gerente de projetos pode ser um gerente que gerencia seiscentas pessoas em um projeto, gerencia outros gerentes, é responsável por elaborar cronogramas e planejar orçamentos, só isso. São dois mundos completamente diferentes! Mas o cargo deles parece o mesmo.

Vamos mudar isso de uma forma um pouco diferente. No que você é realmente bom, tem muita experiência, tem talento? Pelo que você assumirá a responsabilidade porque acha que pode lidar com a tarefa? E aqui alguém vai imediatamente começar a negar: não, não, não, não tenho nenhuma vontade de lidar com os recursos do projeto, não é da minha conta, sou um cara técnico e entendo de usabilidade e interfaces de usuário, não Se quiser gerenciar exércitos de pessoas, é melhor eu ir trabalhar.

E, a propósito, sou um grande defensor de uma abordagem em que este tipo de separação de competências funcione bem. Onde os técnicos podem desenvolver suas carreiras tanto quanto desejarem. No entanto, ainda vejo organizações onde os técnicos reclamam: terei que entrar no gerenciamento de projetos porque esse é o único caminho nesta empresa. Às vezes, isso leva a resultados terríveis. Os melhores técnicos não são bons gestores, e os melhores gestores não conseguem lidar com a tecnologia. Sejamos honestos sobre isso.

Vejo muita demanda por isso agora. Se você é um tecnólogo, sua empresa pode te ajudar, mas independentemente disso, você precisa, realmente precisa encontrar seu próprio caminho profissional porque a tecnologia está sempre mudando e você precisa se reinventar junto com ela! Em apenas vinte anos, as tecnologias podem mudar pelo menos cinco vezes. A tecnologia é uma coisa estranha...

"Especialistas em tudo"

Michael: Como as pessoas podem lidar com essa velocidade das mudanças tecnológicas? Sua complexidade está crescendo, seu número está crescendo, a quantidade total de comunicação entre as pessoas também está crescendo, e acontece que você não pode se tornar um “especialista em tudo”.

Tim: Certo! Se você trabalha com tecnologia, sim, com certeza precisa escolher algo específico e se aprofundar no assunto. Alguma tecnologia que sua organização considera útil (e talvez seja realmente útil). E se você não está mais interessado nisso - eu nunca teria acreditado que diria isso - bem, talvez você devesse mudar para alguma outra organização onde a tecnologia seja mais interessante ou mais conveniente para estudar.

Mas, em geral, sim, você está certo. As tecnologias estão crescendo em todas as direções ao mesmo tempo; ninguém pode dizer “Sou um tecnólogo especialista em todas as tecnologias que existem”. Por outro lado, existem pessoas-esponja que absorvem literalmente o conhecimento tecnológico e são loucas por isso. Já vi algumas dessas pessoas, elas literalmente respiram e vivem isso, é útil e interessante conversar com elas. Eles estudam não só o que está acontecendo dentro da organização, mas em geral falam sobre isso, também são tecnólogos muito legais, são muito conscientes e propositais. Eles apenas tentam ficar na crista da onda, independentemente de qual seja a sua função principal, porque a sua paixão é o movimento da Tecnologia, a promoção da tecnologia. Se você conhecer essa pessoa de repente, vá almoçar com ela e discuta várias coisas legais durante o almoço. Acho que qualquer organização precisa de pelo menos algumas dessas pessoas.

Riscos e incerteza

Michael: Engenheiros honrados, sim. Vamos abordar o gerenciamento de riscos enquanto temos tempo. Começamos esta entrevista com uma discussão sobre software médico, onde erros podem levar a consequências terríveis. Depois falamos sobre o Programa Lunar, onde o custo de um erro é de milhões de dólares e possivelmente de várias vidas humanas. Mas agora vejo o movimento contrário na indústria, as pessoas não pensam nos riscos, não tentam prevê-los, nem sequer os observam.

Oleg: Mova-se rápido e quebre as coisas!

Michael: Sim, ande rápido, quebre coisas, mais e mais coisas, até morrer de alguma coisa. Do seu ponto de vista, como o desenvolvedor médio deveria abordar o gerenciamento de riscos de aprendizagem agora?

Tim: Vamos traçar aqui uma linha entre duas coisas: riscos e incerteza. Estas são coisas diferentes. A incerteza ocorre quando você não tem dados suficientes em um determinado momento para chegar a uma resposta definitiva. Por exemplo, na fase inicial de um projeto, se alguém lhe perguntar “quando você terminará o trabalho”, se você for uma pessoa bastante honesta, você dirá: “Não tenho ideia”. Você simplesmente não sabe, e tudo bem. Você ainda não estudou os problemas e não conhece a equipe, não conhece suas habilidades e assim por diante. Isso é incerteza.

Os riscos surgem quando problemas potenciais já podem ser identificados. Esse tipo de coisa pode acontecer, sua probabilidade é maior que zero, mas menor que cem por cento, algo intermediário. Com isso tudo pode acontecer, desde atrasos e trabalhos desnecessários, até um desfecho fatal para o projeto. O resultado, quando você fala - gente, vamos dobrar nossos guarda-chuvas e sair da praia, não vamos terminar nunca, acabou, ponto final. Presumimos que isso funcionaria, mas não funciona de jeito nenhum, é hora de parar. Estas são as situações.

Muitas vezes, os problemas são mais fáceis de resolver quando já surgiram, quando o problema está acontecendo agora. Mas quando um problema está bem na sua frente, você não está fazendo gerenciamento de riscos – você está resolvendo problemas, gerenciando crises. Se você é um desenvolvedor ou gerente líder, deve estar se perguntando o que poderia acontecer que levaria a atrasos, perda de tempo, custos desnecessários ou ao colapso de todo o projeto? O que nos fará parar e recomeçar? Quando todas essas coisas funcionarem, o que faremos com elas? Existe uma resposta simples e válida para a maioria das situações: não fuja dos riscos, trabalhe neles. Veja como você pode resolver uma situação de risco, reduzi-la a nada, transformá-la de problema em outra coisa. Em vez de dizer: bem, resolveremos os problemas à medida que surgirem.

A incerteza e o risco devem estar na vanguarda de tudo com que você lida. Você pode pegar um plano de projeto, analisar antecipadamente certos riscos críticos e dizer: precisamos lidar com isso agora, porque se alguma coisa der errado, nada mais terá importância. Você não deve se preocupar com a beleza da toalha de mesa se não estiver claro se você pode preparar o jantar. Primeiro é preciso identificar todos os riscos de preparar um jantar delicioso, lidar com eles e só depois pensar em todas as outras coisas que não representam uma ameaça real.

Novamente, o que torna seu projeto único? Vamos ver o que pode fazer nosso projeto sair dos trilhos. O que podemos fazer para minimizar a probabilidade de isso acontecer? Normalmente não dá para simplesmente neutralizá-los 100% e declarar com a consciência tranquila: “É isso, isso não é mais problema, o risco foi resolvido!” Para mim, isso é um sinal de comportamento adulto. Essa é a diferença entre uma criança e um adulto - as crianças pensam que são imortais, que nada pode dar errado, que vai dar tudo certo! Ao mesmo tempo, os adultos observam como as crianças de três anos pulam no parquinho, acompanham os movimentos com os olhos e dizem para si mesmas: “ooh-ooh, ooh-ooh”. Fico por perto e me preparo para pegar quando a criança cair.

Por outro lado, gosto tanto deste negócio porque é arriscado. Fazemos coisas e essas coisas são arriscadas. Eles exigem uma abordagem adulta. O entusiasmo por si só não resolverá seus problemas!

Pensamento de engenharia adulto

Michael: O exemplo com as crianças é bom. Se sou um engenheiro comum, tenho o prazer de ser criança. Mas como você avança em direção a um pensamento mais adulto?

Tim: Uma das ideias que funciona igualmente bem tanto para um desenvolvedor iniciante quanto para um desenvolvedor estabelecido é o conceito de contexto. O que estamos fazendo, o que vamos alcançar. O que é realmente importante neste projeto? Não importa quem você é neste projeto, seja você um estagiário ou o arquiteto-chefe, todos precisam de contexto. Precisamos fazer com que todos pensem em uma escala maior do que seus próprios trabalhos. “Eu faço minha peça e, desde que ela funcione, fico feliz.” Não e não de novo. Sempre vale (sem ser rude!) lembrar às pessoas o contexto em que trabalham. O que todos nós estamos tentando alcançar juntos. Idéias de que você pode ser criança desde que esteja tudo bem com a sua parte do projeto - por favor, não faça isso. Se cruzarmos a linha de chegada, só a cruzaremos juntos. Você não está sozinho, estamos todos juntos. Se todas as pessoas no projeto, tanto jovens como velhos, começassem a falar sobre o que exatamente é importante para o projeto, por que a empresa está investindo dinheiro naquilo que todos nós estamos tentando alcançar... a maioria deles se sentirá muito melhor porque eles verão como o trabalho deles se correlaciona com o trabalho de todos os outros. Por um lado, compreendo a peça pela qual sou pessoalmente responsável. Mas para terminar o trabalho precisamos de todas as outras pessoas também. E se você realmente acha que terminou, sempre temos trabalho a fazer no projeto!

Oleg: Relativamente falando, se você trabalha de acordo com o Kanban, ao atingir o gargalo de algum teste, você pode parar o que estava fazendo lá (por exemplo, programar) e ir ajudar os testadores.

Tim: Exatamente. Acho que os melhores técnicos, se você olhar de perto, são como se fossem seus próprios gerentes. Como posso formular isso...

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

Tim: Exatamente! Quer dizer, você assume a responsabilidade, entende o problema e entra em contato com as pessoas quando vê que suas decisões podem afetar o trabalho delas, coisas assim. Não se trata apenas de ficar sentado em sua mesa, fazendo seu trabalho e nem mesmo perceber o que está acontecendo ao seu redor. Não não não. Aliás, uma das melhores coisas do Agile é que eles propuseram sprints curtos, pois assim o estado de coisas de todos os participantes fica claramente observável, eles podem ver tudo junto. Falamos um do outro todos os dias.

Como entrar no gerenciamento de riscos

Oleg: Existe alguma estrutura formal de conhecimento nesta área? Por exemplo, sou um desenvolvedor Java e quero entender o gerenciamento de riscos sem me tornar um verdadeiro gerente de projetos por formação. Provavelmente lerei primeiro "Quanto custa um projeto de software" de McConnell, e depois? Quais são os primeiros passos?

Tim: A primeira é começar a se comunicar com as pessoas do projeto. Isso proporciona uma melhoria imediata na cultura de comunicação com os colegas. Precisamos começar abrindo tudo por padrão, em vez de ocultá-lo. Fala: são essas coisas que me incomodam, são essas coisas que me tiram o sono à noite, acordei de noite hoje e fiquei tipo: meu Deus, preciso pensar nisso! Os outros veem a mesma coisa? Como grupo, devemos responder a estes potenciais problemas? Você precisa ser capaz de apoiar uma discussão sobre esses tópicos. Não existe uma fórmula pré-preparada pela qual trabalhamos. Não se trata de fazer hambúrgueres, trata-se de pessoas. “Fiz um cheeseburger, vendi um cheeseburger” não é a nossa praia, e é por isso que amo tanto esse trabalho. Gosto quando tudo o que os gestores faziam agora passa a ser propriedade da equipe.

Oleg: Você falou em livros e entrevistas sobre como as pessoas se preocupam mais com a felicidade do que com os números em um gráfico. Por outro lado, quando você diz à equipe: estamos migrando para o devops e agora o programador deve se comunicar constantemente, isso pode estar muito fora de sua zona de conforto. E neste momento ele pode, digamos, estar profundamente infeliz. O que fazer nessa situação?

Tim: Não sei exatamente o que fazer. Se um desenvolvedor estiver muito isolado, ele não verá por que o trabalho está sendo feito, apenas observará sua parte do trabalho e precisará entrar no que chamo de "contexto". Ele precisa descobrir como tudo está conectado. E, claro, não me refiro a apresentações formais ou algo assim. Estou falando do fato de 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. É aqui que você pode começar a discutir ideias, acordos comuns para fazer com que seu trabalho se encaixe bem e como resolver um problema comum juntos.

Para ajudá-los a se adaptar, muitas vezes desejam enviar técnicos para treinamento e discutem o treinamento. Um amigo meu gosta de dizer que treinar é para cães. Há treinamento para pessoas. Uma das melhores coisas de aprender como desenvolvedor é interagir com seus colegas. Se alguém é realmente bom em alguma coisa, você deve observá-lo trabalhar ou conversar com ele sobre seu trabalho ou algo assim. Alguns Kent Beck convencionais falavam constantemente sobre programação extrema. É engraçado porque o XP é uma ideia muito simples, mas causa muitos problemas. Para alguns, fazer XP é como ser forçado a ficar nu na frente dos amigos. Eles verão o que estou fazendo! Eles são meus colegas, não só verão, mas também compreenderão! Terrível! Algumas pessoas estão começando a ficar seriamente nervosas. Mas quando você percebe que esta é a melhor forma 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 obriga você a sair da sua zona de conforto. Como engenheiro, você precisa sair da sua zona de conforto e se comunicar. Como solucionador de problemas, você precisa se colocar constantemente em uma posição fraca e pensar no que pode dar errado. Este tipo de trabalho é inerentemente projetado para ser um incômodo. Você se coloca conscientemente em situações estressantes. Geralmente as pessoas fogem deles, gostam de ser crianças felizes.

Tim: O que pode ser feito, você pode sair e dizer abertamente: “Está tudo bem, eu aguento! Não sou o único que se sente desconfortável. Vamos discutir várias coisas desconfortáveis, todos juntos, como uma equipe!” Esses são os nossos problemas comuns, temos que lidar com eles, sabe? Acho que os desenvolvedores geniais idiossincráticos são como mamutes, eles desapareceram. E o seu significado é muito limitado. Se você não consegue se comunicar, não consegue participar bem. Portanto, apenas fale. Seja honesto e aberto. Lamento muito que isso seja desagradável para alguém. Já imaginou, há muitos anos houve um estudo segundo o qual o principal medo nos Estados Unidos não é a morte, mas adivinhe? Medo de falar em público! Isso significa que em algum lugar há pessoas que preferem morrer a elogiar em voz alta. E acho que basta você ter algumas habilidades básicas, dependendo do que você faz. Habilidades de fala, habilidades de escrita - mas apenas o que for realmente necessário em seu trabalho. Se você trabalha como analista, mas não sabe ler, escrever e falar, então, infelizmente, não terá nada para fazer em meus projetos!

O preço da comunicação

Oleg: Contratar esses funcionários cessantes não é mais caro por vários motivos? Afinal, eles estão constantemente conversando em vez de trabalhar!

Tim: Eu quis dizer o núcleo da equipe, e não apenas todos. Se você tem alguém que é muito legal em ajustar bancos de dados, adora ajustar bancos de dados e vai continuar ajustando seus bancos de dados pelo resto da vida e pronto, legal, continue assim. Mas estou falando de pessoas que querem morar no próprio projeto. O núcleo da equipe, voltado para o desenvolvimento do projeto. Essas pessoas realmente precisam se comunicar constantemente umas com as outras. E principalmente no início do projeto, quando você discute riscos, formas de atingir objetivos globais e assim por diante.

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

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

Oleg: Na verdade, falando de funcionários falantes, tentei simular as objeções das pessoas, especialmente dos gestores, que são convidados a mudar para o devops, a toda esta nova visão do mundo. E vocês, como consultores, deveriam estar cientes dessas objeções muito melhor do que eu, como desenvolvedor! Compartilhe o que mais preocupa os gestores?

Tim: Gerentes? Hum. Na maioria das vezes, os gestores estão sob pressão de problemas, diante da necessidade de liberar algo com urgência e fazer uma entrega, e assim por diante. Eles observam como discutimos e discutimos constantemente sobre algo, e vêem assim: conversas, conversas, conversas... Que outras conversas? Volta para o trabalho! Porque conversar não parece um trabalho para eles. Você não escreve código, não testa software, parece não fazer nada - por que não mandar você fazer alguma coisa? Afinal, a entrega já é daqui a um mês!

Michael: Vá escrever algum código!

Tim: Parece-me que não estão preocupados com o trabalho, mas com a falta de visibilidade do progresso. Para fazer parecer que estamos cada vez mais perto do sucesso, eles precisam nos ver apertando botões no teclado. O dia inteiro, de manhã à noite. Este é o problema número um.

Oleg: Misha, você está pensando em algo.

Michael: Desculpe, me perdi em pensamentos e tive um flashback. Tudo isto me lembrou de um comício interessante que aconteceu ontem... Houve muitos comícios ontem... E tudo isso me parece muito familiar!

Vida sem salários

Tim: Aliás, não é necessário organizar “comícios” de comunicação. Quero dizer, as discussões mais úteis entre desenvolvedores acontecem quando eles conversam entre si. Você entra de manhã com uma xícara de café e há cinco pessoas reunidas discutindo furiosamente algo técnico. Para mim, se sou o gestor deste projeto, é melhor apenas sorrir e ir a algum lugar para tratar do meu negócio, deixá-los discutir o assunto. Eles já estão envolvidos tanto quanto possível. Isso é um bom sinal.

Oleg: A propósito, em seu livro você tem um monte de anotações sobre o que é bom e o que é ruim. Você mesmo usa algum deles? Relativamente falando, agora você tem uma empresa, estruturada de uma forma pouco ortodoxa...

Tim: Pouco ortodoxo, mas este dispositivo nos convém perfeitamente. Nós nos conhecemos há muito tempo. Confiamos um no outro, confiamos muito um no outro antes de nos tornarmos parceiros. E, por exemplo, não temos salário algum. Nós apenas trabalhamos e, por exemplo, se eu ganhasse dinheiro com meus clientes, todo o dinheiro ia para mim. Depois disso, pagamos taxas de adesão à organização, e isso é suficiente para sustentar a própria empresa. Além disso, todos nós nos especializamos em coisas diferentes. Por exemplo, trabalho com contadores, preencho declarações fiscais, faço todo tipo de trabalho administrativo para a empresa e ninguém me paga por isso. James e Tom trabalham em nosso site e ninguém lhes paga. 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; ele faz algumas coisas que não são para a Guilda. Mas enquanto ele pagar suas dívidas, ninguém virá até ele e dirá: “Ei, Tom, vá trabalhar!” É muito fácil lidar com colegas quando não há dinheiro entre vocês. E agora o nosso relacionamento é uma das ideias fundamentais em relação às diferentes especialidades. Funciona e funciona muito bem.

Melhor conselho

Michael: Voltando ao “melhor conselho”, há algo que você diz repetidamente aos seus clientes? Existe uma ideia de 80/20 e alguns conselhos provavelmente são repetidos com mais frequência.

Tim: Certa vez pensei que se você escrevesse um livro como Waltzing with Bears, isso mudaria o curso da história e as pessoas parariam, mas... Bem, veja bem, as empresas muitas vezes fingem que está tudo bem com elas. Assim que algo ruim acontece, é um choque e uma surpresa para eles. “Olha, testamos o sistema e ele não passa em nenhum teste de sistema, e são mais três meses de trabalho não programado, como isso pôde acontecer? Quem sabia? O que poderia dar errado? Sério, você acredita nisso?

Estou tentando explicar que você não deve ficar muito irritado com a situação atual. Precisamos conversar, entender realmente o que poderia ter dado errado e como evitar que tais coisas aconteçam no futuro. Se surgir um problema, como iremos combatê-lo, como iremos contê-lo?

Para mim, tudo isso parece assustador. As pessoas lidam com problemas complexos e incômodos e continuam a fingir que se apenas cruzarem os dedos e torcerem pelo melhor, o “melhor” realmente acontecerá. Não, não funciona assim.

Pratique o gerenciamento de riscos!

Michael: Na sua opinião, quantas organizações se dedicam à gestão de riscos?

Tim: O que me enfurece é que as pessoas simplesmente anotam os riscos, olham a lista resultante e vão trabalhar. Na verdade, identificar riscos para eles é gestão de riscos. Mas para mim isso parece um motivo para perguntar: ok, há uma lista, o que exatamente você vai mudar? Você precisa alterar suas sequências padrão de ações levando em conta esses riscos. Se houver alguma parte mais difícil do trabalho, você precisa resolvê-la e só então passar para algo mais simples. Nos primeiros sprints, comece a resolver problemas complexos. Isso já parece gerenciamento de risco. Mas geralmente as pessoas não conseguem dizer o que mudaram depois de compilar uma lista de riscos.

Michael: E, no entanto, quantas destas empresas estão envolvidas na gestão de riscos, cinco por cento?

Tim: Infelizmente, odeio dizer isso, mas esta é uma parte muito insignificante. Mas mais de cinco, porque existem projetos realmente grandes e eles simplesmente não podem existir se não fizerem pelo menos alguma coisa. Digamos apenas que ficarei muito surpreso se for pelo menos 25%. Pequenos projetos costumam responder a essas questões desta forma: se o problema nos afeta, então nós o resolveremos. Então, eles se metem em problemas e se envolvem na gestão de problemas e na gestão de crises. Quando você tenta resolver um problema e o problema não é resolvido, seja bem-vindo ao gerenciamento de crises.

Sim, ouço frequentemente: “resolveremos os problemas à medida que surgirem”. Certamente iremos? Será que realmente decidiremos?

Oleg: Você pode fazer isso de forma ingênua e simplesmente escrever invariantes importantes no termo de abertura do projeto e, se as invariantes quebrarem, basta reiniciar o projeto. Acontece que é muito piembucano.

Michael: Sim, aconteceu comigo que quando os riscos foram acionados, o projeto foi simplesmente redefinido. Legal, bingo, problema resolvido, não se preocupe mais!

Tim: Vamos pressionar o botão reset! Não, não funciona assim.

Palestra no DevOops 2019

Michael: Chegamos à última pergunta desta entrevista. Você está vindo para o próximo DevOops com uma palestra. Você poderia levantar a cortina do sigilo sobre o que vai contar?

Tim: Neste momento, seis deles estão a escrever um livro sobre a cultura do trabalho, as regras tácitas das organizações. A cultura é determinada pelos valores fundamentais da organização. Normalmente as pessoas não percebem isso, mas como trabalhamos em consultoria há muitos anos, estamos acostumados a perceber. Você entra em uma empresa e, literalmente, em poucos minutos começa a sentir o que está acontecendo. Chamamos isso de “sabor”. Às vezes esse perfume é muito bom, e às vezes é, bem, opa. As coisas são muito diferentes para organizações diferentes.

Michael: Eu também trabalho com 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 comunidade, têm sua própria cultura de equipe. Pode ser toda a empresa, ou um departamento separado, uma equipe separada. Mas antes que você dissesse, aqui está o que acreditamos, aqui está o que é importante... Você não pode mudar uma cultura antes que os valores e crenças por trás de ações específicas sejam compreendidos. O comportamento é fácil de observar, mas a busca por crenças é difícil. DevOps é apenas um ótimo exemplo de como as coisas estão se tornando cada vez mais complexas. As interações estão apenas se tornando mais complexas, não estão se tornando nada mais limpas ou claras, então você deve pensar sobre o que acredita e sobre o que todos ao seu redor silenciam.

Se você quer alcançar resultados rápidos, aqui vai um bom tema para você: já viu empresas onde ninguém diz “não sei”? Há lugares onde você literalmente tortura uma pessoa até que ela admita que não sabe de alguma coisa. Todo mundo sabe tudo, todo mundo é um erudito incrível. Você aborda qualquer pessoa e ela tem que responder instantaneamente à pergunta. Em vez de dizer “não sei”. Viva, eles contrataram um bando de eruditos! E em algumas culturas é geralmente muito perigoso dizer “não sei”; pode ser visto como um sinal de fraqueza. Existem também organizações nas quais, pelo contrário, todos podem dizer “não sei”. Lá é totalmente legal, e se alguém começar a falar besteira em resposta a uma pergunta, é completamente normal responder: “Você não sabe do que está falando, né?” e transformar tudo em uma piada.

Idealmente, você gostaria de ter um emprego onde pudesse ser constantemente feliz. Não vai ser fácil, nem todo dia é ensolarado e agradável, às vezes é preciso trabalhar muito, mas quando você começar a fazer um balanço vai acabar descobrindo: nossa, esse lugar é realmente maravilhoso, me sinto bem trabalhando aqui, tanto emocional quanto intelectualmente. E há empresas onde você vai como consultor e percebe instantaneamente que não aguentaria três meses e fugiria horrorizado. É sobre isso que quero falar no relatório.

Tim Lister chegará com uma palestra "Personagens, comunidade e cultura: fatores importantes para a prosperidade"à conferência DevOops 2019, que acontecerá de 29 a 30 de outubro de 2019 em São Petersburgo. Você pode comprar ingressos no site oficial. Esperamos por você no DevOops!

Fonte: habr.com

Adicionar um comentário