Gerenciamento de projetos
Segundo SARTORE(2005) em um estudo realizado em 8230 projetos
de informática, 52,7% dos projetos foram implantados fora dos prazos acordados e
superaram cerca de 180% do orçamento estimado. 31,1% dos projetos foram
cancelados antes da implantação. Somente 16,2 % dos projetos foram implantados
com sucesso. Segundo o autor, 83,8% destes projetos tiveram problemas por causa
do mau gerenciamento de projetos.
Mas o que é um projeto? Segundo o PMI(1996) um projeto,
possui um início e fim estabelecido. São únicos, mesmo que sejam parecidos,
possuem características que diferenciam um do outro. São desenvolvidos por
pessoas e utilizam recursos limitados.
Assim são necessários inúmeros controles e mecanismos de
medição e a avaliação para o correto gerenciamento de um projeto. SARTORE(2005)
nos lembra que se faz importante o conhecimento do nicho de negócio que se irá
desenvolver o projeto para o alcance de resultados melhores.
Como então alcançar resultados satisfatórios e não entrar nas
estatísticas de fracassos? Podemos recorrer ao PMBOK – Project
Management Body of Knowledge. Trata-se de um guia de
melhores práticas para o gerenciamento de projetos compilados pelo Project
Management Institute – PMI.
Entre as principais disciplinas abordadas por este guia estão
PMI(1996):
·
Gerência de integração.
·
Gerência de escopo.
·
Gerência de tempo.
·
Gerência de custo.
·
Gerência de qualidade.
· Gerência de recursos humanos.
· Gerência de comunicações.
· Gerência de riscos.
· Gerência de aquisições.
A aplicação destas práticas em si, não são garantia de
sucesso, entretanto permitirão que boas equipes alcancem grandes resultados.
Design requisitado x realizado
BONACIN(2004) destaca que grande parte do problema da
qualidade dos softwares se concentram no paradigma objetivista utilizado pela
ciências naturais e aplicados no processo de desenvolvimento de software. Lidar
com abstrações não é tão simples como se imagina ou realiza. Símbolos e suas
representações podem ter inúmeros significados diferentes para duas ou mais
pessoas. Assim a lógica do terceiro excluído (onde não existe o meio termo, ou é
verdadeiro ou é falso), tem feito com que muitos projetos fracassem.
Usuários podem pedir que um botão seja construído em seu
sistema para liberar o crédito de pagamento e este pode estar pensando em uma
tecla do celular, teclado, widget de uma interface gráfica ou até mesmo um botão
de pressão em um console de seu mouse ou carro.
O que BONACIN(2004) alerta é que, a realidade não é a mesma
para todos, ela é subjetiva e possui diferenças de significado e significância,
de acordo com populações ou grupos. Assim ele propõe que uma perspectiva
subjetivista deveria ser empregada, onde os analistas ajudem os usuários a
desenvolverem uma solução. Baseado nos conceitos de produção enxuta, Andon e
PokaYoke, o autor propõe o uso do design participativo, lembrando que os
funcionários são elementos inteligentes e que a solução de problemas rotineiros
ao trabalho é realizada por pessoas próximas a ele. Assim um sistema
computacional deve ser desenvolvido com os usuários e não para os usuários.
O design participativo exige que os designers estejam imersos
no local de trabalho do usuário, compartilhando o mesmo contexto. Técnicas de
etnografia são empregadas com o intuito de melhor entender o trabalho e o
contexto organizacional. Isto inclui a realização de gravações e registro
sistêmico. BONACIN(2004) ainda aponta outras técnicas:
·
Jogos de desenho de ícones– Um participante desenha esboços de ícones enquanto outros tentam adivinhar o que o desenhista tenta expressar.
·
HOOTD (Hierarchical Object-Oriented Task Decomposition) – Decompor uma tarefa em objetos e ações tomadas sobre eles em uma interface gráfica junto aos usuários.
·
Prototipação – Uso de storyboard com interfaces elaboradas em papel ou de uma versão eletrônica de interface.
Ainda outras técnicas podem ser utilizadas e serão mais bem
abordadas pela disciplina de Interação Homem Máquina. Assim, existe uma margem
muito grande para aperfeiçoamento dos processos de engenharia de software, que
ultrapassam barreiras interdisciplinares, como a semiótica, antropologia,
psicologia etc.
Referencial teórico
PMI. – “Project Management Body of Knowledge”. PMI. 1996.
SOMMERVILLE, Ian – “Software Engineering”, 8° edição, Pearson
Education, 2007.
PRESSMAN, Roger S – “Software engineering: a practitioner’s
approach”, 5° edição, McGraw-Hill, 2001.
VEGA, Ítalo S – “Processos de Software – Dificuldades no
Desenvolvimento de Sistemas de Software”,
Disponível em:
http://download.microsoft.com/download/5/a/5/5a58d817-90d1-4878-b275-26ab3552e6d3/AA1/AA1Webcast1.zip
Acessado em 10/01/2009
SWEBOK – “Guide to the Software Engineering Body of
Knowlegment”, 2004.
Disponível em:
http://www.swebok.org/htmlformat.html.
Acessado em 21/08/2008.
SOFTEX – “MPS.BR – Melhoria de Processo do Software
Brasileiro – Guia geral”
Disponível em:
http://www.softex.br/mpsbr/_guias/MPS.BR_Guia_Geral_V1.2.pdf
Acessado em: 21/08/2008
SARTORE, Airton – “Projetos de informática: Gerência e
controle”. Rio de janeiro, Editora rio, 2005
BONACIN, Rodrigo – “Um modelo de desenvolvimento de sistemas
para suporte a cooperação fundamentado em design participativo e semiótica
organizacional”, Campinas , UNICAMP, 2004
GUSTAFSON, David – “Theory and problems of Software
engineering”, SCHAUMS, 2002
CMMI – “CMMI for development version 1.2 – Improving
processes for better products”, Pittsburgh, Carnegie Mellon, 2006
