A morte pela documentação

Frequentemente nós tendemos a pensar na documentação como um componente adicional a um projeto em vez de uma parte real do projeto. A verdade sobre este assunto é que a documentação pode fazer a diferença entre o sucesso e o fracasso de um projeto.

Vez após vez, organizações têm criado bons produtos mas não investido os recursos necessários em sua documentação. Muitos desses produtos se tornaram um fracasso de mercado, não por serem maus produtos, mas porque as pessoas não sabiam como usá-los.

Havia uma grande organização de software que costumava fazer bons pacotes de desenvolvimento. A versão 3 de um software desta companhia era muito bem aceito e tinha grande chance de se tornar a plataforma de desenvolvimento dominante em uma área específica.

Querendo dominar o mercado, a organização investiu todos os seus recursos na versão 4. A interface com o usuário foi mudada na versão 4. Mudaram as opções. Mudaram as chamadas. Mudaram tanto que os usuário teriam dúvidas se a versão 4 era o mesmo produto que a versão 3.

De fato, foi criado um produto de desenvolvimento que estava bem à frente de seu tempo e teria impulsionado dramaticamente a programação. O que aconteceu, na verdade, é que a coisa toda se inverteu e o software foi descontinuado. Enquanto isso, outra organização liberou o software de desenvolvimento que se tornou padrão de fato.

O que deu errado? Como essa organização falhou tão miseravelmente?

Ela vendeu o produto por dois preços. Pelo primeiro preço a empresa entregava apenas a mídia. Pelo segundo preço (quase duas vezes mais) entregava aos usuários a mídia e milhares de páginas de manuais de como usuá-lo.

Muitos programadores pensaram que mudando da versão 3 para a versão 4 estariam fazendo uma mudança evolucionária, e não compraram os manuais. Sem os manuais, os desenvolvedores se perderam sem conseguir imaginar como fazer o que eles precisavam fazer. Frustrados e aborrecidos, os desenvolvedores abandonaram o pacote.

Aqueles que adquiriram os manuais foram literalmente esmagados pelos milhares de páginas espalhadas por cinco livros que se referenciavam mutuamente de tal modo que os usuários tinham que ter todos os livros abertos ao mesmo tempo de maneira a imaginar como fazer o que precisavam fazer. Estes que gastaram o dinheiro extra também abandonaram a nova plataforma.

Naturalmente a plataforma morreu; não porque não era boa, mas porque a documentação a matou. Documentação escrita adequadamente, empacotada adequadamente como um produto de qualidade, deveria impulsionar a empresa para uma posição invejável.

Quando você projetar sua documentação, tenha em mente essa história e assegure que seus produtos não se tornem presa do mesmo fato. Esta catástrofe é bastante fácil de prevenir, mas você deve fazer um esforço consciente de fazer isso.

Traduzido do livro SOFTWARE PROJECT MANAGEMENT FOR DUMMIES de Teresa Luckey e Joseph Phillips lançado em 2006 pela Wiley Publishing.

Sobre Requisitos e Projeto

"A parte individual mais difícil da construção de um sistema de software é decidir o que construir. Nenhuma parte do trabalho danifica tanto o sistema resultante se for feita errado. Nenhuma outra parte é mais difícil de consertar depois" (Fred Brooks).
"É melhor saber algumas das questões a todas as respostas" (James Turber).
"O milagre mais comum da engenharia de software é a transição da análise para o projeto e do projeto para o código" (Richard Due).
"Você pode usar uma borracha na prancheta de desenho ou uma marreta no canteiro de obra" (Frank Lloyd Wright).
"Um erro comum que as pessoas cometem quando tentam projetar algo completamente seguro tem sido subestimar a engenhosidade dos inteiramente doidos" (Douglas Adams).

Engenharia de Software - Uma história de amor e ódio

Palestra de Christian Reis na Feira de Informática 3.0 de 2003 na UFSCar. Eis alguns pontos:
- A profissão moderna mais difícil;
- Exige conhecimento técnico detalhado em uma área em constante ebulição;
- O que eu espero de vocês é que tenham paixão pelos seus produtos, e com estes produtos, que ajudem a construir o Brasil;
- Se não tiverem paixão pelos seus produtos me avisem para eu nem pensar em ser um consumidor;
- Esqueçam suas aulas: desenvolver software (de qualquer maneira) é Engenharia de Software;
- Não se enganem: escrever código, rodar e testar é um processo de software;
- O que nos falta é uma visão de escala: para que tipos de tarefas são adequados que tipos de processo;
- Obviamente, a preocupação com processo de software é menor quando é um projeto de 3 horas;
- Processo de Software é um nome chique para descrever quando sentamos juntos e planejamos construir ou consertar algo:

• Descobrir o que tem para ser feito.
• Descobrir como será feito.
• Fazer. Fazer. Fazer. Fazer.
• Descobrir se faz mesmo o que era para fazer.
  (enxague, repita)

- Para aprender como construir software, precisamos de bons exemplos;
- Nenhum processo bem projetado é burocrático, inútil ou sem resultado. Mas o processo tem que se encaixar na sua equipe;
- Engenharia de Software é para ser divertido e interessante (e seu amigo na hora que dá tudo errado);
- Engenharia de Software ensina ter amor pela equipe, amor pelo usuário, amor pelo produto;
- Engenharia de Software é uma passo em direção à evolução da profissão;
- "Pessoas que dizem que algo não pode ser feito não devem interromper quem está fazendo" (Provérbio Chinês)

O que é Engenharia de Software?

Engenharia de Software é uma disciplina que reúne metodologias, métodos e ferramentas a ser utilizados, desde a percepção do problema até o momento em que o sistema desenvolvido deixa de ser operacional, visando resolver problemas inerentes ao processo de desenvolvimento e ao produto de software (CARVALHO, 2001).
Engenharia de Software é a criação e a utilização de sólidos princípios de engenharia a fim de obter softwares econômicos que sejam confiáveis e que trabalhem eficientemente em máquinas reais (NAUR apud PRESSMAN, 2006).
Engenharia de Software é: (1) aplicação de uma abordagem sistêmica, disciplinada e quantificável para o desenvolvimento, operação e manutenção do software; isto é, a aplicação da engenharia ao software. (2) o estudo de abordagens como as citadas em 1 (IEEE, 1993).