O livro “Como gerenciar intelectuais. Eu, nerds e geeks "

Dedicado aos gerentes de projeto (e àqueles que sonham em se tornar um chefe).

Escrever toneladas de código é difícil, e 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 legais e lições sérias? Michael Lopp (também conhecido em círculos estreitos como Randes) conseguiu. Histórias de ficção sobre pessoas fictícias com experiências incrivelmente úteis (embora fictícias) esperam por você. É assim que Randy compartilha sua experiência diversa, às vezes estranha, adquirida 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? Rand irá ensiná-lo a sobreviver no mundo tóxico de perus inflados e a prosperar na loucura geral de pessoas disfuncionalmente vibrantes. Nesta comunidade estranha de sábios maníacos, existem criaturas ainda mais estranhas - gerentes que, através de um ritual organizacional místico, ganharam poder sobre os planos, pensamentos e contas bancárias de muitas pessoas.

Este livro não é como nenhum manuscrito sobre administração ou liderança. Michael Lopp não esconde nada, ele apenas conta tudo como está (talvez nem todas as histórias devam ser tornadas públicas: R). Mas somente dessa maneira você entenderá como pode sobreviver com um chefe assim, como gerenciar nerds e nerds e como levar “esse maldito projeto” para o final feliz!

Trecho. Mentalidade de engenharia

Reflexões sobre o tópico: você precisa continuar escrevendo código

Há uma lista muito curta de gerentes modernos que devem fazer no livro de Rands sobre regras de liderança. O laconicismo dessa lista decorre do fato de que o conceito de "must" é uma espécie de absoluto e, quando se trata de pessoas, existem muito poucos conceitos absolutos. Um método bem-sucedido de gerenciar um funcionário será um verdadeiro desastre para outro. Essa ideia é o primeiro item da lista de tarefas obrigatórias:

Mantenha-se flexível!

Considerar que você já sabe que tudo é uma péssima idéia. Em uma situação em que o único fato imutável é o fato de que constantes mudanças estão ocorrendo no mundo, a flexibilidade se torna a única posição verdadeira.

Paradoxalmente, o segundo item da lista é surpreendentemente inflexível. No entanto, este item é meu favorito pessoal, porque acredito que ajuda a criar a base para o crescimento gerencial. Este parágrafo diz:

Pare de escrever código!

Teoricamente, se você quer ser um líder, deve aprender a confiar naqueles que trabalham para você e passar completamente a codificação para eles. Esse conselho geralmente é difícil de "digerir", especialmente por novos líderes. Provavelmente, uma das razões pelas quais eles se tornaram líderes é sua produtividade no desenvolvimento e, quando as coisas dão errado, sua primeira reação é recorrer a habilidades nas quais eles estão completamente confiantes, ou seja, à sua capacidade de escrever código.

Quando vejo que um líder recém-cunhado "cai" antes de escrever o código, digo a ele: "Sabemos que você pode escrever código. A questão é diferente: você sabe liderar? Você não é mais responsável sozinho, é responsável por toda a equipe; e quero ter certeza de que você pode fazer com que sua equipe resolva os problemas por conta própria, sem precisar escrever código sozinho. Sua tarefa é descobrir como se escalar. Quero que você não seja o único, quero tantas pessoas como você.

Bons conselhos, certo? Escala. Gerência Responsabilidade Palavras-chave tão comuns. É uma pena que o conselho esteja incorreto.

Errado?

Sim O conselho está errado! Não que isso esteja completamente errado, mas errado o suficiente para que eu tenha que ligar para alguns ex-colegas e me desculpar: “Lembre-se da minha afirmação favorita de que você deveria parar de escrever código? Está errado! Sim ... comece a programar novamente. Comece com Python e Ruby. Sim, estou falando sério! Sua carreira depende disso! ”

Quando iniciei minha carreira como desenvolvedor de software na Borland, trabalhei na equipe Paradox para Windows, e era uma equipe enorme. Apenas um desenvolvedor de aplicativos tinha 13 pessoas. Se adicionarmos pessoas de outras equipes que também trabalharam constantemente nas principais tecnologias para este projeto, como o principal mecanismo de banco de dados e os principais serviços de aplicativos, teremos 50 engenheiros diretamente envolvidos no desenvolvimento deste produto.

Nenhuma outra equipe em que trabalhei chegou nem perto de tamanhos semelhantes. De fato, a cada ano que passa, o número de pessoas na equipe em que trabalho diminui gradualmente. O que está havendo? Somos desenvolvedores, coletivamente, cada vez mais inteligentes? Não, apenas distribuímos a carga.

O que os desenvolvedores estão fazendo nos últimos 20 anos? Durante esse período, escrevemos um monte de código porcaria. Mar de código! Nós escrevemos tanto código que decidimos: seria bom simplificar tudo e mudar para o código-fonte aberto.

Felizmente, graças à Internet, esse processo agora se tornou o mais simples possível. Se você é um desenvolvedor de software, pode conferir agora mesmo! Pesquise seu nome no Google ou no Github e você verá um código que você esqueceu há muito tempo, mas que qualquer pessoa que desejar pode encontrar. Assustador, hein? Você não sabia que o código vive para sempre? Sim, ele vive para sempre.

O código vive para sempre. E um bom código não só vive para sempre, mas cresce, porque quem o valoriza constantemente se preocupa em não perder sua frescura. Esse conjunto de códigos de alta qualidade e bem mantidos ajuda a reduzir o tamanho médio de uma equipe de engenharia, porque nos permite focar não na escrita de um novo código, mas no código existente e trabalhar com menos pessoas envolvidas e em menos tempo.

Essa linha de raciocínio parece deprimente, mas a idéia é que todos nós somos apenas um monte de máquinas de integração que usam fita adesiva para conectar diferentes partes das coisas existentes para criar uma versão ligeiramente diferente da mesma coisa. Essa é uma linha de pensamento clássica para a alta gerência que adora terceirizar. “Isso pode ser feito por qualquer pessoa que saiba usar o Google e que tenha fita adesiva! Então, por que estamos pagando uma tonelada de dinheiro em nossas máquinas de venda automática? ”

Pagamos a esses tipos de executivos muito dinheiro e eles acham esse absurdo. Mais uma vez: minha idéia principal é que existem muitos desenvolvedores brilhantes e muito diligentes em nosso planeta; eles são realmente brilhantes e zelosos, embora não tenham passado um único minuto sentado em universidades credenciadas. Ah, sim, agora existem mais e mais deles!

Não sugiro que você comece a se preocupar com o seu lugar só porque alguns camaradas brilhantes supostamente o atacam. Eu sugiro que você comece a se preocupar com ele, porque a evolução do desenvolvimento de software pode estar se movendo mais rápido que você. Você trabalha há dez anos, dos quais cinco como líder, e pensa: "Eu já sei como o software é desenvolvido". Sim você sabe. Tchau ...

Pare de escrever código, mas ...

Se você seguir o meu conselho inicial e parar de escrever o código, ao mesmo tempo, deixará de participar voluntariamente do processo de criação. É por esse motivo que não sou particularmente ativo na terceirização. Máquinas não criam, elas produzem. Processos bem projetados podem economizar muito dinheiro, mas não trarão nada de novo ao nosso mundo.

Se você tem uma equipe pequena e faz muito por pouco dinheiro, a ideia de parar de escrever código parece uma má decisão de carreira. Mesmo em empresas monstruosas com seus inúmeros regulamentos, processos e políticas, você não tem o direito de esquecer como desenvolver software por conta própria. E o desenvolvimento de software está mudando constantemente. Ela está mudando agora. Sob seus pés! Este mesmo segundo!

Você tem uma objeção. Eu entendo Vamos ouvir.

"Randy, estou a caminho da cadeira do diretor!" Se eu continuar escrevendo código, ninguém acreditará que sou capaz de crescer. ”

Quero lhe perguntar: desde que você assumiu o cargo “Em breve me tornarei diretor!”, Você já reparou que o campo do desenvolvimento de software está mudando mesmo dentro da sua empresa? Se sua resposta for sim, então eu farei outra pergunta: como exatamente isso muda e o que você fará em relação a essas mudanças? Se você respondeu "não" à minha primeira pergunta, precisa mudar para outra cadeira, porque (eu dou um dente!) O escopo do desenvolvimento de software muda neste mesmo instante. Como você vai crescer se esquecer lenta e seguramente como desenvolver software?

Meu conselho é não confiar em muitos recursos para o seu próximo produto. Você precisa tomar medidas constantemente para se manter atualizado sobre como sua equipe cria software. Você pode fazer isso como diretor e como vice-presidente. Algo mais?

Randy! Mas alguém deve ser um árbitro! Alguém deve ver o quadro geral. Se eu escrever um código, perderei de vista a perspectiva ".

Você ainda precisa permanecer como árbitro, deve transmitir as decisões e ainda precisa percorrer o prédio quatro vezes toda segunda-feira de manhã com um de seus engenheiros para ouvir seu discurso semanal por 30 minutos: “Estamos todos condenados ! " Mas, além de tudo isso, você deve manter o pensamento de engenharia em si mesmo e, para isso, não precisa ser um programador em tempo integral.

Meu conselho sobre como manter uma mentalidade de engenharia:

1. Use o ambiente de desenvolvimento. Isso significa que você deve estar familiarizado com as ferramentas de sua equipe, incluindo um sistema de criação de código, controle de versão e uma linguagem de programação. Como resultado, você será fluente no idioma que sua equipe usa quando fala sobre desenvolvimento de produtos. Também permitirá que você continue usando seu editor de texto favorito que funciona muito bem.
2. Você deve poder desenhar um diagrama arquitetural detalhado que descreva seu produto em qualquer superfície e a qualquer momento. Agora não quero dizer uma 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 esquema bonito, mas um esquema difícil de explicar. Este deve ser um cartão adequado para uma compreensão completa do produto. Está constantemente mudando, e você sempre deve saber por que essas ou outras alterações ocorreram.
3. Assuma a implementação de uma das funções. Eu literalmente tremo quando escrevo isso, porque esse ponto está repleto de muitos perigos ocultos, mas eu realmente não tenho certeza de que você possa cumprir o parágrafo 1 e o parágrafo 2 sem assumir pelo menos uma função . Graças à implementação independente de uma das funções, você não apenas participará ativamente do processo de desenvolvimento, mas também permitirá que você alterne periodicamente do papel de "Gerente responsável por tudo" para o papel de "Pessoa responsável pela implementação de uma das funções". Essa posição modesta e despretensiosa lembrará a importância de pequenas decisões.
4. Eu ainda estou tremendo. Parece que alguém já está gritando comigo: “O líder que assumiu a implementação da função ?! (E eu concordo com ele!) Sim, você continua sendo um líder, o que significa que deve ser uma pequena função, ok? Sim, você ainda tem muito o que fazer. Se você não pode assumir a implementação da função de forma alguma, tenho uma dica extra: lide com alguns bugs. Nesse caso, você não sentirá as alegrias da criação, mas entenderá como o produto é criado, o que significa que nunca ficará de fora do trabalho.
5. Escreva testes de unidade. Eu ainda faço isso nas fases posteriores do ciclo de produção, quando as pessoas começam a enlouquecer. Pense nisso como uma lista de verificação de saúde para seu produto. Faça isso frequentemente.

Uma objeção de novo?

“Rand, se eu escrever o código, confundirei minha equipe. Eles não saberão quem eu sou, o líder ou o desenvolvedor. ”

Bom

Sim, eu disse: "Bom!" Fico feliz que você acredite que só pode confundir sua equipe nadando em um lago de desenvolvedores. Tudo é simples aqui: as fronteiras entre os vários papéis no campo do desenvolvimento de software estão atualmente muito borradas. Os caras da interface do usuário estão fazendo o que geralmente pode ser chamado de programação JavaScript e CSS. Os desenvolvedores estão aprendendo cada vez mais sobre o design de interações do usuário. As pessoas se comunicam e aprendem sobre os erros, o roubo do código de outra pessoa e também que não há boas razões para o líder não poder participar dessa bacanal maciça, global e de polinização cruzada de informações.

Além disso, você deseja fazer parte de uma equipe formada por componentes facilmente substituíveis? Isso não apenas tornará sua equipe mais ágil, como também dará a cada um de seus membros a oportunidade de ver o produto e a empresa de vários pontos de vista. Como você ainda pode respeitar Frank, aquele cara legal responsável pelo layout, se não depois de ver a elegância simples de seus scripts de montagem?

Não quero confusão e caos reinando em sua equipe. Pelo contrário, quero que a comunicação em sua equipe se torne mais eficaz. Tenho certeza de que, se você estiver envolvido na criação de um produto e no trabalho de recursos, estará mais perto da sua equipe. E, mais importante, você estará mais próximo das constantes mudanças no processo de desenvolvimento de software em sua organização.

Não pare de desenvolver

Uma vez, uma colega minha da Borland me atacou verbalmente por chamá-la de "codificadora".

“Rand, o codificador é uma máquina sem cérebro! Macaco Um codificador não faz nada além de escrever linhas chatas de código inútil. Não sou codificador, sou desenvolvedor de software! "

Ela estava certa, ela odiaria o meu conselho inicial para os novos líderes: "Pare de escrever código!" Não porque, com isso, suponho que sejam codificadores, mas mais porque sugiro proativamente que eles comecem a ignorar uma das partes mais importantes de seu trabalho - o desenvolvimento de software.

Então, finalizei 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 veterano em desenvolvimento de software que ainda não saiu do Vale do Silício. Nos últimos 20 anos, Michael conseguiu trabalhar em uma variedade de empresas inovadoras, incluindo Apple, Netscape, Symantec, Borland, Palantir, Pinterest, além de participar de uma startup que lentamente partiu para o esquecimento.

Além de seu trabalho, Michael mantém um blog popular sobre tecnologias e gerenciamento sob o pseudônimo de Rands, onde discute idéias de gerenciamento com os leitores, manifesta preocupação com a constante necessidade de se manter atualizado e explica que, apesar das recompensas generosas pelo produto criado, seu sucesso é possível apenas graças à sua equipe. O blog pode ser encontrado em www.randsinrepose.com .

Michael mora com sua família em Redwood, Califórnia. Ele sempre encontra tempo para andar de bicicleta de montanha, jogar hóquei e beber vinho tinto, já que ser saudável é mais importante do que ocupado.

»Mais informações sobre o livro podem ser encontradas no site do editor
» Conteúdo
» Trecho

Cupom de desconto de 20% para vendedores ambulantes - Managing Humans

Após o pagamento da versão em papel do livro, uma versão eletrônica do livro é enviada por e-mail.

PS: 7% do custo do livro será destinado à tradução de novos livros de informática, a lista de livros entregues à gráfica aqui .