Eu não faço a mínima idéia de quantos leitores que passam por aqui diariamente trabalham com algum tipo de documentação ou fluxograma nos projetos em que participam. Este texto é uma espécie de pesquisa para descobrir isso. Quais os tipo de documentação você lida e em que contextos?
Pessoalmente nos últimos tempos eu comecei a “arquitetar a informação” de um projeto de forma mais gráfica utilizando diagramas, em específico o diagrama de Garrett. Tenho participado também do processo de análise (mesmo não tendo formação em ciências da computação ou algo parecido) fazendo o levantamento de requisitos funcionais e não funcionais, descrevendo o que o sistema terá, fluxos de navegação e interação do usuário etc (posteriormente nos diagramas), em equipe, junto com o programador.
Neste meu recente contexto, apenas eu e o Flávio Kaminisse (o programador) somos a “equipe”. Mesmo que ambos tenhamos especialidades diferentes, os questionamentos mútuos contribuíram para dar soluções ao nosso “problema”. Juntos nós fizemos o levantamento destes requisitos, documentamos os campos do sistema e posteriormente ele sozinho escreveu um documento de regras de negócios dentre outros específicos para que os futuros programadores que venham a trabalhar no projeto não se sintam perdidos. Mas o que eu percebi de vantagens nessa brincadeira foi o quanto participar desse processo inicial em equipe foi fundamental ao evitar erros futuros, ao detalhar trechos complexos e requisitos não funcionais do sistema que teriam algum impacto no desenvolvimento.
Após todos estes detalhes da análise e de requisitos é que eu montei um diagrama com a interação do usuário e adicionei pequenos comentários nele, (construído noVisio ) em cada “página”, com os tipos de campos e detalhes que seriam úteis se algum outro designer chegar a colocar a mão no meio do processo de desenvolvimento. Coloquei alguns comentários também do tipo, “isto deve ser em formato de telamodal”, ou então “deve utilizar o script tal e usar máscara nos campos”, e assim por diante.
Existe o documento perfeito?
Concordo com Fahey ao dizer que não existe o santo graal da arquitetura da informação em termos de documentação. Não só na arquitetura, mas em desenvolvimento de software ou análise ou o que for.
Não existe um documento “perfeito”, o que existe são soluções perfeitas para contextos específicos, nem demasiadas e nem pobres. Em um site pequeno, com apenas um formulário de contato de “programação” não vale a pena perder tempo fazendo levantamento de requisitos, análise, etc etc etc… No máximo um documento de MindJet com o que cada página tem que ter de informação é mais que suficiente.
Quais os contextos?
Os contextos para documentação podem ser muitos e serem influenciados pela experiência e maturidade da própria equipe. Qual é o nível de detalhamento destes documentos? Alguém conhece o Getting Real já citado pelo Walmar? Há projetos em detalhes exagerados que chegam a se tornar fetiche para alguns, e para quem aplica o Getting Real em tudo podem faltar detalhes “teoricamente” de extrema importância.
Outro contexto do resultado final destes documentos é a especialidade de quem os cria e os objetivos finais. Um analista sem nenhuma experiência com programação terá uma visão de um documento de análise completamente diferente de um programador experiente que só agora está começando como analista. Um arquiteto da informação que não sabe a diferença em HTML e CSS (exagerando um pouco) vai gerar um diagrama de interação ou detalhamento diferente de um profissional que era (ou ainda é) web designer com muita experiência em programar no client side.
Um documento de levantamento de requisitos tem objetivos completamente diferentes de um diagrama de interação do usuário, e assim por diante.
Acredito que o contexto e o bom senso do desenvolvedor vão guiar e levar um projeto ao sucesso, contemplando boa produtividade dos envolvidos, evitando surpresas e retrabalho durante o desenvolvimento, obtendo resultados elegantes, etc. “A documentação foi criada para o homem ou o homem foi criado para o documento?”, diria Jesus se fosse um gerente de projetos hoje! Mesmo que o ROI final não consiga mensurar certas coisas, os envolvidos no projeto vão saber no final o quão fácil de mexer no código de um projeto grande, o quão otimizado ele ficou, etc.
Por isso eu te pergunto: Como você documenta seus projetos? Quais os contextos em que isso ocorre? Quais as exceções? Usa alguma ferramenta específica? A quantidade de comentários neste texto vai revelar se apenas uma minoria trabalha com algum tipo de documento, ou então que essa minoria é ocupada demais para deixar um comentário aqui para iniciar um diálogo, ou então que eu escrevi um texto longo demais…! [Webinsider]
.
Henrique Costa Pereira
Henrique C. Pereira é UX/UI na Zup, ficou zen, sumiu da internet e fotografa a vida passando nas horas vagas.
12 respostas
Creio que a modulagem de qualquer projeto, desde de um hotsite até um portal é extremamente necessária. Ao começar um projeto somente com briefing, em seguida design e programação é fácil, e depois?! E o feedback do cliente?! E quando ele começar a pedir alterações, alterações e alterações? É nesse ponto que começa a complicar e transformar aquele site em um verdadeiro frankstein.
Ao comprar um carro, o cliente não compra só pela sua beleza, mas também pela maneira de manuseá-lo, tal como direção, freios, marchas, ele tem o desejo de saber como funcionará o carro antes de adquirir. O mesmo, na minha opinião, acontecem com os sites, o cliente quer saber como irão navegar ele, porque existe isso, porque existe aquilo e melhor saída é construir uma modelagem de tudo isso e explicar ao mesmo como funcionará todo o processo. Isso vale desde o início.
Documentação é ótimo, mas sem exageros.
Métodologia é sempre importante, e fundamental no processo criativo.Creio não importa em que software se utilize para fazer esse controle, o importante é fazer.
Mas penso que o nível de detalhamente da documentação vai depender da complexaxidade do projeto. Site de Padarias não precisam de documentação, pois serve o basicão, briefing, concepção e produção.
Mas lendo o GettingReal, eles tem uma visão espartada do processo todo, simplicidade ao extremo.
Obrigado pelo artigo, muito bom
Ops!
Detalhe né!?
Sempre, sempre depende da dimensão do projeto a utilização de todos ou parte da documentação citada.
Vale a pena e ajuda bastante no planejamento e desenvolvimento dos projetos.
1. Briefing
2. Cronograma Macro/Micro
3. Arquitetura Macro/Micro/Detalhada
4. Fluxograma
5. Diagrama de fluxo de dados
Eu uso alguns modelos de documentações, e elas variam dependendo de cada projeto. Vão desde sitemaps, casos de uso, fluxos de interação/navegação. Quanto à entrega, na minha função, hoje, a entrega principal são os wireframes.
Sobre a metodologia aplicada, acho que nem é o caso de saber se têm os passos A, B ou C. Uma das coisas que pude aprender na universidade, é que um bom projeto de design tem, necessariamente, uma metodologia. Seja ela rígida ou flexível. Há muitas metodologias de projeto por aí, algumas muito práticas, outras até bem filosóficas. Escolha uma, tente trabalhar com alguma delas.
Sobre os documentos, acho que um passo importante nas documentações geradas é que elas sejam APROVADAS por alguém (leia-se cliente) e sirvam para definição do escopo do projeto. Pode parecer tolo, mas um dos problemas é que nem sempre isso ocorre. Há clientes que não entendem os documentos e só começam a perceber o projeto quando têm, como gosto de dizer, evidências físicas do job (como os wireframes, por exemplo) E aí resolvem solicitar alterações, mexendo em cronogramas, prazos, gerando retrabalho, etc.
Mas é óbvio que a documentação é fundamental em projetos web, até porque em alguns casos ela serve de escudo para o teu trabalho. Não abra mão dela.
_______
Acho pertinente o artigo. Mas Henrique, na boa, é desnecessário esse tipo de cobrança no teu texto:
…A quantidade de comentários neste texto vai revelar se apenas uma minoria trabalha com algum tipo de documento, ou então que essa minoria é ocupada demais para deixar um comentário aqui para iniciar um diálogo,…
Fica o recado.
Grande abraço!
… aahhh, e repondendo a pergunta, utilizo documentação sim. Se for site instituicional apenas desenho o mapa do site e a navegação. Para sites maiores faço também Use Cases, Diagramas de Classe e MER, documento o Escopo, o Perfil do Cliente e do Publico alvo. Tudo com Word, Visio e DBDesigner.
Eu adaptei uma metodologia tradicional de desenvolvimento de software para uma metodologia mais ágil e flexível, voltada para web. Essa metodologia consiste basicamente em quatro etapas:
1 – Design
2 – Concepção Visual
3 – Concepção Funcional
4 – Pós Produção
Cada uma das Etapas possui subetapas relacionadas, como por exemplo em Design há Briefing e Wireframe, em concepção visual há Layout e Estilos CSS, em Funcional há Use Cases, Diagramas de Classe e Programação, etc.
Muito interessante pra mim que não utilizo nenhuma documentaçao além do word. (que vergonha rs).
Não é só porque trabalho como freelancer não.
Nas 3 empresas que trabalhei nenhuma delas utilizava quaisquer tipo de documentação, nem mesmo um briefing rolava…
Por isso este (e outros) artigo pra mim é tão importante, porque quero fazer as coisas certas em 2007.
E os comentários só enriquecem…muito bom.
Desde que me formei tenho tentado fazer documentações para os meus projetos seguindo uma metodologia própria (para ver a minha metodologia, criei um pdf faz um tempo já.. http://cezinha.com.br/tutorial/metodologia.pdf), baseada em muitas que já vimos por aí.
Basicamente, segue o que o Walmar citou.
1. Briefing
2. Estrutura de Navegação
3. Cronograma
4. Criação da Interface
5. Programação
6. Manutenção
Tento documentar todos os projetos seguindo essas etapas, porém nem sempre é possível tendo em vista o prazo. Tento sempre gerar o briefing, a estrutura do site (árvore do site, wireframe e fluxogramas) e se possível, um resumo de funcionalidades se tiver alguma programação mais complexa (fora formulários de envio de e-mail, por exemplo).
Mas como nem sempre é possível, me restrinjo basicamente a árvore do site, e alguns wireframes.
Os softwares que uso para isso são Adobe Illustrator (para montar a árvore de navegação – as vezes, o Microsoft Visio, mas nem sempre dá), o Microsoft Project, e na maioria das vezes um bloco de notas. E muitas folhas de papel. Sempre rascunho alguma coisa em folhas avulsas mesmo.
Sou designer, mas tenho também o conhecimento na área de programação. Então acabo sempre fazendo tudo do site. Tendo em vista que a minha equipe é formada só por mim mesma.
Aqui na Garimpar utilizamos muito o Dia e o Trac nas atividades relacionadas a documentacao.
Tambem temos docs que funcionam como um Roadmap da solução, que serve como DNA do produto mas na visao de usuário e funcionalidades.
Muito boa essa materia, parabéns.
Jose Roberto (http://www.garimpar.com/busca/sobre/#nos)
Estou entrando no mercado agora, mas já sei a importância de uma boa e ágil documentação. Nos poucos e pequenos projetos que fiz utilizei o DIA como ferramenta para gerar diagramas de navegação/fluxo de dados.
Antes de começar qualquer projeto sempre procuro documentar itens como objetivos, mercado, público-alvo, produto e concorrência. Em seguida vêm os documentos de arquitetura de informação (mapas e wireframes), conteúdo e as diretrizes de design. Após o desenvolvimento em si sempre procuro centralizar em algum lugar as informações em relação a estilos, códigos, programação e histórico de modificações. Um exemplo pode ser visto nesta série.
Depois que li o Getting Real estou tentando deixar de ser tão metódico, flexibilizando a questão da documentação em prol da produtividade quando o custo/benefício não valer a pena (principalmente em projetos pessoais). Para clientes, especialmente os mais exigentes, não vejo como fugir disso.