Parcerias estratégicas em desenvolvimento de software
Um dos pontos críticos no desenvolvimento de software e sistemas é a medição de esforços para a execução dos esforços. Existem algumas maneiras para se medir esforços de desenvolvimento, como análise de pontos de função, COCOMO etc. Para que essas técnicas sejam efetivas, é necessário uma definição de escopo precisa do trabalho a ser efetuado e uma base histórica sobre a produtividade efetiva da equipe que vai executar o trabalho.
Mesmo que se controle preciosamente fatores de risco que impactam o tamanho de um projeto ainda no seu início, sempre ocorrerão mudanças durante o andamento do mesmo. Existem vários tipos de alterações que acontecem no decorrer de um projeto, alguns de natureza positiva e outras nem tanto. Podemos citar como exemplo alterações decorrentes de um maior refinamento de negócio onde se encontram oportunidades a serem exploradas, que não estavam previstas originalmente. Essas novas descobertas que demandam mudanças, são exemplos que impactam positivamente o negócio do cliente, devendo ser estudado o projeto para contemplar tais alterações. Como já foi citado, nem todas as mudanças são positivas, podemos citar como maus exemplos, as mudanças decorrentes de desorganização de quem demanda o projeto ou de quem executa.
Ter em mãos o controle de mudanças durante os projetos é um dos aspectos fundamentais para o seu bom andamento. Existem algumas maneiras de controlar impactos de mudanças, por exemplo estabelecendo pontos de controle nos custos, onde a partir dos quais, possa ser disparado um processo de renegociação de valores. Mesmo que um projeto seja bem mensurado em seu início e o mesmo não contenha muitas mudanças durante a sua execução, desvios podem acontecer que impactem a rentabilidade do mesmo. E a consequência da má situação financeira de um projeto pode afetar o mesmo como um todo.
Um fator que traz segurança para fornecedores e clientes de software e sistemas, é a existência de parcerias fortes, onde a confiança seja decorrente da demonstração mútua de comprometimento com a saúde do negócio de ambas as partes. Pois conforme foi ilustrado, mudanças sempre ocorrerão em projetos, seja qual for a natureza do mesmo.
As metodologias atuais utilizadas para desenvolvimento de software, não resolvem todos os problemas, e se mal utilizadas acabam comprometendo um projeto logo na largada. A metodologia do PMI prevê que um projeto possui uma fase de iniciação. E aqui se encontra um grande paradoxo na adoção dessa metodologia quando se trata de terceirização de serviços de desenvolvimento de software. Nesse tipo de contratação, geralmente um cliente lança uma RFP no mercado e aguarda proposta de fornecedores. Supõe-se que alguêm executou uma fase de iniciação do projeto para partir para um levantamento de propostas. As consultorias que irão apresentar propostas geralmente só tomam conhecimento do projeto através de uma RFP, ou no máximo através de uma RFI, o que significa que a fase de iniciação que prevê o levantamento preciso de escopo e de esforço acontecerá após o fechamento de contrato, o que dá margem a discussões e desentendimentos.
A percepção de incertezas em determinadas situações, por sí só não garante o seu controle, portanto é necessário compreender que em casos que tenham essa natureza, a flexibilidade deve ser maior que a rigidez para se atingir os objetivos traçados. Para concluir esse raciocínio, vamos expor aqui um texto original de um fragmento do livro "Rational Unified Process, The: An Introduction, Third Edition By Philippe Kruchten".
That is how skyscrapers and bridges are built. It's a rational way to proceed but only because the problem domain is relatively well known; engineers can draw on hundreds of years of experimentation in design and construction.By contrast, software engineers have had only a few decades to explore their field. Software developers worked very hard, particularly in the seventies and eighties, to accumulate experimental results in software design and construction. In 1980 I would have sworn that the sequential process was the one and only reasonable approach.
Software engineering has not reached the level of other engineering disciplines (and perhaps it never will) because the underlying "theories" are weak and poorly understood, and the heuristics are crude. Software engineering may be misnamed. At various times it more closely resembles a branch of psychology, sociology, philosophy, or art than engineering. Relatively straightforward laws of physics underlie the design of a bridge, but there is no strict equivalent in software design. Software is "soft" in this respect.
Revisões
Escrito em 17/08/2007 03:00 em aprox. 5:00 hr
Mesmo que se controle preciosamente fatores de risco que impactam o tamanho de um projeto ainda no seu início, sempre ocorrerão mudanças durante o andamento do mesmo. Existem vários tipos de alterações que acontecem no decorrer de um projeto, alguns de natureza positiva e outras nem tanto. Podemos citar como exemplo alterações decorrentes de um maior refinamento de negócio onde se encontram oportunidades a serem exploradas, que não estavam previstas originalmente. Essas novas descobertas que demandam mudanças, são exemplos que impactam positivamente o negócio do cliente, devendo ser estudado o projeto para contemplar tais alterações. Como já foi citado, nem todas as mudanças são positivas, podemos citar como maus exemplos, as mudanças decorrentes de desorganização de quem demanda o projeto ou de quem executa.
Ter em mãos o controle de mudanças durante os projetos é um dos aspectos fundamentais para o seu bom andamento. Existem algumas maneiras de controlar impactos de mudanças, por exemplo estabelecendo pontos de controle nos custos, onde a partir dos quais, possa ser disparado um processo de renegociação de valores. Mesmo que um projeto seja bem mensurado em seu início e o mesmo não contenha muitas mudanças durante a sua execução, desvios podem acontecer que impactem a rentabilidade do mesmo. E a consequência da má situação financeira de um projeto pode afetar o mesmo como um todo.
Um fator que traz segurança para fornecedores e clientes de software e sistemas, é a existência de parcerias fortes, onde a confiança seja decorrente da demonstração mútua de comprometimento com a saúde do negócio de ambas as partes. Pois conforme foi ilustrado, mudanças sempre ocorrerão em projetos, seja qual for a natureza do mesmo.
As metodologias atuais utilizadas para desenvolvimento de software, não resolvem todos os problemas, e se mal utilizadas acabam comprometendo um projeto logo na largada. A metodologia do PMI prevê que um projeto possui uma fase de iniciação. E aqui se encontra um grande paradoxo na adoção dessa metodologia quando se trata de terceirização de serviços de desenvolvimento de software. Nesse tipo de contratação, geralmente um cliente lança uma RFP no mercado e aguarda proposta de fornecedores. Supõe-se que alguêm executou uma fase de iniciação do projeto para partir para um levantamento de propostas. As consultorias que irão apresentar propostas geralmente só tomam conhecimento do projeto através de uma RFP, ou no máximo através de uma RFI, o que significa que a fase de iniciação que prevê o levantamento preciso de escopo e de esforço acontecerá após o fechamento de contrato, o que dá margem a discussões e desentendimentos.
A percepção de incertezas em determinadas situações, por sí só não garante o seu controle, portanto é necessário compreender que em casos que tenham essa natureza, a flexibilidade deve ser maior que a rigidez para se atingir os objetivos traçados. Para concluir esse raciocínio, vamos expor aqui um texto original de um fragmento do livro "Rational Unified Process, The: An Introduction, Third Edition By Philippe Kruchten".
That is how skyscrapers and bridges are built. It's a rational way to proceed but only because the problem domain is relatively well known; engineers can draw on hundreds of years of experimentation in design and construction.By contrast, software engineers have had only a few decades to explore their field. Software developers worked very hard, particularly in the seventies and eighties, to accumulate experimental results in software design and construction. In 1980 I would have sworn that the sequential process was the one and only reasonable approach.
Software engineering has not reached the level of other engineering disciplines (and perhaps it never will) because the underlying "theories" are weak and poorly understood, and the heuristics are crude. Software engineering may be misnamed. At various times it more closely resembles a branch of psychology, sociology, philosophy, or art than engineering. Relatively straightforward laws of physics underlie the design of a bridge, but there is no strict equivalent in software design. Software is "soft" in this respect.
Revisões
Escrito em 17/08/2007 03:00 em aprox. 5:00 hr
