Dedicado a gerentes de projetos (e àqueles que sonham em se tornar chefes).
Escrever toneladas de código é difícil, mas gerenciar pessoas é ainda mais difícil! Então você só precisa deste livro para aprender como fazer as duas coisas.
É possível combinar histórias engraçadas e lições sérias? Michael Lopp (também conhecido em círculos estreitos como Rands) teve sucesso. Você encontrará histórias fictícias sobre pessoas fictícias com experiências incrivelmente gratificantes (embora fictícias). É assim que Rands compartilha suas experiências variadas, às vezes estranhas, adquiridas ao longo dos anos de trabalho em grandes corporações de TI: Apple, Pinterest, Palantir, Netscape, Symantec, etc.
Você é gerente de projetos? Ou quer entender o que seu maldito chefe faz o dia todo? Rands irá ensiná-lo a sobreviver no mundo tóxico dos perus inflados e a prosperar na loucura geral de pessoas disfuncionalmente extravagantes. Nesta estranha comunidade de cérebros maníacos existem criaturas ainda mais estranhas - gestores que, através de um ritual organizacional místico, ganharam poder sobre os planos, pensamentos e contas bancárias de muitas pessoas.
Este livro é diferente de qualquer manuscrito sobre gestão ou liderança. Michael Lopp não esconde nada, apenas conta as coisas como elas são (talvez nem todas as histórias devam ser tornadas públicas: P). Mas só assim você entenderá como sobreviver com um chefe assim, como administrar geeks e nerds e como levar “aquele maldito projeto” a um final feliz!
Excerto. Mentalidade de engenharia
Reflexões sobre: Você deve continuar escrevendo código?
O livro de Rands sobre regras para gerentes contém uma lista muito curta de "obrigações" gerenciais modernas. O laconicismo desta lista decorre do fato de que o conceito de “deve” ser uma espécie de absoluto e, quando se trata de pessoas, existem muito poucos conceitos absolutos. Um método de gestão bem-sucedido para um funcionário será um verdadeiro desastre para outro. Este pensamento é o primeiro item da lista de “obrigações” do gestor:
Mantenha-se flexível!
Pensar que você já sabe tudo é uma péssima ideia. Numa situação em que o único facto constante é que o mundo está em constante mudança, a flexibilidade torna-se a única posição correta.
Paradoxalmente, o segundo item da lista é surpreendentemente inflexível. No entanto, este ponto é o meu favorito porque acredito que ajuda a criar a base para o crescimento gerencial. Este parágrafo diz:
Pare de escrever código!
Em teoria, se você quer ser gerente, precisa aprender a confiar naqueles que trabalham para você e entregar a codificação inteiramente a eles. Esse conselho geralmente é difícil de digerir, especialmente para gestores recém-formados. Provavelmente, uma das razões pelas quais eles se tornaram gerentes é sua produtividade no desenvolvimento e, quando as coisas dão errado, sua primeira reação é recorrer às habilidades nas quais têm total confiança, que é a capacidade de escrever código.
Quando vejo que um gerente recém-formado “afunda” na escrita de código, digo a ele: “Sabemos que você pode escrever código. A questão é: você pode liderar? Você não é mais responsável apenas por si mesmo, você é responsável por toda a equipe; e quero ter certeza de que você conseguirá que sua equipe resolva os problemas por conta própria, sem que você precise escrever o código sozinho. Seu trabalho é descobrir como escalar a si mesmo. Não quero que você seja apenas um, quero que haja muitos como você.”
Bom conselho, certo? Escala. Gerenciamento. Responsabilidade. Palavras-chave tão comuns. É uma pena que o conselho esteja errado.
Incorreta?
Sim. O conselho está errado! Não completamente errado, mas errado o suficiente para que eu tivesse que ligar para alguns ex-colegas e pedir desculpas: “Lembra daquela minha afirmação favorita sobre como você deveria parar de escrever código? Está errado! Sim... Comece a programar novamente. Comece com Python e Ruby. Sim, estou a falar a sério! Sua carreira depende disso!”
Quando comecei minha carreira como desenvolvedor de software na Borland, trabalhei na equipe Paradox Windows, que era uma equipe enorme. Havia 13 desenvolvedores de aplicativos sozinhos. Se você adicionar pessoas de outras equipes que também trabalhavam constantemente em tecnologias-chave para este projeto, como o mecanismo de banco de dados principal e os serviços de aplicativos principais, você teria 50 engenheiros diretamente envolvidos no desenvolvimento deste produto.
Nenhuma outra equipe em que trabalhei chega perto desse tamanho. Na verdade, a cada ano que passa, o número de pessoas na equipe em que trabalho diminui gradativamente. O que está acontecendo? Estamos nós, desenvolvedores, coletivamente ficando cada vez mais inteligentes? Não, estamos apenas compartilhando a carga.
O que os desenvolvedores têm feito nos últimos 20 anos? Durante esse tempo, escrevemos um monte de código. Mar de código! Escrevemos tanto código que decidimos que seria uma boa ideia simplificar tudo e adotar o código aberto.
Felizmente, graças à Internet, este processo tornou-se o mais simples possível. Se você é desenvolvedor de software, pode conferir agora mesmo! Pesquise seu nome no Google ou Github e você verá um código que você esqueceu há muito tempo, mas que qualquer pessoa pode encontrar. Assustador, certo? Você não sabia que o código dura para sempre? Sim, ele vive para sempre.
O código vive para sempre. E um bom código não apenas vive para sempre, mas também cresce porque aqueles que o valorizam garantem constantemente que ele permaneça atualizado. Essa pilha de código bem mantido e de alta qualidade ajuda a reduzir o tamanho médio da equipe de engenharia porque nos permite focar no código existente em vez de escrever um novo código, e realizar o trabalho com menos pessoas e em um período de tempo mais curto.
Essa linha de raciocínio parece deprimente, mas a ideia é que somos todos apenas um bando de autômatos de integração que usam fita adesiva para conectar diferentes partes de coisas existentes e criar uma versão ligeiramente diferente da mesma coisa. Esta é uma linha clássica de pensamento entre os executivos seniores que amam a terceirização. “Qualquer pessoa que saiba usar o Google e tenha fita adesiva pode fazer isso! Então por que estamos pagando tanto dinheiro pelas nossas máquinas?”
Pagamos muito dinheiro a esses gestores, mas eles pensam que são bobagens. Mais uma vez, meu ponto principal é que existem muitos desenvolvedores brilhantes e muito trabalhadores em nosso planeta; eles são verdadeiramente brilhantes e diligentes, embora não tenham passado um único minuto sentados em universidades credenciadas. Ah, sim, agora há cada vez mais deles!
Não sugiro que você comece a se preocupar com o seu lugar só porque alguns camaradas brilhantes estão supostamente procurando por ele. Sugiro que você comece a se preocupar com isso porque a evolução do desenvolvimento de software provavelmente está avançando mais rápido do que você. Você trabalha há dez anos, cinco deles como gestor, e pensa: “Já sei como se desenvolve software”. Sim, você sabe. Tchau…
Pare de escrever código, mas...
Se você seguir meu conselho original e parar de escrever código, também deixará de participar voluntariamente do processo de criação. É por esta razão que não utilizo ativamente a terceirização. Os autômatos não criam, eles produzem. Processos bem desenhados economizam muito dinheiro, mas não trazem nada de novo ao nosso mundo.
Se você tem uma equipe pequena fazendo muito por pouco dinheiro, então a ideia de parar de escrever código me parece uma má decisão profissional. Mesmo em empresas monstruosas com suas intermináveis regulamentações, processos e políticas, você não tem o direito de esquecer como desenvolver software sozinho. E o desenvolvimento de software está em constante mudança. Está mudando agora. Sob seus pés! Neste exato segundo!
Você tem objeções. Entender. Vamos ouvir.
“Rands, estou indo para a cadeira do diretor! Se eu continuar escrevendo código, ninguém acreditará que posso crescer.”
Quero perguntar o seguinte: desde que você sentou na cadeira “Estou prestes a ser CEO!”, você percebeu que o cenário de desenvolvimento de software está mudando, até mesmo dentro da sua empresa? Se a sua resposta for sim, então farei outra pergunta: como exatamente isso está mudando e o que você vai fazer a respeito dessas mudanças? Se você respondeu “não” à minha primeira pergunta, então você precisa passar para uma cadeira diferente, porque (aposto!) o campo do desenvolvimento de software está mudando neste exato momento. Como você vai crescer se, lenta mas seguramente, esquecer como desenvolver software?
Meu conselho é não se comprometer a implementar vários recursos em seu próximo produto. Você precisa tomar medidas constantemente para ficar por dentro de como sua equipe está construindo software. Você pode fazer isso tanto como diretor quanto como vice-presidente. Algo mais?
“Uh, Rands! Mas alguém tem que ser o árbitro! Alguém tem que ver o quadro geral. Se eu escrever código, perderei a perspectiva."
Você ainda precisa ser o árbitro, ainda precisa transmitir as decisões e ainda precisa andar pelo prédio quatro vezes todas as segundas-feiras de manhã com um de seus engenheiros para ouvir seu discurso semanal "Estamos todos condenados" por 30 anos. minutos. ! Mas, além de tudo isso, você precisa manter uma mentalidade de engenharia e não precisa ser um programador em tempo integral para fazer isso.
Minhas dicas para manter uma mentalidade de engenharia:
- Use o ambiente de desenvolvimento. Isso significa que você deve estar familiarizado com as ferramentas da sua equipe, incluindo o sistema de criação de código, controle de versão e linguagem de programação. Como resultado, você se tornará proficiente na linguagem que sua equipe usa ao falar sobre desenvolvimento de produtos. Isso também permitirá que você continue usando seu editor de texto favorito, que está funcionando perfeitamente.
- Você deve ser capaz de desenhar um diagrama arquitetônico detalhado descrevendo seu produto em qualquer superfície e a qualquer momento. Agora não me refiro à versão simplificada com três células e duas setas. Você deve conhecer o diagrama detalhado do produto. O mais difícil. Não apenas um diagrama qualquer, mas um diagrama difícil de explicar. Deve ser um mapa adequado para uma compreensão completa do produto. Está em constante mudança e você deve sempre saber por que ocorreram certas mudanças.
- Assuma a implementação de uma das funções. Estou literalmente estremecendo ao escrever isso porque esse ponto tem muitos perigos ocultos, mas não tenho certeza se você pode cumprir o ponto 1 e o ponto 2 sem se comprometer a implementar pelo menos um recurso. Ao implementar você mesmo um dos recursos, você não apenas estará ativamente envolvido no processo de desenvolvimento, mas também permitirá que você mude periodicamente da função de “Gerente responsável por tudo” para a função de “Homem responsável pela implementação de um das funções.” Essa atitude humilde e despretensiosa irá lembrá-lo da importância das pequenas decisões.
- Ainda estou tremendo. Parece que alguém já está gritando comigo: “O gestor que assumiu a implementação da função?! (E eu concordo com ele!) Sim, você ainda é o gerente, o que significa que deve ser uma função pequena, ok? Sim, você ainda tem muito que fazer. Se você simplesmente não consegue implementar a função, tenho alguns conselhos alternativos para você: corrija alguns bugs. Nesse caso, você não sentirá a alegria da criação, mas terá uma compreensão de como o produto é criado, o que significa que nunca ficará sem trabalho.
- Escreva testes unitários. Ainda faço isso no final do ciclo de produção, quando as pessoas começam a enlouquecer. Pense nisso como uma lista de verificação de saúde para o seu produto. Faça isso com frequência.
Objeção de novo?
“Rands, se eu escrever código, vou confundir minha equipe. Eles não saberão quem eu sou: um gerente ou um desenvolvedor.”
Tudo bem.
Sim, eu disse: "Ok!" Fico feliz que você pense que pode confundir sua equipe apenas nadando no lago dos desenvolvedores. É simples: as fronteiras entre as diferentes funções no desenvolvimento de software são atualmente muito confusas. O pessoal da UI faz o que pode ser chamado de programação JavaScript e CSS. Os desenvolvedores estão aprendendo cada vez mais sobre design de experiência do usuário. As pessoas se comunicam entre si e aprendem sobre bugs, sobre roubo de código de outras pessoas e também sobre o fato de que não há uma boa razão para um gerente não participar dessa bacanal de informações massiva, global e de polinização cruzada.
Além disso, quer fazer parte de uma equipe composta por componentes facilmente substituíveis? Isso não apenas tornará sua equipe mais ágil, mas também dará a cada membro da equipe a oportunidade de ver o produto e a empresa de diversas perspectivas. Como você pode respeitar Frank, o cara calmo responsável pelas construções, mais do que depois de ver a elegância simples de seus scripts de construção?
Não quero que sua equipe fique confusa e caótica. Pelo contrário, quero que sua equipe se comunique de forma mais eficaz. Acredito que se você estiver envolvido na criação do produto e trabalhando nas funcionalidades, estará mais próximo da sua equipe. E o mais importante, você estará mais próximo das constantes mudanças no processo de desenvolvimento de software dentro da sua organização.
Não pare de desenvolver
Certa vez, uma colega minha na Borland me atacou verbalmente por chamá-la de “codificadora”.
“Rands, o codificador é uma máquina estúpida! Macaco! O codificador não faz nada importante, exceto escrever linhas enfadonhas de código inútil. Não sou um programador, sou um desenvolvedor de software!”
Ela estava certa, ela teria odiado meu conselho inicial aos novos CEOs: “Pare de escrever código!” Não porque eu esteja sugerindo que eles sejam programadores, mas mais porque estou sugerindo proativamente que eles comecem a ignorar uma das partes mais importantes de seu trabalho: o desenvolvimento de software.
Então atualizei meu conselho. Se você quer ser um bom líder, pode parar de escrever código, mas...
Seja flexível. Lembre-se do que significa ser engenheiro e não pare de desenvolver software.
Sobre o autor
Michael Lopp é um desenvolvedor de software veterano que ainda não saiu do Vale do Silício. Nos últimos 20 anos, Michael trabalhou para diversas empresas inovadoras, incluindo Apple, Netscape, Symantec, Borland, Palantir, Pinterest, e também participou de uma startup que lentamente caiu no esquecimento.
Fora do trabalho, Michael mantém um blog popular sobre tecnologia e gestão sob o pseudônimo de Rands, onde discute ideias na área de gestão com os leitores, expressa preocupação com a necessidade constante de manter o controle sobre o pulso e explica que, apesar do recompensas generosas pela criação de um produto, seu sucesso só é possível graças à sua equipe. O blog pode ser encontrado aqui .
Michael mora com sua família em Redwood, Califórnia. Ele sempre encontra tempo para praticar mountain bike, jogar hóquei e beber vinho tinto, pois ser saudável é mais importante do que estar ocupado.
» Mais detalhes sobre o livro podem ser encontrados em
»
»
Para Khabrozhiteley 20% de desconto usando cupom - Gerenciando pessoas
Após o pagamento da versão em papel do livro, uma versão eletrônica do livro será enviada por e-mail.
PS: 7% do preço do livro irá para a tradução de novos livros de informática, lista de livros entregue à gráfica .
Fonte: habr.com