Não defina Metodologia de Desenvolvimento de Software…

Posted on Posted in #governoagil, Metodologia Ágil

Se você é Gestor Público de TI e está iniciando o planejamento da contratação da sua próxima “fábrica de software” (não acho esse termo correto, mas esse assunto fica para outro post) porque NÃO TEM EQUIPE DE DESENVOLVIMENTO no seu órgão, então NÃO DEFINA METODOLOGIA DE DESENVOLVIMENTO DE SOFTWARE. As famosas MDS.

A lógica é a seguinte: se eu, Órgão Público, vou contratar porque não vou desenvolver o sistema, ou seja, eu não irei executar as etapas do desenvolvimento, então eu não preciso de uma Metodologia (ou Modelo) de Desenvolvimento de Software…..quem precisa é a empresa que irá fazer. Eu, Poder Público, preciso gerenciar o produto que ela entrega.

Uma pergunta pode estar no ar: “- Se eu não definir uma metodologia, a empresa irá fazer de qualquer jeito?”Isso mesmo, a empresa até pode fazer de qualquer jeito, mas o Gestor Público só aceita se o sistema estiver exatamente conforme as especificações negociais e técnicas.

Não é relevante se a empresa usa Casos de Uso ou User Story, o importante é se o produto foi entregue como eu pedi.

Notem que há uma diferença entre o fazer e o produto. O que queremos, na gestão por resultados e contratos por Ponto de Função é uma métrica de resultado – assunto para outro post, é o produto e não a forma de fazer.

O que queremos é o produto e não a forma de fazer.

Logo, devemos definir a FORMA DE GESTÃO DA DEMANDA.  Seria definir como cobraremos os serviços solicitados:

  • A periodicidade das Ordens de Serviços (OS)
  • Os prazos de entregas
  • Os acordos de níveis de serviços
  • Os requisitos negociais e técnicos da demanda

Percebam que definimos a mera forma de comunicação e cobrança da execução contratual. A empresa pode até usar Cascata, RUP, Scrum, FDD, Kanban ou XP, mas a forma de aceitação dos produtos, quais produtos o órgão necessita e em qual periodicidade, é  o Gestor Público que define.

O trabalho maior do Gestor Público no planejamento de um contrato é definir os critérios de aceitação dos produtos. A forma de fazer não é o foco.

Mas se o seu órgão público possui uma equipe de desenvolvimento interna, o Gestor pode definir uma metodologia de desenvolvimento de software para ser usada internamente. Se alguém perguntar ” – Tenho equipe interna e uma metodologia oficializada aqui no meu órgão, é bom usar no edital para alinhar com a equipe interna?” Talvez, mas analise bem se você irá ter equipe externas e internas alinhadas.

by Herbert Parente

4 thoughts on “Não defina Metodologia de Desenvolvimento de Software…

  1. Ponto de vista interessante, Herbert.
    Contudo, neste cenário há uma questão interessante sobre documentação dos sistemas desenvolvidos.

    No caso de uma empresa pública, que não tem equipe de desenvolvimento interna, é de extrema importância que se tenha a documentação do sistema entregue. Visto que fábricas de software são contratadas por um período de tempo (não indefinidamente). E falo isso porque devemos garantir a continuidade do produto.

    Concordo contigo em relação à definição de uma Metodologia de Desenvolvimento de Sistemas. Não é necessário (nem desejado) ensinarmos a uma fábrica como trabalhar. Mas acho importante definirmos os entregáveis, sejam um software ou mesmo um diagrama ou um documento, não?

  2. Parabéns pela iniciativa! Como entusiasta das metodologias ágeis e futuro servidor público, espero ansioso pelos próximos posts.

    1. Obrigado Giordano, pretendo lançar 1 post a cada 2 semanas. O próximo será sobre os risco de Pontos de Função com contratação pública e metodologias ágeis.

  3. Herbert, excelente post.
    No meu entendimento o órgão deveria possuir um Processo de Software (padrão) que definisse todos os artefatos a serem entregues por qualquer prestador de serviço de desenvolvimento/manutenção de sistemas, englobando Engenharia de Requisitos, Engenharia da Informação, Construção (códigos fontes), Documentação do usuário (help, manuais), documentos contratuais e principalmente o Produto de Software funcionando e livre de bugs.
    Se possuir equipe própria de desenvolvimento, o que ocorre em muitos órgãos, o processo deveria prever a execução de uma MDS, mas dificilmente daria para cobrar dos terceiros que seguissem essa MDS.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *