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 . Na Rússia, seus colegas são mais famosos - и , 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 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?
Тим: 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 (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?
Тим: 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.
Тим: Acho que as metodologias ágeis, começando com 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?
Так что идея вроде «Мы за аджайл, заказчик сам нам расскажет, что хочет получить» — она супернаивная. Заказчики ведь даже не знают, чего они хотят, и тем более они не знают, чего могли бы получить. Кое-кто начнёт приводить в качестве аргументов исторические примеры, я такое уже видел. Но технически продвинутые люди так обычно не говорят. Они говорят: «Сейчас 2019 год, вот такие у нас есть возможности, и мы можем полностью изменить взгляд на подобные вещи!». Вместо того, чтобы мимикрировать под существующие решения, делая их чуточку красивее и причёсанней, иногда нужно выйти и сказать: «Давайте полностью переизобретём то, чем мы тут пытаемся заниматься!».
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?
Тим: 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?
Тим: 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?
Тим: На это можно смотреть со множества разных сторон. Если говорить социологически… когда-то, в более простые времена, вы с командой сидели в одном офисе. Вы могли каждый день быть рядом, вместе распивать кофе и обсуждать работу. Что действительно изменилось, так это то, что теперь команды могут быть распределены географически, в разных странах и часовых зонах, но тем не менее они работают над одной задачей, и это добавляет целый новый пласт сложности. Это может прозвучать по-стариковски, но нет ничего лучше общения лицом к лицу, когда вы все собрались вместе, вместе работаете, можно подойти к коллеге и сказать: гляди, что я обнаружил, как тебе это? Разговоры лицом к лицу дают быстрый способ перейти к неформальному общению, и я думаю, это должно понравиться любителям аджайла тоже. А ещё я беспокоюсь потому, что в реальности мир оказался очень маленьким, и теперь весь он покрыт распределенными командами, и всё это очень сложно.
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?
Тим: 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!
Тим: 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: Вы обычно рассказываете о паттернах и антипаттернах, и это разница между жизнью и смертью проектов. И вот, в нашу жизнь врывается девопс. Есть ли у него какие-то свои паттерны и антипаттерны, которые могут убить проект на месте?
Тим: Паттерны и антипаттерны происходят вокруг всё время. О чём бы рассказать. Ну вот, есть вещь, которую мы называем «блестящие штуки». Людям очень, очень нравятся новые технологии. Они просто заворожены блеском всего, что выглядит круто и стильно, и перестают задаваться вопросами: а оно вообще нужно? Чего мы собираемся достичь? Надежна ли эта штука, имеет ли она хоть какой-то смысл? Я часто вижу людей, скажем так, на переднем крае технологий. Они загипнотизированы тем, что происходит в мире. Но если пристальней вглядеться, что же полезного они делают – зачастую, ничего полезного просто нет!
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?
Тим: Именно, и это обычный ход вещей! Например… кажется, это уже стало шуткой по всему миру, но здесь люди часто говорят про блокчейн-технологии. И они действительно имеют смысл в определённых ситуациях! Когда вам действительно нужны надёжные свидетельства событий, что система работает и что нас никто не обманул, когда у вас проблемы с безопасностью и всё такое прочее, смешанное вместе – блокчейн имеет смысл. Но когда говорят, что Блокчейн сейчас пронесётся по всему миру, сметая всё на своём пути? Мечтайте больше! Это очень дорогая и сложная технология. Технически сложная, требующая временных затрат. В том числе и чисто алгоритмически, каждый раз вам нужно пересчитывать математику, при малейших изменениях… и это отличная идея – но только для определённых случаях. У меня вся жизнь и карьера об этом: интересные идеи в очень определённых ситуациях. Очень важно понимать, какая ситуация именно у тебя.
Michael: Sim, a principal “questão da vida, do universo e de tudo”: esta tecnologia ou abordagem é adequada à sua situação ou não?
Тим: 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.
Тим: 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”.
Тим: 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: Заслуженные инженеры, да. Давайте, пока есть время, коснёмся ещё управления рисками. Мы начали это интервью обсуждением медицинского софта, где ошибки могут привести к печальным последствиям. Дальше мы говорили о Лунной Программе, где стоимость ошибки – миллионы долларов, и возможно – несколько человеческих жизней. Но сейчас я вижу в индустрии противоположное движение, люди не думают о рисках, не пытаются их предсказывать, даже не наблюдают за ними.
Oleg: Mova-se rápido e quebre as coisas!
Michael: Да, продвигайся быстро, ломай вещи, всё больше и больше вещей – и так пока не умрёшь от чего-нибудь. С вашей точки зрения, как сейчас обычному разработчику подступиться к изучению управления рисками?
Тим: 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.
Зачастую проблемы проще всего решать, когда они уже вылезли, когда проблема происходит прямо сейчас. Но когда проблема прямо перед тобой, ты не занимаешься управлением рисками – ты занимаешься решением этой проблемы, кризисным управлением. Если ты ведущий разработчик или менеджер, ты должен задумываться, что может случится такого, что приведет к задержкам, потере времени, лишним затратам или краху всего проекта? Что заставит нас остановиться и начать всё заново? Когда все эти вещи сработают, что мы будем с ними делать? Есть простой ответ, справедливый для большинства ситуаций: не бегите от рисков, работайте над ними. Посмотрите, как можно разрешить рисковую ситуацию, свести её на нет, превратить её из проблемы во что-то ещё. Вместо того чтобы говорить: ну, будем решать проблемы по мере их поступления.
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.
И снова, в чем уникальность вашего проекта? Давайте посмотрим, что может заставить наш проект съехать с накатанных рельсов. Что мы можем сделать для минимизации вероятности, что всё это произойдёт. Обычно вы не можете просто взять и нейтрализовать их на 100%, чтобы с чистой совестью заявлять: «Всё, это больше не проблема, риск рассосался!». Для меня это признак взрослого поведения. Это разница между ребенком и взрослым – дети думают, что бессмертны, что ничего не может пойти наперекосяк, всё будет отлично! В то же время, взрослые смотрят, как трехлетние дети прыгают на детской площадке, провожают глазами движения и говорят про себя: «ох – ух, ох – ух». Я стою неподалёку и готовлюсь ловить, когда ребенок всё-таки упадёт.
С другой стороны, причина, почему мне так нравится этот бизнес – потому что он рисковый. Мы делаем вещи, и эти вещи рискованные. Требуют взрослого подхода. Энтузиазм сам по себе не решит ваших проблем!
Взрослое инженерное мышление
Michael: Пример с детьми хорош. Если я обычный инженер, то мне приятно быть ребенком. Но как продвинуться к более взрослому мышлению?
Тим: 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.
Тим: 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.
Тим: 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?
Тим: 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?
Тим: 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.
Тим: Что можно сделать, можно выйти и открыто сказать: «Всё в порядке, я справлюсь! Не я один испытываю дискомфорт. Давайте обсудим разные некомфортные штуки, все вместе, как команда!». Это наши общие проблемы, мы должны с ними справляться, понимаете? Думаю, идиосинкратические гениальные разработчики – они как мамонты, они исчезли. Да и значение они имеют очень ограниченное. Если вы не можете общаться, вы не можете нормально участвовать. Поэтому – просто говорите. Будьте честными и открытыми. Я очень сожалению, что кому-то это неприятно. Представляете, много лет назад было исследование, согласно которому в США основной страх – это не смерть, а угадайте что? Страх публичных выступлений! Значит, где-то есть люди, которые скорей умрут, чем вслух скажут комплимент. А вам, думаю, достаточно иметь какие-то базовые навыки, в зависимости от того, что вы делаете. Разговорные навыки, навыки письма – но настолько, насколько это действительно нужно в вашей работе. Если вы работаете аналитиком, но при это не можете читать, писать и говорить, то к большому сожалению, вам нечем будет заняться в моих проектах!
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!
Тим: Я имел в виду ядро команды, а не вообще всех подряд. Если у вас есть специалист, который действительно круто настраивает базы данных, любит настраивать базы данных и собирается продолжать настраивать ваши базы данных до конца жизни, и это всё – круто, так держать. Но я говорю о людях, которые хотят жить в самом проекте. Ядро команды, направленно развивающее проект. Этим людям действительно необходимо постоянно общаться друг с другом. И в особенности, в начале проекта, когда вы обсуждаете риски, способы достижения глобальных целей и тому подобные вещи.
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.
Тим: 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?
Тим: 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: Иди писать код!
Тим: 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!
Жизнь без зарплат
Тим: 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...
Тим: 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.
Тим: 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: С вашей точки зрения, как много организаций занимаются менеджментом рисков?
Тим: 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?
Тим: 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: Можно делать наивно и просто вписывать в устав проекта важные инварианты, и если инварианты сломались – просто перезапускать проект. Получается очень по-пиэмбучному.
Michael: Sim, aconteceu comigo que quando os riscos foram acionados, o projeto foi simplesmente redefinido. Legal, bingo, problema resolvido, não se preocupe mais!
Тим: 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?
Тим: 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.
Тим: Собственно, одна из вещей, о которой стоит поговорить на кейноуте, что не всё определяется компанией. Вы и ваша команда, как сообщество – у вас есть собственная командная культура. Это может быть как вся компания, так и отдельный департамент, отдельная команда. Но до того, как ты сказал: вот во что мы верим, вот что важно… Ты не можешь изменить культуру до того, как были осознаны ценности и убеждения, которые стоят за конкретными действиями. Поведение наблюдать легко, а искать убеждения – сложно. DevOps – это как раз отличный пример того, как всё становится сложнее и сложнее. Взаимодействия становятся только сложнее, они вообще не становятся чище и понятней, так что вам стоит задумываться над тем, во что вы верите, и про что все вокруг молчат.
Хотите добиться быстрых результатов, вот вам хорошая тема: видели ли вы компании, в которых никто не говорит «я не знаю»? Есть места, в которых нужно буквально пытать человека до тех пор, пока он признается, что чего-то не знает. Все всё знают, все подряд невероятные эрудиты. Подходишь к любому человеку, и ему приходится мгновенно что-то отвечать на вопрос. Вместо того чтобы сказать «Я не знаю». Ура, они наняли толпу эрудитов! А в каких-то культурах вообще очень опасно говорить «Я не знаю», это может быть воспринято как проявление слабости. Есть и организации в которых наоборот, все могут говорить «я не знаю». Там это совершенно легально, и если кто-то в ответ на вопрос начнёт втирать дичь, совершенно нормально ответить: «Ты ведь не понимаешь, о чём говоришь, верно?» и свести всё на шутку.
В идеале, хотелось бы иметь такую работу, на которой ты мог бы постоянно быть счастлив. Это будет непросто, не каждый день солнечный и приятный, иногда нужно напряжённо работать, но когда ты начнёшь подводить итоги, то окажется: вау, это действительно чудесное место, мне хорошо тут работать, и эмоционально, и интеллектуально. А есть компании, в которые ты заходишь как консультант и мгновенно понимаешь, что и три месяца бы не выдержал и сбежал бы в ужасе. Вот об этом я и хочу поговорить на докладе.
Tim Lister chegará com uma palestra à conferência DevOops 2019, que acontecerá de 29 a 30 de outubro de 2019 em São Petersburgo. Você pode comprar ingressos . Esperamos por você no DevOops!
Fonte: habr.com