Uma cruz (+) significava que o mensageiro poderia ir para o destino em etapas, duas cruzes (++) significavam um lince, três cruzes (+++) - um galope imediato. Portanto, o galope no exército foi chamado oficialmente de fascínio das três cruzes , e mais tarde essa expressão entrou no idioma russo, significando a execução mais rápida das ordens das autoridades. [Wikipedia]
Tar pit (inglês, literalmente piche de piche ) - 1) um problema insolúvel, 2) um lago de betume (um local onde o betume subterrâneo vem à superfície, criando uma seção de asfalto natural). [Dicionário inglês-russo] Os animais capturados no betume não podem sair, por isso esses lagos são um ótimo local para escavar esqueletos pré-históricos [Wikipedia].
“A imaginação representa dinossauros, mamutes e tigres com dentes de sabre tentando se libertar da resina. Não importa quão forte ou ágil o animal, no final, ele estará destinado à morte. Na última década, esse poço de alcatrão vem programando grandes sistemas ... ” [1, p.16] Com essa imagem impressionante, começa o livro clássico de Frederick Brooks, que viu pela primeira vez a luz no distante 1975. Outro livro clássico, publicado no mesmo antigo ano de 1987, não começa melhor: "E naquela época o projeto está morrendo em algum lugar" [2, p.23]. Os anos passam, a humanidade entra em um novo milênio, mas em 2014 outro best-seller começa com a mesma história eterna: “Em 3 de março de 2010, o Federal Bureau of Investigation decidiu suspender seu plano promissor e de larga escala para modernizar o gerenciamento de informações ... O bureau tentou atualizar seu sistema de computadores. por mais de dez anos, e parece que uma catástrofe os atingiu ” [3, p.14].
44 anos depois de Brooks, podemos, com a consciência limpa, repetir: agora, quando você lê essas linhas, o próximo projeto, como seus antecessores, está afundando no mesmo poço de alcatrão . As chances de sucesso no gerenciamento de projetos são menores do que quando se joga uma moeda e não parece crescer muito:
De acordo com os estudos CHAOS do Standish-Group [4]
Por que o progresso na ciência do gerenciamento (incorporado em 6 edições do PMBoK e dezenas de outros livros espessos) por 40 anos (!) Nunca levou a uma melhoria na qualidade do gerenciamento propriamente dito (a menos que, é claro, pela qualidade do gerenciamento seja entendida a probabilidade de se chegar a um determinado ponto)? Para lidar com essa questão, começamos com o principal problema de qualquer projeto, identificado ao longo do famoso livro Brooks.
O primeiro problema: a complexidade do produto que está sendo criado
Se você perguntar ao primeiro especialista em TI que se deparou - "Qual é a principal coisa no mês do homem mítico?" - a resposta provavelmente será: "Que todos os meses-homem são diferentes, os novos trabalhadores não são iguais aos antigos". Até Brooks chama a “lei” de provisão formulada no início do livro (“Se o projeto não cumprir os prazos, a adição de mais mão-de-obra atrasará ainda mais”). Mas isso é apenas uma observação empírica, conhecida por todos que pelo menos uma vez "trocou de cavalo na travessia"; a questão é como planejar um projeto quando todos os meses-homem são diferentes?
O “mítico homem-mês” tornou-se um best-seller, o que dá uma resposta a essa pergunta. Veja como Brooks formula sua compreensão de um problema básico de design:
"... as dificuldades clássicas do desenvolvimento de software decorrem dessa complexidade da entidade e de seu crescimento não linear com tamanho crescente. A complexidade causa dificuldades no processo de comunicação entre os membros da equipe de desenvolvimento, o que leva a erros no produto, excedendo o custo do desenvolvimento, atrasando a execução dos horários de trabalho. Complexidade é a razão. as dificuldades de enumeração e, mais ainda, a compreensão de todos os estados possíveis do programa e, portanto, sua falta de confiabilidade ... A complexidade da estrutura causa a dificuldade durante o desenvolvimento de programas e a adição de novas funções para que não haja efeitos colaterais ... " [1, p. 167]
A diferença fundamental entre o projeto e qualquer outra produção é que o projeto criado é produzido pela primeira vez [sabemos que muitas tarefas como “estragar o balcão de visitas ao site” também são chamadas de “projetos”, mas estamos falando de projetos reais]. Como qualquer coisa real, esse novo produto (não importa se é software ou "hardware") consiste em um grande número de componentes capazes das interações mais inesperadas (negativas - talidomida e positivas - viagra). É extremamente difícil prever como tudo isso funcionará em conjunto, e isso literalmente requer “mentes melhores” e não intermináveis “meses-homem”:
“Projetos de destaque são criados por designers de destaque. Criar programas é um processo criativo. Uma metodologia forte pode capacitar e liberar a mente criativa, mas não pode inflamar ou inspirar alguém que está ocupado com um trabalho tedioso ... Portanto ... acredito que o único e mais importante esforço que podemos fazer é desenvolver maneiras de educar designers de destaque ” [1 p. 185-186]
Da posição básica de Brooks (projetar é criatividade , e o processo criativo não pode ser realizado pela multidão), todo o conteúdo real do “Mês do Homem Mítico” segue diretamente: os requisitos da “ditadura dos arquitetos”, o efeito do segundo projeto e a recomendação “planeje jogar fora a primeira versão” . Mas também segue a tese mais esquecida de Brooks - que no gerenciamento de projetos "não há bala de prata ! " A complexidade dos projetos é objetiva, não pode ser superada com a ajuda de novas linguagens de programação (mesmo as gráficas), ou conectando inteligência artificial. É necessário lidar com a complexidade sempre que for necessário e, se o talento do designer não for suficiente para isso, o projeto não será bem-sucedido.
O principal inimigo do projeto Brooks é a complexidade do produto que está sendo criado . Com cada linha do novo código, com cada página da documentação tecnológica, essa complexidade aumenta e cresce de maneira não linear. E, ao mesmo tempo, o gerente tem à sua disposição menos recursos - o tempo restante até o final do projeto e o dinheiro restante até o final do orçamento:
No ponto de interseção, ou logo antes, fica claro que o projeto realmente requer muito mais dinheiro e tempo do que o originalmente pretendido:
O próximo projeto, chamado "Sentinel", o FBI começou imediatamente, em 2005. O preço da emissão é de US $ 451 milhões e o sistema Sentinel estará totalmente operacional em 2009 ... Em março de 2010, a Lockheed Martin, contratada, estava atrasada para o ano, completando apenas metade do projeto e gastando 405 milhões. Para concluir, de acordo com especialistas independentes, levaria outros seis a oito anos e mais US $ 350 milhões. [3, p.17-18].
Mas deixa eu! Se, desde 1975, sabemos que a complexidade dos projetos está aumentando, por exemplo, quadraticamente - o que impede o orçamento e a equipe de aumentar quadraticamente da mesma maneira? Por que todas as novas gerações de gerentes continuam liderando projetos com um sucesso previsto de 30%, quando você pode simplesmente adicionar dinheiro ?
Agora, é hora de avançar para o próximo livro.
O segundo problema: a complexidade da colaboração
Como já sabemos, o best-seller mundialmente famoso Peopleware (“pessoal” traduzido para o russo como “Fator Humano”), que apareceu doze anos após o Mês do Homem Mítico, começa com uma declaração da alta taxa de mortalidade dos projetos. “Cerca de quinze por cento dos projetos terminaram em nada ... No caso de grandes projetos, o quadro é ainda pior, o colapso compreendeu 25 por cento dos projetos cuja duração variou de vinte e cinco pessoas-ano” [2, p.24]. Isso foi escrito em 1987 (a URSS ainda estava viva). !), com referência ao estudo de 1981 (Brezhnev ainda estava vivo); e o que temos hoje?
De acordo com o relatório CHAOS 2015 [5]
Hoje, o desenvolvedor médio custa US $ 100 mil por ano, acrescentando uma sobrecarga; obtemos que 25 pessoas-ano é de cerca de 3-6 milhões de dólares. Como você pode ver, a situação não mudou desde esses longos anos: 26% dos projetos de médio porte e 43% dos grandes projetos esperam uma falha, e não há nada que possamos fazer sobre isso. Mas por que isso está acontecendo? Demarco e Lister perguntaram aos desenvolvedores sobre os motivos das falhas, e aqui está o que eles obtiveram em resposta:
“Na grande maioria dos casos, não havia uma única razão para a falha no campo da tecnologia. Na maioria das vezes, os participantes de nossas pesquisas chamam "política" como a causa do acidente
Não é de todo a complexidade do produto que está sendo desenvolvido, e não a insuficiência de recursos, como seria de esperar quando se olha para o Brooks Cross! “Política”, o relacionamento entre as pessoas dentro e fora da equipe (o que Demarco e Lister preferiam chamar de “sociologia”) - é isso que, segundo os desenvolvedores, impediu o sucesso acima de tudo.
Pense neste fato : as mesmas pessoas (desenvolvedores, chefes e clientes) que, à primeira vista, estavam mais interessadas no sucesso, unidas pelo bem do projeto, organizaram uma "política", o que levou o projeto ao colapso! “Nós encontramos o inimigo, e ele somos nós” [6]; o projeto revelou o segundo pior inimigo - seu próprio time.
É intuitivamente claro que quanto mais pessoas estiverem envolvidas em um projeto, mais tempo elas terão para organizar o trabalho conjunto e menos - realmente desenvolverão um produto. A questão é quanto menos:
Fig. 2 do artigo Putnam, Myers [7]
Tendo coletado as características numéricas de 491 projetos de desenvolvimento de software de 35 a 95 mil linhas de código, Putnam e Myers apresentaram resultados quase impossíveis de acreditar. Projetos de tamanho comparável foram concluídos por equipes de números diferentes quase ao mesmo tempo, e equipes de números maiores precisavam não menos, mas mais tempo. A lei de Brooks ("adicionar desenvolvedores - desacelerar o projeto") acabou funcionando não apenas com a ameaça de interrupção do projeto, mas desde o início , começando com a adição do nono programador. Se você apresentar os mesmos resultados em termos dos notáveis meses-homem, receberá uma programação ainda mais expressiva. Quanto dinheiro (em salários mensais) é necessário para resolver o mesmo problema por equipes de números diferentes:
Fig. 3 do artigo Putnam, Myers [7]
Os dados obtidos se encaixam aproximadamente em um padrão completamente fantástico: a produtividade de um desenvolvedor em uma equipe é inversamente proporcional ao seu tamanho. Nesse caso, o período de desenvolvimento será o mesmo para qualquer equipe, que é aproximadamente o que os dados de Putnem e Myers demonstram. Acredite ou não, o assunto pessoal de todos; mas mesmo que você não acredite, você deve admitir que o tempo gasto em política cresce de maneira não linear com o tamanho da equipe - e, portanto, muito menos tempo resta para trabalhar em equipes grandes.
O livro de Demarco e Lister contém muitos exemplos de "sociologia", que substituem o trabalho no projeto pelo trabalho de manter a "ordem" na equipe. Escritórios em espaço aberto, onde os chefes podem ver quem está se afastando do trabalho (e os funcionários estão constantemente se distraindo); planejamento detalhado e requisitos constantes para cumprir os prazos (apresse-se e leve a um aumento no número de erros); regulamentação mesquinha (que faz com que você gaste muito tempo relatando o trabalho realizado e mudando a motivação dos funcionários de código para "pedaço de papel"). Todas essas medidas parecem necessárias para a organização do trabalho conjunto - mas, quando totalmente aplicadas, não deixam mais tempo para o trabalho em si.
Agora podemos entender por que o método "basta adicionar dinheiro" não funciona. Um aumento no tamanho do projeto com a organização moderna do trabalho (espaço aberto, prazos apertados, relatórios detalhados) não leva a um aumento significativo da produtividade. Pelo contrário, quanto maior a equipe do projeto, maior o risco de se afundar completamente na documentação, concordando quem está fazendo o quê e de que lado está o problema. O cruzamento da Demarco põe fim às tentativas de aumentar a eficácia dos projetos de maneira “extensa”.
Mas e se mudarmos os próprios princípios de organização de atividades conjuntas? Demarco e Lister recomendaram isso em 1987: Para gerenciar efetivamente as pessoas no campo do trabalho intelectual, é necessário tomar medidas opostas às listadas acima. [isto é regulamentação, padronização, trabalho sob pena de demissão e proibição de qualquer iniciativa]. Supunha-se que no Peopleware estivesse escrito claramente como deveriam ser as medidas "opostas" [na verdade, não]. Vamos olhar novamente para o gráfico de sucesso do projeto. E onde está o resultado do livro ainda incluído na leitura obrigatória de qualquer gerente? Algo para não ver.
Então porque? Existe realmente outra cruz no caminho para o gerenciamento eficaz de projetos?
Terceiro problema: a dificuldade de planejar um novo
À primeira vista, o terceiro obstáculo ao gerenciamento perfeito de projetos é a natureza incomum da maneira correta de orientar o processo criativo. Um desses métodos, agora conhecido como Scrum, foi descrito em um artigo [8] em 1986, mesmo antes do lançamento do Peopleware. Dentro de alguns anos, em 1993, Jeff Sutherland usou pela primeira vez elementos individuais do Scrum em seu projeto e ficou satisfeito com o resultado:
Entregamos o produto de software ao Easel no prazo, em seis meses, sem exceder o orçamento e com um número mínimo de erros - ninguém poderia fazer isso antes.
No entanto, uma descrição detalhada das principais idéias do Scrum foi publicada apenas vinte anos depois , apenas no outro dia, em 2014 [3]. Todo esse tempo, Scrum existiu como uma metodologia semi-sectária, transmitida literalmente de professor para aluno, e ganhou popularidade exclusivamente através do boca a boca. O fato é que o conceito principal do Scrum, que segue diretamente de sua filosofia, não se encaixava em nenhuma lógica de controle razoável:
É o que repito constantemente para a liderança: “Só posso nomear o prazo quando vejo a eficácia da equipe” [3, p. 28).
Se queremos dizer com "gerenciamento de projetos" garantindo a criação de um produto com propriedades especificadas dentro do prazo, dentro do orçamento, o Scrum não é "gerenciamento"! O centro da filosofia Scrum é uma recusa categórica de chegar a um "prazo fixo" do teto (isoladamente da equipe real e de seu desempenho), e a primeira consequência dessa recusa é uma abordagem totalmente não convencional ao planejamento do projeto:
Fui ao chefe da empresa e afirmei que estamos abandonando os gráficos de Gantt. Indignado com o que ouviu, ele exigiu uma explicação.
- Quantos gráficos de Gantt você encontrou para sua carreira profissional? Eu perguntei.
"Com centenas", disse ele.
- Quantos deles eram verdadeiros?
"Nenhum", ele respondeu, pensando por um momento.
Expliquei que, em vez de gráficos e tabelas desnecessários, até o final do mês, daremos a ele parte de um sistema totalmente funcional, que ele próprio poderá testar e verificar por si mesmo se o desenvolvimento está na direção certa " [3, p.50]
Em uma história contada por Sutherland, o chefe concordou em tentar. Mas sabemos qual é o "erro dos sobreviventes" e estamos bem conscientes de que há dez em um desses chefes que enviarão um "gerente de projetos". Que tipo de absurdo, para pagar honestamente, que "trabalharemos e mostraremos algo em um mês"? Que idiota faz isso?
Do livro de Sutherland, sabemos com bastante precisão qual deles: aquele que já tentou tornar o projeto uma maneira clássica e sofreu um fracasso catastrófico. Somente um líder encurralado, que não tem nada a perder, ousa abandonar o princípio básico do gerenciamento de "recursos - apenas sob o plano de uso". É claro que, após vinte anos de uso do Scrum, a atitude em relação a ele mudou um pouco, mas ainda hoje a maioria das conversas "Vou citar o termo e o valor quando reunir a equipe e começar a trabalhar" corre o risco disso.
A ideologia Scrum é tão contrária às idéias geralmente aceitas sobre o projeto ("O cliente concorda em pagar e o Empreiteiro faz o seguinte trabalho ...") que é hora de fazer a pergunta: por que Sutherland foi forçado a dar um passo tão revolucionário? Realmente era impossível deixar as paradas de Gantt “prontamente” e focar na organização do trabalho da equipe (por exemplo, em reuniões diárias diárias, nas quais muitos veem a coisa mais importante no Scrum)?
A julgar pela veemência com que Sutherland ataca em seu livro "Gantt Charts", não se pode:
Ao gerenciar projetos, duas coisas são tradicionalmente necessárias - responsabilidade e previsibilidade. Essa abordagem inevitavelmente levará ao surgimento de uma enorme quantidade de documentação, tabelas e diagramas ... São gastos meses de trabalho fornecendo tudo nos mínimos detalhes, evitando um único mau funcionamento, não excedendo os recursos financeiros e avançando de acordo com o cronograma. [3, p.23] O único problema é que, assim que esse plano perfeitamente aperfeiçoado é confrontado com a realidade, ele imediatamente se transforma em pó. Mas, em vez de jogar o próprio plano e sua abordagem no lixo, os gerentes fingem que o plano funciona ... De fato, eles pagam as pessoas por mentir para eles . [3, p.20]
Eles pagam por mentir para eles - é isso! ( « ») , . , , (« !»). :
, , , , [3, .23]
: ( ) ( ), . «», , :
( , ), , « », . : «, , , ».
— ! [9]
, « » . , , . « - » , . (« ») . , - .
? ? — . () — . — .
. , «» . , ( «»). , . , — , . , .
- [1] . « - », , -, 2007
- [2] ., . « : », , -, 2005
- [3] , . "Scrum. », ., , , 2016
- [4] de.wikipedia.org/wiki/Chaos-Studie
- [5] CHAOS REPORT 2015
- [6] We have met the enemy
- [7] Putnam, Myers «Familiar Metric Management — Small is Beautiful-Once Again», 1998
- [8] , « : » (1986),
- [9] .. « !», ., 1966