Existem vários meios, vou tentar relatar alguns...
Se a cidade for próxima, tente ir visitar a empresa.
Lidar, ver e conversar com o pessoal para o qual você trabalhará é um ponto importante, principalmente se você está construindo uma intranet.
Supondo que seja uma intranet, é de vital importância selecionar empregados e fazer uma entrevista com eles, perguntar dificuldades, desejos, etc.
Se for um site, mas que o empregados irão utilizar, proceda da mesma forma.
Se for apenas um site, para clientes externos, ambientar-se com local da empresa, o estilo de trabalho é importante para você captar o "espírito de trabalho" do grupo. Pode parecer absurdo, mas o ideal é isto.
Caso não seja possível visitar a empresa, a coisa complica...
Basicamente, você terá que agendar diversas reuniões com o cliente, inicialmente perguntando sobre o funcionamento da empresa. Em seguida, comece a perguntar pelos recursos, desejos, etc deste.
Nesta parte, você obterá alguns dados importantes... mas nada definitivo. Geralmente, o pessoal faz um briefing do sistema, ou seja, algumas perguntas pertinentes a desejos do cliente, recursos e notas importantes para que ele consiga expressar sucintamente o desejado e que você consiga compreender exatamente o que o cliente espera.
A partir daí, entra a parte da Engenharia de Software.
Nesta matéria, você aprende a gerar modelos de software, baseados no que o cliente te indicou. Geralmente, o modelo é no padrão I3E (IEEE).
Após isto, empregam-se cálculos para estimativas de custo (um projeto tem que ser viável tanto para a empresa contratante quanto para a contratada). Não me recordo ao certo qual é o modelo mais utilizado... COCOMO ou CMM (se eu não estou confundindo as bolas estes são métodos de cálculos).
A partir daí, você tem uma documentação de requisitos funcionais e não funcionais, um custo para repassar ao cliente. Fora isto, você obtém número de linhas de código estimado para o projeto, número de programadores, tempo para realização do projeto, ...
Pode parecer surreal, mas é o que a Eng. Software te proporciona.
Se o cliente fechar contrato com você, terá agora que reunir-se com as equipes de projeto e discutir o melhor meio de gerar este software (lembre-se... um site também é um software!!!).
Existem diversas formas, o de prototipação, extreme programming, etc.
Geralmente, as empresas preferem o modelo de prototipação não-descartável (ou seja, o protótipo gerado para mostrar ao cliente é o mesmo que se origina o projeto final).
OBS.: prototipação descartável => as equipes trabalham em telas, interfaces sem se preocuparem com otimização e apresentam ao cliente. Este avalia, sugere alterações. O protótipo é descartado e inicia-se a criação de outro protótipo descartável. Estes procedimentos constinuam até que o cliente diz "Isso!". Joga-se então o protótipo fora e inicia-se o projeto definitivo.
extreme programming => o cliente sequer tem um "feeling" de uma sistema. Diversas sub-equipes são geradas e cada grupo é responsável pela criação de itens específicos do projeto. No final, agrupa-se tudo e o software está pronto. Tempo de desenvolvimento cerca de 1/3 menor que o modo por prototipação, mas corre-se o risco do sistema não agradar muito o cliente.
Supondo que escolhemos o prototipação descartável. Nestas reuniões com os grupos, define-se o ME-R (Modelo de Entidade e Relacionamento (estrutura básica dos bancos de dados), geração de documentações específicas (o método extreme programming pode ser utilizado, para a geração dos protótipos), etc).
NOTA: Imagine 30 equipes trabalhando num mesmo projeto. Cada uma cria um componente específico.
Se tudo não for muito organizado, tudo documentado, imagine a chamada de um método de uma classe... a equipe A construiu a classe:
variável = new Classe();
variável.método( arg1, arg2, arg3 );
A equipe B utiliza este método para efetuar a tarefa X. Se não for tudo muito bem documentado, eles podem achar que a chamada do método é:
variável.método( arg3, arg1, arg2 );
e o software nunca funcionará.
Acho que agora entendem a importância de uma boa documentação.
Quanto aos comentários no código... é tão importante quanto uma documentação (isso se não for mais importante).
Imagine que depois de 1 mês, o cliente resolve adicionar um recurso X no projeto. Suponha também que 3 equipes foram demitidas e você e sua equipe ficaram encarregados de alterar alguns itens do código fonte e adaptar este addon que está sendo criado por uma outra equipe...
Onde você vai alterar??? Se não estiver tudo bem documentado, você levará MUITO tempo para encontrar o ponto correto para alterar... digo muito tempo mesmo!!! um software com 250 mil linhas... você levaria algo em torno de... uns 3 meses para conseguir achar os locais onde deve-se alterar. Isto torna-se inviável para a empresa. =\
Voltando à parte do cliente do site......
Você fez a documentação, apresentou o orçamento... ele fechou o contrato (notas quanto a isso, veja abaixo). Hora de projtar os requisitos em termos de programação.
NOTA: Um contrato geralmente deve especificar todos os itens requeridos.
Grandes empresas normalmente utilizam a seguinte faixa de preço para a inserção de um novo recurso enquanto o projeto está sendo feito:
Listagem normal, antes do início do projeto = preço normal
Novo recurso, durante a fase de documentação = 5 x preço normal
Novo recurso, durante a fase de implementação = 20 x preço normal
Novo recurso, após a entrega do projeto = 100 x preço normal.
É de suma importância que os recursos sejam listados no contrato. Pois se não forem, o cliente pode pedir mais N recursos e você não poderá alterar o valor do projeto. Entendeu?! Pois o contrato já foi fechado.
Do contrato:
Para que seja uma coisa oficial, crie o contrato, assine e faça com que o cliente assine também. Reconheça ambas as firmas. Registre em cartório, para que não haja violação neste.
Geralmente, fica uma cópia autenticada para cada uma das partes (contratante/contratado).
Você verá que a qualidade do seu trabalho melhorará 300% adotando medidas simples, além de melhorar sensivelmente a velocidade de desenvolvimento de projetos.
Ah... e por favor. Se você quer realmente realizar um projeto, seja ele de pequeno, médio ou grande porte, não haja como criança.
Muitas pessoas estudam décadas, especializando-se para criar sistemas confiáveis. Amadores então realizam orçamentos incompatíveis com o valor real do projeto, desmerecendo então os que estudaram muito. Além do mais, criam sistemas nada confiáveis, amadores (posso dizer, newbies).
Posso citar como exemplo a minha pessoa. Estudei duro durante 8 anos, me dediquei para me tornar especialista em diversas linguagens.
Quando decido me lançar no mercado como freelancer, vejo o quão desmerecedor de tempo foi o que eu me dediquei. Do que adianta tornar-se especialista, saber 25 linguagens diferentes, se o cliente acha um absurdo pagar por um sistema, que se convertido para reais/hora, dá cerca de 5 reais?!
Vamos dar um exemplo (fictício, pois não quero citar nomes). Me propuseram a criar um sistema de enquete. Demoraria, vamos supor.... 10 horas para construir este sistema. Cobro 50 reais do kra (veja bem, dá 5 reais/hora de trabalho) e este cliente me vira e fala assim: "Tá caro!!! Abaixa isso..."
Minha educação não permite, mas adoraria virar pra ele e falar assim: Trabalha pra mim então por 3 reais/hora? Se você aceitar, eu faço seu sistema.
É o que eu digo... muitos amadores estão preocupados em comprar o "skate" novo (não levem skate ao pé da letra, mas sim como uma representação de comprar algo que queiram) e criam sistemas por um valor até 30x menor que o preço real do sistema.
O que eu quero dizer é pra vocês pensarem e agirem como profissionais, não como crianças. Do que adianta vir um kra aqui no Fórum e falar assim: "Como faço um sistema de newsletter?" e vira um membro e dá o código pronto? A pessoa não aprendeu nada! O que isso mudou na vida do usuário?! Nada.
Penso que se querem evoluir, corram atrás. Não vai ser dando a comida na boca todos os dias que vocês vão se tornar profissionais de respeito.
Indo mais longe... imaginem vocês sendo um tigre. Se vocês viverem num zoológico, tendo comida na boca todos os dias. Um dia, o zoológico fecha as portas e vc é devolvido à selva. Conseguirá sobreviver? Duvido. Sequer sabe caçar...
O mesmo acontece no mercado de trabalho. Se vocês tiverem tudo de mão beijada sempre, nunca serão desenvolvedores.
Não é porque você leu um tutorial qualquer da linguagem X, e construiu um sistema Y, bugado, cheio de brechas de segurança que você pode virar pra todo mundo e falar que é um developer. Disse isso ontem para o Leandro Abdalla (vulgo Chester). Seja bom no que você faz, para se considerar programador na linguagem X.
Acho que vocês nunca viram, sequer perceberam, mas somente em 2003 eu passei a escrever web developer em alguns pontos do Fórum.
Agora... vocês nunca imaginaram o porquê, somente depois de 7 anos como scripter eu comecei a colocar isso embaixo da minha assinatura?! Porque eu não me considerava um developer.
Muitas vezes já pensei em parar de escrever isto na minha assinatura, principalmente pelo fato de saber somente uns 70% de uma linguagem. Hoje por exemplo... um cliente me pediu X recursos, dos quais sei fazer apenas X - 2. Será que sou realmente especialista, programador da lingagem tal, se não sei fazer 2 sistemas?!
Pensem nisso...
Sei que estou cutucando a ferida de muita gente aqui, mas estou indignado com o que vem acontecendo não só neste Fórum, mas em outros lugares da rede.
Um kra aparece do nada e pergunta:
Como crio um menu suspenso?
O outro vai e escreve assim:
Usando layers e alterando sua visiblidade com os métodos onmouseover e onmouseout...
Aí aparece 144 pessoas criticando o membro "outro", porque ele não escreveu o código. Eu deveria elogiar esta pessoa, inclusive dar o cargo de manutenção pra ela. Ela não só respondeu a dúvida, mas também fez com que o usuário tivesse que procurar algo, testasse coisas para fazer o sistema funcionar. Resumindo, faz com que o o "kra" APRENDA!
Agora, o que adianta vir essas 144 pessoas e postarem um código pronto?! O que o "kra" aprendeu?! Nada.
Ele sabe então como usar um menu suspenso já criado, mas sabe realmente criar um? Não.
O pior é que o "kra" ainda vira pros outros e fala que é developer.
Teve um membro, recente aqui no fórum (não vou citar o nome, mas você saberá que é você), que me disse que era expert em JS e PHP. Fiz então 2 perguntas pro kra:
1- Qual a compatibilidade do método do objeto document, o getElementById?
2- Qual a diferença entre mysql_affected_rows e mysql_num_rows?
Ele não soube responder nenhuma. Como ele se considera expert se não sabe o item básico de captura de objetos nos borwsers que suportam DOM (IE5+, NN6+, Mozila (todos) e Opera 5+)?
Como ele se considera expert se ele não sabe o básico da captura de linhas alteradas ou selecionadas num banco de dados?
Enrolei, enrolei, mas quero realmente tocar no ponto que vocês devem pensar bem no que fazem, e não dizerem asneira.
Tem gente não só aqui, mas em muitos outros lugares que estudam e inclusive trabalham com isto, e ostentam o web developer ao lado no nome, que vem sendo denegrido por usuários amadores.
cafesigner, desculpe por no final da minha resposta eu ter fugido completamente do assunto original, mas no início eu respondi sua dúvida.
Peço desculpas pelo desabafo, mas é o que eu sinto no momento.
Grato,
