Observe que não há ponto de interrogação no título. Não quero discutir se os gerentes de projeto são necessários no desenvolvimento de software moderno ou não. A prática mostra que não. Só estou tentando descobrir por que isso aconteceu.
Tendo trabalhado por mais de 20 anos no setor de TI, comecei a construir todos os novos desenvolvimentos a partir do escritório do projeto. Além disso, várias vezes tive que explicar à gerência por que contratar piems. Dada a presença de chefes de departamento, não é tão fácil explicar às pessoas que não estão diretamente envolvidas no desenvolvimento de software o que exatamente os gerentes de projeto farão. Eu tive que superar a resistência perceptível.
Mas, para mim, era um axioma que o escritório e os gerentes de projeto são a base do sucesso. E me diga a alguém há cerca de cinco anos que os gerentes de projeto não são necessários, eu argumentaria com ele até o fim.
Nota do editor: este texto é o resultado de um relatório de Dmitry Kruglov da chegada ao comício de Piemnaya.
Ou você ainda precisa
Vamos começar tentando proteger esta profissão. Se apenas porque os resultados nos últimos locais de trabalho foram alcançados, inclusive graças aos escritórios de projetos construídos com sucesso.
O gerenciamento de projetos não é uma prerrogativa de TI. Esta é uma ciência com mais de 50 anos. Uma ciência que tem seu próprio livro sagrado . Obviamente, o PMBoK não é único, existe o PRINCE e, provavelmente, mais alguns livros, mais ou menos reivindicando louros. Mas o PMB®K é a base de padrões internacionais e isso indica seu alto nível de reconhecimento. Então, vamos construir sobre isso.
Vamos jogar: se você trabalha como gerente de projetos, tente, sem olhar para o futuro, relembrar suas principais áreas de atividade do ponto de vista de um padrão internacional e de um instituto com mais de 50 anos?
Por exemplo, gerencie os requisitos do projeto. Ou gerencie as expectativas. Talvez você se lembre da administração do tempo. Certamente, os colegas que representam a empresa perguntam regularmente quando exatamente essa ou aquela tarefa estará pronta. Talvez você se lembre do gerenciamento de partes interessadas, o que é muito menos comum. O que mais? Gerenciamento de Comunicações. Este último é tão raro quanto as partes interessadas. Mas esta é uma tarefa importante e difícil em nosso tempo, quando todos os participantes do projeto preferem compartilhar informações importantes no Telegram, em vez dos e-mails exigidos pelo rascunho da Carta. Como você pode gerenciar as comunicações se simplesmente não é convidado para um bate-papo no qual eles discutem, por exemplo, a qualidade do seu trabalho?
Compare o que você lembrou com a lista do PMBoK:
Todos os itens são muito sãos. Parece que essa atividade realmente precisa ser realizada por todo gerente de projeto. Parte disso pode ser menos óbvia, como a integração de projetos. Mas se você usou o poder de várias equipes para criar um recurso realmente grande, que precisa reunir antes do lançamento, então você entende o que é esse ponto. A propósito, a tarefa de desenvolver uma funcionalidade em várias equipes em paralelo ainda não foi resolvida sistematicamente.
Gráfico de Gantt
Se houver uma atividade, deve haver seu resultado. Minha opinião pessoal é que o trabalho foi realizado com o artefato apropriado. Para um programador, este é um código funcional. Para um especialista em testes, scripts de teste desenvolvidos ou executados, erros introduzidos no sistema ou autotestes criados. Para o designer - layouts gráficos.
O que é um artefato do gerente de projeto? De todos os artefatos possíveis, incluindo mensagens no telegrama: "Adicione-me finalmente ao seu bate-papo, não posso gerenciar o projeto sem ele!", Observaria primeiro o gráfico de Gantt. Essa é uma ótima ferramenta que pode responder a muitas perguntas sobre o projeto e ajuda a visualizar a maioria das áreas de atividade do gerente de projetos. Afinal, um bom gráfico de Gantt contém tempo, recursos, custos e dependências. Lá você pode adicionar requisitos de comunicação como tarefas. Você pode até adicionar controle às partes interessadas e suas expectativas com marcos e uma descrição do resultado esperado. Acontece uma ferramenta universal para todas as ocasiões.
A maioria das tarefas nessas áreas é resolvida através do gerenciamento de uma entidade - o gráfico de Gantt.
Sua popularidade e versatilidade são confirmadas pelo número de ferramentas e serviços que permitem criar seus diagramas. Tente pesquisar por "Gantt online" e veja por quanto tempo a lista de links para todos os gostos e cores você obtém.
O que acontece: temos uma profissão, temos uma atividade e temos um bom artefato, como resultado. Então, qual é o problema?
É tudo sobre as nuances. Por exemplo, com Gantt, nem tudo é tão bom.
Primeiro, os diagramas de grandes projetos, mais cedo ou mais tarde, tornam-se ilegíveis. Tive experiência trabalhando com um projeto "mais de um ano" no Microsoft Project. Para imprimir seu plano, foi necessário colar seis folhas de A4. Em uma folha, o texto era muito pequeno.
Em segundo lugar, os diagramas de grandes projetos são muito trabalhosos para manter. Fazer alterações geralmente só pode ser feito pelo próprio autor; caso contrário, o plano se desfaz devido a um complexo sistema de dependências.
Em terceiro lugar, deve-se admitir que ninguém, exceto muitos dos gerentes de projeto, lê muitos diagramas. Acontece que esse artefato foi produzido pelo PM e ele sozinho precisa e entende.
No desenvolvimento de software moderno, Gantt, na maioria das vezes, foi abandonado. Paramos de usar esse artefato na criação de um produto, precisamos mesmo do autor?
Se você tentar pesquisar no google o tópico da utilidade dos gerentes de projeto em TI, fica claro que essa discussão está em andamento há muito tempo. Ela conseguiu se tornar outra holivar, como o confronto entre os amantes de iOS e Android, Windows ou OS X. Somente as citações nos resultados da pesquisa são ainda mais emocionantes: “Precisamos de PM?”, “Por que decidimos nos livrar dos PMs”, “É o trabalho de PM é inútil?
Não pretendo dizer que o saldo da disputa global seja a favor da rejeição do MP, mas pelo menos o número de apoiadores desse ponto de vista é significativo.
Metodologias ágeis
Começando a trabalhar em uma empresa em que tenho a tarefa de construir uma equipe de desenvolvimento do zero mais uma vez, percebi que durante os próximos seis meses a um ano não tenho tarefas para o PM. No começo, eu a adicionei à estrutura organizacional por hábito. E então ele atacou com sua própria mão. Riscou intuitivamente, mas se perguntou: "Por que isso aconteceu?".
Minha pesquisa sobre os motivos levou ao entendimento de que a TI possui várias qualidades únicas que permitiram a implementação de metodologias flexíveis. Há uma comparação clássica: construir uma casa e desenvolver software. Essas são disciplinas um tanto semelhantes, não sem razão, pois existe um papel do arquiteto. Lá, e existe um conjunto de requisitos funcionais e não funcionais, há infraestrutura, comunicações internas, montagem, entrega e integração.
Mas a construção é realizada no mundo real e possui um ciclo de produção muito longo e caro até o primeiro teste, antes de receber o primeiro feedback, antes de receber o resultado. O preço de um erro na construção é muito alto.
O produto de TI é digital. E o ciclo de produção pode ser muito curto. Por duas décadas, fomos capazes de criar ferramentas e tecnologias que levaram ao surgimento de metodologias de desenvolvimento flexíveis. Aqui estou pronto para argumentar que uma relação causal é exatamente isso: a capacidade de experimentar rapidamente e obter um resultado operacional levou ao surgimento de metodologias sobre como fazer isso. Obviamente, esse é um feedback positivo curto e as ferramentas continuaram a se desenvolver. E, novamente, a metodologia foi finalizada. E assim por diante, numa espiral, corremos para um tempo cada vez mais curto de lançamento no mercado.
Funções
As metodologias ágeis tornaram-se o padrão de fato e trouxeram novas funções ao processo de desenvolvimento de software. E essas novas funções começaram a tirar atividades e artefatos dos gerentes de projeto.
Proprietário do produto (PO)
Existem projetos que têm vários clientes, vários proprietários e vários tomadores de decisão. PM para eles é a pessoa que busca um compromisso. Ele os reúne, ajuda a priorizar, reconcilia. Ele diz a alguém: "Não", alguém está fazendo lobby. Mas a empresa entende que, em uma busca contínua por compromissos, os recursos são desperdiçados ineficientemente. O recurso mais valioso é gasto na maior parte do tempo.
Portanto, metodologias flexíveis fazem exatamente isso - dizem a uma pessoa da empresa algo no espírito: “Você é extremo em relação a dinheiro, tráfego e conversão. E, para ser sincero, não nos importamos com o que e com que prioridade você faz no produto. O principal é que até o final do ano a conversão aumentará de 1% para 1,1%, caso contrário, o projeto não será rentável. ” E o OP tem o direito de tomar decisões individualmente, determina a prioridade, cria os artefatos correspondentes (planos, roteiros, requisitos) e executa um trabalho do MP.
Techlide (TL)
Cerca de dez anos atrás, a TI começou a mudar a arquitetura estabelecida.
Antes dessas mudanças, as tecnologias e ferramentas eram criadas principalmente para a “arquitetura em camadas” - a camada de banco de dados, a camada de processos de negócios, a camada de agregação, a camada do cliente. Porém, assim que essa abordagem se tornou clássica, assim que as empresas adquiriram as camadas correspondentes de departamentos, surgiram metodologias flexíveis. E todos decidiram, por unanimidade, que os “puff ties” eram ruins e era necessário formar equipes multifuncionais.
Para não dizer que isso era uma ideia nova. Como são chamados os desenvolvedores universais? Pilha cheia Um dos desenvolvedores com mais de 30 anos de idade na entrevista disse: "Eu era desenvolvedor de pilha cheia no momento em que o termo pilha cheia não existia". Antigamente, estávamos todos com stacks completos, porque tínhamos que fazer tudo, incluindo a administração do banco de dados e a configuração do computador do diretor.
As equipes multifuncionais trouxeram um novo papel: techlides. Tehlid não apenas pressionou os chefes dos departamentos, mas também assumiu a parte técnica do trabalho do PM. Antes de tudo, tudo relacionado à avaliação da complexidade e do timing. No momento da transição para metodologias flexíveis, muitos chegaram a um acordo com o fato de que a equipe de desenvolvimento deve avaliar os termos de seu trabalho.
Analista de sistemas (SA)
Um analista de sistemas não é uma nova função, e muitas metodologias ágeis não. Não presumo dizer com certeza, mas é possível que esteja explicitamente disponível no SAFE. Mas o SAFE, em geral, é uma metodologia limítrofe. No entanto, esse papel é extremamente útil e interessante. Como um lubrificante em um mecanismo complexo, permite que ele trabalhe silenciosamente e sem problemas. Um analista de sistemas é em parte o proprietário do produto, em parte o arquiteto. Ele esclarece e detalha os requisitos de negócios para o nível de recursos específicos. Os melhores analistas de sistemas são capazes de avançar suas idéias e visão em ambas as direções, usando uma combinação de conhecimento técnico e habilidades pessoais. Onde os analistas de sistema trabalham, o gerente de projeto é privado das atividades de gerenciamento de requisitos.
Scrum Master (SM)
O Scrum Master reduziu bastante o papel de gerente de projetos. É uma pena que agora as próprias PM tenham se tornado candidatos à extinção.
Sério, mais cedo ou mais tarde o Scrum Master ensinará nas escolas. Haverá lições sobre o Agile, onde o Scrum Master dirá aos alunos de 12 anos de idade como as metodologias ágeis funcionam e quais práticas existem. A experiência ágil agora se tornou uma experiência de desenvolvimento onipresente. Em uma entrevista, 19 em cada 20 pessoas trabalham em iterações de duas semanas, e falar sobre processos se transforma em uma lista de seus parâmetros:
- Qual é a avaliação?
- Pontos da história.
- O que é velocidade?
68.
- Como você planeja projetos?
- Nas classificações de camiseta, S, M, L.
Esta é uma conversa muito rápida. Com os teclados atuais, todos os parâmetros do processo podem ser discutidos em uma hora. Depois disso, eles vão trabalhar com a equipe e não precisam do Scrum Master para isso. A indústria quase digeriu esse papel e está seguindo em frente.
Obviamente, esse não é o caso em todos os lugares. Certamente existem muitas empresas que precisam atingir os padrões de mercado e esse não é um processo rápido. Na Rússia, depois de 10 anos, será possível encontrar um emprego como Scrum Master em algum tipo de “Lenoblkhozpromlespoval” quando a organização decidir transferir seus três programadores para o Agile.
Durante sua popularidade, o Scrum Master conseguiu tirar completamente todas as perguntas da equipe do projeto da PM. Eles levaram não para si mesmos, mas para os membros da equipe, facilitando o envolvimento deles no trabalho de design. A propósito, isso aumentou significativamente o nível de maturidade da TI aos olhos dos negócios.
Ou ainda não é necessário
O que resta? Tomei a liberdade de destacar as tarefas que, ao trabalhar em metodologias flexíveis, são resolvidas por outras funções.
O que resta dos gerentes de projeto depois disso? Comunicações, integração e compras remanescentes. Parece que não há muito para manter uma pessoa dedicada nesse papel? É hora de dizer que os PMs não são necessários. Mas não.
Ainda precisa
Existem categorias de projetos de TI em que a falha sem um gerente dedicado é praticamente garantida.
Projetos do mundo real
Quem trabalha com desenvolvimento móvel sabe que, com a velocidade de fazer alterações e o custo do erro, as coisas não são tão fáceis. Se você perdeu um erro no desenvolvimento móvel e o notou imediatamente, será difícil fazer uma atualização para todo o público. Alguns usuários não atualizarão seus aplicativos e o erro permanecerá. A partir desse problema, por exemplo, as abordagens com controle remoto da funcionalidade dos aplicativos móveis cresceram.
Mas essa é a centésima parte da dor dos gerentes de gerenciamento que gerenciam o desenvolvimento de software, por exemplo, para gerenciar o transportador de classificação em um armazém com uma escala de 5 milhões de unidades de mercadorias. Nesses projetos, dezenas de dependências de fornecedores de equipamentos, as iterações são medidas em meses e o preço do erro aumenta em uma ordem de magnitude.
Projetos relacionados a equipamentos nos trazem de volta dos mundos digitais para a nossa realidade, na qual o controle clássico do PMBoK ainda é relevante.
Projetos de guarda-chuva
Em projetos guarda-chuva, metodologias flexíveis foram interrompidas. Tais projetos são grandes e complexos. Complexidade significa dependências explícitas e implícitas e, em uma certa escala, o desenvolvimento sem um gerente de projeto dedicado se torna extremamente ineficiente. Nesses projetos, as principais tarefas do PM são integração de projetos, dependência e gerenciamento de tempo.
Projetos com alto custo de erro
Sempre haverá indústrias nas quais os erros devem ser eliminados ao máximo - medicina, aviação, indústria espacial e esfera militar. Nessas áreas, quando ocorre um erro, as pessoas morrem ou perdem muito dinheiro. É fácil encontrar exemplos na Internet. Comece com uma história sobre o míssil europeu Arian-5.
Nessas áreas, o MP permanecerá em demanda, mas demandas muito altas serão impostas a eles em termos de competências e experiência. E quanto menor a proporção desses projetos, mais rigorosa será a seleção de candidatos.
Projetos sem parte de papéis
A vida é uma coisa dura, e nem sempre é possível ter uma pessoa dedicada para cada um dos papéis. Até que o mundo esteja perfeito, haverá PMs que fazem o trabalho do Product Owner. Ou PMs que de fato funcionam como teclados. Tais combinações são frequentemente características de startups.
Se prolongarmos com o tempo as tendências que estão ocorrendo no setor agora, teremos um futuro em que o papel do PM em sua forma pura permanecerá relevante para um pequeno número de projetos de desenvolvimento de software cujo trabalho ainda não sabemos como automatizar ou distribuir entre outros membros da equipe.
Texto preparado por:
Autor - Dmitry Kruglov
Editores - Eugene Shklyar, Denis Vonsarovsky
A opinião do autor sobre algumas questões pode não coincidir com a opinião do conselho editorial do blog e da empresa Yandex.Money.