Manifesto NoProjects: desprojetização

Introdução – Os projetos na Indústria de Software - Introdução

Olá. Sou o Roberto Pina, e é com muito prazer que estou iniciando nesse curso falando sobre um tema de vanguarda, a desprojetização do desenvolvimento de software, trazendo o manifesto “No Projects”.

Nesta primeira aula nós vamos falar a respeito dos projetos na indústria de software, como ocorreu o fenômeno de projetização, o que ele acarretou, e quais são os desafios. E esse primeiro vídeo, ele tem, por propósito, fazer uma apresentação geral do curso.

O público-alvo para esse curso são gestores de projetos de TI. Gerentes de projeto, coordenadores, enfim. Membros de áreas de governança, como escritórios de projeto, consultores em metodologias de TI. O cerne desse curso é a respeito de métodos, metodologias, abordagens metodológicas. Então, para quem está envolvido com isso, ou curte esse assunto, vai ser muito interessante. Profissionais aspirantes às posições acima, que ainda não toca projetos, não mexe com governança, não mexe com metodologia, mas tem interesse nesses temas. E público em geral que deseja evoluir seus conhecimentos no assunto “Métodos de Desenvolvimento de Software”.

O que trataremos nesse curso? Primeiramente eu falarei dos projetos da indústria de software, como esta identidade “projeto” entrou na indústria de software e o que isto acarretou. As ideias fundamentais do manifesto “No Projects”, o que é isso, o que é esse movimento, filosofia ou abordagem. O que propõe, a que se contrapõe. Falarei também sobre portfólios adaptativos e gerenciamento de entregas, que é um assunto tratado pelo “No Projects”. Falarei das equipes de entrega de valor, que é como o “No Projects” aborda esta questão de funcionamento das equipes. E, finalmente, sobre orçamentação e contratos no contexto do manifesto ou da abordagem “No Projects”.

Como benefícios para esse curso, nós temos a discussão e, espero, a aquisição por vocês de conhecimentos de vanguarda na temática de metodologias de TI. Trata-se de um tema novo, interessante, desafiador, que nos convida para uma série de reflexões a respeito do trabalho de desenvolvimento de software, os projetos, o relacionamento com os usuários e tudo o mais.

Também, tem como objetivo, prepararmos para novos paradigmas na indústria do software. Pode ser que de fato esteja vindo uma onda baseada em desprojetização, e devemos estar preparados para ela, ou, ao menos, ter uma base de discussão a respeito dos prós e contras desse movimento.

Finalmente, o curso traz uma contribuição para a evolução e diferenciação profissional dos participantes na medida em que aperfeiçoa conhecimentos a respeito de gestão, a respeito de métodos, a respeito do trabalho de desenvolvimento de software.

Como pré-requisitos para esse curso, seria interessante que os participantes tenham funções de ciclo de vida de projetos de TI, Waterfall e Ágil. Ou seja, algum conhecimento acerca de gerenciamento ou de método de desenvolvimento de software, porque usaremos alguns termos e faremos menções a tais métodos.

É padrão pedagógico da Alura a realização de um projeto de conclusão do curso. Esse trabalho prático visa fixar o aprendizado, você será então convidado a realizar esse exercício, e passo a passo o que você deve fazer será passado.

No próximo vídeo, maiores detalhes a respeito desse projeto de conclusão do curso. Vamos lá. Tenho certeza que esse curso é bem diferente, bem interessante, e vai provocar aí um nível de discussão, e isso é muito importante para a comunidade de software.

Vejo vocês no próximo vídeo.

Introdução – Os projetos na Indústria de Software - O Projeto de Conclusão do Curso

Olá. Neste segundo vídeo falarei a respeito do nosso projeto de conclusão do curso. Esse projeto é um exercício que visa a consolidação dos conceitos que nos veremos.

No que consistirá esse exercício? Consistirá no seguinte: na realização de uma análise crítica de um projeto que você já tenha vivenciado, seja como gestor, seja analista, como desenvolvedor, ou mesmo como usuário.

Como foi esse projeto? Que ciclo de vida foi adotado? O que aconteceu com a equipe? Quais foram os problemas enfrentados? E em especial: o que aconteceu com o produto desse projeto? Como ele foi entregue? Como ele iniciou o seu ciclo de vida.

Vamos fazer um inventário disso e verificar se determinados problemas, ou determinados desafios que foram enfrentados, poderiam acontecer de forma diferentes, numa abordagem de desprojetização, e como isso?

Então, o trabalho que foi desenvolvido nesse projeto que você vai escolher, faremos uma revisão e uma reflexão de como seria este desenvolvimento num paradigma “no projects”, e o que isso traria de diferença em especial para o destino da equipe e o destino do produto do projeto.

Ao longo do curso, você receberá, passo a passo, as orientações de como proceder esse projeto de conclusão.

Vejo vocês então no próximo vídeo, onde iniciaremos a falar a respeito da entrada da identidade de projetos no mundo do desenvolvimento de software. Como foi isso, o que acarretou, como tudo começou. Vejo vocês lá.

Introdução – Os projetos na Indústria de Software - O Uso de Projetos para Desenvolver Software

Olá, pessoal. Neste terceiro vídeo da aula 1, falarei a respeito de como os projetos entraram no mundo do desenvolvimento de software.

Nos primórdios do desenvolvimento de software, lá na época dos primeiros mainframes, o hardware era limitante. Então os programadores trabalhavam muito para contornar as limitações dos computadores daquela época. Assim sendo, esse desenvolvimento era artesanal, os programadores atuavam meio que como os cientistas, sem seguir nenhum método predefinido. Trabalhava-se em cima do software, e um belo dia o sistema ficava pronto. Era mais ou menos assim.

E a figura dos usuários era muito insípida, eles não participavam ainda de forma intensa do chamado “jogo do software”. Com o desenvolvimento do hardware e do software, e surgimento das interfaces online, os usuários começaram a participar da vida do desenvolvimento do software.

Isso, sem dúvida, trouxe uma grande evolução para o desenvolvimento e para o uso dos sistemas, para a adição de valor ao negócio através do software. Porém, causou também o início da chamada “crise do software”.

No que consiste a “crise do software”? Consiste numa crescente dificuldade em lidar com os requisitos, os usuários passaram a ter voz ativa e começaram a dizer o que eles queriam, e não apenas receber os sistemas prontos e ouvir coisas do tipo: “Não, fizemos assim porque o computador não permite isso, não permite aquilo”, esse tipo de conversa já não tinha mais cabimento. Porém, os requisitos de software, que são necessidades nebulosas, e a passagem disso para os desenvolvedores, havia aí um grande desafio, perdura até hoje: como fazer essa transição da necessidade para o requisito de software?

Também começaram a surgir muitos problemas de qualidade. Começou-se a produzir software em escala, muitas vezes numa sistemática de tentativa e erro, porque o computador é a única máquina que permite que se trabalhe com indisciplina. Quantas vezes algo funciona, mas a gente não sabe exatamente por que no mundo do software, e isso acarreta uma falta de domínio do código e consecutivamente imprevisibilidade com relação à qualidade. Muitos retrabalhos, bugs etc.

Além disso, faz parte também da crise do software as estimativas ruins. Para esse tipo de trabalho, tão abstrato, é muito difícil dar estimativas de quando vai ficar pronto, esse tipo de coisa. Há também um cenário de muito baixa produtividade, começou a demorar muito tempo para entregar software. Estimativas ruins e sempre estouradas, esse era o ponto.

A manutenção era difícil, por quê? O software, ele já nascia determinados problemas na sua estrutura que tornavam difícil a manutenção, algo que às vezes o próprio autor do programa tinha dificuldade de entender o que foi feito, uma arquitetura confusa, uma lógica enrolada, enfim. Falta de padrões arquitetônicos que forneçam uma estrutura clara para aquele produto dificultando, portanto a sua manutenção, as suas alterações.

E diante disso, diante de toda essa crise, o que poderíamos salvar? Acreditou-se que a solução era a seguinte: “Vamos projetizar. O problema é de gestão, é de planejamento, é de controle. Isso vai resolver essa questão toda relativamente ao software”.

Então, com isso, surgiram métodos de gestão de projetos, muito baseados nas áreas de conhecimento do Pmbok, preconizado pelo PMI. Assim sendo, a ideia é que se eu usasse projetos para desenvolver software, eu ia trazer para o desenvolvimento do software a mesma precisão e a mesma previsibilidade que existem em outras disciplinas de engenharia, como civil e mecânica, que fazem uso de projetos.

Então a brincadeira seria assim: eu faria um bom planejamento upfront, um bom planejamento a priori definindo escopo, definido uma série de parâmetros para o projeto, planejamento, e seguiria um ciclo de vida com especificações funcionais e técnicas, ou seja, a geração de uma documentação detalhada a respeito do produto do software que vai ser desenvolvido, a construção, os testes, e finalmente a implantação. Tudo isso ladeado com monitoração e controle por parte de gestores de projeto.

Assim sendo, com a projetização, esperava-se que tudo acontecesse de maneira repetível e previsível, colocando fim, desta forma, à crise do software. Porém, o que acabou acontecendo, e em especial pela adoção desse tipo de método, semelhante ao da construção civil, que é o método waterfall, que nós acabamos de representar. Gerava-se, e gera-se ainda nos projetos, principalmente aqueles mais tradicionais, uma documentação muito extensa, de difícil interpretação, tentando cercar a questão do escopo. Pressões muito grandes na equipe, especialmente em função de prazos, custos e outras restrições do projeto, e no final das contas, o usuário recebendo produtos que ele não reconhece como atendedores de suas necessidades e expectativas.

O usuário diz: “Mas você não entendeu, não foi exatamente isso que eu pedi, houve um mal-entendido”. Então isso daí é um cenário bastante comum nos projetos, causando um nível muito grande de conflitos, retrabalhos, desgastes e estresse e tudo o mais que, para quem atua com o desenvolvimento de software, conhece na prática toda essa miséria, todo esse nível de desafio que acontece.

Então, a emulação da engenharia não deu certo. Utilizar projetos para fazer com que software fosse desenvolvido e entregue como se estivesse entregando uma ponte, ou um galpão, ou algum outro artefato físico, acabou não funcionando. Porque a produção se afundou em ilusões manufatureiras, se afundou na ilusão de que eu poderia produzir software numa linha de produção, como se estivesse produzindo carros, num processo repetível e previsível, ainda mais através de um ciclo de vida waterfall.

Então, diante dessa problemática, a previsibilidade não estava funcionando, e aí se pensou: “Não, precisamos apertar um pouco mais a gestão. O problema não é o planejamento e a realização de projetos em si, mas sim frouxidão na gestão. Então vamos tornar a gestão mais rigorosa”. Com isso tentou-se aumentar o nível de comando e controle dos projetos, com escritório de projetos, PMOs, aumento do número de reuniões, mais documentação. Só que tudo isso acabou trazendo mais custo e não resolveu a questão da crise do software.

Então a problemática não estava em melhorar os projetos, melhorar o projeto waterfall ou tornar ainda mais rígido. O problema estava na questão do uso do projeto em si como instrumento para desenvolvimento de software.

Veremos isso em detalhe mais para frente, mas no próximo vídeo vamos continuar falando dos projetos na indústria de software, como outras abordagens foram evoluindo na tentativa de resolver esses problemas. Vejo vocês no próximo vídeo.

Sobre o curso Manifesto NoProjects: desprojetização

O curso Manifesto NoProjects: desprojetização possui 134 minutos de vídeos, em um total de 51 atividades. Gostou? Conheça nossos outros cursos de Agilidade em Inovação & Gestão, ou leia nossos artigos de Inovação & Gestão.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Introdução - Os projetos na Indústria de Software
• Ideias Fundamentais do NoProjects
• Portfólios Adaptativos e Gerenciamento de Entregas
• Equipes de Entrega de Valor
• Orçamentação e Contratos no Contexto NoProjects
• Projeto de Conclusão