Escopo variável em projetos de software | Desenvolvimento de Software
Dicas e visões sobre desenvolvimento, metodologias, mercado e como ser um bom profissional da área.
Início > Profissão	> Escopo variável em projetos de software
2 de setembro de 2009 Denis Ferrari
Quantos projetos de software você conhece que foram entregues no prazo e não sofreram alteração de escopo durante o seu desenvolvimento?
Os contratantes de software tem uma falsa idéia de que com um escopo bem definido eles estarão seguros com relação ao produto final que será entregue, e os fornecedores por sua vez de que estarão resguardados contra alterações de requisitos durante o desenvolvimento do software, o que na prática é equivalente ao "Até que a morte os separe" de alguns casamentos.
Quando um contratante decide implantar um software na empresa, ele quer agilizar seus processos e/ou resolver seus problemas, porém, em muitos casos ele acaba gerando novos problemas com os quais não contava. Um projeto de software que dure 1 ano certamente sofrerá alterações de escopo por que é impossível definir todas as nuances de uma implantação antes de começar seu desenvolvimento, então, por que não criar contratos mais flexíveis que permitam novas implementações durante o desenvolvimento? Afinal de contas, se um fornecedor quiser quebrar um contrato, não é um pedaço de papel que irá impedi-lo, na verdade, esse pedaço de papel só vai criar mais problemas.
Os fornecedores por sua vez não deveriam encarar uma prestação de serviço como um contrato comum, mais sim como uma parceria, o objetivo de um profissional de TI é simplificar e viabilizar e não discutir requisitos em contratos cobrando preços absurdos por alterações.
A grande questão é que o mercado como um todo desde o início tratou contratos de softwares de forma equivocada, comprar um software não é comprar uma cadeira, você está pagando o desenvolvimento de algo intangível, o ideal seria pagar o tempo de desenvolvimento e acompanhar todo o processo de construção de perto verificando sempre se o projeto está alinhado com suas necessidades.
Acredito que aceitar que projetos de software são problemáticos é muito cômodo, por que não tentar um novo modelo de contratação? O modelo atual de contratação funciona?
O artigo que escrevi sobre comunicação com o cliente complementa essa visão de trabalho.
Categorias:Profissão Tags:atraso, contrato, escopo, mudança, projeto de software
2 de setembro de 2009 às 11:20 AM
Olá amigo, discordo do seu ponto de vista. O modelo de contratação atual não é o maior problema. Ainda temos que considerar que a maioria das estimativas realizadas pelos atuais engenheiros de software, seja por APF ou outra métrica, são mal feitas. Além disso, no contrato é possível fazer aditivos, o que não impede a mudança de escopo. Então, devemos focar em melhorar o nosso processo e a qualidade do nosso trabalho.
Discordar é viver :). Acredito nos valores do manifesto ágil (Eu e quem assinou), onde indivíduos são mais importantes que processos e ferramentas e colaboração com o cliente é mais importante que negociar contratos.
Segue o link: http://www.manifestoagil.com.br/
Concordo com você no que diz respeito às estimativas erradas, porém, mesmo acertando isso não acredito que o modelo tradicional funcionaria.
No final das contas, vamos tentando acertar cada um de seu jeito.
2 de setembro de 2009 às 11:49 AM
Resumindo ficará muito mais fácil quando as metódologias ágeis tornarem-se o novo padrão para contratos de desenvolvimento de software.
2 de setembro de 2009 às 12:43 PM
Parabéns por sua iniciativa de torna-se escritor.
Analisando seu artigo, eu vejo que, o contrato formal se faz necessário como salva-guarda. Como o Toninho disse acima, nada impede que se faça aditivos no contrato. Quanto ao escopo, já existem ferramentas no mercado que quebram este paradigma tradicional (Em cascata) e que permitem inferências no sistema a medida que ele se desenvolve.
Aguardamos novo artigo.
2 de setembro de 2009 às 1:00 PM
Eu diria que o método tradicional funciona sim, porém para projeto bem pequenos, com duração pequena, e mesmo assim tendo-se a possibilidade de acontecer o que o Denis falou. Mudanças nos próprios processos da contratante, após a análise e pior, após o desenvolvimento. Contando que a comunicação seja somente nas reuniões ou na implantação isso seria um caos.
No caso de estimativas erradas, há dois pontos que podems estar pensando. Ou o engenheiro não sabe medir nada ou há algum problema nos conceitos empregados nos métodos tradicionais. Eu particularmente acredito que há. Neste momento entra os conceito da metodologia ágil, para tentar melhora esses processos de análise e desen volvimento, visando não somente a satisfação do cliente, mas também um melhor desenvolvimento, pois os desenvolvimento são feito em pequenas porções("Faça mais do menos") facilitando, dando a possibilidade de "digerir" mais o processo que estão sendo desenvolvidos.
2 de setembro de 2009 às 3:44 PM
Não considero o modelo tradicional que conhecemos, como a raiz de todos os males para contratação de serviços. Se fosse tão ruim assim, certamente não estaria mais no mercado.
Vejo que o problema está na mutabilidade das necessidades dos negócios (cliente) aliada à histórica falta de capacidade que nós de TI temos em estimar prazo e custo de projetos.
Além disso, o "estabelecimento de escopo" vem da necessidade do cliente de ter uma estimativa de quanto vai gastar.
Responda com sinceridade, você iniciaria a construção de uma casa sem saber quanto precisa para terminá-la?
E mais: se o dinheiro acabar, pra quê ela vai servir?
Eu recomendo que tentem colocar-se no lugar do cliente e entendam o nível de incerteza que existe ao iniciar um projeto de software:
a) A mão-de-obra de TI é cara.
b) É um produto abstrato.
c) O cliente não entende nada de desenvolvimento de software.
d) A fase de desenvolvimento e implantação gera trabalho adicional dentro da empresa do cliente.
e) Há muitos anos vive-se a cultura do gratuito, principalmente depois que a internet tomou conta de nossa vida.
Portanto, sinto que precisamos parar de enxergar o cliente como "um mal necessário" e passarmos a entender suas preocupações e reais necessidades.
Vejo muita gente falar bem do manifesto ágil e ao mesmo tempo defender XP e Scrum, que são métodos de trabalho (processos) com unhas e dentes. Lembrem-se: indivíduos e interações são mais importantes do que processos e ferramentas.
Resumindo: devemos ser parceiros e honestos, independente do modelo de contratação.
2 de setembro de 2009 às 5:04 PM
Concordo com o resumo final do seu comentário, porém, ao meu ponto de vista o modelo de contratação atual cria várias restrições que não somam em nada no desenvolver dos projetos.
Acredito sim que seja necessário realizar levantamos para estimar o quanto de dinheiro e tempo será gasto, porém, acho que da forma como isso é feito não funciona para todos os projetos.
Comparar softwares com casas leva a discussões extensas, porém, duas diferênças devem ser citadas: Softwares podem ser entregues interativamente agregando valor ao negócio do cliente a cada release e casas também dificilmente são construídas exatamente como são projetadas.
Duas perguntas foram levantadas:
(1) O modelo atual de contratação funciona?
Funcionar funciona. O que deveriamos nos perguntar é: O modelo atual pode ser melhor?
(2) por que não tentar um novo modelo de contratação?
Por que não? Desde que o cliente aceite hehehe
3 de setembro de 2009 às 1:06 PM
Os métodos ágeis não descartam estimativas, pelo contrário, você precisa ter ainda mais precisão, pois trabalhará em iterações, e cada iteração deve ser planejada, e isso tudo tem um custo. Concordo que poderia ser melhor o processo atual, todas as métricas atuais são passíveis de discussão, mas para você vender, é necessário mostrar ao cliente o que e porque ele está pagando.
Penso que é necessário esclarecer o ponto de discussão, a proposta do texto foi discutir sobre os modelos de contratos atuais, e muita gente está discutindo metodologias de desenvolvimento e ciclos de vida. Certamente o fator humano será o aspecto mais importante em qualquer metodologia.
Não devemos cair no modismo da metologia ágil achando que é o paraíso. A primeira vista, o modelo tradicional parece ser mais dispendioso para o cliente, mas projetos iterativos tendem a ser mais caros no contexto geral, o cliente não enxerga isso porque nós vamos tirando aos poucos dele (iterativamente).
Ainda acho que não é necessário mexer nos contratos, mas sim especificá-los melhor, ter mais pessoas qualificadas e motivadas a fazer um bom trabalho.
3 de setembro de 2009 às 4:20 PM
Acredito que o contrato deva refletir seu método de trabalho, afinal de contas, se a organização não estiver alinhada desde a equipe de vendas até o pessoal da implantação concerteza ela terá problemas ao longo do caminho.
Não acho que sigo modinhas, estudo e uso métodos ágeis e sei como é complexa a aplicação de suas diretrizes, porém, acredito mais nisso do que no modelo atual. Eu citei as metodologias ágeis pelos seus valores, os quais acredito que toda a equipe (inclusive vendedores) tenham que ter.
Para tratar escopo variável com um cliente você não pode negociar da mesma forma, os argumentos de venda são completamente diferentes, e por consequência o modelo de contratação será diferente, porém, com algumas técnicas você consegue apresentar estimativas da mesma forma como era feito antes só que agora elas são tratadas realmente como estimativas e não como regras, e caso o escopo mude ninguem precisará acessar o setor jurídico.
Posso parecer radical, mas a intenção é exatamente essa, chocar e provocar discussões :).
3 de setembro de 2009 às 4:49 PM
Respeito seu ponto de vista, é uma abordagem diferente. Mas lembre-se de uma coisa: um bom engenheiro de software precisará de muita disciplina e rigor mesmo utilizando metologias ágeis.
Engenheiros de software radicais tem seu valor, principalmente pela criatividade, mas em equipes grandes ou em grandes projetos podem não ser muito úteis pela inquietação e volatilidade.
3 de setembro de 2009 às 5:12 PM
Valeu Toniho,
Não me sinto engenheiro de software radical :).
Acredito que cada empresa tenha seus métodos, e se eles estão funcionando pra que mexer? Nenhuma metogologia é garantia de sucesso, não existe bala de prata.
A minha contestação no artigo é que estatísticamente projetos de software sempre pecam nas mesmas coisas, o que me irrita bastante (não só eu como todos os stakeholders), e acredito que fazer de uma forma diferente pode reduzir esses números (pelo menos tem melhorado pros meus projetos).
Não acredito que a inquetação e volatidade de um profissional seja prejudical a um projeto, essas característas quando aproveitadas geram excelentes frutos, porém, se o projeto é cheio de imposições e não abre espaço a idéias e formas diferentes de fazer esse perfil de profissional vai realmente incomodar, mas vai incomodar aos gestores e não ao projeto.
3 de setembro de 2009 às 7:55 PM
Bom, ainda mantenho minha opinião em relação a volatilidade, dependendo do projeto, ela poderá atrapalhar. Quando puder acesse: http://www.naccq.ac.nz/bacit/0302/2005Desouza_SwEngineers.htm . É um dos artigos mais reconhecidos na área e fala sobre isso. Aproveite que está na academia e desfrute dos artigos científicos… eles ajudam a fundamentar nossas idéias e não somente por empirismo.
Acho que não me fiz entender, mas vou parar por aqui. O objetivo do Blog é apresentar e não impor idéias, e todas as idéias que apresento são com base em experiências em projetos de mercado e não projetos acadêmicos, inclusive um artigo da próxima semana abordará esse tema.
Apresente suas idéias de desenvolvimento de software para que possamos discutir e talvez achar o cinza nesse mundo preto e branco.
Por favor, continue lendo e criticando os artigos, rebater idéias sempre é bom, e ao contrário do que você disse, tenho fundamentos para minhas decisões de projetos, porém, também tenho paixão pelo que faço.
Profissionais de TI pioram com o tempo O que vale mais, experiência profissional ou faculdade?
No TwitterNo MSN/E-mail
Palestra sobre TDD na Faesa
LINQ to Entities e Entity Framework
LINQ e LINQ to SQL
Sou o melhor técnico e agora virei gerente!
Termino o dia cansado, mas posso dizer: Eu amo meu trabalho. (: 1 week ago
Encontro de pré-incubados na TecVitória. em TecVitoria Incubadora instagram.com/p/BhhDxPxFylF/ 1 month ago
Mais um Startup Weekend entregue. Dá trabalho, mas sempre é uma experiência muito boa. Bora para… instagram.com/p/BhWS479hK9L/ 1 month ago
Reunião de Mentores. (: em Wine.com.br instagram.com/p/BhR1ubyhEyJ/ 1 month ago
Mais um time de Mentores do Startup Weekend. em Wine.com.br instagram.com/p/BhRh77ChrGr/ 1 month ago
Tô me sentindo na Época do Rádio Taxi. 25 minutos tentando um táxi. Valeu pela experiência @easytaxi. 1 month ago