projeto

5 erros comuns dos que afirmam: “ah…isso não é importante, é apenas a documentação do sistema”

Primeiramente, é importante entender que modelagem não é documentação. Entendendo-se isso, abaixo são descritos cinco erros comuns daqueles que ainda concluem que a documentação, ou melhor, a modelagem não é importante:

1 – A ausência de rastreabilidade dos requisitos e aprovação de sua linha de base dificulta a identificação das mudanças de escopo. Clientes podem solicitar novas funcionalidades ou mudanças naquelas já construídas e sem uma linha de base com os requisitos, há retrabalho na construção de novas versões do aplicativo em que o fornecedor, invariavelmente, arca com todo o custo.

2- O valor de um erro aumenta conforme se avança no projeto. Partindo-se diretamente para a construção o cliente irá validar o seu pedido, ou parte dele, apenas na homologação, onde ele pode apontar erros que foram provocados, em sua maioria, pelo entendimento incorreto da necessidade. A fase de modelagem possui artefatos textuais e visuais, como os protótipos, que fornecem formas valiosas para identificação de erros incorridos pela má interpretação da necessidade. O custo associado ao encontrar um erro na fase de modelagem é, conforme dito, muito menor do que quando encontrado na fase de homologação da solução.

3- “Pular” a fase de modelagem não significa economia de tempo. O tempo dispensado na modelagem provoca o encontro de erros pelo cliente apenas na fase de homologação. Retrabalho na fase de construção pode significar o gasto de um tempo, por vezes, até maior do que o planejado para a fase de modelagem.

4 – A modelagem proporciona a evolução da maturidade da solução conforme o avanço no desenho dos artefatos. Os diagramas por muitas vezes se completam e uma descoberta em, por exemplo, um diagrama de sequência provoca uma nova versão no diagrama de classes que provoca novas versões dos diagramas consequentes e, assim, até uma versão aprovada e definitiva.

5- Apesar de modelagem ser diferente de documentação, a modelagem gera sim importantes artefatos que, no final, documentam o que foi construído, o como foi construído e motivo pelo o qual foi construído. Sem ela, toda essa informação acaba concentrada em recursos ou empresas terceiras que pode gerar uma dependência desnecessária e muitas vezes prejudicial. Ainda falando sobre esse tópico, a ausência de uma documentação do legado pode provocar profundos impactos para a empresa. Há inúmeros exemplos de projetos gigantescos com o objetivo de levantar, por engenharia reversa, a documentação do legado, importante principalmente, para projetos de fusão e/ou incorporação e também projetos de migração para novas plataformas.

O que vocês acham? A fase de modelagem é ou não importante em um projeto de software?

Anúncios

Gestão de projetos 2.0

A realização de uma gestão de projetos eficaz se faz, entre outras coisas, pelo uso de várias técnicas e ferramentas. A Web 2.0 possui ferramentas que, se adequadamente exploradas, podem trazer grandes ganhos em várias áreas de conhecimento do projeto. O termo Gestão de projetos 2.0 origina-se justamente pelo uso dessas ferramentas.

Fóruns de discussão, compartilhamento, blogs, microblogs, wikis, mashups, perfil, comunidades, redes sociais, ferramentas que utilizamos, pelo menos uma delas, todos os dias em nossa vida pessoal. Elas mudaram e estão mudando a forma pela qual nos relacionamos e a forma pela qual consumimos informações. Percebemos também essa mudança cada vez mais no mundo profissional: blogs da presidência, comunidades de eventos da empresa, etc. e porque não, ferramentas de gerenciamento de projetos? E como elas poderiam ser úteis? Abaixo exemplifico algumas das possíveis formas de uso:

Fórum de discussão: pode ser utilizado para tratar dúvidas do projeto, procurando trazer o entendimento comum a equipe. Sua característica colaborativa proporciona também o surgimento de soluções em grupo. Particularmente, pode ser útil nos processos de planejamento do projeto.

Comunidade: caracterizada por possuir um único tema central, no caso, o próprio projeto. Pode ser útil na reunião de todos os stakeholders em único local, proporcionando um meio de integração, de comunicação, compartilhamento de conhecimento e de mobilização da equipe do projeto.

Redes Sociais: em um perfil de uma rede social declaramos nossos hobbies, interesses, e mais profissionalmente, nossas habilidades e conhecimento. Sendo assim, uma coleção de perfis profissionais pode ser útil para que o gerente de projetos encontre pessoas com habilidades inerentes ao projeto. A rede social também é caracterizada pelo relacionamento entre as pessoas e de seus perfis na rede, podendo assim ser utilizada como um modo de construção do clima de equipe e, até mesmo, de feedbacks rápidos e curtos para com a equipe.

Esses exemplos mostram apenas algumas formas de uso. E inegável que as ferramentas de mídias sociais podem trazer ganhos, promovendo uma gestão mais colaborativa e adaptada a cultura e comportamento das novas gerações. Mas é importante lembrar que a mídias sociais são ferramentas, e ferramentas são apenas um meio. Sua implantação deve ser planejada, desenvolvida e monitorada, como em qualquer projeto, para que o objetivo para o qual foi determinado seja alcançado com sucesso.

Link de meu artigo sobre o assunto, como conclusão do MBA: USO DE MÍDIAS SOCIAIS COMO FERRAMENTA NA GESTÃO DE PROJETOS EM DEPARTAMENTOS DE DESENVOLVIMENTO DE SISTEMAS

Desafios enfrentados em um projeto

A figura ao lado representa muito bem o desespero que por vezes nos toma em algumas situações de projeto. Quando estamos gerenciando um projeto nos parece em algumas situações que o mesmo “está vivo”. Bem como diz um amigo meu: ” Quando pareço ter mapeado todas as possibilidades de caminho de um projeto surge de maneira improvável algo do “nada” que acaba causando uma terrível dor de cabeça…”. É… eu também já sofri desta terrível verdade. Um projeto é de uma maneira tão complexa e há tantos elementos nele que o PMI criou 9 áreas diferentes de conhecimento e cada uma com seus respectivos esforços para qual o gerente de projetos deve focar.  A partir de agora irei citar alguns ( 5 pelo menos) problemas e situações comuns que surgem em um projeto: (Para muitos destes até mesmo o grande padre Quevedo teria problemas no intuito de encontrar um explicação lógica)

1 – Escopo -> O escopo é uma das áreas de conhecimento do PMI e tenho ela, por experiência própria, como uma das mais difíceis para gerenciar.  Por muitas vezes, mesmo tendo fechado o escopo com o usuário  Uma, Duas, Três, Quatro vezes , seja esse entendimento documentado por ata, carta, papel de pão ou holograma, é muito comum que no andar do desenvolvimento do projeto – quando você estiver fechando o desenvolvimento ou iniciando a homologação, que o usuário questione sobre uma funcionalidade não requisitada e que não fazia parte do projeto. Pois bem isto não é um problema! É só enviar ao controle integrado de mudanças (PMBOK) para que seja avaliado se esta mudança será ou não aprovada. Dependendo do caso uma alteração ou acréscimo de uma nova funcionalidade pode até não fazer um impacto no projeto em termos de tempo e às vezes custo. Porém, rotineiras mudanças , mesmo que pequenas, podem criar um ciclo sem fim prejudicando o projeto. Por muitas vezes o gerente de projeto terá de ter “pulso firme” para controlar o escopo do projeto e seu conseqüente sucesso.

2 – Grande quantidade de stakeholders envolvidos -> A área de comunicação é fundamental e constitui umas das principais atividades do projeto. Quando o número de stakeholders de um projeto cresce ( e nisso incluo os próprios membros de equipe do projeto) a comunicação vai se tornando cada vez mais desafiante. Por muitas vezes o gerente do projeto irá ter de resolver conflitos e perceber interesses individuais.  É importante que o gerente tenha total controle sobre a sua equipe de projeto. Porém, por muitas vezes isto não será possível porque esses membros podem estar envolvidos em outras atividades as quais aplicam mais interesse ( isto acontece principalmente nas estruturas de organização matricial fraca e funcional).

3 – Riscos -> Aquela frase citada mais acima de um amigo meu mostra muito bem o que acontece quando se fala de riscos. É improvável se mapear todos os riscos que podem causar conseqüências não desejáveis a um projeto. O que faz então, por muitas vezes, é elaborar um plano de contingência a ser utilizado caso alguma coisa venha dar errado no projeto.

4 – Características do próprio projeto -> Como falamos também mais acima o projeto é quase um ser dotado de vida. E como tal, o mesmo vai sofrendo mudanças enquanto há o seu desenvolvimento. Por muitas vezes quando estamos em uma fase mais detalhada do projeto surge algo até então não pensado. E isto é muito mais comum do que possa aparecer.

5 – Priorização de projetos – Por muitas vezes você pode ter uma demanda de diversos projetos para serem atendidos para o usuário. Acontece que a partir de uma seqüência linear previamente definida pelo usuário dos projetos com mais prioridade esta “fila” segue uma constante mudança. Por muitas vezes,  podemos nos deparar em situações em que temos de “sair correndo” literalmente com um projeto porque a prioridade de um usuário mudou , seja lá pelo motivo qualquer.

Calma não se desesperem! Coloquei aqui só os problemas. Porém para todos aqui há algum tipo de solução que se não evita pode, no mínimo, minimizar as suas conseqüências. O importante é sempre não deixa-los crescer e mata-los (os problemas) tornando-se cada vez mais um analista tipo 8 hehehehe.