Skip to content

Quero meu software e não documentos!

outubro 15, 2009

Antes de mais nada, o titulo me parece um pouco polêmico, Desenvolver software sem documentação? Não precisamos considerá-lo ao extremo. Mas quando falamos de desenvolvimento de software o que eu vejo é que a documentação é mais importante que o próprio software. Processos pesados, burocráticos e que procuram segui-lo ao pé da letra, esquecendo que desenvolver software é uma arte e não devemos tratar tudo como simples metódos operacionais.

Sou “Analista” e vou escrever os documentos para o programador. Um dos erros mais comuns daqueles que ainda não entendem o ciclo de vida de uma equipe em um projeto de software que procura atender as espectativas dos stakeholders é o fato de considerá o seu desenvolvimento em fases, criando uma fase para análise, outra para modelagem, outra para construção e por seu fim a fase de teste para entrega do produto. Ok, os passos existem mas devem serem consideradas em um processo incremental! As pessoas esquecem isso, esquecem que o cliente nem sempre sabe o que quer e que só apresentando o software construído constantemente, você pode reduzir os riscos e entregar algo que realmente é útil para ele.  Com as metodologias ágeis em alta, muitas pessoas encaram isso como a solução dos seus problemas, mas não é o ágil que irá resolver seus problemas e sim a COLABORAÇÃO da equipe em fazer acontecer, fazer entregar o produto que satisfaça o cliente.

Vejo as pessoas fazendo um monte de asneiras, pessoas com anos de experiência em construcão de software, tapam os ouvidos e aumentam seu EGO em acharem que estão fazendo um ótimo trabalho sem ao menos saber o que pode ser melhorado e o que eles tem errado. Essas pessoas são ótimas para se encaixar em um processo burocrático, cheio de documentos e pouco código.  Transformar o desenvolvimento de software em processos operacionais atribuindo cada atividade isolada a cada pessoa (ou equipes), fazendo com que o ato de programar seja algo ridicularizado, mesmo que no final o resultado prove ao contrário, só dá espaços para o fracasso do projeto.  entregas acima do prazo estimado (o fato de querer detalhar todo o projeto no inicio e estimá-lo como se o desenvolvimento dele é só uma questão de tempo, como uma máquina fabricando x frascos por hora), nem sempre conseguindo atender as espectativas do cliente (Devido a tamanha quantidade de documentos em um processo burocrático da espaço a distanciar o cliente do que realmente ele deseja.), a qualidade comprometida (programadores implementam um monte de documentos especificados pelo analista após meses de sua “atividade intelectual” do projeto.).

Trabalhando em equipe! Não tem nada de novo nisso, as coisas são comuns para aqueles que já tem um tempo vivenciando projetos das mais diversas situações, equipes, clientes, projeto.. e no final voltamos a fazer algo que já se fazia quando não precisavamos “burocratizar tudo” para desenvolver uma solucão no mundo computacional de um problema do mundo real. Fazer uma equipe trabalhar em conjunto (por isso equipe) em resolver os problemas do cliente é o ponto principal de qualquer processo.  Entender o problema, debater e opiniar por solucões devem ser diretos de todos da equipe e não apenas de uma pesssoa que está destinada a fazer esse trabalho.

Um desenho vale mais que mil palavras. Sempre que desenvolvemos, rabiscamos para podermos debater e discutir em equipe os problemas e propor as melhores estruturas para a solução do problema, aplicando isso em rascunhos a resposta se torna mais rápido dando liberdade a resolução do problema de maneira mais prática e eficácia

Volto a lembrar que não deve-se levar tudo ao seu extremo, não estou aqui para falar que não precisa-se de documentos e nem de analistas, arquitetos e programadores, estou apenas mostrando que a forma de ser trabalhar deve-se ser melhorada e focada no que o cliente precisa! Documentos devem ser criados apenas quando necessário e não como obrigatórios.  As pessoas esquecem de entregar algo útil para o cliente e trabalham para seguir o processos que “acham” ser valioso.  Algumas pessoas usam elas como uma forma para se defender de futuros fracassos do software.  Será que isso é trabalhar em equipe? e qual o objetivo da equipe e qual o seu objetivo?

From → Metodologias

17 Comentários
  1. Parabéns pelo post polêmico!

    Documentos ajudam a nos defender diante de um projeto negociado, determinando o início e o fim do produto final.

    O problema é: os requisitos mudam com o passar do tempo, daí novos documentos podem ser anexados ao escopo do projeto fazendo com que os “programadores” mais preencham relatórios do que te fato programem.

    O pulo do gato é não burocratizar demais a coisa, tornando-a enfadonha, pois como você citou no início do post “…desenvolver software é uma arte…”

    Abraço pra ti irmão

  2. Sérgio Souza permalink

    É isso ae rapaz… fazer checkout no svn de quase 1Gb de documentos desatualizados, na sua maioria, não dar!

    Força nos post e parabéns!

  3. Deise Costa permalink

    Se muitos documentos ajudassem na construção de um sw, a qualidade do mesmo não estaria tão comprometida. Isso é a prova de que ninguém ler nada!
    Mas, se a idéia é só manter o svn cheio de documentos então, escreve o código com qualidade e depois cria vários docs word. Assim, poderemos garantir que estarão atualizados (ou não), e que pelo menos 80% do que foi solicitado pelo cliente foi construido.
    😛

  4. Danilo permalink

    Legal o post Chefe …. Muito bom mesmo.

  5. Fabrício permalink

    Gostei do Post Verto. Agora as pessoas que saem faculdade sem saber programar vão ficar sem emprego, já que só servem pra escrever DOC.🙂

  6. Franco permalink

    Discordo que desenvolver software seja uma arte… Devemos combater essa mentalidade… Se for assim vamos parar com essa estória de Fábrica de Software e vamos mudar o nome para Ateliê de Software.
    Assim também entraremos na lei de incetivos fiscais Rouanet e no vinculamos ao Ministerio da Cultura e Fundacao Nacional de Artes.
    VOce provavelmente trabalha em uma empresa sem vergonha com profissionais de baixa qualificação. Nunca ouvi um gestor de uma empresa com MPS.BR ou CMMi falando mal de Eng. de Software. Pq só os frustrados de empresas formada por amadores tem esse complexo???

    • Olá Franco,

      Desenvolver software é sim uma arte🙂 arte, porque as escolhas para soluções dos problemas são extensos, arte porque não existe o procedimento padrão para se construir software, temos ferramentas e metodologias para solucionar os problemas, agora como você irá resolver..

      Fabrica de Software é furada, não queria comparar engenharia de software com engenharia civil.. ou algo parecido. ( esse debate já existe aos montes na internet )

      Não tenho nada contra processos CMMI, ( a empresa em que eu presto serviço é CCMI ).

      Empresas formadas de amadores? grandes empresas prezam pelo software e não pelos seus documentos.

      Thoughtworks, 37signals.. globo.com .. várias empresas aplicam cada vez mais práticas em que seu principal objetivo é o Produto . A falta de entedimentos das metodologias fazem com que as empresas encham seus processos de documentos sem se perguntar se está sendo útil para o produto final ou não.

  7. Franco, deu discurso aparenta estar destoado da realidade do desenvolvimento de software moderno. Desde os anos 70 se diz que programar é uma atividade intelectual e altamente criativa. Recentemente Robert Martin, James Shore, Martin Fowler e outras comparam desenvolver software com arte.

    Inclusive, nos dois mais recentes eventos de desenvolvimento de software, o Agiles 2009 e o Rails Summit 2009, tiveram o Joshua Kerievsky e o Obie Fernandez respectivamente defendendo este ponto de vista colocado pelo Everton.

    MPS.BR e CMMI não garantem muita coisa. Nada adianta você ser maduro num processo que é ruim. Abraços!

  8. Franco permalink

    Cardoso

    Entao o problema nao sao as metodologias e sim, como voce disse a falta de entendimento delas.

    Contudo nao foi isso que voce argumentou em seu post. Repetitivamente, disse que documentos não são úteis, e apenas código é o que interessa para o cliente.

    Uma coisa é ovcê dizer que não estão usando documentação da maneira correta, e outra é você dizer que ela deve ser desconsiderada, e somente em casos extremos utilizada.

    O fato de voce prestar servicos a uma empresa com CMMi sei la de qual nivel realmente nao significa nada, até pq sua mentalidade contradiz as praticas do CMMI-DEV

    • Franco, acho que você não conseguiu entender a idéia principal do contéudo!

      Não estou propondo acabar com os documentos! use se acham úteis para seu projeto. Se você tivesse mais atencao ao que eu escrevi deveria ter lido quando eu falo:
      “Documentos devem ser criados apenas quando necessário e não como obrigatórios. ”

      Não vou mais discutir algo tão claro e real para aqueles que presenciam a evolucão do desenvolvimento de software.

  9. Franco permalink

    Na verdade profissionais como voce devem ser riscados do mercado pq favorecem o amadorismo que esta viciando a area TI

    A regulamentação é o unico baluarte hoje para acabar com o lado podre do TI , que muitos se negam a reconhecer o que esta diante de seus olhos, e os academicistas alienados que realmente nao o conhecem (leia-se SBC)

    • Antonio Jr permalink

      Franco,

      Não posso ficar calado com essa. Estive recentemente no Agiles 2009 em Florianópolis e conheci pessoas formidáveis como o Joshua Kerievsky. A palestra dele foi um comparativo entre a arte e os processos de desenvolvimento de softwares. Desenvolver software é SIM uma arte. Documentação obrigatória só para seguir um determinado processo é uma grande perda de tempo.
      Como diz a minha sogra: o papel aceita tudo. A melhor documentação é ver os metódos de testes verdinhos.
      Eu acho que voce perdeu o bonde. Atualize-se.

  10. Franco, duvido muito que você sabia desenvolver software ou gosta mesmo de fazer isso.

    Com seu ponto de vista primário e controverso a realidade atual você estaria falando que Pessoas como Martin Fowler , Kent Back, Eric Evans, Craig Lerman entre outros devem ser “riscados do mercado”. O próprio manifesto ágil quando nos diz: “O funcionamento do software acima de documentação abrangente;”

    Bom, já conheco muito bem o tipo de profissional que você é então.. boa sorte🙂

  11. Documentação boa é a estritamente necessária. Ponto.

  12. Documentação boa é aquela executável e verificável.

  13. O meio termo deve ser considerado. Devemos criar documentos baseado nas necessidades do projeto e não porque esta definido em um processo X ou Y.

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: